From nobody Fri Nov 1 07:57:17 2019 Return-Path: <0100016e27785ce1-6ade1cd2-78fc-40ee-bb4d-f7c4b685e3d3-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 F266512089C; Fri, 1 Nov 2019 07:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 kQRD-adIZzzC; Fri, 1 Nov 2019 07:57:14 -0700 (PDT) Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F12E1208A3; Fri, 1 Nov 2019 07:57:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1572620230; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Message-Id:Date:Cc:To:Feedback-ID; bh=aIHf8U1M8pAbM8xZWJ+mEEi3X4czSD0Rl5AJWQ+ad28=; b=HwStyqwc8OXur+kxt1etfAu+heFAVsTaP9EwRxzWQvet9VTLbTUkhbfBDvAJmJ9W JbzqBE7bhP2t7HJZuSPPICJNbDJDX56c2S2hgUlCqqK1npP5OIwI3BofafUUiFI77sc Siyo+8fzjN1mAESrYtvSD4mP3mmuQozG9F9mrqxE= 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: <0100016e27785ce1-6ade1cd2-78fc-40ee-bb4d-f7c4b685e3d3-000000@email.amazonses.com> Date: Fri, 1 Nov 2019 14:57:09 +0000 Cc: draft-ietf-netmod-factory-default@ietf.org To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.11.01-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] WG Last Call: draft-ietf-netmod-factory-default-05 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, 01 Nov 2019 14:57:16 -0000 This begins a two-week Working Group Last Call (WGLC) on = draft-ietf-netmod-factory-default-05. The WGLC ends on Nov 15 (two days = before the NETCONF 106 session). Please send your comments to the = working group mailing list. 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 Fri Nov 1 08:08:20 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C221200A1; Fri, 1 Nov 2019 08:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=EKm3JAsa; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=pr02BJV/ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GlOt12InHGh; Fri, 1 Nov 2019 08:08:16 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07E9912009C; Fri, 1 Nov 2019 08:08:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1340; q=dns/txt; s=iport; t=1572620896; x=1573830496; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=xO7NUvTJoVpOrCFVPKk4re+9TZOQ0z+ve2BvaS9acpc=; b=EKm3JAsatPFxFHUhJdC1dVeElRQ++jLWra/o/dcHBx6Tt1u5U3CaITvH ZbxHtvyZY2pn17e4KIlu5e8zSEKRvFvcjKnXAkj0NgK7fvEGItyEpMqWL sKEOmLYFs99gZd+2TWTq6ZcqJaPZMa4PCAIDAkpOipzIrkzy8ib27W3Zf 8=; IronPort-PHdr: =?us-ascii?q?9a23=3AFJm2ZBaJbD9G4SgHFQZ/3/3/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gebRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavoZCgzBsdPfFRk5Hq8d0NSHZW2ag=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BNAADUSbxd/49dJa1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgWkHAQELAYFKUAWBRCAECyoKhB6DRgOEWoYbgjkll3yBLoEkA1Q?= =?us-ascii?q?JAQEBDAEBLQIBAYRAAheDZCQ0CQ4CAwsBAQQBAQECAQUEbYU3DIVRAQEBAQI?= =?us-ascii?q?BEhERDAEBLAsBBAsCAQgYAgImAgICMBUQAgQOBSKDAIJHAw4gAacqAoE4iGB?= =?us-ascii?q?1gTKCfgEBBYUZGIIXCYEOKAGMEBiBQD+BEScME4JMPoRFgxAygiyNHSyCNIV?= =?us-ascii?q?gmBkKgiSVNRtagWKHWo9PqBQCBAIEBQIOAQEFgVI5gVhwFTsqAYJBUBEUgwa?= =?us-ascii?q?Dc4pTdIEojDYBgQ0BAQ?= X-IronPort-AV: E=Sophos;i="5.68,256,1569283200"; d="scan'208";a="355011040" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Nov 2019 15:08:15 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id xA1F8EcF011150 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 1 Nov 2019 15:08:15 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 1 Nov 2019 10:08:14 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 1 Nov 2019 10:08:13 -0500 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 1 Nov 2019 10:08:13 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=abjGuqjdw1gIeqPgoAxe0rfUtHDiqZrXqaiKkP6gBNwDWwVtuFS5ySitbSA1AAGMRegNao1q+b7q005P56qM5BWe0P8+buNJUKlMTagBxLZI2dUZlBIF0q4IlioZsFvyg4Y6GvT/FS1LoqQY8U8gCsiy0CWdHrIaJVAfRuSjd1eqaqoBWWuLXQutw262Es61pIlkhbQLzdYwc9CKMgm1N0SBzabxXt8FRCU081IdRUbyGrgUE3PM4hOL/I3t57S4zaQ1aGdbKrlMQYZlUSJnaBpzS1oJTR/lIueP/MqF9COdg4sTcn30eedQ1riyvbflbXm7VtciY3Bka5RsrGrfWg== 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=xO7NUvTJoVpOrCFVPKk4re+9TZOQ0z+ve2BvaS9acpc=; b=UyYlm1ATRaZgTchjTAU7OrRIP/AyHX4Y5r5GgXkIYKTY4IWJ40JmrGrcGWFI+J0ObmTT2as2r3JRlFl0pGMyNF+CVf6syr9nJNsR97EiNDGCBfOYY38N08Qxe07B1wnDw4XW/odcz+/iW/vArHu51vbhXIl6bEf6UFo3yTkFXMsrffEO5daQ0pvS4tl5ptH0gePlh4yMg8/e70ioedKMFkZ/2sffsY1PjMBL3tqrumQanGPexkDlrwQxMwAEkVmK9oEZg5Jd9jwiT6CfT2wf6VuarNNSGGzMT/yGAuT0q68Crc4Le/T0AW0oZdjVHhZBjSfwxbVgDWGRpMegGtNAVA== 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=xO7NUvTJoVpOrCFVPKk4re+9TZOQ0z+ve2BvaS9acpc=; b=pr02BJV/yiW6zqqbh2eTIfhzgYdNHgnPLrTGn3ftj2eOie7N0XsNptgucp/42IIgPjBSh5WnVqiGTPCytYHAfIV2BSapj/oWX7EsPKBt+uloqmKovAUK+5iGfkLgnYkIHi8a3dA3PUDQelI/zQL2s/BX8Wb8NlGmrrtz5qPlXUA= Received: from BN6PR11MB1667.namprd11.prod.outlook.com (10.172.23.12) by BN6PR11MB1794.namprd11.prod.outlook.com (10.175.100.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2408.24; Fri, 1 Nov 2019 15:08:12 +0000 Received: from BN6PR11MB1667.namprd11.prod.outlook.com ([fe80::499:8548:e967:458e]) by BN6PR11MB1667.namprd11.prod.outlook.com ([fe80::499:8548:e967:458e%12]) with mapi id 15.20.2387.028; Fri, 1 Nov 2019 15:08:12 +0000 From: "Joe Clarke (jclarke)" To: Kent Watsen CC: "netconf@ietf.org" , "draft-ietf-netmod-factory-default@ietf.org" Thread-Topic: [netconf] WG Last Call: draft-ietf-netmod-factory-default-05 Thread-Index: AQHVkMTAZBzY+UUmZkims0FnmWt9D6d2atCA Date: Fri, 1 Nov 2019 15:08:12 +0000 Message-ID: <3EBC8D26-8205-47F2-B46E-5774C21A517C@cisco.com> References: <0100016e27785ce1-6ade1cd2-78fc-40ee-bb4d-f7c4b685e3d3-000000@email.amazonses.com> In-Reply-To: <0100016e27785ce1-6ade1cd2-78fc-40ee-bb4d-f7c4b685e3d3-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=jclarke@cisco.com; x-originating-ip: [173.38.117.76] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ef5525fa-e2b9-4e5e-fa8b-08d75edd5062 x-ms-traffictypediagnostic: BN6PR11MB1794: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 020877E0CB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(396003)(39860400002)(136003)(376002)(366004)(189003)(199004)(6512007)(66446008)(66066001)(7736002)(2906002)(71190400001)(305945005)(71200400001)(186003)(4744005)(3846002)(2616005)(6116002)(33656002)(476003)(11346002)(446003)(14444005)(256004)(86362001)(486006)(5660300002)(64756008)(14454004)(6246003)(6486002)(25786009)(81156014)(8676002)(81166006)(229853002)(6436002)(478600001)(316002)(76176011)(6506007)(36756003)(102836004)(53546011)(8936002)(91956017)(76116006)(26005)(54906003)(4326008)(66946007)(555904003)(66556008)(66476007)(99286004); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR11MB1794; H:BN6PR11MB1667.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: qSNatEmIaMj3N0QtAMdUTI7eK/hZUk8pyJwOKPbmXLj5/9GgrWlbpLe+E7Rui+NcYHs3OAHfpJD2NlcgxbtlPRW+gr4d6XU9b1KTIOrgzbhKlpu35aM2I4aB1xARpiRJoOcUdc9K6k0aQlrSWQqeQyXCk5jv3JRjRfaMX5zsczF6RopbIsdH19uMWc0dQCCJ1p/RkOqaNYSpLNYfTgCZdUXxdiqdX23doqDfQjex0cABFmfVSbgFqdSA40s3/kMvs++eDEunVOnTtL2elWWTE8Rce5qpvoJQCMXUcqbDImuVgkDpfrYVNtYSxVjm7UnDxM32a54cTCq0uhylnASbdRZt+ucY7dzb25NtPDvcLa0XQulW3jOGduTw0jv7YLGJ3pyBfRFT8RtEDRtkLlU8ko8Q+xRH75QrZqvJdplPZAQWJywt5lTH94As068LI8Wc x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ef5525fa-e2b9-4e5e-fa8b-08d75edd5062 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Nov 2019 15:08:12.4502 (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: bXHRYNWpjlJp+7gsi8U+dAkW7ujUkobDO30zOCgXiXNYXgfkXn1ehS64ZukRYecCR8TBonvTMZK2U2Q5fC4TBA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1794 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.18, xch-rcd-008.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [netconf] WG Last Call: draft-ietf-netmod-factory-default-05 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, 01 Nov 2019 15:08:18 -0000 DQoNCj4gT24gTm92IDEsIDIwMTksIGF0IDEwOjU3LCBLZW50IFdhdHNlbiA8a2VudCtpZXRmQHdh dHNlbi5uZXQ+IHdyb3RlOg0KPiANCj4gVGhpcyBiZWdpbnMgYSB0d28td2VlayBXb3JraW5nIEdy b3VwIExhc3QgQ2FsbCAoV0dMQykgb24gZHJhZnQtaWV0Zi1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0 LTA1LiAgVGhlIFdHTEMgZW5kcyBvbiBOb3YgMTUgKHR3byBkYXlzIGJlZm9yZSB0aGUgTkVUQ09O RiAxMDYgc2Vzc2lvbikuICBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSB3b3JraW5n IGdyb3VwIG1haWxpbmcgbGlzdC4NCj4gDQo+IFBvc2l0aXZlIGNvbW1lbnRzLCBlLmcuLCAiSSd2 ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFuZCBiZWxpZXZlIGl0IGlzIHJlYWR5IGZvciBwdWJs aWNhdGlvbiIsIGFyZSB3ZWxjb21lISAgVGhpcyBpcyB1c2VmdWwgYW5kIGltcG9ydGFudCwgZXZl biBmcm9tIGF1dGhvcnMuICBPYmplY3Rpb25zLCBjb25jZXJucywgYW5kIHN1Z2dlc3Rpb25zIGFy ZSBhbHNvIHdlbGNvbWVkIGF0IHRoaXMgdGltZS4NCg0KSW4gZ2VuZXJhbCwgSSB0aGluayBpdOKA mXMgcmVhZHkgdG8gZ28uICBUd28gbml0czoNCg0KKiBNeSBuYW1lIGlzIG1pc3NwZWxsZWQgaW4g dGhlIGFja25vd2xlZGdlbWVudHMNCg0KKiBJbiBTZWN0aW9uIDI6DQoNCk9MRDoNCg0KMi4gYnkg dmVuZG9ycyB1c2luZyBZQU5HIEluc3RhbmNlIERhdGEgW+KApl0gZmlsZSBmb3JtYXQgaW4gdmVu ZG9y4oCZcyB3ZWJzaXRlIG9yIG90aGVyIHBsYWNlcyB3aGVyZSBvZmYtbGluZSBkb2N1bWVudCBp cyBrZXB0Ow0KDQpORVc6DQoNCjIuIGJ5IHZlbmRvcnMgdXNpbmcgYSBmaWxlIGluIFlBTkcgSW5z dGFuY2UgRGF0YSBb4oCmXSBmb3JtYXQgb24gdGhlIHZlbmRvcuKAmXMgd2Vic2l0ZSBvciBpbiBv dGhlciBwbGFjZXMgd2hlcmUgc2ltaWxhciBvZmYtbGluZSBkb2N1bWVudHMgYXJlIGtlcHQ7DQoN CkpvZQ0KDQo= From nobody Fri Nov 1 08:18:30 2019 Return-Path: <0100016e278bd4fb-145dce0d-46df-4866-942f-391910bd8376-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 E98421208D1; Fri, 1 Nov 2019 08:18:29 -0700 (PDT) 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 l-abZCaJJfkt; Fri, 1 Nov 2019 08:18:27 -0700 (PDT) Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 531D71208CD; Fri, 1 Nov 2019 08:18:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1572621506; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=SyDKGiPcLfAbi14X3PjsSQmvjzAGuVtBYrhoEPnOx30=; b=i1pJYy9wX6TJUFWnLnJ/PEuzFl5LDxQwxoQBYwCMvnHOnBWqBQ0bCXHlIGboAXev 7DmVQFyfA1tq9nLA4cvXUnJCzYwIF8DnsXaTqua2cemgBAw6zkvfP142NqAPpZZc4fD 1ULyGTt7wB6y3oFVCHsPj5F06Ti5dJ7ueITRLxv4= From: Kent Watsen Message-ID: <0100016e278bd4fb-145dce0d-46df-4866-942f-391910bd8376-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C10FB0F9-23DA-434B-8B9A-0D0941F638AC" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 1 Nov 2019 15:18:25 +0000 In-Reply-To: <0100016e27785ce1-6ade1cd2-78fc-40ee-bb4d-f7c4b685e3d3-000000@email.amazonses.com> Cc: draft-ietf-netmod-factory-default@ietf.org To: "netconf@ietf.org" References: <0100016e27785ce1-6ade1cd2-78fc-40ee-bb4d-f7c4b685e3d3-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.11.01-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] WG Last Call: draft-ietf-netmod-factory-default-05 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, 01 Nov 2019 15:18:30 -0000 --Apple-Mail=_C10FB0F9-23DA-434B-8B9A-0D0941F638AC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have reviewed -05 and support it so long as the following comments are = considered: Kent // contributor =3D=3D=3D=3D review =3D=3D=3D=3D Section 1 is missing a NMDA-compliance statement, per https://tools.ietf.org/html/rfc8407#section-3.5 = . Section 2 says: Factory-default content SHALL be specified by one of the following means in descending order of precedence 1. For the , and datastores as the content of the datastore, if it exists; The (1) sentence doesn't flow from the sentence before. Maybe you mean something like: 1. Network management protocol (e.g., NETCONF, RESTCONF) operations may be used to access the contents of = . Section 2 says: For the server supporting zero touch bootstrapping mechanisms, the factory default configuration causes the bootstrapping process to execute,e.g.,the server might reset configuration to device's factory default configuration,for the version of operating system software it is running. s/the server might reset /the server resets / Section 2 says: In addition,the "factory-reset" RPC might also be used to trigger some other restoring and resetting tasks such as files cleanup, restarting the node or some of the software processes, setting some security data/passwords to the default value, removing logs, or removing any temporary data (from datastore or elsewhere), etc. s/the "factory-reset" RPC might /the "factory-reset" RPC MAY / ??? Section 3 says: this document introduces a new datastore resource named 'Factory-Default' ... 'Factory-Default' should not be capitalized. Section 3 says: The contents of the datastore can be read using NETCONF,=20 RESTCONF and operations. Which doesn't make sense. Perhaps: The contents of the datastore can be read using NETCONF=20 and operations, and the RESTCONF protocol equivalents. Section 3 says: The operation can be used to copy the factory default content to a set of read-write configuration datastores and then the content of these datastores is propagated automatically to any other read only datastores, e.g., and . This is confusing. I think what you want to say is The operation copies the factory default content to and, if present, . Section 4 says: import ietf-netconf { prefix nc ; } import ietf-datastores { prefix ds; } These statements are missing "reference" statements. Section 4 says: description "The read-only datastore contains the configuration that will be copied into e.g., the running datastore by the factory-reset operation if the target is the running datastore."; which excludes and confusingly mentions a "target" when the RPC itself has no parameters. Perhaps: description "The read-only datastore contains the configuration that will be copied into and, if present, ."; Section 5. Please make the registrations have single-spaced lines. Section 6. The last paragraph doesn't make a point. Perhaps conclude with something like: "This module does not itself set "nacm:default-deny-write" on the=20 'factory-reset' RPC, leaving it to applications to configure the access control settings." Appendix B should have a note to the RFC Stream Editor to=20 remove it when the draft is published. Kent=20 > On Nov 1, 2019, at 10:57 AM, Kent Watsen wrote: >=20 > This begins a two-week Working Group Last Call (WGLC) on = draft-ietf-netmod-factory-default-05. The WGLC ends on Nov 15 (two days = before the NETCONF 106 session). Please send your comments to the = working group mailing list. >=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 >=20 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --Apple-Mail=_C10FB0F9-23DA-434B-8B9A-0D0941F638AC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = have reviewed -05 and support it so long as the following comments are = considered:

Kent // = contributor



=3D=3D= =3D=3D review =3D=3D=3D=3D

Section 1 is missing a NMDA-compliance statement, = per
 https://tools.ietf.org/html/rfc8407#section-3.5.




Section 2 says:

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

   1.  For the = <running>,<candidate> and <startup> datastores as = the
       content of the = <factory-default> datastore, if it exists;

The (1) sentence doesn't flow from the sentence before. =   Maybe you
mean something like:

   1. =  Network management protocol (e.g., NETCONF, RESTCONF)
        operations may be used to access = the contents  of <factory-default>.



Section 2 says:

   For the server supporting zero = touch bootstrapping mechanisms, the
   factory = default configuration causes the bootstrapping process to
   execute,e.g.,the server might reset = configuration to device's factory
   default = configuration,for the version of operating system software it
   is running.

s/the = server might reset /the server resets /




Section 2 says:
   In addition,the "factory-reset" RPC might also = be used
   to trigger some other restoring and = resetting tasks such as files
   cleanup, = restarting the node or some of the software processes,
   setting some security data/passwords to the = default value, removing
   logs, or removing any = temporary data (from datastore or elsewhere),
  =  etc.

s/the "factory-reset" RPC might = /the "factory-reset" RPC MAY / ???



Section 3 says:

   this document introduces a new datastore = resource named
   'Factory-Default' ...

'Factory-Default' should = not be capitalized.



Section 3 says:
    The contents of the = datastore can be read using NETCONF, 
  =   RESTCONF <get-data> and <get-config> = operations.

Which doesn't make sense. =  Perhaps:

  =   The contents of the datastore can be read using = NETCONF 
     <get-data> and = <get-config> operations, and the RESTCONF
    protocol equivalents.




Section 3 says:

      The operation = <factory-
      reset> can be used to = copy the factory default content to a set of
    =   read-write configuration datastores and then the content of = these
      datastores is propagated = automatically to any other read only
      = datastores, e.g., <intended> and <operational>.

This is confusing.  I think what = you want to say is

      The operation <factory-
      reset> copies the factory default = content to <running> and,
    =   if present, <startup>.




Section 4 = says:

  import ietf-netconf { prefix = nc ; }
  import ietf-datastores { prefix ds; }

These statements are missing "reference" = statements.



Section 4 says:

    description "The read-only = datastore contains the configuration that
  =     will be copied into e.g., the running datastore by = the
      factory-reset operation if = the target is the running
      = datastore.";

which excludes = <startup> and confusingly mentions a "target" when
the RPC itself has no parameters.  Perhaps:

  =   description "The read-only datastore contains the = configuration
    that  will be = copied into <running> and, if present, <startup>.";




Section 5.

Please make the = registrations have single-spaced lines.




Section 6.

The last paragraph doesn't make a point.  Perhaps = conclude with
something like:

  "This module does not itself set = "nacm:default-deny-write" on the 
  =  'factory-reset' RPC, leaving it to applications to configure = the
    access control settings."




Appendix B should have a note to the RFC Stream Editor = to 
remove it when the draft is published.



Kent 




On Nov 1, 2019, at 10:57 AM, Kent Watsen = <kent+ietf@watsen.net> wrote:

This = begins a two-week Working Group Last Call (WGLC) on = draft-ietf-netmod-factory-default-05.  The WGLC ends on Nov 15 (two = days before the NETCONF 106 session).  Please send your comments to = the working group mailing list.

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


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

= --Apple-Mail=_C10FB0F9-23DA-434B-8B9A-0D0941F638AC-- From nobody Fri Nov 1 08:21:03 2019 Return-Path: <0100016e278e252b-9983b033-3b15-464d-898b-807e8576c35b-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 C5E691208A6; Fri, 1 Nov 2019 08:21:00 -0700 (PDT) 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 yXL23yXE28w1; Fri, 1 Nov 2019 08:20:59 -0700 (PDT) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD483120154; Fri, 1 Nov 2019 08:20:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1572621657; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=dnjjO6KpFYBBvu/b7Qu8m6Hde8ONPV0azIyw9zhhQ4M=; b=CpRmqmmnvUx5X0eNbc4RBv96BsOs9OMeD+o1y59kl5LFt5xmdkyFCnjBXo8yj1Z9 letJBDln2OiIqex3lTQhUYdgtxq5RIyo2N3aw3djoZjezsah/q/R3uFn4SbUwbrwi0A l3kpE1Wtmk7xRxLt5U9c/wrDGVQZnGF2kmlVkK8E= From: Kent Watsen Message-ID: <0100016e278e252b-9983b033-3b15-464d-898b-807e8576c35b-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_D3128637-9C78-462B-B4EF-FFB0F7171F06" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 1 Nov 2019 15:20:57 +0000 In-Reply-To: <0100016e27785ce1-6ade1cd2-78fc-40ee-bb4d-f7c4b685e3d3-000000@email.amazonses.com> Cc: draft-ietf-netmod-factory-default@ietf.org To: "netconf@ietf.org" References: <0100016e27785ce1-6ade1cd2-78fc-40ee-bb4d-f7c4b685e3d3-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.11.01-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] WG Last Call: draft-ietf-netmod-factory-default-05 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, 01 Nov 2019 15:21:01 -0000 --Apple-Mail=_D3128637-9C78-462B-B4EF-FFB0F7171F06 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii ABORT - sorry wrong working group! :egg-face:=20 Kent // hiding hat > On Nov 1, 2019, at 10:57 AM, Kent Watsen wrote: >=20 > This begins a two-week Working Group Last Call (WGLC) on = draft-ietf-netmod-factory-default-05. The WGLC ends on Nov 15 (two days = before the NETCONF 106 session). Please send your comments to the = working group mailing list. >=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 >=20 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --Apple-Mail=_D3128637-9C78-462B-B4EF-FFB0F7171F06 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

ABORT  - sorry wrong working group! =   :egg-face: 


Kent  // hiding = hat



On Nov 1, 2019, at 10:57 AM, Kent Watsen <kent+ietf@watsen.net> wrote:

This = begins a two-week Working Group Last Call (WGLC) on = draft-ietf-netmod-factory-default-05.  The WGLC ends on Nov 15 (two = days before the NETCONF 106 session).  Please send your comments to = the working group mailing list.

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


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

= --Apple-Mail=_D3128637-9C78-462B-B4EF-FFB0F7171F06-- From nobody Fri Nov 1 08:37:53 2019 Return-Path: <0100016e279d85c9-ed769315-a2e4-4553-8819-81297009f2af-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 0144F120227 for ; Fri, 1 Nov 2019 08:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 sXWed4vEe8ad for ; Fri, 1 Nov 2019 08:37:50 -0700 (PDT) Received: from a8-64.smtp-out.amazonses.com (a8-64.smtp-out.amazonses.com [54.240.8.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A48EF12016E for ; Fri, 1 Nov 2019 08:37:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1572622665; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=CVeX0CpJmqStOu6ZsP76qRQop3fL8XUTXp9gkOmjdmk=; b=gsORF4wUVFCzjRiXHMX1LtqAg+J0Y9pdDM6giVT3h6BGMn7au3UHguKYICgsfumv 7QJYXLfcd6eQDmxTD/a1gOW8Rw5vXTlZH9Cr7gWvcn7izQM3DXejb+A5+TYwpE6tTiC nPUwtuHVKnSIgYI8zDImHNs6uBwe2HpzjVraIKb8= From: Kent Watsen Message-ID: <0100016e279d85c9-ed769315-a2e4-4553-8819-81297009f2af-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_B84CE54B-0F5B-41B8-B0CB-5615C8F05C35" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 1 Nov 2019 15:37:45 +0000 In-Reply-To: Cc: "Eric Voit (evoit)" , Mahesh Jethanandani , Alexander Clemm , Benoit Claise , "netconf@ietf.org" To: =?utf-8?Q?Bal=C3=A1zs_Lengyel?= References: <4F49DF08-B7FC-4EBD-9D6B-7BC329E50334@gmail.com> <0100016d83c486c9-83aece79-684a-4999-b382-dd9c09f24c62-000000@email.amazonses.com> <0100016db140fe70-7564d937-87d1-450c-9267-2e1235e3fbb4-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.11.01-54.240.8.64 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] WGLC for draft-ietf-netconf-notification-capabilities 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, 01 Nov 2019 15:37:52 -0000 --Apple-Mail=_B84CE54B-0F5B-41B8-B0CB-5615C8F05C35 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Balazs, > Hello, > I added your comments to the upcoming next version of the draft. > Regards Balazs Your update missed a couple nits (see below). Kent // contributor > BALAZS2: OK, Updated with first part, but Rob has asked for an extra = sentence about the dangers of revealing read-only data, I added that = too. > =E2=80=9CAll protocol-accessible data are read-only and cannot be = modified.=20 > The data in this module is not security sensitive. > Access control may be configured, to avoid exposing=20 > the read-only data.=E2=80=9D > =20 > Okay. s/protocol-accessible data/protocol-accessible data nodes/ > BALAZS2: Agreed. This is part of normal file handling, transport. So I = reworded this to: > =E2=80=9CWhen that data is in file format, data should be protected = against=20 > modification or unauthorized access using normal file handling = and=20 > secure and mutually authenticated file transport = mechanisms.=E2=80=9D > =20 > Okay. The end can be shortened, i.e., just "file handling = mechanisms". Kent --Apple-Mail=_B84CE54B-0F5B-41B8-B0CB-5615C8F05C35 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Balazs,

Hello,

I added  your comments to the upcoming next = version of the draft.

Regards = Balazs


Your update missed a couple nits (see = below).

Kent // = contributor




BALAZS2: OK,  Updated with = first part, but Rob has asked for an extra sentence about the dangers of = revealing read-only data, I added that too.

=E2=80=9CAll protocol-accessible data = are read-only and cannot be modified. 

        The data in = this module is not security sensitive.

        Access control may = be configured, to avoid exposing 

        the read-only = data.=E2=80=9D

 

Okay.  s/protocol-accessible = data/protocol-accessible data nodes/

<= div>



BALAZS2: Agreed. This is = part of normal file handling, transport. So I reworded this = to:

=E2=80=9CWhen that data is in file = format, data should be protected against 

        modification = or unauthorized access using normal file handling and 

        secure and = mutually authenticated file transport mechanisms.=E2=80=9D

 

Okay.  The end can be shortened, i.e., just = "file handling = mechanisms".





Kent

= --Apple-Mail=_B84CE54B-0F5B-41B8-B0CB-5615C8F05C35-- From nobody Fri Nov 1 08:43:42 2019 Return-Path: <0100016e27a2d317-26951a3f-fcbf-4d15-939c-ab060aa9a337-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 CC7061201EA; Fri, 1 Nov 2019 08:43:39 -0700 (PDT) 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 Dy36QYEaUBbz; Fri, 1 Nov 2019 08:43:37 -0700 (PDT) Received: from a8-64.smtp-out.amazonses.com (a8-64.smtp-out.amazonses.com [54.240.8.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E5E61200EB; Fri, 1 Nov 2019 08:43:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1572623012; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:Cc:To:Feedback-ID; bh=mDVlHux2Bq/aPmTfdPizSHasWtXdb3+u8fHM6MlFh7M=; b=KN0cPo3qfCdcqMHoDOZ+AEVX3lHBnOJp/onrg8+aDJKpyYS9gmMN4khdPYAbnI0y 6uvsn2zNzu9lLAW2jsh9R+9xKPbhI4qHuDhvf2Nzdd3eGGbzTWUxFDnswsUZrW7Zl4l QvUhYxIzLvvZ72iVEoVK3ovrMBoC53Qr0fSDd97k= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_0586D73E-F263-4F75-9EE5-67209F7DF8C7" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-ID: <0100016e27a2d317-26951a3f-fcbf-4d15-939c-ab060aa9a337-000000@email.amazonses.com> Date: Fri, 1 Nov 2019 15:43:32 +0000 Cc: draft-ietf-netconf-notification-capabilities@ietf.org, "netconf@ietf.org" To: =?utf-8?Q?Bal=C3=A1zs_Lengyel?= , Alexander Clemm , Benoit Claise X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.11.01-54.240.8.64 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] IPR poll on draft-ietf-netconf-notification-capabilities-05 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, 01 Nov 2019 15:43:40 -0000 --Apple-Mail=_0586D73E-F263-4F75-9EE5-67209F7DF8C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii To each author listed on the "To" line. In order to complete the Shepherd writeup, are you aware of any IPR that = applies to draft-ietf-netconf-notification-capabilities-05? Please Reply-All to = *this* email and state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If "yes", has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3669, 5378 and 8179 for more details)? If "yes" again, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think = appropriate. If you are listed as a document author or contributor please answer the = above by responding to this email regardless of whether or not you are aware of = any relevant IPR. This document will not advance to the next stage until a response = has been received from each author and listed contributor. NOTE: THIS APPLIES TO = ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the WG email list or attend WG meetings but are not listed = as an author or contributor, we remind you of your obligations under the IETF IPR = rules which encourages you to notify the IETF if you are aware of IPR of others on = an IETF contribution, or to refrain from participating in any contribution or = discussion related to your undisclosed IPR. For more information, please see the RFCs = listed above and = http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, Kent // as both Shepherd and co-Chair --Apple-Mail=_0586D73E-F263-4F75-9EE5-67209F7DF8C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii To = each author listed on the "To" line.

In = order to complete the Shepherd writeup, are you aware of any IPR that = applies
to = draft-ietf-netconf-notification-capabilities-05?  Please Reply-All = to *this* email
and state either:

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

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

If = "yes" again, please state either:

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

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

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

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

Thank you,
Kent // = as both Shepherd and co-Chair
= --Apple-Mail=_0586D73E-F263-4F75-9EE5-67209F7DF8C7-- From nobody Fri Nov 1 08:46:28 2019 Return-Path: <0100016e27a53a56-4e90c30c-cf53-4df0-9cd7-8a5b5ce9b1ce-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 06B101208E4; Fri, 1 Nov 2019 08:46:14 -0700 (PDT) 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 beiosRk9JnaC; Fri, 1 Nov 2019 08:46:12 -0700 (PDT) Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FF2F12091B; Fri, 1 Nov 2019 08:46:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1572623170; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Message-Id:References:To:Feedback-ID; bh=B2FP5FxKo4ZWuhilYME3NCaiSy814ZTyot04DAZkkUY=; b=donEn7+jKT3omxy07Gk+9tsgzqI3+QUXRvMZAMQ0BTJDZC7WsRL7sBnqr34ocFiD W31XAM0m8O4ePoa1j45Oh6h0OLMYvks+eLjgHxaf3WEHLCZKwo4fGqGZHva4uHEZIdW D9dHOvxUXpnIK4syQzTHDNXUqfjn/yNQmmVmQGC8= Content-Type: multipart/alternative; boundary="Apple-Mail=_3C57301B-50A5-43DB-9970-C085EFDE665A" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Kent Watsen In-Reply-To: <157233302184.6593.3869700028694968875@ietfa.amsl.com> Date: Fri, 1 Nov 2019 15:46:10 +0000 Cc: "netconf@ietf.org" Message-ID: <0100016e27a53a56-4e90c30c-cf53-4df0-9cd7-8a5b5ce9b1ce-000000@email.amazonses.com> References: <157233302184.6593.3869700028694968875@ietfa.amsl.com> To: Ladislav Lhotka , draft-ietf-netconf-notification-capabilities@ietf.org X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.11.01-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Yangdoctors last call review of draft-ietf-netconf-notification-capabilities-05 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, 01 Nov 2019 15:46:20 -0000 --Apple-Mail=_3C57301B-50A5-43DB-9970-C085EFDE665A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii [moving yang-doctors to BCC] Thank you Lada. Authors, please update the draft as needed to address these YANG Doctor = comments. Kent // as Shepherd > On Oct 29, 2019, at 3:10 AM, Ladislav Lhotka via Datatracker = wrote: >=20 > Reviewer: Ladislav Lhotka > Review result: Ready with Nits >=20 > ***** Section 2. Introduction > - Paragraph 3: the use of MAY is inappropriate: publishers > indeed may have limitations, but this should follow from RFC > 8641, and this document should take it as a fact. > ***** Section 3. Notification Capability Model > - The use of RFC 2119 terms is again questionable: I understand > the ietf-notification-capabilities data as an optional aid for > the implementors, but requiring that "The file SHALL be > available in implementation time ..." is way too strict. > ***** Section 3.2. YANG Module > - This is one of the cases where it would be helpful to know > which of the imported modules, such as ietf-netconf-acm, is > also intended to be implemented. This may be addressed in a > future YANG version (see issue #95 in yang-next), until then I > would suggest to include YANG library data describing a > minimum implementation. > ***** Appendix A. Instance data examples > - Example in Fig. 2: the element has an incorrect > XML namespace (of the ietf-datastores module). > - Many enum values are invalid because they contain > leading/trailing whitespace. It would be better to encode the > examples in JSON. >=20 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --Apple-Mail=_3C57301B-50A5-43DB-9970-C085EFDE665A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii [moving yang-doctors to BCC]


Thank you Lada.

Authors, please update the draft as needed to address these = YANG Doctor comments.

Kent // as Shepherd




On Oct 29, 2019, at 3:10 AM, Ladislav Lhotka = via Datatracker <noreply@ietf.org> wrote:

Reviewer: Ladislav Lhotka
Review result: Ready = with Nits

***** Section 2. Introduction
     - Paragraph 3: the use of MAY = is inappropriate: publishers
=        indeed may have limitations, = but this should follow from RFC
=        8641, and this document should = take it as a fact.
***** Section 3. Notification = Capability Model
     - The use = of RFC 2119 terms is again questionable: I understand
=        the = ietf-notification-capabilities data as an optional aid for
=        the implementors, but = requiring that "The file SHALL be
=        available in implementation = time ..." is way too strict.
***** Section 3.2. YANG = Module
     - This is one of the = cases where it would be helpful to know
=        which of the imported modules, = such as ietf-netconf-acm, is
=        also intended to be = implemented. This may be addressed in a
=        future YANG version (see issue = #95 in yang-next), until then I
=        would suggest to include YANG = library data describing a
=        minimum implementation.
***** Appendix A. Instance data examples
=      - Example in Fig. 2: the <datastore> = element has an incorrect
=        XML namespace (of the = ietf-datastores module).
     - = Many enum values are invalid because they contain
=        leading/trailing whitespace. = It would be better to encode the
=        examples in JSON.


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

= --Apple-Mail=_3C57301B-50A5-43DB-9970-C085EFDE665A-- From nobody Sat Nov 2 02:03:09 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7721213CD; Sat, 2 Nov 2019 02:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id px83PV0TIXcn; Sat, 2 Nov 2019 02:03:04 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E456120121; Sat, 2 Nov 2019 02:02:35 -0700 (PDT) Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 7510F907F336D0C58608; Sat, 2 Nov 2019 09:02:32 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sat, 2 Nov 2019 09:02:31 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0439.000; Sat, 2 Nov 2019 17:02:21 +0800 From: Tianran Zhou To: netconf CC: NETCONF Chairs , draft-zhou-netconf-multi-stream-originators Thread-Topic: Adoption request//FW: New Version Notification for draft-zhou-netconf-multi-stream-originators-09.txt Thread-Index: AQHVkVw8S1pGUlGMRkyA6Vvkjqkd0g== Date: Sat, 2 Nov 2019 09:02:21 +0000 Message-ID: References: <157250161429.32624.10183459345808600687.idtracker@ietfa.amsl.com> In-Reply-To: <157250161429.32624.10183459345808600687.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_BBA82579FD347748BEADC4C445EA0F21BF077A82NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [netconf] Adoption request//FW: New Version Notification for draft-zhou-netconf-multi-stream-originators-09.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Nov 2019 09:03:08 -0000 --_000_BBA82579FD347748BEADC4C445EA0F21BF077A82NKGEML515MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgRm9sa3MsDQoNCldlIGp1c3QgdXBkYXRlZCB0aGUgZHJhZnQgdG8gYWRkcmVzcyBzb21lIG1v cmUgY2xhcmlmaWNhdGlvbiBxdWVzdGlvbnMuDQpJIHRoaW5rIGl0oa9zIHJlYWR5IGFzIHRoZSBz dGFydGluZyBwb2ludCBmb3Igd29ya2luZyBncm91cCBkaXNjdXNzaW9uLg0KV2UgcmVxdWVzdCB0 aGUgYWRvcHRpb24gY2FsbC4NCg0KQ2hlZXJzLA0KVGlhbnJhbg0KDQoNCg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KU2VudCBmcm9tIFdlTGluaw0KDQq3orz+yMujuiBpbnRl cm5ldC1kcmFmdHM8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmc+Pg0KytW8/sjLo7ogQW5keSBCaWVybWFuPGFuZHlAeXVtYXdvcmtzLmNvbTxt YWlsdG86YW5keUB5dW1hd29ya3MuY29tPj47RXJpYyBWb2l0PGV2b2l0QGNpc2NvLmNvbTxtYWls dG86ZXZvaXRAY2lzY28uY29tPj47WmhlbmdndWFuZ3lpbmcgKFdhbGtlcik8emhlbmdndWFuZ3lp bmdAaHVhd2VpLmNvbTxtYWlsdG86emhlbmdndWFuZ3lpbmdAaHVhd2VpLmNvbT4+O0FsZXhhbmRl ciBDbGVtbTxsdWR3aWdAY2xlbW0ub3JnPG1haWx0bzpsdWR3aWdAY2xlbW0ub3JnPj47VGlhbnJh biBaaG91PHpob3V0aWFucmFuQGh1YXdlaS5jb208bWFpbHRvOnpob3V0aWFucmFuQGh1YXdlaS5j b20+Pg0K1vfM4qO6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtemhvdS1uZXRj b25mLW11bHRpLXN0cmVhbS1vcmlnaW5hdG9ycy0wOS50eHQNCsqxvOSjuiAyMDE5LTEwLTMxIDE0 OjAwOjIyDQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXpob3UtbmV0Y29uZi1tdWx0 aS1zdHJlYW0tb3JpZ2luYXRvcnMtMDkudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0 dGVkIGJ5IFRpYW5yYW4gWmhvdSBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0K DQpOYW1lOiAgICAgICAgICAgZHJhZnQtemhvdS1uZXRjb25mLW11bHRpLXN0cmVhbS1vcmlnaW5h dG9ycw0KUmV2aXNpb246ICAgICAgIDA5DQpUaXRsZTogICAgICAgICAgU3Vic2NyaXB0aW9uIHRv IE11bHRpcGxlIFN0cmVhbSBPcmlnaW5hdG9ycw0KRG9jdW1lbnQgZGF0ZTogIDIwMTktMTAtMzEN Ckdyb3VwOiAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAgICAgICAgICAy Mg0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC16aG91LW5ldGNvbmYtbXVsdGktc3RyZWFtLW9yaWdpbmF0b3JzLTA5LnR4dA0KU3RhdHVz OiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXpob3UtbmV0 Y29uZi1tdWx0aS1zdHJlYW0tb3JpZ2luYXRvcnMvDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpob3UtbmV0Y29uZi1tdWx0aS1zdHJlYW0tb3JpZ2lu YXRvcnMtMDkNCkh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9odG1sL2RyYWZ0LXpob3UtbmV0Y29uZi1tdWx0aS1zdHJlYW0tb3JpZ2luYXRvcnMNCkRpZmY6 ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtemhvdS1u ZXRjb25mLW11bHRpLXN0cmVhbS1vcmlnaW5hdG9ycy0wOQ0KDQpBYnN0cmFjdDoNCiAgIFRoaXMg ZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBkaXN0cmlidXRlZCBkYXRhIGV4cG9ydCBtZWNoYW5pc20g dGhhdA0KICAgYWxsb3dzIG11bHRpcGxlIGRhdGEgc3RyZWFtcyB0byBiZSBtYW5hZ2VkIHVzaW5n IGEgc2luZ2xlDQogICBzdWJzY3JpcHRpb24uICBTcGVjaWZpY2FsbHksIG11bHRpcGxlIGRhdGEg c3RyZWFtcyBhcmUgcHVzaGVkDQogICBkaXJlY3RseSB0byB0aGUgY29sbGVjdG9yIHdpdGhvdXQg cGFzc2luZyB0aHJvdWdoIGEgYnJva2VyIGZvcg0KICAgaW50ZXJuYWwgY29uc29saWRhdGlvbi4N Cg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0 ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lv biBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBT ZWNyZXRhcmlhdA0KDQo= --_000_BBA82579FD347748BEADC4C445EA0F21BF077A82NKGEML515MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi Folks,

We just updated the draft to address some more clarification questions.
I think it=A1=AFs ready as the starting point for working group discussion.=
We request the adoption call.

Cheers,
Tianran




Sent from WeLink

=B7=A2=BC=FE=C8=CB=A3=BA internet-drafts<internet-drafts@ietf.org>
=CA=D5=BC=FE=C8=CB=A3=BA Andy Bierman<andy@yumaworks.com>;Eric Voit<evoit@cisco.com>;Zhengguangying (Walker)<zhengguangying@huawei.com>;Ale= xander Clemm<ludwig@clemm.org>;Tian= ran Zhou<zhoutianran@huawei.co= m>
=D6=F7=CC=E2=A3=BA New Version Notification for draft-zhou-netc= onf-multi-stream-originators-09.txt
=CA=B1=BC=E4=A3=BA 2019-10-31 14:00:22


A new version of I-D, draft-zhou-netconf-multi-stream-originators-09.txt has been successfully submitted by Tianran Zhou and posted to the
IETF repository.

Name:           draft-zho= u-netconf-multi-stream-originators
Revision:       09
Title:          Subscription t= o Multiple Stream Originators
Document date:  2019-10-31
Group:          Individual Sub= mission
Pages:          22
URL:            https://www.ietf.org/internet-drafts/draft-zhou-netconf-multi-stream-origin= ators-09.txt
Status:         https://datatracker.ietf.org/doc/draft-zhou-netconf-multi-stream-originator= s/
Htmlized:       https://tools.ietf.org/html/draft-zhou-netconf-multi-stream-originators-09<= /a>
Htmlized:       https://datatracker.ietf.org/doc/html/draft-zhou-netconf-multi-stream-origi= nators
Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-zhou-netconf-multi-stream-origina= tors-09

Abstract:
   This document describes the distributed data export mechanism = that
   allows multiple data streams to be managed using a single
   subscription.  Specifically, multiple data streams are pu= shed
   directly to the collector without passing through a broker for=
   internal consolidation.


            &nb= sp;            =             &nb= sp;            =             &nb= sp;            =       


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

The IETF Secretariat

 --_000_BBA82579FD347748BEADC4C445EA0F21BF077A82NKGEML515MBXchi_-- From nobody Sat Nov 2 12:56:15 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A54A12011B; Sat, 2 Nov 2019 12:56:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <157272456900.6064.6153062742143912680@ietfa.amsl.com> Date: Sat, 02 Nov 2019 12:56:09 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-crypto-types-12.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: Sat, 02 Nov 2019 19:56:09 -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 : Common YANG Data Types for Cryptography Authors : Kent Watsen Wang Haiguang Filename : draft-ietf-netconf-crypto-types-12.txt Pages : 53 Date : 2019-11-02 Abstract: This document defines four YANG modules for types useful to cryptographic applications. The modules defined include: o ietf-crypto-types o iana-symmetric-algs o iana-asymmetric-algs o iana-hash-algs The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-crypto-types/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-12 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-crypto-types-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-crypto-types-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Nov 2 12:58:34 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 979A612021C; Sat, 2 Nov 2019 12:58:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <157272470754.6048.14184983758683309295@ietfa.amsl.com> Date: Sat, 02 Nov 2019 12:58:27 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-trust-anchors-07.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: Sat, 02 Nov 2019 19:58:28 -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 : A YANG Data Model for a Truststore Authors : Kent Watsen Henk Birkholz Filename : draft-ietf-netconf-trust-anchors-07.txt Pages : 13 Date : 2019-11-02 Abstract: This document defines a YANG 1.1 data model for configuring global sets of X.509 certificates, SSH host-keys, raw public keys, and PSKs (pairwise-symmetric or pre-shared keys) that can be referenced by other data models for trust. While the SSH host-keys are uniquely for the SSH protocol, certificates, raw public keys, and PSKs may have multiple uses, including authenticating protocol peers and verifying signatures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-trust-anchors/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-07 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-trust-anchors-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-trust-anchors-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Nov 2 13:00:08 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9306B120043; Sat, 2 Nov 2019 12:59:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <157272479952.5955.17844876321976801349@ietfa.amsl.com> Date: Sat, 02 Nov 2019 12:59:59 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-keystore-14.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: Sat, 02 Nov 2019 20:00:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : A YANG Data Model for a Keystore Author : Kent Watsen Filename : draft-ietf-netconf-keystore-14.txt Pages : 38 Date : 2019-11-02 Abstract: This document defines a YANG 1.1 module called "ietf-keystore" that enables centralized configuration of both symmetric and asymmetric keys. The secret value for both key types may be encrypted. Asymmetric keys may be associated with certificates. Notifications are sent when certificates are about to expire. Editorial Note (To be removed by RFC Editor) This draft contains many placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: o "AAAA" --> the assigned RFC value for [I-D.ietf-netconf-crypto-types]. o "XXXX" --> the assigned RFC value for this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: o "2019-11-02" --> the publication date of this draft The following Appendix section is to be removed prior to publication: o Appendix A. Change Log The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-keystore/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-keystore-14 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-keystore-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-keystore-14 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 Sat Nov 2 13:20:41 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D960120043; Sat, 2 Nov 2019 13:20:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <157272604057.6039.9441223454821619129@ietfa.amsl.com> Date: Sat, 02 Nov 2019 13:20:40 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-ssh-client-server-16.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: Sat, 02 Nov 2019 20:20:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : YANG Groupings for SSH Clients and SSH Servers Authors : Kent Watsen Gary Wu Liang Xia Filename : draft-ietf-netconf-ssh-client-server-16.txt Pages : 48 Date : 2019-11-02 Abstract: This document defines three YANG modules: the first defines groupings for a generic SSH client, the second defines groupings for a generic SSH server, and the third defines common identities and groupings used by both the client and the server. It is intended that these groupings will be used by applications using the SSH protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-ssh-client-server/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server-16 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-ssh-client-server-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-ssh-client-server-16 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 Sat Nov 2 13:27:36 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF1C12002F; Sat, 2 Nov 2019 13:27:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <157272645160.5938.5633918238393142344@ietfa.amsl.com> Date: Sat, 02 Nov 2019 13:27:31 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-tls-client-server-16.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: Sat, 02 Nov 2019 20:27:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : YANG Groupings for TLS Clients and TLS Servers Authors : Kent Watsen Gary Wu Liang Xia Filename : draft-ietf-netconf-tls-client-server-16.txt Pages : 47 Date : 2019-11-02 Abstract: This document defines three YANG modules: the first defines groupings for a generic TLS client, the second defines groupings for a generic TLS server, and the third defines common identities and groupings used by both the client and the server. It is intended that these groupings will be used by applications using the TLS protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-tls-client-server/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-16 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-tls-client-server-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-tls-client-server-16 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 Sat Nov 2 13:32:37 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E3712080E; Sat, 2 Nov 2019 13:32:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <157272675092.5955.15547209007510551897@ietfa.amsl.com> Date: Sat, 02 Nov 2019 13:32:30 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-netconf-client-server-16.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: Sat, 02 Nov 2019 20:32:31 -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 : NETCONF Client and Server Models Author : Kent Watsen Filename : draft-ietf-netconf-netconf-client-server-16.txt Pages : 82 Date : 2019-11-02 Abstract: This document defines two YANG modules, one module to configure a NETCONF client and the other module to configure a NETCONF server. Both modules support both the SSH and TLS transport protocols, and support both standard NETCONF and NETCONF Call Home connections. Editorial Note (To be removed by RFC Editor) This draft contains many placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. This document contains references to other drafts in progress, both in the Normative References section, as well as in body text throughout. Please update the following references to reflect their final RFC assignments: o I-D.ietf-netconf-keystore o I-D.ietf-netconf-tcp-client-server o I-D.ietf-netconf-ssh-client-server o I-D.ietf-netconf-tls-client-server Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: o "XXXX" --> the assigned RFC value for this draft o "AAAA" --> the assigned RFC value for I-D.ietf-netconf-tcp-client- server o "YYYY" --> the assigned RFC value for I-D.ietf-netconf-ssh-client- server o "ZZZZ" --> the assigned RFC value for I-D.ietf-netconf-tls-client- server Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: o "2019-11-02" --> the publication date of this draft The following Appendix section is to be removed prior to publication: o Appendix B. Change Log The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-netconf-client-server/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-16 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-netconf-client-server-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-netconf-client-server-16 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 Sat Nov 2 13:35:44 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 300C1120043; Sat, 2 Nov 2019 13:35:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <157272693813.6019.981772461094813451@ietfa.amsl.com> Date: Sat, 02 Nov 2019 13:35:38 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-restconf-client-server-16.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: Sat, 02 Nov 2019 20:35:38 -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 : RESTCONF Client and Server Models Author : Kent Watsen Filename : draft-ietf-netconf-restconf-client-server-16.txt Pages : 67 Date : 2019-11-02 Abstract: This document defines two YANG modules, one module to configure a RESTCONF client and the other module to configure a RESTCONF server. Both modules support the TLS transport protocol with both standard RESTCONF and RESTCONF Call Home connections. Editorial Note (To be removed by RFC Editor) This draft contains many placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. This document contains references to other drafts in progress, both in the Normative References section, as well as in body text throughout. Please update the following references to reflect their final RFC assignments: o I-D.ietf-netconf-keystore o I-D.ietf-netconf-tcp-client-server o I-D.ietf-netconf-tls-client-server o I-D.ietf-netconf-http-client-server Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: o "XXXX" --> the assigned RFC value for this draft o "AAAA" --> the assigned RFC value for I-D.ietf-netconf-tcp-client- server o "BBBB" --> the assigned RFC value for I-D.ietf-netconf-tls-client- server o "CCCC" --> the assigned RFC value for I-D.ietf-netconf-http- client-server Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: o "2019-11-02" --> the publication date of this draft The following Appendix section is to be removed prior to publication: o Appendix B. Change Log The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-client-server/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server-16 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-restconf-client-server-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-restconf-client-server-16 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 Sat Nov 2 13:55:26 2019 Return-Path: <0100016e2de6a66d-ff5aea75-edfc-4d98-8c0e-95674c411430-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 D6ECE12002F for ; Sat, 2 Nov 2019 13:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ZbtC6WB_r20r for ; Sat, 2 Nov 2019 13:55:22 -0700 (PDT) Received: from a8-64.smtp-out.amazonses.com (a8-64.smtp-out.amazonses.com [54.240.8.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F30D12001E for ; Sat, 2 Nov 2019 13:55:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1572728121; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=j9uNOcCakKFFzl6+Nu6USujMmk1DZAeAQQSh52BU9rc=; b=EhdsQ9E1LphegI8EMoYF6z1Km3aFmpEGnS1UUbFjVvn4++100luu76xDKJ3qDeEg Ly6fzMZGXuMKf8d0Wa7Cs5+8qsY8YeYuLYdxoAjEm+NqgUttA6Pg9xBYgSS7vGj+vaR hCh3wRtbXghWE4jPZ/yHsE+vGjS0F3M2tkDUc1Vg= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_625C5E71-45EE-4CEA-A9D1-E576E844CECA" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-ID: <0100016e2de6a66d-ff5aea75-edfc-4d98-8c0e-95674c411430-000000@email.amazonses.com> Date: Sat, 2 Nov 2019 20:55:21 +0000 To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.11.02-54.240.8.64 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] today's updates to the client-server suite of drafts 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, 02 Nov 2019 20:55:25 -0000 --Apple-Mail=_625C5E71-45EE-4CEA-A9D1-E576E844CECA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The biggest change is in the crypto-types draft, as it continues to try = to grapple with the "algorithm" problem. =20 I don't think there is consensus for having distinct "iana-" modules for = each type of algorithm yet. For one, if it were a module to be be = supported by IANA, one might expect more of a template but, as the = algorithm-lists pull from numerous RFCs, how to make a template wasn't = clear to me and, besides, having a distinct module for each type of = algorithm became a convenient way to define a "config false" list for = the algorithms supported by the server. In any case, I offer this update to the WG for discussion. Below are = the change logs for each draft. Kent // contributor =3D=3D=3D=3D=3D change logs =3D=3D=3D=3D=3D crypto-types: o Removed all non-essential (to NC/RC) algorithm types. o Moved remaining algorithm types each into its own module. o Added a 'config false' "algorithms-supported" list to each of the algorithm-type modules. trust-anchors (truststore): o Added Henk Birkholz as a co-author (thanks Henk!) o Added PSKs and raw public keys to Truststore. keystore: o Updated YANG module and examples to incorporate the new iana-*-algorithm modules in the crypto-types draft. tcp-client-server o No update. ssh-client-server o Removed unnecessary if-feature statements in the -client and -server modules. o Cleaned up some description statements in the -client and -server modules. o Fixed a canonical ordering issue in ietf-ssh-common detected by new pyang. tls-client-server o Removed unnecessary if-feature statements in the -client and -server modules. o Cleaned up some description statements in the -client and -server modules. o Fixed a canonical ordering issue in ietf-ssh-common detected by new pyang. http-client-server o Removed "protocol-version" leaf in http-client-grouping. netconf-client-server o Added refinement to make "cert-to-name/fingerprint" be mandatory false. o Commented out refinement to "tls-server-grouping/client- authentication" until a better "must" expression is defined. restconf-client-server o Added refinement to make "cert-to-name/fingerprint" be mandatory false. o Commented out refinement to "tls-server-grouping/client- authentication" until a better "must" expression is defined. o Updated restconf-client example to reflect that http-client- grouping no longer has a "protocol-version" leaf. --Apple-Mail=_625C5E71-45EE-4CEA-A9D1-E576E844CECA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

The = biggest change is in the crypto-types draft, as it continues to try to = grapple with the "algorithm" problem.  

I don't = think there is consensus for having distinct "iana-" modules for each = type of algorithm yet.  For one, if it were a module to be be = supported by IANA, one might expect more of a template but, as the = algorithm-lists pull from numerous RFCs, how to make a = template wasn't clear to me and, besides, having a distinct module for = each type of algorithm became a convenient way to define a "config = false" list for the algorithms supported by the server.

In any = case, I offer this update to the WG for discussion.  Below = are the change logs for each draft.

Kent // contributor


=3D=3D=3D=3D=3D change logs =3D=3D=3D=3D=3D

crypto-types:

   o  Removed all = non-essential (to NC/RC) algorithm types.

   o  Moved remaining algorithm types each = into its own module.

   o  Added a 'config false' = "algorithms-supported" list to each of the
      algorithm-type modules.



trust-anchors (truststore):

   o  Added Henk Birkholz as a co-author = (thanks Henk!)

  =  o  Added PSKs and raw public keys to = Truststore.



keystore:

   o  Updated YANG module and examples to = incorporate the new
      iana-*-algorithm = modules in the crypto-types draft.



tcp-client-server

  =  o  No update.




ssh-client-server

   o  Removed unnecessary if-feature = statements in the -client and
  =     -server modules.

   o  Cleaned up some description statements = in the -client and -server
  =     modules.

   o  Fixed a canonical ordering issue in = ietf-ssh-common detected by
  =     new pyang.



tls-client-server

   o  Removed = unnecessary if-feature statements in the -client and
      -server modules.

   o  Cleaned up some description = statements in the -client and -server
  =     modules.

   o  Fixed a canonical ordering = issue in ietf-ssh-common detected by
  =     new pyang.



http-client-server

   o  Removed "protocol-version" leaf in = http-client-grouping.



netconf-client-server

   o  Added refinement to = make "cert-to-name/fingerprint" be mandatory
      false.

   o  Commented out refinement to = "tls-server-grouping/client-
  =     authentication" until a better "must" expression is = defined.



restconf-client-server

   o  Added refinement to = make "cert-to-name/fingerprint" be mandatory
      false.

   o  Commented out refinement to = "tls-server-grouping/client-
  =     authentication" until a better "must" expression is = defined.

   o  Updated restconf-client example to = reflect that http-client-
  =     grouping no longer has a "protocol-version" = leaf.


= --Apple-Mail=_625C5E71-45EE-4CEA-A9D1-E576E844CECA-- From nobody Sat Nov 2 15:22:40 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92FB712006F; Sat, 2 Nov 2019 15:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9DdIYrXPHu0; Sat, 2 Nov 2019 15:22:38 -0700 (PDT) Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (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 6C156120013; Sat, 2 Nov 2019 15:22:38 -0700 (PDT) Received: by mail-pl1-x62e.google.com with SMTP id x6so5907725pln.2; Sat, 02 Nov 2019 15:22:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vhk7M12j+kkwwQZvgcWxOm/pvIOI5AQnd5U1bBhsE7M=; b=DOnGlWp+k6I7UWIIhBmfnlOZyzo+8i8QkEuO4fO2qy3dM+vVjLKhiga6gKXwi7UdQ7 CbdFGYjSzSqCOcV57EuAjAjWABSZ26MCI8GxOJFPNCuG0hT27m1s7tlI7BN1NutE+djj p6yLgBMiC76gZ8SJCSv7KAjjH4SbeKBXAMHhDvxZukcyIk4KzxGR39qbXJryxt2BYOqS APD4kKyWHyNLDpVRZivKKZC6fnwx2r6/Zu0l9Utr4yuSS4XKQ33+5a+qBOb5LAtdqLyn Ch6zfz388ZViM4cKzCkEDLllaml+/PRuAmkgLzBzmHu7mbCeEEzrhXilUv6n7sofcDjc x36g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vhk7M12j+kkwwQZvgcWxOm/pvIOI5AQnd5U1bBhsE7M=; b=QC+hpTSicJcaLA7U0mGaVgcCp8pbPx982bKDI/pSRODeCqJwcm4BxC4A2Md/mspnTo cZBmezYS7ut5zvDDj+jcY35Wxo3jAYmLm7J0abCoOH+14oho98AY7ld9Ph85VV839mOS J9IchBIlZDX98W4W54VokPiilPzeRhkmSw+4iK84gSjyLPlaEFu8r/GwNht4by5G8Dqp v+EZLkMFA6bFzEDp82ICd/1ACs03h8AOVjH/XWErNon2dW5sjtIXoo7kweBKEgS8caUR 3ttNlF5z15MpEYhpT2RkIdivLSz8CdNsGdOZJaudk/C95S6PwkrEnmfngbKdEzsizt18 U2Iw== X-Gm-Message-State: APjAAAWUXPb57gXajVS1LoqPLJp0e+8eXeZ0ZumDpjMDT+L6DX409NvW X3YNAZnvi3MaWSdKm+YpgScM9oxy1EU= X-Google-Smtp-Source: APXvYqyl+hmmiAPUwSYsEtRzeoPW+bH1WgA9i7K32BjJkqy0SYm9sJqI5RUfjSa5CuyEpTFYzgG40Q== X-Received: by 2002:a17:902:bf06:: with SMTP id bi6mr14104609plb.327.1572733357700; Sat, 02 Nov 2019 15:22:37 -0700 (PDT) Received: from ?IPv6:2601:647:5600:5020:2c55:7b09:61f1:d215? ([2601:647:5600:5020:2c55:7b09:61f1:d215]) by smtp.gmail.com with ESMTPSA id bx20sm8909629pjb.12.2019.11.02.15.22.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 Nov 2019 15:22:36 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Mahesh Jethanandani In-Reply-To: <704A1489-3BC0-4EFF-A5B0-7D664EA05970@gmail.com> Date: Sat, 2 Nov 2019 15:22:35 -0700 Cc: httpbis-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <150E2E2A-26D9-4B61-8639-B9025E92AD70@gmail.com> References: <704A1489-3BC0-4EFF-A5B0-7D664EA05970@gmail.com> To: Netconf X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04 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, 02 Nov 2019 22:22:40 -0000 Just a reminder. This adoption call is still open. > On Oct 21, 2019, at 3:52 PM, Mahesh Jethanandani = wrote: >=20 > Hi WG, >=20 > The author has posted a -04 version of the draft, and believes that it = ready for WG adoption. >=20 > This starts a 2 week poll ending on November 4, to decide whether this = document should be made a WG document or not. Please reply to this email = whether or not you support adoption of this draft by the WG. Indications = that the draft has been read will be also be appreciated. >=20 > Thanks. >=20 > Mahesh Jethanandani > mjethanandani@gmail.com >=20 >=20 >=20 Mahesh Jethanandani mjethanandani@gmail.com From nobody Mon Nov 4 00:12:02 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F70120227 for ; Mon, 4 Nov 2019 00:11:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 MoSh-YaUI7hy for ; Mon, 4 Nov 2019 00:11:51 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C4DE412006D for ; Mon, 4 Nov 2019 00:11:50 -0800 (PST) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 174F91AE018B; Mon, 4 Nov 2019 09:11:49 +0100 (CET) Date: Mon, 04 Nov 2019 09:11:19 +0100 (CET) Message-Id: <20191104.091119.1760037446043812190.mbj@tail-f.com> To: kent+ietf@watsen.net Cc: netconf@ietf.org From: Martin Bjorklund In-Reply-To: <0100016e1d98c767-57716d36-7f50-41d9-9641-360626517728-000000@email.amazonses.com> References: <0100016e1a0d419b-b221bfcc-d3cd-4386-a016-474e2303fba0-000000@email.amazonses.com> <20191030.132839.500650494712032488.mbj@tail-f.com> <0100016e1d98c767-57716d36-7f50-41d9-9641-360626517728-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] x509c2n:cert-to-name problem 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, 04 Nov 2019 08:12:01 -0000 Hi, Kent Watsen wrote: > [moving this fork in the 'netmod' discussion to the 'netconf' list] > > > >> The "tls-server-parameters" container defines the certificates used to > >> authenticate the client's cert. In many deployments, regardless how > >> the client cert is authenticated, the "client-identification" section only > >> needs to explain how to extract the "name" from the cert, a fingerprint > >> isn't needed to identify either the client's end-entity or some > >> intermediate cert. > > > > Ok. To me this sounds like you need a more complex^wsophisticated > > client identification mechansim than what a plain cert-to-name gives > > you. I don't think there is anything wrong with the current > > cert-to-name grouping. So let's continue this discussion in the > > netconf ML, where this model is being developed. > > In an attempt to resolve this issue, I modified both ietf-netconf-server > and ietf-restconf-server as follows: > > OLD: > uses x509c2n:cert-to-name; > > NEW: > uses x509c2n:cert-to-name { > refine "cert-to-name/fingerprint" { > mandatory false; > description > "A 'fingerprint' value does not need to be specified > when the 'cert-to-name' mapping is independent of > fingerprint matching. A 'cert-to-name' having no > fingerprint value will match any client certificate > and therefore should only be present at the end of > the user-ordered 'cert-to-name' list."; > } > } Did you see my email "client identification in ietf-netconf-server"? I don't think this refinement is the correct solution. /martin From nobody Mon Nov 4 00:35:08 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D77E21208C0; Mon, 4 Nov 2019 00:35:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 8l0Y85JlzsVO; Mon, 4 Nov 2019 00:34: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 EBACF1208E6; Mon, 4 Nov 2019 00:34:58 -0800 (PST) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 601221AE018B; Mon, 4 Nov 2019 09:34:57 +0100 (CET) Date: Mon, 04 Nov 2019 09:34:27 +0100 (CET) Message-Id: <20191104.093427.842126049822749848.mbj@tail-f.com> To: mjethanandani@gmail.com Cc: netconf@ietf.org, httpbis-chairs@ietf.org From: Martin Bjorklund In-Reply-To: <704A1489-3BC0-4EFF-A5B0-7D664EA05970@gmail.com> References: <704A1489-3BC0-4EFF-A5B0-7D664EA05970@gmail.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] Adoption call for draft-kwatsen-netconf-http-client-server-04 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, 04 Nov 2019 08:35:05 -0000 Hi, In principle I wouldn't mind a document like this. But if the HTTP experts have concerns, and based on the contents of the model (*) perhaps it is better to add the necessary nodes directly to the higher-level modules (e.g, ietf-restconf-server for the server nodes). (*) The grouping for the server doesn't really add much, imo. Basically it has a seemingly arbitrary selection of headers to control (in fact just 'Server'), which protocol version to support, and a per-server list of "basic" username/passwords (which is probably not a common way to configure authentication). The client grouping also doens't add much, with the possible exception of the proxy settings; perhaps these nodes could be specified in a generic grouping. /martin Mahesh Jethanandani wrote: > Hi WG, > > The author has posted a -04 version of the draft, and believes that it > ready for WG adoption. > > This starts a 2 week poll ending on November 4, to decide whether this > document should be made a WG document or not. Please reply to this > email whether or not you support adoption of this draft by the > WG. Indications that the draft has been read will be also be > appreciated. > > Thanks. > > Mahesh Jethanandani > mjethanandani@gmail.com > > > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Mon Nov 4 02:01:39 2019 Return-Path: <0100016e35dcd47e-5729ff45-cb28-4a7a-a5a4-2e43a0ea41a5-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 BCE08120100 for ; Mon, 4 Nov 2019 02:01: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 Nfuan-gZvThm for ; Mon, 4 Nov 2019 02:01:36 -0800 (PST) Received: from a8-64.smtp-out.amazonses.com (a8-64.smtp-out.amazonses.com [54.240.8.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98E5E1200FF for ; Mon, 4 Nov 2019 02:01:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1572861695; h=Content-Type:Content-Transfer-Encoding:From:Mime-Version:Subject:Date:Message-Id:References:Cc:In-Reply-To:To:Feedback-ID; bh=jYoBihAIUlts1Z2WcCGrc3TdA56IY9cya8ZeHOvJn40=; b=VAsyQ7QOn7eagjM9S1N4LHcTQZYlfjXDgdlZi819TT9Jp3AKYci2Q2oBJF557PXO R6BGNgwKIhgnpwK4yKJxXvu1Obhlhm0crSrhEJaa4YcbZrqPZCXc65xytWSbuXW1b9G /pu4JzcwTMrRFaPD1SjXggehW1jDSaTzzASvbkUE= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Kent Watsen Mime-Version: 1.0 (1.0) Date: Mon, 4 Nov 2019 10:01:35 +0000 Message-ID: <0100016e35dcd47e-5729ff45-cb28-4a7a-a5a4-2e43a0ea41a5-000000@email.amazonses.com> References: <20191104.091119.1760037446043812190.mbj@tail-f.com> Cc: netconf@ietf.org In-Reply-To: <20191104.091119.1760037446043812190.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: iPhone Mail (17A878) X-SES-Outgoing: 2019.11.04-54.240.8.64 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] x509c2n:cert-to-name problem 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, 04 Nov 2019 10:01:38 -0000 > Did you see my email "client identification in ietf-netconf-server"? No, could you send again? I see it in the archive, so send to just me? K. > I don't think this refinement is the correct solution. > > > /martin From nobody Mon Nov 4 03:39:57 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7891200D7; Mon, 4 Nov 2019 03:39:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_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 9vJtPAGBJaf5; Mon, 4 Nov 2019 03:39:54 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 67FD21200B3; Mon, 4 Nov 2019 03:39:54 -0800 (PST) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 9F86D1AE018B; Mon, 4 Nov 2019 12:39:52 +0100 (CET) Date: Mon, 04 Nov 2019 12:39:23 +0100 (CET) Message-Id: <20191104.123923.1142091174247472340.mbj@tail-f.com> To: netconf@ietf.org, draft-ietf-netmod-factory-default@ietf.org From: Martin Bjorklund In-Reply-To: <0100016e27785ce1-6ade1cd2-78fc-40ee-bb4d-f7c4b685e3d3-000000@email.amazonses.com> References: <0100016e27785ce1-6ade1cd2-78fc-40ee-bb4d-f7c4b685e3d3-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] WG Last Call: draft-ietf-netmod-factory-default-05 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, 04 Nov 2019 11:39:56 -0000 Hi, I have reviewd version 06 of this draft, and have some comments: o Abstract and Introduction These both contain: Optionally a new "factory-default" read-only datastore is defined, Perhaps change to: A new optional read-only datastore "factory-default" is defined, o Abstract and Introduction These both contain: The reset operation may be used e.g. during initial zero-touch configuration and in the Introduction there's a reference to RFC 8572. But what does this actually mean? o Introduction OLD: NETCONF defines the operation that allows resetting the NEW: NETCONF defines the operation that allows resetting the o Section 2 This section says: Factory-default content MAY be specified by one of the following means in descending order of precedence 1. datastore, if it exists; 2. by vendors using a file in YANG Instance Data [I-D.ietf-netmod-yang-instance-file-format] format or some other format in vendor's website or other places where similar off-line documents are kept; 3. In some implementation specific manner; I don't think this defines any useful behaviour, and suggest this text is removed. o Section 2 This section says: For the server supporting zero touch bootstrapping mechanisms, the factory default configuration causes the bootstrapping process to execute,e.g.,the server resets configuration to device's factory default configuration,for the version of operating system software it is running. It is not clear to me what this is supposed to mean. I think it means "if the factory default configuration specifies that ztp is to be run, then ztp will be run after a factory reset". But this is kind of obvious... So I suggest that this sentence is removed. o Section 4 The YANG module contains the boilerplate text from RFC 8174, but the module doesn't use 8174-language, so I suggest the boilerplate text is removed. o Section 4 Suggest: OLD: feature factory-default-as-datastore { description "Indicates that the factory default configuration is also available as a separate datastore"; } NEW: feature factory-default-as-datastore { description "Indicates that the factory default configuration is available as a datastore."; } o Section 4 The module augments a new leaf 'factory-default' into . I suggest that we remove this. Other datastores like intended are not available through get-config, and I see no reason why factory-default should be treated differently. o Section 4 I recommend that you run the YANG module through pyang -f yang --keep-comments --yang-line-length 69 in order to fix some formatting and indentation issues. /martin From nobody Mon Nov 4 05:51:14 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF9E1200FE; Mon, 4 Nov 2019 05:51:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t83VavDcsyNY; Mon, 4 Nov 2019 05:51:10 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D8501200FA; Mon, 4 Nov 2019 05:51:10 -0800 (PST) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 9749FB4C8301B2ADE81A; Mon, 4 Nov 2019 13:51:08 +0000 (GMT) Received: from lhreml710-chm.china.huawei.com (10.201.108.61) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 4 Nov 2019 13:51:08 +0000 Received: from lhreml710-chm.china.huawei.com (10.201.108.61) by lhreml710-chm.china.huawei.com (10.201.108.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Mon, 4 Nov 2019 13:51:08 +0000 Received: from DGGEML402-HUB.china.huawei.com (10.3.17.38) by lhreml710-chm.china.huawei.com (10.201.108.61) 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, 4 Nov 2019 13:51:07 +0000 Received: from DGGEML531-MBS.china.huawei.com ([169.254.5.209]) by DGGEML402-HUB.china.huawei.com ([fe80::fca6:7568:4ee3:c776%31]) with mapi id 14.03.0439.000; Mon, 4 Nov 2019 21:51:05 +0800 From: Qin Wu To: Martin Bjorklund , "netconf@ietf.org" , "draft-ietf-netmod-factory-default@ietf.org" Thread-Topic: [netconf] WG Last Call: draft-ietf-netmod-factory-default-05 Thread-Index: AdWTEkzEpd/+HgYhTzqKI8E8oLCxAg== Date: Mon, 4 Nov 2019 13:51:04 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.31.203] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] WG Last Call: draft-ietf-netmod-factory-default-05 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, 04 Nov 2019 13:51:12 -0000 VGhhbmtzIE1hcnRpbiwgc2VlIHJlcGx5IGlubGluZSBiZWxvdy4NCg0KLS0tLS3Tyrz+1K28/i0t LS0tDQq3orz+yMs6IE1hcnRpbiBCam9ya2x1bmQgW21haWx0bzptYmpAdGFpbC1mLmNvbV0gDQq3 osvNyrG85DogMjAxOcTqMTHUwjTI1SAxOTozOQ0KytW8/sjLOiBuZXRjb25mQGlldGYub3JnOyBk cmFmdC1pZXRmLW5ldG1vZC1mYWN0b3J5LWRlZmF1bHRAaWV0Zi5vcmcNCtb3zOI6IFJlOiBbbmV0 Y29uZl0gV0cgTGFzdCBDYWxsOiBkcmFmdC1pZXRmLW5ldG1vZC1mYWN0b3J5LWRlZmF1bHQtMDUN Cg0KSGksDQoNCkkgaGF2ZSByZXZpZXdkIHZlcnNpb24gMDYgb2YgdGhpcyBkcmFmdCwgYW5kIGhh dmUgc29tZSBjb21tZW50czoNCg0KDQpvICBBYnN0cmFjdCBhbmQgSW50cm9kdWN0aW9uDQoNCiAg VGhlc2UgYm90aCBjb250YWluOg0KDQogICBPcHRpb25hbGx5IGEgbmV3ICJmYWN0b3J5LWRlZmF1 bHQiIHJlYWQtb25seSBkYXRhc3RvcmUgaXMgZGVmaW5lZCwNCg0KICBQZXJoYXBzIGNoYW5nZSB0 bzoNCg0KICAgQSBuZXcgb3B0aW9uYWwgcmVhZC1vbmx5IGRhdGFzdG9yZSAiZmFjdG9yeS1kZWZh dWx0IiBpcyBkZWZpbmVkLA0KDQpbUWluXTpPa2F5Lg0KDQpvICBBYnN0cmFjdCBhbmQgSW50cm9k dWN0aW9uDQoNCiAgVGhlc2UgYm90aCBjb250YWluOg0KDQogICAgVGhlIHJlc2V0IG9wZXJhdGlv biBtYXkgYmUgdXNlZCBlLmcuIGR1cmluZyBpbml0aWFsDQogICAgemVyby10b3VjaCBjb25maWd1 cmF0aW9uIA0KDQogIGFuZCBpbiB0aGUgSW50cm9kdWN0aW9uIHRoZXJlJ3MgYSByZWZlcmVuY2Ug dG8gUkZDIDg1NzIuDQoNCiAgQnV0IHdoYXQgZG9lcyB0aGlzIGFjdHVhbGx5IG1lYW4/DQpbUWlu XTogSXQgbWVhbnMgdGhlIGtleSB3b3JkIHplcm8tdG91Y2ggY29tZXMgZnJvbSBSRkM4NTcyLg0K DQpvICBJbnRyb2R1Y3Rpb24NCg0KICBPTEQ6DQoNCiAgIE5FVENPTkYgZGVmaW5lcyB0aGUgPGRl bGV0ZT4gb3BlcmF0aW9uIHRoYXQgYWxsb3dzIHJlc2V0dGluZyB0aGUNCg0KICBORVc6DQoNCiAg IE5FVENPTkYgZGVmaW5lcyB0aGUgPGRlbGV0ZS1jb25maWc+IG9wZXJhdGlvbiB0aGF0IGFsbG93 cyByZXNldHRpbmcgdGhlDQoNCltRaW5dOkdvb2QgY2F0Y2gsIHRoYW5rcy4NCm8gIFNlY3Rpb24g Mg0KDQogIFRoaXMgc2VjdGlvbiBzYXlzOg0KDQogICAgRmFjdG9yeS1kZWZhdWx0IGNvbnRlbnQg TUFZIGJlIHNwZWNpZmllZCBieSBvbmUgb2YgdGhlIGZvbGxvd2luZw0KICAgIG1lYW5zIGluIGRl c2NlbmRpbmcgb3JkZXIgb2YgcHJlY2VkZW5jZQ0KDQogICAgMS4gIDxmYWN0b3J5LWRlZmF1bHQ+ IGRhdGFzdG9yZSwgaWYgaXQgZXhpc3RzOw0KDQogICAgMi4gIGJ5IHZlbmRvcnMgdXNpbmcgYSBm aWxlIGluIFlBTkcgSW5zdGFuY2UgRGF0YQ0KICAgICAgICBbSS1ELmlldGYtbmV0bW9kLXlhbmct aW5zdGFuY2UtZmlsZS1mb3JtYXRdIGZvcm1hdCBvciBzb21lIG90aGVyDQogICAgICAgIGZvcm1h dCBpbiB2ZW5kb3IncyB3ZWJzaXRlIG9yIG90aGVyIHBsYWNlcyB3aGVyZSBzaW1pbGFyIG9mZi1s aW5lDQogICAgICAgIGRvY3VtZW50cyBhcmUga2VwdDsNCg0KICAgIDMuICBJbiBzb21lIGltcGxl bWVudGF0aW9uIHNwZWNpZmljIG1hbm5lcjsNCg0KDQogIEkgZG9uJ3QgdGhpbmsgdGhpcyBkZWZp bmVzIGFueSB1c2VmdWwgYmVoYXZpb3VyLCBhbmQgc3VnZ2VzdCB0aGlzDQogIHRleHQgaXMgcmVt b3ZlZC4NCg0KW1Fpbl06IE9rYXksIHNpbmNlIGJvdGggeW91IGFuZCBBbmR5IHN1Z2dlc3QgdG8g ZGVsZXRlLCB0aGUgdGV4dCBjYW4gZ28gYXdheSBub3cuDQpvICBTZWN0aW9uIDINCg0KICBUaGlz IHNlY3Rpb24gc2F5czoNCg0KICAgIEZvciB0aGUgc2VydmVyIHN1cHBvcnRpbmcgemVybyB0b3Vj aCBib290c3RyYXBwaW5nIG1lY2hhbmlzbXMsIHRoZQ0KICAgIGZhY3RvcnkgZGVmYXVsdCBjb25m aWd1cmF0aW9uIGNhdXNlcyB0aGUgYm9vdHN0cmFwcGluZyBwcm9jZXNzIHRvDQogICAgZXhlY3V0 ZSxlLmcuLHRoZSBzZXJ2ZXIgcmVzZXRzIGNvbmZpZ3VyYXRpb24gdG8gZGV2aWNlJ3MgZmFjdG9y eQ0KICAgIGRlZmF1bHQgY29uZmlndXJhdGlvbixmb3IgdGhlIHZlcnNpb24gb2Ygb3BlcmF0aW5n IHN5c3RlbSBzb2Z0d2FyZSBpdA0KICAgIGlzIHJ1bm5pbmcuDQoNCiAgSXQgaXMgbm90IGNsZWFy IHRvIG1lIHdoYXQgdGhpcyBpcyBzdXBwb3NlZCB0byBtZWFuLiAgSSB0aGluayBpdA0KICBtZWFu cyAiaWYgdGhlIGZhY3RvcnkgZGVmYXVsdCBjb25maWd1cmF0aW9uIHNwZWNpZmllcyB0aGF0IHp0 cCBpcyB0bw0KICBiZSBydW4sIHRoZW4genRwIHdpbGwgYmUgcnVuIGFmdGVyIGEgZmFjdG9yeSBy ZXNldCIuICBCdXQgdGhpcyBpcw0KICBraW5kIG9mIG9idmlvdXMuLi4gIFNvIEkgc3VnZ2VzdCB0 aGF0IHRoaXMgc2VudGVuY2UgaXMgcmVtb3ZlZC4NCg0KW1Fpbl06IEpvZSBpbiBlYXJsaWVyIGNv bW1lbnRzIHdhbnRlZCB0byBtYWtlIHN1cmUgcmVib290IHdvdWxkIGhhcHBlbiBhcyBwYXJ0IG9m IHRoaXMgUlBDLA0KS2VudCBjb21lZCB1cCB3aXRoIGEgZmV3IHN1Z2dlc3Rpb24gYXMgYWJvdmUu IEkgYWxzbyBmZWVsIGEgbGl0dGxlIHJlZHVuZGFudCBzaW5jZSByZXN0YXJ0aW5nIHRoZSBub2Rl IGlzIHNpZGUgZWZmZWN0IG9mIA0KRmFjdG9yeS1yZXNldCBoYXMgYWxyZWFkeSBiZWVuIGNvdmVy ZWQgaW4gdGhlIHRleHQuIEkgYW0gaGFwcHkgdG8NCnRha2UgaXQgb3V0IGlmIG5vYm9keSBpcyBh Z2FpbnN0IGl0Lg0KDQpvICBTZWN0aW9uIDQNCg0KICBUaGUgWUFORyBtb2R1bGUgY29udGFpbnMg dGhlIGJvaWxlcnBsYXRlIHRleHQgZnJvbSBSRkMgODE3NCwgYnV0IHRoZQ0KICBtb2R1bGUgZG9l c24ndCB1c2UgODE3NC1sYW5ndWFnZSwgc28gSSBzdWdnZXN0IHRoZSBib2lsZXJwbGF0ZSB0ZXh0 DQogIGlzIHJlbW92ZWQuDQpbUWluXTogIk1BWSIga2V5IHdvcmQgaXMgdXNlZCBpbiB0aGlzIGRy YWZ0LCBJIGFtIG5vdCBzdXJlIHRvIHJlbW92ZSBib2lsZXJwbGF0ZSB0ZXh0Lg0KDQpvICBTZWN0 aW9uIDQNCg0KICBTdWdnZXN0Og0KDQogIE9MRDoNCg0KICAgICBmZWF0dXJlIGZhY3RvcnktZGVm YXVsdC1hcy1kYXRhc3RvcmUgew0KICAgICAgIGRlc2NyaXB0aW9uICJJbmRpY2F0ZXMgdGhhdCB0 aGUgZmFjdG9yeSBkZWZhdWx0IGNvbmZpZ3VyYXRpb24gaXMNCiAgICAgICAgIGFsc28gYXZhaWxh YmxlIGFzIGEgc2VwYXJhdGUgZGF0YXN0b3JlIjsNCiAgICAgfQ0KDQogIE5FVzoNCg0KICAgICBm ZWF0dXJlIGZhY3RvcnktZGVmYXVsdC1hcy1kYXRhc3RvcmUgew0KICAgICAgIGRlc2NyaXB0aW9u DQogICAgICAgICAiSW5kaWNhdGVzIHRoYXQgdGhlIGZhY3RvcnkgZGVmYXVsdCBjb25maWd1cmF0 aW9uIGlzDQogICAgICAgICAgYXZhaWxhYmxlIGFzIGEgZGF0YXN0b3JlLiI7DQogICAgIH0NCltR aW5dOk9rYXkuDQoNCm8gIFNlY3Rpb24gNA0KDQogIFRoZSBtb2R1bGUgYXVnbWVudHMgYSBuZXcg bGVhZiAnZmFjdG9yeS1kZWZhdWx0JyBpbnRvIDxnZXQtY29uZmlnPi4NCiAgSSBzdWdnZXN0IHRo YXQgd2UgcmVtb3ZlIHRoaXMuICBPdGhlciBkYXRhc3RvcmVzIGxpa2UgaW50ZW5kZWQgYXJlDQog IG5vdCBhdmFpbGFibGUgdGhyb3VnaCBnZXQtY29uZmlnLCBhbmQgSSBzZWUgbm8gcmVhc29uIHdo eQ0KICBmYWN0b3J5LWRlZmF1bHQgc2hvdWxkIGJlIHRyZWF0ZWQgZGlmZmVyZW50bHkuDQpbUWlu XTogb3JpZ2luYWxseSwgaXQgd2FzIGFkZGVkIGJhc2VkIG9uIGNoYWlyJ3Mgc3VnZ2VzdGlvbi4N CkkgYW0gb2theSB0byByZW1vdmUgaXQgaWYgdGhlcmUgaXMgbm9ib2R5IGFnYWluc3QgaXQuDQoN Cm8gIFNlY3Rpb24gNA0KDQogIEkgcmVjb21tZW5kIHRoYXQgeW91IHJ1biB0aGUgWUFORyBtb2R1 bGUgdGhyb3VnaA0KDQogICAgcHlhbmcgLWYgeWFuZyAtLWtlZXAtY29tbWVudHMgLS15YW5nLWxp bmUtbGVuZ3RoIDY5IDxGSUxFPg0KDQogIGluIG9yZGVyIHRvIGZpeCBzb21lIGZvcm1hdHRpbmcg YW5kIGluZGVudGF0aW9uIGlzc3Vlcy4NCg0KW1Fpbl06T2theSwgdGhhbmtzLg0KDQovbWFydGlu DQoNCg== From nobody Mon Nov 4 05:57:37 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42FC4120219; Mon, 4 Nov 2019 05:57:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 ImMiWypyB7eE; Mon, 4 Nov 2019 05:57:25 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 52CE8120814; Mon, 4 Nov 2019 05:57:25 -0800 (PST) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id D02121AE049B; Mon, 4 Nov 2019 14:57:23 +0100 (CET) Date: Mon, 04 Nov 2019 14:56:54 +0100 (CET) Message-Id: <20191104.145654.1893092470951786518.mbj@tail-f.com> To: bill.wu@huawei.com Cc: netconf@ietf.org, draft-ietf-netmod-factory-default@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=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netconf] WG Last Call: draft-ietf-netmod-factory-default-05 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, 04 Nov 2019 13:57:36 -0000 SGksDQoNClRyaW1taW5nIHRvIG9wZW4gaXNzdWVzLi4uDQoNClFpbiBXdSA8YmlsbC53dUBodWF3 ZWkuY29tPiB3cm90ZToNCj4gVGhhbmtzIE1hcnRpbiwgc2VlIHJlcGx5IGlubGluZSBiZWxvdy4N Cj4gDQo+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBNYXJ0aW4gQmpvcmts dW5kIFttYWlsdG86bWJqQHRhaWwtZi5jb21dIA0KDQo+IG8gIEFic3RyYWN0IGFuZCBJbnRyb2R1 Y3Rpb24NCj4gDQo+ICAgVGhlc2UgYm90aCBjb250YWluOg0KPiANCj4gICAgIFRoZSByZXNldCBv cGVyYXRpb24gbWF5IGJlIHVzZWQgZS5nLiBkdXJpbmcgaW5pdGlhbA0KPiAgICAgemVyby10b3Vj aCBjb25maWd1cmF0aW9uIA0KPiANCj4gICBhbmQgaW4gdGhlIEludHJvZHVjdGlvbiB0aGVyZSdz IGEgcmVmZXJlbmNlIHRvIFJGQyA4NTcyLg0KPiANCj4gICBCdXQgd2hhdCBkb2VzIHRoaXMgYWN0 dWFsbHkgbWVhbj8NCj4gW1Fpbl06IEl0IG1lYW5zIHRoZSBrZXkgd29yZCB6ZXJvLXRvdWNoIGNv bWVzIGZyb20gUkZDODU3Mi4NCg0KSSBnZXQgdGhhdCBwYXJ0LiAgSSB3YXMgd29uZGVyaW5nIGFi b3V0IHRoZSBtZWFuaW5nIG9mIHRoZSBzZW50ZW5jZS4NCkhvdyBjYW4gInJlc2V0IiBiZSB1c2Vk ICJkdXJpbmcgaW5pdGlhbCB6ZXJvLXRvdWNoIGNvbmZpZ3VyYXRpb24iPw0KDQoNCj4gbyAgU2Vj dGlvbiA0DQo+IA0KPiAgIFRoZSBZQU5HIG1vZHVsZSBjb250YWlucyB0aGUgYm9pbGVycGxhdGUg dGV4dCBmcm9tIFJGQyA4MTc0LCBidXQgdGhlDQo+ICAgbW9kdWxlIGRvZXNuJ3QgdXNlIDgxNzQt bGFuZ3VhZ2UsIHNvIEkgc3VnZ2VzdCB0aGUgYm9pbGVycGxhdGUgdGV4dA0KPiAgIGlzIHJlbW92 ZWQuDQo+IFtRaW5dOiAiTUFZIiBrZXkgd29yZCBpcyB1c2VkIGluIHRoaXMgZHJhZnQsIEkgYW0g bm90IHN1cmUgdG8gcmVtb3ZlIGJvaWxlcnBsYXRlIHRleHQuDQoNCkJ1dCBNQVkgaXNuJ3QgdXNl ZCBpbiB0aGUgKllBTkcgbW9kdWxlKi4gIFRoZSBib2lsZXJwbGF0ZSBpbiBzZWN0aW9uDQoxLjEg c2hvdWxkIHN0YXksIGJ1dCB0aGUgYm9pbGVycGxhdGUgaW4gdGhlIFlBTkcgbW9kdWxlIHNob3Vs ZCBiZQ0KcmVtb3ZlZC4NCg0KDQoNCi9tYXJ0aW4NCg== From nobody Mon Nov 4 06:17:26 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D28331200E7; Mon, 4 Nov 2019 06:17:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2PO1awAhoM0; Mon, 4 Nov 2019 06:17:22 -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 1D48E120099; Mon, 4 Nov 2019 06:17:22 -0800 (PST) Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 7452215E36F566E04083; Mon, 4 Nov 2019 14:17:20 +0000 (GMT) Received: from lhreml718-chm.china.huawei.com (10.201.108.69) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 4 Nov 2019 14:17:19 +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; Mon, 4 Nov 2019 14:17:19 +0000 Received: from DGGEML421-HUB.china.huawei.com (10.1.199.38) 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; Mon, 4 Nov 2019 14:17:19 +0000 Received: from DGGEML531-MBS.china.huawei.com ([169.254.5.209]) by dggeml421-hub.china.huawei.com ([10.1.199.38]) with mapi id 14.03.0439.000; Mon, 4 Nov 2019 22:17:12 +0800 From: Qin Wu To: Martin Bjorklund CC: "netconf@ietf.org" , "draft-ietf-netmod-factory-default@ietf.org" Thread-Topic: [netconf] WG Last Call: draft-ietf-netmod-factory-default-05 Thread-Index: AdWTGad/hoXGC87vTem9+ie/gPo2nw== Date: Mon, 4 Nov 2019 14:17:12 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.31.203] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] WG Last Call: draft-ietf-netmod-factory-default-05 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, 04 Nov 2019 14:17:24 -0000 LS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBNYXJ0aW4gQmpvcmtsdW5kIFttYWls dG86bWJqQHRhaWwtZi5jb21dIA0K5Y+R6YCB5pe26Ze0OiAyMDE55bm0MTHmnIg05pelIDIxOjU3 DQrmlLbku7bkuro6IFFpbiBXdSA8YmlsbC53dUBodWF3ZWkuY29tPg0K5oqE6YCBOiBuZXRjb25m QGlldGYub3JnOyBkcmFmdC1pZXRmLW5ldG1vZC1mYWN0b3J5LWRlZmF1bHRAaWV0Zi5vcmcNCuS4 u+mimDogUmU6IFtuZXRjb25mXSBXRyBMYXN0IENhbGw6IGRyYWZ0LWlldGYtbmV0bW9kLWZhY3Rv cnktZGVmYXVsdC0wNQ0KDQpIaSwNCg0KVHJpbW1pbmcgdG8gb3BlbiBpc3N1ZXMuLi4NCg0KUWlu IFd1IDxiaWxsLnd1QGh1YXdlaS5jb20+IHdyb3RlOg0KPiBUaGFua3MgTWFydGluLCBzZWUgcmVw bHkgaW5saW5lIGJlbG93Lg0KPiANCj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiDlj5Hku7bk uro6IE1hcnRpbiBCam9ya2x1bmQgW21haWx0bzptYmpAdGFpbC1mLmNvbV0NCg0KPiBvICBBYnN0 cmFjdCBhbmQgSW50cm9kdWN0aW9uDQo+IA0KPiAgIFRoZXNlIGJvdGggY29udGFpbjoNCj4gDQo+ ICAgICBUaGUgcmVzZXQgb3BlcmF0aW9uIG1heSBiZSB1c2VkIGUuZy4gZHVyaW5nIGluaXRpYWwN Cj4gICAgIHplcm8tdG91Y2ggY29uZmlndXJhdGlvbg0KPiANCj4gICBhbmQgaW4gdGhlIEludHJv ZHVjdGlvbiB0aGVyZSdzIGEgcmVmZXJlbmNlIHRvIFJGQyA4NTcyLg0KPiANCj4gICBCdXQgd2hh dCBkb2VzIHRoaXMgYWN0dWFsbHkgbWVhbj8NCj4gW1Fpbl06IEl0IG1lYW5zIHRoZSBrZXkgd29y ZCB6ZXJvLXRvdWNoIGNvbWVzIGZyb20gUkZDODU3Mi4NCg0KSSBnZXQgdGhhdCBwYXJ0LiAgSSB3 YXMgd29uZGVyaW5nIGFib3V0IHRoZSBtZWFuaW5nIG9mIHRoZSBzZW50ZW5jZS4NCkhvdyBjYW4g InJlc2V0IiBiZSB1c2VkICJkdXJpbmcgaW5pdGlhbCB6ZXJvLXRvdWNoIGNvbmZpZ3VyYXRpb24i Pw0KDQpbUWluXTogSSB0aGluayAicmVzZXQiIGNhbiBiZSB1c2VkIGF0IHRoZSBiZWdpbm5pbmcg b2Ygc2Vzc2lvbiBzZXR1cCBvciBpbiB0aGUgbWlkZGxlIG9mIHNlc3Npb24gd2hlbiB0aGUgZXhp c3RpbmcgY29uZmlndXJhdGlvbg0KSGFzIGZhdGFsIGVycm9yLg0KTWF5YmUgY2hhbmdlIGl0IGlu dG8gImJlZm9yZSBpbml0aWFsIHplcm8tdG91Y2ggY29uZmlndXJhdGlvbiI/DQoNCj4gbyAgU2Vj dGlvbiA0DQo+IA0KPiAgIFRoZSBZQU5HIG1vZHVsZSBjb250YWlucyB0aGUgYm9pbGVycGxhdGUg dGV4dCBmcm9tIFJGQyA4MTc0LCBidXQgdGhlDQo+ICAgbW9kdWxlIGRvZXNuJ3QgdXNlIDgxNzQt bGFuZ3VhZ2UsIHNvIEkgc3VnZ2VzdCB0aGUgYm9pbGVycGxhdGUgdGV4dA0KPiAgIGlzIHJlbW92 ZWQuDQo+IFtRaW5dOiAiTUFZIiBrZXkgd29yZCBpcyB1c2VkIGluIHRoaXMgZHJhZnQsIEkgYW0g bm90IHN1cmUgdG8gcmVtb3ZlIGJvaWxlcnBsYXRlIHRleHQuDQoNCkJ1dCBNQVkgaXNuJ3QgdXNl ZCBpbiB0aGUgKllBTkcgbW9kdWxlKi4gIFRoZSBib2lsZXJwbGF0ZSBpbiBzZWN0aW9uDQoxLjEg c2hvdWxkIHN0YXksIGJ1dCB0aGUgYm9pbGVycGxhdGUgaW4gdGhlIFlBTkcgbW9kdWxlIHNob3Vs ZCBiZSByZW1vdmVkLg0KDQpbUWluXTogSSBzZWUsIHdpbGwgcmVtb3ZlIGl0IGZyb20gdGhlIG1v ZHVsZS4NCg0KL21hcnRpbg0K From nobody Mon Nov 4 06:56:50 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95659120130; Mon, 4 Nov 2019 06:56:48 -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, SPF_HELO_NONE=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 vf2c6fvSvTNG; Mon, 4 Nov 2019 06:56:46 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C24AD1200F4; Mon, 4 Nov 2019 06:56:46 -0800 (PST) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 7CDD71AE049B; Mon, 4 Nov 2019 15:56:45 +0100 (CET) Date: Mon, 04 Nov 2019 15:56:16 +0100 (CET) Message-Id: <20191104.155616.1730122739409524776.mbj@tail-f.com> To: bill.wu@huawei.com Cc: netconf@ietf.org, draft-ietf-netmod-factory-default@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=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netconf] WG Last Call: draft-ietf-netmod-factory-default-05 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, 04 Nov 2019 14:56:49 -0000 UWluIFd1IDxiaWxsLnd1QGh1YXdlaS5jb20+IHdyb3RlOg0KPiAtLS0tLemCruS7tuWOn+S7ti0t LS0tDQo+IOWPkeS7tuS6ujogTWFydGluIEJqb3JrbHVuZCBbbWFpbHRvOm1iakB0YWlsLWYuY29t XSANCj4g5Y+R6YCB5pe26Ze0OiAyMDE55bm0MTHmnIg05pelIDIxOjU3DQo+IOaUtuS7tuS6ujog UWluIFd1IDxiaWxsLnd1QGh1YXdlaS5jb20+DQo+IOaKhOmAgTogbmV0Y29uZkBpZXRmLm9yZzsg ZHJhZnQtaWV0Zi1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0QGlldGYub3JnDQo+IOS4u+mimDogUmU6 IFtuZXRjb25mXSBXRyBMYXN0IENhbGw6IGRyYWZ0LWlldGYtbmV0bW9kLWZhY3RvcnktZGVmYXVs dC0wNQ0KPiANCj4gSGksDQo+IA0KPiBUcmltbWluZyB0byBvcGVuIGlzc3Vlcy4uLg0KPiANCj4g UWluIFd1IDxiaWxsLnd1QGh1YXdlaS5jb20+IHdyb3RlOg0KPiA+IFRoYW5rcyBNYXJ0aW4sIHNl ZSByZXBseSBpbmxpbmUgYmVsb3cuDQo+ID4gDQo+ID4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K PiA+IOWPkeS7tuS6ujogTWFydGluIEJqb3JrbHVuZCBbbWFpbHRvOm1iakB0YWlsLWYuY29tXQ0K PiANCj4gPiBvICBBYnN0cmFjdCBhbmQgSW50cm9kdWN0aW9uDQo+ID4gDQo+ID4gICBUaGVzZSBi b3RoIGNvbnRhaW46DQo+ID4gDQo+ID4gICAgIFRoZSByZXNldCBvcGVyYXRpb24gbWF5IGJlIHVz ZWQgZS5nLiBkdXJpbmcgaW5pdGlhbA0KPiA+ICAgICB6ZXJvLXRvdWNoIGNvbmZpZ3VyYXRpb24N Cj4gPiANCj4gPiAgIGFuZCBpbiB0aGUgSW50cm9kdWN0aW9uIHRoZXJlJ3MgYSByZWZlcmVuY2Ug dG8gUkZDIDg1NzIuDQo+ID4gDQo+ID4gICBCdXQgd2hhdCBkb2VzIHRoaXMgYWN0dWFsbHkgbWVh bj8NCj4gPiBbUWluXTogSXQgbWVhbnMgdGhlIGtleSB3b3JkIHplcm8tdG91Y2ggY29tZXMgZnJv bSBSRkM4NTcyLg0KPiANCj4gSSBnZXQgdGhhdCBwYXJ0LiAgSSB3YXMgd29uZGVyaW5nIGFib3V0 IHRoZSBtZWFuaW5nIG9mIHRoZSBzZW50ZW5jZS4NCj4gSG93IGNhbiAicmVzZXQiIGJlIHVzZWQg ImR1cmluZyBpbml0aWFsIHplcm8tdG91Y2ggY29uZmlndXJhdGlvbiI/DQo+IA0KPiBbUWluXTog SSB0aGluayAicmVzZXQiIGNhbiBiZSB1c2VkIGF0IHRoZSBiZWdpbm5pbmcgb2Ygc2Vzc2lvbiBz ZXR1cCBvciBpbiB0aGUgbWlkZGxlIG9mIHNlc3Npb24gd2hlbiB0aGUgZXhpc3RpbmcgY29uZmln dXJhdGlvbg0KPiBIYXMgZmF0YWwgZXJyb3IuDQo+IE1heWJlIGNoYW5nZSBpdCBpbnRvICJiZWZv cmUgaW5pdGlhbCB6ZXJvLXRvdWNoIGNvbmZpZ3VyYXRpb24iPw0KDQpJIGRvbid0IHRoaW5rIHRo aXMgaXMgY29ycmVjdDsgbm9vbmUgd2lsbCBpbnZva2UgImZhY3RvcnktcmVzZXQiDQoqYmVmb3Jl KiB0aGUgaW5pdGlhbCB6dHAgLS0gcmF0aGVyLCB0aGUgZmFjdG9yeSBkZWZhdWx0IGNvbmZpZyB3 aWxsDQpjb250YWluIGNvbmZpZyB0byBlbmFibGUgenRwIChzZWUgZS5nLiBzZWN0aW9uIEEuMSBp biBSRkMgODU3MikuDQpQZXJoYXBzIHNpbXBseSByZW1vdmUgdGhpcyBzZW50ZW5jZT8NCg0KS2Vu dCwgZG8geW91IGhhdmUgYW4gb3Bpbmlvbj8NCg0KDQovbWFydGluDQo= From nobody Mon Nov 4 16:20:09 2019 Return-Path: <0100016e38eecc54-1c213e7a-4062-4328-91d9-525a75dac5ff-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 ADD9412009E; Mon, 4 Nov 2019 16:20:07 -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 EYVuk6VF7Yuc; Mon, 4 Nov 2019 16:20:06 -0800 (PST) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11E98120041; Mon, 4 Nov 2019 16:20:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1572913204; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=XhgVgAIQQlGj8dczZEz0pTb0+BfrocO8TKgw5nF8Y0M=; b=bYqV8i80UFAlUh4v9Wgzr+oJBOJPzsZ3gK4fxQZF7cy8HdcoLlr2J0hgsFViBrgu 8+dCyWCTyMOG/o0gDQ79jJ6av9Zg4dTVeLKUT8tpAC364wDC/lpBN1BtjwtVKWVMO08 CTeWPhsldvfPS1VxO0hPdOTJCG4VU59SruE4kl7I= From: Kent Watsen Message-ID: <0100016e38eecc54-1c213e7a-4062-4328-91d9-525a75dac5ff-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_ED10FF82-35B2-4166-9560-D9C74B107AA3" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 5 Nov 2019 00:20:04 +0000 In-Reply-To: Cc: Tianran Zhou , draft-zhou-netconf-multi-stream-originators , "netconf-chairs@ietf.org" To: "netconf@ietf.org" References: <157250161429.32624.10183459345808600687.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.11.05-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Adoption request//FW: New Version Notification for draft-zhou-netconf-multi-stream-originators-09.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2019 00:20:08 -0000 --Apple-Mail=_ED10FF82-35B2-4166-9560-D9C74B107AA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 All, and Tianran. The chairs have been working closely with the authors for the last week = in trying to make improvements to this draft prior to agreeing to = initiate an adoption poll. Our primary concern has been, and continues = to be so, that the draft doesn't clearly specify the problem statement, = while describing perhaps too many implementation-level details. We understand that adoptions of a draft is just a starting point for the = WG to develop the draft from. However, without a clear problem = statement, it is difficult to discern what is scope the draft. In = particular, we perceive this draft as enabling clients to 1) discover = how many line cards there are and 2) determine the = "message-generator-id" for each (however 'each' is mapped). = Additionally, we feel that this draft's claim to defining a distributed = logging architecture is overreaching, as distributed Syslog-based = implementations have existed for years. =20 What does the WG think? The chairs are cognizant that such questions = may be sussed out in the course of an adoption poll, but felt the need = the WG to focus on this particular point first. We would welcome the WG = to discuss this point on list before the 106 meeting. Kent and Mahesh > On Nov 2, 2019, at 5:02 AM, Tianran Zhou = wrote: >=20 > Hi Folks, >=20 > We just updated the draft to address some more clarification = questions. > I think it=E2=80=99s ready as the starting point for working group = discussion. > We request the adoption call. >=20 > Cheers, > Tianran=20 --Apple-Mail=_ED10FF82-35B2-4166-9560-D9C74B107AA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

All, and = Tianran.

The = chairs have been working closely with the authors for the last week in = trying to make improvements to this draft prior to agreeing to initiate = an adoption poll.  Our primary concern has been, and continues to = be so, that the draft doesn't clearly specify the problem statement, = while describing perhaps too many implementation-level = details.

We = understand that adoptions of a draft is just a starting point for the WG = to develop the draft from.  However, without a clear problem = statement, it is difficult to discern what is scope the draft.  In = particular, we perceive this draft as enabling clients to 1) discover = how many line cards there are and 2) determine the = "message-generator-id" for each (however 'each' is mapped). =  Additionally, we feel that this draft's claim to defining a = distributed logging architecture is overreaching, as distributed = Syslog-based implementations have existed for years.  

What does the WG think? =   The chairs are cognizant that such questions may be sussed out in = the course of an adoption poll, but felt the need the WG to focus on = this particular point first.  We would welcome the WG to discuss = this point on list before the 106 meeting.

Kent and Mahesh



On Nov = 2, 2019, at 5:02 AM, Tianran Zhou <zhoutianran@huawei.com> wrote:

Hi Folks,

We just = updated the draft to address some more clarification questions.
I think it=E2=80=99s ready as the starting point for working = group discussion.
We request the adoption call.

Cheers,
Tianran 
= --Apple-Mail=_ED10FF82-35B2-4166-9560-D9C74B107AA3-- From nobody Mon Nov 4 16:51:55 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 105DE120147; Mon, 4 Nov 2019 16:51:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ID9YbrCToP0U; Mon, 4 Nov 2019 16:51:52 -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 2CDA712006F; Mon, 4 Nov 2019 16:51:52 -0800 (PST) Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id B916C38C4B70BF923243; Tue, 5 Nov 2019 00:51:49 +0000 (GMT) Received: from DGGEML421-HUB.china.huawei.com (10.1.199.38) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 5 Nov 2019 00:51:48 +0000 Received: from DGGEML531-MBS.china.huawei.com ([169.254.5.209]) by dggeml421-hub.china.huawei.com ([10.1.199.38]) with mapi id 14.03.0439.000; Tue, 5 Nov 2019 08:51:40 +0800 From: Qin Wu To: Martin Bjorklund CC: "netconf@ietf.org" , "draft-ietf-netmod-factory-default@ietf.org" Thread-Topic: [netconf] WG Last Call: draft-ietf-netmod-factory-default-05 Thread-Index: AdWTcx8LJqoftY79TsiobEj5vz6Y4w== Date: Tue, 5 Nov 2019 00:51:41 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.31.203] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] WG Last Call: draft-ietf-netmod-factory-default-05 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, 05 Nov 2019 00:51:54 -0000 SGksIE1hcnRpbjoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogTWFydGluIEJq b3JrbHVuZCBbbWFpbHRvOm1iakB0YWlsLWYuY29tXSANCuWPkemAgeaXtumXtDogMjAxOeW5tDEx 5pyINOaXpSAyMjo1Ng0K5pS25Lu25Lq6OiBRaW4gV3UgPGJpbGwud3VAaHVhd2VpLmNvbT4NCuaK hOmAgTogbmV0Y29uZkBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0 QGlldGYub3JnDQrkuLvpopg6IFJlOiBbbmV0Y29uZl0gV0cgTGFzdCBDYWxsOiBkcmFmdC1pZXRm LW5ldG1vZC1mYWN0b3J5LWRlZmF1bHQtMDUNCg0KUWluIFd1IDxiaWxsLnd1QGh1YXdlaS5jb20+ IHdyb3RlOg0KPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+IOWPkeS7tuS6ujogTWFydGluIEJq b3JrbHVuZCBbbWFpbHRvOm1iakB0YWlsLWYuY29tXQ0KPiDlj5HpgIHml7bpl7Q6IDIwMTnlubQx MeaciDTml6UgMjE6NTcNCj4g5pS25Lu25Lq6OiBRaW4gV3UgPGJpbGwud3VAaHVhd2VpLmNvbT4N Cj4g5oqE6YCBOiBuZXRjb25mQGlldGYub3JnOyBkcmFmdC1pZXRmLW5ldG1vZC1mYWN0b3J5LWRl ZmF1bHRAaWV0Zi5vcmcNCj4g5Li76aKYOiBSZTogW25ldGNvbmZdIFdHIExhc3QgQ2FsbDogZHJh ZnQtaWV0Zi1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0LTA1DQo+IA0KPiBIaSwNCj4gDQo+IFRyaW1t aW5nIHRvIG9wZW4gaXNzdWVzLi4uDQo+IA0KPiBRaW4gV3UgPGJpbGwud3VAaHVhd2VpLmNvbT4g d3JvdGU6DQo+ID4gVGhhbmtzIE1hcnRpbiwgc2VlIHJlcGx5IGlubGluZSBiZWxvdy4NCj4gPiAN Cj4gPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+ID4g5Y+R5Lu25Lq6OiBNYXJ0aW4gQmpvcmts dW5kIFttYWlsdG86bWJqQHRhaWwtZi5jb21dDQo+IA0KPiA+IG8gIEFic3RyYWN0IGFuZCBJbnRy b2R1Y3Rpb24NCj4gPiANCj4gPiAgIFRoZXNlIGJvdGggY29udGFpbjoNCj4gPiANCj4gPiAgICAg VGhlIHJlc2V0IG9wZXJhdGlvbiBtYXkgYmUgdXNlZCBlLmcuIGR1cmluZyBpbml0aWFsDQo+ID4g ICAgIHplcm8tdG91Y2ggY29uZmlndXJhdGlvbg0KPiA+IA0KPiA+ICAgYW5kIGluIHRoZSBJbnRy b2R1Y3Rpb24gdGhlcmUncyBhIHJlZmVyZW5jZSB0byBSRkMgODU3Mi4NCj4gPiANCj4gPiAgIEJ1 dCB3aGF0IGRvZXMgdGhpcyBhY3R1YWxseSBtZWFuPw0KPiA+IFtRaW5dOiBJdCBtZWFucyB0aGUg a2V5IHdvcmQgemVyby10b3VjaCBjb21lcyBmcm9tIFJGQzg1NzIuDQo+IA0KPiBJIGdldCB0aGF0 IHBhcnQuICBJIHdhcyB3b25kZXJpbmcgYWJvdXQgdGhlIG1lYW5pbmcgb2YgdGhlIHNlbnRlbmNl Lg0KPiBIb3cgY2FuICJyZXNldCIgYmUgdXNlZCAiZHVyaW5nIGluaXRpYWwgemVyby10b3VjaCBj b25maWd1cmF0aW9uIj8NCj4gDQo+IFtRaW5dOiBJIHRoaW5rICJyZXNldCIgY2FuIGJlIHVzZWQg YXQgdGhlIGJlZ2lubmluZyBvZiBzZXNzaW9uIHNldHVwIA0KPiBvciBpbiB0aGUgbWlkZGxlIG9m IHNlc3Npb24gd2hlbiB0aGUgZXhpc3RpbmcgY29uZmlndXJhdGlvbiBIYXMgZmF0YWwgZXJyb3Iu DQo+IE1heWJlIGNoYW5nZSBpdCBpbnRvICJiZWZvcmUgaW5pdGlhbCB6ZXJvLXRvdWNoIGNvbmZp Z3VyYXRpb24iPw0KDQpJIGRvbid0IHRoaW5rIHRoaXMgaXMgY29ycmVjdDsgbm9vbmUgd2lsbCBp bnZva2UgImZhY3RvcnktcmVzZXQiDQoqYmVmb3JlKiB0aGUgaW5pdGlhbCB6dHAgLS0gcmF0aGVy LCB0aGUgZmFjdG9yeSBkZWZhdWx0IGNvbmZpZyB3aWxsIGNvbnRhaW4gY29uZmlnIHRvIGVuYWJs ZSB6dHAgKHNlZSBlLmcuIHNlY3Rpb24gQS4xIGluIFJGQyA4NTcyKS4NClBlcmhhcHMgc2ltcGx5 IHJlbW92ZSB0aGlzIHNlbnRlbmNlPw0KDQpbUWluXTpVbmRlcnN0YW5kLCBzbyBmYWN0b3J5IGRl ZmF1bHQgY29uZmlnIGluIHJlbGV2YW50IGRhdGFzdG9yZSBpcyBzdGlsbCB1c2VmdWwgZHVyaW5n IGluaXRpYWwgemVybyB0b3VjaCBjb25maWd1cmF0aW9uLGhvdyBhYm91dCB0aGUgZm9sbG93aW5n IGNoYW5nZQ0KT0xEIFRFWFQ6DQoiDQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIG1ldGhv ZCB0byByZXNldCBhIHNlcnZlciB0byBpdHMgZmFjdG9yeS0NCiAgIGRlZmF1bHQgY29udGVudC4g IFRoZSByZXNldCBvcGVyYXRpb24gbWF5IGJlIHVzZWQgZS5nLiBkdXJpbmcgaW5pdGlhbA0KICAg emVyby10b3VjaCBjb25maWd1cmF0aW9uIG9yIHdoZW4gdGhlIGV4aXN0aW5nIGNvbmZpZ3VyYXRp b24gaGFzIG1ham9yDQogICBlcnJvcnMsIHNvIHJlLXN0YXJ0aW5nIHRoZSBjb25maWd1cmF0aW9u IHByb2Nlc3MgZnJvbSBzY3JhdGNoIGlzIHRoZQ0KICAgYmVzdCBvcHRpb24uDQoNCi4uLi4uLi4N Cg0KICAgT3B0aW9uYWxseSBhIG5ldyAiZmFjdG9yeS1kZWZhdWx0IiByZWFkLW9ubHkgZGF0YXN0 b3JlIGlzIGRlZmluZWQsDQogICB0aGF0IGNvbnRhaW5zIHRoZSBkYXRhIHRoYXQgd2lsbCBiZSBj b3BpZWQgb3ZlciB0byB0aGUgcnVubmluZw0KICAgZGF0YXN0b3JlIGF0IHJlc2V0Lg0KIg0KTkVX IFRFWFQ6DQoiDQogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBtZXRob2QgdG8gcmVzZXQgYSBz ZXJ2ZXIgdG8gaXRzIGZhY3RvcnktDQogICBkZWZhdWx0IGNvbnRlbnQuICBUaGUgcmVzZXQgb3Bl cmF0aW9uIG1heSBiZSB1c2VkIGUuZy4gDQogICB3aGVuIHRoZSBleGlzdGluZyBjb25maWd1cmF0 aW9uIGhhcyBtYWpvcg0KICAgZXJyb3JzLCBzbyByZS1zdGFydGluZyB0aGUgY29uZmlndXJhdGlv biBwcm9jZXNzIGZyb20gc2NyYXRjaCBpcyB0aGUNCiAgIGJlc3Qgb3B0aW9uLg0KDQouLi4uLi4u DQoNCiAgIE9wdGlvbmFsbHkgYSBuZXcgImZhY3RvcnktZGVmYXVsdCIgcmVhZC1vbmx5IGRhdGFz dG9yZSBpcyBkZWZpbmVkLA0KICAgdGhhdCBjb250YWlucyB0aGUgZGF0YSB0aGF0IHdpbGwgYmUg Y29waWVkIG92ZXIgdG8gdGhlIHJ1bm5pbmcNCiAgIGRhdGFzdG9yZSBhdCByZXNldCBvciBkdXJp bmcgaW5pdGlhbCB6ZXJvLXRvdWNoIGNvbmZpZ3VyYXRpb24uDQoiDQpIb3BlIHRoaXMgYWRkcmVz c2VzIHlvdXIgcG9pbnQuDQoNCktlbnQsIGRvIHlvdSBoYXZlIGFuIG9waW5pb24/DQoNCg0KL21h cnRpbg0K From nobody Mon Nov 4 18:27:12 2019 Return-Path: <0100016e39631e46-c007fd65-2e51-47a6-bd27-764f5257a16c-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 C605B120033 for ; Mon, 4 Nov 2019 18:27:10 -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 98U8ZMAXIOFi for ; Mon, 4 Nov 2019 18:27:09 -0800 (PST) Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D312812000F for ; Mon, 4 Nov 2019 18:27:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1572920827; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=yWrLcoc3BFSmd4ySEYmrCdsIP8l4ukYtncxDDuBsFQg=; b=BygZNdlPouIgRIQRbOtn0dTH2Pxt4rGpDW0iLpGcv/V8UQ15Jv01/8ivPk3QM2Av KeOaOpPaZt8yo3sxoezeOifyelQSwdwFBmoiIbMtGVUYZgdWuj4UnNOXT1527EZweTe jz+5PNZdoXTz+vwyWFrTw4Ef0jOOGxkg2cs/aQfg= From: Kent Watsen Message-ID: <0100016e39631e46-c007fd65-2e51-47a6-bd27-764f5257a16c-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_15C1EAA2-6D2C-46F3-86E4-4D330547DB49" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 5 Nov 2019 02:27:07 +0000 In-Reply-To: <20191104.111319.869021723410428870.mbj@tail-f.com> Cc: "netconf@ietf.org" To: Martin Bjorklund References: <20191104.111319.869021723410428870.mbj@tail-f.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.11.05-54.240.8.83 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] client identification in ietf-netconf-server 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, 05 Nov 2019 02:27:11 -0000 --Apple-Mail=_15C1EAA2-6D2C-46F3-86E4-4D330547DB49 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Martin, > The ietf-netconf-server module has this: >=20 > grouping netconf-server-grouping { > ... > container client-identification { > ... > container cert-maps { > when "../../../../tls"; > uses x509c2n:cert-to-name; > ... > } > } > } >=20 > Note the "when" expression. This means that the grouping has a strong > depency on where is it used. We should try to avoid such a design. Would this be better? =20 OLD when "../../../../tls"; NEW if-feature "tls-listen or tls-call-home"; > But should't this cert-to-name list be available when x509-certs are > used also with SSH? Hmmm. I'd assumed that, with RFC 6187, the username was still passed as = its own field, but I see this in Section 4: For the purposes of user authentication, the mapping between certificates and user names is left as an implementation and configuration issue for implementers and system administrators. So you may be right about that. I only ever looked at RFC 6187 from the = perspective of the server presenting an IDevID certificate. But, = assuming it's true, then perhaps this: NEWEST: if-feature "tls-listen or tls-call-home or = sshcmn:ssh-x509-certs"; > The current data model for ssh specifies certs on > a per-user basis. But this requires lots of configuration in the case > that the cert encodes the user name (even though the name is in the > cert you have to configure each user on each device). I suggest we > align the model for SSH with the TLS model for cert identification. We certainly want to factor out configuration where possible. I'd need = to look into this more. Perhaps you can send a diff? > For TLS, the data model has the following structure: >=20 > +--rw netconf-server > +--rw listen! {ssh-listen or tls-listen}? > +--rw idle-timeout? uint16 > +--rw endpoint* [name] > +--rw name string > +--rw (transport) > ... > +--:(tls) {tls-listen}? >=20 > [ reset indentation to make the diagram easier to read ] >=20 > +--rw tls > +--rw tcp-server-parameters > ... > +--rw tls-server-parameters > | +--rw server-identity > ... > | +--rw client-authentication! > | | +--rw (required-or-optional) > | | | +--:(required) > | | | | +--rw required? empty > | | | +--:(optional) > | | | +--rw optional? empty > | | +--rw (local-or-external) > | | +--:(local) {local-client-auth-supported}? > | | | +--rw ca-certs! {ts:x509-certificates}? > | | | | +--rw (local-or-truststore) > | | | | +--:(local) {local-definitions-supported}? > | | | | | +--rw local-definition > | | | | | +--rw cert* trust-anchor-cert-cms > | | | | | +---n certificate-expiration > | | | | | +-- expiration-date > | | | | | yang:date-and-time > | | | | +--:(truststore) > | | | | = {truststore-supported,x509-certificates}? > | | | | +--rw truststore-reference? > | | | | ts:certificates-ref > | | | +--rw client-certs! {ts:x509-certificates}? > | | | +--rw (local-or-truststore) > | | | +--:(local) {local-definitions-supported}? > | | | | +--rw local-definition > | | | | +--rw cert* trust-anchor-cert-cms > | | | | +---n certificate-expiration > | | | | +-- expiration-date > | | | | yang:date-and-time > | | | +--:(truststore) > | | | = {truststore-supported,x509-certificates}? > | | | +--rw truststore-reference? > | | | ts:certificates-ref > | | +--:(external) > | | {external-client-auth-supported}? > | | +--rw client-auth-defined-elsewhere? > | | empty > ... > +--rw netconf-server-parameters > +--rw client-identification > +--rw cert-maps > +--rw cert-to-name* [id] > +--rw id uint32 > +--rw fingerprint > | x509c2n:tls-fingerprint > +--rw map-type identityref > +--rw name string > It is not clear how this is used by the server to end up either with > an authenticated user name or failed authentication. Okay, let's fix that. > First of all, how is the "required-or-optional" choice used in a > NETCONF server? What happens if an operation configures this to > "optional"? (side note: why is this a choice of empty leafs instead > of a leaf?) Hmmm, this 'choice' seems unneeded for NETCONF. The "choice" is coming = from the ietf-tls-server, and a similar "choice" is in ietf-http-server. = It was put there, in part, for RESTCONF, as user-auth can occur at = either (or both!) protocol layers... > Second, I assume that the idea is that the server uses the config > params in "local-or-external" and the certificate presented by the > client and after this step is either accepted or rejected. It is not > clear what is supposed to happen if someone configures > "client-auth-defined-elsewhere". I think it is better to not define > this case, but (perhaps) keep the choice and explain that other > modules can augment additional config params here for other > authentication mechanisms. Well that's just the thing, the goal is to enable user-auth to NOT be = defined here. As the description statement in ietf-tls-server says: "Configuring credentials externally enables applications to place client authentication with client definitions, rather then in a part of a data model principally concerned with configuring the TLS transport."; > Next, my guess is that the intention is that if the cert was accepted > in the step above, it is checked in cert-to-name to see if a user name > can be derived. Yes. > In another thread you mentioned that if a local cert is configured, it > seems redundant to also configure the cert as a fingerprint in > cert-to-name. I'm not sure about this. But perhaps you can use the > same "map-type" and "name" leafs in the "client-cert" container? It > is not as easy for the "truststore-reference"; perhaps you'd have to > augment the truststore with these leafs in this case. In context, that statement I made before is a relatively minor = objection. That said, I don't understand your proposal, as you = suggesting the recreate the essence of 'cert-to-name'? Another idea I = had was that the fingerprint could be in a "union" with also a = truststore-reference, which is only mildly better... Kent // contributor --Apple-Mail=_15C1EAA2-6D2C-46F3-86E4-4D330547DB49 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Martin,


The ietf-netconf-server module has this:

 grouping netconf-server-grouping {
=    ...
   container = client-identification {
=      ...
=      container cert-maps {
=        when "../../../../tls";
       uses = x509c2n:cert-to-name;
=        ...
=      }
   }
 }

Note the "when" = expression.  This means that the grouping has a strong
depency on where is it used.  We should try to avoid = such a design.


Would this be better? =   

OLD
  =      when "../../../../tls";

NEW
if-feature "tls-listen or = tls-call-home";



But should't this = cert-to-name list be available when x509-certs are
used = also with SSH?

Hmmm.  I'd assumed that, with RFC 6187, the = username was still passed as its own field, but I see this in Section = 4:

   For the purposes of user authentication, the =
mapping between
   certificates and user names is left as an implementation and
   configuration issue for implementers and system administrators.

So you may be = right about that.  I only ever looked at RFC 6187 from the = perspective of the server presenting an IDevID certificate.  But, = assuming it's true, then perhaps this:

NEWEST:
= if-feature "tls-listen or tls-call-home or = sshcmn:ssh-x509-certs";



The current data model for ssh specifies = certs on
a per-user basis. But this requires lots of = configuration in the case
that the cert encodes the user = name (even though the name is in the
cert you have to = configure each user on each device).  I suggest we
align the model for SSH with the TLS model for cert = identification.

We certainly want to factor out configuration where = possible.  I'd need to look into this more.  Perhaps you can = send a diff?


For TLS, the data model has the following structure:

 +--rw netconf-server
=     +--rw listen! {ssh-listen or tls-listen}?
       +--rw = idle-timeout?   uint16
=        +--rw endpoint* [name]
=           +--rw name =         string
=           +--rw = (transport)
=             &n= bsp;...
=             &n= bsp;+--:(tls) {tls-listen}?

=    [ reset indentation to make the diagram easier to read = ]

  +--rw tls
=      +--rw tcp-server-parameters
=      ...
=      +--rw tls-server-parameters
=      |  +--rw server-identity
= =            ...
     |  +--rw = client-authentication!
     | =  |  +--rw (required-or-optional)
=      |  |  |  +--:(required)
     |  |  |  | =  +--rw required?    empty
=      |  |  |  +--:(optional)
     |  |  | =     +--rw optional?    empty
     |  |  +--rw = (local-or-external)
     | =  |     +--:(local) =  {local-client-auth-supported}?
=      |  |     | =  +--rw ca-certs!   {ts:x509-certificates}?
=      |  |     | =  |  +--rw (local-or-truststore)
=      |  |     | =  |     +--:(local) =  {local-definitions-supported}?
=      |  |     | =  |     |  +--rw local-definition
     |  | =     |  |     | =     +--rw cert*   trust-anchor-cert-cms
     |  | =     |  |     | =     +---n certificate-expiration
=      |  |     | =  |     | =        +-- expiration-date
     |  | =     |  |     | =             &n= bsp;  yang:date-and-time
=      |  |     | =  |     +--:(truststore)
=      |  |     | =  | =             &n= bsp;{truststore-supported,x509-certificates}?
=      |  |     | =  |        +--rw = truststore-reference?
     | =  |     |  | =             &n= bsp;  ts:certificates-ref
=      |  |     | =  +--rw client-certs!  {ts:x509-certificates}?
=      |  |     | =     +--rw (local-or-truststore)
=      |  |     | =        +--:(local) =  {local-definitions-supported}?
=      |  |     | =        |  +--rw = local-definition
     |  | =     |        | =     +--rw cert* =     trust-anchor-cert-cms
=      |  |     | =        | =     +---n certificate-expiration
=      |  |     | =        | =        +-- expiration-date
     |  | =     |        | =             &n= bsp;  yang:date-and-time
=      |  |     | =        +--:(truststore)
=      |  |     | =             &n= bsp;   {truststore-supported,x509-certificates}?
     |  | =     | =           +--rw = truststore-reference?
     | =  |     | =             &n= bsp;     ts:certificates-ref
=      |  | =     +--:(external)
=      |  | =             &n= bsp;{external-client-auth-supported}?
=      |  | =        +--rw = client-auth-defined-elsewhere?
=      |  | =             &n= bsp;  empty
=          ...
=      +--rw netconf-server-parameters
        +--rw = client-identification
=            +--rw = cert-maps
=             &n= bsp; +--rw cert-to-name* [id]
=             &n= bsp;    +--rw id =             ui= nt32
=             &n= bsp;    +--rw fingerprint
=             &n= bsp;    | =       x509c2n:tls-fingerprint
= =             &n= bsp;    +--rw map-type =       identityref
=             &n= bsp;    +--rw name =           string




It is not clear = how this is used by the server to end up either with
an = authenticated user name or failed = authentication.

Okay, let's fix that.


First of all, how is the = "required-or-optional" choice used in a
NETCONF server? =  What happens if an operation configures this to
"optional"?  (side note: why is this a choice of empty = leafs instead
of a leaf?)

Hmmm, = this 'choice' seems unneeded for NETCONF.  The "choice" is coming = from the ietf-tls-server, and a similar "choice" is = in ietf-http-server. It was put there, in part, for RESTCONF, as = user-auth can occur at either (or both!) protocol = layers...



Second, I assume that the idea is that the server uses the = config
params in "local-or-external" and the certificate = presented by the
client and after this step is either = accepted or rejected.  It is not
clear what is = supposed to happen if someone configures
"client-auth-defined-elsewhere".  I think it is better = to not define
this case, but (perhaps) keep the choice and = explain that other
modules can augment additional config = params here for other
authentication mechanisms.

Well = that's just the thing, the goal is to enable user-auth to NOT be defined = here.  As the description statement in ietf-tls-server = says:

        =   "Configuring credentials externally enables applications
           to place client = authentication with client definitions,
    =        rather then in a part of a data model = principally
          =  concerned with configuring the TLS transport.";


Next, my guess is that the intention is that = if the cert was accepted
in the step above, it is checked = in cert-to-name to see if a user name
can be derived.

Yes.


In another thread you mentioned that if a local cert is = configured, it
seems redundant to also configure the cert = as a fingerprint in
cert-to-name.  I'm not sure about = this.  But perhaps you can use the
same "map-type" = and "name" leafs in the "client-cert" container?  It
is= not as easy for the "truststore-reference"; perhaps you'd have to
augment the truststore with these leafs in this case.

In = context, that statement I made before is a relatively minor objection. =  That said, I don't understand your proposal, as you suggesting the = recreate the essence of 'cert-to-name'?   Another idea I had was = that the fingerprint could be in a "union" with also a = truststore-reference, which is only mildly better...


Kent // = contributor


= --Apple-Mail=_15C1EAA2-6D2C-46F3-86E4-4D330547DB49-- From nobody Mon Nov 4 18:30:54 2019 Return-Path: <0100016e3966831a-74ad59d8-0ce4-4627-8b3e-6cf4becd76a2-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 B24D5120033 for ; Mon, 4 Nov 2019 18:30:52 -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 dW1gsclN--wX for ; Mon, 4 Nov 2019 18:30:51 -0800 (PST) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3301012000F for ; Mon, 4 Nov 2019 18:30:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1572921050; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=iMiUlBg7sAPQgk/SMJ6regrbhcTbqDOJ9p2z6UndjPk=; b=XWgABcnBncZ9yVzx/iBf1vXVW+vITAoisJ2bZfhlSQr0RxWetUhzpv5EVtE0azF9 kZcgZnJ5/my7N+rR9kpBOwIimBmQoy5y0B7Cl2LDb8wvYOSduBoQyz5zsf646Y6mO2K 79Qt5gx2KMwS0wqdn5mWyLCH/l39P9i5CJvFsw2g= From: Kent Watsen Message-ID: <0100016e3966831a-74ad59d8-0ce4-4627-8b3e-6cf4becd76a2-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_3A928E5A-ABE8-447E-8BDC-B4438637F310" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 5 Nov 2019 02:30:49 +0000 In-Reply-To: <20191104.091119.1760037446043812190.mbj@tail-f.com> Cc: "netconf@ietf.org" To: Martin Bjorklund References: <0100016e1a0d419b-b221bfcc-d3cd-4386-a016-474e2303fba0-000000@email.amazonses.com> <20191030.132839.500650494712032488.mbj@tail-f.com> <0100016e1d98c767-57716d36-7f50-41d9-9641-360626517728-000000@email.amazonses.com> <20191104.091119.1760037446043812190.mbj@tail-f.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.11.05-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] x509c2n:cert-to-name problem 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, 05 Nov 2019 02:30:53 -0000 --Apple-Mail=_3A928E5A-ABE8-447E-8BDC-B4438637F310 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Martin, >>>> The "tls-server-parameters" container defines the certificates used = to >>>> authenticate the client's cert. In many deployments, regardless = how >>>> the client cert is authenticated, the "client-identification" = section only >>>> needs to explain how to extract the "name" from the cert, a = fingerprint >>>> isn't needed to identify either the client's end-entity or some >>>> intermediate cert. >>>=20 >>> Ok. To me this sounds like you need a more complex^wsophisticated >>> client identification mechansim than what a plain cert-to-name gives >>> you. I don't think there is anything wrong with the current >>> cert-to-name grouping. So let's continue this discussion in the >>> netconf ML, where this model is being developed. >>=20 >> In an attempt to resolve this issue, I modified both = ietf-netconf-server >> and ietf-restconf-server as follows: >>=20 >> OLD: >> uses x509c2n:cert-to-name; >>=20 >> NEW: >> uses x509c2n:cert-to-name { >> refine "cert-to-name/fingerprint" { >> mandatory false; >> description >> "A 'fingerprint' value does not need to be specified >> when the 'cert-to-name' mapping is independent of >> fingerprint matching. A 'cert-to-name' having no >> fingerprint value will match any client certificate >> and therefore should only be present at the end of >> the user-ordered 'cert-to-name' list."; >> } >> } >=20 > Did you see my email "client identification in ietf-netconf-server"? > I don't think this refinement is the correct solution. Having replied to your other message, I still don't understand this = statement. I understand the fingerprint being useful in some scenarios = and unnecessary in others. When unnecessary, as a user, I'd rather not = have to configure it. Kent // contributor --Apple-Mail=_3A928E5A-ABE8-447E-8BDC-B4438637F310 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Martin,


The = "tls-server-parameters" container defines the certificates used to
authenticate the client's cert.  In many deployments, = regardless how
the client cert is authenticated, the = "client-identification" section only
needs to explain how = to extract the "name" from the cert, a fingerprint
isn't = needed to identify either the client's end-entity or some
intermediate cert.

Ok.  To me this sounds like you need a more = complex^wsophisticated
client identification mechansim = than what a plain cert-to-name gives
you.  I don't = think there is anything wrong with the current
cert-to-name = grouping.  So let's continue this discussion in the
netconf ML, where this model is being developed.

In an attempt to resolve this = issue, I modified both ietf-netconf-server
and = ietf-restconf-server as follows:

OLD:
       uses = x509c2n:cert-to-name;

NEW:
=        uses x509c2n:cert-to-name {
         refine = "cert-to-name/fingerprint" {
=            mandator= y false;
=            descript= ion
=             &n= bsp;"A 'fingerprint' value does not need to be specified
=             &n= bsp; when the 'cert-to-name' mapping is independent of
= =             &n= bsp; fingerprint matching.  A 'cert-to-name' having no
=             &n= bsp; fingerprint value will match any client certificate
=             &n= bsp; and therefore should only be present at the end of
=             &n= bsp; the user-ordered 'cert-to-name' list.";
=          }
=        }
Did you see my email "client identification in = ietf-netconf-server"?
I don't think this refinement is the = correct solution.

Having replied to your other message, I still = don't understand this statement.  I understand the fingerprint = being useful in some scenarios and unnecessary in others.  When = unnecessary, as a user, I'd rather not have to configure = it.


Kent = // contributor


= --Apple-Mail=_3A928E5A-ABE8-447E-8BDC-B4438637F310-- From nobody Mon Nov 4 18:45:44 2019 Return-Path: <0100016e3974193b-284affdb-1b18-479d-b4d7-cdb7055708a0-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 32D3F12006B; Mon, 4 Nov 2019 18:45:43 -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 gNg6d2o6OcnK; Mon, 4 Nov 2019 18:45:41 -0800 (PST) Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3D0012004D; Mon, 4 Nov 2019 18:45:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1572921940; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=2hXXR/asJQHLDAujVE2w9u2s14ro9q1Oiu7FEvMOv/Q=; b=edNJl02FnStrVMzll0loQoei1vE/BSKY5gwqmYFq7dy7jVe4oqvV122XTqSw8oTN c0+jzqRUYKf9nRYkCJ/tV4BgvkTmQcColsL4ZtYwsSD50jH2A0l2PPkqel7skTJgPAy 0iqoNSdAKxp0oBkK9Gq2ESfmU2nK1gbnFGmVGeYQ= From: Kent Watsen Message-ID: <0100016e3974193b-284affdb-1b18-479d-b4d7-cdb7055708a0-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_EF4A5BD3-59CA-46CE-8093-F97EBD280CFB" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 5 Nov 2019 02:45:40 +0000 In-Reply-To: <20191104.155616.1730122739409524776.mbj@tail-f.com> Cc: Qin Wu , "netconf@ietf.org" , draft-ietf-netmod-factory-default@ietf.org To: Martin Bjorklund References: <20191104.155616.1730122739409524776.mbj@tail-f.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.11.05-54.240.8.96 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] WG Last Call: draft-ietf-netmod-factory-default-05 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, 05 Nov 2019 02:45:43 -0000 --Apple-Mail=_EF4A5BD3-59CA-46CE-8093-F97EBD280CFB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Qin, Martin, >>> But what does this actually mean? >>> [Qin]: It means the key word zero-touch comes from RFC8572. >>=20 >> I get that part. I was wondering about the meaning of the sentence. >> How can "reset" be used "during initial zero-touch configuration"? >>=20 >> [Qin]: I think "reset" can be used at the beginning of session setup = or in the middle of session when the existing configuration >> Has fatal error. >> Maybe change it into "before initial zero-touch configuration"? >=20 > I don't think this is correct; noone will invoke "factory-reset" > *before* the initial ztp -- rather, the factory default config will > contain config to enable ztp (see e.g. section A.1 in RFC 8572). > Perhaps simply remove this sentence? >=20 > Kent, do you have an opinion? For devices supporting ZTP, as you say, no one will invoke = "factory-reset" before the initial ZTP. This RPC can only, at best, = reenable ZTP as part of the reset operation. This seems obvious to me = (e.g., section A.1), but Joe felt that it would be helpful to call it = out. My only role in this was to craft the text that said it correctly. = As for if the sentence is better in or out, I hold no strong opinion, = but perceive two WG members having opposite opinions. Kent // contributor --Apple-Mail=_EF4A5BD3-59CA-46CE-8093-F97EBD280CFB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Qin, Martin,

 But what does this = actually mean?
[Qin]: It means the key word zero-touch = comes from RFC8572.

I get that = part.  I was wondering about the meaning of the sentence.
How can "reset" be used "during initial zero-touch = configuration"?

[Qin]: I think "reset" can = be used at the beginning of session setup or in the middle of session = when the existing configuration
Has fatal error.
Maybe change it into "before initial zero-touch = configuration"?

I don't think this is correct; noone will invoke = "factory-reset"
*before* the initial ztp -- rather, the factory default = config will
contain = config to enable ztp (see e.g. section A.1 in RFC 8572).
Perhaps = simply remove this sentence?

Kent, do you have an = opinion?

For devices supporting ZTP, as you say, = no one will invoke "factory-reset" before the initial ZTP.   = This RPC can only, at best, reenable ZTP as part of the reset operation. =   This seems obvious to me (e.g., section A.1), but Joe felt that = it would be helpful to call it out.  My only role in this was to = craft the text that said it correctly.  As for if the sentence is = better in or out, I hold no strong opinion, but perceive two WG members = having opposite opinions.

Kent // contributor


= --Apple-Mail=_EF4A5BD3-59CA-46CE-8093-F97EBD280CFB-- From nobody Mon Nov 4 19:23:38 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78AC2120073; Mon, 4 Nov 2019 19:23:36 -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 KUQHDm3yiPYl; Mon, 4 Nov 2019 19:23: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 18A7312002F; Mon, 4 Nov 2019 19:23:34 -0800 (PST) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id B14BA15D58E8C9BBE22D; Tue, 5 Nov 2019 03:23:31 +0000 (GMT) Received: from DGGEML422-HUB.china.huawei.com (10.1.199.39) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 5 Nov 2019 03:23:30 +0000 Received: from DGGEML531-MBS.china.huawei.com ([169.254.5.209]) by dggeml422-hub.china.huawei.com ([10.1.199.39]) with mapi id 14.03.0439.000; Tue, 5 Nov 2019 11:23:28 +0800 From: Qin Wu To: Kent Watsen , Martin Bjorklund CC: "netconf@ietf.org" , "draft-ietf-netmod-factory-default@ietf.org" Thread-Topic: [netconf] WG Last Call: draft-ietf-netmod-factory-default-05 Thread-Index: AdWTh7yGmdQMxpeCSNayhB4IIl3ujw== Date: Tue, 5 Nov 2019 03:23:27 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.31.203] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAA93E96B6dggeml531mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] WG Last Call: draft-ietf-netmod-factory-default-05 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, 05 Nov 2019 03:23:37 -0000 --_000_B8F9A780D330094D99AF023C5877DABAA93E96B6dggeml531mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 t6K8/sjLOiBLZW50IFdhdHNlbiBbbWFpbHRvOmtlbnQraWV0ZkB3YXRzZW4ubmV0XQ0Kt6LLzcqx vOQ6IDIwMTnE6jEx1MI1yNUgMTA6NDYNCsrVvP7IyzogTWFydGluIEJqb3JrbHVuZCA8bWJqQHRh aWwtZi5jb20+DQqzrcvNOiBRaW4gV3UgPGJpbGwud3VAaHVhd2VpLmNvbT47IG5ldGNvbmZAaWV0 Zi5vcmc7IGRyYWZ0LWlldGYtbmV0bW9kLWZhY3RvcnktZGVmYXVsdEBpZXRmLm9yZw0K1vfM4jog UmU6IFtuZXRjb25mXSBXRyBMYXN0IENhbGw6IGRyYWZ0LWlldGYtbmV0bW9kLWZhY3RvcnktZGVm YXVsdC0wNQ0KDQpRaW4sIE1hcnRpbiwNCg0KIEJ1dCB3aGF0IGRvZXMgdGhpcyBhY3R1YWxseSBt ZWFuPw0KW1Fpbl06IEl0IG1lYW5zIHRoZSBrZXkgd29yZCB6ZXJvLXRvdWNoIGNvbWVzIGZyb20g UkZDODU3Mi4NCg0KSSBnZXQgdGhhdCBwYXJ0LiAgSSB3YXMgd29uZGVyaW5nIGFib3V0IHRoZSBt ZWFuaW5nIG9mIHRoZSBzZW50ZW5jZS4NCkhvdyBjYW4gInJlc2V0IiBiZSB1c2VkICJkdXJpbmcg aW5pdGlhbCB6ZXJvLXRvdWNoIGNvbmZpZ3VyYXRpb24iPw0KDQpbUWluXTogSSB0aGluayAicmVz ZXQiIGNhbiBiZSB1c2VkIGF0IHRoZSBiZWdpbm5pbmcgb2Ygc2Vzc2lvbiBzZXR1cCBvciBpbiB0 aGUgbWlkZGxlIG9mIHNlc3Npb24gd2hlbiB0aGUgZXhpc3RpbmcgY29uZmlndXJhdGlvbg0KSGFz IGZhdGFsIGVycm9yLg0KTWF5YmUgY2hhbmdlIGl0IGludG8gImJlZm9yZSBpbml0aWFsIHplcm8t dG91Y2ggY29uZmlndXJhdGlvbiI/DQoNCkkgZG9uJ3QgdGhpbmsgdGhpcyBpcyBjb3JyZWN0OyBu b29uZSB3aWxsIGludm9rZSAiZmFjdG9yeS1yZXNldCINCipiZWZvcmUqIHRoZSBpbml0aWFsIHp0 cCAtLSByYXRoZXIsIHRoZSBmYWN0b3J5IGRlZmF1bHQgY29uZmlnIHdpbGwNCmNvbnRhaW4gY29u ZmlnIHRvIGVuYWJsZSB6dHAgKHNlZSBlLmcuIHNlY3Rpb24gQS4xIGluIFJGQyA4NTcyKS4NClBl cmhhcHMgc2ltcGx5IHJlbW92ZSB0aGlzIHNlbnRlbmNlPw0KDQpLZW50LCBkbyB5b3UgaGF2ZSBh biBvcGluaW9uPw0KDQpGb3IgZGV2aWNlcyBzdXBwb3J0aW5nIFpUUCwgYXMgeW91IHNheSwgbm8g b25lIHdpbGwgaW52b2tlICJmYWN0b3J5LXJlc2V0IiBiZWZvcmUgdGhlIGluaXRpYWwgWlRQLiAg IFRoaXMgUlBDIGNhbiBvbmx5LCBhdCBiZXN0LCByZWVuYWJsZSBaVFAgYXMgcGFydCBvZiB0aGUg cmVzZXQgb3BlcmF0aW9uLiAgIFRoaXMgc2VlbXMgb2J2aW91cyB0byBtZSAoZS5nLiwgc2VjdGlv biBBLjEpLCBidXQgSm9lIGZlbHQgdGhhdCBpdCB3b3VsZCBiZSBoZWxwZnVsIHRvIGNhbGwgaXQg b3V0LiAgTXkgb25seSByb2xlIGluIHRoaXMgd2FzIHRvIGNyYWZ0IHRoZSB0ZXh0IHRoYXQgc2Fp ZCBpdCBjb3JyZWN0bHkuICBBcyBmb3IgaWYgdGhlIHNlbnRlbmNlIGlzIGJldHRlciBpbiBvciBv dXQsIEkgaG9sZCBubyBzdHJvbmcgb3BpbmlvbiwgYnV0IHBlcmNlaXZlIHR3byBXRyBtZW1iZXJz IGhhdmluZyBvcHBvc2l0ZSBvcGluaW9ucy4NCg0KW1Fpbl06IFRoZSBxdWVzdGlvbiBpcyBzaG91 bGQgcnBjIG9yIGZhY3RvcnkgZGVmYXVsdCBjb25maWcgb3IgYm90aCBlbmFibGUgenRwPw0KSSB0 aGluayBkdXJpbmcgaW5pdGlhbCB6ZXJvLXRvdWNoIGNvbmZpZ3VyZSwgaXQgaXMgZmFjdG9yeSBk ZWZhdWx0IGNvbmZpZyB0byBlbmFibGUgenRwLg0KSW4gdGhlIG1pZGRsZSBvZiBzZXNzaW9uLCBy cGMgY2FuIGJlIHVzZWQgdG8gdHJpZ2dlciB6dHAgcHJvY2VzcyBleGVjdXRpb24uDQoNCktlbnQg Ly8gY29udHJpYnV0b3INCg0KDQo= --_000_B8F9A780D330094D99AF023C5877DABAA93E96B6dggeml531mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

=B7=A2=BC=FE=C8=CB: Kent Watsen [m= ailto:kent+ietf@watsen.net]
=B7=A2=CB=CD=CA=B1=BC=E4:<= /span> 2019=C4=EA11=D4=C25=C8=D5 10:46
=CA=D5=BC=FE=C8=CB: Martin Bjorklund <mbj@tail-f.com>
=B3=AD=CB=CD: Qin Wu <bill.wu@huawei.com>; netconf@ietf.org; draft-ietf-netmod-fa= ctory-default@ietf.org
=D6=F7=CC=E2: Re: [netconf] WG Last Call: draft-ietf-netmod-factory-default-05

 

Qin, Martin,<= /p>

 

 But what does this actually m= ean?
[Qin]: It means the key word zero-touch comes from RFC8572.


I get that part.  I was wondering about the meaning of the sentence. How can "reset" be used "during initial zero-touch configura= tion"?

[Qin]: I think "reset" can be used at the beginning of session se= tup or in the middle of session when the existing configuration
Has fatal error.
Maybe change it into "before initial zero-touch configuration"?


I don't think this is correct; noone will invoke "factory-reset"<= br> *before* the initial ztp -- rather, the factory default config will
contain config to enable ztp (see e.g. section A.1 in RFC 8572).
Perhaps simply remove this sentence?

Kent, do you have an opinion?=

 

For devices supporting ZTP, as = you say, no one will invoke "factory-reset" before the initi= al ZTP.   This RPC can only, at best, reenable ZTP as part of the rese= t operation.   This seems obvious to me (e.g., section A.1), but Joe felt that it would be helpful to call it out.  My only role i= n this was to craft the text that said it correctly.  As for if the se= ntence is better in or out, I hold no strong opinion, but perceive two WG m= embers having opposite opinions.

 

[Qin]: The question is= should rpc or factory default config or both enable ztp?

I think during initial= zero-touch configure, it is factory default config to enable ztp.

In the middle of sessi= on, rpc can be used to trigger ztp process execution.

 

Kent // contributor<= /span>

 

 

--_000_B8F9A780D330094D99AF023C5877DABAA93E96B6dggeml531mbschi_-- From nobody Tue Nov 5 01:02:46 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3185C120811 for ; Tue, 5 Nov 2019 01:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyXmi8Hva5w9 for ; Tue, 5 Nov 2019 01:02:42 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A508120810 for ; Tue, 5 Nov 2019 01:02:42 -0800 (PST) Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id C39A6D0C6D64E73F18B6 for ; Tue, 5 Nov 2019 09:02:40 +0000 (GMT) Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 5 Nov 2019 09:02:36 +0000 Received: from DGGEMM507-MBS.china.huawei.com ([169.254.3.2]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0439.000; Tue, 5 Nov 2019 17:02:21 +0800 From: wangzitao To: "netconf@ietf.org" Thread-Topic: New Version Notification for draft-wang-netconf-bulk-subscribed-notifications-00.txt Thread-Index: AdWTtshQDHncEyAIRtGsBePGIh9Z8w== Date: Tue, 5 Nov 2019 09:02:21 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.142.117] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] New Version Notification for draft-wang-netconf-bulk-subscribed-notifications-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2019 09:02:44 -0000 RGVhciBXRywNCg0KV2Ugc3VibWl0dGVkIGEgbmV3IGRyYWZ0OiAgaHR0cHM6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXdhbmctbmV0Y29uZi1idWxrLXN1YnNjcmliZWQtbm90 aWZpY2F0aW9ucy0wMC50eHQNCkluIHRoaXMgZG9jdW1lbnQsIHdlIGRlZmluZXMgYSB5YW5nIG1v ZGVsIGFuZCBhc3NvY2lhdGVkIG1lY2hhbmlzbSB0aGF0IGFsbG93cyB1c2VyIHRvIGJ1bGsgc3Vi c2NyaWJlIHRvIHB1Ymxpc2hlcidzIGV2ZW50IGJhc2VkIG9uIHRoZWlyIHJlcXVpcmVtZW50cyAu DQoNCk1vcmUgZGV0YWlscyBwbGVhc2UgcmV2aWV3IHRoZSBkcmFmdCwgY29tbWVudHMgYW5kIHN1 Z2dlc3Rpb25zIGFyZSB3ZWxjb21lIQ0KDQpCZXN0IFJlZ2FyZHMhDQotTWljaGFlbA0KDQoNCi0t LS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogaW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn IFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANCuWPkemAgeaXtumXtDogMjAxOeW5 tDEx5pyINOaXpSA5OjIzDQrmlLbku7bkuro6IHdhbmd6aXRhbyA8d2FuZ3ppdGFvQGh1YXdlaS5j b20+OyBRaW4gV3UgPGJpbGwud3VAaHVhd2VpLmNvbT47IHdhbmd6aXRhbyA8d2FuZ3ppdGFvQGh1 YXdlaS5jb20+OyBRaW4gV3UgPGJpbGwud3VAaHVhd2VpLmNvbT4NCuS4u+mimDogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC13YW5nLW5ldGNvbmYtYnVsay1zdWJzY3JpYmVkLW5v dGlmaWNhdGlvbnMtMDAudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXdhbmct bmV0Y29uZi1idWxrLXN1YnNjcmliZWQtbm90aWZpY2F0aW9ucy0wMC50eHQNCmhhcyBiZWVuIHN1 Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTWljaGFlbCBXYW5nIGFuZCBwb3N0ZWQgdG8gdGhlIElF VEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LXdhbmctbmV0Y29uZi1idWxrLXN1YnNjcmli ZWQtbm90aWZpY2F0aW9ucw0KUmV2aXNpb246CTAwDQpUaXRsZToJCUJ1bGsgU3Vic2NyaXB0aW9u IHRvIFlBTkcgRXZlbnQgTm90aWZpY2F0aW9uDQpEb2N1bWVudCBkYXRlOgkyMDE5LTExLTAzDQpH cm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkxMQ0KVVJMOiAgICAgICAgICAg IGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC13YW5nLW5ldGNvbmYt YnVsay1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMtMDAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd2FuZy1uZXRjb25mLWJ1bGstc3Vi c2NyaWJlZC1ub3RpZmljYXRpb25zLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC13YW5nLW5ldGNvbmYtYnVsay1zdWJzY3JpYmVkLW5vdGlmaWNhdGlv bnMtMDANCkh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9o dG1sL2RyYWZ0LXdhbmctbmV0Y29uZi1idWxrLXN1YnNjcmliZWQtbm90aWZpY2F0aW9ucw0KDQoN CkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgWUFORyBkYXRhIG1vZGVsIGFu ZCBhc3NvY2lhdGVkIG1lY2hhbmlzbSB0aGF0DQogICBhbGxvd3Mgc3Vic2NyaWJlciBhcHBsaWNh dGlvbnMgdG8gYnVsayBzdWJzY3JpYmUgdG8gcHVibGlzaGVycycgZXZlbnQNCiAgIHN0cmVhbXMg YmFzZWQgb24gdGhlaXIgcmVxdWlyZW1lbnRzLiAgQW5kIGl0IGFsc28gYWxsb3dzIHRoZQ0KICAg cHVibGlzaGVycyB0byByZXBvcnQgbXVsdGlwbGUgZXZlbnQgc3RyZWFtcyBvciBzdWJzY3JpcHRp b25zIGludG8gYQ0KICAgc2luZ2xlIG5vdGlmaWNhdGlvbiBtZXNzYWdlIGJhc2VkIG9uIGdyb3Vw IGlkZW50aWZpZXIgYWZmaWxpYXRpb24uDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0K DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0 aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm IGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0 DQoNCg== From nobody Tue Nov 5 03:44:36 2019 Return-Path: <0100016e3b61749d-22a2fb2c-fff3-4e5e-8944-396b9bd69317-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 A2E311208E6; Tue, 5 Nov 2019 03:44:35 -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, MIME_QP_LONG_LINE=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 CTwvclESbM-o; Tue, 5 Nov 2019 03:44:34 -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 73A881208ED; Tue, 5 Nov 2019 03:44:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1572954273; h=Content-Type:Content-Transfer-Encoding:From:Mime-Version:Subject:Date:Message-Id:References:Cc:In-Reply-To:To:Feedback-ID; bh=NIoo4fcFrMvuOTXkC0SbO8tY5+I8Or7Ks1pqCIuWjgk=; b=kPq2zMQcCYkhNzxdagu9jBemF6EhvotWzUWJAmktlnMicVUusrAJIe/CH++G7dCP tCeRGtKBh2AREp6RQye/FPeuFSoCmqDDcyeXcJAQt7Fsv2/nW+RYIWNmaWtMi2BZ2nI Kll/6ODY+ciygZ2d/KzAQSop2hHARfsh9OPPMHUA= Content-Type: multipart/alternative; boundary=Apple-Mail-B6144B69-3F66-4BCE-BF8F-E249ADAF1186 Content-Transfer-Encoding: 7bit From: Kent Watsen Mime-Version: 1.0 (1.0) Date: Tue, 5 Nov 2019 11:44:33 +0000 Message-ID: <0100016e3b61749d-22a2fb2c-fff3-4e5e-8944-396b9bd69317-000000@email.amazonses.com> References: Cc: Martin Bjorklund , "netconf@ietf.org" , "draft-ietf-netmod-factory-default@ietf.org" In-Reply-To: To: Qin Wu X-Mailer: iPhone Mail (17A878) X-SES-Outgoing: 2019.11.05-54.240.8.31 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] WG Last Call: draft-ietf-netmod-factory-default-05 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, 05 Nov 2019 11:44:36 -0000 --Apple-Mail-B6144B69-3F66-4BCE-BF8F-E249ADAF1186 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Qin, > [Qin]: The question is should rpc or factory default config or both enable= ztp? > I think during initial zero-touch configure, it is factory default config t= o enable ztp. > In the middle of session, rpc can be used to trigger ztp process execution= . The factory-default config enables ZTP. The RPC actives the factory-defaul= t config.=20 K. =20= --Apple-Mail-B6144B69-3F66-4BCE-BF8F-E249ADAF1186 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Qin,

<= div dir=3D"ltr">
[Qin]: Th= e question is should rpc or factory default config or both enable ztp?

I think during initial z= ero-touch configure, it is factory default config to enable ztp.<= /span>

In the middle of session= , rpc can be used to trigger ztp process execution.


The factory-default config enables ZTP.=  The RPC actives  the factory-default config. 

K.  
= --Apple-Mail-B6144B69-3F66-4BCE-BF8F-E249ADAF1186-- From nobody Tue Nov 5 06:50:22 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDB9A12082D for ; Tue, 5 Nov 2019 06:50:12 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 tm4NYvpC0NAF for ; Tue, 5 Nov 2019 06:50:10 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60062.outbound.protection.outlook.com [40.107.6.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 AB71512092D for ; Tue, 5 Nov 2019 06:42:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lTzbchOyyWBIk7zJrSoFle81RAbAZSdUekIKE0apRZETNfqcdM3xOCZ6PKhrXZ8+3tcOiElAve6ae8qVlmIarShPusCsXmli9rpTpuBHKw8wZ1MolwooLtUMqM/6gN2x6hd7HGb25rkvjG5nx7oJK8Xudv5PuPXjR/sxLBfVE6IIAxTjTQL/+MoPK/iCKpNHVCSufLIxHuiZ0Azz+IOYwfjObWPZMV3yPE0MuKEtAbJ1sH/Xc8Pgx5uvl6IwbsWyytTpINbaf1DJF/lr/R+F3w2qflFJbpMNpVPNnZxisJQkz0WfWPFk8LM6kvI7FXRV/slcRtvfXfe1I/dDUmnftQ== 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=lHDhPzwdPCB1meJyX9CTgCuLgxWWo4EyLrHh2pvmQ+s=; b=ILBlBZupxszKXROfL8vx2DtBQEE5dG7x9trtNVUUOorbzvs7n4TbiqkFx8iZuDjhZHtWRaHyJuf2128RqmHZgBz2Mx5YMxv2tE7MrV+UUId28Lrpa4TDnK/EQ51fLh7DhKDZPYAPEfjE35mYEBf4kJ3hGlCmjkmWAvsdcIGVfJdxIEZJqE9K+vwF9bFhgKsXPjrNe9qWvVw1gwlFxWRYKVmxA/ofn0KeJETTcXwaD4Rp3zCJhvZMo0xIytj2I4aw9cPPGzQYj5MMS6Kkc9/rbfbu4NJetxWuL/BEZGicO5h+ckN/diZwYwNYnLBNfECXKvJ2rdJbtMg8RmXV4oj4sg== 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=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lHDhPzwdPCB1meJyX9CTgCuLgxWWo4EyLrHh2pvmQ+s=; b=D9rWyh70ympKX45upQdttrFpStINgIgMC6YbFVpdnP5oywDduAFh1h/1KU7tKj+3Z8cwg0VDFUyl30d0kF8L56x9CT8CQaYw9QCI5MvhkC/vsuFYiVOhxqEqe9lNcwWsfDcy3qYasnnsw5zr0XbUhIsI5bKDuMit3hkXAwifEfc= Received: from AM7PR07MB6214.eurprd07.prod.outlook.com (10.186.170.77) by AM7PR07MB6453.eurprd07.prod.outlook.com (10.186.171.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.13; Tue, 5 Nov 2019 14:42:15 +0000 Received: from AM7PR07MB6214.eurprd07.prod.outlook.com ([fe80::3c4a:6fb:4b5a:8a]) by AM7PR07MB6214.eurprd07.prod.outlook.com ([fe80::3c4a:6fb:4b5a:8a%7]) with mapi id 15.20.2430.014; Tue, 5 Nov 2019 14:42:15 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: Kent Watsen CC: "Eric Voit (evoit)" , Mahesh Jethanandani , Alexander Clemm , Benoit Claise , "netconf@ietf.org" Thread-Topic: [netconf] WGLC for draft-ietf-netconf-notification-capabilities Thread-Index: AQHVaCiq/P3ytjAdYEi7Gp+LSYgUDqc7MLcAgAA5KYCAA/LsEIAFZuYAgARZyDCACYfTgIABFhoAgCMI5ICABjkt8A== Date: Tue, 5 Nov 2019 14:42:15 +0000 Message-ID: References: <4F49DF08-B7FC-4EBD-9D6B-7BC329E50334@gmail.com> <0100016d83c486c9-83aece79-684a-4999-b382-dd9c09f24c62-000000@email.amazonses.com> <0100016db140fe70-7564d937-87d1-450c-9267-2e1235e3fbb4-000000@email.amazonses.com> <0100016e279d85c9-ed769315-a2e4-4553-8819-81297009f2af-000000@email.amazonses.com> In-Reply-To: <0100016e279d85c9-ed769315-a2e4-4553-8819-81297009f2af-000000@email.amazonses.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: de872f8c-f22e-4d3f-ad7a-08d761fe59e1 x-ms-traffictypediagnostic: AM7PR07MB6453: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1247; x-forefront-prvs: 0212BDE3BE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(376002)(136003)(346002)(366004)(39860400002)(189003)(199004)(66556008)(66476007)(55016002)(66574012)(76116006)(85182001)(53546011)(71200400001)(3846002)(790700001)(86362001)(99936001)(2906002)(15650500001)(26005)(8936002)(186003)(6506007)(446003)(52536014)(229853002)(81156014)(81166006)(76176011)(2420400007)(74316002)(25786009)(486006)(5660300002)(33656002)(66066001)(99286004)(66446008)(6306002)(71190400001)(6436002)(6116002)(102836004)(256004)(7736002)(54906003)(11346002)(14444005)(7696005)(8676002)(85202003)(4326008)(7110500001)(14454004)(9686003)(54896002)(316002)(66616009)(476003)(64756008)(6246003)(478600001)(66946007); DIR:OUT; SFP:1101; SCL:1; SRVR:AM7PR07MB6453; H:AM7PR07MB6214.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: W3tBjg0NWv+x0aMj152eWfBvj8mDXE6yiiZEMQ5CFZ88OXlbJM9nwmxiQOQ2FiX7XqYk4KYoYFIOiUvXKUICFxLgRYxMBaZSzP84VXfova7hQD8Nd6AyBXcKHoNZJ6isCb9Th0m38CWAPALfgjnsig0aNEXuxyeqinIGhmlpQP+VhpIkgcBL1P8ZSpmgZf/oc9EPU2bTK/dz008VvlwxnbdakbUJzU+l4IYwnbxMrQJ7irdByT6eFKJsPeymvdDhJuNM46UwFJ51ikjCn8yU7eAGiQCOKlfeYnscDxqGNhR6e+CrdIPA1CrTh14YYF+oApvMK0ovu23dnx0f/bVLqo7X0haTC+CaUZph1cCJJIFNjDesc1Vhvt9XEuWo3SUfKjzktk+36DgwWoQFzSVpdPr4L5YpBSyP3pJOd76Zjx28LtTVfdQ+/+mN4TTv1ovY x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_076C_01D593EF.9836C250" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: de872f8c-f22e-4d3f-ad7a-08d761fe59e1 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2019 14:42:15.1275 (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: JzmmT+dnR8OV/C5+N9QvhBtPIuXBBtaK0fq+fo4G9IYESqHbj5aUv23/LsNWuFcucHacsBGDTFXjOqqMI+oB1l8VOKfqGbVqg91Gyoesfzc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6453 Archived-At: Subject: Re: [netconf] WGLC for draft-ietf-netconf-notification-capabilities 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, 05 Nov 2019 14:50:13 -0000 ------=_NextPart_000_076C_01D593EF.9836C250 Content-Type: multipart/alternative; boundary="----=_NextPart_001_076D_01D593EF.9836C250" ------=_NextPart_001_076D_01D593EF.9836C250 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Sorry for the missed updates. I corrected them. Balazs =20 From: Kent Watsen =20 Sent: 2019. november 1., p=C3=A9ntek 16:38 To: Bal=C3=A1zs Lengyel Cc: Eric Voit (evoit) ; Mahesh Jethanandani = ; Alexander Clemm ; Benoit = Claise ; netconf@ietf.org Subject: Re: [netconf] WGLC for = draft-ietf-netconf-notification-capabilities =20 Hi Balazs, =20 Hello, I added your comments to the upcoming next version of the draft. Regards Balazs =20 Your update missed a couple nits (see below). =20 Kent // contributor =20 =20 =20 =20 BALAZS2: OK, Updated with first part, but Rob has asked for an extra = sentence about the dangers of revealing read-only data, I added that = too. =E2=80=9CAll protocol-accessible data are read-only and cannot be = modified.=20 The data in this module is not security sensitive. Access control may be configured, to avoid exposing=20 the read-only data.=E2=80=9D Okay. s/protocol-accessible data/protocol-accessible data nodes/ BALAZS: OK, corrected. =20 =20 =20 BALAZS2: Agreed. This is part of normal file handling, transport. So I = reworded this to: =E2=80=9CWhen that data is in file format, data should be protected = against=20 modification or unauthorized access using normal file handling = and=20 secure and mutually authenticated file transport = mechanisms.=E2=80=9D =20 Okay. The end can be shortened, i.e., just "file handling mechanisms". BALAZS: OK, corrected. =20 Kent =20 ------=_NextPart_001_076D_01D593EF.9836C250 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Sorry for the missed updates. I corrected = them.

Balazs

 

From: Kent Watsen = <kent+ietf@watsen.net>
Sent: 2019. november 1., = p=C3=A9ntek 16:38
To: Bal=C3=A1zs Lengyel = <balazs.lengyel@ericsson.com>
Cc: Eric Voit (evoit) = <evoit@cisco.com>; Mahesh Jethanandani = <mjethanandani@gmail.com>; Alexander Clemm = <ludwig@clemm.org>; Benoit Claise <bclaise@cisco.com>; = netconf@ietf.org
Subject: Re: [netconf] WGLC for = draft-ietf-netconf-notification-capabilities

 

Hi = Balazs,

 

Hello,

I added =  your comments to the upcoming next version of the = draft.

Regards = Balazs

 

Your update missed a couple nits (see = below).

 

Kent // contributor

 

 

 

 

BALAZS2: OK, =  Updated with first part, but Rob has asked for an extra sentence = about the dangers of revealing read-only data, I added that = too.

=E2=80=9CAll protocol-accessible data are = read-only and cannot be modified. 

        T= he data in this module is not security = sensitive.

        = Access control may be configured, to avoid exposing 

        t= he read-only = data.=E2=80=9D

Okay. =  s/protocol-accessible data/protocol-accessible data = nodes/

BALAZS: OK, = corrected.

 

 

 



BALAZS2: Agreed. This is part of normal file = handling, transport. So I reworded this = to:

=E2=80=9CWhen that data is in file format, data = should be protected against 

        m= odification or unauthorized access using normal file handling and 

        s= ecure and mutually authenticated file transport = mechanisms.=E2=80=9D

<= p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <= /o:p>

Okay. =  The end can be shortened, i.e., just "file handling = mechanisms".

BALAZS: OK, = corrected.

 

Kent

 

------=_NextPart_001_076D_01D593EF.9836C250-- ------=_NextPart_000_076C_01D593EF.9836C250 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 DTE5MTEwNTE0NDIxM1owIwYJKoZIhvcNAQkEMRYEFKFWOV8roltRmNKZZj3OzW6GLcsCMEMGCSqG SIb3DQEJDzE2MDQwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG BSsOAwIaMGsGCSsGAQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8x ITBtBgsqhkiG9w0BCRACCzFeoFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITAN BgkqhkiG9w0BAQEFAASCAQBVCqfnCYfQKttt/NA9Tcb+WFGtl2IGeOyXZPLic2HWXMpOP1AZLeKZ jlZHCjYUsCnS6lzfJ9yLmz/XL38G6ypdQfWwMgn+R6nxGcSt2zGpVB4YFZ83PMTXO8D1WN0+MC7l 636N47+B83yenJ77oppBLeW2NGOqclYezwtcn7m7BfNWsoR7r1D0yTH4eFNFkQeTlceb2EX33qKG 3tdtVFRVNI31Nsbu6rg9Xw+0nABCqyuK76K6X3V587agjtjVPmK8cUMFXva51FP4rQdM8wdgPpn4 J2jYL57uMdCWoZsmlOiyKpUMltd/XrLgGFKgMAjqqIFcBX0V70mCYoe3PvgtAAAAAAAA ------=_NextPart_000_076C_01D593EF.9836C250-- From nobody Tue Nov 5 06:51:50 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83337120142; Tue, 5 Nov 2019 06:50:43 -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 XC6FLvTy_1rT; Tue, 5 Nov 2019 06:50:39 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30084.outbound.protection.outlook.com [40.107.3.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 575B112090B; Tue, 5 Nov 2019 06:38:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Haz0GM59/rRMOFoUNTDCWHBOUMaL1B2/RtuaCNKC+XOHjs+inbOi/QnN1bnU/PTiRN4ghHJWBdRAMuXB/xQHdNZr0Z0RtCOWUJqposYwWCcJN87Lal0u4GJOZlnH42J8t8NTLh/pOYTa0R2Uh+NqMEZ8TJsBJkL/dAE5OHIKxJvMgutAdKQWvILgkjuMGdxN1zvehT2EttM7s7M2bR9IuhmbO0BYxVT9CgeXVZuRw8n7VQNT5CYIuAFtGhfHh6c0FvLhAZXn0AEj9GP2Bl6k8iRRJAinCZ/BlkzJ1b+xyhpJZJF10Bga9Z9SqchmO+IVr4yGUHjTzAIyUrSjVVerKg== 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=/jMv4ihVkzY0uCxoPNMKImGEp1tD0g7hEBN+sZAk2hU=; b=MCirtAUfRfKUdhA9RspmKwQqTTTzUHBEODtSt2nwCy7145ZDmKlTTE5dls7SGzY8YkcWPbLxm/uxU7be0iwp4oeiomuwkAz9taZWQrMVmJD5H//FgoEYsu2oaZoJTxcnZtVx2Udxvq13zyDmQWdDVbEsJ0zsaJRntQNj2CeiIGqPZpPLrI6q64LnAwL3R6lzSVD9eJsyGYu76Rbmj38c1PdiMOcaKY/QfjMAJ++zqPIN1632HEIJZqAuGU3EBGsxMzF2YLHHqp98CNiyUSDhC44f7VIxXLt4BTT+wdRJZHZi+6xvcw6Uqfy0wBLiO0EjU0T2riI7ObB2SllTIB+rgA== 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=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/jMv4ihVkzY0uCxoPNMKImGEp1tD0g7hEBN+sZAk2hU=; b=f3upI8PnuxSdbaxZ6fstTM5VSlh9Tlwf/FQhK7I+cITWfnhfrJ4CQ2/XHqu3bqFakaNP46vpEpLPSUJYkuszzVnitd5JB44W/wRJGl2T0GzSkNtteSPxqucmuBRegFL6GVkrFBMKKRw9WQViMwkF8W2EdteD/dkLK0eufY+dkFA= Received: from AM7PR07MB6214.eurprd07.prod.outlook.com (10.186.170.77) by AM7PR07MB6453.eurprd07.prod.outlook.com (10.186.171.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.13; Tue, 5 Nov 2019 14:38:27 +0000 Received: from AM7PR07MB6214.eurprd07.prod.outlook.com ([fe80::3c4a:6fb:4b5a:8a]) by AM7PR07MB6214.eurprd07.prod.outlook.com ([fe80::3c4a:6fb:4b5a:8a%7]) with mapi id 15.20.2430.014; Tue, 5 Nov 2019 14:38:27 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: Ladislav Lhotka , "yang-doctors@ietf.org" CC: "last-call@ietf.org" , "netconf@ietf.org" , "draft-ietf-netconf-notification-capabilities.all@ietf.org" Thread-Topic: Yangdoctors last call review of draft-ietf-netconf-notification-capabilities-05 Thread-Index: AQHVjifxsBW2rOU/zkWUCQzU06Ifbqd63YyQ Date: Tue, 5 Nov 2019 14:38:27 +0000 Message-ID: References: <157233302184.6593.3869700028694968875@ietfa.amsl.com> In-Reply-To: <157233302184.6593.3869700028694968875@ietfa.amsl.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: 1147285a-9204-4ad5-c1a9-08d761fdd1eb x-ms-traffictypediagnostic: AM7PR07MB6453: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0212BDE3BE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(376002)(136003)(346002)(366004)(39860400002)(189003)(51914003)(199004)(13464003)(66556008)(66476007)(55016002)(66574012)(76116006)(85182001)(53546011)(71200400001)(3846002)(86362001)(99936001)(2906002)(15650500001)(26005)(305945005)(8936002)(186003)(6506007)(446003)(52536014)(229853002)(81156014)(81166006)(76176011)(110136005)(74316002)(25786009)(486006)(5660300002)(33656002)(66066001)(99286004)(66446008)(71190400001)(6436002)(6116002)(2501003)(102836004)(256004)(7736002)(54906003)(11346002)(14444005)(7696005)(8676002)(85202003)(4326008)(14454004)(9686003)(316002)(66616009)(476003)(64756008)(6246003)(478600001)(66946007); DIR:OUT; SFP:1101; SCL:1; SRVR:AM7PR07MB6453; H:AM7PR07MB6214.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: fZRy6PrUb/dq+L5flzGrTr+JUKp6Rq/dEaJcJ/V7bjTfE4hsRcQ6uzvjDY/UyFwdoXNIoFbmc6z+KGIoCudNn9qZHMcCjaCugJccQ/YeiRzKhCX4Cu4xq5Hv4WUkkfrM4j2XbU1L3hLNADgmT+t5Dr7G8yTQ0lLcriJV5YMCc6l8mp5MocXSaoirRlkTdRj0bOeFj+jEtBrKsUxqAcAaGuZvsPjfcrECgmY5ZeYZAUISRo8OXu3Cq9lVWXp5jAAWCrcP5URTf7Hk07rtDoWyXgEJoux+WKcueKteJJQ/kkVPyCCPlJYasoC1yEZdG8lac/wOzANU5pS0M5UHH1kg6dOnVu8OImo7aldR+Fp1KOkK4zjvcrHAtAGiHfOaHD0F0GHDDfPQG0YWfi3FQKP+V88bePpFpxtRmx5keIkOH+h1nZTmKW1H5HjvSgDVwSty x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0768_01D593EF.10227C60" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1147285a-9204-4ad5-c1a9-08d761fdd1eb X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2019 14:38:27.1677 (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: r9gqYNM4m/OUAZKx/Nqvh48LZ0NED11jBnF9y9GXmmCnbjHZ7tdo7FjvuprS+jxcHbqtItJbQ3YLovgWQk6KDKMCAczDFP4CTRwpTO3PFAM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6453 Archived-At: Subject: Re: [netconf] Yangdoctors last call review of draft-ietf-netconf-notification-capabilities-05 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, 05 Nov 2019 14:50:48 -0000 ------=_NextPart_000_0768_01D593EF.10227C60 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Lada, Thanks for the comments. See answers below. Regards Balazs -----Original Message----- From: Ladislav Lhotka via Datatracker =20 Sent: 2019. okt=C3=B3ber 29., kedd 8:10 To: yang-doctors@ietf.org Cc: last-call@ietf.org; netconf@ietf.org; = draft-ietf-netconf-notification-capabilities.all@ietf.org Subject: Yangdoctors last call review of = draft-ietf-netconf-notification-capabilities-05 Reviewer: Ladislav Lhotka Review result: Ready with Nits ***** Section 2. Introduction - Paragraph 3: the use of MAY is inappropriate: publishers indeed may have limitations, but this should follow from RFC 8641, and this document should take it as a fact. BALAZS: OK ***** Section 3. Notification Capability Model - The use of RFC 2119 terms is again questionable: I understand the ietf-notification-capabilities data as an optional aid for the implementors, but requiring that "The file SHALL be available in implementation time ..." is way too strict. BALAZS: OK, changed to SHOULD. Other reviewers wanted strong statements. ***** Section 3.2. YANG Module - This is one of the cases where it would be helpful to know which of the imported modules, such as ietf-netconf-acm, is also intended to be implemented. This may be addressed in a future YANG version (see issue #95 in yang-next), until then I would suggest to include YANG library data describing a minimum implementation. BALAZS: OK. Yes, it would be useful information. I added it as a = description substatement to import. =20 ***** Appendix A. Instance data examples - Example in Fig. 2: the element has an incorrect XML namespace (of the ietf-datastores module). BALAZS: I don't understand the comment; I don't see the error. Could you = please advise me what you think should be there? Exactly where?=20 - Many enum values are invalid because they contain leading/trailing whitespace. It would be better to encode the examples in JSON. BALAZS: I would like to keep the examples as they are. In many previous RFCs lines in XML examples were broken into multiple = lines. E.g.=20 RFC7950 7.16.3 rfc8341 A.4 rfc8641 4.4.1 rfc6022 4.1 rfc8525 B rfc8072 A.1.1 rfc6243 A.3.1 IMHO it is readable. It is better to use longer descriptive names in = YANG, then to use short names just to avoid long lines in XML examples. ------=_NextPart_000_0768_01D593EF.10227C60 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 DTE5MTEwNTE0MzgyNVowIwYJKoZIhvcNAQkEMRYEFIO0AcLeTReXH6P4FfAUhdEgsQv/MEMGCSqG SIb3DQEJDzE2MDQwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG BSsOAwIaMGsGCSsGAQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8x ITBtBgsqhkiG9w0BCRACCzFeoFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITAN BgkqhkiG9w0BAQEFAASCAQCCut6//BBehhry5LycIOW4eVL9T1gruqVtG0sjux/fz54L6RbpUf2X We1Qpx19y6Jg6TYEJHC8gCf3qgjj0qdQvxSxrx58qZoYyQ0kZl3eu56O5J07Mpjc3BgvsGMD4tWv oszn3S+931OPRQcjYaYKunP27gOQ2bfBuiW4zYgxAkBNppecdvD9Q8ej5BeZtttIG4OMLv+a9pvI w35bcFkNjpuTLXnpoO9Hw80kKMMKyxmlzjyqqEfUd8m1yCdcWyO0KWku+2FQYfUxZWZ+cwZSlS8o Q780eRGK9Z4RS7e/yPzBb2ICyEGgzRMjpGNmSpe6cZMJp3ulyy3SceyWnfCCAAAAAAAA ------=_NextPart_000_0768_01D593EF.10227C60-- From nobody Tue Nov 5 06:52:15 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6856F120BE5; Tue, 5 Nov 2019 06:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KA-C19GISs6n; Tue, 5 Nov 2019 06:50:55 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 611FC12094D; Tue, 5 Nov 2019 06:46:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8880; q=dns/txt; s=iport; t=1572965167; x=1574174767; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=Ehsq5/SfL0rz5fErQ26R8tVnRcwQU0liZB1WRSGx0GI=; b=K5J+UNfE1dYsUHqn0s7dMsSSwHtoVShHgS1lE7vegYCL1UC/9TxhlEh2 JTUpDVz5ZAR800MA0tUgOdxm1YX601PJVny13neCVFIj3zpRskgtznAgB fGVJQUJctPizuZ1HVJTrZbjwLVAKX2SmSpZ+Eiq9pMbWEJVeTxcUVN5R3 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BWAAC+isFd/xbLJq1mGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBEQEBAQEBAQEBAQEBgX6BHFOBHVUgEiqNLId6JZMchiSBZwk?= =?us-ascii?q?BAQEMAQEjDAEBhEAChDI4EwIDCwEBBAEBAQIBBQRthTcMhVEBAQEBAy1HAwI?= =?us-ascii?q?QCxEEAQEvTwgGAQwGAgEBgx4BgncPrzKCJx+FL4MogUiBNowrgUA/gREnDIJ?= =?us-ascii?q?fPoJXCwKBLgESAYYNBI0EoHKCLocVhR+JAgYbgjxyhmmECotIjkOILogciRI?= =?us-ascii?q?CERWBaSJncTMaCBsVO4JsCUcRFIwNhUBAAzABj1SCMAEB?= X-IronPort-AV: E=Sophos; i="5.68,271,1569283200"; d="scan'208,217"; a="18785858" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Nov 2019 14:46:03 +0000 Received: from [10.228.43.44] ([10.228.43.44]) (authenticated bits=0) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPSA id xA5Ek1QQ027656 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NO); Tue, 5 Nov 2019 14:46:03 GMT To: =?UTF-8?Q?Bal=c3=a1zs_Lengyel?= , Kent Watsen , Alexander Clemm Cc: "draft-ietf-netconf-notification-capabilities@ietf.org" , "netconf@ietf.org" References: <0100016e27a2d317-26951a3f-fcbf-4d15-939c-ab060aa9a337-000000@email.amazonses.com> From: Benoit Claise Message-ID: <1b2e930f-f654-5567-f89f-a5ba8fca8b27@cisco.com> Date: Tue, 5 Nov 2019 15:46:01 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5736756A9E4284D88897F8BC" Content-Language: en-US X-Authenticated-User: bclaise X-Outbound-SMTP-Client: 10.228.43.44, [10.228.43.44] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [netconf] IPR poll on draft-ietf-netconf-notification-capabilities-05 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, 05 Nov 2019 14:51:00 -0000 This is a multi-part message in MIME format. --------------5736756A9E4284D88897F8BC Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit "No, I'm not aware of any IPR that applies to this draft" Regards, B. > "No, I'm not aware of any IPR that applies to this draft" > > Regards Balazs > > *From:* Kent Watsen > *Sent:* 2019. november 1., péntek 16:44 > *To:* Balázs Lengyel ; Alexander Clemm > ; Benoit Claise > *Cc:* draft-ietf-netconf-notification-capabilities@ietf.org; > netconf@ietf.org > *Subject:* IPR poll on draft-ietf-netconf-notification-capabilities-05 > > To each author listed on the "To" line. > > In order to complete the Shepherd writeup, are you aware of any IPR > that applies > to draft-ietf-netconf-notification-capabilities-05?  Please Reply-All > to *this* email > > and state either: > > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > > If "yes", has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3669, 5378 and 8179 for more details)? > > If "yes" again, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think > appropriate. > > If you are listed as a document author or contributor please answer > the above by > responding to this email regardless of whether or not you are aware of > any relevant > IPR.  This document will not advance to the next stage until a > response has been > received from each author and listed contributor.  NOTE: THIS APPLIES > TO ALL > OF YOU LISTED IN THIS MESSAGE'S TO LINES. > > If you are on the WG email list or attend WG meetings but are not > listed as an author > or contributor, we remind you of your obligations under the IETF IPR > rules which > encourages you to notify the IETF if you are aware of IPR of others on > an IETF > contribution, or to refrain from participating in any contribution or > discussion related > to your undisclosed IPR. For more information, please see the RFCs > listed above > and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > > Thank you, > Kent // as both Shepherd and co-Chair > --------------5736756A9E4284D88897F8BC Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

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


Regards, B.

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

Regards Balazs

 

From: Kent Watsen <kent+ietf@watsen.net>
Sent: 2019. november 1., péntek 16:44
To: Balázs Lengyel <balazs.lengyel@ericsson.com>; Alexander Clemm <ludwig@clemm.org>; Benoit Claise <bclaise@cisco.com>
Cc: draft-ietf-netconf-notification-capabilities@ietf.org; netconf@ietf.org
Subject: IPR poll on draft-ietf-netconf-notification-capabilities-05

 

To each author listed on the "To" line.

In order to complete the Shepherd writeup, are you aware of any IPR that applies
to draft-ietf-netconf-notification-capabilities-05?  Please Reply-All to *this* email

and state either:

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

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

If "yes" again, please state either:

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

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

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

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

Thank you,
Kent // as both Shepherd and co-Chair


--------------5736756A9E4284D88897F8BC-- From nobody Tue Nov 5 06:53:10 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 612D2120D85; Tue, 5 Nov 2019 06:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 GfHttqGwc-dV; Tue, 5 Nov 2019 06:51:20 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60085.outbound.protection.outlook.com [40.107.6.85]) (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 75D83120931; Tue, 5 Nov 2019 06:43:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UKzW6MKBtm5O6yPih62YZsiUOhqcCPtkjdOIf00TtXdH3U7GfCEGTjY+R7/SpXwsxaq5MAetv7bvjHJMYnnEScUUDksljvFKCe2mOsjcU0Jw7+hEPLv9LqscRVpsYWEpI6WFZ9Rh5ZG0Fw3fOaRtXYm9Cyf63MO5NtpBnRxmACUrZAXcCIdwD6X+mYG9sBhbrpHL2O1O89IJYjwByAp4p8fRV0WA4GkokC+trbUDzJkR/P1yPZ8bhNAdFgwITHOBb7jFGQ6Mv94ofWN9mSZECYH1YdIUCNvWjDv2XSKsSAP1oo2QsVaW6UqzHOJ/jHAi9g1I0ft+IspvQFKtrVJ7Mw== 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=ECVx3RaG8xiFO+/4EXqREikeIsbbYYhfOW0OFZ+YsT8=; b=QNkAkN5JKP1PiaQXZFQ/IhcvT+FOJc2A7dPOdd2oFdQo+tQ5tQgPZy5jpaZZ2vuM8z2eGvj9xGscs9UYB8Gzf+HJfjtQva1TK/Od6w5F0j4ZteGMlFkeUdRfMt5E+d/rbH4NOO1vbKqbVpAjO0GoPdk1ZeVLSNGscnM825VJab4RqD9qSX+ME1MoKRueBO9F14vUgA+D7RpX8ywaOZHhIIowS9M9GT9vdYOd70QIc1NmyhGCx5QyvP7al9vv8tCTwAMOCM1wOt11xx52SE8K1Lw8SNft93mNrmuWqxwN/Y0sZbc308ZGRutFoF8g9fJbN0Z4Hi72v43UmRF6GCHt5A== 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=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ECVx3RaG8xiFO+/4EXqREikeIsbbYYhfOW0OFZ+YsT8=; b=I+Lt+qdIHePjKAduD9r64P4v47F2FpenpEpr61FtHsEvbjCUwiAnfQoLckP7QRya2BZrRGTuuXRyLw4nP4uSLa0pi6q9BYuvjhic98aNVHbCu3Pn9FHa9/kUXRk9muBw73fz+HbBmk4U0Ky1c/GhsrXJBLJfLskCqR2HivMN2y4= Received: from AM7PR07MB6214.eurprd07.prod.outlook.com (10.186.170.77) by AM7PR07MB6453.eurprd07.prod.outlook.com (10.186.171.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.13; Tue, 5 Nov 2019 14:43:17 +0000 Received: from AM7PR07MB6214.eurprd07.prod.outlook.com ([fe80::3c4a:6fb:4b5a:8a]) by AM7PR07MB6214.eurprd07.prod.outlook.com ([fe80::3c4a:6fb:4b5a:8a%7]) with mapi id 15.20.2430.014; Tue, 5 Nov 2019 14:43:17 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Lengyel?= To: Kent Watsen , Alexander Clemm , Benoit Claise CC: "draft-ietf-netconf-notification-capabilities@ietf.org" , "netconf@ietf.org" Thread-Topic: IPR poll on draft-ietf-netconf-notification-capabilities-05 Thread-Index: AQHVkMsk8opabM1K2EW3faNx/VocNKd8rQmg Date: Tue, 5 Nov 2019 14:43:17 +0000 Message-ID: References: <0100016e27a2d317-26951a3f-fcbf-4d15-939c-ab060aa9a337-000000@email.amazonses.com> In-Reply-To: <0100016e27a2d317-26951a3f-fcbf-4d15-939c-ab060aa9a337-000000@email.amazonses.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: 5b750af2-895a-4283-67e2-08d761fe7ef1 x-ms-traffictypediagnostic: AM7PR07MB6453: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 0212BDE3BE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(376002)(136003)(346002)(366004)(39860400002)(189003)(199004)(66556008)(66476007)(55016002)(66574012)(76116006)(53546011)(71200400001)(3846002)(790700001)(86362001)(99936001)(2906002)(15650500001)(26005)(45776006)(8936002)(186003)(6506007)(446003)(52536014)(229853002)(81156014)(81166006)(76176011)(2420400007)(110136005)(74316002)(25786009)(486006)(5660300002)(33656002)(66066001)(99286004)(66446008)(6306002)(71190400001)(6436002)(6116002)(102836004)(256004)(7736002)(54906003)(11346002)(14444005)(7696005)(8676002)(4326008)(966005)(7110500001)(606006)(14454004)(9686003)(54896002)(316002)(66616009)(476003)(64756008)(236005)(6246003)(478600001)(66946007); DIR:OUT; SFP:1101; SCL:1; SRVR:AM7PR07MB6453; H:AM7PR07MB6214.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: RHbUvpQAI6JTCgAwnrAPzQ1/RXHwCvEHURGvfsr+fnvGulB26+xjJRq/FeBamwUGZ4pWUFAREdizs2QDX9btONBAXs/c73o1q5CxSMNWyM4Iy6t8oaP885oapyudYT8wZjtm3G1HxX9UUwXZX7Izkp3HHDN1fG5js9KKJPegUTZ5w+4aykMI44N+40t7cMfyf7Wx0nad0Hhgvau/RsEFF6uszerYIhrqCxxh6FfUrm5iwCQ17upsWM7QE/7wlAEUGwNSD+B9HaRsEdl/xYtyXWzL/1xcp32gCYZaMBs9qfwN1yF12MbkQEjdFNAdTfcCWPcMWpqT1ER3OS/VYd34gmaWP4XHHZg2l/adOymRO24Jy8EkR3CWa9eEdDhL8y9HC0DW1aupXwfFkPHcwuR/+/gd9w1UnDtnqUA6cLlbZFaoFHyoghUSKNNUDf3PoERG x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0773_01D593EF.BCFFB880" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5b750af2-895a-4283-67e2-08d761fe7ef1 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2019 14:43:17.3939 (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: kuQAOmhOrZWT4QVmFfq2ammxhJUKu+k8yXhF/79CCegV2xIBtDRrl6/zWb5Tbmh7MhyHq8ExrlHdoR49XlNNfRQ+AVeegMCKX7inPaN/NRE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6453 Archived-At: Subject: Re: [netconf] IPR poll on draft-ietf-netconf-notification-capabilities-05 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, 05 Nov 2019 14:51:28 -0000 ------=_NextPart_000_0773_01D593EF.BCFFB880 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0774_01D593EF.BCFFB880" ------=_NextPart_001_0774_01D593EF.BCFFB880 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable "No, I'm not aware of any IPR that applies to this draft" Regards Balazs =20 From: Kent Watsen =20 Sent: 2019. november 1., p=E9ntek 16:44 To: Bal=E1zs Lengyel ; Alexander Clemm ; Benoit Claise Cc: draft-ietf-netconf-notification-capabilities@ietf.org; = netconf@ietf.org Subject: IPR poll on draft-ietf-netconf-notification-capabilities-05 =20 To each author listed on the "To" line. In order to complete the Shepherd writeup, are you aware of any IPR that applies to draft-ietf-netconf-notification-capabilities-05? Please Reply-All to *this* email and state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If "yes", has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3669, 5378 and 8179 for more details)? If "yes" again, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of = any relevant IPR. This document will not advance to the next stage until a response = has been received from each author and listed contributor. NOTE: THIS APPLIES TO = ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the WG email list or attend WG meetings but are not listed = as an author or contributor, we remind you of your obligations under the IETF IPR = rules which encourages you to notify the IETF if you are aware of IPR of others on = an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs = listed above and = http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, Kent // as both Shepherd and co-Chair ------=_NextPart_001_0774_01D593EF.BCFFB880 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

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

Regards = Balazs

 

From: Kent Watsen = <kent+ietf@watsen.net>
Sent: 2019. november 1., = p=E9ntek 16:44
To: Bal=E1zs Lengyel = <balazs.lengyel@ericsson.com>; Alexander Clemm = <ludwig@clemm.org>; Benoit Claise = <bclaise@cisco.com>
Cc: = draft-ietf-netconf-notification-capabilities@ietf.org; = netconf@ietf.org
Subject: IPR poll on = draft-ietf-netconf-notification-capabilities-05

 

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

In order to complete = the Shepherd writeup, are you aware of any IPR that applies
to = draft-ietf-netconf-notification-capabilities-05?  Please Reply-All = to *this* email

and state = either:

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

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

If "yes" again, please state = either:

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

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

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

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

Thank you,
Kent // as both Shepherd and = co-Chair

------=_NextPart_001_0774_01D593EF.BCFFB880-- ------=_NextPart_000_0773_01D593EF.BCFFB880 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 DTE5MTEwNTE0NDMxNVowIwYJKoZIhvcNAQkEMRYEFHbhMFG6NG7fH6B0Lz4It+dkeMBSMEMGCSqG SIb3DQEJDzE2MDQwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG BSsOAwIaMGsGCSsGAQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8x ITBtBgsqhkiG9w0BCRACCzFeoFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITAN BgkqhkiG9w0BAQEFAASCAQB5Uae+LgPiJu4TVcP0CP9wjDCvSRgqzvvvMWNH7k30S8UhfniO5XBF CjAhbCSzu7d7aJG4S58Va8bTqJ5EYZEiVMV/TJv6oqndwBY5aTZKjAZlI3/YfOIOgxU36DISHPmp jBAQwEFnSNXAgSj6Tyd5QWH42wVfq368eJgM70c/5ESOGaP567WF44oayc9rFsmqbXh9jYJ61XMl ON+1ZIVbLiAtKMJW/5rttPBJjt1OhiR3e/RKMwpxIG1lJTaEso7lyapDb9FH1cnPk+ODCHwx0qOH twYCW1yl0MyRUkVAbiAnrKN90+NRF6x4HCANFQfpH8oQKMeMiv1rlYrFmHr1AAAAAAAA ------=_NextPart_000_0773_01D593EF.BCFFB880-- From nobody Tue Nov 5 07:15:19 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3FDF120116; Tue, 5 Nov 2019 07:15:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHKMbonewJA1; Tue, 5 Nov 2019 07:14:53 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10082.outbound.protection.outlook.com [40.107.1.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 891CD1200C3; Tue, 5 Nov 2019 07:14:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=C2qWy6hj04CQSoTmOjnZ7yk6mKk5JiFd26yzoBD595wSZNwNSjGDnOKzZuAMm4Nx+qb9w1AYfGjJTPWujzMx2/ugPJ5LbO3i4zM93TdaRn/M35BY5fni9PwwE0sgIiqBJdXxzLEUrOa87pMjfKWNiQzhJEAD+5VSBtgXpwu/akms0ToYiY87fTOOgUTtgTu3OKuuVTZvAMTj62fA7tGsyJpo3BVRTN6QoV56HPiJKQCGiS8De0sWbUK0CuoNEusS0fkhoKB1O7U+FEGUaOxPbC8xI0XDzThUW1/iZEXIaLSQLXv5fBVppbc587aMj/54XyRnJNqsj3U2VZj6+eoE/w== 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=Rb0uqqQJBbJ84pzdLgn1So/IRHMeRZI/v9GbNDDOEZw=; b=GZ2CAfnDnox5e3erlkkwxgym1WNStcvWIkEzf/mPJE4N6vZ7NdenYhvdS/juwG0N8V3pOZYooKBokZA7bAKCFCV7+g+vQv+TdsYVf54O7mqULT+XgpHZRoOOayzBoa30V+Bbaj2FfDJeOgZXQUZ/5qFm2Cc5Qe6sl+m/xAyY0pCHU6uX+7KjTflBhWOpBPBK6qbOwixNhmumV8K/1EmwTJHuQhgW0otO6cJKLIH5OU49QJxBePH7urAxmYvD0P7vhmBvH8LKepkep1r3O6Gq5OH5rxcHc24B6JWrMFpec/M4OmSRhX40TIkMAO3xXRNgK+y6QJESwJ1w0nZbK+L9Rw== 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=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Rb0uqqQJBbJ84pzdLgn1So/IRHMeRZI/v9GbNDDOEZw=; b=F/zNq5bcDzDMFDMcSw53e4GwnXhJzNqHip/WgEuzbf1nwM3nEEDuFvbjvaS7jylbRTQ5xrOiJ2jYdW3zP/4aKCjMh5ldGIodPcDVSE13zNJ6LedICULcq9sxNUvCjx1A0KfDxvOtSgh3S/HYLX02BKyHuPJ6PXuKi3DkggMDFkU= Received: from AM7PR07MB6214.eurprd07.prod.outlook.com (10.186.170.77) by AM7PR07MB6326.eurprd07.prod.outlook.com (10.186.168.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.16; Tue, 5 Nov 2019 15:14:47 +0000 Received: from AM7PR07MB6214.eurprd07.prod.outlook.com ([fe80::3c4a:6fb:4b5a:8a]) by AM7PR07MB6214.eurprd07.prod.outlook.com ([fe80::3c4a:6fb:4b5a:8a%7]) with mapi id 15.20.2430.014; Tue, 5 Nov 2019 15:14:47 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Lengyel?= To: Kent Watsen , Ladislav Lhotka , "draft-ietf-netconf-notification-capabilities@ietf.org" CC: "netconf@ietf.org" , "Benoit Claise (bclaise@cisco.com)" , Alexander Clemm Thread-Topic: [netconf] Yangdoctors last call review of draft-ietf-netconf-notification-capabilities-05 Thread-Index: AQHVjifxsBW2rOU/zkWUCQzU06Ifbqd2eqYAgAY+8oA= Date: Tue, 5 Nov 2019 15:14:46 +0000 Message-ID: References: <157233302184.6593.3869700028694968875@ietfa.amsl.com> <0100016e27a53a56-4e90c30c-cf53-4df0-9cd7-8a5b5ce9b1ce-000000@email.amazonses.com> In-Reply-To: <0100016e27a53a56-4e90c30c-cf53-4df0-9cd7-8a5b5ce9b1ce-000000@email.amazonses.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: 53bb2e34-0567-46fd-8258-08d76202e524 x-ms-traffictypediagnostic: AM7PR07MB6326: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0212BDE3BE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39860400002)(346002)(366004)(376002)(136003)(189003)(199004)(102836004)(229853002)(64756008)(8676002)(66446008)(6246003)(9326002)(26005)(99286004)(71190400001)(81156014)(71200400001)(86362001)(81166006)(76176011)(5024004)(14444005)(256004)(6306002)(9686003)(55016002)(6436002)(54896002)(7696005)(66946007)(76116006)(25786009)(66574012)(66556008)(53546011)(7110500001)(8936002)(606006)(446003)(11346002)(790700001)(6116002)(3846002)(476003)(486006)(45776006)(66066001)(4326008)(66616009)(6506007)(52536014)(236005)(33656002)(66476007)(5660300002)(2906002)(15650500001)(2420400007)(74316002)(54906003)(7736002)(186003)(478600001)(316002)(2501003)(99936001)(110136005)(966005)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM7PR07MB6326; H:AM7PR07MB6214.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: PIKpCc5OsgsGdzImRLzex04vweg4LMWZPSsSvni6XSetJ2BZwzhVqiO7gwtGnhoLfyVwZc3ksiuY8zgtyCnWqRHw5ZeKO1cpytO8Qq374TywonIJOohNPPKVWKSGDDbq+xHIlxp8yMhGEqEgq8QJcACTnuCWTxkj+tKakHcsDEd665HN0hLssvbmfdP1LQHl5EGjtN+bVLwe541c6XL1M2Asto/1RpB1uNeYv+/anNFm/QhB/lQ4hmI8L0TijgeiEYXDJMMeLwYNkBHi2HeaLWU3NV08xMQdsUyKIkyvzGim/N43slWuj56euBXx2mnsbJH2U/tDeTs0jfS93FtGwjEPGpr1jrEh6uNtHUbfgmzZLm28swh1P48F6RNMCsLfHzsyT65d5qXr+ynFFlMaYOwvaQs/vu3PcILp8LCsctPh+z7w5EdY0C9LHb3wTDx1 x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0795_01D593F4.23478290" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 53bb2e34-0567-46fd-8258-08d76202e524 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2019 15:14:46.8503 (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: OGTJDscucDo8wX/4YGmg52hgR8KSnasdxpUA6AX27TmMVtvU1ufNMKYLRAtH3oEatdVQO4e8QngO6z5aKG7OR3aoL7kFfhkEyONWZXVTYIw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6326 Archived-At: Subject: Re: [netconf] Yangdoctors last call review of draft-ietf-netconf-notification-capabilities-05 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, 05 Nov 2019 15:15:03 -0000 ------=_NextPart_000_0795_01D593F4.23478290 Content-Type: multipart/mixed; boundary="----=_NextPart_001_0796_01D593F4.23478290" ------=_NextPart_001_0796_01D593F4.23478290 Content-Type: multipart/alternative; boundary="----=_NextPart_002_0797_01D593F4.23478290" ------=_NextPart_002_0797_01D593F4.23478290 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I have updated the draft, but missed the dead-line, so I can=92t upload = it. I will upload it when possible. I attached it to this mail. The changes are small, so I hope it is not a big problem. =20 I accepted + corrected all comments except 2 from Lada, which I do not = fully understand, as described in a reply to him. Regards Balazs =20 P.S. very busy with Yangifying 3GPP :-) =20 From: Kent Watsen =20 Sent: 2019. november 1., p=E9ntek 16:46 To: Ladislav Lhotka ; draft-ietf-netconf-notification-capabilities@ietf.org Cc: netconf@ietf.org Subject: Re: [netconf] Yangdoctors last call review of draft-ietf-netconf-notification-capabilities-05 =20 [moving yang-doctors to BCC] =20 =20 Thank you Lada. =20 Authors, please update the draft as needed to address these YANG Doctor comments. =20 Kent // as Shepherd =20 =20 =20 On Oct 29, 2019, at 3:10 AM, Ladislav Lhotka via Datatracker > wrote: =20 Reviewer: Ladislav Lhotka Review result: Ready with Nits ***** Section 2. Introduction - Paragraph 3: the use of MAY is inappropriate: publishers indeed may have limitations, but this should follow from RFC 8641, and this document should take it as a fact. ***** Section 3. Notification Capability Model - The use of RFC 2119 terms is again questionable: I understand the ietf-notification-capabilities data as an optional aid for the implementors, but requiring that "The file SHALL be available in implementation time ..." is way too strict. ***** Section 3.2. YANG Module - This is one of the cases where it would be helpful to know which of the imported modules, such as ietf-netconf-acm, is also intended to be implemented. This may be addressed in a future YANG version (see issue #95 in yang-next), until then I would suggest to include YANG library data describing a minimum implementation. ***** Appendix A. Instance data examples - Example in Fig. 2: the element has an incorrect XML namespace (of the ietf-datastores module). - Many enum values are invalid because they contain leading/trailing whitespace. It would be better to encode the examples in JSON. _______________________________________________ netconf mailing list netconf@ietf.org =20 https://www.ietf.org/mailman/listinfo/netconf =20 ------=_NextPart_002_0797_01D593F4.23478290 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

I have = updated the draft, but missed the dead-line, so I can’t upload it. = =A0I will upload it when possible. =A0I attached it to this = mail.

The changes are small, so I = hope it is not a big problem.

 

I accepted + = corrected all comments except 2 from Lada, which I do not fully = understand, as described in a reply to him.

Regards Balazs

 

P.S. very = busy with Yangifying 3GPP=A0 :-)

 

From: Kent Watsen = <kent@watsen.net>
Sent: 2019. november 1., p=E9ntek = 16:46
To: Ladislav Lhotka <lhotka@nic.cz>; = draft-ietf-netconf-notification-capabilities@ietf.org
Cc: = netconf@ietf.org
Subject: Re: [netconf] Yangdoctors last call = review of = draft-ietf-netconf-notification-capabilities-05

 

[moving = yang-doctors to BCC]

 

 

Thank you Lada.

 

Authors, please update the draft as needed to address = these YANG Doctor comments.

 

Kent // as Shepherd

 

 

 



On Oct 29, 2019, at 3:10 AM, Ladislav Lhotka via = Datatracker <noreply@ietf.org> = wrote:

 

Reviewer: Ladislav Lhotka
Review result: Ready with = Nits

***** Section 2. = Introduction
     - Paragraph 3: the use of = MAY is inappropriate: = publishers
       indeed may have = limitations, but this should follow from = RFC
       8641, and this document = should take it as a fact.
***** Section 3. Notification Capability = Model
     - The use of RFC 2119 terms is = again questionable: I = understand
       the = ietf-notification-capabilities data as an optional aid = for
       the implementors, but = requiring that "The file SHALL = be
       available in = implementation time ..." is way too strict.
***** Section 3.2. = YANG Module
     - This is one of the cases = where it would be helpful to = know
       which of the imported = modules, such as ietf-netconf-acm, = is
       also intended to be = implemented. This may be addressed in = a
       future YANG version (see = issue #95 in yang-next), until then = I
       would suggest to include = YANG library data describing = a
       minimum = implementation.
***** Appendix A. Instance data = examples
     - Example in Fig. 2: the = <datastore> element has an = incorrect
       XML namespace (of = the ietf-datastores module).
     - Many = enum values are invalid because they = contain
       leading/trailing = whitespace. It would be better to encode = the
       examples in = JSON.


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

 

------=_NextPart_002_0797_01D593F4.23478290-- ------=_NextPart_001_0796_01D593F4.23478290 Content-Type: text/plain; name="draft-ietf-netconf-notification-capabilities-06.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-netconf-notification-capabilities-06.txt" =0A= =0A= =0A= =0A= NETCONF B. Lengyel=0A= Internet-Draft Ericsson=0A= Intended status: Standards Track A. Clemm=0A= Expires: May 8, 2020 Futurewei=0A= B. Claise=0A= Cisco Systems, Inc.=0A= November 5, 2019=0A= =0A= =0A= YANG-Push Notification Capabilities=0A= draft-ietf-netconf-notification-capabilities-06=0A= =0A= Abstract=0A= =0A= This document proposes a YANG module that allows a publisher to=0A= specify capabilities related to "Subscription to YANG Datastores"=0A= (YANG-Push). It proposes to use YANG Instance Data to document this=0A= information and make it already available at implementation-time, but=0A= also allow it to be reported at run-time.=0A= =0A= Status of This Memo=0A= =0A= This Internet-Draft is submitted in full conformance with the=0A= provisions of BCP 78 and BCP 79.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF). Note that other groups may also distribute=0A= working documents as Internet-Drafts. The list of current Internet-=0A= Drafts is at https://datatracker.ietf.org/drafts/current/.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six months=0A= and may be updated, replaced, or obsoleted by other documents at any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= This Internet-Draft will expire on May 8, 2020.=0A= =0A= Copyright Notice=0A= =0A= Copyright (c) 2019 IETF Trust and the persons identified as the=0A= document authors. All rights reserved.=0A= =0A= This document is subject to BCP 78 and the IETF Trust's Legal=0A= Provisions Relating to IETF Documents=0A= (https://trustee.ietf.org/license-info) in effect on the date of=0A= publication of this document. Please review these documents=0A= carefully, as they describe your rights and restrictions with respect=0A= to this document. Code Components extracted from this document must=0A= =0A= =0A= =0A= Lengyel, et al. Expires May 8, 2020 [Page 1]=0A= =0C=0A= Internet-Draft YANG-Push Notification Capabilities November 2019=0A= =0A= =0A= include Simplified BSD License text as described in Section 4.e of=0A= the Trust Legal Provisions and are provided without warranty as=0A= described in the Simplified BSD License.=0A= =0A= Table of Contents=0A= =0A= 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2=0A= 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 3. Notification Capability Model . . . . . . . . . . . . . . . . 5=0A= 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 6=0A= 3.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 6=0A= 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12=0A= 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13=0A= 5.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 13=0A= 5.2. The YANG Module Names Registry . . . . . . . . . . . . . 13=0A= 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13=0A= 6.1. Normative References . . . . . . . . . . . . . . . . . . 13=0A= 6.2. Informative References . . . . . . . . . . . . . . . . . 14=0A= Appendix A. Instance data examples . . . . . . . . . . . . . . . 14=0A= Appendix B. Changes between revisions . . . . . . . . . . . . . 17=0A= Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18=0A= =0A= 1. Terminology=0A= =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and=0A= "OPTIONAL" in this document are to be interpreted as described in BCP=0A= 14 [RFC2119] [RFC8174] when, and only when, they appear in all=0A= capitals, as shown here.=0A= =0A= The terms YANG-Push, On-change subscription and Periodic subscription=0A= are used as defined in [RFC8641]=0A= =0A= The terms Subscriber, Publisher and Receiver are used as defined in=0A= [RFC8639]=0A= =0A= On-change Notification Capability: The capability of the publisher to=0A= send on-change notifications for a specific datastore or a specific=0A= data node.=0A= =0A= The term Server is used as defined in [RFC8342]=0A= =0A= Implementation-time information: Information about the publisher's=0A= behavior that is made available during the implementation of the=0A= publisher, available from a source other then a running server=0A= implementing the publisher.=0A= =0A= =0A= =0A= =0A= =0A= Lengyel, et al. Expires May 8, 2020 [Page 2]=0A= =0C=0A= Internet-Draft YANG-Push Notification Capabilities November 2019=0A= =0A= =0A= Run-time information: Information about the publisher's behavior that=0A= is available from the running server (implementing the publisher) via=0A= management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040].=0A= =0A= 2. Introduction=0A= =0A= As defined in [RFC8641] a publisher may allow subscribers to=0A= subscribe to updates from a datastore and subsequently push such=0A= update notifications to the receiver. Notifications may be sent=0A= periodically or on-change (more or less immediately after each=0A= change).=0A= =0A= A publisher supporting YANG-Push has a number of capabilities defined=0A= in [RFC8641] that are often determined during the implementation of=0A= the publisher. These include:=0A= =0A= o Supported (reporting) periods for periodic subscriptions=0A= =0A= o Maximum number of objects that can be sent in an update=0A= =0A= o The set of datastores or data nodes for which periodic=0A= notification is supported=0A= =0A= If the optional on-change feature is supported, additionally:=0A= =0A= o Supported dampening periods for on-change subscriptions=0A= =0A= o The set of datastores or data nodes for which on-change=0A= notification is supported=0A= =0A= Publishers have limitations in how many update notifications and how=0A= many datastore node updates they can send out in a certain time-=0A= period.=0A= =0A= Publishers might not support periodic subscriptions to all=0A= datastores.=0A= =0A= In some cases, a publisher supporting on-change notifications will=0A= not be able to push updates for some object types on-change. Reasons=0A= for this might be that the value of the datastore node changes=0A= frequently (e.g. in-octets counter), that small object changes are=0A= frequent and irrelevant to the receiver (e.g., a temperature gauge=0A= changing 0.1 degrees within a predetermined and acceptable range), or=0A= that the implementation is not capable of on-change notification for=0A= a particular object. In those cases, it will be important for=0A= subscriber applications to have a way to identify which objects on-=0A= change notifications are supported and for which ones not.=0A= =0A= =0A= =0A= =0A= Lengyel, et al. Expires May 8, 2020 [Page 3]=0A= =0C=0A= Internet-Draft YANG-Push Notification Capabilities November 2019=0A= =0A= =0A= Faced with the reality that support for on-change notification does=0A= not mean that such notifications will be sent for any specific data=0A= node, subscriber/management applications can not rely on the on-=0A= change functionality unless the subscriber has some means to identify=0A= which objects on-change notifications are supported. YANG models are=0A= meant to be used as an interface contract. Without identification of=0A= the data nodes actually supporting on-change, this contract would be=0A= incomplete.=0A= =0A= This document proposes a YANG module that allows a subscriber to=0A= discover YANG-Push related capabilities both at implementation-time=0A= and run-time.=0A= =0A= Implementation-time information is needed by Network Management=0A= System (NMS) implementers. A NMS implementation that wants to=0A= support notifications, needs the information about on-change=0A= notification capability. If the information is not documented in a=0A= way available to the NMS designer, but only as instance data from the=0A= network node once it is deployed, the NMS implementation will be=0A= delayed, because it has to wait for the network node to be ready. In=0A= addition, the assumption that all NMS implementers will have a=0A= correctly configured network node available to retrieve data from is=0A= an expensive proposition and may not always hold. (An NMS may need=0A= to be able to handle many dozens of network node types.) Often a=0A= fully functional NMS is a requirement for introducing a new network=0A= node type into a network, so delaying NMS readiness effectively also=0A= delays the time at which a new network node type can be introduced=0A= into the network.=0A= =0A= Implementation-time information is needed by system integrators.=0A= When introducing a network node type into their network, operators=0A= often need to integrate the node type into their own management=0A= system. The NMS may have management functions that depend on on-=0A= change notifications. The network operator needs to plan his=0A= management practices and NMS implementation before he even decides to=0A= buy the specific network node type. Moreover the decision to buy the=0A= node type sometimes depends on these management possibilities.=0A= =0A= Run-time information is needed:=0A= =0A= o for any "purely model driven" application, e.g. a NETCONF-browser.=0A= Such applications depend on reading models, capabilities in run-=0A= time to support all the publisher's available functionality.=0A= =0A= o in case the capability might change during run-time e.g. due to=0A= licensing, HW constraints etc.=0A= =0A= =0A= =0A= =0A= =0A= Lengyel, et al. Expires May 8, 2020 [Page 4]=0A= =0C=0A= Internet-Draft YANG-Push Notification Capabilities November 2019=0A= =0A= =0A= o to check that capability information provided early, already in=0A= implementation-time is indeed what the publisher implements (is=0A= the supplied documentation correct?)=0A= =0A= 3. Notification Capability Model=0A= =0A= It is a goal to provide YANG-Push notification capability information=0A= in a format that is:=0A= =0A= o vendor independent=0A= =0A= o machine readable=0A= =0A= o identical for implementation-time and run-time=0A= =0A= The YANG module ietf-notification-capabilities is defined to provide=0A= the information. It contains:=0A= =0A= o a set of capabilities related to the throughput of notification=0A= data the publisher can send out=0A= =0A= o specification of which data nodes support on-change notifications.=0A= =0A= Capability values can be specified on publisher level, datastore=0A= level or on specific data nodes (and their contained sub-tree) of a=0A= specific datastore. Capability values on a smaller, more specific=0A= part of the publisher's data always override more generic values.=0A= =0A= On-change capability is not specified on a publisher level as=0A= different datastores usually have different on-change capabilities.=0A= On a datastore level on-change capability for configuration and state=0A= data can be specified separately.=0A= =0A= The information SHOULD be provided in two ways both following the=0A= ietf-notification-capabilities module:=0A= =0A= o For the implementation-time use-case: It SHOULD be provided by the=0A= implementer as YANG instance data file complying to=0A= [I-D.ietf-netmod-yang-instance-file-format]. The file SHALL be=0A= available already in implementation-time retrievable in a way that=0A= does not depend on a live network node. E.g. download from=0A= product Website.=0A= =0A= o For the run-time use-case: It SHOULD be available via NETCONF=0A= [RFC6241] or RESTCONF [RFC8040] from the live server (implementing=0A= the publisher) during run-time. Implementations which support=0A= changing these capabilities at run-time SHOULD support on-change=0A= =0A= =0A= =0A= =0A= Lengyel, et al. Expires May 8, 2020 [Page 5]=0A= =0C=0A= Internet-Draft YANG-Push Notification Capabilities November 2019=0A= =0A= =0A= notifications about the publisher-subscription-capabilities=0A= container.=0A= =0A= 3.1. Tree Diagram=0A= =0A= The following tree diagram [RFC8340] provides an overview of the data=0A= model.=0A= =0A= module: ietf-notification-capabilities=0A= +--ro publisher-subscription-capabilities=0A= +--ro (update-period)?=0A= | +--:(minimum-update-period)=0A= | | +--ro minimum-update-period? uint32=0A= | +--:(supported-update-period)=0A= | +--ro supported-update-period* uint32=0A= +--ro max-objects-per-update? uint32=0A= +--ro minimum-dampening-period? uint32 {yp:on-change}?=0A= +--ro on-change-supported? notification-support=0A= | {yp:on-change}?=0A= +--ro periodic-notifications-supported? notification-support=0A= +--ro supported-excluded-change-type* union {yp:on-change}?=0A= +--ro datastore-capabilities* [datastore]=0A= +--ro datastore -> /yanglib:yang-library/datastore/name=0A= +--ro per-node-capabilities* [node-selector]=0A= +--ro node-selector nacm:node-instance-identifier=0A= +--ro (update-period)?=0A= | +--:(minimum-update-period)=0A= | | +--ro minimum-update-period? uint32=0A= | +--:(supported-update-period)=0A= | +--ro supported-update-period* uint32=0A= +--ro max-objects-per-update? uint32=0A= +--ro minimum-dampening-period? uint32=0A= | {yp:on-change}?=0A= +--ro on-change-supported? notification-support=0A= | {yp:on-change}?=0A= +--ro periodic-notifications-supported? notification-support=0A= +--ro supported-excluded-change-type* union {yp:on-change}?=0A= =0A= 3.2. YANG Module=0A= =0A= file "ietf-notification-capabilities@2019-11-05.yang"=0A= =0A= module ietf-notification-capabilities {=0A= yang-version 1.1;=0A= namespace=0A= "urn:ietf:params:xml:ns:yang:ietf-notification-capabilities";=0A= prefix inc;=0A= =0A= =0A= =0A= =0A= Lengyel, et al. Expires May 8, 2020 [Page 6]=0A= =0C=0A= Internet-Draft YANG-Push Notification Capabilities November 2019=0A= =0A= =0A= import ietf-netconf-acm { prefix nacm; }=0A= import ietf-yang-push {=0A= prefix yp;=0A= description=0A= "This module requires ietf-yang-push to be implemented.";=0A= }=0A= import ietf-yang-library {=0A= prefix yanglib;=0A= description "This module requires ietf-yang-library to=0A= be implemented. Revision 2019-01-04 or a=0A= revision derived from it is required.";=0A= }=0A= =0A= organization=0A= "IETF NETCONF (Network Configuration) Working Group";=0A= contact=0A= "WG Web: =0A= WG List: =0A= =0A= Editor: Balazs Lengyel=0A= ";=0A= description=0A= "This module specifies YANG-Push related publisher=0A= capabilities.=0A= =0A= The module contains=0A= - capabilities related to the throughput of notification data the=0A= publisher can support. (Note that for a specific subscription=0A= the publisher MAY still allow only longer periods or smaller=0A= updates depending on e.g. actual load conditions.)=0A= - specification of which data nodes support on-change or periodic=0A= notifications.=0A= =0A= Capability values can be specified on publisher level, datastore=0A= level or on specific data nodes (and their contained sub-tree) of=0A= a specific datastore.=0A= If a capability is specified on multiple levels, the=0A= specification on a more specific level overrides more=0A= generic capability specifications; thus=0A= - a publisher level specification is overridden by any other=0A= specification=0A= - a datastore level specification (with a node-selector '/') is=0A= overridden by a specification with a more specific node-selector.=0A= - a specification for a specific datastore and node-selector=0A= is overridden by a specification for the same datastore with=0A= a node-slector that describes more levels of containing lists=0A= and containers.=0A= =0A= =0A= =0A= =0A= Lengyel, et al. Expires May 8, 2020 [Page 7]=0A= =0C=0A= Internet-Draft YANG-Push Notification Capabilities November 2019=0A= =0A= =0A= If for a specific capability different values are indicated=0A= for different nodes in a subscription, then only values=0A= acceptable for every node are guaranteed to be acceptable=0A= for the subscription.=0A= =0A= To find a capability value for a specific node in a=0A= specific datastore the user SHALL=0A= 1) consider the publisher level capabilities under the=0A= publisher-subscription-capabilities container if such exist=0A= 2) search for a datastore-capabilities list entry for=0A= the specific datastore=0A= 3) within that datastore entry search for a=0A= per-node-capabilities entry that specifies the specific=0A= capability and that has the node-selector selecting the=0A= specific data node and that specifies the most levels of=0A= containing containers and lists.=0A= 4) If no entries are found in the previous steps the=0A= publisher is not capable of providing a value because=0A= it is unknown, the capability is changing for some reason,=0A= there is no specified limit etc. In this case the=0A= publisher's behavior is unspecified.=0A= =0A= The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',=0A= 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',=0A= 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document=0A= are to be interpreted as described in BCP 14 (RFC 2119)=0A= (RFC 8174) when, and only when, they appear in all=0A= capitals, as shown here.=0A= =0A= Copyright (c) 2019 IETF Trust and the persons identified as=0A= authors of the code. All rights reserved.=0A= =0A= Redistribution and use in source and binary forms, with or=0A= without modification, is permitted pursuant to, and subject=0A= to the license terms contained in, the Simplified BSD License=0A= set forth in Section 4.c of the IETF Trust's Legal Provisions=0A= Relating to IETF Documents=0A= (http://trustee.ietf.org/license-info).=0A= =0A= This version of this YANG module is part of RFC XXXX; see=0A= the RFC itself for full legal notices.";=0A= =0A= revision 2019-11-05 {=0A= description=0A= "Initial version";=0A= reference=0A= "RFC XXX: YANG-Push Notification Capabilities";=0A= }=0A= =0A= =0A= =0A= Lengyel, et al. Expires May 8, 2020 [Page 8]=0A= =0C=0A= Internet-Draft YANG-Push Notification Capabilities November 2019=0A= =0A= =0A= grouping subscription-capabilities {=0A= description "Capabilities related to Yang-Push notifications";=0A= =0A= typedef notification-support {=0A= type enumeration {=0A= enum no-notifications-supported {=0A= description "The publisher is not capable of sending any=0A= notifications for the relevant scope and subscription=0A= type." ;=0A= }=0A= enum notifications-for-config-changes-supported {=0A= description "The publisher is capable of sending=0A= notifications for config=3Dtrue nodes, but not=0A= for config=3Dfalse nodes for the relevant scope=0A= and subscription type." ;=0A= }=0A= enum notifications-for-state-changes-supported {=0A= description "The publisher is capable of sending=0A= notifications for config=3Dfalse nodes, but not=0A= for config=3Dtrue nodes for the relevant scope=0A= and subscription type." ;=0A= }=0A= enum notifications-for-all-changes-supported {=0A= description "The publisher is capable of sending=0A= notifications for both config=3Dfalse and config=3Dtrue=0A= nodes for the relevant scope and subscription type." ;=0A= }=0A= }=0A= description "Type for defining whether on-change or=0A= periodic notifications are supported for no, only config=3Dtrue,=0A= only config=3Dfalse or all data nodes.";=0A= }=0A= =0A= choice update-period {=0A= description "Supported update-period values.";=0A= leaf minimum-update-period {=0A= type uint32;=0A= units "centiseconds";=0A= description "Indicates the minimal update period that is=0A= supported for a periodic subscription.=0A= A periodic subscription to the selected data nodes must=0A= specify a value that is at least as large or greater than=0A= this";=0A= }=0A= =0A= leaf-list supported-update-period {=0A= type uint32;=0A= units "centiseconds";=0A= =0A= =0A= =0A= Lengyel, et al. Expires May 8, 2020 [Page 9]=0A= =0C=0A= Internet-Draft YANG-Push Notification Capabilities November 2019=0A= =0A= =0A= description "Supported update period values for a=0A= periodic subscription.=0A= A periodic subscription to the selected data nodes must=0A= specify one of the values in the list; other values=0A= are not supported.";=0A= }=0A= }=0A= =0A= leaf max-objects-per-update {=0A= type uint32 {=0A= range "1..max";=0A= }=0A= description=0A= "Maximum number of objects that can be sent=0A= in an update for the selected data nodes.";=0A= }=0A= =0A= leaf minimum-dampening-period {=0A= if-feature yp:on-change;=0A= type uint32;=0A= units "centiseconds";=0A= description=0A= "The minimum dampening period supported for on-change=0A= subscriptions for the selected data nodes.";=0A= }=0A= =0A= leaf on-change-supported {=0A= if-feature yp:on-change;=0A= type notification-support;=0A= description=0A= "Specifies whether the publisher is capable of=0A= sending on-change notifications for the selected=0A= data store or data nodes and the subtree below them.";=0A= }=0A= =0A= leaf periodic-notifications-supported {=0A= type notification-support;=0A= description=0A= "Specifies whether the publisher is capable of=0A= sending periodic notifications for the selected=0A= data store or data nodes and the subtree below them.";=0A= }=0A= =0A= leaf-list supported-excluded-change-type {=0A= if-feature yp:on-change;=0A= type union {=0A= type enumeration {=0A= enum none {=0A= =0A= =0A= =0A= Lengyel, et al. Expires May 8, 2020 [Page 10]=0A= =0C=0A= Internet-Draft YANG-Push Notification Capabilities November 2019=0A= =0A= =0A= description "None of the change types can be excluded.";=0A= }=0A= enum all {=0A= description=0A= "Any combination of change types can be excluded.";=0A= }=0A= }=0A= type yp:change-type;=0A= }=0A= description "The change types that can be excluded in=0A= YANG-Push subscriptions.";=0A= }=0A= }=0A= =0A= container publisher-subscription-capabilities {=0A= config false;=0A= description "YANG-Push related publisher capabilities.=0A= Capability values specified here at the publisher level=0A= are valid for all datastores and=0A= are used when the capability is not specified on the=0A= datastore level or for specific data nodes. ";=0A= =0A= uses subscription-capabilities {=0A= refine supported-excluded-change-type {=0A= default none;=0A= }=0A= }=0A= =0A= list datastore-capabilities {=0A= key datastore;=0A= =0A= description "Capabilities values per datastore.=0A= For non-NMDA servers/publishers the config=3Dfalse data is=0A= considered as if it was part of the running datastore.";=0A= =0A= leaf datastore {=0A= type leafref {=0A= path /yanglib:yang-library/yanglib:datastore/yanglib:name;=0A= }=0A= description "The datastore for which capabilities are defined.=0A= Only individual datastores can be specified=0A= e.g. ds:conventional is not allowed.";=0A= }=0A= =0A= list per-node-capabilities {=0A= key "node-selector";=0A= description=0A= "Each list entry specifies notification capabilities=0A= =0A= =0A= =0A= Lengyel, et al. Expires May 8, 2020 [Page 11]=0A= =0C=0A= Internet-Draft YANG-Push Notification Capabilities November 2019=0A= =0A= =0A= for the selected data nodes. The same capabilities apply for=0A= the data nodes in the subtree below them unless another list=0A= entry with a more specific node selector is present.";=0A= =0A= leaf node-selector {=0A= type nacm:node-instance-identifier;=0A= description=0A= "Selects the data nodes for which capabilities are=0A= specified. The special value '/' denotes all data nodes=0A= in the datastore.=0A= The system SHOULD order list entries according to=0A= the tree structure of the data models to make=0A= reading/parsing the data model more simple.";=0A= }=0A= =0A= uses subscription-capabilities;=0A= }=0A= }=0A= }=0A= }=0A= =0A= =0A= =0A= 4. Security Considerations=0A= =0A= The YANG module specified in this document defines a schema for data=0A= that is designed to be accessed via network management protocols such=0A= as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer=0A= is the secure transport layer, and the mandatory-to-implement secure=0A= transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer=0A= is HTTPS, and the mandatory-to-implement secure transport is TLS=0A= [RFC8446].=0A= =0A= The Network Configuration Access Control Model (NACM) [RFC8341]=0A= provides the means to restrict access for particular NETCONF or=0A= RESTCONF users to a preconfigured subset of all available NETCONF or=0A= RESTCONF protocol operations and content.=0A= =0A= All protocol-accessible data nodes are read-only and cannot be=0A= modified. The data in this module is not security sensitive. Access=0A= control may be configured, to avoid exposing the read-only data.=0A= =0A= When that data is in file format, data should be protected against=0A= modification or unauthorized access using normal file handling=0A= mechanisms.=0A= =0A= =0A= =0A= =0A= =0A= =0A= Lengyel, et al. Expires May 8, 2020 [Page 12]=0A= =0C=0A= Internet-Draft YANG-Push Notification Capabilities November 2019=0A= =0A= =0A= 5. IANA Considerations=0A= =0A= 5.1. The IETF XML Registry=0A= =0A= This document registers one URI in the IETF XML registry [RFC3688].=0A= Following the format in [RFC3688], the following registrations are=0A= requested:=0A= =0A= URI: urn:ietf:params:xml:ns:yang:ietf-notification-capabilities=0A= Registrant Contact: The NETCONF WG of the IETF.=0A= XML: N/A, the requested URI is an XML namespace.=0A= =0A= 5.2. The YANG Module Names Registry=0A= =0A= This document registers one YANG module in the YANG Module Names=0A= registry [RFC7950]. Following the format in [RFC7950], the the=0A= following registrations are requested:=0A= =0A= name: ietf-notification-capabilities=0A= namespace: urn:ietf:params:xml:ns:yang:ietf-notification-capabilities=0A= prefix: inc=0A= reference: RFC XXXX=0A= =0A= 6. References=0A= =0A= 6.1. Normative References=0A= =0A= [I-D.ietf-netmod-yang-instance-file-format]=0A= Lengyel, B. and B. Claise, "YANG Instance Data File=0A= Format", draft-ietf-netmod-yang-instance-file-format-04=0A= (work in progress), August 2019.=0A= =0A= [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,=0A= and A. Bierman, Ed., "Network Configuration Protocol=0A= (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,=0A= .=0A= =0A= [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure=0A= Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,=0A= .=0A= =0A= [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",=0A= RFC 7950, DOI 10.17487/RFC7950, August 2016,=0A= .=0A= =0A= [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF=0A= Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,=0A= .=0A= =0A= =0A= =0A= Lengyel, et al. Expires May 8, 2020 [Page 13]=0A= =0C=0A= Internet-Draft YANG-Push Notification Capabilities November 2019=0A= =0A= =0A= [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,=0A= and R. Wilton, "Network Management Datastore Architecture=0A= (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,=0A= .=0A= =0A= [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol=0A= Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,=0A= .=0A= =0A= [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard,=0A= E., and A. Tripathy, "Subscription to YANG Notifications",=0A= RFC 8639, DOI 10.17487/RFC8639, September 2019,=0A= .=0A= =0A= [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications=0A= for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641,=0A= September 2019, .=0A= =0A= 6.2. Informative References=0A= =0A= [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate=0A= Requirement Levels", BCP 14, RFC 2119,=0A= DOI 10.17487/RFC2119, March 1997,=0A= .=0A= =0A= [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,=0A= DOI 10.17487/RFC3688, January 2004,=0A= .=0A= =0A= [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC=0A= 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,=0A= May 2017, .=0A= =0A= [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",=0A= BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,=0A= .=0A= =0A= Appendix A. Instance data examples=0A= =0A= The following example is instance-data describing the notification=0A= capabilities of a hypothetical "acme-switch". The switch implements=0A= the running, candidate and operational datastores. Every change can=0A= be reported on-change from running, nothing from candidate and all=0A= config=3Dfalse data from operational. Periodic subscriptions are=0A= supported for running and operational, but not for candidate.=0A= =0A= =0A= =0A= acme-switch-notification-capabilities=0A= ietf-notification-capabilities@2019-10-22.yang=0A= =0A= Notification capabilities of acme-switch.=0A= Acme-switch implements the running, candidate and operational=0A= datastores. Every change can be reported on-change from running,=0A= nothing from candidate and all config=3Dfalse data from operational.=0A= Periodic subscriptions are supported for running and=0A= operational, but not for candidate.=0A= =0A= =0A= =0A= 500=0A= 2000=0A= 100=0A= =0A= notifications-for-all-changes-supported=0A= =0A= =0A= ds:operational=0A= =0A= /=0A= =0A= notifications-for-state-changes-supported=0A= =0A= =0A= =0A= =0A= ds:candidate=0A= =0A= /=0A= no-notifications-supported=0A= =0A= no-notifications-supported=0A= =0A= =0A= =0A= =0A= ds:running=0A= =0A= /=0A= notifications-for-all-changes-supported=0A= =0A= =0A= =0A= =0A= =0A= =0A= Lengyel, et al. Expires May 8, 2020 [Page 15]=0A= =0C=0A= Internet-Draft YANG-Push Notification Capabilities November 2019=0A= =0A= =0A= =0A= =0A= =0A= =0A= Figure 1: Notification Capabilities with datastore level settings=0A= =0A= The following is the instance-data describing the notification=0A= capabilities of a hypothetical "acme-router". The router implements=0A= the running, and operational datastores. Every change can be=0A= reported on-change from running, but only config=3Dtrue nodes and some=0A= config=3Dfalse data from operational. Interface statistics are not=0A= reported on-change only 2 important counters. Datastore subscription=0A= capabilities are not reported on-change as they never change on the=0A= acme-router during run-time.=0A= =0A= =0A= =0A= acme-router-notification-capabilities=0A= ietf-notification-capabilities@2019-10-22.yang=0A= =0A= Defines the notification capabilities of an acme-router.=0A= The router only has running, and operational datastores.=0A= Every change can be reported on-change from running, but=0A= only config=3Dtrue nodes and some config=3Dfalse data from = operational.=0A= Statistics are not reported on-change only 2 important counters,=0A= for these a smaller dampening period is possible.=0A= =0A= =0A= =0A= 500=0A= 2000=0A= 100=0A= =0A= notifications-for-all-changes-supported=0A= =0A= =0A= notifications-for-all-changes-supported=0A= =0A= =0A= all=0A= =0A= =0A= =0A= ds:operational=0A= =0A= =0A= =0A= =0A= Lengyel, et al. Expires May 8, 2020 [Page 16]=0A= =0C=0A= Internet-Draft YANG-Push Notification Capabilities November 2019=0A= =0A= =0A= =0A= =0A= /if:interfaces/if:interface/if:statistics=0A= =0A= no-notifications-supported=0A= =0A= =0A= =0A= =0A= /if:interfaces/if:interface/if:statistics/if:in-octets=0A= =0A= 10=0A= =0A= notifications-for-all-changes-supported=0A= =0A= =0A= =0A= =0A= /if:interfaces/if:interface/if:statistics/if:out-octets=0A= =0A= 10=0A= =0A= notifications-for-all-changes-supported=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Figure 2: Notification Capabilities with data node specific settings=0A= =0A= Appendix B. Changes between revisions=0A= =0A= v05 - v06=0A= =0A= o Providing the capability data is only a "SHOULD" recommendation.=0A= Some reviewers wanted MUST some wanted much less.=0A= =0A= o The YANG module import statements now indicate the imported=0A= modules that must be implemented not just available as import as=0A= requested by the YangDoctors review.=0A= =0A= v04 - v05=0A= =0A= o Added new capabilities periodic-notifications-supported and=0A= supported-excluded-change-type.=0A= =0A= =0A= =0A= =0A= Lengyel, et al. Expires May 8, 2020 [Page 17]=0A= =0C=0A= Internet-Draft YANG-Push Notification Capabilities November 2019=0A= =0A= =0A= o Restructured YANG module to make the node-selector's usage similar=0A= to how NACM uses it: "/" means the whole datastore.=0A= =0A= o Small corrections, spelling, rewording=0A= =0A= o Replaced the term server with the term publisher except in cases=0A= where we speak about datastores and functionality based on get,=0A= getconfig operations. In this latter case it is really the server=0A= functionality that is discussed=0A= =0A= v03 - v04=0A= =0A= o Clarified recommended support for on-change notifications about=0A= the datastore-subscription-capabilities.=0A= =0A= v02 - v03=0A= =0A= o Allow throughput related capabilities to be defined on top,=0A= datastore or data node level. Described that specific capability=0A= values always override generic ones.=0A= =0A= o Indicate that non-NMDA servers can also use this model.=0A= =0A= o Updated according to draft-ietf-netmod-yang-instance-file-=0A= format-04=0A= =0A= v01 - v02=0A= =0A= o Added instance data examples=0A= =0A= o On-change capability can be defined per datastore=0A= =0A= o Added "if-feature yp:on-change" where relevant=0A= =0A= o Unified units used=0A= =0A= v00 - v01=0A= =0A= o Add more capabilities: minimum period, supported period max-number=0A= of objects, min dampening period, dampening supported=0A= =0A= Authors' Addresses=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Lengyel, et al. Expires May 8, 2020 [Page 18]=0A= =0C=0A= Internet-Draft YANG-Push Notification Capabilities November 2019=0A= =0A= =0A= Balazs Lengyel=0A= Ericsson=0A= Magyar Tudosok korutja 11=0A= 1117 Budapest=0A= Hungary=0A= =0A= Email: balazs.lengyel@ericsson.com=0A= =0A= =0A= Alexander Clemm=0A= Futurewei=0A= 2330 Central Expressway=0A= Santa Clara, CA 95050=0A= USA=0A= =0A= Email: ludwig@clemm.org=0A= =0A= =0A= Benoit Claise=0A= Cisco Systems, Inc.=0A= De Kleetlaan 6a b1=0A= 1831 Diegem=0A= Belgium=0A= =0A= Email: bclaise@cisco.com=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Lengyel, et al. Expires May 8, 2020 [Page 19]=0A= ------=_NextPart_001_0796_01D593F4.23478290 Content-Type: text/xml; name="draft-ietf-netconf-notification-capabilities-06.xml" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-netconf-notification-capabilities-06.xml" YANG-Push = Notification Capabilities Ericsson
Magyar Tudosok korutja 11 1117 Budapest Hungary balazs.lengyel@ericsson.com
Futurewei
2330 Central Expressway Santa Clara, CA 95050 USA ludwig@clemm.org
=20 Cisco Systems, Inc.
De Kleetlaan 6a b1 1831 Diegem Belgium bclaise@cisco.com
=09 OPS NETCONF =20 This document proposes a YANG module that allows a publisher to=20 specify capabilities related to "Subscription to YANG = Datastores" (YANG-Push). It proposes to use YANG Instance Data to document this = information=20 and make it already available at implementation-time, but also = allow=20 it to be reported at run-time.=20
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown = here. The terms YANG-Push, On-change subscription and Periodic=20 subscription are used as defined in The terms Subscriber, Publisher and Receiver are used as=20 defined in On-change Notification Capability: The capability of the = publisher=20 to send on-change notifications for a specific datastore or a = specific data node. The term Server is used as defined in Implementation-time information: Information about the = publisher's behavior that is made available during the implementation of the = publisher,=20 available from a source other then a running server implementing = the publisher.=20 Run-time information: Information about the publisher's behavior that is available from the running server (implementing = the=20 publisher) via management protocols=20 such as NETCONF or RESTCONF .
=20
As defined in a publisher may allow = subscribers =20 to subscribe to updates from a datastore and subsequently push=20 such update notifications to the receiver. Notifications may be = sent=20 periodically or on-change (more or less immediately after each = change). A publisher supporting YANG-Push has a number of capabilities = defined in =20 that are often determined during the implementation of the = publisher. These include: Supported (reporting) periods for periodic = subscriptions Maximum number of objects that can be sent in an update The set of datastores or data nodes for which periodic = notification is supported If the optional on-change feature is supported, additionally: Supported dampening periods for on-change subscriptions The set of datastores or data nodes for which on-change = notification is supported Publishers have limitations in how many update notifications=20 and how many datastore node updates they can send out in a = certain=20 time-period. Publishers might not support periodic subscriptions to all = datastores. In some cases, a publisher supporting on-change notifications = will not be able to push updates for some object types on-change. Reasons = for this might be that the value of the datastore node changes = frequently (e.g. in-octets counter), that small object changes are frequent and irrelevant to the receiver (e.g., a temperature = gauge changing 0.1 degrees within a predetermined and acceptable range), or that = the=20 implementation is not capable of on-change notification for a particular object. In those cases,=20 it will be important for subscriber applications to have a way to identify which objects on-change notifications are supported and for which ones not. Faced with the reality that support for on-change notification = does not=20 mean that such notifications will be sent for any specific data = node,=20 subscriber/management applications can not rely on the on-change = functionality unless=20 the subscriber has some means to identify which objects = on-change=20 notifications are supported. YANG models are meant to be used as an interface contract. = Without=20 identification of the data nodes actually supporting on-change,=20 this contract would be incomplete. =20 This document proposes a YANG module that allows a subscriber to = discover YANG-Push related capabilities both at =20 implementation-time and run-time.=20 Implementation-time information is needed by Network Management = System=20 (NMS) implementers.=20 A NMS implementation that wants to support notifications, needs=20 the information about on-change notification capability. If the information is not documented=20 in a way available to the NMS designer, but only as instance = data from=20 the network node once it is deployed,=20 the NMS implementation will be delayed, because it has to wait = for the=20 network node to be ready. In addition, the assumption that all=20 NMS implementers will=20 have a correctly configured network node available to retrieve = data from=20 is an expensive proposition and may not always hold. (An NMS may = need=20 to be able to handle many dozens of network node types.)=20 Often a fully functional NMS is a requirement for introducing a = new=20 network node type=20 into a network, so delaying NMS readiness effectively also = delays the=20 time at which a new network node type can be introduced into the = network. Implementation-time information is needed by system integrators. = When introducing a network node type into their network,=20 operators often need to integrate the node type into their own=20 management system. The NMS may have management functions that = depend=20 on on-change notifications. The network operator needs to plan = his=20 management practices and NMS implementation before he even = decides to=20 buy the specific network node type. Moreover the decision to buy = the node=20 type sometimes depends on these management possibilities. =20 =20 Run-time information is needed: =20 for any "purely model driven" application, e.g. a = NETCONF-browser.=20 Such applications depend on reading models, capabilities in = run-time=20 to support all the publisher's available functionality. in case the capability might change during run-time=20 e.g. due to licensing, HW constraints etc. to check that capability information provided early,=20 already in implementation-time is indeed what the publisher = implements=20 (is the supplied documentation correct?)
=20
It is a goal to provide YANG-Push notification capability = information=20 in a format that is:=20 vendor independent machine readable identical for implementation-time and run-time =20 The YANG module ietf-notification-capabilities is defined to = provide the=20 information. It contains: =20 a set of capabilities related to the throughput of = notification data the=20 publisher can send out specification of which data nodes support on-change = notifications. Capability values can be specified on publisher level, datastore = level=20 or on specific data nodes (and their contained sub-tree) of a = specific=20 datastore. Capability values on a smaller, more specific part=20 of the publisher's data always override more generic values. On-change capability is not specified on a publisher level as=20 different datastores usually have different on-change=20 capabilities. On a datastore level on-change capability for=20 configuration and state data can be specified separately. The information SHOULD be provided in two ways both following=20 the ietf-notification-capabilities module: For the implementation-time use-case: It SHOULD be provided = by the=20 implementer as YANG instance data file complying to=20 .=20 The file SHALL be=20 available already in implementation-time retrievable in a way = that=20 does not depend on a live network node. E.g. download from=20 product Website. For the run-time use-case: It SHOULD be available via=20 NETCONF or=20 RESTCONF from the live server = (implementing=20 the publisher) during run-time. Implementations which support changing these capabilities at=20 run-time SHOULD support on-change notifications about the=20 publisher-subscription-capabilities container. =20
The following tree diagram provides an overview of the data model.
/yanglib:yang-library/datastore/name +--ro per-node-capabilities* [node-selector] +--ro node-selector nacm:node-instance-identifier +--ro (update-period)? | +--:(minimum-update-period) | | +--ro minimum-update-period? uint32 | +--:(supported-update-period) | +--ro supported-update-period* uint32 +--ro max-objects-per-update? uint32 +--ro minimum-dampening-period? uint32=20 | {yp:on-change}? +--ro on-change-supported? notification-support=20 | {yp:on-change}? +--ro periodic-notifications-supported? notification-support +--ro supported-excluded-change-type* union {yp:on-change}? = =20 ]]>
=20
<CODE BEGINS> file = "ietf-notification-capabilities@2019-11-05.yang"
WG List: Editor: Balazs Lengyel "; description "This module specifies YANG-Push related publisher capabilities. The module contains - capabilities related to the throughput of notification data the publisher can support. (Note that for a specific subscription the publisher MAY still allow only longer periods or smaller updates depending on e.g. actual load conditions.) - specification of which data nodes support on-change or periodic=20 notifications. =20 Capability values can be specified on publisher level, datastore level or on specific data nodes (and their contained sub-tree) of a specific datastore. =20 If a capability is specified on multiple levels, the specification on a more specific level overrides more=20 generic capability specifications; thus=20 - a publisher level specification is overridden by any other=20 specification - a datastore level specification (with a node-selector '/') is=20 overridden by a specification with a more specific node-selector. - a specification for a specific datastore and node-selector=20 is overridden by a specification for the same datastore with=20 a node-slector that describes more levels of containing lists=20 and containers. =20 If for a specific capability different values are indicated =20 for different nodes in a subscription, then only values=20 acceptable for every node are guaranteed to be acceptable=20 for the subscription. =20 To find a capability value for a specific node in a=20 specific datastore the user SHALL=20 1) consider the publisher level capabilities under the=20 publisher-subscription-capabilities container if such exist=20 2) search for a datastore-capabilities list entry for=20 the specific datastore 3) within that datastore entry search for a =20 per-node-capabilities entry that specifies the specific=20 capability and that has the node-selector selecting the=20 specific data node and that specifies the most levels of=20 containing containers and lists.=20 4) If no entries are found in the previous steps the=20 publisher is not capable of providing a value because=20 it is unknown, the capability is changing for some reason,=20 there is no specified limit etc. In this case the=20 publisher's behavior is unspecified. =20 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. Copyright (c) 2019 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2019-11-05 { description "Initial version"; reference "RFC XXX: YANG-Push Notification Capabilities"; } grouping subscription-capabilities { description "Capabilities related to Yang-Push notifications"; =20 typedef notification-support { type enumeration { enum no-notifications-supported { description "The publisher is not capable of sending any=20 notifications for the relevant scope and subscription=20 type." ; } enum notifications-for-config-changes-supported { description "The publisher is capable of sending=20 notifications for config=3Dtrue nodes, but not=20 for config=3Dfalse nodes for the relevant scope=20 and subscription type." ; } enum notifications-for-state-changes-supported { description "The publisher is capable of sending=20 notifications for config=3Dfalse nodes, but not=20 for config=3Dtrue nodes for the relevant scope=20 and subscription type." ; } enum notifications-for-all-changes-supported { description "The publisher is capable of sending=20 notifications for both config=3Dfalse and config=3Dtrue=20 nodes for the relevant scope and subscription type." ; } }=20 description "Type for defining whether on-change or=20 periodic notifications are supported for no, only config=3Dtrue, = only config=3Dfalse or all data nodes."; } =20 choice update-period { description "Supported update-period values."; leaf minimum-update-period { type uint32; units "centiseconds"; description "Indicates the minimal update period that is=20 supported for a periodic subscription.=20 A periodic subscription to the selected data nodes must=20 specify a value that is at least as large or greater than=20 this"; } leaf-list supported-update-period { type uint32; units "centiseconds"; description "Supported update period values for a periodic subscription.=20 A periodic subscription to the selected data nodes must=20 specify one of the values in the list; other values =20 are not supported."; } } leaf max-objects-per-update { type uint32 { range "1..max"; } description "Maximum number of objects that can be sent in an update for the selected data nodes."; } leaf minimum-dampening-period { if-feature yp:on-change; type uint32; units "centiseconds"; description "The minimum dampening period supported for on-change subscriptions for the selected data nodes."; } leaf on-change-supported { if-feature yp:on-change; type notification-support; =20 description "Specifies whether the publisher is capable of sending on-change notifications for the selected data store or data nodes and the subtree below them."; } =20 leaf periodic-notifications-supported { type notification-support; =20 description "Specifies whether the publisher is capable of sending periodic notifications for the selected data store or data nodes and the subtree below them."; } =20 =20 leaf-list supported-excluded-change-type { if-feature yp:on-change; type union { type enumeration { enum none { description "None of the change types can be excluded."; } enum all { description=20 "Any combination of change types can be excluded."; } } type yp:change-type; } =20 description "The change types that can be excluded in=20 YANG-Push subscriptions."; } } =20 container publisher-subscription-capabilities { config false; description "YANG-Push related publisher capabilities. Capability values specified here at the publisher level=20 are valid for all datastores and=20 are used when the capability is not specified on the=20 datastore level or for specific data nodes. "; uses subscription-capabilities { refine supported-excluded-change-type { default none; } } =20 list datastore-capabilities { key datastore; =20 description "Capabilities values per datastore. For non-NMDA servers/publishers the config=3Dfalse data is considered as if it was part of the running datastore."; leaf datastore { type leafref { path /yanglib:yang-library/yanglib:datastore/yanglib:name; } description "The datastore for which capabilities are defined. Only individual datastores can be specified=20 e.g. ds:conventional is not allowed."; } =20 list per-node-capabilities { key "node-selector"; description "Each list entry specifies notification capabilities=20 for the selected data nodes. The same capabilities apply for=20 the data nodes in the subtree below them unless another list=20 entry with a more specific node selector is present."; leaf node-selector { type nacm:node-instance-identifier; description "Selects the data nodes for which capabilities are=20 specified. The special value '/' denotes all data nodes=20 in the datastore. The system SHOULD order list entries according to=20 the tree structure of the data models to make=20 reading/parsing the data model more simple."; } uses subscription-capabilities; } } } } ]]>
<CODE ENDS>
=20
=20 =20
=20 The YANG module specified in this document defines a schema for = data=20 that is designed to be accessed via network management = protocols such=20 as NETCONF or RESTCONF . The lowest NETCONF layer=20 is the secure transport layer, and the mandatory-to-implement = secure=20 transport is Secure Shell (SSH) . The = lowest RESTCONF layer=20 is HTTPS, and the mandatory-to-implement secure transport is=20 TLS . The Network Configuration Access Control Model (NACM) [RFC8341] = provides the means to restrict access for particular NETCONF or = RESTCONF users to a preconfigured subset of all available = NETCONF or=20 RESTCONF protocol operations and content.=20 All protocol-accessible data nodes are read-only and cannot be = modified.=20 The data in this module is not security sensitive. Access control may be configured, to avoid exposing=20 the read-only data. When that data is in file format, data should be protected = against=20 modification or unauthorized access using normal file handling = mechanisms.
This document = registers one URI in the IETF XML=20 registry . Following the format in=20 , the following registrations are requested:
URI: urn:ietf:params:xml:ns:yang:ietf-notification-capabilities Registrant Contact: The NETCONF WG of the IETF. XML: N/A, the requested URI is an XML namespace.
This document registers one YANG module in the YANG Module Names registry . Following the format in , the the following registrations are requested:
name: ietf-notification-capabilities namespace: urn:ietf:params:xml:ns:yang:ietf-notification-capabilities prefix: inc reference: RFC XXXX
The following example is instance-data describing the = notification=20 capabilities of a hypothetical "acme-switch". The switch = implements=20 the running, candidate and operational=20 datastores. Every change can be reported on-change from running, = nothing from candidate and all config=3Dfalse data from = operational. Periodic subscriptions are supported for running and=20 operational, but not for candidate.
acme-switch-notification-capabilities ietf-notification-capabilities@2019-10-22.yang =20 Notification capabilities of acme-switch. Acme-switch implements the running, candidate and operational=20 datastores. Every change can be reported on-change from running,=20 nothing from candidate and all config=3Dfalse data from operational. Periodic subscriptions are supported for running and=20 operational, but not for candidate. 500 2000 100 notifications-for-all-changes-supported ds:operational / notifications-for-state-changes-supported =20 ds:candidate / no-notifications-supported no-notifications-supported =20 ds:running / notifications-for-all-changes-supported =20 ]]>
The following is the instance-data describing the notification=20 capabilities of a hypothetical "acme-router". The router = implements=20 the running, and operational datastores. Every change can be reported on-change from running,=20 but only config=3Dtrue nodes and some config=3Dfalse data from = operational. Interface statistics are not reported on-change only 2 important = counters. Datastore subscription capabilities are not reported on-change = as they=20 never change on the acme-router during run-time.
acme-router-notification-capabilities ietf-notification-capabilities@2019-10-22.yang =20 Defines the notification capabilities of an acme-router. The router only has running, and operational datastores. Every change can be reported on-change from running, but=20 only config=3Dtrue nodes and some config=3Dfalse data from = operational. Statistics are not reported on-change only 2 important counters, for these a smaller dampening period is possible. 500 2000 100 notifications-for-all-changes-supported notifications-for-all-changes-supported all ds:operational /if:interfaces/if:interface/if:statistics no-notifications-supported /if:interfaces/if:interface/if:statistics/if:in-octets 10 notifications-for-all-changes-supported /if:interfaces/if:interface/if:statistics/if:out-octets 10 notifications-for-all-changes-supported =20 ]]>
v05 - v06 Providing the capability data is only a "SHOULD" = recommendation.=20 Some reviewers wanted MUST some wanted much less. The YANG module import statements now indicate the imported = modules=20 that must be implemented not just available as import as = requested by=20 the YangDoctors review. v04 - v05 Added new capabilities periodic-notifications-supported and = supported-excluded-change-type. =20 Restructured YANG module to make the node-selector's usage = similar=20 to how NACM uses it: "/" means the whole datastore. Small corrections, spelling, rewording Replaced the term server with the term publisher except in = cases=20 where we speak about datastores and functionality based on get, getconfig operations. In this latter case it is really = the=20 server functionality that is discussed v03 - v04 Clarified recommended support for on-change notifications = about=20 the datastore-subscription-capabilities. v02 - v03 Allow throughput related capabilities to be defined on top, = datastore or data node level. Described that specific = capability=20 values always override generic ones. Indicate that non-NMDA servers can also use this model. Updated according to = draft-ietf-netmod-yang-instance-file-format-04 v01 - v02 Added instance data examples On-change capability can be defined per datastore Added "if-feature yp:on-change" where relevant Unified units used v00 - v01 Add more capabilities: minimum period, supported period max-number of objects, min dampening period,=20 dampening supported
=20 ------=_NextPart_001_0796_01D593F4.23478290-- ------=_NextPart_000_0795_01D593F4.23478290 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 DTE5MTEwNTE1MTQ0NVowIwYJKoZIhvcNAQkEMRYEFOXdCjHd/3HKT5EkO6PWcZyFtqi9MEMGCSqG SIb3DQEJDzE2MDQwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG BSsOAwIaMGsGCSsGAQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8x ITBtBgsqhkiG9w0BCRACCzFeoFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITAN BgkqhkiG9w0BAQEFAASCAQB4cSzZemj6i5pU8uMaECCW9QI197+6ett+om8yiq4yk1l1t7x+hlvw THKP+9J9EtSmwYKcSkQEDFLQbppJ9xck7oIXDYCKa1eUtyU4WNRCoVncTwg15Ju7DpPVe0Lx63Ul XHbKQWbMuOSsVMncbNlSjLqkwT1RcoQjxt7B+kcBiRtMF311kuunWV5o7iEboDMZXuyKDHSyslPQ VCm+NcLRrtUl0petPJbiI8pab7F+mcLckJCc685PTXYNAJqjZyVkE6FcI3JZoLDOSGjIcR5YUAId 0l49yTvb+BFMYXdoLeQoeJAqrI8NTAYNf4Rcbw8dyUnFJO11D+AxJ1sM4bimAAAAAAAA ------=_NextPart_000_0795_01D593F4.23478290-- From nobody Tue Nov 5 07:17:27 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5E881200B3 for ; Tue, 5 Nov 2019 07:17:25 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18Gj3w7iOLyh for ; Tue, 5 Nov 2019 07:17:23 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60076.outbound.protection.outlook.com [40.107.6.76]) (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 7E34B1200B9 for ; Tue, 5 Nov 2019 07:17:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MZhA9E1qIu9kwk0adQHMUPJgnwywe17VpyzG5BktoI/Qj+pyMz8EyIKgA5bQi3wSsO9CeR6XnahxtGaP+Khv4azsuXyucoVITxqUWfH88WfuWLBKyzpPrNpzuKoZ3ubzBET65862fJ/h3jvMoYpTYUKJmnzikLJZqcwML/G7MyrKjx49tzpUkKcCtxQW2ZU7CzSHv5r5TUlfG0dHjkr2ygvlGgMRhiHaY7OmXmwGPXKudydkBSUFB95zyMhnT3hFm7TUCt+yTHfLzcNeRyuF1WsHghWi1nq3xeKXtNfuVlwVDh3uzK3TXpqTDKnMl/MdYWEoaVcbbPCllNrdSeLUPw== 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=78esqjEYcsiIB+lj8ZfGCjSjzg7Q3iE2iltZFakaNQo=; b=VZq745YyyUo9KQBN+ELWRVIjYwcU1ucfeapD+sLFDDCMrVsKon+EJWzLmiXbtBXBqHoQ8o7CaTFNiucvdD0jxyIOzSt1CqeLJYDLlWR+MT++BkjUQ3qmkcOtAWBtwEg6Y9ejuH6L9C2NO7G4JaMezwrn7cf0MOA5bUGzmawnqWLi4ZZbpQBPkyHg2PNAQZRTRSDoGpe0xB+hbryzzXCovDFpIcnSGTb2fHaD0eWWfAnU2njignWTx+1cvq7WK0ShkPzXlrwc+QL2/isPfIzmD5J0u4NPAWU96sdxVL5d2LNT7TnAuzIDA3Bzw9xARjyv8Yvc/O9FkWluDhuLpeYHJQ== 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=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=78esqjEYcsiIB+lj8ZfGCjSjzg7Q3iE2iltZFakaNQo=; b=lhJb/44Vme2vYs2aG2b+SDUyWqUObz5dLbRiG9jFIRKLg2rTRpNsp0zN79Ph+y7Ab8Hr7hWTdjS9RoniOGnvhie2wmUPOiEHnvqu2Fru9gquPwQzj2R07vubdzkfk93qBJc60ksp8EQllFKl2FUjM7bmPBwWs/8Ijd2S1/1naCU= Received: from AM0PR07MB5187.eurprd07.prod.outlook.com (20.178.20.74) by AM0PR07MB4547.eurprd07.prod.outlook.com (52.135.148.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.16; Tue, 5 Nov 2019 15:17:19 +0000 Received: from AM0PR07MB5187.eurprd07.prod.outlook.com ([fe80::f016:8dc4:2887:cacd]) by AM0PR07MB5187.eurprd07.prod.outlook.com ([fe80::f016:8dc4:2887:cacd%3]) with mapi id 15.20.2430.013; Tue, 5 Nov 2019 15:17:19 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Kov=E1cs?= To: "netconf@ietf.org" , Kent Watsen Thread-Topic: FIXMEs in ietf-crypto-types and client/server models Thread-Index: AdWT66zB5kr5iNWxQ6yg/MeI8i6GNg== Date: Tue, 5 Nov 2019 15:17:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.kovacs@ericsson.com; x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fb940188-f4d5-42c8-853c-08d762034047 x-ms-traffictypediagnostic: AM0PR07MB4547: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0212BDE3BE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(396003)(39860400002)(346002)(376002)(136003)(199004)(189003)(66476007)(790700001)(6116002)(76116006)(66556008)(256004)(3846002)(6506007)(102836004)(2501003)(316002)(99286004)(74316002)(110136005)(26005)(64756008)(66446008)(2906002)(66946007)(33656002)(71200400001)(71190400001)(55016002)(6436002)(86362001)(478600001)(6306002)(14454004)(54896002)(9686003)(52536014)(561944003)(7696005)(66066001)(7736002)(186003)(476003)(5660300002)(9326002)(25786009)(8676002)(81156014)(81166006)(8936002)(45776006)(486006)(170073001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB4547; H:AM0PR07MB5187.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: RftL+XU2n4ztvfO1SfTpxVt3xIUURXVYjcM/ezPDUEKGz8x79arTnrG7/QJf2P2i8Wb9FwtSdUWYZkmFdDFSVlNCJbz2SWcpTBqca/VXMIQhFNsULJaa5hFhv4qlu1tugFECvHKEKzymfg9Z0O8ObPSrB2Z8bicPVatMhiCRTxBOAy7ZtTYdZGv0OqEA+2OJim2IMpAA44zXwW5hjpZZKbJwFtHd8YVwGX9IEdsETi4fgmG9x4bJKfr6scPp/jkjqakfi+ehp+202+XjWZ+/cQTmp4ckkyl1txjUWAkszdmAv0AMco/jED9qGmHcE4fPBJZMnQ0o8IUqaQrzdHmqopl+5GoGBSy6u+MjdTRwZ4ma5UnNu6ZKtve2u0wbpnNCh/9U7UtDd2LwPI6DrHAd8yBJrdjysFJd4sFijY/wvZzvnWJtKmMMXWHRIexEJ6xq x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR07MB5187A1438941A29D28CE3486837E0AM0PR07MB5187eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: fb940188-f4d5-42c8-853c-08d762034047 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2019 15:17:19.8587 (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: T2LdjIL0HdfIaAFFcmzeV/AIzZO9yMY5CoC2Mip1hDHCcVgs4QRb+tKJazeIsSly/75mtIIR650e1laz2xId9ejzSgJgjuT7iwGsGs8H+kU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4547 Archived-At: Subject: [netconf] FIXMEs in ietf-crypto-types and client/server models 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, 05 Nov 2019 15:17:26 -0000 --_000_AM0PR07MB5187A1438941A29D28CE3486837E0AM0PR07MB5187eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I see some FIXMEs in ietf-crypto-types and related models. I would be inter= ested about the current state of them and possibility to clean them up. 1. Key-format (symmetric-key, public-key, asymmetric-key-pair) I assume the idea here is to make it possible to have choices for the ASN.1= types holding the keys. If this flexibility for formats is necessary I don= 't have any objection to them but having a single agreed type for these dif= ferent use cases would also suffice. 2. attributes in asymmetric-key-pair-with-cert(s)-grouping I think attributes should be kept optional. If there is anything else besid= es subject seen mandatory maybe it should be extracted out from attributes = and be spelled out a separate leaf, but I don't think there is. 1. PSK and raw public keys The use case of PSK and raw public keys are not the most urgent in my opini= on which now slows a bit the progress of these drafts, but let's make an at= tempt to finalize them. raw-public-keys: I see these were added due to RFC 7250 and 8446. I guess i= n truststore this is a separate container to distinguish from SSH host keys= . For configuring the private part I think keystore already gives support f= or this case with the asymmetric key (w/o cert) and in the client/server dr= afts Kent's proposal could be used (I replaced raw public key with existing= type, shouldn't that be useable straight away?) container { choice auth-type { uses ks:local-or-keystore-end-entity-cert-with-key= -grouping; uses ks:local-or-keystore-asymmetric-key-grouping; I would also prefer if these choices are in features, so that an implementa= tion can choose. psk: given that the asymmetric keys without certs were covered by host keys= and raw public keys, I think psk should only be symmetric keys. Symmetric = keys are then sensitive/secret data and as such I believe they should only = be referenced from keystore. Seeing them in truststore was unexpected for m= e. When it comes to their use, clients and servers should be extended with = following configuration (and I assume we talk of TLS clients and servers on= ly): container { choice auth-type { uses ks:local-or-keystore-end-entity-cert-with-key= -grouping; uses ks:local-or-keystore-asymmetric-key-grouping; uses ks:local-or-keystore-symmetric-key-grouping; Latter grouping would be a new one, but it would use existing constructs an= d terms from keystore. I don't think we need new ones. Selected cipher suit= es will need to have PSK in them for using symmetric key (similar match nee= ded for the others). Note that symmetric keys can be used for other cases t= han TLS PSK, for example SNMPv3 USM. Again, features would be necessary (th= ose could be saying x.509 or raw-public-key or psk). Br, Balazs --_000_AM0PR07MB5187A1438941A29D28CE3486837E0AM0PR07MB5187eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

I see some FIXMEs in ietf-crypto-types and related m= odels. I would be interested about the current state of them and possibilit= y to clean them up.

 

  1. Key-format (symmetric-key, public-key, asymmetric-key-pair)

I assume the idea here is to make it possible= to have choices for the ASN.1 types holding the keys. If this flexibility = for formats is necessary I don’t have any objection to them but havin= g a single agreed type for these different use cases would also suffice.

 

2.     &= nbsp; attributes in asymmetric-key-pair-with-cert(s)-grou= ping

I think attributes should be kept optional. I= f there is anything else besides subject seen mandatory maybe it should be = extracted out from attributes and be spelled out a separate leaf, but I don= ’t think there is.

 

  1. PSK and raw public keys

The use case of PSK and raw public keys are n= ot the most urgent in my opinion which now slows a bit the progress of thes= e drafts, but let’s make an attempt to finalize them.

 

raw-public-keys: I see these were added due t= o RFC 7250 and 8446. I guess in truststore this is a separate container to = distinguish from SSH host keys. For configuring the private part I think ke= ystore already gives support for this case with the asymmetric key (w/o cert) and in the client/server drafts Ke= nt’s proposal could be used (I replaced raw public key with existing = type, shouldn’t that be useable straight away?)

 

   &nb= sp;                container <client-identity or server= -identity> {

   &nb= sp;                  choice auth-type {

   &nb= sp;                     uses ks:local-or-keystore-end-enti= ty-cert-with-key-grouping;
       &n= bsp;              =    uses ks:local-or-keystore-asymmetric-key-grouping;

I would also prefer if these choices are in f= eatures, so that an implementation can choose.

 

psk: given that the asymmetric keys without c= erts were covered by host keys and raw public keys, I think psk should only= be symmetric keys. Symmetric keys are then sensitive/secret data and as su= ch I believe they should only be referenced from keystore. Seeing them in truststore was unexpected for me. When it co= mes to their use, clients and servers should be extended with following con= figuration (and I assume we talk of TLS clients and servers only):

 

   &nb= sp;                container <client-identity or server= -identity> {

   &nb= sp;                  choice auth-type {

  &n= bsp;            = ;          uses ks:local-or-keystore-e= nd-entity-cert-with-key-grouping;
       &n= bsp;              =    uses ks:local-or-keystore-asymmetric-key-grouping;

       &nb= sp;             = ;  uses ks:local-or-keystore-symmetric-key-grouping;<= o:p>

 

Latter grouping would be a new one, but it wo= uld use existing constructs and terms from keystore. I don’t think we= need new ones. Selected cipher suites will need to have PSK in them for us= ing symmetric key (similar match needed for the others). Note that symmetric keys can be used for other cases than= TLS PSK, for example SNMPv3 USM. Again, features would be necessary (those= could be saying x.509 or raw-public-key or psk).

 

 

Br,

Balazs

 

--_000_AM0PR07MB5187A1438941A29D28CE3486837E0AM0PR07MB5187eurp_-- From nobody Tue Nov 5 08:43:52 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACD7120871; Tue, 5 Nov 2019 08:43:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.998 X-Spam-Level: X-Spam-Status: No, score=-6.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_HI=-5, 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 OIEgPmnDwIGd; Tue, 5 Nov 2019 08:43:45 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A43C412085B; Tue, 5 Nov 2019 08:43:45 -0800 (PST) Received: from birdie (unknown [IPv6:2a01:5e0:29:ffff:a77:4b4a:dc25:79cc]) by mail.nic.cz (Postfix) with ESMTPSA id 74622140FCE; Tue, 5 Nov 2019 17:43:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1572972223; bh=FupaaR+uVFUkjPBtpTMD0myWfPW7y6LT9rpMqHfs60o=; h=From:To:Date; b=YS95h73xpv5Jw7BZJ6PdFHwDWjYuD6toGPGNo2b8u7M4nHieGItB8tTyWwgp5pvrk BmmQ0rUOu9+kMxngLmowUrPUboRF06SVWE0iSJkd5D/3af/EoyaCSI6uvPWZnBxrun tgiP1at/IqY7scgougddgsB+D+9haBKmZRHAE8Ns= Message-ID: <352449f5e1398ccfca7591e0e4555b710c766802.camel@nic.cz> From: Ladislav Lhotka To: =?ISO-8859-1?Q?Bal=E1zs?= Lengyel , "yang-doctors@ietf.org" Cc: "last-call@ietf.org" , "netconf@ietf.org" , "draft-ietf-netconf-notification-capabilities.all@ietf.org" Date: Tue, 05 Nov 2019 17:43:43 +0100 In-Reply-To: References: <157233302184.6593.3869700028694968875@ietfa.amsl.com> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.100.3 at mail.nic.cz X-Virus-Status: Clean Archived-At: Subject: Re: [netconf] Yangdoctors last call review of draft-ietf-netconf-notification-capabilities-05 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, 05 Nov 2019 16:43:50 -0000 On Tue, 2019-11-05 at 14:38 +0000, Balázs Lengyel wrote: ... > ***** Appendix A. Instance data examples > - Example in Fig. 2: the element has an incorrect > XML namespace (of the ietf-datastores module). > BALAZS: I don't understand the comment; I don't see the error. Could you > please advise me what you think should be there? Exactly where? This element: ds:operational The re-declaration of the default XML namespace is wrong and should be removed (as in Fig. 1). > > - Many enum values are invalid because they contain > leading/trailing whitespace. It would be better to encode the > examples in JSON. > BALAZS: I would like to keep the examples as they are. > In many previous RFCs lines in XML examples were broken into multiple lines. > E.g. > RFC7950 7.16.3 > rfc8341 A.4 > rfc8641 4.4.1 > rfc6022 4.1 > rfc8525 B > rfc8072 A.1.1 > rfc6243 A.3.1 > IMHO it is readable. It is better to use longer descriptive names in YANG, > then to use short names just to avoid long lines in XML examples. The problem with this approach is that it may mislead casual readers into thinking that the whitespace can be freely added to such values. Lada > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Nov 5 10:20:39 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD293120130; Tue, 5 Nov 2019 10:20:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.481 X-Spam-Level: X-Spam-Status: No, score=0.481 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, MISSING_MIMEOLE=1.899, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nktY6Xn1UwUT; Tue, 5 Nov 2019 10:20:36 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E06112010E; Tue, 5 Nov 2019 10:20:36 -0800 (PST) Received: from [IPv6:2607:fb90:a631:7aaf:11f4:5f9d:93f0:5d9e] ([172.58.35.63]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1MCrkq-1iaorg3Suu-008oyO; Tue, 05 Nov 2019 19:20:25 +0100 Date: Tue, 05 Nov 2019 10:20:19 -0800 Message-ID: <25c03604-1050-4117-a80e-16d3b9bd2716@email.android.com> X-Android-Message-ID: <25c03604-1050-4117-a80e-16d3b9bd2716@email.android.com> In-Reply-To: <1b2e930f-f654-5567-f89f-a5ba8fca8b27@cisco.com> From: Alexander Clemm To: Benoit Claise Cc: =?ISO-8859-1?Q?Bal=E1zs_Lengyel?= , Kent Watsen , draft-ietf-netconf-notification-capabilities@ietf.org, netconf@ietf.org Importance: Normal X-Priority: 3 X-MSMail-Priority: Normal MIME-Version: 1.0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 X-Provags-ID: V03:K1:HHUZgZBRtiCAnoZvYihDYPi+624nEvkm7T+Uq3cd+D0jjZwUut0 7/NVFe7mcsTZ67iZniQhLI4bEQtsLLiyiauHF/maWcGpJpUG4cXMg0S4Urr5/jjuVjGDhYV yjgZiUJuqtGoLts/EHC4SAFuPp3MlNr0icmCxYXiCmKX9DBv/ncbmDcf8tBw3OitmN1FJZL TXOFqG63N5XE12kKc8p8A== X-UI-Out-Filterresults: notjunk:1;V03:K0:vkwFTCZBgbg=:5WQnyTiK0Bv1FRywgVs5Nd tCUjnk/Ai6poglooa6gvkpkaii3HBj4LzhS+hjXTpQquLlnJbnze3TZzs19N1Aj/il0u11uMm NtA5Kf0EyQ+oA431YcI3ZiAozUKqHekx3xq+SlT1PEn7JgzHS2h18IxBIoExmqP0UgIUMB3jv +W0QYLkQl0BKxRli01ulTHBR/ijAbQ4Qyrymq1/Z8fPXTVW0vU7JLpWuA/BZbYgZNxq5LNjoe 4rXQxuJhfVf7Ez48PYQs0f44WHteG6NP7qipBaZOnNNA2f/DnDD1YT225kxkiqpg4nz9l70gb 2a+h25E7AWbwHsaq5JWB6ReQc0B3nk+qF3tHe3uIezV8pTfJUFfCyUqvYv1k+47TwpTCJTGM7 067fAVj+JAZu3Diz2H02yfW6bRgc9sqvIwkj25FZOL6fBQrWg51bJZifLghAMdsHRXY3LN0Qk 9Z9wyWNwm3rwkoez/UvlzWOXhYuItf2h4WDzuhNni2Dxhxcwmb5ByGuXoix1t7f8eg9Of+ORZ n4/F2nrGFLG036VZcH1KCDHIpwMuheWJB4HhwZLwdjB289u1cg0deoKaeTr8wV1Dz4rZjgbFq x9Dmtqo5Bp09erdNUdjXgBIHlY32bbE5ctTBsHjcdlr+BCbZOmxU3ZuWtMOyE27BbBSEx9NxJ g/DP1Jyk1aW1zkks6Bk44Md3wlWeG9Fv9/ta1tV1ZTgsgnzSo5R6FeuPM7AdVZ7F9GfWvIeRZ yBhew5cNvyx0kYBcKCqz2++7rVFDPyDbS+c021yZwyTahPmNMyW8NEPi+py78d1GFTpQVIMbO 9H7wbntyyFHWCWOUMdOy6eDh6CqPhRqQEGZnqaF1vtlsyBwD7wYV5s5Emo6OHdKFKMaQeE1yC yFeunQZo7hjH64PtZXCg== Archived-At: Subject: Re: [netconf] IPR poll on draft-ietf-netconf-notification-capabilities-05 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, 05 Nov 2019 18:20:39 -0000 PGRpdiBkaXI9J2F1dG8nPjxkaXY+Ik5vLCBJJ20gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBh cHBsaWVzIHRvIHRoaXMgZHJhZnQuIjxkaXYgZGlyPSJhdXRvIj48YnI+PC9kaXY+PGRpdiBkaXI9 ImF1dG8iPktpbmQgcmVnYXJkczwvZGl2PjxkaXYgZGlyPSJhdXRvIj4tLS0gQWxleDwvZGl2Pjxi cj48ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5P biBOb3YgNSwgMjAxOSA2OjQ2IEFNLCBCZW5vaXQgQ2xhaXNlICZsdDtiY2xhaXNlQGNpc2NvLmNv bSZndDsgd3JvdGU6PGJyIHR5cGU9ImF0dHJpYnV0aW9uIj48YmxvY2txdW90ZSBjbGFzcz0icXVv dGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtw YWRkaW5nLWxlZnQ6MWV4Ij48ZGl2PgogICAgPGRpdj4KICAgICAgPHA+Ik5vLCBJJ20gbm90IGF3 YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvCiAgICAgICAgdGhpcyBkcmFmdCI8L3A+CiAg ICAgIDxwPjxicj4KICAgICAgPC9wPgogICAgICA8cD5SZWdhcmRzLCBCLjxicj4KICAgICAgPC9w PgogICAgPC9kaXY+CiAgICA8YmxvY2txdW90ZT4KICAgICAgCiAgICAgIAogICAgICAKICAgICAg PGRpdj4KICAgICAgICA8cD4iTm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxp ZXMKICAgICAgICAgIHRvIHRoaXMgZHJhZnQiPC9wPgogICAgICAgIDxwPlJlZ2FyZHMgQmFsYXpz PC9wPgogICAgICAgIDxwPiZuYnNwOzwvcD4KICAgICAgICA8ZGl2PgogICAgICAgICAgPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjZTFlMWUxIDFwdDtwYWRkaW5nOjNw dCAwY20gMGNtIDBjbSI+CiAgICAgICAgICAgIDxwPjxiPkZyb206PC9iPiBLZW50IFdhdHNlbgog ICAgICAgICAgICAgIDxhIGhyZWY9Im1haWx0bzprZW50K2lldGZAd2F0c2VuLm5ldCI+Jmx0O2tl bnQraWV0ZkB3YXRzZW4ubmV0Jmd0OzwvYT4gPGJyPgogICAgICAgICAgICAgIDxiPlNlbnQ6PC9i PiAyMDE5LiBub3ZlbWJlciAxLiwgcMOpbnRlayAxNjo0NDxicj4KICAgICAgICAgICAgICA8Yj5U bzo8L2I+IEJhbMOhenMgTGVuZ3llbAogICAgICAgICAgICAgIDxhIGhyZWY9Im1haWx0bzpiYWxh enMubGVuZ3llbEBlcmljc3Nvbi5jb20iPiZsdDtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20m Z3Q7PC9hPjsgQWxleGFuZGVyIENsZW1tCiAgICAgICAgICAgICAgPGEgaHJlZj0ibWFpbHRvOmx1 ZHdpZ0BjbGVtbS5vcmciPiZsdDtsdWR3aWdAY2xlbW0ub3JnJmd0OzwvYT47IEJlbm9pdCBDbGFp c2UKICAgICAgICAgICAgICA8YSBocmVmPSJtYWlsdG86YmNsYWlzZUBjaXNjby5jb20iPiZsdDti Y2xhaXNlQGNpc2NvLmNvbSZndDs8L2E+PGJyPgogICAgICAgICAgICAgIDxiPkNjOjwvYj4KICAg ICAgICAgICAgICA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlv bi1jYXBhYmlsaXRpZXNAaWV0Zi5vcmciPmRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24t Y2FwYWJpbGl0aWVzQGlldGYub3JnPC9hPjsKICAgICAgICAgICAgICA8YSBocmVmPSJtYWlsdG86 bmV0Y29uZkBpZXRmLm9yZyI+bmV0Y29uZkBpZXRmLm9yZzwvYT48YnI+CiAgICAgICAgICAgICAg PGI+U3ViamVjdDo8L2I+IElQUiBwb2xsIG9uCiAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1uZXRj b25mLW5vdGlmaWNhdGlvbi1jYXBhYmlsaXRpZXMtMDU8L3A+CiAgICAgICAgICA8L2Rpdj4KICAg ICAgICA8L2Rpdj4KICAgICAgICA8cD4mbmJzcDs8L3A+CiAgICAgICAgPHA+VG8gZWFjaCBhdXRo b3IgbGlzdGVkIG9uIHRoZSAiVG8iIGxpbmUuPGJyPgogICAgICAgICAgPGJyPgogICAgICAgICAg SW4gb3JkZXIgdG8gY29tcGxldGUgdGhlIFNoZXBoZXJkIHdyaXRldXAsIGFyZSB5b3UgYXdhcmUg b2YKICAgICAgICAgIGFueSBJUFIgdGhhdCBhcHBsaWVzPGJyPgogICAgICAgICAgdG8gZHJhZnQt aWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1jYXBhYmlsaXRpZXMtMDU/ICZuYnNwO1BsZWFzZQog ICAgICAgICAgUmVwbHktQWxsIHRvICp0aGlzKiBlbWFpbDwvcD4KICAgICAgICA8ZGl2PgogICAg ICAgICAgPHA+YW5kJm5ic3A7c3RhdGUgZWl0aGVyOjxicj4KICAgICAgICAgICAgPGJyPgogICAg ICAgICAgICAiTm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhp cyBkcmFmdCI8YnI+CiAgICAgICAgICAgIG9yPGJyPgogICAgICAgICAgICAiWWVzLCBJJ20gYXdh cmUgb2YgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Ijxicj4KICAgICAgICAgICAgPGJy PgogICAgICAgICAgICBJZiAieWVzIiwgaGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNv bXBsaWFuY2Ugd2l0aAogICAgICAgICAgICBJRVRGIElQUiBydWxlczxicj4KICAgICAgICAgICAg KHNlZSBSRkNzIDM2NjksIDUzNzggYW5kIDgxNzkgZm9yIG1vcmUgZGV0YWlscyk/PGJyPgogICAg ICAgICAgICA8YnI+CiAgICAgICAgICAgIElmICJ5ZXMiIGFnYWluLCBwbGVhc2Ugc3RhdGUgZWl0 aGVyOjxicj4KICAgICAgICAgICAgPGJyPgogICAgICAgICAgICAiWWVzLCB0aGUgSVBSIGhhcyBi ZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIKICAgICAgICAgICAgcnVs ZXMiPGJyPgogICAgICAgICAgICBvcjxicj4KICAgICAgICAgICAgIk5vLCB0aGUgSVBSIGhhcyBu b3QgYmVlbiBkaXNjbG9zZWQiPGJyPgogICAgICAgICAgICA8YnI+CiAgICAgICAgICAgIElmIHlv dSBhbnN3ZXIgbm8sIHBsZWFzZSBwcm92aWRlIGFueSBhZGRpdGlvbmFsIGRldGFpbHMgeW91CiAg ICAgICAgICAgIHRoaW5rIGFwcHJvcHJpYXRlLjxicj4KICAgICAgICAgICAgPGJyPgogICAgICAg ICAgICBJZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRv ciBwbGVhc2UKICAgICAgICAgICAgYW5zd2VyIHRoZSBhYm92ZSBieTxicj4KICAgICAgICAgICAg cmVzcG9uZGluZyB0byB0aGlzIGVtYWlsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBvciBub3QgeW91 CiAgICAgICAgICAgIGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQ8YnI+CiAgICAgICAgICAgIElQ Ui4gJm5ic3A7VGhpcyBkb2N1bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0IHN0YWdl IHVudGlsCiAgICAgICAgICAgIGEgcmVzcG9uc2UgaGFzIGJlZW48YnI+CiAgICAgICAgICAgIHJl Y2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5kIGxpc3RlZCBjb250cmlidXRvci4gJm5ic3A7Tk9U RToKICAgICAgICAgICAgVEhJUyBBUFBMSUVTIFRPIEFMTDxicj4KICAgICAgICAgICAgT0YgWU9V IExJU1RFRCBJTiBUSElTIE1FU1NBR0UnUyBUTyBMSU5FUy48YnI+CiAgICAgICAgICAgIDxicj4K ICAgICAgICAgICAgSWYgeW91IGFyZSBvbiB0aGUgV0cgZW1haWwgbGlzdCBvciBhdHRlbmQgV0cg bWVldGluZ3MgYnV0CiAgICAgICAgICAgIGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvcjxicj4K ICAgICAgICAgICAgb3IgY29udHJpYnV0b3IsIHdlIHJlbWluZCB5b3Ugb2YgeW91ciBvYmxpZ2F0 aW9ucyB1bmRlciB0aGUKICAgICAgICAgICAgSUVURiBJUFIgcnVsZXMgd2hpY2g8YnI+CiAgICAg ICAgICAgIGVuY291cmFnZXMgeW91IHRvIG5vdGlmeSB0aGUgSUVURiBpZiB5b3UgYXJlIGF3YXJl IG9mIElQUiBvZgogICAgICAgICAgICBvdGhlcnMgb24gYW4gSUVURjxicj4KICAgICAgICAgICAg Y29udHJpYnV0aW9uLCBvciB0byByZWZyYWluIGZyb20gcGFydGljaXBhdGluZyBpbiBhbnkKICAg ICAgICAgICAgY29udHJpYnV0aW9uIG9yIGRpc2N1c3Npb24gcmVsYXRlZDxicj4KICAgICAgICAg ICAgdG8geW91ciB1bmRpc2Nsb3NlZCBJUFIuIEZvciBtb3JlIGluZm9ybWF0aW9uLCBwbGVhc2Ug c2VlCiAgICAgICAgICAgIHRoZSBSRkNzIGxpc3RlZCBhYm92ZTxicj4KICAgICAgICAgICAgYW5k Jm5ic3A7PGEgaHJlZj0iaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvZ3JvdXAvaWVzZy90cmFj L3dpa2kvSW50ZWxsZWN0dWFsUHJvcGVydHkiPmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2dy b3VwL2llc2cvdHJhYy93aWtpL0ludGVsbGVjdHVhbFByb3BlcnR5PC9hPi48YnI+CiAgICAgICAg ICAgIDxicj4KICAgICAgICAgICAgVGhhbmsgeW91LDxicj4KICAgICAgICAgICAgS2VudCAvLyBh cyBib3RoIFNoZXBoZXJkIGFuZCBjby1DaGFpcjwvcD4KICAgICAgICA8L2Rpdj4KICAgICAgPC9k aXY+CiAgICA8L2Jsb2NrcXVvdGU+CiAgICA8YnI+CiAgPC9kaXY+CjwvYmxvY2txdW90ZT48L2Rp dj48YnI+PC9kaXY+PC9kaXY+PC9kaXY+ From nobody Tue Nov 5 19:45:25 2019 Return-Path: <0100016e3ed10fbb-8a5a44a9-6df6-4ac1-9b56-8dbf61ec64cc-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 78842120033 for ; Tue, 5 Nov 2019 19:45:23 -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 pxH4T3AdNKDs for ; Tue, 5 Nov 2019 19:45:20 -0800 (PST) Received: from a8-32.smtp-out.amazonses.com (a8-32.smtp-out.amazonses.com [54.240.8.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3369B12002E for ; Tue, 5 Nov 2019 19:45:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1573011918; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=JygmWiIH9P2Q/OohZPFOS1TWTiSq3f0LIWhKA6kw9l4=; b=GV4EJVoOonLJ6otptXEKPVKA8MQ2vyNp9yaYBwLRYZgZdwmvIfFHMmNyqk2wvddN QSIOWhbqXDXkSZ3UWLj6YWnrLUF2He5HqjUYCYGg7u8titR0St+8Mnsy++nU8OPS6p4 IVSj/S8MpFEzX0bFncqyittBFecjaCq/uV9IaS7Y= From: Kent Watsen Message-ID: <0100016e3ed10fbb-8a5a44a9-6df6-4ac1-9b56-8dbf61ec64cc-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_8EACB715-DF9B-4D04-9B90-7C2ED3D3F166" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 6 Nov 2019 03:45:18 +0000 In-Reply-To: Cc: "netconf@ietf.org" To: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= References: X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.11.06-54.240.8.32 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] FIXMEs in ietf-crypto-types and client/server models 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, 06 Nov 2019 03:45:23 -0000 --Apple-Mail=_8EACB715-DF9B-4D04-9B90-7C2ED3D3F166 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Bal=C3=A1zs, > I see some FIXMEs in ietf-crypto-types and related models. I would be = interested about the current state of them and possibility to clean them = up. Yes! thanks for taking this up. > Key-format (symmetric-key, public-key, asymmetric-key-pair) > I assume the idea here is to make it possible to have choices for the = ASN.1 types holding the keys. If this flexibility for formats is = necessary I don=E2=80=99t have any objection to them but having a single = agreed type for these different use cases would also suffice. I believe here you're referring to the 3 instances of lines like: leaf key { nacm:default-deny-all; type binary; //must "../key-format"; FIXME: remove comment if approach ok ... } FWIW, the whole "key-format" leaf is still being sussed out (your = opinion would be helpful on that thread as well) but, so far it seems = promising. The reason these lines are commented out is because 1) the = WG hasn't committed to this path yet and 2) I didn't want to update all = the examples in all the drafts (other than truststore and keystore) to = add a "key-format" leaf until the WG had more consensus on the = "key-format" leafs. I don't understand your last comment/sentence. Can you provide an = example? =20 > 2. attributes in asymmetric-key-pair-with-cert(s)-grouping > I think attributes should be kept optional. If there is anything else = besides subject seen mandatory maybe it should be extracted out from = attributes and be spelled out a separate leaf, but I don=E2=80=99t think = there is. I believe here you're referring to the 2 instances of lines like: leaf attributes { type binary; // FIXME: does this need to be mandatory? ... } These are in the "generate-certificate-signing-request" actions found = inside the asymmetric-key-pair-with-cert(s)-grouping. Hmmm, are you claiming that "attributes" are not required in order to = generate a CSR? I think the CSR itself MUST have attributes (right?) = so, if not specified, what default values are used? > PSK and raw public keys > The use case of PSK and raw public keys are not the most urgent in my = opinion which now slows a bit the progress of these drafts, but let=E2=80=99= s make an attempt to finalize them. Agreed, but they are legal for TLS and a WG member stated that they were = needed in order to support another IETF WG's efforts. A quick = resolution would be best! =20 > raw-public-keys: I see these were added due to RFC 7250 and 8446. I = guess in truststore this is a separate container to distinguish from SSH = host keys. For configuring the private part I think keystore already = gives support for this case with the asymmetric key (w/o cert) and in = the client/server drafts Kent=E2=80=99s proposal could be used (I = replaced raw public key with existing type, shouldn=E2=80=99t that be = useable straight away?) > =20 > container { > choice auth-type { > uses = ks:local-or-keystore-end-entity-cert-with-key-grouping; > uses = ks:local-or-keystore-asymmetric-key-grouping; >=20 > I would also prefer if these choices are in features, so that an = implementation can choose. To your first sentence, yes, "psk" (and "raw-public-key") are top-level = nodes in truststore, as can be seen here = (https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-07#section-2= .1 = ). Note, the trust-anchors draft accidentally doesn't include the = ietf-truststore.yang module. The body of your comment above seems to be about supporting the = secret-half of the PSK and RPK within the Keystore. I've raise this = question a couple times previously to Henk (who's asking for the PSK/RPK = add), but he's not responded yet as to if doing so is important (though = I can only imagine that it does). With that said, I think your YANG = snippet is meant to be in ietf-tls-server and ietf-tls-client modules = (right?). I'm having a hard time following the "I replaced raw public = key with existing type, shouldn=E2=80=99t that be useable straight = away?" comment. To your last sentence regarding features, could you provide an example = of what you mean? PS: none of this goes to the FIXME in the ietf-crypto-types. I had = previously asked Henk to provide some text here as well but, apparently, = like all of us at this time, he's been busy! > psk: given that the asymmetric keys without certs were covered by = host keys and raw public keys, I think psk should only be symmetric = keys. Symmetric keys are then sensitive/secret data and as such I = believe they should only be referenced from keystore. Seeing them in = truststore was unexpected for me. When it comes to their use, clients = and servers should be extended with following configuration (and I = assume we talk of TLS clients and servers only): > =20 > container { > choice auth-type { > uses = ks:local-or-keystore-end-entity-cert-with-key-grouping; > uses = ks:local-or-keystore-asymmetric-key-grouping; > uses = ks:local-or-keystore-symmetric-key-grouping; > =20 > Latter grouping would be a new one, but it would use existing = constructs and terms from keystore. I don=E2=80=99t think we need new = ones. Selected cipher suites will need to have PSK in them for using = symmetric key (similar match needed for the others). Note that symmetric = keys can be used for other cases than TLS PSK, for example SNMPv3 USM. = Again, features would be necessary (those could be saying x.509 or = raw-public-key or psk). Correct, I said the same (that PSKs are essentially symmetric keys) = before as well. Regarding only being referenced to keystore, why not = also support them being local-definitions too? Certainly not a problem = if encrypted and, even when not encrypted, then they can be "protected" = by NACM-like mechanisms, right? Why was/is seeing them in truststore a = surprise, perhaps because they're not encryptable there? I agree that = symmetric keys can be used beyond PSK (and encryption of the asymmetric = keys, the original use case). Regarding features, again, please provide = a YANG-snippet so it is clear to me (and all) what you mean. Thanks! Kent --Apple-Mail=_8EACB715-DF9B-4D04-9B90-7C2ED3D3F166 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Bal=C3=A1zs,


I = see some FIXMEs in ietf-crypto-types and related models. I would be = interested about the current state of them and possibility to clean them = up.

Yes!  thanks = for taking this up.


  1. Key-format (symmetric-key, public-key, = asymmetric-key-pair)
I assume the idea here is to make it possible to = have choices for the ASN.1 types holding the keys. If this flexibility = for formats is necessary I don=E2=80=99t have any objection to them but = having a single agreed type for these different use cases would also = suffice.

I = believe here you're referring to the 3 instances of lines = like:

    =   leaf key {
      =   nacm:default-deny-all;
      =   type binary;
      =   //must "../key-format";  FIXME: remove comment if = approach ok
        ...
 =     }

FWIW, the whole = "key-format" leaf is still being sussed out (your opinion would be = helpful on that thread as well) but, so far it seems promising. =  The reason these lines are commented out is because 1) the WG = hasn't committed to this path yet and 2) I didn't want to update all the = examples in all the drafts (other than truststore and keystore) to add a = "key-format" leaf until the WG had more consensus on the "key-format" = leafs.

I don't understand your last = comment/sentence.  Can you provide an example?

 
2.       attributes in = asymmetric-key-pair-with-cert(s)-grouping
I think attributes should be kept = optional. If there is anything else besides subject seen mandatory maybe = it should be extracted out from attributes and be spelled out a separate = leaf, but I don=E2=80=99t think there = is.

I believe = here you're referring to the 2 instances of lines like:

      =   leaf attributes {
    =       type binary; // FIXME: does this = need to be mandatory?
          = ...
        }

These are in the = "generate-certificate-signing-request" actions found inside = the asymmetric-key-pair-with-cert(s)-grouping.

Hmmm, are you claiming that "attributes" are not = required in order to generate a CSR?  I think the CSR itself MUST = have attributes (right?) so, if not specified, what default values are = used?



  1. PSK and raw public keys
The use = case of PSK and raw public keys are not the most urgent in my opinion = which now slows a bit the progress of these drafts, but let=E2=80=99s = make an attempt to finalize them.

Agreed, but they are legal for TLS and a WG member = stated that they were needed in order to support another IETF WG's = efforts.  A quick resolution would be best!

 
raw-public-keys: I see these were added due to RFC 7250 and = 8446. I guess in truststore this is a separate container to distinguish = from SSH host keys. For configuring the private part I think keystore = already gives support for this case with the asymmetric key (w/o cert) = and in the client/server drafts Kent=E2=80=99s proposal could be used (I = replaced raw public key with existing type, shouldn=E2=80=99t that be = useable straight away?)
 
        &= nbsp;         =   container <client-identity or server-identit= y> {
        &= nbsp;             = choice auth-type {
        &= nbsp;             =   =  uses ks:local-or-keystore-end-entity-cert-with-key-grouping;        &= nbsp;             =    uses ks:local-or-keystore-asymmetric-key-grouping;

I would also prefer if these choices = are in features, so that an implementation can = choose.

To your = first sentence, yes, "psk" (and "raw-public-key") are top-level nodes in = truststore, as can be seen here (https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-07= #section-2.1).   Note, the trust-anchors draft accidentally = doesn't include the ietf-truststore.yang module.

The body of your comment above seems to be about = supporting the secret-half of the PSK and RPK within the Keystore. =  I've raise this question a couple times previously to Henk (who's = asking for the PSK/RPK add), but he's not responded yet as to if doing = so is important (though I can only imagine that it does).   With = that said, I think your YANG snippet is meant to be in ietf-tls-server = and ietf-tls-client modules (right?).  I'm having a hard time = following the "I replaced raw = public key with existing type, shouldn=E2=80=99t that be useable = straight away?" comment.

To your last sentence regarding features, could you provide = an example of what you mean?

PS: none of this goes to the FIXME in the = ietf-crypto-types.  I had previously asked Henk to provide some = text here as well but, apparently, like all of us at this time, he's = been busy!


 psk: = given that the asymmetric keys without certs were covered by host keys = and raw public keys, I think psk should only be symmetric keys. = Symmetric keys are then sensitive/secret data and as such I believe they = should only be referenced from keystore. Seeing them in truststore was = unexpected for me. When it comes to their use, clients and servers = should be extended with following configuration (and I assume we talk of = TLS clients and servers only):
 
        &= nbsp;         =   container <client-identity or server-identit= y> {
        &= nbsp;             = choice auth-type {
        &= nbsp;             =   =  uses ks:local-or-keystore-end-entity-cert-with-key-grouping;        &= nbsp;             =    uses ks:local-or-keystore-asymmetric-key-grouping;
          &nb= sp;      =       uses ks:local-or-keystore-symmetric-key-grouping;
 
Latter grouping would be a new one, but it would use existing = constructs and terms from keystore. I don=E2=80=99t think we need new = ones. Selected cipher suites will need to have PSK in them for using = symmetric key (similar match needed for the others). Note that symmetric = keys can be used for other cases than TLS PSK, for example SNMPv3 USM. = Again, features would be necessary (those could be saying x.509 or = raw-public-key or psk).


Correct, I said the same = (that PSKs are essentially symmetric keys) before as well. =  Regarding only being referenced to keystore, why not also support = them being local-definitions too?  Certainly not a problem if = encrypted and, even when not encrypted, then they can be "protected" by = NACM-like mechanisms, right?   Why was/is seeing them in truststore = a surprise, perhaps because they're not encryptable there?  I agree = that symmetric keys can be used beyond PSK (and encryption of the = asymmetric keys, the original use case).  Regarding features, = again, please provide a YANG-snippet so it is clear to me (and all) what = you mean.


Thanks!
Kent

= --Apple-Mail=_8EACB715-DF9B-4D04-9B90-7C2ED3D3F166-- From nobody Tue Nov 5 23:56:17 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8071A120BFF for ; Tue, 5 Nov 2019 23:56:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 z0PCRD6yFH0r for ; Tue, 5 Nov 2019 23:56:12 -0800 (PST) Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) (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 037F7120C01 for ; Tue, 5 Nov 2019 23:56:11 -0800 (PST) Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id xA67u7fB015319 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Wed, 6 Nov 2019 08:56:08 +0100 Received: from [192.168.16.50] (79.234.112.245) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.468.0; Wed, 6 Nov 2019 08:56:02 +0100 To: Kent Watsen , =?UTF-8?B?QmFsw6F6cyBLb3bDoWNz?= CC: "netconf@ietf.org" References: <0100016e3ed10fbb-8a5a44a9-6df6-4ac1-9b56-8dbf61ec64cc-000000@email.amazonses.com> From: Henk Birkholz Message-ID: <2b0daa52-10e4-566b-6e66-760dbd47c24b@sit.fraunhofer.de> Date: Wed, 6 Nov 2019 08:56:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <0100016e3ed10fbb-8a5a44a9-6df6-4ac1-9b56-8dbf61ec64cc-000000@email.amazonses.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [79.234.112.245] Archived-At: Subject: Re: [netconf] FIXMEs in ietf-crypto-types and client/server models 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, 06 Nov 2019 07:56:16 -0000 Hi Balázs, hi list, Item 3.) is on me, I think. Sorry! For me personally, there are a few technical questions that have to be resolved on the list first. Under the assumption that the trust stores will be used for TLS (maybe potential other things), I am not sure if the YANG module is an appropriate place to make some (maybe implicit?) "mandatory-to-implement" decisions. If there can be (and I think effectively there should be, but I do not know the appropriate place for them) prescriptive statements here, I would recommend the following proposals for the use with TLS: 1.) With respect to the format of the "raw" pub-key, I propose that the structure defined in section 3 of RFC 7250 MUST be used. 2.) With respect to cipher suite and interoperability, I propose to make RFC 7151 and RFC 4492 (basically the NIST curve and its format extensions) mti for raw pub-key and to point to RFC 7250 for guidance & to make RFC6635 mti for psk. 3.) With respect to key identities, I propose that raw pub-key identities as specified in RFC 6920 and a minimum hash length enabled by mode sha-256-120 MUST be used & to support and recommend the use of Identity Hints (section 5.2. in RFC 4279) for PSKs and refer to the corresponding security considerations (section 7 in RFC 4279). My first question - on a technical level: do these proposals in the context of using TLS sound reasonable to the group? My second question - on a semantic level: do these normative requirements belong here? My third question - on a noob level :) If they belong here, where would these mandatory requirements be spelled out? Viele Grüße, Henk On 06.11.19 04:45, Kent Watsen wrote: > > Hi Balázs, > > >> I see some FIXMEs in ietf-crypto-types and related models. I would be >> interested about the current state of them and possibility to clean >> them up. > > Yes!  thanks for taking this up. > > >> 1. Key-format (symmetric-key, public-key, asymmetric-key-pair) >> >> I assume the idea here is to make it possible to have choices for the >> ASN.1 types holding the keys. If this flexibility for formats is >> necessary I don’t have any objection to them but having a single >> agreed type for these different use cases would also suffice. > > I believe here you're referring to the 3 instances of lines like: > >       leaf key { >         nacm:default-deny-all; >         type binary; >         //must "../key-format";  FIXME: remove comment if approach ok >         ... >       } > > FWIW, the whole "key-format" leaf is still being sussed out (your > opinion would be helpful on that thread as well) but, so far it seems > promising.  The reason these lines are commented out is because 1) the > WG hasn't committed to this path yet and 2) I didn't want to update all > the examples in all the drafts (other than truststore and keystore) to > add a "key-format" leaf until the WG had more consensus on the > "key-format" leafs. > > I don't understand your last comment/sentence.  Can you provide an example? > >> 2.attributes in asymmetric-key-pair-with-cert(s)-grouping >> I think attributes should be kept optional. If there is anything else >> besides subject seen mandatory maybe it should be extracted out from >> attributes and be spelled out a separate leaf, but I don’t think there is. > > I believe here you're referring to the 2 instances of lines like: > >         leaf attributes { >           type binary; // FIXME: does this need to be mandatory? >           .... >         } > > These are in the "generate-certificate-signing-request" actions found > inside the asymmetric-key-pair-with-cert(s)-grouping. > > Hmmm, are you claiming that "attributes" are not required in order to > generate a CSR?  I think the CSR itself MUST have attributes (right?) > so, if not specified, what default values are used? > > > >> 3. PSK and raw public keys >> >> The use case of PSK and raw public keys are not the most urgent in my >> opinion which now slows a bit the progress of these drafts, but let’s >> make an attempt to finalize them. > > Agreed, but they are legal for TLS and a WG member stated that they were > needed in order to support another IETF WG's efforts.  A quick > resolution would be best! > > >> raw-public-keys: I see these were added due to RFC 7250 and 8446. I >> guess in truststore this is a separate container to distinguish from >> SSH host keys. For configuring the private part I think keystore >> already gives support for this case with the asymmetric key (w/o cert) >> and in the client/server drafts Kent’s proposal could be used (I >> replaced raw public key with existing type, shouldn’t that be useable >> straight away?) >>     container  { >>       choice auth-type { >>          uses ks:local-or-keystore-end-entity-cert-with-key-grouping; >>          uses ks:local-or-keystore-asymmetric-key-grouping; >> >> I would also prefer if these choices are in features, so that an >> implementation can choose. > > To your first sentence, yes, "psk" (and "raw-public-key") are top-level > nodes in truststore, as can be seen here > (https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-07#section-2.1). >   Note, the trust-anchors draft accidentally doesn't include the > ietf-truststore.yang module. > > The body of your comment above seems to be about supporting the > secret-half of the PSK and RPK within the Keystore.  I've raise this > question a couple times previously to Henk (who's asking for the PSK/RPK > add), but he's not responded yet as to if doing so is important (though > I can only imagine that it does).   With that said, I think your YANG > snippet is meant to be in ietf-tls-server and ietf-tls-client modules > (right?).  I'm having a hard time following the "I replaced raw public > key with existing type, shouldn’t that be useable straight away?" comment. > > To your last sentence regarding features, could you provide an example > of what you mean? > > PS: none of this goes to the FIXME in the ietf-crypto-types.  I had > previously asked Henk to provide some text here as well but, apparently, > like all of us at this time, he's been busy! > > >> psk: given that the asymmetric keys without certs were covered by host >> keys and raw public keys, I think psk should only be symmetric keys. >> Symmetric keys are then sensitive/secret data and as such I believe >> they should only be referenced from keystore. Seeing them in >> truststore was unexpected for me. When it comes to their use, clients >> and servers should be extended with following configuration (and I >> assume we talk of TLS clients and servers only): >>     container  { >>       choice auth-type { >>          uses ks:local-or-keystore-end-entity-cert-with-key-grouping; >>          uses ks:local-or-keystore-asymmetric-key-grouping; >>                        uses ks:/local-or-keystore-symmetric-key-grouping/; >> Latter grouping would be a new one, but it would use existing >> constructs and terms from keystore. I don’t think we need new ones. >> Selected cipher suites will need to have PSK in them for using >> symmetric key (similar match needed for the others). Note that >> symmetric keys can be used for other cases than TLS PSK, for example >> SNMPv3 USM. Again, features would be necessary (those could be saying >> x.509 or raw-public-key or psk). > > > Correct, I said the same (that PSKs are essentially symmetric keys) > before as well.  Regarding only being referenced to keystore, why not > also support them being local-definitions too?  Certainly not a problem > if encrypted and, even when not encrypted, then they can be "protected" > by NACM-like mechanisms, right?   Why was/is seeing them in truststore a > surprise, perhaps because they're not encryptable there?  I agree that > symmetric keys can be used beyond PSK (and encryption of the asymmetric > keys, the original use case).  Regarding features, again, please provide > a YANG-snippet so it is clear to me (and all) what you mean. > > > Thanks! > Kent > > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Wed Nov 6 01:53:38 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 867C712080E for ; Wed, 6 Nov 2019 01:53:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 wIiBA_9swvyr for ; Wed, 6 Nov 2019 01:53:35 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D374A12080D for ; Wed, 6 Nov 2019 01:53:34 -0800 (PST) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 009521AE018B; Wed, 6 Nov 2019 10:53:32 +0100 (CET) Date: Wed, 06 Nov 2019 10:53:03 +0100 (CET) Message-Id: <20191106.105303.176994873055471743.mbj@tail-f.com> To: kent+ietf@watsen.net Cc: netconf@ietf.org From: Martin Bjorklund In-Reply-To: <0100016e2de6a66d-ff5aea75-edfc-4d98-8c0e-95674c411430-000000@email.amazonses.com> References: <0100016e2de6a66d-ff5aea75-edfc-4d98-8c0e-95674c411430-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] today's updates to the client-server suite of drafts 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, 06 Nov 2019 09:53:37 -0000 Hi, What happened to the YANG module in draft-ietf-netconf-trust-anchors-07? It just has: file "ietf-truststore@2019-11-02.yang" /martin Kent Watsen wrote: > > The biggest change is in the crypto-types draft, as it continues to > try to grapple with the "algorithm" problem. > > I don't think there is consensus for having distinct "iana-" modules > for each type of algorithm yet. For one, if it were a module to be be > supported by IANA, one might expect more of a template but, as the > algorithm-lists pull from numerous RFCs, how to make a template wasn't > clear to me and, besides, having a distinct module for each type of > algorithm became a convenient way to define a "config false" list for > the algorithms supported by the server. > > In any case, I offer this update to the WG for discussion. Below are > the change logs for each draft. > > Kent // contributor > > > ===== change logs ===== > > crypto-types: > > o Removed all non-essential (to NC/RC) algorithm types. > > o Moved remaining algorithm types each into its own module. > > o Added a 'config false' "algorithms-supported" list to each of the > algorithm-type modules. > > > > trust-anchors (truststore): > > o Added Henk Birkholz as a co-author (thanks Henk!) > > o Added PSKs and raw public keys to Truststore. > > > > keystore: > > o Updated YANG module and examples to incorporate the new > iana-*-algorithm modules in the crypto-types draft. > > > > tcp-client-server > > o No update. > > > > > ssh-client-server > > o Removed unnecessary if-feature statements in the -client and > -server modules. > > o Cleaned up some description statements in the -client and -server > modules. > > o Fixed a canonical ordering issue in ietf-ssh-common detected by > new pyang. > > > > tls-client-server > > o Removed unnecessary if-feature statements in the -client and > -server modules. > > o Cleaned up some description statements in the -client and -server > modules. > > o Fixed a canonical ordering issue in ietf-ssh-common detected by > new pyang. > > > > http-client-server > > o Removed "protocol-version" leaf in http-client-grouping. > > > > netconf-client-server > > o Added refinement to make "cert-to-name/fingerprint" be mandatory > false. > > o Commented out refinement to "tls-server-grouping/client- > authentication" until a better "must" expression is defined. > > > > restconf-client-server > > o Added refinement to make "cert-to-name/fingerprint" be mandatory > false. > > o Commented out refinement to "tls-server-grouping/client- > authentication" until a better "must" expression is defined. > > o Updated restconf-client example to reflect that http-client- > grouping no longer has a "protocol-version" leaf. > > From nobody Wed Nov 6 05:29:02 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1EE1120904 for ; Wed, 6 Nov 2019 05:28:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 6GI4Lv6bleZI for ; Wed, 6 Nov 2019 05:28:54 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 071F0120C6F for ; Wed, 6 Nov 2019 05:28:53 -0800 (PST) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id A41361AE018B; Wed, 6 Nov 2019 14:28:51 +0100 (CET) Date: Wed, 06 Nov 2019 14:28:22 +0100 (CET) Message-Id: <20191106.142822.2117534105126283386.mbj@tail-f.com> To: kent+ietf@watsen.net Cc: netconf@ietf.org From: Martin Bjorklund In-Reply-To: <0100016e39631e46-c007fd65-2e51-47a6-bd27-764f5257a16c-000000@email.amazonses.com> References: <20191104.111319.869021723410428870.mbj@tail-f.com> <0100016e39631e46-c007fd65-2e51-47a6-bd27-764f5257a16c-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] client identification in ietf-netconf-server 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, 06 Nov 2019 13:29:01 -0000 Hi, Kent Watsen wrote: > Hi Martin, > > > > The ietf-netconf-server module has this: > > > > grouping netconf-server-grouping { > > ... > > container client-identification { > > ... > > container cert-maps { > > when "../../../../tls"; > > uses x509c2n:cert-to-name; > > ... > > } > > } > > } > > > > Note the "when" expression. This means that the grouping has a strong > > depency on where is it used. We should try to avoid such a design. > > > Would this be better? > > OLD > when "../../../../tls"; > > NEW > if-feature "tls-listen or tls-call-home"; Yes, but see below. > > But should't this cert-to-name list be available when x509-certs are > > used also with SSH? > > Hmmm. I'd assumed that, with RFC 6187, the username was still passed > as its own field, but I see this in Section 4: > > For the purposes of user authentication, the mapping between > certificates and user names is left as an implementation and > configuration issue for implementers and system administrators. If the username was used as identification it would mean that with a valid cert I could present myself as any user! > So you may be right about that. I only ever looked at RFC 6187 from > the perspective of the server presenting an IDevID certificate. But, > assuming it's true, then perhaps this: > > NEWEST: > if-feature "tls-listen or tls-call-home or sshcmn:ssh-x509-certs"; Ok. This gives: grouping netconf-server-grouping { description ...; container client-identification { description "Specifies a mapping through which clients MAY be identified (i.e., the NETCONF username) from a supplied certificate. Note that a client MAY alternatively be identified via an alternate authentication scheme."; container cert-maps { if-feature "tls-listen or tls-call-home or sshcmn:ssh-x509-certs"; But since the description of the "client-identification" says that it is used only with certificates, perhaps that container's name should reflect this, and the if-feature statement moved to that container? Perhaps: container client-cert-identification if-feature "tls-listen or tls-call-home or sshcmn:ssh-x509-certs"; and also perhaps remove 'cert-maps', and use the cert-to-name grouping directly here? > > The current data model for ssh specifies certs on > > a per-user basis. But this requires lots of configuration in the case > > that the cert encodes the user name (even though the name is in the > > cert you have to configure each user on each device). I suggest we > > align the model for SSH with the TLS model for cert identification. > > We certainly want to factor out configuration where possible. I'd > need to look into this more. Perhaps you can send a diff? Today we have under 'ssh-server-parameters/client-authentication': +--:(local) {local-client-auth-supported}? +--rw users +--rw user* [name] +--rw name string +--rw password? ianach:crypt-hash +--rw host-keys! | +--rw (local-or-truststore) | +--:(local) {local-definitions-supported}? | | +--rw local-definition | | +--rw host-key* ct:ssh-host-key | | +--rw cert* trust-anchor-cert-cms | | +---n certificate-expiration | | +-- expiration-date yang:date-and-time | +--:(truststore) {truststore-supported,ssh-host-keys}? | +--rw truststore-reference? ts:host-keys-ref +--rw ca-certs! {sshcmn:ssh-x509-certs}? | +--rw (local-or-truststore) | +--:(local) {local-definitions-supported}? | | +--rw local-definition | | +--rw cert* trust-anchor-cert-cms | | +---n certificate-expiration | | +-- expiration-date yang:date-and-time | +--:(truststore) {truststore-supported,x509-certificates}? | +--rw truststore-reference? ts:certificates-ref +--rw client-certs! {sshcmn:ssh-x509-certs}? +--rw (local-or-truststore) +--:(local) {local-definitions-supported}? | +--rw local-definition | +--rw cert* trust-anchor-cert-cms | +---n certificate-expiration | +-- expiration-date yang:date-and-time +--:(truststore) {truststore-supported,x509-certificates}? +--rw truststore-reference? ts:certificates-ref I think host-keys, ca-certs and client-certs should be moved out of the user list: +--:(local) {local-client-auth-supported}? +--rw users | +--rw user* [name] | +--rw name string | +--rw password? ianach:crypt-hash +--rw host-keys! | +--rw (local-or-truststore) | +--:(local) {local-definitions-supported}? | | +--rw local-definition | | +--rw host-key* ct:ssh-host-key | | +--rw cert* trust-anchor-cert-cms | | +---n certificate-expiration | | +-- expiration-date yang:date-and-time | +--:(truststore) {truststore-supported,ssh-host-keys}? | +--rw truststore-reference? ts:host-keys-ref +--rw ca-certs! {sshcmn:ssh-x509-certs}? | +--rw (local-or-truststore) | +--:(local) {local-definitions-supported}? | | +--rw local-definition | | +--rw cert* trust-anchor-cert-cms | | +---n certificate-expiration | | +-- expiration-date yang:date-and-time | +--:(truststore) {truststore-supported,x509-certificates}? | +--rw truststore-reference? ts:certificates-ref +--rw client-certs! {sshcmn:ssh-x509-certs}? +--rw (local-or-truststore) +--:(local) {local-definitions-supported}? | +--rw local-definition | +--rw cert* trust-anchor-cert-cms | +---n certificate-expiration | +-- expiration-date yang:date-and-time +--:(truststore) {truststore-supported,x509-certificates}? +--rw truststore-reference? ts:certificates-ref But also here I think that the choice "local-or-external" isn't ideal. I think that a system that implements some "external" mechanism should/would augement this data model with specific nodes for that mechanism. As a simplistic example: augment /netconf-server/.../client-authentication { leaf use-host-keys-in-filesystem { leaf boolean; } } In this case, requiring the client to configure both this new leaf and "client-auth-defined-elsewhere" seems redundant and non-intuitive. Another case is a system that *always* use the filesystem host keys. It would simply just always do that, and again, requiring the client to configure "client-auth-defined-elsewhere" seems incorrect. So my suggestion is to remove the choice "local-or-external" and remove the external case, and instead document that (i) systems may use some other hard-wired mechanism or (ii) other modules can augment this container with additional control parameters for other mechanisms. > > For TLS, the data model has the following structure: > > > > +--rw netconf-server > > +--rw listen! {ssh-listen or tls-listen}? > > +--rw idle-timeout? uint16 > > +--rw endpoint* [name] > > +--rw name string > > +--rw (transport) > > ... > > +--:(tls) {tls-listen}? > > > > [ reset indentation to make the diagram easier to read ] > > > > +--rw tls > > +--rw tcp-server-parameters > > ... > > +--rw tls-server-parameters > > | +--rw server-identity > > ... > > | +--rw client-authentication! > > | | +--rw (required-or-optional) > > | | | +--:(required) > > | | | | +--rw required? empty > > | | | +--:(optional) > > | | | +--rw optional? empty > > | | +--rw (local-or-external) > > | | +--:(local) {local-client-auth-supported}? > > | | | +--rw ca-certs! {ts:x509-certificates}? > > | | | | +--rw (local-or-truststore) > > | | | | +--:(local) {local-definitions-supported}? > > | | | | | +--rw local-definition > > | | | | | +--rw cert* trust-anchor-cert-cms > > | | | | | +---n certificate-expiration > > | | | | | +-- expiration-date > > | | | | | yang:date-and-time > > | | | | +--:(truststore) > > | | | | {truststore-supported,x509-certificates}? > > | | | | +--rw truststore-reference? > > | | | | ts:certificates-ref > > | | | +--rw client-certs! {ts:x509-certificates}? > > | | | +--rw (local-or-truststore) > > | | | +--:(local) {local-definitions-supported}? > > | | | | +--rw local-definition > > | | | | +--rw cert* trust-anchor-cert-cms > > | | | | +---n certificate-expiration > > | | | | +-- expiration-date > > | | | | yang:date-and-time > > | | | +--:(truststore) > > | | | {truststore-supported,x509-certificates}? > > | | | +--rw truststore-reference? > > | | | ts:certificates-ref > > | | +--:(external) > > | | {external-client-auth-supported}? > > | | +--rw client-auth-defined-elsewhere? > > | | empty > > ... > > +--rw netconf-server-parameters > > +--rw client-identification > > +--rw cert-maps > > +--rw cert-to-name* [id] > > +--rw id uint32 > > +--rw fingerprint > > | x509c2n:tls-fingerprint > > +--rw map-type identityref > > +--rw name string > > > > > > It is not clear how this is used by the server to end up either with > > an authenticated user name or failed authentication. > > Okay, let's fix that. > > > > First of all, how is the "required-or-optional" choice used in a > > NETCONF server? What happens if an operation configures this to > > "optional"? (side note: why is this a choice of empty leafs instead > > of a leaf?) > > Hmmm, this 'choice' seems unneeded for NETCONF. The "choice" is > coming from the ietf-tls-server, and a similar "choice" is in > ietf-http-server. It was put there, in part, for RESTCONF, as > user-auth can occur at either (or both!) protocol layers... Ok. Yes, the RESTCONF auth mechanism is interesting. Let's discuss that in a separate thread. > > Second, I assume that the idea is that the server uses the config > > params in "local-or-external" and the certificate presented by the > > client and after this step is either accepted or rejected. It is not > > clear what is supposed to happen if someone configures > > "client-auth-defined-elsewhere". I think it is better to not define > > this case, but (perhaps) keep the choice and explain that other > > modules can augment additional config params here for other > > authentication mechanisms. > > Well that's just the thing, the goal is to enable user-auth to NOT be > defined here. As the description statement in ietf-tls-server says: > > "Configuring credentials externally enables applications > to place client authentication with client definitions, > rather then in a part of a data model principally > concerned with configuring the TLS transport."; I totally agree with this. I am questioning the solution. See above for my proposal. > > Next, my guess is that the intention is that if the cert was accepted > > in the step above, it is checked in cert-to-name to see if a user name > > can be derived. > > Yes. > > > > In another thread you mentioned that if a local cert is configured, it > > seems redundant to also configure the cert as a fingerprint in > > cert-to-name. I'm not sure about this. But perhaps you can use the > > same "map-type" and "name" leafs in the "client-cert" container? It > > is not as easy for the "truststore-reference"; perhaps you'd have to > > augment the truststore with these leafs in this case. > > In context, that statement I made before is a relatively minor > objection. That said, I don't understand your proposal, as you > suggesting the recreate the essence of 'cert-to-name'? Another idea I > had was that the fingerprint could be in a "union" with also a > truststore-reference, which is only mildly better... Aha, now I understand your suggestion of making fingerprint optional. I agree that this could work. However, I assume it must be used with care. If you know for sure that a successful result from the authentication mechanism means that CA cert X has been used, you can save some typing by not configuring the fingerprint of X. So the question is if it is worth it? /martin From nobody Wed Nov 6 06:27:25 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 028E91208AE for ; Wed, 6 Nov 2019 06:27: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjeQKA1DVqlX for ; Wed, 6 Nov 2019 06:27:19 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00050.outbound.protection.outlook.com [40.107.0.50]) (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 4BFCF1200F9 for ; Wed, 6 Nov 2019 06:27:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QUy4FsLT3VyxuXvmjBvEBUVmCunk7coMMBNZ3SoBeST7BtNrt2IycIbKa0Hrbpk7xBJIrI6Nq/jQ7X60O80Dfgqo4wQK18H/jHlJV7Yaf1T+ZM00c8ST4KPZf8Xi2DcWWvv8kJ8IIpUXVlc/1WrdYy5CXicqb69LzaVGBesRRFZdkkevDpfpE06I00MLX4C/Rq2E6WhgjuQps1qLGrl8g6Lq0xy7S7SnzxqMtuo3gvochkUeaSMVcda4J199Fl/KyXmVZW3jVWQvns2KaXSaa/77VqxGQDEUZgH3Mew9vnf3H4LabwiqcbPTPAYG8S2d2fe4kDKPOTT7kVmM8INkcg== 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=ahXa1McKFQr6qS7sG0AYoDZWR68oYYdJD0n0q+SXnnM=; b=NDIoff/n8WnFGD9FXMGuLHoXsi86a9ot2YqscZKw3W08oQ7Owpab6HBVFJXM7Z7CczSIm4DyIWhPZFeYbZThFvhJox3OFUl9adW2Cixl+PF3rP6HFcHf1ggOqkdJdaOvNy9f4Rp821STHZ88Kn4urLmj3NeepGHjs2C1u3ICbxX2FoMCVWQ8Wz20VB5BsSLggNOqlU1Yz1Qhlr3Cxm8neEc2gv8xpp/0U1KjYiP+isDpPRw0/ysJtZXDvS+m/XM118IGnFF3tyFEIa4HKiE7JoAZEN8b7O264Qg/03YdAyL98W4o4pdqb+RtNQ2BYNgWIxzlnF6a9QDAvldX0JAxyg== 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=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ahXa1McKFQr6qS7sG0AYoDZWR68oYYdJD0n0q+SXnnM=; b=Vmhzp2Rt+Rw3qerZPqqh/VkzVxvILj113zxikUhPLwkNY9EWLSjqqG1WfZmkzisvcjiNrpTnobA6GIVWN40gg1Atrscy/V7ukHvQXZb8IewdUVuHXldIU97HoX7C7dj8nwnRjMSZoY4KYAd5tR65T7N6zgZCxbtfbgOpEOiPYxw= Received: from AM0PR07MB5187.eurprd07.prod.outlook.com (20.178.20.74) by AM0PR07MB4673.eurprd07.prod.outlook.com (52.135.148.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.13; Wed, 6 Nov 2019 14:27:16 +0000 Received: from AM0PR07MB5187.eurprd07.prod.outlook.com ([fe80::f016:8dc4:2887:cacd]) by AM0PR07MB5187.eurprd07.prod.outlook.com ([fe80::f016:8dc4:2887:cacd%3]) with mapi id 15.20.2430.013; Wed, 6 Nov 2019 14:27:10 +0000 From: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= To: Kent Watsen CC: "netconf@ietf.org" Thread-Topic: FIXMEs in ietf-crypto-types and client/server models Thread-Index: AdWT66zB5kr5iNWxQ6yg/MeI8i6GNgAaO58AABS9kxA= Date: Wed, 6 Nov 2019 14:27:10 +0000 Message-ID: References: <0100016e3ed10fbb-8a5a44a9-6df6-4ac1-9b56-8dbf61ec64cc-000000@email.amazonses.com> In-Reply-To: <0100016e3ed10fbb-8a5a44a9-6df6-4ac1-9b56-8dbf61ec64cc-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.kovacs@ericsson.com; x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e6cc8616-173e-49c5-f24c-08d762c568b5 x-ms-traffictypediagnostic: AM0PR07MB4673: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 02135EB356 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(346002)(396003)(376002)(136003)(366004)(189003)(199004)(52536014)(85202003)(606006)(6246003)(33656002)(81156014)(14454004)(66556008)(66476007)(74316002)(478600001)(6506007)(8936002)(446003)(476003)(11346002)(76116006)(81166006)(8676002)(561944003)(486006)(4326008)(66446008)(64756008)(790700001)(6116002)(2906002)(3846002)(14444005)(186003)(256004)(7736002)(102836004)(66946007)(26005)(66066001)(76176011)(7696005)(6436002)(316002)(55016002)(99286004)(71190400001)(5660300002)(85182001)(71200400001)(9326002)(229853002)(6306002)(236005)(86362001)(25786009)(54896002)(9686003)(170073001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB4673; 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: 8fkplE8pFtwkiD+znVJiTuHPsGO6ujCIjkAdcmihWi95qcUAH26v0PrGwqD+h5kD97NPlUnh0jSE1R57VwtbXiWTepKn8kazffEULYhLfFbPwRF72CApUu2Gi5FeKWFeiUPWd589KFZd0rzEgZd0YvR6Lzdv1f3Z+wPB1YBRd3Rcb5k/64S8UxhWFKGb9w2FKNPh46y9plFoO6H84gelXFYuIBv5ddrUoD0/BaXBq3HSmGkDei+nnIrhCgH/6qlWvhjxknmDcJg4HoNlKEA7V+5OgrGldk0srmCLIVKf/WbbYN+Sdy2e27hjog32XbzPEu+rECJi3ydopiaZxkUowFhPOOk057ZnaNEUaNasiczbEi2C7qw+m9eA7CA08xs1Sxzu/UqNpBuaYlfYXO8JnshCjTBrTY65pqKTRBBN9xyg9KacNEnuo3tquJfR63dYklF1KDVmDlv6lnEWGiBYiPm8RiTSoV3G3GLs4oJzGqM= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR07MB5187296C56CCE38DADE9EA1483790AM0PR07MB5187eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: e6cc8616-173e-49c5-f24c-08d762c568b5 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2019 14:27:10.0278 (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: 0ujycrVWFpfMIdCKVaiawVhKsrjpznZP1u7ueV3W08gsI/9dymablCpyhd4z/vNttdU2kEKp4LHD7oSbdS76A4Soimjn6PEm6VxEEzm6uLo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4673 Archived-At: Subject: Re: [netconf] FIXMEs in ietf-crypto-types and client/server models 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, 06 Nov 2019 14:27:23 -0000 --_000_AM0PR07MB5187296C56CCE38DADE9EA1483790AM0PR07MB5187eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2VudCwNCg0KDQoNCjEuICAgICAgIEtleS1mb3JtYXQgKHN5bW1ldHJpYy1rZXksIHB1Ymxp Yy1rZXksIGFzeW1tZXRyaWMta2V5LXBhaXIpDQpJIGFzc3VtZSB0aGUgaWRlYSBoZXJlIGlzIHRv IG1ha2UgaXQgcG9zc2libGUgdG8gaGF2ZSBjaG9pY2VzIGZvciB0aGUgQVNOLjEgdHlwZXMgaG9s ZGluZyB0aGUga2V5cy4gSWYgdGhpcyBmbGV4aWJpbGl0eSBmb3IgZm9ybWF0cyBpcyBuZWNlc3Nh cnkgSSBkb27igJl0IGhhdmUgYW55IG9iamVjdGlvbiB0byB0aGVtIGJ1dCBoYXZpbmcgYSBzaW5n bGUgYWdyZWVkIHR5cGUgZm9yIHRoZXNlIGRpZmZlcmVudCB1c2UgY2FzZXMgd291bGQgYWxzbyBz dWZmaWNlLg0KDQpJIGJlbGlldmUgaGVyZSB5b3UncmUgcmVmZXJyaW5nIHRvIHRoZSAzIGluc3Rh bmNlcyBvZiBsaW5lcyBsaWtlOg0KDQogICAgICBsZWFmIGtleSB7DQogICAgICAgIG5hY206ZGVm YXVsdC1kZW55LWFsbDsNCiAgICAgICAgdHlwZSBiaW5hcnk7DQogICAgICAgIC8vbXVzdCAiLi4v a2V5LWZvcm1hdCI7ICBGSVhNRTogcmVtb3ZlIGNvbW1lbnQgaWYgYXBwcm9hY2ggb2sNCiAgICAg ICAgLi4uDQogICAgICB9DQoNCkZXSVcsIHRoZSB3aG9sZSAia2V5LWZvcm1hdCIgbGVhZiBpcyBz dGlsbCBiZWluZyBzdXNzZWQgb3V0ICh5b3VyIG9waW5pb24gd291bGQgYmUgaGVscGZ1bCBvbiB0 aGF0IHRocmVhZCBhcyB3ZWxsKSBidXQsIHNvIGZhciBpdCBzZWVtcyBwcm9taXNpbmcuICBUaGUg cmVhc29uIHRoZXNlIGxpbmVzIGFyZSBjb21tZW50ZWQgb3V0IGlzIGJlY2F1c2UgMSkgdGhlIFdH IGhhc24ndCBjb21taXR0ZWQgdG8gdGhpcyBwYXRoIHlldCBhbmQgMikgSSBkaWRuJ3Qgd2FudCB0 byB1cGRhdGUgYWxsIHRoZSBleGFtcGxlcyBpbiBhbGwgdGhlIGRyYWZ0cyAob3RoZXIgdGhhbiB0 cnVzdHN0b3JlIGFuZCBrZXlzdG9yZSkgdG8gYWRkIGEgImtleS1mb3JtYXQiIGxlYWYgdW50aWwg dGhlIFdHIGhhZCBtb3JlIGNvbnNlbnN1cyBvbiB0aGUgImtleS1mb3JtYXQiIGxlYWZzLg0KDQpJ IGRvbid0IHVuZGVyc3RhbmQgeW91ciBsYXN0IGNvbW1lbnQvc2VudGVuY2UuICBDYW4geW91IHBy b3ZpZGUgYW4gZXhhbXBsZT8NCg0KQmFsYXpzPiBPaywgdGhlbiBsZXTigJlzIHdhaXQgZm9yIFdH IGRlY2lzaW9uLiBXZWxsLCBJIGp1c3Qgc2F5IHRoYXQgdGhlIGVhcmxpZXIgd2F5cyBvZiBjb21t dW5pY2F0aW5nIHRoZSBrZXkgZm9ybWF0cyB3ZXJlIGFkZXF1YXRlIGZyb20gbXkgcG9pbnQgb2Yg dmlldywgd2hpY2ggd2FzIHRoYXQgaW4gZG9jdW1lbnRhdGlvbiBpdCB3YXMgc2FpZCB0aGF0IGZv ciBSU0EgdXNlIFJTQVByaXZhdGVLZXkgYW5kIGZvciBFQyB1c2UgRUNQcml2YXRlS2V5LCBhbmQg c2ltaWxhcmx5IGZvciBvdGhlciB0eXBlcy4gSeKAmW0gYWxzbyBvayB3aXRoIHRoZSBrZXktZm9y bWF0IGFwcHJvYWNoIGlmIHByZWZlcnJlZCBieSB0aGUgV0cuDQoNCkluIGVhcmxpZXIgdmVyc2lv bnM6DQoNCiAgICAgICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgICAgICAiVGhlIHZhbHVlIG9m IHRoZSBiaW5hcnkga2V5LiAgVGhlIGtleSdzIHZhbHVlIGlzDQogICAgICAgICAgICAgIGludGVy cHJldGVkIGJ5IHRoZSAnYWxnb3JpdGhtJy4gIEZvciBleGFtcGxlLCBhIERTQSBrZXkNCiAgICAg ICAgICAgICAgaXMgYW4gaW50ZWdlciwgYW4gUlNBIGtleSBpcyByZXByZXNlbnRlZCBhcyBSU0FQ cml2YXRlS2V5DQogICAgICAgICAgICAgIGFzIGRlZmluZWQgaW4gUkZDIDgwMTc8aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzgwMTc+LCBhbmQgYW4gRUNDIGtleSBpcyByZXByZXNlbnRl ZCBhcw0KICAgICAgICAgICAgICBFQ1ByaXZhdGVLZXkgYXMgZGVmaW5lZCBpbiBSRkMgNTkxNTxo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTkxNT4uIg0KDQoNCjIuICAgICAgIGF0dHJp YnV0ZXMgaW4gYXN5bW1ldHJpYy1rZXktcGFpci13aXRoLWNlcnQocyktZ3JvdXBpbmcNCkkgdGhp bmsgYXR0cmlidXRlcyBzaG91bGQgYmUga2VwdCBvcHRpb25hbC4gSWYgdGhlcmUgaXMgYW55dGhp bmcgZWxzZSBiZXNpZGVzIHN1YmplY3Qgc2VlbiBtYW5kYXRvcnkgbWF5YmUgaXQgc2hvdWxkIGJl IGV4dHJhY3RlZCBvdXQgZnJvbSBhdHRyaWJ1dGVzIGFuZCBiZSBzcGVsbGVkIG91dCBhIHNlcGFy YXRlIGxlYWYsIGJ1dCBJIGRvbuKAmXQgdGhpbmsgdGhlcmUgaXMuDQoNCkkgYmVsaWV2ZSBoZXJl IHlvdSdyZSByZWZlcnJpbmcgdG8gdGhlIDIgaW5zdGFuY2VzIG9mIGxpbmVzIGxpa2U6DQoNCiAg ICAgICAgbGVhZiBhdHRyaWJ1dGVzIHsNCiAgICAgICAgICB0eXBlIGJpbmFyeTsgLy8gRklYTUU6 IGRvZXMgdGhpcyBuZWVkIHRvIGJlIG1hbmRhdG9yeT8NCiAgICAgICAgICAuLi4NCiAgICAgICAg fQ0KDQpUaGVzZSBhcmUgaW4gdGhlICJnZW5lcmF0ZS1jZXJ0aWZpY2F0ZS1zaWduaW5nLXJlcXVl c3QiIGFjdGlvbnMgZm91bmQgaW5zaWRlIHRoZSBhc3ltbWV0cmljLWtleS1wYWlyLXdpdGgtY2Vy dChzKS1ncm91cGluZy4NCg0KSG1tbSwgYXJlIHlvdSBjbGFpbWluZyB0aGF0ICJhdHRyaWJ1dGVz IiBhcmUgbm90IHJlcXVpcmVkIGluIG9yZGVyIHRvIGdlbmVyYXRlIGEgQ1NSPyAgSSB0aGluayB0 aGUgQ1NSIGl0c2VsZiBNVVNUIGhhdmUgYXR0cmlidXRlcyAocmlnaHQ/KSBzbywgaWYgbm90IHNw ZWNpZmllZCwgd2hhdCBkZWZhdWx0IHZhbHVlcyBhcmUgdXNlZD8NCg0KQmFsYXpzPiBJbiBSRkMy OTg2PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMyOTg2I3NlY3Rpb24tMz4gdGhlIGF0 dHJpYnV0ZXMgYXJlIHNhaWQgdG8gYmUgb3B0aW9uYWwuIFdlIGp1c3QgbmVlZCB0aGUgc3ViamVj dCBETiBhcyBtYW5kYXRvcnksIGRvbuKAmXQgd2U/DQoNCg0KDQoNCiAgICAgICAgMS4gQSBDZXJ0 aWZpY2F0aW9uUmVxdWVzdEluZm8gdmFsdWUgY29udGFpbmluZyBhIHN1YmplY3QNCg0KICAgICAg ICAgICBkaXN0aW5ndWlzaGVkIG5hbWUsIGEgc3ViamVjdCBwdWJsaWMga2V5LCBhbmQgb3B0aW9u YWxseSBhDQoNCiAgICAgICAgICAgc2V0IG9mIGF0dHJpYnV0ZXMgaXMgY29uc3RydWN0ZWQgYnkg YW4gZW50aXR5IHJlcXVlc3RpbmcNCg0KICAgICAgICAgICBjZXJ0aWZpY2F0aW9uLg0KDQoNCg0K DQozLiAgICAgICBQU0sgYW5kIHJhdyBwdWJsaWMga2V5cw0KVGhlIHVzZSBjYXNlIG9mIFBTSyBh bmQgcmF3IHB1YmxpYyBrZXlzIGFyZSBub3QgdGhlIG1vc3QgdXJnZW50IGluIG15IG9waW5pb24g d2hpY2ggbm93IHNsb3dzIGEgYml0IHRoZSBwcm9ncmVzcyBvZiB0aGVzZSBkcmFmdHMsIGJ1dCBs ZXTigJlzIG1ha2UgYW4gYXR0ZW1wdCB0byBmaW5hbGl6ZSB0aGVtLg0KDQpBZ3JlZWQsIGJ1dCB0 aGV5IGFyZSBsZWdhbCBmb3IgVExTIGFuZCBhIFdHIG1lbWJlciBzdGF0ZWQgdGhhdCB0aGV5IHdl cmUgbmVlZGVkIGluIG9yZGVyIHRvIHN1cHBvcnQgYW5vdGhlciBJRVRGIFdHJ3MgZWZmb3J0cy4g IEEgcXVpY2sgcmVzb2x1dGlvbiB3b3VsZCBiZSBiZXN0IQ0KDQoNCg0KcmF3LXB1YmxpYy1rZXlz OiBJIHNlZSB0aGVzZSB3ZXJlIGFkZGVkIGR1ZSB0byBSRkMgNzI1MCBhbmQgODQ0Ni4gSSBndWVz cyBpbiB0cnVzdHN0b3JlIHRoaXMgaXMgYSBzZXBhcmF0ZSBjb250YWluZXIgdG8gZGlzdGluZ3Vp c2ggZnJvbSBTU0ggaG9zdCBrZXlzLiBGb3IgY29uZmlndXJpbmcgdGhlIHByaXZhdGUgcGFydCBJ IHRoaW5rIGtleXN0b3JlIGFscmVhZHkgZ2l2ZXMgc3VwcG9ydCBmb3IgdGhpcyBjYXNlIHdpdGgg dGhlIGFzeW1tZXRyaWMga2V5ICh3L28gY2VydCkgYW5kIGluIHRoZSBjbGllbnQvc2VydmVyIGRy YWZ0cyBLZW504oCZcyBwcm9wb3NhbCBjb3VsZCBiZSB1c2VkIChJIHJlcGxhY2VkIHJhdyBwdWJs aWMga2V5IHdpdGggZXhpc3RpbmcgdHlwZSwgc2hvdWxkbuKAmXQgdGhhdCBiZSB1c2VhYmxlIHN0 cmFpZ2h0IGF3YXk/KQ0KDQogICAgICAgICAgICAgICAgICAgIGNvbnRhaW5lciA8Y2xpZW50LWlk ZW50aXR5IG9yIHNlcnZlci1pZGVudGl0eT4gew0KICAgICAgICAgICAgICAgICAgICAgIGNob2lj ZSBhdXRoLXR5cGUgew0KICAgICAgICAgICAgICAgICAgICAgICAgIHVzZXMga3M6bG9jYWwtb3It a2V5c3RvcmUtZW5kLWVudGl0eS1jZXJ0LXdpdGgta2V5LWdyb3VwaW5nOw0KICAgICAgICAgICAg ICAgICAgICAgICAgIHVzZXMga3M6bG9jYWwtb3Ita2V5c3RvcmUtYXN5bW1ldHJpYy1rZXktZ3Jv dXBpbmc7DQoNCg0KSSB3b3VsZCBhbHNvIHByZWZlciBpZiB0aGVzZSBjaG9pY2VzIGFyZSBpbiBm ZWF0dXJlcywgc28gdGhhdCBhbiBpbXBsZW1lbnRhdGlvbiBjYW4gY2hvb3NlLg0KDQpUbyB5b3Vy IGZpcnN0IHNlbnRlbmNlLCB5ZXMsICJwc2siIChhbmQgInJhdy1wdWJsaWMta2V5IikgYXJlIHRv cC1sZXZlbCBub2RlcyBpbiB0cnVzdHN0b3JlLCBhcyBjYW4gYmUgc2VlbiBoZXJlIChodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRjb25mLXRydXN0LWFuY2hvcnMtMDcj c2VjdGlvbi0yLjEpLiAgIE5vdGUsIHRoZSB0cnVzdC1hbmNob3JzIGRyYWZ0IGFjY2lkZW50YWxs eSBkb2Vzbid0IGluY2x1ZGUgdGhlIGlldGYtdHJ1c3RzdG9yZS55YW5nIG1vZHVsZS4NCg0KVGhl IGJvZHkgb2YgeW91ciBjb21tZW50IGFib3ZlIHNlZW1zIHRvIGJlIGFib3V0IHN1cHBvcnRpbmcg dGhlIHNlY3JldC1oYWxmIG9mIHRoZSBQU0sgYW5kIFJQSyB3aXRoaW4gdGhlIEtleXN0b3JlLiAg SSd2ZSByYWlzZSB0aGlzIHF1ZXN0aW9uIGEgY291cGxlIHRpbWVzIHByZXZpb3VzbHkgdG8gSGVu ayAod2hvJ3MgYXNraW5nIGZvciB0aGUgUFNLL1JQSyBhZGQpLCBidXQgaGUncyBub3QgcmVzcG9u ZGVkIHlldCBhcyB0byBpZiBkb2luZyBzbyBpcyBpbXBvcnRhbnQgKHRob3VnaCBJIGNhbiBvbmx5 IGltYWdpbmUgdGhhdCBpdCBkb2VzKS4gICBXaXRoIHRoYXQgc2FpZCwgSSB0aGluayB5b3VyIFlB Tkcgc25pcHBldCBpcyBtZWFudCB0byBiZSBpbiBpZXRmLXRscy1zZXJ2ZXIgYW5kIGlldGYtdGxz LWNsaWVudCBtb2R1bGVzIChyaWdodD8pLiAgSSdtIGhhdmluZyBhIGhhcmQgdGltZSBmb2xsb3dp bmcgdGhlICJJIHJlcGxhY2VkIHJhdyBwdWJsaWMga2V5IHdpdGggZXhpc3RpbmcgdHlwZSwgc2hv dWxkbuKAmXQgdGhhdCBiZSB1c2VhYmxlIHN0cmFpZ2h0IGF3YXk/IiBjb21tZW50Lg0KDQpCYWxh enM6IFlvdSBoYWQgYW4gZXhhbXBsZSBlYXJsaWVyIGluIGFuIGVtYWlsIGZyb20gMTAvOC8yMDE5 LCB3aGljaCBpcyBhYm91dCB0aGUgVExTIGNsaWVudC9zZXJ2ZXIgbW9kZWxzLiBCZWxvdywgeW91 IGFyZSByZWZlcnJpbmcgdG8gc29tZSBwb3NzaWJseSBuZXcgZ3JvdXBpbmdzIHRoYXQgeW91IHdh bnRlZCB0byBwcm9wb3NlLiBJIGRvbuKAmXQgdW5kZXJzdGFuZCB0aG91Z2ggd2h5IHlvdSBtZW50 aW9uZWQgdGhlc2UgbmV3IGdyb3VwaW5ncyBzaW5jZSDigJhrczpsb2NhbC1vci1rZXlzdG9yZS1h c3ltbWV0cmljLWtleS1ncm91cGluZ+KAmSAoUlBLKSBhbmQgc29tZXRoaW5nIG5ldyB0aGF0IGp1 c3QgcmVmZXJzIHRvIGEga2V5c3RvcmUgc3ltbWV0cmljIGtleSwgc3VjaCBhcyDigJhrczpsb2Nh bC1vci1rZXlzdG9yZS1zeW1tZXRyaWMta2V5LWdyb3VwaW5n4oCZIChQU0spIHNob3VsZCBiZSBn b29kLiBUaGlzIGxhdHRlciBJIHRoaW5rIHdvdWxkIGJlIGEgbmV3IGdyb3VwaW5nLCBidXQgd2l0 aCBleGlzdGluZyB0ZXJtaW5vbG9neS4NCg0KQWxsLCBsb29raW5nIGF0IGlldGYtdGxzLWNsaWVu dC55YW5nIGFuZCBpZXRmLXRscy1zZXJ2ZXIueWFuZywgYWRkaW5nIHRoZSBhYmlsaXR5IHRvIGNv bmZpZ3VyZSB0aGUgInByaXZhdGUiIGhhbGYgb2YgYSBQU0sgb3IgcmF3IHB1YmxpYyBrZXkgd291 bGQgYmUgc29tZXRoaW5nIGxpa2U6DQoNCiAgICAgICAgICAgICAgICBPTEQNCiAgICAgICAgICAg ICAgICAgICAgY29udGFpbmVyIDxjbGllbnQtaWRlbnRpdHkgb3Igc2VydmVyLWlkZW50aXR5PiB7 DQogICAgICAgICAgICAgICAgICAgICAgdXNlcyBrczpsb2NhbC1vci1rZXlzdG9yZS1lbmQtZW50 aXR5LWNlcnQtd2l0aC1rZXktZ3JvdXBpbmc7DQogICAgICAgICAgICAgICAgTkVXDQogICAgICAg ICAgICAgICAgICAgIGNvbnRhaW5lciA8Y2xpZW50LWlkZW50aXR5IG9yIHNlcnZlci1pZGVudGl0 eT4gew0KICAgICAgICAgICAgICAgICAgICAgIGNob2ljZSBhdXRoLXR5cGUgew0KICAgICAgICAg ICAgICAgICAgICAgICAgIHVzZXMga3M6bG9jYWwtb3Ita2V5c3RvcmUtZW5kLWVudGl0eS1jZXJ0 LXdpdGgta2V5LWdyb3VwaW5nOw0KICAgICAgICAgICAgICAgICAgICAgICAgIHVzZXMga3M6bG9j YWwtb3Ita2V5c3RvcmUtcmF3LXB1YmxpYy1rZXktZ3JvdXBpbmc7DQogICAgICAgICAgICAgICAg ICAgICAgICAgdXNlcyBrczpsb2NhbC1vci1rZXlzdG9yZS1wcmUtc2hhcmVkLWtleS1ncm91cGlu ZzsNCg0KDQoNClRvIHlvdXIgbGFzdCBzZW50ZW5jZSByZWdhcmRpbmcgZmVhdHVyZXMsIGNvdWxk IHlvdSBwcm92aWRlIGFuIGV4YW1wbGUgb2Ygd2hhdCB5b3UgbWVhbj8NCg0KDQpjb250YWluZXIg PGNsaWVudC1pZGVudGl0eSBvciBzZXJ2ZXItaWRlbnRpdHk+IHsNCiAgICBjaG9pY2UgYXV0aC10 eXBlIHsNCiAgICAgICAgbWFuZGF0b3J5IHRydWU7DQogICAgICAgIGNhc2UgY2VydGlmaWNhdGUg ew0KICAgICAgICAgICAgaWYtZmVhdHVyZSB4NTA5LWNlcnRpZmljYXRlLWF1dGg7DQogICAgICAg ICAgIHVzZXMga3M6bG9jYWwtb3Ita2V5c3RvcmUtZW5kLWVudGl0eS1jZXJ0LXdpdGgta2V5LWdy b3VwaW5nOw0KICAgICAgIH0NCiAgICAgICAgY2FzZSByYXctcHVibGljLWtleSB7DQogICAgICAg ICAgICBpZi1mZWF0dXJlIHJhdy1wdWJsaWMta2V5LWF1dGg7DQogICAgICAgICAgIHVzZXMga3M6 bG9jYWwtb3Ita2V5c3RvcmUtYXN5bW1ldHJpYy1rZXktZ3JvdXBpbmc7DQogICAgICAgfQ0KICAg ICAgICBjYXNlIHBzayB7DQogICAgICAgICAgICBpZi1mZWF0dXJlIHBzay1hdXRoOw0KICAgICAg ICAgICB1c2VzIGtzOmxvY2FsLW9yLWtleXN0b3JlLXN5bW1ldHJpYy1rZXktZ3JvdXBpbmc7DQog ICAgICAgfQ0KDQpJIGFzc3VtZSB0aGVzZSBmZWF0dXJlcyB3b3VsZCB0aGVuIG5lZWQgdG8gYmUg ZGVmaW5lZCBpbiB0aGUgVExTIGNsaWVudC9zZXJ2ZXIgZHJhZnQuDQoNClBTOiBub25lIG9mIHRo aXMgZ29lcyB0byB0aGUgRklYTUUgaW4gdGhlIGlldGYtY3J5cHRvLXR5cGVzLiAgSSBoYWQgcHJl dmlvdXNseSBhc2tlZCBIZW5rIHRvIHByb3ZpZGUgc29tZSB0ZXh0IGhlcmUgYXMgd2VsbCBidXQs IGFwcGFyZW50bHksIGxpa2UgYWxsIG9mIHVzIGF0IHRoaXMgdGltZSwgaGUncyBiZWVuIGJ1c3kh DQoNCg0KDQogcHNrOiBnaXZlbiB0aGF0IHRoZSBhc3ltbWV0cmljIGtleXMgd2l0aG91dCBjZXJ0 cyB3ZXJlIGNvdmVyZWQgYnkgaG9zdCBrZXlzIGFuZCByYXcgcHVibGljIGtleXMsIEkgdGhpbmsg cHNrIHNob3VsZCBvbmx5IGJlIHN5bW1ldHJpYyBrZXlzLiBTeW1tZXRyaWMga2V5cyBhcmUgdGhl biBzZW5zaXRpdmUvc2VjcmV0IGRhdGEgYW5kIGFzIHN1Y2ggSSBiZWxpZXZlIHRoZXkgc2hvdWxk IG9ubHkgYmUgcmVmZXJlbmNlZCBmcm9tIGtleXN0b3JlLiBTZWVpbmcgdGhlbSBpbiB0cnVzdHN0 b3JlIHdhcyB1bmV4cGVjdGVkIGZvciBtZS4gV2hlbiBpdCBjb21lcyB0byB0aGVpciB1c2UsIGNs aWVudHMgYW5kIHNlcnZlcnMgc2hvdWxkIGJlIGV4dGVuZGVkIHdpdGggZm9sbG93aW5nIGNvbmZp Z3VyYXRpb24gKGFuZCBJIGFzc3VtZSB3ZSB0YWxrIG9mIFRMUyBjbGllbnRzIGFuZCBzZXJ2ZXJz IG9ubHkpOg0KDQogICAgICAgICAgICAgICAgICAgIGNvbnRhaW5lciA8Y2xpZW50LWlkZW50aXR5 IG9yIHNlcnZlci1pZGVudGl0eT4gew0KICAgICAgICAgICAgICAgICAgICAgIGNob2ljZSBhdXRo LXR5cGUgew0KICAgICAgICAgICAgICAgICAgICAgICAgIHVzZXMga3M6bG9jYWwtb3Ita2V5c3Rv cmUtZW5kLWVudGl0eS1jZXJ0LXdpdGgta2V5LWdyb3VwaW5nOw0KICAgICAgICAgICAgICAgICAg ICAgICAgIHVzZXMga3M6bG9jYWwtb3Ita2V5c3RvcmUtYXN5bW1ldHJpYy1rZXktZ3JvdXBpbmc7 DQogICAgICAgICAgICAgICAgICAgICAgIHVzZXMga3M6bG9jYWwtb3Ita2V5c3RvcmUtc3ltbWV0 cmljLWtleS1ncm91cGluZzsNCg0KTGF0dGVyIGdyb3VwaW5nIHdvdWxkIGJlIGEgbmV3IG9uZSwg YnV0IGl0IHdvdWxkIHVzZSBleGlzdGluZyBjb25zdHJ1Y3RzIGFuZCB0ZXJtcyBmcm9tIGtleXN0 b3JlLiBJIGRvbuKAmXQgdGhpbmsgd2UgbmVlZCBuZXcgb25lcy4gU2VsZWN0ZWQgY2lwaGVyIHN1 aXRlcyB3aWxsIG5lZWQgdG8gaGF2ZSBQU0sgaW4gdGhlbSBmb3IgdXNpbmcgc3ltbWV0cmljIGtl eSAoc2ltaWxhciBtYXRjaCBuZWVkZWQgZm9yIHRoZSBvdGhlcnMpLiBOb3RlIHRoYXQgc3ltbWV0 cmljIGtleXMgY2FuIGJlIHVzZWQgZm9yIG90aGVyIGNhc2VzIHRoYW4gVExTIFBTSywgZm9yIGV4 YW1wbGUgU05NUHYzIFVTTS4gQWdhaW4sIGZlYXR1cmVzIHdvdWxkIGJlIG5lY2Vzc2FyeSAodGhv c2UgY291bGQgYmUgc2F5aW5nIHguNTA5IG9yIHJhdy1wdWJsaWMta2V5IG9yIHBzaykuDQoNCg0K Q29ycmVjdCwgSSBzYWlkIHRoZSBzYW1lICh0aGF0IFBTS3MgYXJlIGVzc2VudGlhbGx5IHN5bW1l dHJpYyBrZXlzKSBiZWZvcmUgYXMgd2VsbC4gIFJlZ2FyZGluZyBvbmx5IGJlaW5nIHJlZmVyZW5j ZWQgdG8ga2V5c3RvcmUsIHdoeSBub3QgYWxzbyBzdXBwb3J0IHRoZW0gYmVpbmcgbG9jYWwtZGVm aW5pdGlvbnMgdG9vPyAgQ2VydGFpbmx5IG5vdCBhIHByb2JsZW0gaWYgZW5jcnlwdGVkIGFuZCwg ZXZlbiB3aGVuIG5vdCBlbmNyeXB0ZWQsIHRoZW4gdGhleSBjYW4gYmUgInByb3RlY3RlZCIgYnkg TkFDTS1saWtlIG1lY2hhbmlzbXMsIHJpZ2h0Pw0KDQpCYWxhenM+IExvY2FsIGRlZmluaXRpb25z IGFyZSBvayB0b28gdGhhdOKAmXMgd2h5IEkgdXNlZCBhIGh5cG90aGV0aWNhbCBncm91cGluZyBu YW1lICBrczpsb2NhbC1vci1rZXlzdG9yZS1zeW1tZXRyaWMta2V5LWdyb3VwaW5nLg0KDQogIFdo eSB3YXMvaXMgc2VlaW5nIHRoZW0gaW4gdHJ1c3RzdG9yZSBhIHN1cnByaXNlLCBwZXJoYXBzIGJl Y2F1c2UgdGhleSdyZSBub3QgZW5jcnlwdGFibGUgdGhlcmU/DQoNCkJhbGF6cz4gV2hlbiBQU0tz IGFyZSB1c2VkIHRoZW4gYm90aCBjb21tdW5pY2F0aW5nIGVuZHMgdXNlIHRoZSBzaGFyZWQga2V5 IGZvciBzaWduaW5nIGFuZCB2ZXJpZnlpbmcgbWVzc2FnZXMuIFRoZW4gb25lIGNvbmZpZ3VyYXRp b24gc2VlbXMgZW5vdWdoIHRoYXQgaXMgZWl0aGVyIGxvY2FsIG9yIGZyb20ga2V5c3RvcmUsIHdo eSB3b3VsZCBpdCBiZSBuZWNlc3NhcnkgdG8gc2V0IGl0IHVwIHlldCBhbm90aGVyIHRpbWUgZm9y IHZlcmlmaWNhdGlvbiBmcm9tIGxvY2FsIG9yIHRydXN0c3RvcmU/IFRoaXMgd291bGQgbWVhbiB0 aGVyZSBpcyBubyBuZWVkIGZvciBhIFBTSyBvcHRpb24gd2hlbiBjb25maWd1cmluZyBob3cgdG8g IHZlcmlmeSB0aGUgcGVlci4NCg0KY29udGFpbmVyIDxjbGllbnQtYXV0aGVudGljYXRpb24gb3Ig c2VydmVyLWF1dGhlbnRpY2F0aW9uPiB7DQogICAgY2hvaWNlIGF1dGgtdHlwZSB7DQogICAgICAg IG1hbmRhdG9yeSB0cnVlOw0KICAgICAgICBjYXNlIGNlcnRpZmljYXRlIHsNCiAgICAgICAgICAg IGlmLWZlYXR1cmUgeDUwOS1jZXJ0aWZpY2F0ZS1hdXRoOw0KICAgICAgICAgICAgY29udGFpbmVy IGNhLWNlcnRzIHsNCg0KICAgICAgICAgICAgICAgIHVzZXMgdHM6bG9jYWwtb3ItdHJ1c3RzdG9y ZS1jZXJ0cy1ncm91cGluZw0KICAgICAgICAgICAgfQ0KICAgICAgICAgICAgY29udGFpbmVyIHNl cnZlci1jZXJ0cyB7DQoNCiAgICAgICAgICAgICAgICB1c2VzIHRzOmxvY2FsLW9yLXRydXN0c3Rv cmUtY2VydHMtZ3JvdXBpbmcNCiAgICAgICAgICAgIH0NCiAgICAgICB9DQogICAgICAgIGNhc2Ug cmF3LXB1YmxpYy1rZXkgew0KICAgICAgICAgICAgaWYtZmVhdHVyZSByYXctcHVibGljLWtleS1h dXRoOw0KICAgICAgICAgICAgICAgIHVzZXMga3M6IGxvY2FsLW9yLXRydXN0c3RvcmUtcmF3LXB1 Yi1rZXlzLWdyb3VwaW5nDQogICAgICAgfQ0KDQpObyBuZWVkIGZvciBQU0sgY29uZmlnIHNpbmNl IGl0IGlzIGFscmVhZHkgY29uZmlndXJlZCBpbiBjbGllbnQvc2VydmVyLWlkZW50aXR5Lg0KDQpP ciB3aGF0IGlzIHRoZSByZWFzb25pbmcgd2h5IGl0IGlzIG5lY2Vzc2FyeSB0byBjb25maWd1cmUg YSBQU0sgZnJvbSB0cnVzdHN0b3JlPw0KDQogSSBhZ3JlZSB0aGF0IHN5bW1ldHJpYyBrZXlzIGNh biBiZSB1c2VkIGJleW9uZCBQU0sgKGFuZCBlbmNyeXB0aW9uIG9mIHRoZSBhc3ltbWV0cmljIGtl eXMsIHRoZSBvcmlnaW5hbCB1c2UgY2FzZSkuICBSZWdhcmRpbmcgZmVhdHVyZXMsIGFnYWluLCBw bGVhc2UgcHJvdmlkZSBhIFlBTkctc25pcHBldCBzbyBpdCBpcyBjbGVhciB0byBtZSAoYW5kIGFs bCkgd2hhdCB5b3UgbWVhbi4NCg0KDQpUaGFua3MhDQpLZW50DQoNCg== --_000_AM0PR07MB5187296C56CCE38DADE9EA1483790AM0PR07MB5187eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0 UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7 DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxp Lm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsN Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uYXBwbGUtY29udmVy dGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFu LmFwcGxlLXRhYi1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXRhYi1zcGFuO30NCnNwYW4u RW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5IVE1MUHJlZm9y bWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRl ZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUyNQ0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBE ZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MjU4ODc5MzI3Ow0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczo0MDUwMjg4MDt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVs LXN0YXJ0LWF0OjM7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMQ0KCXttc28t bGlzdC1pZDoxNTU0NTQyMDQxOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNTM4OTQ3NTU0O30N Cm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBLZW50 LDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9t OjBpbjttYXJnaW4tbGVmdDoxLjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQ7dGV4dC1pbmRlbnQ6 LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPktleS1mb3JtYXQgKHN5bW1ldHJpYy1rZXks IHB1YmxpYy1rZXksIGFzeW1tZXRyaWMta2V5LXBhaXIpPG86cD48L286cD48L3A+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj5JIGFzc3VtZSB0aGUgaWRlYSBoZXJlIGlzIHRvIG1ha2UgaXQgcG9zc2li bGUgdG8gaGF2ZSBjaG9pY2VzIGZvciB0aGUgQVNOLjEgdHlwZXMgaG9sZGluZyB0aGUga2V5cy4g SWYgdGhpcyBmbGV4aWJpbGl0eSBmb3IgZm9ybWF0cyBpcyBuZWNlc3NhcnkgSSBkb27igJl0IGhh dmUgYW55IG9iamVjdGlvbiB0byB0aGVtIGJ1dCBoYXZpbmcgYSBzaW5nbGUgYWdyZWVkIHR5cGUN CiBmb3IgdGhlc2UgZGlmZmVyZW50IHVzZSBjYXNlcyB3b3VsZCBhbHNvIHN1ZmZpY2UuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ SSBiZWxpZXZlIGhlcmUgeW91J3JlIHJlZmVycmluZyB0byB0aGUgMyBpbnN0YW5jZXMgb2YgbGlu ZXMgbGlrZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4m bmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwO2xlYWYmbmJzcDtrZXkmbmJzcDt7PGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7bmFjbTpkZWZhdWx0LWRlbnktYWxsOzxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwO3R5cGUmbmJzcDtiaW5hcnk7PGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7Ly9tdXN0ICZxdW90Oy4uL2tleS1mb3JtYXQm cXVvdDs7Jm5ic3A7Jm5ic3A7RklYTUU6IHJlbW92ZSBjb21tZW50IGlmIGFwcHJvYWNoIG9rPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC4uLjxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7IH08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj5GV0lXLCB0aGUgd2hvbGUgJnF1b3Q7a2V5LWZvcm1hdCZxdW90OyBsZWFmIGlz IHN0aWxsIGJlaW5nIHN1c3NlZCBvdXQgKHlvdXIgb3BpbmlvbiB3b3VsZCBiZSBoZWxwZnVsIG9u IHRoYXQgdGhyZWFkIGFzIHdlbGwpIGJ1dCwgc28gZmFyIGl0IHNlZW1zIHByb21pc2luZy4gJm5i c3A7VGhlIHJlYXNvbiB0aGVzZSBsaW5lcyBhcmUgY29tbWVudGVkIG91dCBpcyBiZWNhdXNlIDEp IHRoZSBXRyBoYXNuJ3QNCiBjb21taXR0ZWQgdG8gdGhpcyBwYXRoIHlldCBhbmQgMikgSSBkaWRu J3Qgd2FudCB0byB1cGRhdGUgYWxsIHRoZSBleGFtcGxlcyBpbiBhbGwgdGhlIGRyYWZ0cyAob3Ro ZXIgdGhhbiB0cnVzdHN0b3JlIGFuZCBrZXlzdG9yZSkgdG8gYWRkIGEgJnF1b3Q7a2V5LWZvcm1h dCZxdW90OyBsZWFmIHVudGlsIHRoZSBXRyBoYWQgbW9yZSBjb25zZW5zdXMgb24gdGhlICZxdW90 O2tleS1mb3JtYXQmcXVvdDsgbGVhZnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+SSBkb24ndCB1bmRlcnN0YW5kIHlvdXIgbGFzdCBjb21tZW50L3NlbnRl bmNlLiAmbmJzcDtDYW4geW91IHByb3ZpZGUgYW4gZXhhbXBsZT88bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QmFsYXpzJmd0OyBPaywgdGhlbiBsZXTigJlzIHdhaXQgZm9yIFdHIGRlY2lzaW9uLiBX ZWxsLCBJIGp1c3Qgc2F5IHRoYXQgdGhlIGVhcmxpZXIgd2F5cyBvZiBjb21tdW5pY2F0aW5nIHRo ZSBrZXkgZm9ybWF0cyB3ZXJlIGFkZXF1YXRlIGZyb20gbXkgcG9pbnQgb2Ygdmlldywgd2hpY2gg d2FzIHRoYXQgaW4gZG9jdW1lbnRhdGlvbiBpdCB3YXMgc2FpZCB0aGF0IGZvciBSU0EgdXNlIFJT QVByaXZhdGVLZXkgYW5kIGZvcg0KIEVDIHVzZSBFQ1ByaXZhdGVLZXksIGFuZCBzaW1pbGFybHkg Zm9yIG90aGVyIHR5cGVzLiBJ4oCZbSBhbHNvIG9rIHdpdGggdGhlIGtleS1mb3JtYXQgYXBwcm9h Y2ggaWYgcHJlZmVycmVkIGJ5IHRoZSBXRy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gZWFy bGllciB2ZXJzaW9uczo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZXNj cmlwdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7VGhlIHZhbHVlIG9mIHRoZSBiaW5hcnkga2V5LiZu YnNwOyBUaGUga2V5J3MgdmFsdWUgaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGludGVycHJldGVkIGJ5 IHRoZSAnYWxnb3JpdGhtJy4mbmJzcDsgRm9yIGV4YW1wbGUsIGEgRFNBIGtleTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgaXMgYW4gaW50ZWdlciwgYW4gUlNBIGtleSBpcyByZXByZXNlbnRlZCBhcyBSU0FQ cml2YXRlS2V5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhcyBkZWZpbmVkIGluDQo8YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODAxNyI+UkZDIDgwMTc8L2E+LCBhbmQgYW4gRUND IGtleSBpcyByZXByZXNlbnRlZCBhczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRUNQcml2YXRlS2V5IGFz IGRlZmluZWQgaW4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1OTE1 Ij5SRkMgNTkxNTwvYT4uJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXYg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluIj4yLjxzcGFuIHN0eWxlPSJmb250LXNp emU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPmF0dHJpYnV0ZXMgaW4gYXN5bW1ldHJp Yy1rZXktcGFpci13aXRoLWNlcnQocyktZ3JvdXBpbmc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SSB0aGluayBhdHRyaWJ1dGVzIHNob3VsZCBiZSBrZXB0IG9w dGlvbmFsLiBJZiB0aGVyZSBpcyBhbnl0aGluZyBlbHNlIGJlc2lkZXMgc3ViamVjdCBzZWVuIG1h bmRhdG9yeSBtYXliZSBpdCBzaG91bGQgYmUgZXh0cmFjdGVkIG91dCBmcm9tIGF0dHJpYnV0ZXMg YW5kIGJlIHNwZWxsZWQgb3V0IGEgc2VwYXJhdGUgbGVhZiwgYnV0IEkgZG9u4oCZdCB0aGluayB0 aGVyZSBpcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj5JIGJlbGlldmUgaGVyZSB5b3UncmUgcmVmZXJyaW5nIHRvIHRoZSAyIGlu c3RhbmNlcyBvZiBsaW5lcyBsaWtlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwO2xlYWYmbmJzcDth dHRyaWJ1dGVzJm5ic3A7ezxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsm bmJzcDt0eXBlJm5ic3A7YmluYXJ5OyZuYnNwOy8vIEZJWE1FOiBkb2VzIHRoaXMgbmVlZCB0byBi ZSBtYW5kYXRvcnk/PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAuLi48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRoZXNlIGFyZSBpbiB0aGUg JnF1b3Q7Z2VuZXJhdGUtY2VydGlmaWNhdGUtc2lnbmluZy1yZXF1ZXN0JnF1b3Q7IGFjdGlvbnMg Zm91bmQgaW5zaWRlIHRoZSZuYnNwO2FzeW1tZXRyaWMta2V5LXBhaXItd2l0aC1jZXJ0KHMpLWdy b3VwaW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkht bW0sIGFyZSB5b3UgY2xhaW1pbmcgdGhhdCAmcXVvdDthdHRyaWJ1dGVzJnF1b3Q7IGFyZSBub3Qg cmVxdWlyZWQgaW4gb3JkZXIgdG8gZ2VuZXJhdGUgYSBDU1I/ICZuYnNwO0kgdGhpbmsgdGhlIENT UiBpdHNlbGYgTVVTVCBoYXZlIGF0dHJpYnV0ZXMgKHJpZ2h0Pykgc28sIGlmIG5vdCBzcGVjaWZp ZWQsIHdoYXQgZGVmYXVsdCB2YWx1ZXMgYXJlIHVzZWQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5C YWxhenMmZ3Q7IEluIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMyOTg2 I3NlY3Rpb24tMyI+DQpSRkMyOTg2PC9hPiB0aGUgYXR0cmlidXRlcyBhcmUgc2FpZCB0byBiZSBv cHRpb25hbC4gV2UganVzdCBuZWVkIHRoZSBzdWJqZWN0IEROIGFzIG1hbmRhdG9yeSwgZG9u4oCZ dCB3ZT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMS4gQSBDZXJ0aWZpY2F0aW9uUmVxdWVzdElu Zm8gdmFsdWUgY29udGFpbmluZyBhIHN1YmplY3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg ZGlzdGluZ3Vpc2hlZCBuYW1lLCBhIHN1YmplY3QgcHVibGljIGtleSwgYW5kIDxiPm9wdGlvbmFs bHkgYTxvOnA+PC9vOnA+PC9iPjwvcHJlPg0KPHByZT48Yj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2V0IG9mIGF0dHJpYnV0ZXM8 L2I+IGlzIGNvbnN0cnVjdGVkIGJ5IGFuIGVudGl0eSByZXF1ZXN0aW5nPG86cD48L286cD48L3By ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGNlcnRpZmljYXRpb24uPG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MGluO21hcmdpbi1sZWZ0OjEuMGlu O21hcmdpbi1ib3R0b206LjAwMDFwdDt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2 ZWwxIGxmbzIiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Okln bm9yZSI+My48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48 IVtlbmRpZl0+UFNLIGFuZCByYXcgcHVibGljIGtleXM8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPlRoZSB1c2UgY2FzZSBvZiBQU0sgYW5kIHJhdyBwdWJsaWMga2V5cyBhcmUg bm90IHRoZSBtb3N0IHVyZ2VudCBpbiBteSBvcGluaW9uIHdoaWNoIG5vdyBzbG93cyBhIGJpdCB0 aGUgcHJvZ3Jlc3Mgb2YgdGhlc2UgZHJhZnRzLCBidXQgbGV04oCZcyBtYWtlIGFuIGF0dGVtcHQg dG8gZmluYWxpemUgdGhlbS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPkFncmVlZCwgYnV0IHRoZXkgYXJlIGxlZ2FsIGZvciBUTFMgYW5kIGEg V0cgbWVtYmVyIHN0YXRlZCB0aGF0IHRoZXkgd2VyZSBuZWVkZWQgaW4gb3JkZXIgdG8gc3VwcG9y dCBhbm90aGVyIElFVEYgV0cncyBlZmZvcnRzLiAmbmJzcDtBIHF1aWNrIHJlc29sdXRpb24gd291 bGQgYmUgYmVzdCE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4mbmJzcDs8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+cmF3LXB1YmxpYy1rZXlzOiBJIHNlZSB0aGVzZSB3ZXJlIGFkZGVkIGR1ZSB0byBSRkMgNzI1 MCBhbmQgODQ0Ni4gSSBndWVzcyBpbiB0cnVzdHN0b3JlIHRoaXMgaXMgYSBzZXBhcmF0ZSBjb250 YWluZXIgdG8gZGlzdGluZ3Vpc2ggZnJvbSBTU0ggaG9zdCBrZXlzLiBGb3IgY29uZmlndXJpbmcg dGhlIHByaXZhdGUgcGFydCBJIHRoaW5rIGtleXN0b3JlIGFscmVhZHkgZ2l2ZXMNCiBzdXBwb3J0 IGZvciB0aGlzIGNhc2Ugd2l0aCB0aGUgYXN5bW1ldHJpYyBrZXkgKHcvbyBjZXJ0KSBhbmQgaW4g dGhlIGNsaWVudC9zZXJ2ZXIgZHJhZnRzIEtlbnTigJlzIHByb3Bvc2FsIGNvdWxkIGJlIHVzZWQg KEkgcmVwbGFjZWQgcmF3IHB1YmxpYyBrZXkgd2l0aCBleGlzdGluZyB0eXBlLCBzaG91bGRu4oCZ dCB0aGF0IGJlIHVzZWFibGUgc3RyYWlnaHQgYXdheT8pPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIGNs YXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9z cGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4mbmJz cDsgJm5ic3A7Jm5ic3A7Y29udGFpbmVyJm5ic3A7Jmx0O2NsaWVudC1pZGVudGl0eSZuYnNwO29y Jm5ic3A7c2VydmVyLWlkZW50aXR5Jmd0OyZuYnNwO3s8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3Bh biBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ozwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgY2hvaWNlIGF1dGgtdHlwZSB7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt1c2VzJm5ic3A7a3M6bG9j YWwtb3Ita2V5c3RvcmUtZW5kLWVudGl0eS1jZXJ0LXdpdGgta2V5LWdyb3VwaW5nOzxicj4NCjxz cGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dXNlcyZuYnNwO2tzOmxvY2FsLW9y LWtleXN0b3JlLWFzeW1tZXRyaWMta2V5LWdyb3VwaW5nOzxicj4NCjxicj4NCjxicj4NCjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JIHdvdWxkIGFsc28gcHJl ZmVyIGlmIHRoZXNlIGNob2ljZXMgYXJlIGluIGZlYXR1cmVzLCBzbyB0aGF0IGFuIGltcGxlbWVu dGF0aW9uIGNhbiBjaG9vc2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VG8geW91ciBmaXJzdCBzZW50ZW5jZSwgeWVzLCAmcXVv dDtwc2smcXVvdDsgKGFuZCAmcXVvdDtyYXctcHVibGljLWtleSZxdW90OykgYXJlIHRvcC1sZXZl bCBub2RlcyBpbiB0cnVzdHN0b3JlLCBhcyBjYW4gYmUgc2VlbiBoZXJlICg8YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRjb25mLXRydXN0LWFuY2hvcnMt MDcjc2VjdGlvbi0yLjEiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5l dGNvbmYtdHJ1c3QtYW5jaG9ycy0wNyNzZWN0aW9uLTIuMTwvYT4pLg0KICZuYnNwOyBOb3RlLCB0 aGUgdHJ1c3QtYW5jaG9ycyBkcmFmdCBhY2NpZGVudGFsbHkgZG9lc24ndCBpbmNsdWRlIHRoZSBp ZXRmLXRydXN0c3RvcmUueWFuZyBtb2R1bGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+VGhlIGJvZHkgb2YgeW91ciBjb21tZW50IGFib3ZlIHNlZW1zIHRv IGJlIGFib3V0IHN1cHBvcnRpbmcgdGhlIHNlY3JldC1oYWxmIG9mIHRoZSBQU0sgYW5kIFJQSyB3 aXRoaW4gdGhlIEtleXN0b3JlLiAmbmJzcDtJJ3ZlIHJhaXNlIHRoaXMgcXVlc3Rpb24gYSBjb3Vw bGUgdGltZXMgcHJldmlvdXNseSB0byBIZW5rICh3aG8ncyBhc2tpbmcgZm9yIHRoZSBQU0svUlBL IGFkZCksDQogYnV0IGhlJ3Mgbm90IHJlc3BvbmRlZCB5ZXQgYXMgdG8gaWYgZG9pbmcgc28gaXMg aW1wb3J0YW50ICh0aG91Z2ggSSBjYW4gb25seSBpbWFnaW5lIHRoYXQgaXQgZG9lcykuICZuYnNw OyBXaXRoIHRoYXQgc2FpZCwgSSB0aGluayB5b3VyIFlBTkcgc25pcHBldCBpcyBtZWFudCB0byBi ZSBpbiBpZXRmLXRscy1zZXJ2ZXIgYW5kIGlldGYtdGxzLWNsaWVudCBtb2R1bGVzIChyaWdodD8p LiAmbmJzcDtJJ20gaGF2aW5nIGEgaGFyZCB0aW1lIGZvbGxvd2luZyB0aGUgJnF1b3Q7SQ0KIHJl cGxhY2VkIHJhdyBwdWJsaWMga2V5IHdpdGggZXhpc3RpbmcgdHlwZSwgc2hvdWxkbuKAmXQgdGhh dCBiZSB1c2VhYmxlIHN0cmFpZ2h0IGF3YXk/JnF1b3Q7IGNvbW1lbnQuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJhbGF6czogWW91IGhhZCBhbiBleGFtcGxlIGVhcmxp ZXIgaW4gYW4gZW1haWwgZnJvbSAxMC84LzIwMTksIHdoaWNoIGlzIGFib3V0IHRoZSBUTFMgY2xp ZW50L3NlcnZlciBtb2RlbHMuIEJlbG93LCB5b3UgYXJlIHJlZmVycmluZyB0byBzb21lIHBvc3Np Ymx5IG5ldyBncm91cGluZ3MgdGhhdCB5b3Ugd2FudGVkIHRvIHByb3Bvc2UuIEkgZG9u4oCZdCB1 bmRlcnN0YW5kIHRob3VnaCB3aHkgeW91IG1lbnRpb25lZA0KIHRoZXNlIG5ldyBncm91cGluZ3Mg c2luY2Ug4oCYa3M6bG9jYWwtb3Ita2V5c3RvcmUtYXN5bW1ldHJpYy1rZXktZ3JvdXBpbmfigJkg KFJQSykgYW5kIHNvbWV0aGluZyBuZXcgdGhhdCBqdXN0IHJlZmVycyB0byBhIGtleXN0b3JlIHN5 bW1ldHJpYyBrZXksIHN1Y2ggYXMg4oCYa3M6bG9jYWwtb3Ita2V5c3RvcmUtc3ltbWV0cmljLWtl eS1ncm91cGluZ+KAmSAoUFNLKSBzaG91bGQgYmUgZ29vZC4gVGhpcyBsYXR0ZXIgSSB0aGluayB3 b3VsZCBiZSBhIG5ldyBncm91cGluZywNCiBidXQgd2l0aCBleGlzdGluZyB0ZXJtaW5vbG9neS48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+QWxsLCBsb29raW5nIGF0Jm5ic3A7aWV0Zi10bHMt Y2xpZW50LnlhbmcgYW5kJm5ic3A7aWV0Zi10bHMtc2VydmVyLnlhbmcsIGFkZGluZyB0aGUgYWJp bGl0eSB0byBjb25maWd1cmUgdGhlICZxdW90O3ByaXZhdGUmcXVvdDsgaGFsZiBvZiBhIFBTSyBv ciByYXcgcHVibGljIGtleSB3b3VsZCBiZSBzb21ldGhpbmcgbGlrZTo8bzpwPjwvbzpwPjwvaT48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48bzpwPiZuYnNwOzwvbzpwPjwvaT48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPjxpPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L2k+PC9zcGFuPjxpPk9MRDxvOnA+PC9vOnA+ PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3Bh biI+PGk+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvaT48L3NwYW4+PGk+Jm5i c3A7ICZuYnNwOyZuYnNwO2NvbnRhaW5lciAmbHQ7Y2xpZW50LWlkZW50aXR5Jm5ic3A7b3ImbmJz cDtzZXJ2ZXItaWRlbnRpdHkmZ3Q7IHs8bzpwPjwvbzpwPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGNsYXNzPSJhcHBsZS10 YWItc3BhbiI+PGk+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L2k+PC9zcGFu PjxpPiZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7dXNlcyZuYnNwO2tzOmxvY2FsLW9yLWtleXN0 b3JlLWVuZC1lbnRpdHktY2VydC13aXRoLWtleS1ncm91cGluZzs8bzpwPjwvbzpwPjwvaT48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPjxpPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L2k+PC9zcGFuPjxpPk5FVzxvOnA+PC9v OnA+PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWIt c3BhbiI+PGk+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvaT48L3NwYW4+PGk+ Jm5ic3A7ICZuYnNwOyZuYnNwO2NvbnRhaW5lciZuYnNwOyZsdDtjbGllbnQtaWRlbnRpdHkmbmJz cDtvciZuYnNwO3NlcnZlci1pZGVudGl0eSZndDsmbmJzcDt7PG86cD48L286cD48L2k+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj48aT4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9pPjwvc3Bhbj48aT4mbmJzcDsgJm5ic3A7 ICZuYnNwOyBjaG9pY2UgYXV0aC10eXBlIHs8bzpwPjwvbzpwPjwvaT48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPjxpPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyA8L2k+PC9zcGFuPjxpPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDt1c2VzJm5ic3A7a3M6bG9jYWwtb3Ita2V5c3RvcmUtZW5kLWVudGl0eS1jZXJ0 LXdpdGgta2V5LWdyb3VwaW5nOzxicj4NCjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7dXNlcyZuYnNwO2tzOmxvY2FsLW9yLWtleXN0b3JlLXJhdy1wdWJsaWMt a2V5LWdyb3VwaW5nOzxicj4NCjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7dXNlcyZuYnNwO2tzOmxvY2FsLW9yLWtleXN0b3JlLXByZS1zaGFyZWQta2V5LWdy b3VwaW5nOzxvOnA+PC9vOnA+PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UbyB5b3Vy IGxhc3Qgc2VudGVuY2UgcmVnYXJkaW5nIGZlYXR1cmVzLCBjb3VsZCB5b3UgcHJvdmlkZSBhbiBl eGFtcGxlIG9mIHdoYXQgeW91IG1lYW4/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Y29udGFpbmVyJm5ic3A7Jmx0O2Ns aWVudC1pZGVudGl0eSZuYnNwO29yJm5ic3A7c2VydmVyLWlkZW50aXR5Jmd0OyZuYnNwO3s8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyBjaG9p Y2UgYXV0aC10eXBlIHs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDttYW5kYXRvcnkgdHJ1ZTs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBjYXNlIGNlcnRpZmljYXRlIHs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpZi1mZWF0dXJlIHg1MDktY2VydGlmaWNhdGUt YXV0aDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZu YnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt1c2VzJm5ic3A7 a3M6bG9jYWwtb3Ita2V5c3RvcmUtZW5kLWVudGl0eS1jZXJ0LXdpdGgta2V5LWdyb3VwaW5nOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjYXNlIHJhdy1wdWJsaWMt a2V5IHs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpZi1m ZWF0dXJlIHJhdy1wdWJsaWMta2V5LWF1dGg7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7dXNlcyZuYnNwO2tzOmxvY2FsLW9yLWtleXN0b3JlLWFzeW1tZXRyaWMta2V5 LWdyb3VwaW5nOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgY2FzZSBwc2sgezxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlmLWZlYXR1cmUgcHNrLWF1dGg7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dXNlcyZuYnNwO2tzOmxvY2FsLW9yLWtleXN0b3Jl LXN5bW1ldHJpYy1rZXktZ3JvdXBpbmc7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fTxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhc3N1 bWUgdGhlc2UgZmVhdHVyZXMgd291bGQgdGhlbiBuZWVkIHRvIGJlIGRlZmluZWQgaW4gdGhlIFRM UyBjbGllbnQvc2VydmVyIGRyYWZ0Ljxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlBT OiBub25lIG9mIHRoaXMgZ29lcyB0byB0aGUgRklYTUUgaW4gdGhlIGlldGYtY3J5cHRvLXR5cGVz LiAmbmJzcDtJIGhhZCBwcmV2aW91c2x5IGFza2VkIEhlbmsgdG8gcHJvdmlkZSBzb21lIHRleHQg aGVyZSBhcyB3ZWxsIGJ1dCwgYXBwYXJlbnRseSwgbGlrZSBhbGwgb2YgdXMgYXQgdGhpcyB0aW1l LCBoZSdzIGJlZW4gYnVzeSE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i Pjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJz cDtwc2s6IGdpdmVuIHRoYXQgdGhlIGFzeW1tZXRyaWMga2V5cyB3aXRob3V0IGNlcnRzIHdlcmUg Y292ZXJlZCBieSBob3N0IGtleXMgYW5kIHJhdyBwdWJsaWMga2V5cywgSSB0aGluayBwc2sgc2hv dWxkIG9ubHkgYmUgc3ltbWV0cmljIGtleXMuIFN5bW1ldHJpYyBrZXlzIGFyZSB0aGVuIHNlbnNp dGl2ZS9zZWNyZXQgZGF0YSBhbmQgYXMgc3VjaCBJIGJlbGlldmUgdGhleQ0KIHNob3VsZCBvbmx5 IGJlIHJlZmVyZW5jZWQgZnJvbSBrZXlzdG9yZS4gU2VlaW5nIHRoZW0gaW4gdHJ1c3RzdG9yZSB3 YXMgdW5leHBlY3RlZCBmb3IgbWUuIFdoZW4gaXQgY29tZXMgdG8gdGhlaXIgdXNlLCBjbGllbnRz IGFuZCBzZXJ2ZXJzIHNob3VsZCBiZSBleHRlbmRlZCB3aXRoIGZvbGxvd2luZyBjb25maWd1cmF0 aW9uIChhbmQgSSBhc3N1bWUgd2UgdGFsayBvZiBUTFMgY2xpZW50cyBhbmQgc2VydmVycyBvbmx5 KTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPiZuYnNwOyAmbmJzcDsmbmJzcDtjb250YWluZXImbmJzcDsm bHQ7Y2xpZW50LWlkZW50aXR5Jm5ic3A7b3ImbmJzcDtzZXJ2ZXItaWRlbnRpdHkmZ3Q7Jm5ic3A7 ezxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBjaG9pY2UgYXV0 aC10eXBlIHs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNw YW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDs8L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt1c2VzJm5ic3A7a3M6bG9jYWwtb3It a2V5c3RvcmUtZW5kLWVudGl0eS1jZXJ0LXdpdGgta2V5LWdyb3VwaW5nOzxicj4NCjxzcGFuIGNs YXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9z cGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4mbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dXNlcyZuYnNwO2tzOmxvY2FsLW9yLWtleXN0 b3JlLWFzeW1tZXRyaWMta2V5LWdyb3VwaW5nOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dXNlcyZuYnNwO2tzOjxpPmxvY2Fs LW9yLWtleXN0b3JlLXN5bW1ldHJpYy1rZXktZ3JvdXBpbmc8L2k+OzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+TGF0dGVyIGdyb3VwaW5nIHdvdWxkIGJlIGEgbmV3IG9u ZSwgYnV0IGl0IHdvdWxkIHVzZSBleGlzdGluZyBjb25zdHJ1Y3RzIGFuZCB0ZXJtcyBmcm9tIGtl eXN0b3JlLiBJIGRvbuKAmXQgdGhpbmsgd2UgbmVlZCBuZXcgb25lcy4gU2VsZWN0ZWQgY2lwaGVy IHN1aXRlcyB3aWxsIG5lZWQgdG8gaGF2ZSBQU0sgaW4gdGhlbSBmb3IgdXNpbmcgc3ltbWV0cmlj IGtleSAoc2ltaWxhcg0KIG1hdGNoIG5lZWRlZCBmb3IgdGhlIG90aGVycykuIE5vdGUgdGhhdCBz eW1tZXRyaWMga2V5cyBjYW4gYmUgdXNlZCBmb3Igb3RoZXIgY2FzZXMgdGhhbiBUTFMgUFNLLCBm b3IgZXhhbXBsZSBTTk1QdjMgVVNNLiBBZ2FpbiwgZmVhdHVyZXMgd291bGQgYmUgbmVjZXNzYXJ5 ICh0aG9zZSBjb3VsZCBiZSBzYXlpbmcgeC41MDkgb3IgcmF3LXB1YmxpYy1rZXkgb3IgcHNrKS48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5Db3JyZWN0LCBJIHNhaWQgdGhlIHNhbWUg KHRoYXQgUFNLcyBhcmUgZXNzZW50aWFsbHkgc3ltbWV0cmljIGtleXMpIGJlZm9yZSBhcyB3ZWxs LiAmbmJzcDtSZWdhcmRpbmcgb25seSBiZWluZyByZWZlcmVuY2VkIHRvIGtleXN0b3JlLCB3aHkg bm90IGFsc28gc3VwcG9ydCB0aGVtIGJlaW5nIGxvY2FsLWRlZmluaXRpb25zIHRvbz8gJm5ic3A7 Q2VydGFpbmx5IG5vdCBhIHByb2JsZW0gaWYNCiBlbmNyeXB0ZWQgYW5kLCBldmVuIHdoZW4gbm90 IGVuY3J5cHRlZCwgdGhlbiB0aGV5IGNhbiBiZSAmcXVvdDtwcm90ZWN0ZWQmcXVvdDsgYnkgTkFD TS1saWtlIG1lY2hhbmlzbXMsIHJpZ2h0Pw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJhbGF6 cyZndDsgTG9jYWwgZGVmaW5pdGlvbnMgYXJlIG9rIHRvbyB0aGF04oCZcyB3aHkgSSB1c2VkIGEg aHlwb3RoZXRpY2FsIGdyb3VwaW5nIG5hbWUgJm5ic3A7a3M6PGI+PGk+bG9jYWw8L2k+PC9iPjxp Pi1vci1rZXlzdG9yZS1zeW1tZXRyaWMta2V5LWdyb3VwaW5nLjwvaT48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyBXaHkgd2FzL2lzIHNlZWlu ZyB0aGVtIGluIHRydXN0c3RvcmUgYSBzdXJwcmlzZSwgcGVyaGFwcyBiZWNhdXNlIHRoZXkncmUg bm90IGVuY3J5cHRhYmxlIHRoZXJlPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CYWxhenMmZ3Q7 IFdoZW4gUFNLcyBhcmUgdXNlZCB0aGVuIGJvdGggY29tbXVuaWNhdGluZyBlbmRzIHVzZSB0aGUg c2hhcmVkIGtleSBmb3Igc2lnbmluZyBhbmQgdmVyaWZ5aW5nIG1lc3NhZ2VzLiBUaGVuIG9uZSBj b25maWd1cmF0aW9uIHNlZW1zIGVub3VnaCB0aGF0IGlzIGVpdGhlciBsb2NhbCBvciBmcm9tIGtl eXN0b3JlLCB3aHkgd291bGQgaXQgYmUgbmVjZXNzYXJ5IHRvIHNldCBpdCB1cCB5ZXQgYW5vdGhl cg0KIHRpbWUgZm9yIHZlcmlmaWNhdGlvbiBmcm9tIGxvY2FsIG9yIHRydXN0c3RvcmU/IFRoaXMg d291bGQgbWVhbiB0aGVyZSBpcyBubyBuZWVkIGZvciBhIFBTSyBvcHRpb24gd2hlbiBjb25maWd1 cmluZyBob3cgdG8gJm5ic3A7dmVyaWZ5IHRoZSBwZWVyLg0KPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPmNvbnRhaW5lciZuYnNwOyZsdDtjbGllbnQtYXV0aGVudGljYXRpb24mbmJzcDtvciZuYnNw O3NlcnZlci1hdXRoZW50aWNhdGlvbiZndDsmbmJzcDt7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsgY2hvaWNlIGF1dGgtdHlwZSB7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7bWFuZGF0b3J5IHRydWU7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Y2FzZSBjZXJ0aWZpY2F0ZSB7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgaWYtZmVhdHVyZSB4NTA5LWNlcnRpZmljYXRlLWF1dGg7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY29udGFpbmVyIGNhLWNlcnRzIHs8bzpw PjwvbzpwPjwvcD4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsgJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7dXNlcyB0czpsb2NhbC1vci10cnVzdHN0b3JlLWNlcnRzLWdyb3VwaW5nPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbnRhaW5lciBz ZXJ2ZXItY2VydHMgezxvOnA+PC9vOnA+PC9wPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw OyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt1c2VzIHRzOmxvY2FsLW9yLXRydXN0c3RvcmUt Y2VydHMtZ3JvdXBpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB9PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGNhc2UgcmF3LXB1YmxpYy1rZXkgezxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGlmLWZlYXR1cmUgcmF3LXB1YmxpYy1rZXktYXV0aDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDt1c2VzJm5ic3A7a3M6IGxvY2FsLW9yLXRydXN0c3RvcmUtcmF3LXB1Yi1rZXlzLWdyb3VwaW5n PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfTxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Tm8gbmVlZCBmb3IgUFNLIGNvbmZpZyBzaW5jZSBpdCBpcyBhbHJlYWR5IGNv bmZpZ3VyZWQgaW4gY2xpZW50L3NlcnZlci1pZGVudGl0eS48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T3Igd2hhdCBpcyB0aGUgcmVhc29uaW5nIHdoeSBpdCBpcyBuZWNlc3NhcnkgdG8gY29uZmln dXJlIGEgUFNLIGZyb20gdHJ1c3RzdG9yZT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwO0kgYWdyZWUgdGhhdCBzeW1tZXRyaWMga2V5cyBjYW4g YmUgdXNlZCBiZXlvbmQgUFNLIChhbmQgZW5jcnlwdGlvbiBvZiB0aGUgYXN5bW1ldHJpYyBrZXlz LCB0aGUgb3JpZ2luYWwgdXNlIGNhc2UpLiAmbmJzcDtSZWdhcmRpbmcgZmVhdHVyZXMsIGFnYWlu LCBwbGVhc2UgcHJvdmlkZSBhIFlBTkctc25pcHBldCBzbyBpdCBpcyBjbGVhciB0byBtZSAoYW5k IGFsbCkgd2hhdCB5b3UNCiBtZWFuLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGFua3MhPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPktlbnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_AM0PR07MB5187296C56CCE38DADE9EA1483790AM0PR07MB5187eurp_-- From nobody Wed Nov 6 07:23:08 2019 Return-Path: <0100016e414fd844-b3f5f0fc-cb1d-48d6-a1c2-6738ae07c7c6-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 D05971208AE for ; Wed, 6 Nov 2019 07:23:05 -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 u4z9bD3fET7Z for ; Wed, 6 Nov 2019 07:23:04 -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 E9FFA120869 for ; Wed, 6 Nov 2019 07:23:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1573053782; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=ZdJeJucCMcNgboRuLVKHPpRcszdEKTqLvgAYN92q+tQ=; b=QP7i51ah7ZxjpTQjlp0sgesNOEGrUZXw4gYv9GzdkWyTL2shsMAAeFw/fGRV6In/ kuzgzdH8cMOCDZiJO9oVzxRRHmHrSfN4h/XbqeYJMkdilxpgvI8UPM80xevSSt1iK+Y XXR3guU5G5MALmrWn2/mMskcKp9pCgocx4Cr4x44= From: Kent Watsen Message-ID: <0100016e414fd844-b3f5f0fc-cb1d-48d6-a1c2-6738ae07c7c6-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_26472FFC-A243-4A60-AA73-DD7BD4D5DA13" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 6 Nov 2019 15:23:02 +0000 In-Reply-To: <20191106.105303.176994873055471743.mbj@tail-f.com> Cc: "netconf@ietf.org" To: Martin Bjorklund References: <0100016e2de6a66d-ff5aea75-edfc-4d98-8c0e-95674c411430-000000@email.amazonses.com> <20191106.105303.176994873055471743.mbj@tail-f.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.11.06-54.240.8.31 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] missing ietf-truststore module. (was: today's updates to the client-server suite of drafts) 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, 06 Nov 2019 15:23:06 -0000 --Apple-Mail=_26472FFC-A243-4A60-AA73-DD7BD4D5DA13 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > What happened to the YANG module in > draft-ietf-netconf-trust-anchors-07? =20 The YANG module contained a TAB character, and the new `rfcfold` = script's failure wasn't caught. Here is the file: = https://github.com/netconf-wg/trust-anchors/blob/master/ietf-truststore.ya= ng = Kent > It just has: >=20 > file "ietf-truststore@2019-11-02.yang" >=20 >=20 > >=20 >=20 > /martin --Apple-Mail=_26472FFC-A243-4A60-AA73-DD7BD4D5DA13 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii


What happened = to the YANG module in
draft-ietf-netconf-trust-anchors-07? =  

The YANG = module contained a TAB character, and the new `rfcfold` script's failure = wasn't caught.


Kent



It just has:

  <CODE BEGINS> file "ietf-truststore@2019-11-02.yang"


  <CODE ENDS>

/martin

= --Apple-Mail=_26472FFC-A243-4A60-AA73-DD7BD4D5DA13-- From nobody Wed Nov 6 12:47:29 2019 Return-Path: <0100016e4278d338-6fad5d0f-14fe-41a8-9432-af7e9ec62280-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 2239E120072 for ; Wed, 6 Nov 2019 12:47: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, 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 GZ8oKmxi2Qy0 for ; Wed, 6 Nov 2019 12:47:26 -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 6D8CE1200FF for ; Wed, 6 Nov 2019 12:47:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1573073245; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=Lj52/C7uchYB3Fm8SJ6LmOvM+g8GCnnlGG05NhEJ/2E=; b=aQSWQNoYxSOxITA4j8NlKs0pf6gVI+Tvg07cOHtsWxvj27YCg6JBIWIrnNfGYhpG g2L3+xwgT1RbL3eAL0aRBUg0cTleRqbrNQ/Nv7DoPARazzw+NxHm7D5VKjmkkUiA1pQ pgLStlfT0Bp8DWHKsA+J76tV4FeXTuYFF1Z7E9aM= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_0078DFDD-BE90-4E58-84F6-40D68B9A1B6D" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-ID: <0100016e4278d338-6fad5d0f-14fe-41a8-9432-af7e9ec62280-000000@email.amazonses.com> Date: Wed, 6 Nov 2019 20:47:25 +0000 To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.11.06-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] draft netconf-106 agenda posted 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, 06 Nov 2019 20:47:28 -0000 --Apple-Mail=_0078DFDD-BE90-4E58-84F6-40D68B9A1B6D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii All, A draft agenda for our 106 meeting in Singapore has been posted. Please take a look and let us know if any changes are needed. https://datatracker.ietf.org/doc/agenda-106-netconf = Presenters: Please provide your slides to the chairs no later than the Friday before our meeting. Please only send a PDF version of your slides. If you requested "remote" presentation, your request has been submitted to the MeetEcho team. Kent (and Mahesh) --Apple-Mail=_0078DFDD-BE90-4E58-84F6-40D68B9A1B6D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii All,

 =  A draft agenda for our 106 meeting in Singapore has been = posted.
   Please take a = look and let us know if any changes are needed.

https://datatracker.ietf.org/doc/agenda-106-netconf


Presenters:

   Please provide your slides = to the chairs no later than the Friday
  =  before our meeting.  Please only send a PDF version of your = slides.
   If you requested "remote" = presentation, your request has been
  =  submitted to the MeetEcho team.

Kent (and Mahesh)

= --Apple-Mail=_0078DFDD-BE90-4E58-84F6-40D68B9A1B6D-- From nobody Wed Nov 6 16:04:18 2019 Return-Path: <0100016e432d004b-32e62ef2-4e6c-48f6-8fa4-092c55778ea8-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 2907C1200CC; Wed, 6 Nov 2019 16:04: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 ruzEMpshpT_Z; Wed, 6 Nov 2019 16:04:14 -0800 (PST) Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D4CC120169; Wed, 6 Nov 2019 16:04:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1573085053; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=zRVeprWI7wdNZZThSoObf5qiTa87Tcq+6la5CsLOFVk=; b=OC4vNq9qYLg4riinEP2CIGwZaHwZDHBkfUgsaRmMy30bel5i48UN9EoECzFrr9kb dVQO8v2Z+hzkqu9X1Z66pWUnXQ/cORCj26fE8d0/YYMRo6xtx6aa8YC6dPihM7OqC5e mY2c0mgm2qPJ/+05w3Dz93TdZgsBd6aRtUSnGH7s= From: Kent Watsen Message-ID: <0100016e432d004b-32e62ef2-4e6c-48f6-8fa4-092c55778ea8-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_28247C3C-B748-4374-BC1D-DC8B54B5ED39" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 7 Nov 2019 00:04:13 +0000 In-Reply-To: <20191104.093427.842126049822749848.mbj@tail-f.com> Cc: Mahesh Jethanandani , httpbis-chairs@ietf.org, "netconf@ietf.org" To: Martin Bjorklund References: <704A1489-3BC0-4EFF-A5B0-7D664EA05970@gmail.com> <20191104.093427.842126049822749848.mbj@tail-f.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.11.07-54.240.8.96 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04 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, 07 Nov 2019 00:04:16 -0000 --Apple-Mail=_28247C3C-B748-4374-BC1D-DC8B54B5ED39 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Martin, > In principle I wouldn't mind a document like this. But if the HTTP > experts have concerns, and based on the contents of the model (*) > perhaps it is better to add the necessary nodes directly to the > higher-level modules (e.g, ietf-restconf-server for the server nodes). Adding the nodes into the higher-level modules seems incorrect, as it = would effectively cause the same content to be replicated into a = multiplicity of higher-level modules leading to user-confusion and = maintenance-complexity. It seems more appropriate to understand what the concerns are and try to = address them. =20 Noteworthily, the HTTP experts additionally said that they would have no = issue if the module were called something else = (ietf-restful-http-client/server?) as then it wouldn't appear to = intending to be an all-encompassing HTTP definition and it would no = longer require involvement of the HTTP experts to ensure correctness. > (*) The grouping for the server doesn't really add much, imo. > Basically it has a seemingly arbitrary selection of headers to control > (in fact just 'Server'), which protocol version to support, and a > per-server list of "basic" username/passwords (which is probably not > a common way to configure authentication). True, but it is still meaningful, even if only for the protocol version, = and providing a target for higher-level modules to augment into. > The client grouping also doens't add much, with the possible exception > of the proxy settings; perhaps these nodes could be specified in a > generic grouping. The "client-identity" container is important. Note that "basic-auth" is = under an "if-feature" statement in anticipation that higher-level models = will want to augment into the "auth-type" choice statement other = (potentially proprietary) auth schemes. Kent // contributor --Apple-Mail=_28247C3C-B748-4374-BC1D-DC8B54B5ED39 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Martin,

In principle I wouldn't mind = a document like this.  But if the HTTP
experts have = concerns, and based on the contents of the model (*)
perhaps= it is better to add the necessary nodes directly to the
higher-level modules (e.g, ietf-restconf-server for the = server nodes).

Adding the nodes into the higher-level modules = seems incorrect, as it would effectively cause the same content to be = replicated into a multiplicity of higher-level modules leading to = user-confusion and maintenance-complexity.

It seems more appropriate to understand what the = concerns are and try to address them.   

Noteworthily, the HTTP experts additionally said = that they would have no issue if the module were called something else = (ietf-restful-http-client/server?) as then it wouldn't appear to = intending to be an all-encompassing HTTP definition and it would no = longer require involvement of the HTTP experts to ensure = correctness.


(*) The = grouping for the server doesn't really add much, imo.
Basically it has a seemingly arbitrary selection of headers = to control
(in fact just 'Server'), which protocol version = to support, and a
per-server list of "basic" = username/passwords (which is probably not
a common way to = configure authentication).
True, but it is still meaningful, even if only for the = protocol version, and providing a target for higher-level modules to = augment into.


The client grouping also doens't add much, with the possible = exception
of the proxy settings; perhaps these nodes could = be specified in a
generic = grouping.

The = "client-identity" container is important.  Note that "basic-auth" = is under an "if-feature" statement in anticipation that higher-level = models will want to augment into the "auth-type" choice statement other = (potentially proprietary) auth schemes.


Kent // = contributor

= --Apple-Mail=_28247C3C-B748-4374-BC1D-DC8B54B5ED39-- From nobody Wed Nov 6 23:38:04 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70A2312022D; Wed, 6 Nov 2019 23:38:02 -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_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 nTeMW5obto23; Wed, 6 Nov 2019 23:38:00 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60083.outbound.protection.outlook.com [40.107.6.83]) (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 C00441201DE; Wed, 6 Nov 2019 23:37:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kGPnnsfPj6+TISL2ytQnPba/ShfLFVxJ/pLTRN9EYpqiStMnY0nyn4Ax1MlbsSZrDiS7flsRk53osShaI2NrpHComA9W/nD1lsisv0nRMHb5QbJ8RBSGQ9nN/dP1fLbXhSDPrBvI1XWcgxZM1gE/PzDSQ6rTqiU8U/ehmY8Dm3V1wTChzxHidPlQjqg6q+L71QQzVLGxANgomxthbOBXdjjLivynkawYAxDdPDS9YG5YCs7AhuJ1DUaYCljRbR86lmcpiJS7UFjLZEPeyStoIZTmc279G5b8VngeNxJZ4SjjROsyEDfM9JlIETJ+zfe3bu/IhWXrxCg3I0S5OSUbKg== 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=yeTUXKHlqy1oLFJa6MgbgX/jZyeWFl71Xwm1oFU48hw=; b=TcMVjxHOlAwl9glv64CKCUmGt5AN0pQbYXTG5B/P+WdMo+AoXC/uC2IauhCcSY6JL8n76BsBERnXUrfv71ABSKHo779lDMea5uDH0b3VPlIj7qX9qEfosWkdBJYUFQFwgNALqjSvAhsFszNagpmXFk3H7gXQ9980qlfhZ3UtRfXlqccP7jBQ9vlmV0xfQUTwitxgvtfIKTKEI6+RN1jeKQA2A9FNr7y2wvKDX/SYoQCmRFneXelUvDhQeVrL5QiFnFLrjnZPe5BYPVpWqo0uLM9Y+62HiWXrpeHRjCx9+4S4/DhcqNa4BB+WGuuqakR6pRFlZg+DsyvMKCAT248tLw== 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=yeTUXKHlqy1oLFJa6MgbgX/jZyeWFl71Xwm1oFU48hw=; b=IXSWv9nDonUpaa570qhXwWYnVT8hs5CU5fgzfFqCi2hxgdxB9Cc5nfXnqU6K6szbAsMTs4N8kHC1dlak7a2ZQyfmytJKtaMzPoVxFENyLPr6rXjOw2JgYiIR9pTGBTGYYMnNtaDRVSMQyITp8AwlZm1kzd5x4uR8hM8YrtgAB2A= Received: from AM5P190MB0482.EURP190.PROD.OUTLOOK.COM (10.161.65.11) by AM5P190MB0516.EURP190.PROD.OUTLOOK.COM (10.161.64.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.20; Thu, 7 Nov 2019 07:37:56 +0000 Received: from AM5P190MB0482.EURP190.PROD.OUTLOOK.COM ([fe80::6c6c:2cd2:11dd:2aff]) by AM5P190MB0482.EURP190.PROD.OUTLOOK.COM ([fe80::6c6c:2cd2:11dd:2aff%5]) with mapi id 15.20.2408.028; Thu, 7 Nov 2019 07:37:56 +0000 From: =?iso-8859-1?Q?Sch=F6nw=E4lder=2C_J=FCrgen?= To: Kent Watsen CC: Martin Bjorklund , "httpbis-chairs@ietf.org" , "netconf@ietf.org" Thread-Topic: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04 Thread-Index: AQHVlP7tQNGFXrGSO0O5oXJVG0m2yKd/UouA Date: Thu, 7 Nov 2019 07:37:56 +0000 Message-ID: <20191107073755.kw6xqp5uqruiask6@anna.jacobs.jacobs-university.de> References: <704A1489-3BC0-4EFF-A5B0-7D664EA05970@gmail.com> <20191104.093427.842126049822749848.mbj@tail-f.com> <0100016e432d004b-32e62ef2-4e6c-48f6-8fa4-092c55778ea8-000000@email.amazonses.com> In-Reply-To: <0100016e432d004b-32e62ef2-4e6c-48f6-8fa4-092c55778ea8-000000@email.amazonses.com> 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: AM0PR06CA0010.eurprd06.prod.outlook.com (2603:10a6:208:ab::23) To AM5P190MB0482.EURP190.PROD.OUTLOOK.COM (2603:10a6:206:1d::11) 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: 99d34bfb-af84-4b02-6322-08d7635567fb x-ms-traffictypediagnostic: AM5P190MB0516: x-ms-exchange-purlcount: 1 x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 0214EB3F68 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39850400004)(366004)(376002)(346002)(396003)(136003)(189003)(199004)(52116002)(66476007)(64756008)(6436002)(66946007)(76176011)(305945005)(6916009)(446003)(256004)(6246003)(71190400001)(6306002)(71200400001)(6486002)(66556008)(6512007)(229853002)(66446008)(4326008)(5660300002)(1076003)(3450700001)(54906003)(6116002)(2906002)(81156014)(4744005)(7736002)(99286004)(81166006)(8676002)(43066004)(46003)(486006)(386003)(86362001)(102836004)(8936002)(6506007)(476003)(11346002)(25786009)(14454004)(186003)(478600001)(316002)(786003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5P190MB0516; H:AM5P190MB0482.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: 6RMSe5H+sVnKGbtgXv+NWX0d9xx21nw0QaHFWGB294nL+PCK8s58jP3BnLZZq04akg9N7TVZS3fnIzLdSoxjMmZrVuHhvyZ0qTo14NMulnbqdgcuI1/nxflWQ780fBTg5EZJK2CtOyxrzSnQJ2h8TetUHHPlGtEWn7KduAFtBUAfMLwsoNiKYoQrzLySBknUwWx8utwmDlmuuK6ibkhBcOFXgrc0WZosjFKj7x0EmSKNKT1MvNFMjdh7UP1BcgjZ3QtmclWqErLHlPBkgXwpl6rc1MMyf7iNSIT/WYSUIHVFzj6abvEOXpdJritebE92G0b17O7EKJSg63P/n/Ps4Ka0hRyAAUOPbFS/Sl22BDpc/0UFAJnIORQMe0futNbvQIU2LYpAd/A4LssNKeCf9mOS3d3uPc5/1EOzXu2EuBxNGXy3f5yETafTgnqeD3Us30iCMTAUS69CxoL3Bs7irRutaZ/WA6mjI9s5Rtye8is= Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 99d34bfb-af84-4b02-6322-08d7635567fb X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2019 07:37:56.5861 (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: hFGdkVsMnqs3vffsv2gcwGnLVpfcFU+hCDjSlTGFAXXnaY9mk3iKRjDaHbdX6b9d06y5zddY85Us3I6gl3orqulA6QRwG1+qcXu2JH3lEMw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5P190MB0516 Archived-At: Subject: Re: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04 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, 07 Nov 2019 07:38:02 -0000 On Thu, Nov 07, 2019 at 12:04:13AM +0000, Kent Watsen wrote: >=20 > Noteworthily, the HTTP experts additionally said that they would have no = issue if the module were called something else (ietf-restful-http-client/se= rver?) as then it wouldn't appear to intending to be an all-encompassing HT= TP definition and it would no longer require involvement of the HTTP expert= s to ensure correctness. > Changing the module name to ietf-restful-http-client/server makes any reuse of the definitions look back. I also think that the module should ensure correctness, perhaps not completeness. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Nov 7 07:10:45 2019 Return-Path: <0100016e466ae626-e9821117-8286-4f26-bc91-284d7dcaa453-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 C9A0D12089D; Thu, 7 Nov 2019 07:10:43 -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 88IYGhrb8QKu; Thu, 7 Nov 2019 07:10:43 -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 ACDA112083C; Thu, 7 Nov 2019 07:10:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1573139441; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=nNASjj9ThbxFJkhVbzWACteU2ewWUroAL8JUN8QCSXQ=; b=KovHiiZ9FGWoP9bnEHEI63xU3fnUNQNHkIH72aEI3Tat4fnHidscCvyB3/F5j4GJ ySO2dHh9G7Nh2EHdUpSqEBiVbwboovwFdPx6jNOexdqfVu4IlOkPCVuoQ+Wi3StpyZV dnNqGuWvEjatlRFrAtqQuy2uWjGC34s5GhyNr+Ns= From: Kent Watsen Message-ID: <0100016e466ae626-e9821117-8286-4f26-bc91-284d7dcaa453-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_9D497D6C-2C42-4931-BBBE-696900EDF02E" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 7 Nov 2019 15:10:41 +0000 In-Reply-To: <20191107073755.kw6xqp5uqruiask6@anna.jacobs.jacobs-university.de> Cc: "httpbis-chairs@ietf.org" , "netconf@ietf.org" To: Juergen Schoenwaelder References: <704A1489-3BC0-4EFF-A5B0-7D664EA05970@gmail.com> <20191104.093427.842126049822749848.mbj@tail-f.com> <0100016e432d004b-32e62ef2-4e6c-48f6-8fa4-092c55778ea8-000000@email.amazonses.com> <20191107073755.kw6xqp5uqruiask6@anna.jacobs.jacobs-university.de> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.11.07-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04 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, 07 Nov 2019 15:10:44 -0000 --Apple-Mail=_9D497D6C-2C42-4931-BBBE-696900EDF02E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Juergen, >> Noteworthily, the HTTP experts additionally said that they would have = no issue if the module were called something else = (ietf-restful-http-client/server?) as then it wouldn't appear to = intending to be an all-encompassing HTTP definition and it would no = longer require involvement of the HTTP experts to ensure correctness. >>=20 >=20 > Changing the module name to ietf-restful-http-client/server makes any > reuse of the definitions look back. Can you clarify what you mean by "look back"? Thanks, Kent > I also think that the module > should ensure correctness, perhaps not completeness. >=20 > /js --Apple-Mail=_9D497D6C-2C42-4931-BBBE-696900EDF02E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi Juergen,

Noteworthily, the HTTP experts additionally = said that they would have no issue if the module were called something = else (ietf-restful-http-client/server?) as then it wouldn't appear to = intending to be an all-encompassing HTTP definition and it would no = longer require involvement of the HTTP experts to ensure correctness.


Changing the = module name to ietf-restful-http-client/server makes any
reuse of the definitions look back. =

Can you clarify = what you mean by "look back"?

Thanks,
Kent


I also think that the = module
should ensure correctness, perhaps not = completeness.

/js

= --Apple-Mail=_9D497D6C-2C42-4931-BBBE-696900EDF02E-- From nobody Thu Nov 7 07:33:51 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFC0120884; Thu, 7 Nov 2019 07:33:50 -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_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 T-8kofpeVCsR; Thu, 7 Nov 2019 07:33:46 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10044.outbound.protection.outlook.com [40.107.1.44]) (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 6806B12082C; Thu, 7 Nov 2019 07:33:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=i/nDV16qQgz7dEmvGlhIE0+rNZpksXsfINT8WOvXwhlIUP3JT3CQTpJSk/IPHNrSgIAFfePUauLKHiIYaJobDtpXhPL02zMY/JRxc835P/tufe3rVDu7mcBjv683wM1e6Wx2+9iUStReDopmD1dzH3kaIwvjHxqalRSm1QvpLuU8BVw+AdO2zw7miEC/sTKswPg5V/bYSu60zNLIrELG9Zz53RBEp0F1JAxj06e4QnSCWwStJsLa6WJ3cN4nRCRe2y1JF0EA1PRoUirXxiJ8cuYlmPQerLeSIkxwVP/Lcl6IgMtNd6Qr4VRCkPzUx+1qci86BOj1Dnq4eRcCVj9xUw== 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=ftgTFHc/jXOMp5weHUGnz+2O5wDjzx+xWklthn2Kd+g=; b=WYOXo41tHhbCwg4m3tDGwOwuXNbsf90iHPcUxNDvs45okIwZ+kxaLo6cAKIrwug6vzFSHjHFSQUrLYQQZcQfrt5Y2YMC+TTWuLF2wD8aB9iz0E/3OhPjmTWh0C5JSNaaQ0GKb31WUvgFtY9g086jZc4wBscs+I7Wg10SUYcz0vGP/X5ieNiZV0aXBhWMx6PwfBWRqbEfLauU8ZtnJhKqf7Y43vtN2VRQjL4/LA7l7G40rbMvHHGnN21sy90/ycuwD/pEcZyeFR5ygUXG0Zs5G3I48uPvYGGr5gRGS2CjWxLiCJippk76kgOOgcQd5PNHrekgvtll8HJnMcAPCWOxVg== 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=ftgTFHc/jXOMp5weHUGnz+2O5wDjzx+xWklthn2Kd+g=; b=OdXdPPwDN23AkmqCpNFRZDwwNnaSU83yDe0UqhA1WdzJuHkpLT4cMbM/M0LYqlrFSCprr+2uUU0Dh/gtCOoiGqmEpwMRnZDdNwrJSmaSD67sfyCsRnb4PPn2jsnMjcfrZLQ7u12Zz+aLUpbyplu+vf1ccMw9TnAnWsTTCPHh7to= Received: from AM5P190MB0482.EURP190.PROD.OUTLOOK.COM (10.161.65.11) by AM5P190MB0547.EURP190.PROD.OUTLOOK.COM (10.161.81.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.23; Thu, 7 Nov 2019 15:33:44 +0000 Received: from AM5P190MB0482.EURP190.PROD.OUTLOOK.COM ([fe80::6c6c:2cd2:11dd:2aff]) by AM5P190MB0482.EURP190.PROD.OUTLOOK.COM ([fe80::6c6c:2cd2:11dd:2aff%5]) with mapi id 15.20.2408.028; Thu, 7 Nov 2019 15:33:44 +0000 From: =?iso-8859-1?Q?Sch=F6nw=E4lder=2C_J=FCrgen?= To: Kent Watsen CC: "httpbis-chairs@ietf.org" , "netconf@ietf.org" Thread-Topic: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04 Thread-Index: AQHVlP7tQNGFXrGSO0O5oXJVG0m2yKd/UouAgAB+gICAAAZvAA== Date: Thu, 7 Nov 2019 15:33:43 +0000 Message-ID: <20191107153342.gqtgyseqyvsppcul@anna.jacobs.jacobs-university.de> References: <704A1489-3BC0-4EFF-A5B0-7D664EA05970@gmail.com> <20191104.093427.842126049822749848.mbj@tail-f.com> <0100016e432d004b-32e62ef2-4e6c-48f6-8fa4-092c55778ea8-000000@email.amazonses.com> <20191107073755.kw6xqp5uqruiask6@anna.jacobs.jacobs-university.de> <0100016e466ae626-e9821117-8286-4f26-bc91-284d7dcaa453-000000@email.amazonses.com> In-Reply-To: <0100016e466ae626-e9821117-8286-4f26-bc91-284d7dcaa453-000000@email.amazonses.com> 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: AM3PR07CA0147.eurprd07.prod.outlook.com (2603:10a6:207:8::33) To AM5P190MB0482.EURP190.PROD.OUTLOOK.COM (2603:10a6:206:1d::11) 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: 3513f486-2f83-4480-7e40-08d76397df82 x-ms-traffictypediagnostic: AM5P190MB0547: x-ms-exchange-purlcount: 1 x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0214EB3F68 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(136003)(366004)(39850400004)(396003)(189003)(199004)(2906002)(64756008)(305945005)(7736002)(81166006)(81156014)(8676002)(446003)(52116002)(76176011)(11346002)(478600001)(3450700001)(66446008)(476003)(786003)(66476007)(6916009)(316002)(8936002)(6506007)(66946007)(386003)(486006)(6436002)(66556008)(99286004)(4326008)(229853002)(6116002)(3716004)(256004)(25786009)(54906003)(86362001)(14454004)(1076003)(186003)(5660300002)(6246003)(6306002)(71200400001)(6512007)(6486002)(71190400001)(46003)(43066004)(102836004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5P190MB0547; H:AM5P190MB0482.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: eyFN1aDDh1elO7ndxK53dtjUrbVb/EkGpnnQ6uofaOEcyCW9tM4RjSv7W6Y62ZqnTT6HYw0CpmOMuhlo9iKx3i7Tcgf8uf40aOx94rwqy/RB0qLIsUvm61WzpuwLCT7dZq4eRck9fwjhglOKaoHiFJaTvsTYO4AoFHV7HDPE4UCftVWk4lW/eNJ+FpNDvZXvh3JYjEKbV++qz2gDGPanzLSDc1kzW42UnqUKygZNBkBxhXPITeqC+irS9OE2BQSRG0R2nDh2TD2IJPxRAE+jPY5TMVFYV+QMSVsqab6AQPQs6dbzF8SrTl+MwJL0EahWeVhkgozFZSh8x8C+RLJ6fjkbso3fftxwAbdmKZBnbl6waKIVOn0SzHjT2fa2ygImlIqzi6v+iXUMOqVzZnPEOBnFYDAEeQAkQ62jbkkqKqzEURonxMPbRzp5TTOGQRyPvCo0ezMgzfU06fqdg4oK6xWJVqXrNV8VcpT4Ob0kRjk= Content-Type: text/plain; charset="iso-8859-1" Content-ID: <964FEC3629009C42BC43CD921AC4CAFA@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: 3513f486-2f83-4480-7e40-08d76397df82 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2019 15:33:43.9316 (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: o24o0IufJJqG8GutFUgdGccB20k1xeYrehNCh92DaqOasAVg+FxiBiQZVbvsisglm8Aj0ppmavuwF34ejRUQN+NLk8mrKv6Jsr4+Zwnvvds= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5P190MB0547 Archived-At: Subject: Re: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04 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, 07 Nov 2019 15:33:50 -0000 On Thu, Nov 07, 2019 at 03:10:41PM +0000, Kent Watsen wrote: >=20 > Hi Juergen, >=20 > >> Noteworthily, the HTTP experts additionally said that they would have = no issue if the module were called something else (ietf-restful-http-client= /server?) as then it wouldn't appear to intending to be an all-encompassing= HTTP definition and it would no longer require involvement of the HTTP exp= erts to ensure correctness. > >>=20 > >=20 > > Changing the module name to ietf-restful-http-client/server makes any > > reuse of the definitions look back. >=20 > Can you clarify what you mean by "look back"? > The name just looks odd: Do I want to import something that is labeled as a restconf specific grouping? The HTTP people do not want us to define something that may look generic but do we want to define something that looks like a solution just for restconf? Well, perhaps we should just put the -restconf- thing in the name and future will tell us whether people reuse this or attempt to roll their own. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Nov 7 09:24:21 2019 Return-Path: <0100016e46e53383-ec073c86-f9d4-4358-9d78-b337f9cd9a58-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 DF4FD12093A; Thu, 7 Nov 2019 09:24:19 -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 XKSDL6shkNcr; Thu, 7 Nov 2019 09:24:18 -0800 (PST) Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEEA912093E; Thu, 7 Nov 2019 09:24:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1573147456; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=jzeD5+fsMQBVMYgqO6+C2IglewIsy6cH1B/ShR1wqjI=; b=Y+khX6gYG3oD5pBpcTBY7iar7ycHkmTlBItZMfUgze1eU8Xr4YbCkL8s7vT9nP5M VCV4T0Aa+48TY47lzQxKqM89ETwgq+xAqFX8jLpdzNj5dcqimnolVnnafIvRUrrkvDs JUrMt+bH4BbZGuXAb6syDwEmOgacrJBC8FqNCfQA= From: Kent Watsen Message-ID: <0100016e46e53383-ec073c86-f9d4-4358-9d78-b337f9cd9a58-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_26E16379-4213-4045-AED7-6AF8C2B9D7A9" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 7 Nov 2019 17:24:16 +0000 In-Reply-To: <20191107153342.gqtgyseqyvsppcul@anna.jacobs.jacobs-university.de> Cc: "httpbis-chairs@ietf.org" , "netconf@ietf.org" To: Juergen Schoenwaelder References: <704A1489-3BC0-4EFF-A5B0-7D664EA05970@gmail.com> <20191104.093427.842126049822749848.mbj@tail-f.com> <0100016e432d004b-32e62ef2-4e6c-48f6-8fa4-092c55778ea8-000000@email.amazonses.com> <20191107073755.kw6xqp5uqruiask6@anna.jacobs.jacobs-university.de> <0100016e466ae626-e9821117-8286-4f26-bc91-284d7dcaa453-000000@email.amazonses.com> <20191107153342.gqtgyseqyvsppcul@anna.jacobs.jacobs-university.de> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.11.07-54.240.8.83 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04 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, 07 Nov 2019 17:24:20 -0000 --Apple-Mail=_26E16379-4213-4045-AED7-6AF8C2B9D7A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >>>> Noteworthily, the HTTP experts additionally said that they would = have no issue if the module were called something else = (ietf-restful-http-client/server?) as then it wouldn't appear to = intending to be an all-encompassing HTTP definition and it would no = longer require involvement of the HTTP experts to ensure correctness. >>>>=20 >>>=20 >>> Changing the module name to ietf-restful-http-client/server makes = any >>> reuse of the definitions look back. >>=20 >> Can you clarify what you mean by "look back"? >>=20 >=20 > The name just looks odd: Do I want to import something that is labeled > as a restconf specific grouping? The HTTP people do not want us to > define something that may look generic but do we want to define > something that looks like a solution just for restconf? Well, perhaps > we should just put the -restconf- thing in the name and future will > tell us whether people reuse this or attempt to roll their own. I see, but note that I wrote "restfull" (not "restconf"), which is = important since the "https-notif" draft is NOT using RESTCONF (just = HTTP). That said, I don't see why we shouldn't proceed with "http", as that is = what the protocol layer is called. At one point the HTTP chairs said = that, if we wanted to use "http", then we should involve the httpbis WG, = which makes sense, but shouldn't (in my mind) block an adoption. I = suggest that we take the draft to the httpbis list and (maybe) present = it in the httpbis session. =20 A couple days ago I looked for the httpbis list, but couldn't find it. = Their agenda [1] looks packed, so probably too late for a new request, = but if the HTTP chairs are reading this and think we could squeeze in a = quick preso, that would be great, otherwise, pointers to the httpbis = list would be appreciated. [1] = https://datatracker.ietf.org/meeting/106/materials/agenda-106-httpbis-01.h= tml = Kent --Apple-Mail=_26E16379-4213-4045-AED7-6AF8C2B9D7A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Noteworthily, the HTTP = experts additionally said that they would have no issue if the module = were called something else (ietf-restful-http-client/server?) as then it = wouldn't appear to intending to be an all-encompassing HTTP definition = and it would no longer require involvement of the HTTP experts to ensure = correctness.


Changing the module name to ietf-restful-http-client/server = makes any
reuse of the definitions look back.

Can you clarify what you mean by = "look back"?


The = name just looks odd: Do I want to import something that is labeled
as a restconf specific grouping? The HTTP people do not want = us to
define something that may look generic but do we = want to define
something that looks like a solution just = for restconf? Well, perhaps
we should just put the = -restconf- thing in the name and future will
tell us = whether people reuse this or attempt to roll their own.

I = see, but note that I wrote "restfull" (not "restconf"), which is = important since the "https-notif" draft is NOT using RESTCONF (just = HTTP).

That said, I don't see why we = shouldn't proceed with "http", as that is what the protocol layer is = called.   At one point the HTTP chairs said that, if we wanted to = use "http", then we should involve the httpbis WG, which makes sense, = but shouldn't (in my mind) block an adoption.   I suggest that we = take the draft to the httpbis list and (maybe) present it in = the httpbis session.  

A couple days ago I looked for the httpbis list, = but couldn't find it.  Their agenda [1] looks packed, so probably = too late for a new request, but if the HTTP chairs are reading this and = think we could squeeze in a quick preso, that would be great, otherwise, = pointers to the httpbis list would be appreciated.


Kent

= --Apple-Mail=_26E16379-4213-4045-AED7-6AF8C2B9D7A9-- From nobody Thu Nov 7 11:51:03 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C66E4120255; Thu, 7 Nov 2019 11:51:01 -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, SPF_HELO_NONE=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 ct-izbpNf2eh; Thu, 7 Nov 2019 11:50: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 BEAF71200E0; Thu, 7 Nov 2019 11:50:59 -0800 (PST) Received: from localhost (h-4-44.A165.priv.bahnhof.se [158.174.4.44]) by mail.tail-f.com (Postfix) with ESMTPSA id AC0921AE0388; Thu, 7 Nov 2019 20:50:57 +0100 (CET) Date: Thu, 07 Nov 2019 20:50:57 +0100 (CET) Message-Id: <20191107.205057.1889050828820990344.mbj@tail-f.com> To: kent+ietf@watsen.net Cc: J.Schoenwaelder@jacobs-university.de, httpbis-chairs@ietf.org, netconf@ietf.org From: Martin Bjorklund In-Reply-To: <0100016e46e53383-ec073c86-f9d4-4358-9d78-b337f9cd9a58-000000@email.amazonses.com> References: <0100016e466ae626-e9821117-8286-4f26-bc91-284d7dcaa453-000000@email.amazonses.com> <20191107153342.gqtgyseqyvsppcul@anna.jacobs.jacobs-university.de> <0100016e46e53383-ec073c86-f9d4-4358-9d78-b337f9cd9a58-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] Adoption call for draft-kwatsen-netconf-http-client-server-04 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, 07 Nov 2019 19:51:02 -0000 Hi, Kent Watsen wrote: > > >>>> Noteworthily, the HTTP experts additionally said that they would have > >>>> no issue if the module were called something else > >>>> (ietf-restful-http-client/server?) as then it wouldn't appear to > >>>> intending to be an all-encompassing HTTP definition and it would no > >>>> longer require involvement of the HTTP experts to ensure correctness. > >>>> > >>> > >>> Changing the module name to ietf-restful-http-client/server makes any > >>> reuse of the definitions look back. > >> > >> Can you clarify what you mean by "look back"? > >> > > > > The name just looks odd: Do I want to import something that is labeled > > as a restconf specific grouping? The HTTP people do not want us to > > define something that may look generic but do we want to define > > something that looks like a solution just for restconf? Well, perhaps > > we should just put the -restconf- thing in the name and future will > > tell us whether people reuse this or attempt to roll their own. > > I see, but note that I wrote "restfull" (not "restconf"), which is > important since the "https-notif" draft is NOT using RESTCONF (just > HTTP). > > That said, I don't see why we shouldn't proceed with "http", as that > is what the protocol layer is called. At one point the HTTP chairs > said that, if we wanted to use "http", then we should involve the > httpbis WG, which makes sense, but shouldn't (in my mind) block an > adoption. I suggest that we take the draft to the httpbis list and > (maybe) present it in the httpbis session. I think it is quite clear that the WG doesn't want more delays. So I think that either we simply don't add this grouping *at this point*, and define the necessary nodes in the higher-level modules, even though it is not perfect; or we define the "restful" module with these groupings, even though that is also perhaps not perfect. /martin > A couple days ago I looked for the httpbis list, but couldn't find it. > Their agenda [1] looks packed, so probably too late for a new request, > but if the HTTP chairs are reading this and think we could squeeze in > a quick preso, that would be great, otherwise, pointers to the httpbis > list would be appreciated. > > [1] > https://datatracker.ietf.org/meeting/106/materials/agenda-106-httpbis-01.html > > > Kent > From nobody Thu Nov 7 17:44:45 2019 Return-Path: <0100016e48af524e-96c5b2d0-6b19-4e26-b3b6-8bb8021851d8-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 45E781200CC; Thu, 7 Nov 2019 17:44:43 -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 C7pmSiqsE_qi; Thu, 7 Nov 2019 17:44:41 -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 4FB6B12004A; Thu, 7 Nov 2019 17:44:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1573177479; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=WEYc926jcrQcUMag5iG5Zyr4hIitlpdSaGjdCMaJ9mk=; b=cI5RkN/cRPoUEusT1API1PM+0DocuiNpSNpZlLeXy6C7N5SWCafs0z8oPozmkQCc 4dGm2giwlS/RTuP5TyYpF6sWyRZO1D4PX1KFTvfu1o97MhFrCw28wVQkYfHo04ks9qH FL/oJMmjEEgbwVOTNUhODLMoKncrQKxToAR11I5s= From: Kent Watsen Message-ID: <0100016e48af524e-96c5b2d0-6b19-4e26-b3b6-8bb8021851d8-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_92294D73-B8D3-449F-9F03-6A1D9F87DBF3" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 8 Nov 2019 01:44:39 +0000 In-Reply-To: <20191107.205057.1889050828820990344.mbj@tail-f.com> Cc: Juergen Schoenwaelder , httpbis-chairs@ietf.org, "netconf@ietf.org" To: Martin Bjorklund References: <0100016e466ae626-e9821117-8286-4f26-bc91-284d7dcaa453-000000@email.amazonses.com> <20191107153342.gqtgyseqyvsppcul@anna.jacobs.jacobs-university.de> <0100016e46e53383-ec073c86-f9d4-4358-9d78-b337f9cd9a58-000000@email.amazonses.com> <20191107.205057.1889050828820990344.mbj@tail-f.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.11.08-54.240.8.31 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04 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, 08 Nov 2019 01:44:43 -0000 --Apple-Mail=_92294D73-B8D3-449F-9F03-6A1D9F87DBF3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Martin, > I think it is quite clear that the WG doesn't want more delays. =20 Is it? I only know that Balazs K. wishes to have the first three = drafts (crypto-types, truststore, and keystore) completed soon. The = Nokia/BBF folks were interested in netconf-server, but forked long ago. = Otherwise, I'm unaware of anyone stating a preference. For myself, I = only hope to achieve a good result. > So I think that either we simply don't add this grouping *at this = point*, > and define the necessary nodes in the higher-level modules, even > though it is not perfect; or we define the "restful" module with these > groupings, even though that is also perhaps not perfect. ietf-restful-client and ietf-restful-server sound nice, but not so much = in a stack: tcp-server-parameters : { ... }, tls-server-parameters : { ... }, restful-server-parameters : { ... }, <---- end-user says = "what's that?" restconf-server-parameters : { ... } or (for https-notif) tcp-client-parameters : { ... }, tls-client-parameters : { ... }, restful-client-parameters : { ... } <---- end-user says "what's = that?" Actually, the above is purposely inaccurate. If you recall, we = switched to having container-less groupings, thus the consuming module = can name the container whatever it wants, so the net-net is no impact = other than changing the import and uses statements. Though I still = don't know why we should do even this, given the lack of any response to = my Oct 30th message. Kent // contributor --Apple-Mail=_92294D73-B8D3-449F-9F03-6A1D9F87DBF3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Martin,

I think it is quite clear = that the WG doesn't want more delays. =  

Is it? =   I only know that Balazs K. wishes to have the first three drafts = (crypto-types, truststore, and keystore) completed soon.  The = Nokia/BBF folks were interested in netconf-server, but forked long ago. =  Otherwise, I'm unaware of anyone stating a preference.   For = myself, I only hope to achieve a good result.


So I think that either we simply don't = add this grouping *at this point*,
and define the = necessary nodes in the higher-level modules, even
though = it is not perfect; or we define the "restful" module with these
groupings, even though that is also perhaps not perfect.

ietf-restful-client and ietf-restful-server sound = nice, but not so much in a stack:

    tcp-server-parameters : { ... = },
    tls-server-parameters : { ... = },
    restful-server-parameters : { = ... },        <---- end-user says "what's = that?"
    = restconf-server-parameters : { ... }

or (for https-notif)

    tcp-client-parameters : { ... = },
    tls-client-parameters : { ... = },
    restful-client-parameters : { = ... }    <---- end-user says "what's that?"


Actually, the above is purposely inaccurate. =   If you recall, we switched to having container-less groupings, = thus the consuming module can name the container whatever it wants, so = the net-net is no impact other than changing the import and uses = statements.   Though I still don't know why we should do even this, = given the lack of any response to my Oct 30th message.


Kent // = contributor

= --Apple-Mail=_92294D73-B8D3-449F-9F03-6A1D9F87DBF3-- From nobody Fri Nov 8 16:14:36 2019 Return-Path: <0100016e4d8323b0-2a182947-485d-43e6-908c-13bc5ad2f210-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 05AC6120124 for ; Fri, 8 Nov 2019 16:14:35 -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 CqTHsFLOX5o2 for ; Fri, 8 Nov 2019 16:14:32 -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 DF180120047 for ; Fri, 8 Nov 2019 16:14:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1573258470; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=laB/SZL/mwbnuXKQte3AG7wlTswhUK2TC+NpSAM3MF4=; b=nMwVazc0SwWbRNxFiGh7Ce5gXjr7z1rzvcOe2Rmus0m+fdyn2LlMfaWGycoOdUCX ueZ7JI/9Nv5JRpKWRz4oWo3zR/ecnhvGB/pyPR79bG8MSCZ+kTU8vdCYqAb0ezIjPn3 1jOA8zsie8ogS9xA2WHrClQgvI8afLz0p782S4Rw= From: Kent Watsen Message-ID: <0100016e4d8323b0-2a182947-485d-43e6-908c-13bc5ad2f210-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_59EEF00F-EEDA-4E9F-81FC-0B51B1A0F040" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 9 Nov 2019 00:14:30 +0000 In-Reply-To: <20191106.142822.2117534105126283386.mbj@tail-f.com> Cc: "netconf@ietf.org" To: Martin Bjorklund References: <20191104.111319.869021723410428870.mbj@tail-f.com> <0100016e39631e46-c007fd65-2e51-47a6-bd27-764f5257a16c-000000@email.amazonses.com> <20191106.142822.2117534105126283386.mbj@tail-f.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.11.09-54.240.8.31 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] client identification in ietf-netconf-server 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, 09 Nov 2019 00:14:35 -0000 --Apple-Mail=_59EEF00F-EEDA-4E9F-81FC-0B51B1A0F040 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Martin, [Not trimming down because too much context would be lost.] >>> The ietf-netconf-server module has this: >>>=20 >>> grouping netconf-server-grouping { >>> ... >>> container client-identification { >>> ... >>> container cert-maps { >>> when "../../../../tls"; >>> uses x509c2n:cert-to-name; >>> ... >>> } >>> } >>> } >>>=20 >>> Note the "when" expression. This means that the grouping has a = strong >>> depency on where is it used. We should try to avoid such a design. >>=20 >>=20 >> Would this be better? =20 >>=20 >> OLD >> when "../../../../tls"; >>=20 >> NEW >> if-feature "tls-listen or tls-call-home"; >=20 > Yes, but see below. >=20 >=20 >>> But should't this cert-to-name list be available when x509-certs are >>> used also with SSH? >>=20 >> Hmmm. I'd assumed that, with RFC 6187, the username was still passed >> as its own field, but I see this in Section 4: >>=20 >> For the purposes of user authentication, the mapping between >> certificates and user names is left as an implementation and >> configuration issue for implementers and system administrators. >=20 > If the username was used as identification it would mean that with a > valid cert I could present myself as any user! >=20 >> So you may be right about that. I only ever looked at RFC 6187 from >> the perspective of the server presenting an IDevID certificate. But, >> assuming it's true, then perhaps this: >>=20 >> NEWEST: >> if-feature "tls-listen or tls-call-home or = sshcmn:ssh-x509-certs"; >=20 > Ok. >=20 > This gives: >=20 > grouping netconf-server-grouping { > description ...; > container client-identification { > description > "Specifies a mapping through which clients MAY be identified > (i.e., the NETCONF username) from a supplied certificate. > Note that a client MAY alternatively be identified via an > alternate authentication scheme."; > container cert-maps { > if-feature "tls-listen or tls-call-home or = sshcmn:ssh-x509-certs"; Yes. > But since the description of the "client-identification" says that it > is used only with certificates, perhaps that container's name should > reflect this, and the if-feature statement moved to that container? > Perhaps: >=20 > container client-cert-identification > if-feature "tls-listen or tls-call-home or = sshcmn:ssh-x509-certs"; >=20 > and also perhaps remove 'cert-maps', and use the cert-to-name grouping > directly here? Good. My only hesitation is that someday there may be a need for = another way to identify clients, but that sounds too far out (even for = me) to squabble over. But a better name is needed. = "cert-based-client-identification" would be more accurate, but that = seems overly long. Looking at a snippet of config might help... netconf-server-parameters : { something-here : [ { cert-to-name : { ... } cert-to-name : { ... }, ... cert-to-name : { ... } } ] } How about "cert-to-name-mappings"? ( know, almost the same length, but = half the number of syllables!). But that name leaves out the word = "identity", which is may be important in security circles, so maybe = "client-identity-mappings"? This seems pretty good, right? (I renamed = it to "client-identity-mappings" in both ietf-netconf-server and = ietf-restconf-server) >>> The current data model for ssh specifies certs on >>> a per-user basis. But this requires lots of configuration in the = case >>> that the cert encodes the user name (even though the name is in the >>> cert you have to configure each user on each device). I suggest we >>> align the model for SSH with the TLS model for cert identification. >>=20 >> We certainly want to factor out configuration where possible. I'd >> need to look into this more. Perhaps you can send a diff? >=20 > Today we have under 'ssh-server-parameters/client-authentication': >=20 > +--:(local) {local-client-auth-supported}? > +--rw users > +--rw user* [name] > +--rw name string > +--rw password? ianach:crypt-hash > +--rw host-keys! > | +--rw (local-or-truststore) > | +--:(local) {local-definitions-supported}? > | | +--rw local-definition > | | +--rw host-key* ct:ssh-host-key > | | +--rw cert* = trust-anchor-cert-cms > | | +---n certificate-expiration > | | +-- expiration-date yang:date-and-time Not to take away from your point, but the previous three lines don't = exist in the model. > | +--:(truststore) {truststore-supported,ssh-host-keys}? > | +--rw truststore-reference? ts:host-keys-ref > +--rw ca-certs! {sshcmn:ssh-x509-certs}? > | +--rw (local-or-truststore) > | +--:(local) {local-definitions-supported}? > | | +--rw local-definition > | | +--rw cert* = trust-anchor-cert-cms > | | +---n certificate-expiration > | | +-- expiration-date yang:date-and-time > | +--:(truststore) = {truststore-supported,x509-certificates}? > | +--rw truststore-reference? ts:certificates-ref > +--rw client-certs! {sshcmn:ssh-x509-certs}? > +--rw (local-or-truststore) > +--:(local) {local-definitions-supported}? > | +--rw local-definition > | +--rw cert* = trust-anchor-cert-cms > | +---n certificate-expiration > | +-- expiration-date yang:date-and-time > +--:(truststore) = {truststore-supported,x509-certificates}? > +--rw truststore-reference? ts:certificates-ref >=20 > I think host-keys, ca-certs and client-certs should be moved out of > the user list: >=20 > +--:(local) {local-client-auth-supported}? > +--rw users > | +--rw user* [name] > | +--rw name string > | +--rw password? ianach:crypt-hash > +--rw host-keys! > | +--rw (local-or-truststore) > | +--:(local) {local-definitions-supported}? > | | +--rw local-definition > | | +--rw host-key* ct:ssh-host-key > | | +--rw cert* trust-anchor-cert-cms > | | +---n certificate-expiration > | | +-- expiration-date yang:date-and-time Again, not to take away from your point, but the previous three lines = don't exist in the model. > | +--:(truststore) {truststore-supported,ssh-host-keys}? > | +--rw truststore-reference? ts:host-keys-ref > +--rw ca-certs! {sshcmn:ssh-x509-certs}? > | +--rw (local-or-truststore) > | +--:(local) {local-definitions-supported}? > | | +--rw local-definition > | | +--rw cert* trust-anchor-cert-cms > | | +---n certificate-expiration > | | +-- expiration-date yang:date-and-time > | +--:(truststore) {truststore-supported,x509-certificates}? > | +--rw truststore-reference? ts:certificates-ref > +--rw client-certs! {sshcmn:ssh-x509-certs}? > +--rw (local-or-truststore) > +--:(local) {local-definitions-supported}? > | +--rw local-definition > | +--rw cert* trust-anchor-cert-cms > | +---n certificate-expiration > | +-- expiration-date yang:date-and-time > +--:(truststore) {truststore-supported,x509-certificates}? > +--rw truststore-reference? ts:certificates-ref I agree that "ca-certs" and "client-certs" should be pulled out (as they = are in ietf-tls-server), but I'm unsure if "host-keys" can be, at least = not unless we introduce something like "host-key-to-name" maps, right? For now, I only pulled out "ca-certs" and "client-certs". > But also here I think that the choice "local-or-external" isn't > ideal. I think that a system that implements some "external" > mechanism should/would augement this data model with specific nodes > for that mechanism. As a simplistic example: >=20 > augment /netconf-server/.../client-authentication { > leaf use-host-keys-in-filesystem { > leaf boolean; > } > } >=20 > In this case, requiring the client to configure both this new leaf and > "client-auth-defined-elsewhere" seems redundant and non-intuitive. Agreed. > Another case is a system that *always* use the filesystem host keys. > It would simply just always do that, and again, requiring the client > to configure "client-auth-defined-elsewhere" seems incorrect. Agreed. > So my suggestion is to remove the choice "local-or-external" and > remove the external case, and instead document that (i) systems may > use some other hard-wired mechanism or (ii) other modules can augment > this container with additional control parameters for other > mechanisms. Agree in principle, but unsure about implementation. One thing = important to me you didn't mention is having the "local" configuration = gated by a "feature" statement. So, do we float the = "local-client-auth-supported" (renamed appropriately) up to the = "client-authentication" container? If so, would that incorrectly cover = the "supported-authentication-methods" descendent? Suggestions? >>> For TLS, the data model has the following structure: >>>=20 >>> +--rw netconf-server >>> +--rw listen! {ssh-listen or tls-listen}? >>> +--rw idle-timeout? uint16 >>> +--rw endpoint* [name] >>> +--rw name string >>> +--rw (transport) >>> ... >>> +--:(tls) {tls-listen}? >>>=20 >>> [ reset indentation to make the diagram easier to read ] >>>=20 >>> +--rw tls >>> +--rw tcp-server-parameters >>> ... >>> +--rw tls-server-parameters >>> | +--rw server-identity >>> ... >>> | +--rw client-authentication! >>> | | +--rw (required-or-optional) >>> | | | +--:(required) >>> | | | | +--rw required? empty >>> | | | +--:(optional) >>> | | | +--rw optional? empty >>> | | +--rw (local-or-external) >>> | | +--:(local) {local-client-auth-supported}? >>> | | | +--rw ca-certs! {ts:x509-certificates}? >>> | | | | +--rw (local-or-truststore) >>> | | | | +--:(local) {local-definitions-supported}? >>> | | | | | +--rw local-definition >>> | | | | | +--rw cert* trust-anchor-cert-cms >>> | | | | | +---n certificate-expiration >>> | | | | | +-- expiration-date >>> | | | | | yang:date-and-time >>> | | | | +--:(truststore) >>> | | | | = {truststore-supported,x509-certificates}? >>> | | | | +--rw truststore-reference? >>> | | | | ts:certificates-ref >>> | | | +--rw client-certs! {ts:x509-certificates}? >>> | | | +--rw (local-or-truststore) >>> | | | +--:(local) {local-definitions-supported}? >>> | | | | +--rw local-definition >>> | | | | +--rw cert* trust-anchor-cert-cms >>> | | | | +---n certificate-expiration >>> | | | | +-- expiration-date >>> | | | | yang:date-and-time >>> | | | +--:(truststore) >>> | | | = {truststore-supported,x509-certificates}? >>> | | | +--rw truststore-reference? >>> | | | ts:certificates-ref >>> | | +--:(external) >>> | | {external-client-auth-supported}? >>> | | +--rw client-auth-defined-elsewhere? >>> | | empty >>> ... >>> +--rw netconf-server-parameters >>> +--rw client-identification >>> +--rw cert-maps >>> +--rw cert-to-name* [id] >>> +--rw id uint32 >>> +--rw fingerprint >>> | x509c2n:tls-fingerprint >>> +--rw map-type identityref >>> +--rw name string >>=20 >>=20 >>=20 >>=20 >>> It is not clear how this is used by the server to end up either with >>> an authenticated user name or failed authentication. >>=20 >> Okay, let's fix that. >>=20 >>=20 >>> First of all, how is the "required-or-optional" choice used in a >>> NETCONF server? What happens if an operation configures this to >>> "optional"? (side note: why is this a choice of empty leafs instead >>> of a leaf?) >>=20 >> Hmmm, this 'choice' seems unneeded for NETCONF. The "choice" is >> coming from the ietf-tls-server, and a similar "choice" is in >> ietf-http-server. It was put there, in part, for RESTCONF, as >> user-auth can occur at either (or both!) protocol layers... >=20 > Ok. Yes, the RESTCONF auth mechanism is interesting. Let's discuss > that in a separate thread. Okay. For now, I'll leave the "required-or-optional" in both = ietf-tls-server and ietf-http-server. However, to address the issue = that it can never apply to NETCONF, it seems that a possible strategy = would be to move both instances to augmentations defined in = ietf-restconf-server... That said, to go along with some of your thinking from above, it's not = clear how an application would consume the "required-or-optional" = configuration. Case in point, in the RESTCONF server based product I'm = working on, the configuration for each client, which is defined outside = the restconf-server-grouping tree, has descendants nodes like = "http-password" and "tls-trust-anchor", with meanings that, if defined, = then the client MUST present said auth credentials at that = protocol-layer. IIRC, the code doesn't check these flags at all. =20 So, rather than moving both "required-or-optional" instances to = augmentations in ietf-restconf-server, maybe they can just be deleted? >>> Second, I assume that the idea is that the server uses the config >>> params in "local-or-external" and the certificate presented by the >>> client and after this step is either accepted or rejected. It is = not >>> clear what is supposed to happen if someone configures >>> "client-auth-defined-elsewhere". I think it is better to not define >>> this case, but (perhaps) keep the choice and explain that other >>> modules can augment additional config params here for other >>> authentication mechanisms. >>=20 >> Well that's just the thing, the goal is to enable user-auth to NOT be >> defined here. As the description statement in ietf-tls-server says: >>=20 >> "Configuring credentials externally enables applications >> to place client authentication with client definitions, >> rather then in a part of a data model principally >> concerned with configuring the TLS transport."; >=20 > I totally agree with this. I am questioning the solution. See above > for my proposal. Ack. >>> Next, my guess is that the intention is that if the cert was = accepted >>> in the step above, it is checked in cert-to-name to see if a user = name >>> can be derived. >>=20 >> Yes. >>=20 >>=20 >>> In another thread you mentioned that if a local cert is configured, = it >>> seems redundant to also configure the cert as a fingerprint in >>> cert-to-name. I'm not sure about this. But perhaps you can use the >>> same "map-type" and "name" leafs in the "client-cert" container? It >>> is not as easy for the "truststore-reference"; perhaps you'd have to >>> augment the truststore with these leafs in this case. >>=20 >> In context, that statement I made before is a relatively minor >> objection. That said, I don't understand your proposal, are you >> suggesting to recreate the essence of 'cert-to-name'? Another idea I >> had was that the fingerprint could be in a "union" with also a >> truststore-reference, which is only mildly better... >=20 > Aha, now I understand your suggestion of making fingerprint optional. > I agree that this could work. However, I assume it must be used with > care. If you know for sure that a successful result from the > authentication mechanism means that CA cert X has been used, you can > save some typing by not configuring the fingerprint of X. So the > question is if it is worth it? Yes, saving typing is the gist of it, but I don't think handling with = care is needed or, rather, it's no more care. As I understand it, a = fingerprint would be redundant in the common case, i.e., most configs = would not have to define a fingerprint, so the optimization seems worth = it to me. Separately, be aware that calculating an x509c2n:tls-fingerprint is not = a simple copy/paste. That is, the command `openssl x509 -in CERT.pem = -noout -sha256 -fingerprint` is close, but not exactly what is needed. =20= > /martin >=20 Kent // contributor --Apple-Mail=_59EEF00F-EEDA-4E9F-81FC-0B51B1A0F040 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Hi Martin,

[Not trimming down because too much context would = be lost.]


The = ietf-netconf-server module has this:

= grouping netconf-server-grouping {
  ...
  container client-identification {
=     ...
=     container cert-maps {
=       when "../../../../tls";
=       uses x509c2n:cert-to-name;
      ...
=     }
  }
= }

Note the "when" expression.  This = means that the grouping has a strong
depency on where is = it used.  We should try to avoid such a design.


Would this be = better?   

OLD
=       when "../../../../tls";

NEW
if-feature "tls-listen or = tls-call-home";

Yes, but see = below.


But = should't this cert-to-name list be available when x509-certs are
used also with SSH?

Hmmm.  I'd assumed that, with RFC 6187, the username was = still passed
as its own field, but I see this in Section = 4:

  For the purposes of user = authentication, the mapping between
=   certificates and user names is left as an implementation = and
  configuration issue for implementers and = system administrators.

If the = username was used as identification it would mean that with a
valid cert I could present myself as any user!

So you = may be right about that.  I only ever looked at RFC 6187 from
the perspective of the server presenting an IDevID = certificate.  But,
assuming it's true, then perhaps = this:

NEWEST:
= if-feature "tls-listen or tls-call-home or = sshcmn:ssh-x509-certs";

Ok.

This gives:

=  grouping netconf-server-grouping {
=    description ...;
=    container client-identification {
=      description
=        "Specifies a mapping through = which clients MAY be identified
=         (i.e., the NETCONF = username) from a supplied certificate.
=         Note that a client MAY = alternatively be identified via an
=         alternate authentication = scheme.";
     container = cert-maps {
=        if-feature "tls-listen or = tls-call-home or sshcmn:ssh-x509-certs";

Yes.

But since the description of = the "client-identification" says that it
is used only with = certificates, perhaps that container's name should
reflect = this, and the if-feature statement moved to that container?
Perhaps:

=    container client-cert-identification
=      if-feature "tls-listen or tls-call-home or = sshcmn:ssh-x509-certs";

and also perhaps = remove 'cert-maps', and use the cert-to-name grouping
directly here?

Good.  My only hesitation is that someday = there may be a need for another way to identify clients, but that sounds = too far out (even for me) to squabble over.  But a better name is = needed.  "cert-based-client-identification" would be more accurate, = but that seems overly long.  Looking at a snippet of config might = help...

      = netconf-server-parameters : {
        = something-here : [
          = {
            cert-to-name : { = ... }
            cert-to-name : = { ... },
            = ...
            cert-to-name : { = ... }
          }
  =       ]
      }

How about "cert-to-name-mappings"?  ( know, = almost the same length, but half the number of syllables!).  But = that name leaves out the word "identity", which is may be important in = security circles, so maybe "client-identity-mappings"?   This seems = pretty good, right?  (I renamed it to "client-identity-mappings" in = both ietf-netconf-server and ietf-restconf-server)


The current data model = for ssh specifies certs on
a per-user basis. But this = requires lots of configuration in the case
that the cert = encodes the user name (even though the name is in the
cert = you have to configure each user on each device).  I suggest we
align the model for SSH with the TLS model for cert = identification.

We certainly = want to factor out configuration where possible.  I'd
need to look into this more.  Perhaps you can send a = diff?

Today we have under = 'ssh-server-parameters/client-authentication':

 +--:(local) {local-client-auth-supported}?
    +--rw users
=        +--rw user* [name]
=           +--rw name =            string =           +--rw = password?       ianach:crypt-hash
=           +--rw = host-keys!
=           | =  +--rw (local-or-truststore)
=           | =     +--:(local) {local-definitions-supported}?
=           | =     |  +--rw local-definition
=           | =     |     +--rw host-key* =             &n= bsp;   ct:ssh-host-key
=           | =     |     +--rw cert* =             &n= bsp;       trust-anchor-cert-cms
=           | =     |     +---n = certificate-expiration
=           | =     |        +-- = expiration-date    yang:date-and-time

Not to = take away from your point, but the previous three lines don't exist in = the model.

=           | =     +--:(truststore) = {truststore-supported,ssh-host-keys}?
=           | =        +--rw truststore-reference? =   ts:host-keys-ref
=           +--rw = ca-certs! {sshcmn:ssh-x509-certs}?
=           | =  +--rw (local-or-truststore)
=           | =     +--:(local) {local-definitions-supported}?
=           | =     |  +--rw local-definition
=           | =     |     +--rw cert* =             &n= bsp;       trust-anchor-cert-cms
=           | =     |     +---n = certificate-expiration
=           | =     |        +-- = expiration-date    yang:date-and-time
=           | =     +--:(truststore) = {truststore-supported,x509-certificates}?
=           | =        +--rw truststore-reference? =   ts:certificates-ref
=           +--rw = client-certs! {sshcmn:ssh-x509-certs}?
=             &n= bsp;+--rw (local-or-truststore)
=             &n= bsp;   +--:(local) {local-definitions-supported}?
=             &n= bsp;   |  +--rw local-definition
=             &n= bsp;   |     +--rw cert* =             &n= bsp;       trust-anchor-cert-cms
=             &n= bsp;   |     +---n = certificate-expiration
=             &n= bsp;   |        +-- = expiration-date    yang:date-and-time
=             &n= bsp;   +--:(truststore) = {truststore-supported,x509-certificates}?
=             &n= bsp;   +--rw truststore-reference? =   ts:certificates-ref

I think = host-keys, ca-certs and client-certs should be moved out of
the user list:

=  +--:(local) {local-client-auth-supported}?
=     +--rw users
=     |  +--rw user* [name]
=     |     +--rw name =            string     |     +--rw = password?       ianach:crypt-hash
    +--rw host-keys!
=     |  +--rw (local-or-truststore)
=     |     +--:(local) = {local-definitions-supported}?
    | =     |  +--rw local-definition
=     |     | =     +--rw host-key* =             &n= bsp;   ct:ssh-host-key
=     |     | =     +--rw cert* =             &n= bsp;       trust-anchor-cert-cms
    |     | =     +---n certificate-expiration
=     |     | =        +-- expiration-date =    yang:date-and-time

Again, = not to take away from your point, but the previous three lines don't = exist in the model.

=     |     +--:(truststore) = {truststore-supported,ssh-host-keys}?
=     | =        +--rw truststore-reference? =   ts:host-keys-ref
=     +--rw ca-certs! {sshcmn:ssh-x509-certs}?
    |  +--rw = (local-or-truststore)
    | =     +--:(local) {local-definitions-supported}?
    |     | =  +--rw local-definition
    | =     |     +--rw cert* =             &n= bsp;       trust-anchor-cert-cms
    |     | =     +---n certificate-expiration
=     |     | =        +-- expiration-date =    yang:date-and-time
=     |     +--:(truststore) = {truststore-supported,x509-certificates}?
=     | =        +--rw truststore-reference? =   ts:certificates-ref
=     +--rw client-certs! {sshcmn:ssh-x509-certs}?
       +--rw = (local-or-truststore)
=           +--:(local) = {local-definitions-supported}?
=           | =  +--rw local-definition
=           | =     +--rw cert* =             &n= bsp;       trust-anchor-cert-cms
=           | =     +---n certificate-expiration
=           | =        +-- expiration-date =    yang:date-and-time
=           +--:(truststor= e) {truststore-supported,x509-certificates}?
=             &n= bsp;+--rw truststore-reference?   ts:certificates-ref

I = agree that "ca-certs" and "client-certs" should be pulled out (as they = are in ietf-tls-server), but I'm unsure if "host-keys" can be, at least = not unless we introduce something like "host-key-to-name" maps, = right?

For now, I only pulled out = "ca-certs" and "client-certs".



But also here I think that the choice = "local-or-external" isn't
ideal.  I think that a = system that implements some "external"
mechanism = should/would augement this data model with specific nodes
for that mechanism.  As a simplistic example:

 augment = /netconf-server/.../client-authentication {
=    leaf use-host-keys-in-filesystem {
=      leaf boolean;
=    }
 }

In= this case, requiring the client to configure both this new leaf and
"client-auth-defined-elsewhere" seems redundant and = non-intuitive.

Agreed.

Another case is = a system that *always* use the filesystem host keys.
It = would simply just always do that, and again, requiring the client
to configure "client-auth-defined-elsewhere" seems = incorrect.

Agreed.

So my = suggestion is to remove the choice "local-or-external" and
remove the external case, and instead document that (i) = systems may
use some other hard-wired mechanism or (ii) = other modules can augment
this container with additional = control parameters for other
mechanisms.

Agree = in principle, but unsure about implementation.   One thing =  important to me you didn't mention is having the "local" = configuration gated by a "feature" statement.  So, do we float the = "local-client-auth-supported" (renamed appropriately) up to the = "client-authentication" container?  If so, would that incorrectly = cover the "supported-authentication-methods" descendent? =  Suggestions?


For TLS, the data model has the following structure:

+--rw netconf-server
=    +--rw listen! {ssh-listen or tls-listen}?
=       +--rw idle-timeout? =   uint16
=       +--rw endpoint* [name]
=          +--rw name =         string
=          +--rw = (transport)
=             ..= .
=             +-= -:(tls) {tls-listen}?

  [ reset = indentation to make the diagram easier to read ]

 +--rw tls
    +--rw = tcp-server-parameters
    ...
    +--rw tls-server-parameters
    |  +--rw server-identity
=           ...
    |  +--rw = client-authentication!
    |  | =  +--rw (required-or-optional)
=     |  |  |  +--:(required)
    |  |  |  | =  +--rw required?    empty
=     |  |  |  +--:(optional)
    |  |  | =     +--rw optional?    empty
    |  |  +--rw = (local-or-external)
    |  | =     +--:(local) =  {local-client-auth-supported}?
=     |  |     |  +--rw = ca-certs!   {ts:x509-certificates}?
=     |  |     |  | =  +--rw (local-or-truststore)
=     |  |     |  | =     +--:(local) =  {local-definitions-supported}?
=     |  |     |  | =     |  +--rw local-definition
=     |  |     |  | =     |     +--rw cert* =   trust-anchor-cert-cms
=     |  |     |  | =     |     +---n = certificate-expiration
    |  | =     |  |     | =        +-- expiration-date
    |  |     | =  |     | =             &n= bsp;  yang:date-and-time
=     |  |     |  | =     +--:(truststore)
=     |  |     |  | =             &n= bsp;{truststore-supported,x509-certificates}?
=     |  |     |  | =        +--rw truststore-reference?
    |  |     | =  | =             &n= bsp;  ts:certificates-ref
=     |  |     |  +--rw = client-certs!  {ts:x509-certificates}?
=     |  |     | =     +--rw (local-or-truststore)
=     |  |     | =        +--:(local) =  {local-definitions-supported}?
=     |  |     | =        |  +--rw = local-definition
    |  | =     |        | =     +--rw cert* =     trust-anchor-cert-cms
=     |  |     | =        | =     +---n certificate-expiration
=     |  |     | =        | =        +-- expiration-date
    |  |     | =        | =             &n= bsp;  yang:date-and-time
=     |  |     | =        +--:(truststore)
=     |  |     | =             &n= bsp;   {truststore-supported,x509-certificates}?
    |  |     | =           +--rw = truststore-reference?
    |  | =     | =             &n= bsp;     ts:certificates-ref
=     |  | =     +--:(external)
=     |  | =             &n= bsp;{external-client-auth-supported}?
=     |  | =        +--rw = client-auth-defined-elsewhere?
    | =  | =             &n= bsp;  empty
=         ...
=     +--rw netconf-server-parameters
=        +--rw client-identification
=           +--rw = cert-maps
=             &n= bsp;+--rw cert-to-name* [id]
=             &n= bsp;   +--rw id =             ui= nt32
=             &n= bsp;   +--rw fingerprint
=             &n= bsp;   | =       x509c2n:tls-fingerprint
= =             &n= bsp;   +--rw map-type =       identityref
=             &n= bsp;   +--rw name =           string




It is not clear how this = is used by the server to end up either with
an = authenticated user name or failed authentication.

Okay, let's fix that.


First of all, how is the "required-or-optional" choice used = in a
NETCONF server?  What happens if an operation = configures this to
"optional"?  (side note: why is = this a choice of empty leafs instead
of a leaf?)

Hmmm, this 'choice' seems = unneeded for NETCONF.  The "choice" is
coming from = the ietf-tls-server, and a similar "choice" is in
ietf-http-server. It was put there, in part, for RESTCONF, = as
user-auth can occur at either (or both!) protocol = layers...

Ok.  Yes, the = RESTCONF auth mechanism is interesting.  Let's discuss
that in a separate thread.

Okay. =  For now, I'll leave the "required-or-optional" in both = ietf-tls-server and ietf-http-server.   However, to address the = issue that it can never apply to NETCONF, it seems that a possible = strategy would be to move both instances to augmentations defined in = ietf-restconf-server...

That said, = to go along with some of your thinking from above, it's not clear how an = application would consume the "required-or-optional" configuration. =  Case in point, in the RESTCONF server based product I'm working = on, the configuration for each client, which is defined outside the = restconf-server-grouping tree, has descendants nodes like = "http-password" and "tls-trust-anchor", with meanings that, if defined, = then the client MUST present said auth credentials at that = protocol-layer.  IIRC, the code doesn't check these flags at all. =  

So, rather than moving both = "required-or-optional" instances to augmentations in = ietf-restconf-server, maybe they can just be deleted?



Second, I = assume that the idea is that the server uses the config
params in "local-or-external" and the certificate presented = by the
client and after this step is either accepted or = rejected.  It is not
clear what is supposed to happen = if someone configures
"client-auth-defined-elsewhere". =  I think it is better to not define
this case, but = (perhaps) keep the choice and explain that other
modules = can augment additional config params here for other
authentication mechanisms.

Well that's just the thing, the goal is to enable user-auth = to NOT be
defined here.  As the description statement = in ietf-tls-server says:

=          "Configuring = credentials externally enables applications
=           to place = client authentication with client definitions,
=           rather then = in a part of a data model principally
=           concerned = with configuring the TLS transport.";

I totally agree with this.  I am questioning the = solution.  See above
for my proposal.

Ack.


Next, my guess is that the intention is that if the cert was = accepted
in the step above, it is checked in cert-to-name = to see if a user name
can be derived.

Yes.


In = another thread you mentioned that if a local cert is configured, it
seems redundant to also configure the cert as a fingerprint = in
cert-to-name.  I'm not sure about this.  But = perhaps you can use the
same "map-type" and "name" leafs = in the "client-cert" container?  It
is not as easy = for the "truststore-reference"; perhaps you'd have to
augment the truststore with these leafs in this case.

In context, that statement I made = before is a relatively minor
objection.  That said, I = don't understand your proposal, are you
suggesting to = recreate the essence of 'cert-to-name'?  Another idea I
had was that the fingerprint could be in a "union" with also = a
truststore-reference, which is only mildly better...

Aha, now I understand your = suggestion of making fingerprint optional.
I agree that = this could work.  However, I assume it must be used with
care.  If you know for sure that a successful result = from the
authentication mechanism means that CA cert X has = been used, you can
save some typing by not configuring the = fingerprint of X.  So the
question is if it is worth = it?

Yes, saving typing is the gist of it, but I don't = think handling with care is needed or, rather, it's no more care.   = As I understand it, a fingerprint would be redundant in the common case, = i.e., most configs would not have to define a fingerprint, so the = optimization seems worth it to me.

Separately, be aware that calculating an = x509c2n:tls-fingerprint is not a simple copy/paste.  That is, the = command `openssl = x509 -in CERT.pem -noout -sha256 -fingerprint` = is close, but not exactly what is needed.  


/martin


Kent // contributor


= --Apple-Mail=_59EEF00F-EEDA-4E9F-81FC-0B51B1A0F040-- From nobody Fri Nov 8 18:35:52 2019 Return-Path: <0100016e4e047907-659bf6cd-db99-4284-9e0a-8d52a10266e9-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 4AA3212011F for ; Fri, 8 Nov 2019 18:35:50 -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 QognBhRo8yeS for ; Fri, 8 Nov 2019 18:35:48 -0800 (PST) Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06FD11200F6 for ; Fri, 8 Nov 2019 18:35:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1573266946; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=T8LKgfck7QZY+U8A0eFQ4IW0YN1DquhD4xE4YyrH/wc=; b=epLn6mbnJrqeaF8hPReE6GvHiFnoV5BK0IDIpO+PE491Q0RBKAUePaA1++Ls+JTc JpPTWFdfaNsOB7oqVxQiNbrYTz4hYKWotcxa+cxBFdUlbkwnqwLS2MIggymTSWuXJES EO2e4kR2W6suz7H9WWUCWlD/8KPc6xg0rBhDl9/w= From: Kent Watsen Message-ID: <0100016e4e047907-659bf6cd-db99-4284-9e0a-8d52a10266e9-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_1CC348F2-E305-4EFF-9B6D-91C8058A0238" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 9 Nov 2019 02:35:46 +0000 In-Reply-To: <2b0daa52-10e4-566b-6e66-760dbd47c24b@sit.fraunhofer.de> Cc: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= , "netconf@ietf.org" To: Henk Birkholz References: <0100016e3ed10fbb-8a5a44a9-6df6-4ac1-9b56-8dbf61ec64cc-000000@email.amazonses.com> <2b0daa52-10e4-566b-6e66-760dbd47c24b@sit.fraunhofer.de> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.11.09-54.240.8.96 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] FIXMEs in ietf-crypto-types and client/server models 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, 09 Nov 2019 02:35:50 -0000 --Apple-Mail=_1CC348F2-E305-4EFF-9B6D-91C8058A0238 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Henk, > Under the assumption that the trust stores will be used for TLS (maybe = potential other things), I am not sure if the YANG module is an = appropriate place to make some (maybe implicit?) = "mandatory-to-implement" decisions. If there can be (and I think = effectively there should be, but I do not know the appropriate place for = them) prescriptive statements here, I would recommend the following = proposals for the use with TLS: I understand the sentiment expressed, but the details are muddy. I = presume the below are the clarifications, but even they are not clear to = me... ;^) > 1.) With respect to the format of the "raw" pub-key, I propose that = the structure defined in section 3 of RFC 7250 MUST be used. Is this what you have in mind? OLD: typedef raw-public-key { type binary; description "The binary key data for a raw public key. FIXME: specify how it is formatted."; } NEW: typedef raw-public-key { type binary; description "A SubjectPublicKeyInfo structure, as specified in RFC 5280, encoded using ASN.1 distinguished encoding rules (DER), as specified in ITU-T X.690."; reference "RFC 7250: Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. ITU-T X.690: Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)."; } If so, then I think Balazs's idea to use = ks:local-or-keystore-asymmetric-key-grouping is a good one, as it = ultimately becomes a SubjectPublicKeyInfo structure for the public-half, = and a one of a few different kinds of structures for the private half.=20= > 2.) With respect to cipher suite and interoperability, I propose to = make RFC 7151 and RFC 4492 (basically the NIST curve and its format = extensions) mti for raw pub-key and to point to RFC 7250 for guidance & = to make RFC6635 mti for psk. Can you propose the draft-text you have in mind? > 3.) With respect to key identities, I propose that raw pub-key = identities as specified in RFC 6920 and a minimum hash length enabled by = mode sha-256-120 MUST be used & to support and recommend the use of = Identity Hints (section 5.2. in RFC 4279) for PSKs and refer to the = corresponding security considerations (section 7 in RFC 4279). Can you propose the draft-text you have in mind? > My first question - on a technical level: do these proposals in the = context of using TLS sound reasonable to the group? This is hard to answer without the understanding the change to the YANG = module > My second question - on a semantic level: do these normative = requirements belong here? You mean in the YANG module? Where else might they be located? > My third question - on a noob level :) If they belong here, where = would these mandatory requirements be spelled out? In the YANG modules, we strive to define as much normative information = as possible using YANG statements for automation but, when necessary, = resort to "description" statements to define things. But I think you = know this already, so maybe you're asking a different question? > Viele Gr=C3=BC=C3=9Fe, >=20 > Henk PS: all the above regards RPKs, but how should PSK be defined? OLD: typedef psk { type binary; description "The binary key data for a PSK (pairwise-symmetric or pre-shared key). FIXME: specify how it is formmated."; } NEW: ??? Is there any reason to not use a presumed = ks:local-or-keystore-symmetric-key-grouping, that would ultimately = become either an OctetString or a OneSymmetricKey? Kent // contributor --Apple-Mail=_1CC348F2-E305-4EFF-9B6D-91C8058A0238 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Henk,


Under = the assumption that the trust stores will be used for TLS (maybe = potential other things), I am not sure if the YANG module is an = appropriate place to make some (maybe implicit?) = "mandatory-to-implement" decisions. If there can be (and I think = effectively there should be, but I do not know the appropriate place for = them) prescriptive statements here, I would recommend the following = proposals for the use with TLS:

I understand the sentiment expressed, but the = details are muddy.  I presume the below are the clarifications, but = even they are not clear to me...   ;^)


1.) With respect to the format of the "raw" = pub-key, I propose that the structure defined in section 3 of RFC 7250 = MUST be used.

Is this what you have in mind?

OLD:

  typedef raw-public-key {
    type binary;
  =   description
      "The = binary key data for a raw public key.
      =  FIXME: specify how it is formatted.";
  = }

NEW:

  typedef raw-public-key {
    type binary;
  =   description
      "A = SubjectPublicKeyInfo structure, as specified in RFC
  =      5280, encoded using ASN.1 distinguished encoding = rules
       (DER), as specified in = ITU-T X.690.";
    reference
      "RFC 7250:
  =        Using Raw Public Keys in Transport Layer = Security
         (TLS) and = Datagram Transport Layer Security (DTLS).
    =    RFC 5280:
        =  Internet X.509 Public Key Infrastructure Certificate
         and Certificate Revocation = List (CRL) Profile.
       ITU-T = X.690:
         Information = technology - ASN.1 encoding rules:
      =    Specification of Basic Encoding Rules (BER),
         Canonical Encoding Rules = (CER) and Distinguished
        =  Encoding Rules (DER).";
  }

If so, then I think Balazs's idea = to use ks:local-or-keystore-asymmetric-key-grouping is a good one, = as it ultimately becomes a SubjectPublicKeyInfo structure for the = public-half, and a one of a few different kinds of structures for the = private half. 



2.) With respect to cipher suite and = interoperability, I propose to make RFC 7151 and RFC 4492 (basically the = NIST curve and its format extensions) mti for raw pub-key and to point = to RFC 7250 for guidance & to make RFC6635 mti for psk.

Can = you propose the draft-text you have in mind?


3.) With respect to key identities, I propose = that raw pub-key identities as specified in RFC 6920 and a minimum hash = length enabled by mode sha-256-120 MUST be used & to support and = recommend the use of Identity Hints (section 5.2. in RFC 4279) for PSKs = and refer to the corresponding security considerations (section 7 in RFC = 4279).

Can you propose the draft-text you have in = mind?


My first question - on a technical level: do these proposals = in the context of using TLS sound reasonable to the group?

This is = hard to answer without the understanding the change to the YANG = module


My second question - on a semantic level: do = these normative requirements belong here?

You mean = in the YANG module?  Where else might they be = located?


My third = question - on a noob level :) If they belong here, where would these = mandatory requirements be spelled out?

In the = YANG modules, we strive to define as much normative information as = possible using YANG statements for automation but, when necessary, = resort to "description" statements to define things.  But I think = you know this already, so maybe you're asking a different = question?


Viele Gr=C3=BC=C3=9Fe,

Henk

PS: all the above regards RPKs, but how should PSK = be defined?

OLD:

 typedef psk {
  =   type binary;
  =   description
      "The = binary key data for a PSK (pairwise-symmetric or
  =      pre-shared key).  FIXME: specify how it is = formmated.";
  }

NEW:

  = ???

Is there any reason to not use a = presumed ks:local-or-keystore-symmetric-key-grouping, that would = ultimately become either an OctetString or = a OneSymmetricKey?




Kent // contributor


= --Apple-Mail=_1CC348F2-E305-4EFF-9B6D-91C8058A0238-- From nobody Sun Nov 10 19:07:05 2019 Return-Path: <0100016e586dbe79-24514978-922b-479b-a523-3d2bbcdc56c4-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 C844B1200EC for ; Sun, 10 Nov 2019 19:07:01 -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 1WEo9VSXRKNY for ; Sun, 10 Nov 2019 19:06:59 -0800 (PST) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB03F1200C3 for ; Sun, 10 Nov 2019 19:06:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1573441617; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=ZVog5Mx+9XB9DDHOtE+prEK/lL2tJt+WGkeYr1/Pbyw=; b=WDmLJRvyLbmGincawrJCCn60d61RalrVaBNd6gVNJFo1fYZvgsuYeJzlVP1XbBKq /LbKIXLr4h/Smqg3rf1byPp2b5OCP1nwnHS9+CMNbMIUnUUPppB3nrCyqNRgsOLQvRv yFYpQbHrvvrvc/I3AVGRAb/w5ys8/rz/ad+0fHcA= From: Kent Watsen Message-ID: <0100016e586dbe79-24514978-922b-479b-a523-3d2bbcdc56c4-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F06B6630-7688-4BEB-9562-0B82D64FBFB8" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 11 Nov 2019 03:06:57 +0000 In-Reply-To: Cc: "netconf@ietf.org" To: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= References: <0100016e3ed10fbb-8a5a44a9-6df6-4ac1-9b56-8dbf61ec64cc-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.11.11-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] FIXMEs in ietf-crypto-types and client/server models 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, 11 Nov 2019 03:07:02 -0000 --Apple-Mail=_F06B6630-7688-4BEB-9562-0B82D64FBFB8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Balazs, > 1. Key-format (symmetric-key, public-key, asymmetric-key-pair) > I assume the idea here is to make it possible to have choices for the = ASN.1 types holding the keys. If this flexibility for formats is = necessary I don=E2=80=99t have any objection to them but having a single = agreed type for these different use cases would also suffice. > =20 > I believe here you're referring to the 3 instances of lines like: > =20 > leaf key { > nacm:default-deny-all; > type binary; > //must "../key-format"; FIXME: remove comment if approach ok > ... > } > =20 > FWIW, the whole "key-format" leaf is still being sussed out (your = opinion would be helpful on that thread as well) but, so far it seems = promising. The reason these lines are commented out is because 1) the = WG hasn't committed to this path yet and 2) I didn't want to update all = the examples in all the drafts (other than truststore and keystore) to = add a "key-format" leaf until the WG had more consensus on the = "key-format" leafs. > =20 > I don't understand your last comment/sentence. Can you provide an = example? > =20 > Balazs> Ok, then let=E2=80=99s wait for WG decision. Well, I just say = that the earlier ways of communicating the key formats were adequate = from my point of view, which was that in documentation it was said that = for RSA use RSAPrivateKey and for EC use ECPrivateKey, and similarly for = other types. I=E2=80=99m also ok with the key-format approach if = preferred by the WG. > =20 > In earlier versions: > =20 > description > "The value of the binary key. The key's value is > interpreted by the 'algorithm'. For example, a DSA key > is an integer, an RSA key is represented as = RSAPrivateKey > as defined in RFC 8017 = , and an ECC key is represented as > ECPrivateKey as defined in RFC 5915 = ."=20 Yes, the previous way (example above) was adequate, but I believe the = new way (i.e. using a key-format leaf) is better as: 1) it enables the a key-type (e.g., a symmetric key) do be expressed in = different ways as needed (OctetString vs. OneSymmetricKey vs. = EncryptedData) 2) it MAY (haven't tried to model it yet) be able to support encoding = variations (DER vs PEM, and CMS vs. multi-part PEM) 3) it decouples the part that we are stuck on (i.e., the 'algorithm' = node) and it being factored-out may provide more flexibility in that = definition. The WG hasn't discussed key-format yet. Above is the first foray into = it...do these arguments sound compelling? > 2. attributes in asymmetric-key-pair-with-cert(s)-grouping > I think attributes should be kept optional. If there is anything else = besides subject seen mandatory maybe it should be extracted out from = attributes and be spelled out a separate leaf, but I don=E2=80=99t think = there is. > =20 > I believe here you're referring to the 2 instances of lines like: > =20 > leaf attributes { > type binary; // FIXME: does this need to be mandatory? > ... > } > =20 > These are in the "generate-certificate-signing-request" actions found = inside the asymmetric-key-pair-with-cert(s)-grouping. > =20 > Hmmm, are you claiming that "attributes" are not required in order to = generate a CSR? I think the CSR itself MUST have attributes (right?) = so, if not specified, what default values are used? > =20 > Balazs> In RFC2986 the = attributes are said to be optional. We just need the subject DN as = mandatory, don=E2=80=99t we? > =20 > =20 > 1. A CertificationRequestInfo value containing a subject > distinguished name, a subject public key, and optionally a > set of attributes is constructed by an entity requesting > certification. Thank you. I've removed these to comments, thus leaving the = "attrubtute" nodes as NOT mandatory. > 3. PSK and raw public keys > The use case of PSK and raw public keys are not the most urgent in my = opinion which now slows a bit the progress of these drafts, but let=E2=80=99= s make an attempt to finalize them. > =20 > Agreed, but they are legal for TLS and a WG member stated that they = were needed in order to support another IETF WG's efforts. A quick = resolution would be best! > =20 > =20 > raw-public-keys: I see these were added due to RFC 7250 and 8446. I = guess in truststore this is a separate container to distinguish from SSH = host keys. For configuring the private part I think keystore already = gives support for this case with the asymmetric key (w/o cert) and in = the client/server drafts Kent=E2=80=99s proposal could be used (I = replaced raw public key with existing type, shouldn=E2=80=99t that be = useable straight away?) > =20 > container { > choice auth-type { > uses = ks:local-or-keystore-end-entity-cert-with-key-grouping; > uses = ks:local-or-keystore-asymmetric-key-grouping; >=20 >=20 > I would also prefer if these choices are in features, so that an = implementation can choose. > =20 > To your first sentence, yes, "psk" (and "raw-public-key") are = top-level nodes in truststore, as can be seen here = (https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-07#section-2= .1 = ). Note, the trust-anchors draft accidentally doesn't include the = ietf-truststore.yang module. > =20 > The body of your comment above seems to be about supporting the = secret-half of the PSK and RPK within the Keystore. I've raise this = question a couple times previously to Henk (who's asking for the PSK/RPK = add), but he's not responded yet as to if doing so is important (though = I can only imagine that it does). With that said, I think your YANG = snippet is meant to be in ietf-tls-server and ietf-tls-client modules = (right?). I'm having a hard time following the "I replaced raw public = key with existing type, shouldn=E2=80=99t that be useable straight = away?" comment. > =20 > Balazs: You had an example earlier in an email from 10/8/2019, which = is about the TLS client/server models. Below, you are referring to some = possibly new groupings that you wanted to propose. I don=E2=80=99t = understand though why you mentioned these new groupings since = =E2=80=98ks:local-or-keystore-asymmetric-key-grouping=E2=80=99 (RPK) and = something new that just refers to a keystore symmetric key, such as = =E2=80=98ks:local-or-keystore-symmetric-key-grouping=E2=80=99 (PSK) = should be good. This latter I think would be a new grouping, but with = existing terminology. > =20 > All, looking at ietf-tls-client.yang and ietf-tls-server.yang, adding = the ability to configure the "private" half of a PSK or raw public key = would be something like: > =20 > OLD > container { > uses = ks:local-or-keystore-end-entity-cert-with-key-grouping; >=20 > NEW > container { > choice auth-type { > uses = ks:local-or-keystore-end-entity-cert-with-key-grouping; > uses = ks:local-or-keystore-raw-public-key-grouping; > uses = ks:local-or-keystore-pre-shared-key-grouping; > =20 Ah, now I understand, I and agree that this seems like the right way to = do it, but see below... > To your last sentence regarding features, could you provide an example = of what you mean? > =20 > =20 > container { > choice auth-type { > mandatory true; > case certificate { > if-feature x509-certificate-auth; > uses = ks:local-or-keystore-end-entity-cert-with-key-grouping; > } > case raw-public-key { > if-feature raw-public-key-auth; > uses ks:local-or-keystore-asymmetric-key-grouping; > } > case psk { > if-feature psk-auth; > uses ks:local-or-keystore-symmetric-key-grouping; > } Better! This uses the existing groupings (e.g., = ks:local-or-keystore-asymmetric-key-grouping) whereas the above proposal = defined new ones. (see GitHub for latest files, though the commit is = larger than it should be) Henk, what do you think? > I assume these features would then need to be defined in the TLS = client/server draft. Yes. > PS: none of this goes to the FIXME in the ietf-crypto-types. I had = previously asked Henk to provide some text here as well but, apparently, = like all of us at this time, he's been busy! >=20 > psk: given that the asymmetric keys without certs were covered by = host keys and raw public keys, I think psk should only be symmetric = keys. Symmetric keys are then sensitive/secret data and as such I = believe they should only be referenced from keystore. Seeing them in = truststore was unexpected for me. When it comes to their use, clients = and servers should be extended with following configuration (and I = assume we talk of TLS clients and servers only): > =20 > container { > choice auth-type { > uses = ks:local-or-keystore-end-entity-cert-with-key-grouping; > uses = ks:local-or-keystore-asymmetric-key-grouping; > uses = ks:local-or-keystore-symmetric-key-grouping; > =20 > Latter grouping would be a new one, but it would use existing = constructs and terms from keystore. I don=E2=80=99t think we need new = ones. Selected cipher suites will need to have PSK in them for using = symmetric key (similar match needed for the others). Note that symmetric = keys can be used for other cases than TLS PSK, for example SNMPv3 USM. = Again, features would be necessary (those could be saying x.509 or = raw-public-key or psk). > =20 > =20 > Correct, I said the same (that PSKs are essentially symmetric keys) = before as well. Regarding only being referenced to keystore, why not = also support them being local-definitions too? Certainly not a problem = if encrypted and, even when not encrypted, then they can be "protected" = by NACM-like mechanisms, right? > =20 > Balazs> Local definitions are ok too that=E2=80=99s why I used a = hypothetical grouping name ks:local-or-keystore-symmetric-key-grouping. Sorry, I glossed over the "local-" prefix in your earlier statement. I agree that PSKs should be in Keystore when used for = client-identity/server-identity nodes... (more below) > Why was/is seeing them in truststore a surprise, perhaps because = they're not encryptable there? > =20 > Balazs> When PSKs are used then both communicating ends use the shared = key for signing and verifying messages. Then one configuration seems = enough that is either local or from keystore, why would it be necessary = to set it up yet another time for verification from local or truststore? = This would mean there is no need for a PSK option when configuring how = to verify the peer. > =20 > container { > choice auth-type { > mandatory true; > case certificate { > if-feature x509-certificate-auth; > container ca-certs { > uses ts:local-or-truststore-certs-grouping > } > container server-certs { > uses ts:local-or-truststore-certs-grouping > } > } > case raw-public-key { > if-feature raw-public-key-auth; > uses ks: local-or-truststore-raw-pub-keys-grouping > } >=20 > No need for PSK config since it is already configured in = client/server-identity. Ack. (see GitHub for latest files, though the commit is larger than it = should be) And, as a bonus, Keystore already defines support for encryption (unlike = Truststore). > Or what is the reasoning why it is necessary to configure a PSK from = truststore? Somehow I thought that were being used in conceptually different ways, = but I see now that's not really the case... Thank you, Balazs, this message was most helpful! =20 Kent // contributor --Apple-Mail=_F06B6630-7688-4BEB-9562-0B82D64FBFB8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Balazs,


1.       Key-= format (symmetric-key, public-key, asymmetric-key-pair)

I assume the idea here is to make it = possible to have choices for the ASN.1 types holding the keys. If this = flexibility for formats is necessary I don=E2=80=99t have any objection = to them but having a single agreed type for these different use cases = would also suffice.
 
I believe here you're referring to the 3 instances = of lines like:
 
      leaf key {
        nacm:default-deny-all;
        type binary;
        //must = "../key-format";  FIXME: remove comment if approach ok
        ...
 =     }
 
FWIW, the = whole "key-format" leaf is still being sussed out (your opinion would be = helpful on that thread as well) but, so far it seems promising. =  The reason these lines are commented out is because 1) the WG = hasn't committed to this path yet and 2) I didn't want to update all the = examples in all the drafts (other than truststore and keystore) to add a = "key-format" leaf until the WG had more consensus on the "key-format" = leafs.
 
I don't understand your last comment/sentence. =  Can you provide an example?
 
Balazs> Ok, then let=E2=80=99s wait = for WG decision. Well, I just say that the earlier ways of communicating = the key formats were adequate from my point of view, which was that in = documentation it was said that for RSA use RSAPrivateKey and for EC use = ECPrivateKey, and similarly for other types. I=E2=80=99m also ok with = the key-format approach if preferred by the = WG.
 
In = earlier versions:
 
           = description
          &nb= sp;  "The value of the binary key.  The key's value is
          &nb= sp;   interpreted by the 'algorithm'.  For example, a DSA = key
          &nb= sp;   is an integer, an RSA key is represented as = RSAPrivateKey
          &nb= sp;   as defined in RFC 8017, and an ECC key is = represented as
          &nb= sp;   ECPrivateKey as defined in RFC 5915." 

Yes, the previous way (example above) was = adequate, but I believe the new way (i.e. using a key-format leaf) is = better as:

1) it enables the a = key-type (e.g., a symmetric key) do be expressed in different ways as = needed (OctetString vs. OneSymmetricKey = vs. EncryptedData)
2) it MAY (haven't tried to model it = yet) be able to support encoding variations (DER vs PEM, and CMS vs. = multi-part PEM)
3) it decouples the part that we are stuck on = (i.e., the 'algorithm' node) and it being factored-out may provide more = flexibility in that definition.

The = WG hasn't discussed key-format yet.  Above is the first foray into = it...do these arguments sound compelling?




2.       attributes in = asymmetric-key-pair-with-cert(s)-grouping
I think attributes = should be kept optional. If there is anything else besides subject seen = mandatory maybe it should be extracted out from attributes and be = spelled out a separate leaf, but I don=E2=80=99t think there is.
 
I believe here you're referring to the 2 = instances of lines like:
 
      =   leaf attributes {
    =       type binary; // FIXME: does this = need to be mandatory?
          = ...
        }
 
These are in the = "generate-certificate-signing-request" actions found inside = the asymmetric-key-pair-with-cert(s)-grouping.
 
Hmmm, are you claiming that = "attributes" are not required in order to generate a CSR?  I think = the CSR itself MUST have attributes (right?) so, if not specified, what = default values are used?
 
Balazs> In RFC2986 the attributes are said to = be optional. We just need the subject DN as mandatory, don=E2=80=99t = we?
 
 
        1. A =
CertificationRequestInfo value containing a subject
           =
distinguished name, a subject public key, and optionally =
a
           =
set of attributes is constructed by an entity requesting
           =
certification.

Thank you.  I've removed these to comments, = thus leaving the "attrubtute" nodes as NOT mandatory.




3.       PSK and raw = public keys

The use case of PSK = and raw public keys are not the most urgent in my opinion which now = slows a bit the progress of these drafts, but let=E2=80=99s make an = attempt to finalize them.
 
Agreed, but they are legal for TLS and = a WG member stated that they were needed in order to support another = IETF WG's efforts.  A quick resolution would be best!
 
 
raw-public-keys: I = see these were added due to RFC 7250 and 8446. I guess in truststore = this is a separate container to distinguish from SSH host keys. For = configuring the private part I think keystore already gives support for = this case with the asymmetric key (w/o cert) and in the client/server = drafts Kent=E2=80=99s proposal could be used (I replaced raw public key = with existing type, shouldn=E2=80=99t that be useable straight = away?)
 
        &= nbsp;         =   container <client-identity or server-identit= y> {
        &= nbsp;             choice = auth-type {
        &= nbsp;               =  uses ks:local-or-keystore-end-entity-cert-with-key-grouping;        &= nbsp;               =  uses ks:local-or-keystore-asymmetric-key-grouping;


I would also prefer = if these choices are in features, so that an implementation can = choose.
 
To your first sentence, yes, "psk" (and = "raw-public-key") are top-level nodes in truststore, as can be seen here = (https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-07= #section-2.1).   Note, the trust-anchors draft accidentally = doesn't include the ietf-truststore.yang module.
 
The body of your comment above seems to = be about supporting the secret-half of the PSK and RPK within the = Keystore.  I've raise this question a couple times previously to = Henk (who's asking for the PSK/RPK add), but he's not responded yet as = to if doing so is important (though I can only imagine that it does). =   With that said, I think your YANG snippet is meant to be in = ietf-tls-server and ietf-tls-client modules (right?).  I'm having a = hard time following the "I replaced raw public key with existing type, = shouldn=E2=80=99t that be useable straight away?" comment.
 
Balazs: You had an example earlier in an email from = 10/8/2019, which is about the TLS client/server models. Below, you are = referring to some possibly new groupings that you wanted to propose. I = don=E2=80=99t understand though why you mentioned these new groupings = since =E2=80=98ks:local-or-keystore-asymmetric-key-grouping=E2=80=99 = (RPK) and something new that just refers to a keystore symmetric key, = such as =E2=80=98ks:local-or-keystore-symmetric-key-grouping=E2=80=99 = (PSK) should be good. This latter I think would be a new grouping, but = with existing terminology.
 
All, looking = at ietf-tls-client.yang and ietf-tls-server.yang, adding the = ability to configure the "private" half of a PSK or raw public key would = be something like:
 
          &nb= sp;     OLD
          &nb= sp;         container = <client-identity or server-identity> {

          &nb= sp;         =   uses ks:local-or-keystore-end-entity-cert-with-key-groupi= ng;

          &nb= sp;     NEW
          &nb= sp;       =   container <client-identity or server-identit= y> {
          &nb= sp;           choice auth-type {
          &nb= sp;             =  uses ks:local-or-keystore-end-entity-cert-with-key-grouping;        &= nbsp;             =    uses ks:local-or-keystore-raw-public-key-grouping;
        &= nbsp;             =    uses ks:local-or-keystore-pre-shared-key-grouping;
 

Ah, now I understand, I and agree that this seems = like the right way to do it, but see below...


To your last sentence regarding = features, could you provide an example of what you mean?
 
 
container <client-identity or server-identity= > {
    choice auth-type {
        mandatory = true;
        case certificate = {
          &nb= sp; if-feature x509-certificate-auth;
    =        uses ks:local-or-keystore-e= nd-entity-cert-with-key-grouping;
       = }
        case = raw-public-key {
          &nb= sp; if-feature raw-public-key-auth;
    =        uses ks:local-or-keystore-a= symmetric-key-grouping;
       }
        case psk {
          &nb= sp; if-feature psk-auth;
    =        uses ks:local-or-keystore-s= ymmetric-key-grouping;
       }

Better!  This uses the existing groupings = (e.g., ks:local-or-keystore-asymmetric-key-grouping) whereas the = above proposal defined new ones.  (see GitHub for latest files, = though the commit is larger than it should be)

Henk, what do you think?


I assume = these features would then need to be defined in the TLS client/server = draft.

Yes.


PS: none of this = goes to the FIXME in the ietf-crypto-types.  I had previously asked = Henk to provide some text here as well but, apparently, like all of us = at this time, he's been busy!

 psk: given = that the asymmetric keys without certs were covered by host keys and raw = public keys, I think psk should only be symmetric keys. Symmetric keys = are then sensitive/secret data and as such I believe they should only be = referenced from keystore. Seeing them in truststore was unexpected for = me. When it comes to their use, clients and servers should be extended = with following configuration (and I assume we talk of TLS clients and = servers only):
 
        &= nbsp;         =   container <client-identity or server-identit= y> {
        &= nbsp;             choice = auth-type {
        &= nbsp;               =  uses ks:local-or-keystore-end-entity-cert-with-key-grouping;        &= nbsp;               =  uses ks:local-or-keystore-asymmetric-key-grouping;
          &nb= sp;      =       uses ks:local-or-keystore-symmetric-key-grouping;
 
Latter grouping = would be a new one, but it would use existing constructs and terms from = keystore. I don=E2=80=99t think we need new ones. Selected cipher suites = will need to have PSK in them for using symmetric key (similar match = needed for the others). Note that symmetric keys can be used for other = cases than TLS PSK, for example SNMPv3 USM. Again, features would be = necessary (those could be saying x.509 or raw-public-key or psk).
 
 
Correct, I said the = same (that PSKs are essentially symmetric keys) before as well. =  Regarding only being referenced to keystore, why not also support = them being local-definitions too?  Certainly not a problem if = encrypted and, even when not encrypted, then they can be "protected" by = NACM-like mechanisms, right?
 
Balazs> Local definitions are ok too = that=E2=80=99s why I used a hypothetical grouping name  ks:local-or-keystore-symmetric-key-grouping.

Sorry, I glossed over the = "local-" prefix in your earlier statement.

I agree that PSKs should be in Keystore when used = for client-identity/server-identity nodes... (more below)


  = Why was/is seeing them in truststore a surprise, perhaps because they're = not encryptable there?
 
Balazs> When PSKs are used then both communicating ends = use the shared key for signing and verifying messages. Then one = configuration seems enough that is either local or from keystore, why = would it be necessary to set it up yet another time for verification = from local or truststore? This would mean there is no need for a PSK = option when configuring how to  verify the peer.
 
container <client-authentication or server-au= thentication> {
    choice auth-type {
        mandatory = true;
        case certificate = {
          &nb= sp; if-feature x509-certificate-auth;
          &nb= sp; container ca-certs {
    =
            us=
es ts:local-or-truststore-certs-grouping
          &nb= sp; }
          &nb= sp; container server-certs {
    =
            us=
es ts:local-or-truststore-certs-grouping
          &nb= sp; }
       }
        case = raw-public-key {
          &nb= sp; if-feature raw-public-key-auth;
    =             us= es ks: local-or-truststore-raw-pub-keys-grouping
       }

No need for PSK config since it is already configured in = client/server-identity.

Ack.   (see GitHub for latest files, though = the commit is larger than it should be)

And, as a bonus, Keystore already defines support = for encryption (unlike Truststore).


 Or what is the reasoning why it is = necessary to configure a PSK from = truststore?

Somehow I thought that were being used in = conceptually different ways, but I see now that's not really the = case...


Thank you, Balazs, this message was most helpful! =   

Kent // = contributor


= --Apple-Mail=_F06B6630-7688-4BEB-9562-0B82D64FBFB8-- From nobody Mon Nov 11 02:00:50 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722F412083E for ; Mon, 11 Nov 2019 02:00:49 -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 MPn3RHUJ4AfD for ; Mon, 11 Nov 2019 02:00:46 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 03F7F120059 for ; Mon, 11 Nov 2019 02:00:45 -0800 (PST) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 51C7F1AE018B; Mon, 11 Nov 2019 11:00:43 +0100 (CET) Date: Mon, 11 Nov 2019 11:00:13 +0100 (CET) Message-Id: <20191111.110013.2019956803552089416.mbj@tail-f.com> To: kent+ietf@watsen.net Cc: netconf@ietf.org From: Martin Bjorklund In-Reply-To: <0100016e4d8323b0-2a182947-485d-43e6-908c-13bc5ad2f210-000000@email.amazonses.com> References: <0100016e39631e46-c007fd65-2e51-47a6-bd27-764f5257a16c-000000@email.amazonses.com> <20191106.142822.2117534105126283386.mbj@tail-f.com> <0100016e4d8323b0-2a182947-485d-43e6-908c-13bc5ad2f210-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] client identification in ietf-netconf-server 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, 11 Nov 2019 10:00:50 -0000 Hi, Kent Watsen wrote: > > Hi Martin, > > [Not trimming down because too much context would be lost.] > > > >>> The ietf-netconf-server module has this: > >>> > >>> grouping netconf-server-grouping { > >>> ... > >>> container client-identification { > >>> ... > >>> container cert-maps { > >>> when "../../../../tls"; > >>> uses x509c2n:cert-to-name; > >>> ... > >>> } > >>> } > >>> } > >>> > >>> Note the "when" expression. This means that the grouping has a strong > >>> depency on where is it used. We should try to avoid such a design. > >> > >> > >> Would this be better? > >> > >> OLD > >> when "../../../../tls"; > >> > >> NEW > >> if-feature "tls-listen or tls-call-home"; > > > > Yes, but see below. > > > > > >>> But should't this cert-to-name list be available when x509-certs are > >>> used also with SSH? > >> > >> Hmmm. I'd assumed that, with RFC 6187, the username was still passed > >> as its own field, but I see this in Section 4: > >> > >> For the purposes of user authentication, the mapping between > >> certificates and user names is left as an implementation and > >> configuration issue for implementers and system administrators. > > > > If the username was used as identification it would mean that with a > > valid cert I could present myself as any user! > > > >> So you may be right about that. I only ever looked at RFC 6187 from > >> the perspective of the server presenting an IDevID certificate. But, > >> assuming it's true, then perhaps this: > >> > >> NEWEST: > >> if-feature "tls-listen or tls-call-home or sshcmn:ssh-x509-certs"; > > > > Ok. > > > > This gives: > > > > grouping netconf-server-grouping { > > description ...; > > container client-identification { > > description > > "Specifies a mapping through which clients MAY be identified > > (i.e., the NETCONF username) from a supplied certificate. > > Note that a client MAY alternatively be identified via an > > alternate authentication scheme."; > > container cert-maps { > > if-feature "tls-listen or tls-call-home or sshcmn:ssh-x509-certs"; > > Yes. > > > But since the description of the "client-identification" says that it > > is used only with certificates, perhaps that container's name should > > reflect this, and the if-feature statement moved to that container? > > Perhaps: > > > > container client-cert-identification > > if-feature "tls-listen or tls-call-home or sshcmn:ssh-x509-certs"; > > > > and also perhaps remove 'cert-maps', and use the cert-to-name grouping > > directly here? > > Good. My only hesitation is that someday there may be a need for > another way to identify clients, but that sounds too far out (even for > me) to squabble over. But a better name is needed. > "cert-based-client-identification" would be more accurate, but that > seems overly long. Looking at a snippet of config might help... > > netconf-server-parameters : { > something-here : [ > { > cert-to-name : { ... } > cert-to-name : { ... }, > ... > cert-to-name : { ... } > } > ] > } > > How about "cert-to-name-mappings"? ( know, almost the same length, > but half the number of syllables!). But that name leaves out the word > "identity", which is may be important in security circles, so maybe > "client-identity-mappings"? I think this name is as generic as "client-identification". The best so far imo is "cert-based-client-identification". A bit long, but descripitive. > This seems pretty good, right? (I > renamed it to "client-identity-mappings" in both ietf-netconf-server > and ietf-restconf-server) > > > >>> The current data model for ssh specifies certs on > >>> a per-user basis. But this requires lots of configuration in the case > >>> that the cert encodes the user name (even though the name is in the > >>> cert you have to configure each user on each device). I suggest we > >>> align the model for SSH with the TLS model for cert identification. > >> > >> We certainly want to factor out configuration where possible. I'd > >> need to look into this more. Perhaps you can send a diff? > > > > Today we have under 'ssh-server-parameters/client-authentication': > > > > +--:(local) {local-client-auth-supported}? > > +--rw users > > +--rw user* [name] > > +--rw name string > > +--rw password? ianach:crypt-hash > > +--rw host-keys! > > | +--rw (local-or-truststore) > > | +--:(local) {local-definitions-supported}? > > | | +--rw local-definition > > | | +--rw host-key* ct:ssh-host-key > > | | +--rw cert* trust-anchor-cert-cms > > | | +---n certificate-expiration > > | | +-- expiration-date yang:date-and-time > > Not to take away from your point, but the previous three lines don't > exist in the model. > > > | +--:(truststore) {truststore-supported,ssh-host-keys}? > > | +--rw truststore-reference? ts:host-keys-ref > > +--rw ca-certs! {sshcmn:ssh-x509-certs}? > > | +--rw (local-or-truststore) > > | +--:(local) {local-definitions-supported}? > > | | +--rw local-definition > > | | +--rw cert* trust-anchor-cert-cms > > | | +---n certificate-expiration > > | | +-- expiration-date yang:date-and-time > > | +--:(truststore) {truststore-supported,x509-certificates}? > > | +--rw truststore-reference? ts:certificates-ref > > +--rw client-certs! {sshcmn:ssh-x509-certs}? > > +--rw (local-or-truststore) > > +--:(local) {local-definitions-supported}? > > | +--rw local-definition > > | +--rw cert* trust-anchor-cert-cms > > | +---n certificate-expiration > > | +-- expiration-date yang:date-and-time > > +--:(truststore) {truststore-supported,x509-certificates}? > > +--rw truststore-reference? ts:certificates-ref > > > > I think host-keys, ca-certs and client-certs should be moved out of > > the user list: > > > > +--:(local) {local-client-auth-supported}? > > +--rw users > > | +--rw user* [name] > > | +--rw name string > > | +--rw password? ianach:crypt-hash > > +--rw host-keys! > > | +--rw (local-or-truststore) > > | +--:(local) {local-definitions-supported}? > > | | +--rw local-definition > > | | +--rw host-key* ct:ssh-host-key > > | | +--rw cert* trust-anchor-cert-cms > > | | +---n certificate-expiration > > | | +-- expiration-date yang:date-and-time > > Again, not to take away from your point, but the previous three lines > don't exist in the model. > > > | +--:(truststore) {truststore-supported,ssh-host-keys}? > > | +--rw truststore-reference? ts:host-keys-ref > > +--rw ca-certs! {sshcmn:ssh-x509-certs}? > > | +--rw (local-or-truststore) > > | +--:(local) {local-definitions-supported}? > > | | +--rw local-definition > > | | +--rw cert* trust-anchor-cert-cms > > | | +---n certificate-expiration > > | | +-- expiration-date yang:date-and-time > > | +--:(truststore) {truststore-supported,x509-certificates}? > > | +--rw truststore-reference? ts:certificates-ref > > +--rw client-certs! {sshcmn:ssh-x509-certs}? > > +--rw (local-or-truststore) > > +--:(local) {local-definitions-supported}? > > | +--rw local-definition > > | +--rw cert* trust-anchor-cert-cms > > | +---n certificate-expiration > > | +-- expiration-date yang:date-and-time > > +--:(truststore) {truststore-supported,x509-certificates}? > > +--rw truststore-reference? ts:certificates-ref > > I agree that "ca-certs" and "client-certs" should be pulled out (as > they are in ietf-tls-server), but I'm unsure if "host-keys" can be, at > least not unless we introduce something like "host-key-to-name" maps, > right? > > For now, I only pulled out "ca-certs" and "client-certs". Hmm, I realize that I have misunderstood 'host-keys' here. How exactly is this supposed to be used? This is the client authentication part of a server. How is the *host* key used here by the server? I mean, the client doesn't present a host key to the server, so I don't understand what this is. > > But also here I think that the choice "local-or-external" isn't > > ideal. I think that a system that implements some "external" > > mechanism should/would augement this data model with specific nodes > > for that mechanism. As a simplistic example: > > > > augment /netconf-server/.../client-authentication { > > leaf use-host-keys-in-filesystem { > > leaf boolean; > > } > > } > > > > In this case, requiring the client to configure both this new leaf and > > "client-auth-defined-elsewhere" seems redundant and non-intuitive. > > Agreed. > > > Another case is a system that *always* use the filesystem host keys. > > It would simply just always do that, and again, requiring the client > > to configure "client-auth-defined-elsewhere" seems incorrect. > > Agreed. > > > So my suggestion is to remove the choice "local-or-external" and > > remove the external case, and instead document that (i) systems may > > use some other hard-wired mechanism or (ii) other modules can augment > > this container with additional control parameters for other > > mechanisms. > > Agree in principle, but unsure about implementation. One thing > important to me you didn't mention is having the "local" configuration > gated by a "feature" statement. So, do we float the > "local-client-auth-supported" (renamed appropriately) up to the > "client-authentication" container? If so, would that incorrectly > cover the "supported-authentication-methods" descendent? > Suggestions? Perhaps just add the if-feature to the containers "users", "ca-certs", "client-certs"? > >>> For TLS, the data model has the following structure: > >>> > >>> +--rw netconf-server > >>> +--rw listen! {ssh-listen or tls-listen}? > >>> +--rw idle-timeout? uint16 > >>> +--rw endpoint* [name] > >>> +--rw name string > >>> +--rw (transport) > >>> ... > >>> +--:(tls) {tls-listen}? > >>> > >>> [ reset indentation to make the diagram easier to read ] > >>> > >>> +--rw tls > >>> +--rw tcp-server-parameters > >>> ... > >>> +--rw tls-server-parameters > >>> | +--rw server-identity > >>> ... > >>> | +--rw client-authentication! > >>> | | +--rw (required-or-optional) > >>> | | | +--:(required) > >>> | | | | +--rw required? empty > >>> | | | +--:(optional) > >>> | | | +--rw optional? empty > >>> | | +--rw (local-or-external) > >>> | | +--:(local) {local-client-auth-supported}? > >>> | | | +--rw ca-certs! {ts:x509-certificates}? > >>> | | | | +--rw (local-or-truststore) > >>> | | | | +--:(local) {local-definitions-supported}? > >>> | | | | | +--rw local-definition > >>> | | | | | +--rw cert* trust-anchor-cert-cms > >>> | | | | | +---n certificate-expiration > >>> | | | | | +-- expiration-date > >>> | | | | | yang:date-and-time > >>> | | | | +--:(truststore) > >>> | | | | {truststore-supported,x509-certificates}? > >>> | | | | +--rw truststore-reference? > >>> | | | | ts:certificates-ref > >>> | | | +--rw client-certs! {ts:x509-certificates}? > >>> | | | +--rw (local-or-truststore) > >>> | | | +--:(local) {local-definitions-supported}? > >>> | | | | +--rw local-definition > >>> | | | | +--rw cert* trust-anchor-cert-cms > >>> | | | | +---n certificate-expiration > >>> | | | | +-- expiration-date > >>> | | | | yang:date-and-time > >>> | | | +--:(truststore) > >>> | | | {truststore-supported,x509-certificates}? > >>> | | | +--rw truststore-reference? > >>> | | | ts:certificates-ref > >>> | | +--:(external) > >>> | | {external-client-auth-supported}? > >>> | | +--rw client-auth-defined-elsewhere? > >>> | | empty > >>> ... > >>> +--rw netconf-server-parameters > >>> +--rw client-identification > >>> +--rw cert-maps > >>> +--rw cert-to-name* [id] > >>> +--rw id uint32 > >>> +--rw fingerprint > >>> | x509c2n:tls-fingerprint > >>> +--rw map-type identityref > >>> +--rw name string > >> > >> > >> > >> > >>> It is not clear how this is used by the server to end up either with > >>> an authenticated user name or failed authentication. > >> > >> Okay, let's fix that. > >> > >> > >>> First of all, how is the "required-or-optional" choice used in a > >>> NETCONF server? What happens if an operation configures this to > >>> "optional"? (side note: why is this a choice of empty leafs instead > >>> of a leaf?) > >> > >> Hmmm, this 'choice' seems unneeded for NETCONF. The "choice" is > >> coming from the ietf-tls-server, and a similar "choice" is in > >> ietf-http-server. It was put there, in part, for RESTCONF, as > >> user-auth can occur at either (or both!) protocol layers... > > > > Ok. Yes, the RESTCONF auth mechanism is interesting. Let's discuss > > that in a separate thread. > > Okay. For now, I'll leave the "required-or-optional" in both > ietf-tls-server and ietf-http-server. However, to address the issue > that it can never apply to NETCONF, it seems that a possible strategy > would be to move both instances to augmentations defined in > ietf-restconf-server... > > That said, to go along with some of your thinking from above, it's not > clear how an application would consume the "required-or-optional" > configuration. Case in point, in the RESTCONF server based product > I'm working on, the configuration for each client, which is defined > outside the restconf-server-grouping tree, has descendants nodes like > "http-password" and "tls-trust-anchor", with meanings that, if > defined, then the client MUST present said auth credentials at that > protocol-layer. IIRC, the code doesn't check these flags at all. > > So, rather than moving both "required-or-optional" instances to > augmentations in ietf-restconf-server, maybe they can just be deleted? Yes I think so, altough I haven't yet studied the restconf model in detail. > >>> Second, I assume that the idea is that the server uses the config > >>> params in "local-or-external" and the certificate presented by the > >>> client and after this step is either accepted or rejected. It is not > >>> clear what is supposed to happen if someone configures > >>> "client-auth-defined-elsewhere". I think it is better to not define > >>> this case, but (perhaps) keep the choice and explain that other > >>> modules can augment additional config params here for other > >>> authentication mechanisms. > >> > >> Well that's just the thing, the goal is to enable user-auth to NOT be > >> defined here. As the description statement in ietf-tls-server says: > >> > >> "Configuring credentials externally enables applications > >> to place client authentication with client definitions, > >> rather then in a part of a data model principally > >> concerned with configuring the TLS transport."; > > > > I totally agree with this. I am questioning the solution. See above > > for my proposal. > > Ack. > > > >>> Next, my guess is that the intention is that if the cert was accepted > >>> in the step above, it is checked in cert-to-name to see if a user name > >>> can be derived. > >> > >> Yes. > >> > >> > >>> In another thread you mentioned that if a local cert is configured, it > >>> seems redundant to also configure the cert as a fingerprint in > >>> cert-to-name. I'm not sure about this. But perhaps you can use the > >>> same "map-type" and "name" leafs in the "client-cert" container? It > >>> is not as easy for the "truststore-reference"; perhaps you'd have to > >>> augment the truststore with these leafs in this case. > >> > >> In context, that statement I made before is a relatively minor > >> objection. That said, I don't understand your proposal, are you > >> suggesting to recreate the essence of 'cert-to-name'? Another idea I > >> had was that the fingerprint could be in a "union" with also a > >> truststore-reference, which is only mildly better... > > > > Aha, now I understand your suggestion of making fingerprint optional. > > I agree that this could work. However, I assume it must be used with > > care. If you know for sure that a successful result from the > > authentication mechanism means that CA cert X has been used, you can > > save some typing by not configuring the fingerprint of X. So the > > question is if it is worth it? > > Yes, saving typing is the gist of it, but I don't think handling with > care is needed or, rather, it's no more care. As I understand it, a > fingerprint would be redundant in the common case, i.e., most configs > would not have to define a fingerprint, so the optimization seems > worth it to me. It would be interesting to hear other opinions on this, esp. from security people. Personally I can accept both alternatives. > Separately, be aware that calculating an x509c2n:tls-fingerprint is > not a simple copy/paste. That is, the command `openssl x509 -in > CERT.pem -noout -sha256 -fingerprint` is close, but not exactly what > is needed. Right; you have to prefix this fingerprint with "04:". /martin From nobody Mon Nov 11 06:22:44 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2049D120289; Mon, 11 Nov 2019 06:22:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=j8mdUdRz; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=FPfdZ2fY Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uh7VFpXXAKbU; Mon, 11 Nov 2019 06:22:39 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 662F512009C; Mon, 11 Nov 2019 06:22:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10058; q=dns/txt; s=iport; t=1573482159; x=1574691759; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dX4Yiz6Qj90bp3LyLbEfbyU+f0q9VCfiPO4pvHn3xfY=; b=j8mdUdRz00h5nhuGphidE5ON5+mk4HXT56aVsvD5QxZsJYNC/9HidEaY jbl2kYHIWBRYtj/CvpU0IU5gASQw5R5exBo4xpThJ9zaSxdi/inuwZMH9 0G+LbvPXlJJqxlc3UWf6Z2zsu8L1SXQzbibn/S41Cjab1o85Rq3QYH1ud Q=; IronPort-PHdr: =?us-ascii?q?9a23=3Aoaf+7hGIG47WbzrjSWXxRJ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1A3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+eeT1bigmG8JqX15+9Hb9Ok9QS47z?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CyAAB4bcld/51dJa1lGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYF+gRwvKScFbFggBAsqCodlA4pqgl6THoRiglI?= =?us-ascii?q?DVAkBAQEMAQElCAIBAYRAAoQUJDgTAgMLAQEEAQEBAgEFBG2FNwyFUQEBAQE?= =?us-ascii?q?DEgsQEwEBKQ4BDwIBCBABBAEBKAcyFAkIAgQBDQUIEweDAYF5TQMuAQIMoV4?= =?us-ascii?q?CgTiIYIIngn4BAQWBNAEDBINNGIIXAwaBNowUGIFAP4FXgkw+gmICAQKBSBg?= =?us-ascii?q?MHwmDDIIslU8kmCEKgiWHF45ImXmCDIQMiC+INpFAAgQCBAUCDgEBBYFpIoF?= =?us-ascii?q?YcBU7gjgBM1ARFJA2DBeBBAEIgkOFFIU/dAGBJ4xaAYEOAQE?= X-IronPort-AV: E=Sophos;i="5.68,293,1569283200"; d="scan'208,217";a="377649165" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Nov 2019 14:22:38 +0000 Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id xABEMbPG015517 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Nov 2019 14:22:37 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 11 Nov 2019 08:22:37 -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; Mon, 11 Nov 2019 09:22:36 -0500 Received: from NAM05-DM3-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; Mon, 11 Nov 2019 09:22:36 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AoqGVkJHnBFyDR+iMjYFre/W5ShPUCxjX2vPEOGmicGzp5n16qDicP4tT1NTPIIBP22bs9Y78vy6lYUf4KohpW3mnKKsDTRo4JS64HzTxly1Tu/vxNBGodS8xE2qMhCE8rvoz4pRGehPKHCLorPtCsOfkyK9NFVad+w7YVs4Ql31wHTGe9hvWHqACW+9cUSa9iZaJ+AGaES4ZaNHuhGUAuNcSq2P9CGj4543O1JxhMu0f6VWheIOQvTN9esipLlpH33bzoA4FLEl6h6NVR+/ksv5JgNjZsK8h2b13t7Bk+aJq8FSKv0KWFUF92tF6pE41lC7VdyDAU8oTh17g+5QQg== 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=fApCWX5h1Iml5+YIZaJdUxq5xS/1EB9q6v9tPELbimw=; b=gdlobzwJk0NsZpkDnfI5Hw9raaHnkW78N/jIKtCCtYIMJx2jxe+v15B/gffcg8rubs0fZxBIeNQ/STGLTwfZNRpteykuZDx1idJaumgPLVW36/j9FmMI78mHZPbc6yH7Bb1/6OfcLXpFq2fBwcnQDlR06nftO8n/p0H2iKIAjfLJbv0vmNrwdVsLIoaQPelNLN+RhuVuup5s7qLgJuU/UipujAmvPgBj7ayNXkFuweennipRhLMeR5DxkfdkG4twBL/hA0JiJ4NZfmrZSHXO+QDMqlagtfmZZbbZM1d5tEGLlv8CM4tH8bmx44yiZTN3TUKYJwBRbKdsn4nYqp8pAw== 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=fApCWX5h1Iml5+YIZaJdUxq5xS/1EB9q6v9tPELbimw=; b=FPfdZ2fYj+GKgC2jUowhlRZe2OsBhMjl566s98U1+Xu5KpxWzQtD2u+Ijmv69E8hZdEz/xNXCw+6+r5LfRHWLt+4HHfzrX8qjNFqtjD/Lc1EGzF46EwyveByM0B5ToE/z9VKZIS4ZoYYdzPMakYLFNu/xFZ9vC7Re7/04m8O4fQ= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB4335.namprd11.prod.outlook.com (52.135.38.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.25; Mon, 11 Nov 2019 14:22:35 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::49b6:bc5c:bd3e:203c]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::49b6:bc5c:bd3e:203c%5]) with mapi id 15.20.2430.027; Mon, 11 Nov 2019 14:22:35 +0000 From: "Rob Wilton (rwilton)" To: Kent Watsen , Juergen Schoenwaelder CC: "httpbis-chairs@ietf.org" , "netconf@ietf.org" Thread-Topic: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04 Thread-Index: AQHViGJKiGFhsDrRSkSDDSpVvqe78Kd6xJGAgAQocICAAH7EAIAAfoCAgAAGb4CAAB7jAIAGFkxw Date: Mon, 11 Nov 2019 14:22:35 +0000 Message-ID: References: <704A1489-3BC0-4EFF-A5B0-7D664EA05970@gmail.com> <20191104.093427.842126049822749848.mbj@tail-f.com> <0100016e432d004b-32e62ef2-4e6c-48f6-8fa4-092c55778ea8-000000@email.amazonses.com> <20191107073755.kw6xqp5uqruiask6@anna.jacobs.jacobs-university.de> <0100016e466ae626-e9821117-8286-4f26-bc91-284d7dcaa453-000000@email.amazonses.com> <20191107153342.gqtgyseqyvsppcul@anna.jacobs.jacobs-university.de> <0100016e46e53383-ec073c86-f9d4-4358-9d78-b337f9cd9a58-000000@email.amazonses.com> In-Reply-To: <0100016e46e53383-ec073c86-f9d4-4358-9d78-b337f9cd9a58-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=rwilton@cisco.com; x-originating-ip: [173.38.220.60] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5eea4993-384e-4811-d25a-08d766b298ef x-ms-traffictypediagnostic: MN2PR11MB4335: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0218A015FA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39860400002)(136003)(346002)(366004)(376002)(199004)(189003)(9326002)(66066001)(81166006)(8676002)(110136005)(81156014)(476003)(8936002)(71190400001)(99286004)(71200400001)(486006)(14444005)(256004)(446003)(11346002)(102836004)(7736002)(2906002)(21615005)(54906003)(26005)(316002)(76176011)(186003)(74316002)(7696005)(86362001)(53546011)(6506007)(33656002)(790700001)(14454004)(6436002)(52536014)(966005)(478600001)(5660300002)(606006)(6116002)(3846002)(9686003)(54896002)(6306002)(66446008)(64756008)(66476007)(66946007)(66556008)(236005)(55016002)(76116006)(4326008)(25786009)(229853002)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4335; 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: lq2Oak5DbfawLwnbIWzrKEq8H0B0F5lIKFzGkaB4Dnp9EwuCfRM5nZL8oWPebgS8cLlD9HSpVEk3WLMFJvyRE57QXxu6xUT/gCoYy2UQtrVSNTjRZnLDXFb6yuk0kV0fJmNXtFBjmjGhzQ5AWZ9t6hS/Xo2362dO2C5Si+FbokEhyNAjTNaSg9nPCrh/f0coGbNttf1lwOcrJTnqSoKbjuwxFtgw0ZNcvpIv2N2/JEvEtxh0SHtyDW2JHWPlOkbpcA+yCUPaMh8i0Z3sbnHcMCYwbSHlviv6GScJyMsFZHRjUB1ZnSzBALwOzgn+9bTrapHgB3IVx3wsrj4N6DAfhexbaKgXrfX6O/Jl1Tv/6J1tchsfphIUnjHPh8EImftyoLETuPVKuV47uVG9yBQhpdmjqlnn7qHDKbeZjBnBLm1wZehw7TghFqLp8M3t1W6TrB91kuPOzzuNeRpgKoqRKQ+BoJ1Nr2AF8Q+zXnHfy5o= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB43665D4C44574150432EA1BDB5740MN2PR11MB4366namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 5eea4993-384e-4811-d25a-08d766b298ef X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2019 14:22:35.1600 (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: fxUXeykpWLfjG9PPLCSUos+Tm+rNGGA+OyW6KST8g5My3e1CJ8GW25OEE0/scCJesTzt5AxMKZwwC0xy1BWD+g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4335 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.30, xch-rcd-020.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04 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, 11 Nov 2019 14:22:42 -0000 --_000_MN2PR11MB43665D4C44574150432EA1BDB5740MN2PR11MB4366namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kent, According to https://datatracker.ietf.org/wg/httpbis/charter/, it looks lik= e the list address is: ietf-http-wg@w3.org Thanks, Rob From: netconf On Behalf Of Kent Watsen Sent: 07 November 2019 17:24 To: Juergen Schoenwaelder Cc: httpbis-chairs@ietf.org; netconf@ietf.org Subject: Re: [netconf] Adoption call for draft-kwatsen-netconf-http-client-= server-04 Noteworthily, the HTTP experts additionally said that they would have no is= sue if the module were called something else (ietf-restful-http-client/serv= er?) as then it wouldn't appear to intending to be an all-encompassing HTTP= definition and it would no longer require involvement of the HTTP experts = to ensure correctness. Changing the module name to ietf-restful-http-client/server makes any reuse of the definitions look back. Can you clarify what you mean by "look back"? The name just looks odd: Do I want to import something that is labeled as a restconf specific grouping? The HTTP people do not want us to define something that may look generic but do we want to define something that looks like a solution just for restconf? Well, perhaps we should just put the -restconf- thing in the name and future will tell us whether people reuse this or attempt to roll their own. I see, but note that I wrote "restfull" (not "restconf"), which is importan= t since the "https-notif" draft is NOT using RESTCONF (just HTTP). That said, I don't see why we shouldn't proceed with "http", as that is wha= t the protocol layer is called. At one point the HTTP chairs said that, i= f we wanted to use "http", then we should involve the httpbis WG, which mak= es sense, but shouldn't (in my mind) block an adoption. I suggest that we= take the draft to the httpbis list and (maybe) present it in the httpbis s= ession. A couple days ago I looked for the httpbis list, but couldn't find it. The= ir agenda [1] looks packed, so probably too late for a new request, but if = the HTTP chairs are reading this and think we could squeeze in a quick pres= o, that would be great, otherwise, pointers to the httpbis list would be ap= preciated. [1] https://datatracker.ietf.org/meeting/106/materials/agenda-106-httpbis-0= 1.html Kent --_000_MN2PR11MB43665D4C44574150432EA1BDB5740MN2PR11MB4366namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kent,<= o:p>

&nbs= p;

According= to https://datatr= acker.ietf.org/wg/httpbis/charter/, it looks like the list address is: ietf-http-wg@w3.org

 =

Thanks,

Rob

&nbs= p;

&nbs= p;

From: netconf <netconf-bounces@ietf.org> On Behalf Of Kent Watsen
Sent: 07 November 2019 17:24
To: Juergen Schoenwaelder <J.Schoenwaelder@jacobs-university.de&g= t;
Cc: httpbis-chairs@ietf.org; netconf@ietf.org
Subject: Re: [netconf] Adoption call for draft-kwatsen-netconf-http-= client-server-04

 

 

Noteworthily, the HTT= P experts additionally said that they would have no issue if the module wer= e called something else (ietf-restful-http-client/server?) as then it would= n't appear to intending to be an all-encompassing HTTP definition and it would no longer require involvement of the HTTP exp= erts to ensure correctness.


Changing the module name to ietf-restful-http-client/server makes any
reuse of the definitions look back.


Can you clarify what you mean by "look back"?


The name just looks odd: Do I want to import something that is labeled
as a restconf specific grouping? The HTTP people do not want us to
define something that may look generic but do we want to define
something that looks like a solution just for restconf? Well, perhaps
we should just put the -restconf- thing in the name and future will
tell us whether people reuse this or attempt to roll their own.<= /p>

 

I see, but note that I wrote "restfull" (n= ot "restconf"), which is important since the "https-notif&qu= ot; draft is NOT using RESTCONF (just HTTP).

 

That said, I don't see why we shouldn't proceed with= "http", as that is what the protocol layer is called.   At = one point the HTTP chairs said that, if we wanted to use "http", = then we should involve the httpbis WG, which makes sense, but shouldn't (in my mind) block an adoption.   I suggest that we take th= e draft to the httpbis list and (maybe) present it in the ht= tpbis session.  

 

A couple days ago I looked for the httpbis list, but= couldn't find it.  Their agenda [1] looks packed, so probably too lat= e for a new request, but if the HTTP chairs are reading this and think we c= ould squeeze in a quick preso, that would be great, otherwise, pointers to the httpbis list would be appreciated.

 

 

Kent

 

--_000_MN2PR11MB43665D4C44574150432EA1BDB5740MN2PR11MB4366namp_-- From nobody Mon Nov 11 06:26:25 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A9F12009C; Mon, 11 Nov 2019 06:26:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=XXeTteZM; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=fK/UVu4h Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hlkek8AjA2Sr; Mon, 11 Nov 2019 06:26:21 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F198512007C; Mon, 11 Nov 2019 06:26:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10980; q=dns/txt; s=iport; t=1573482381; x=1574691981; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Bbm5ADH+ehPeFb/mMUhjDyJ42xrCxsndb6mnfYjUsx0=; b=XXeTteZMCmKh09XwYkfZSMSjjYzGcsH8Pe5mHoEdfesG1+780HT3gZyE YPbgGrZul5dCyJMyRKKV6wqkHMK0dWUm/m1SqauLrIDNyRp0m3sZceQ6t +jjnWx99GsFnM5oNZkVeRLqKV7jnY4UWJr/4zmIDXWTWycR3imRwqJowJ E=; IronPort-PHdr: =?us-ascii?q?9a23=3AHirMlxzpeywJhCjXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhSN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZufFkz/MPnsRyc7B89FElRi+iLzPA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DfAQDZbsld/51dJa1lGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBfoEcLyknBWxYIAQLKgqHZQOKa4Jekx6EYoJSA1QJAQE?= =?us-ascii?q?BDAEBLQIBAYRAAoQUJDgTAgMLAQEEAQEBAgEFBG2FNwyFUQEBAQEDEgsQEwE?= =?us-ascii?q?BNwEPAgEIEQQBAS8yHQgCBAENBQgagwGBeU0DLgECoWgCgTiIYIIngn4BAQW?= =?us-ascii?q?FDBiCFwmBNopRgUMYgUA/gVeCTD6ELxiDQIIslU8kmCEKgiWVX5l5ggyEDIg?= =?us-ascii?q?vmXYCBAIEBQIOAQEFgWkigVhwFYMnUBEUkDaBJwEJgkKKU3SBKIxaAYEOAQE?= X-IronPort-AV: E=Sophos;i="5.68,293,1569283200"; d="scan'208,217";a="370352132" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Nov 2019 14:26:19 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id xABEQJGD020368 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Nov 2019 14:26:19 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; Mon, 11 Nov 2019 08:26:18 -0600 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 11 Nov 2019 08:26:18 -0600 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 11 Nov 2019 08:26:18 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=euYCsDcRNb67GRzwIA9pPVbdd7jK5wP2ZjvBvVU/I7nktBIrr0bRCkMYcthZcaxLYhBJqfExk5D5TBfHXTjn5ju4ycfqhKEzngUP3jwXimrghxAshXNn1a9ttyIg9TNDTklB+abM9A4ZdQmQTT8VTRXbY4l0GlcCX7I2XqnOmvOC3hdxRNsy087Gp4SxtJB/FV5Hy3TWPeKqFA+axAayMurPmbcJb1+D7Yc8I0tu7h+W3RmzwlEWDn5K8jQLsEUHFQU5gxyZAdP/G4PlRupUC4PJGEzdkT53ras17MeVPm4DYmeUh4LwN4Tb/MioHNSTIrEdHmaT3PWq45oFfVw1jg== 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=FfsjOayPz0Q8iPQCZqRAQS+S5ZUzU4i63cLijlWGhbY=; b=T9A+Qx599P747WomSEehrbYJT2CHfeIUHX2B93EotbQdk5S2PZjAlScgoVpV1zn8li7ms2GdLQj5SkXwOT5qiLzjp6/D76si9d/zlrLzA7sqYQomIqTHuvUoZQDKk7A5nRWxNL+cLPu1mHVlhAJp3Xo18NBFVaDMxM6l9gidox4pxthNtfkoLsAWRxJhV6n+V8Np9gnEPtXaMhi5bfiB1ker6lAv2OXyF3bajEkdjdLSgvUEO8/6nt2zsPWSwpSjf9bl6iGa9RD3/G9Djd3v0e6KR8gOBcE/rWakX9nofIX5REuD501XdGHfHRN6HkZ8Cx3tCIB80WF2alCUW80rfA== 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=FfsjOayPz0Q8iPQCZqRAQS+S5ZUzU4i63cLijlWGhbY=; b=fK/UVu4h9oTRbiMNSjDYQmp4cIKoQJIh4WiWFRUCRkIvuv05pl4tjT2aTcf0ZI1IWbcIYcaM4kNGMv1R2EH9waNOIhjcKC2Ij+EE+AgU1idER23RVzBXuIXHrQvXEWx4XW2vTn7m0tksquAk8p59kZjKbk+IiQVTd17dapN+Jj0= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB4335.namprd11.prod.outlook.com (52.135.38.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.25; Mon, 11 Nov 2019 14:26:17 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::49b6:bc5c:bd3e:203c]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::49b6:bc5c:bd3e:203c%5]) with mapi id 15.20.2430.027; Mon, 11 Nov 2019 14:26:17 +0000 From: "Rob Wilton (rwilton)" To: Kent Watsen , Martin Bjorklund CC: "httpbis-chairs@ietf.org" , "netconf@ietf.org" Thread-Topic: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04 Thread-Index: AQHViGJKiGFhsDrRSkSDDSpVvqe78Kd6xJGAgAQocICAAH7EAIAAfoCAgAAGb4CAAB7jAIAAKPyAgABi0oCABYgvMA== Date: Mon, 11 Nov 2019 14:26:17 +0000 Message-ID: References: <0100016e466ae626-e9821117-8286-4f26-bc91-284d7dcaa453-000000@email.amazonses.com> <20191107153342.gqtgyseqyvsppcul@anna.jacobs.jacobs-university.de> <0100016e46e53383-ec073c86-f9d4-4358-9d78-b337f9cd9a58-000000@email.amazonses.com> <20191107.205057.1889050828820990344.mbj@tail-f.com> <0100016e48af524e-96c5b2d0-6b19-4e26-b3b6-8bb8021851d8-000000@email.amazonses.com> In-Reply-To: <0100016e48af524e-96c5b2d0-6b19-4e26-b3b6-8bb8021851d8-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=rwilton@cisco.com; x-originating-ip: [173.38.220.60] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6c1cbef6-41a0-4400-e814-08d766b31d99 x-ms-traffictypediagnostic: MN2PR11MB4335: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0218A015FA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(346002)(136003)(396003)(376002)(39860400002)(51444003)(189003)(199004)(5660300002)(6116002)(14454004)(790700001)(478600001)(6436002)(52536014)(229853002)(25786009)(4326008)(6246003)(9686003)(3846002)(66946007)(66476007)(66556008)(64756008)(66446008)(6306002)(54896002)(76116006)(55016002)(486006)(256004)(14444005)(99286004)(71190400001)(71200400001)(446003)(11346002)(9326002)(66066001)(81166006)(476003)(8936002)(8676002)(81156014)(110136005)(186003)(74316002)(7696005)(76176011)(6506007)(53546011)(33656002)(86362001)(2906002)(7736002)(102836004)(316002)(54906003)(26005); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4335; H:MN2PR11MB4366.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: hUt15GTiIUAgU4MJUylqLR80yz23c4lon1tsuPZ7jBvtXhAyRrQYQX2aTs7UE4+KGj2vrI9AWteE17yIdpwA/dGxf6kiZ/VQLmzkz/I1w3h+rZ5USSrqsYhbYIDeHmowpWfSFzWDTLGzS1K8Q7yBup5S8vlXFtsw6MK809jKi+sXwR0PscrVcnqZh8AsE3rJgmErVp6bphpJcm7iL3QdyLwfZAAJa8a2oz4qA71yePoWw/COGrhNuW6SJCzLFQZQYzcWSaNgl9lxnCe0x00h2DGBYR23OM0SFQLfxsl6D56Wbvo/k5IfmhbuHqaEFoN06XQrEu9MC8cUnL9dcL0G4hap9bXsSK6YroLO2rmyBpBcu6+Dxg3KN1YzhV2b5ljwowrT6twr97g32vbPd+uOrMfjIaLaHUVxJ0H+32Sj3ViM7i0EgQkcZTzbw+x7WsoI x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB4366C48AAC796F456FC0205FB5740MN2PR11MB4366namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6c1cbef6-41a0-4400-e814-08d766b31d99 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2019 14:26:17.7669 (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: TFqgr6G1kDkjAtreEI4T/PlWVVy0UGxd1i6a9U3Y4uN/e2nomcdMBWJGSNEGzagkuJaOnsOqiMAC9QSrt6qFnQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4335 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04 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, 11 Nov 2019 14:26:23 -0000 --_000_MN2PR11MB4366C48AAC796F456FC0205FB5740MN2PR11MB4366namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kent, I broadly agree with Martin here, in that I think that we want to get all o= f the "Client-Server" drafts finished. Defining groupings in one place is probably beneficial and I as such as sup= port the adoption of this draft, but not if it going to cause the other dra= fts that depend on these modules to end up being blocked for another 8 mont= hs, or a year. Can we quickly find a name for these modules that is good enough for us, an= d would also be acceptable to the httpbis WG? Perhaps "http-rest" instead of "http" or "restful"? Thanks, Rob From: netconf On Behalf Of Kent Watsen Sent: 08 November 2019 01:45 To: Martin Bjorklund Cc: httpbis-chairs@ietf.org; netconf@ietf.org Subject: Re: [netconf] Adoption call for draft-kwatsen-netconf-http-client-= server-04 Hi Martin, I think it is quite clear that the WG doesn't want more delays. Is it? I only know that Balazs K. wishes to have the first three drafts (= crypto-types, truststore, and keystore) completed soon. The Nokia/BBF folk= s were interested in netconf-server, but forked long ago. Otherwise, I'm u= naware of anyone stating a preference. For myself, I only hope to achieve= a good result. So I think that either we simply don't add this grouping *at this point*, and define the necessary nodes in the higher-level modules, even though it is not perfect; or we define the "restful" module with these groupings, even though that is also perhaps not perfect. ietf-restful-client and ietf-restful-server sound nice, but not so much in = a stack: tcp-server-parameters : { ... }, tls-server-parameters : { ... }, restful-server-parameters : { .... }, <---- end-user says "what'= s that?" restconf-server-parameters : { ... } or (for https-notif) tcp-client-parameters : { ... }, tls-client-parameters : { ... }, restful-client-parameters : { .... } <---- end-user says "what's tha= t?" Actually, the above is purposely inaccurate. If you recall, we switched t= o having container-less groupings, thus the consuming module can name the c= ontainer whatever it wants, so the net-net is no impact other than changing= the import and uses statements. Though I still don't know why we should = do even this, given the lack of any response to my Oct 30th message. Kent // contributor --_000_MN2PR11MB4366C48AAC796F456FC0205FB5740MN2PR11MB4366namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kent,<= o:p>

&nbs= p;

I broadly= agree with Martin here, in that I think that we want to get all of the = 220;Client-Server” drafts finished.

&nbs= p;

Defining = groupings in one place is probably beneficial and I as such as support the = adoption of this draft, but not if it going to cause the other drafts that = depend on these modules to end up being blocked for another 8 months, or a year.

&nbs= p;

Can we qu= ickly find a name for these modules that is good enough for us, and would a= lso be acceptable to the httpbis WG?

&nbs= p;

Perhaps &= #8220;http-rest” instead of “http” or “restful̶= 1;?

&nbs= p;

Thanks,

Rob<= /o:p>

&nbs= p;

&nbs= p;

From: netconf <netconf-bounces@ietf.org> On Behalf Of Kent Watsen
Sent: 08 November 2019 01:45
To: Martin Bjorklund <mbj@tail-f.com>
Cc: httpbis-chairs@ietf.org; netconf@ietf.org
Subject: Re: [netconf] Adoption call for draft-kwatsen-netconf-http-= client-server-04

 

Hi Martin,

 

I think it is quite clear that the WG doesn't want m= ore delays.  

 

Is it?   I only know that Balazs K. wishes to h= ave the first three drafts (crypto-types, truststore, and keystore) complet= ed soon.  The Nokia/BBF folks were interested in netconf-server, but f= orked long ago.  Otherwise, I'm unaware of anyone stating a preference.   For myself, I only hope to achieve a good res= ult.

 



So I think that either we simply don't add this= grouping *at this point*,
and define the necessary nodes in the higher-level modules, even
though it is not perfect; or we define the "restful" module with = these
groupings, even though that is also perhaps not perfect.

 

ietf-restful-client and ietf-restful-server sound ni= ce, but not so much in a stack:

 

    tcp-server-parameters : { ... },<= /o:p>

    tls-server-parameters : { ... },<= /o:p>

    restful-server-parameters : { .... }, =        <---- end-user says "what's that?"<= o:p>

    restconf-server-parameters : { ... }

 

or (for https-notif)

 

    tcp-client-parameters : { ... },<= /o:p>

    tls-client-parameters : { ... },<= /o:p>

    restful-client-parameters : { .... } &= nbsp;  <---- end-user says "what's that?"

 

 

Actually, the above is purposely inaccurate.   = If you recall, we switched to having container-less groupings, thus the con= suming module can name the container whatever it wants, so the net-net is n= o impact other than changing the import and uses statements.   Though I still don't know why we should do eve= n this, given the lack of any response to my Oct 30th message.

 

 

Kent // contributor

 

--_000_MN2PR11MB4366C48AAC796F456FC0205FB5740MN2PR11MB4366namp_-- From nobody Tue Nov 12 01:10:58 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB9431201DE for ; Tue, 12 Nov 2019 01:10:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 59RnT0kiNlTb for ; Tue, 12 Nov 2019 01:10:53 -0800 (PST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20062.outbound.protection.outlook.com [40.107.2.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 84B98120046 for ; Tue, 12 Nov 2019 01:10:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DVFZxIgJjhW43HzyhUfviYkrxJJCU6rq5UH7szIGi85P2Ml0C7fP5BG8arwuY9XNIg8bMYt9cKh17bo/InTCNCzjB1joUK6twGzJjE+fXKJErS0kh3eFGoN7twPjJtn6LHItHygWpeD/BsxUQ6UZc1Wwtry0LeLVTpSzeDZmCWaZ5zNqEmqu/eO+wwxcQSY3NiGQTKQzaPn6C6KKstF6AgW6TNaZa89W5CmneiXPdeCxo5VU1GsMlYeghRZkdbq1a/CjXHK5eM50xK7bBeezaxdSjv10hHZWvJHA+M1jha7HiKWikKQRMxSpLdm5QIhRnigB2aerISiumnYKeOOIvQ== 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=g1nT3XzK6dCDG/RQVjS9tI3uhmqxJGhPFfhwpe8JpXk=; b=jzE/JFGeWrjb6Xkl1NNm344MKN5xBauGUUuVFgXUk89r7vSNkXYEo8B5Vp+hQjWLHE6W4bYM0N7xC5i7dvfU45vbCyRZQzT2ND/hqWWQYro7keJwrUVXBoADidPLUPixgTvAW+5PZfE+9e6OckCyHIYAWbgEhQqfS0ni8GN/Y9/zE20fED/+Ytqgpr59G1l5fQDhgQoI9TCXtTSVaKRIZZG+wh2HV5j6CB00YucF1cB9Q/vsp1XfHXsw/OGwX7aJFF9huv53jMBdgSW1MdYpIZD4V4t/wB89RQfA0XCoW4f8tJ0IqErSgEoFO9cDMSWWNbkSMSH1izALmICzVMZVVA== 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=g1nT3XzK6dCDG/RQVjS9tI3uhmqxJGhPFfhwpe8JpXk=; b=aHwl0G0fPrS8xffwXIkEsF3LV3O3Lj8lYSM1FOXlu2JjsDvkNgkVkm1GpXEPIv/Uo62bi8qsGvOo/MWFHaJoMprt1pf0WExm+Bx8akKH2xZ58cb0MnTu8I/DM5L7pw6BA+5s9oUEHIym2MwIc+GAMemZbNyGB6+dwYMQGBFIxHA= Received: from AM0PR07MB5187.eurprd07.prod.outlook.com (20.178.20.74) by AM0PR07MB4753.eurprd07.prod.outlook.com (52.135.150.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.19; Tue, 12 Nov 2019 09:10:49 +0000 Received: from AM0PR07MB5187.eurprd07.prod.outlook.com ([fe80::e485:83e7:ee62:53f8]) by AM0PR07MB5187.eurprd07.prod.outlook.com ([fe80::e485:83e7:ee62:53f8%5]) with mapi id 15.20.2451.023; Tue, 12 Nov 2019 09:10:49 +0000 From: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= To: Kent Watsen CC: "netconf@ietf.org" Thread-Topic: FIXMEs in ietf-crypto-types and client/server models Thread-Index: AdWT66zB5kr5iNWxQ6yg/MeI8i6GNgAaO58AABS9kxAA5WCRgAA+4dkw Date: Tue, 12 Nov 2019 09:10:49 +0000 Message-ID: References: <0100016e3ed10fbb-8a5a44a9-6df6-4ac1-9b56-8dbf61ec64cc-000000@email.amazonses.com> <0100016e586dbe79-24514978-922b-479b-a523-3d2bbcdc56c4-000000@email.amazonses.com> In-Reply-To: <0100016e586dbe79-24514978-922b-479b-a523-3d2bbcdc56c4-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.kovacs@ericsson.com; x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6efbfd76-5b39-49c6-faa5-08d76750360a x-ms-traffictypediagnostic: AM0PR07MB4753: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 021975AE46 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(346002)(376002)(366004)(396003)(136003)(199004)(189003)(66946007)(25786009)(52536014)(6436002)(6246003)(236005)(476003)(6506007)(76116006)(316002)(11346002)(486006)(53546011)(66574012)(478600001)(446003)(71190400001)(14444005)(256004)(186003)(71200400001)(5660300002)(30864003)(2906002)(561944003)(9326002)(33656002)(99286004)(86362001)(76176011)(606006)(229853002)(4326008)(7696005)(8936002)(81166006)(81156014)(7736002)(85182001)(66066001)(66556008)(66476007)(64756008)(85202003)(66446008)(9686003)(26005)(790700001)(6116002)(3846002)(74316002)(54896002)(14454004)(6306002)(8676002)(55016002)(102836004)(170073001)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB4753; H:AM0PR07MB5187.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: Y9ZcLHudPm8lgq25XPLY+cMHsA23oL01TDNXGURZJDwp80U43L0ddCY8/Q/MUX99XvMYwl0C4BEGp5zVAFoPTMyPMxCzOWZelJ2DQkopq9v+erdaBgg6amYWOfabGF01u6m08a+LtDq7qX4QwULFNeaRbhRLA7UIaF2AkWnVzz6O8fua3f4F+hG9p2l+Y0aCx5cYyL2rkzBlIX+ILoxFvRHTIEr0so0jKvn91sIgyvzEYkIc/KDlQ/uUnTlME/qjEU6ENeUS+q2XgzVUw+UGV7QX0utC20bakQBubjpFgLpqR8cPk/sdwJgZAyhtXM5pGT0gfZ5cvdWFtot3qvmoSok5Rohk9TZI492U3iJhpfxPmF7MQ2KZ6BJcbKyDhf6Odc8StdmrkWJ9VRpVvMYdbsRNV3HXcnKwWRqsNx7jVFR7nWUHJUxLwAvABogZv1Ip x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR07MB51870B440CA86FD39E0926C883770AM0PR07MB5187eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6efbfd76-5b39-49c6-faa5-08d76750360a X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2019 09:10:49.7008 (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: mlbY02nwq2+f/aq1TyJQXT9rcPhb/3E3Sr+Z63GUP07a/L1WlnKDkiQOEcTB0deSOHs/RY5hLgRx86d374yizaGrvc3B2BkegbDyPhS8f5E= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4753 Archived-At: Subject: Re: [netconf] FIXMEs in ietf-crypto-types and client/server models 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, 12 Nov 2019 09:10:57 -0000 --_000_AM0PR07MB51870B440CA86FD39E0926C883770AM0PR07MB5187eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2VudCwNCg0KUmVnYXJkaW5nIHRoaXMgb25lOg0KDQpZZXMsIHRoZSBwcmV2aW91cyB3YXkg KGV4YW1wbGUgYWJvdmUpIHdhcyBhZGVxdWF0ZSwgYnV0IEkgYmVsaWV2ZSB0aGUgbmV3IHdheSAo aS5lLiB1c2luZyBhIGtleS1mb3JtYXQgbGVhZikgaXMgYmV0dGVyIGFzOg0KDQoxKSBpdCBlbmFi bGVzIHRoZSBhIGtleS10eXBlIChlLmcuLCBhIHN5bW1ldHJpYyBrZXkpIGRvIGJlIGV4cHJlc3Nl ZCBpbiBkaWZmZXJlbnQgd2F5cyBhcyBuZWVkZWQgKE9jdGV0U3RyaW5nIHZzLiBPbmVTeW1tZXRy aWNLZXkgdnMuIEVuY3J5cHRlZERhdGEpDQoyKSBpdCBNQVkgKGhhdmVuJ3QgdHJpZWQgdG8gbW9k ZWwgaXQgeWV0KSBiZSBhYmxlIHRvIHN1cHBvcnQgZW5jb2RpbmcgdmFyaWF0aW9ucyAoREVSIHZz IFBFTSwgYW5kIENNUyB2cy4gbXVsdGktcGFydCBQRU0pDQozKSBpdCBkZWNvdXBsZXMgdGhlIHBh cnQgdGhhdCB3ZSBhcmUgc3R1Y2sgb24gKGkuZS4sIHRoZSAnYWxnb3JpdGhtJyBub2RlKSBhbmQg aXQgYmVpbmcgZmFjdG9yZWQtb3V0IG1heSBwcm92aWRlIG1vcmUgZmxleGliaWxpdHkgaW4gdGhh dCBkZWZpbml0aW9uLg0KDQpUaGUgV0cgaGFzbid0IGRpc2N1c3NlZCBrZXktZm9ybWF0IHlldC4g IEFib3ZlIGlzIHRoZSBmaXJzdCBmb3JheSBpbnRvIGl0Li4uZG8gdGhlc2UgYXJndW1lbnRzIHNv dW5kIGNvbXBlbGxpbmc/DQoNClllcyBpbmRlZWQuIFNvIHRoZSBwcm9wb3NhbCBpcyBvayBmb3Ig bWUuIElzIHRoZXJlIGFueXRoaW5nIHRvIGRpc2N1c3Mgb24gdGhlIGRldGFpbHMgb2YgdGhpcyB0 byBtYXR0ZXIgb3IgdGhlIGhhdmUgdGhlIFdH4oCZcyBjb21taXRtZW50Pw0KDQpCcg0KQmFsYXpz DQoNCg0KRnJvbTogS2VudCBXYXRzZW4gPGtlbnQraWV0ZkB3YXRzZW4ubmV0Pg0KU2VudDogTW9u ZGF5LCBOb3ZlbWJlciAxMSwgMjAxOSA0OjA3IEFNDQpUbzogQmFsw6F6cyBLb3bDoWNzIDxiYWxh enMua292YWNzQGVyaWNzc29uLmNvbT4NCkNjOiBuZXRjb25mQGlldGYub3JnDQpTdWJqZWN0OiBS ZTogRklYTUVzIGluIGlldGYtY3J5cHRvLXR5cGVzIGFuZCBjbGllbnQvc2VydmVyIG1vZGVscw0K DQpIaSBCYWxhenMsDQoNCg0KDQoxLiAgICAgICBLZXktZm9ybWF0IChzeW1tZXRyaWMta2V5LCBw dWJsaWMta2V5LCBhc3ltbWV0cmljLWtleS1wYWlyKQ0KSSBhc3N1bWUgdGhlIGlkZWEgaGVyZSBp cyB0byBtYWtlIGl0IHBvc3NpYmxlIHRvIGhhdmUgY2hvaWNlcyBmb3IgdGhlIEFTTi4xIHR5cGVz IGhvbGRpbmcgdGhlIGtleXMuIElmIHRoaXMgZmxleGliaWxpdHkgZm9yIGZvcm1hdHMgaXMgbmVj ZXNzYXJ5IEkgZG9u4oCZdCBoYXZlIGFueSBvYmplY3Rpb24gdG8gdGhlbSBidXQgaGF2aW5nIGEg c2luZ2xlIGFncmVlZCB0eXBlIGZvciB0aGVzZSBkaWZmZXJlbnQgdXNlIGNhc2VzIHdvdWxkIGFs c28gc3VmZmljZS4NCg0KSSBiZWxpZXZlIGhlcmUgeW91J3JlIHJlZmVycmluZyB0byB0aGUgMyBp bnN0YW5jZXMgb2YgbGluZXMgbGlrZToNCg0KICAgICAgbGVhZiBrZXkgew0KICAgICAgICBuYWNt OmRlZmF1bHQtZGVueS1hbGw7DQogICAgICAgIHR5cGUgYmluYXJ5Ow0KICAgICAgICAvL211c3Qg Ii4uL2tleS1mb3JtYXQiOyAgRklYTUU6IHJlbW92ZSBjb21tZW50IGlmIGFwcHJvYWNoIG9rDQog ICAgICAgIC4uLg0KICAgICAgfQ0KDQpGV0lXLCB0aGUgd2hvbGUgImtleS1mb3JtYXQiIGxlYWYg aXMgc3RpbGwgYmVpbmcgc3Vzc2VkIG91dCAoeW91ciBvcGluaW9uIHdvdWxkIGJlIGhlbHBmdWwg b24gdGhhdCB0aHJlYWQgYXMgd2VsbCkgYnV0LCBzbyBmYXIgaXQgc2VlbXMgcHJvbWlzaW5nLiAg VGhlIHJlYXNvbiB0aGVzZSBsaW5lcyBhcmUgY29tbWVudGVkIG91dCBpcyBiZWNhdXNlIDEpIHRo ZSBXRyBoYXNuJ3QgY29tbWl0dGVkIHRvIHRoaXMgcGF0aCB5ZXQgYW5kIDIpIEkgZGlkbid0IHdh bnQgdG8gdXBkYXRlIGFsbCB0aGUgZXhhbXBsZXMgaW4gYWxsIHRoZSBkcmFmdHMgKG90aGVyIHRo YW4gdHJ1c3RzdG9yZSBhbmQga2V5c3RvcmUpIHRvIGFkZCBhICJrZXktZm9ybWF0IiBsZWFmIHVu dGlsIHRoZSBXRyBoYWQgbW9yZSBjb25zZW5zdXMgb24gdGhlICJrZXktZm9ybWF0IiBsZWFmcy4N Cg0KSSBkb24ndCB1bmRlcnN0YW5kIHlvdXIgbGFzdCBjb21tZW50L3NlbnRlbmNlLiAgQ2FuIHlv dSBwcm92aWRlIGFuIGV4YW1wbGU/DQoNCkJhbGF6cz4gT2ssIHRoZW4gbGV04oCZcyB3YWl0IGZv ciBXRyBkZWNpc2lvbi4gV2VsbCwgSSBqdXN0IHNheSB0aGF0IHRoZSBlYXJsaWVyIHdheXMgb2Yg Y29tbXVuaWNhdGluZyB0aGUga2V5IGZvcm1hdHMgd2VyZSBhZGVxdWF0ZSBmcm9tIG15IHBvaW50 IG9mIHZpZXcsIHdoaWNoIHdhcyB0aGF0IGluIGRvY3VtZW50YXRpb24gaXQgd2FzIHNhaWQgdGhh dCBmb3IgUlNBIHVzZSBSU0FQcml2YXRlS2V5IGFuZCBmb3IgRUMgdXNlIEVDUHJpdmF0ZUtleSwg YW5kIHNpbWlsYXJseSBmb3Igb3RoZXIgdHlwZXMuIEnigJltIGFsc28gb2sgd2l0aCB0aGUga2V5 LWZvcm1hdCBhcHByb2FjaCBpZiBwcmVmZXJyZWQgYnkgdGhlIFdHLg0KDQpJbiBlYXJsaWVyIHZl cnNpb25zOg0KDQogICAgICAgICAgIGRlc2NyaXB0aW9uDQogICAgICAgICAgICAgIlRoZSB2YWx1 ZSBvZiB0aGUgYmluYXJ5IGtleS4gIFRoZSBrZXkncyB2YWx1ZSBpcw0KICAgICAgICAgICAgICBp bnRlcnByZXRlZCBieSB0aGUgJ2FsZ29yaXRobScuICBGb3IgZXhhbXBsZSwgYSBEU0Ega2V5DQog ICAgICAgICAgICAgIGlzIGFuIGludGVnZXIsIGFuIFJTQSBrZXkgaXMgcmVwcmVzZW50ZWQgYXMg UlNBUHJpdmF0ZUtleQ0KICAgICAgICAgICAgICBhcyBkZWZpbmVkIGluIFJGQyA4MDE3PGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4MDE3PiwgYW5kIGFuIEVDQyBrZXkgaXMgcmVwcmVz ZW50ZWQgYXMNCiAgICAgICAgICAgICAgRUNQcml2YXRlS2V5IGFzIGRlZmluZWQgaW4gUkZDIDU5 MTU8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU5MTU+LiINCg0KWWVzLCB0aGUgcHJl dmlvdXMgd2F5IChleGFtcGxlIGFib3ZlKSB3YXMgYWRlcXVhdGUsIGJ1dCBJIGJlbGlldmUgdGhl IG5ldyB3YXkgKGkuZS4gdXNpbmcgYSBrZXktZm9ybWF0IGxlYWYpIGlzIGJldHRlciBhczoNCg0K MSkgaXQgZW5hYmxlcyB0aGUgYSBrZXktdHlwZSAoZS5nLiwgYSBzeW1tZXRyaWMga2V5KSBkbyBi ZSBleHByZXNzZWQgaW4gZGlmZmVyZW50IHdheXMgYXMgbmVlZGVkIChPY3RldFN0cmluZyB2cy4g T25lU3ltbWV0cmljS2V5IHZzLiBFbmNyeXB0ZWREYXRhKQ0KMikgaXQgTUFZIChoYXZlbid0IHRy aWVkIHRvIG1vZGVsIGl0IHlldCkgYmUgYWJsZSB0byBzdXBwb3J0IGVuY29kaW5nIHZhcmlhdGlv bnMgKERFUiB2cyBQRU0sIGFuZCBDTVMgdnMuIG11bHRpLXBhcnQgUEVNKQ0KMykgaXQgZGVjb3Vw bGVzIHRoZSBwYXJ0IHRoYXQgd2UgYXJlIHN0dWNrIG9uIChpLmUuLCB0aGUgJ2FsZ29yaXRobScg bm9kZSkgYW5kIGl0IGJlaW5nIGZhY3RvcmVkLW91dCBtYXkgcHJvdmlkZSBtb3JlIGZsZXhpYmls aXR5IGluIHRoYXQgZGVmaW5pdGlvbi4NCg0KVGhlIFdHIGhhc24ndCBkaXNjdXNzZWQga2V5LWZv cm1hdCB5ZXQuICBBYm92ZSBpcyB0aGUgZmlyc3QgZm9yYXkgaW50byBpdC4uLmRvIHRoZXNlIGFy Z3VtZW50cyBzb3VuZCBjb21wZWxsaW5nPw0KDQoNCg0KDQoNCjIuICAgICAgIGF0dHJpYnV0ZXMg aW4gYXN5bW1ldHJpYy1rZXktcGFpci13aXRoLWNlcnQocyktZ3JvdXBpbmcNCkkgdGhpbmsgYXR0 cmlidXRlcyBzaG91bGQgYmUga2VwdCBvcHRpb25hbC4gSWYgdGhlcmUgaXMgYW55dGhpbmcgZWxz ZSBiZXNpZGVzIHN1YmplY3Qgc2VlbiBtYW5kYXRvcnkgbWF5YmUgaXQgc2hvdWxkIGJlIGV4dHJh Y3RlZCBvdXQgZnJvbSBhdHRyaWJ1dGVzIGFuZCBiZSBzcGVsbGVkIG91dCBhIHNlcGFyYXRlIGxl YWYsIGJ1dCBJIGRvbuKAmXQgdGhpbmsgdGhlcmUgaXMuDQoNCkkgYmVsaWV2ZSBoZXJlIHlvdSdy ZSByZWZlcnJpbmcgdG8gdGhlIDIgaW5zdGFuY2VzIG9mIGxpbmVzIGxpa2U6DQoNCiAgICAgICAg bGVhZiBhdHRyaWJ1dGVzIHsNCiAgICAgICAgICB0eXBlIGJpbmFyeTsgLy8gRklYTUU6IGRvZXMg dGhpcyBuZWVkIHRvIGJlIG1hbmRhdG9yeT8NCiAgICAgICAgICAuLi4NCiAgICAgICAgfQ0KDQpU aGVzZSBhcmUgaW4gdGhlICJnZW5lcmF0ZS1jZXJ0aWZpY2F0ZS1zaWduaW5nLXJlcXVlc3QiIGFj dGlvbnMgZm91bmQgaW5zaWRlIHRoZSBhc3ltbWV0cmljLWtleS1wYWlyLXdpdGgtY2VydChzKS1n cm91cGluZy4NCg0KSG1tbSwgYXJlIHlvdSBjbGFpbWluZyB0aGF0ICJhdHRyaWJ1dGVzIiBhcmUg bm90IHJlcXVpcmVkIGluIG9yZGVyIHRvIGdlbmVyYXRlIGEgQ1NSPyAgSSB0aGluayB0aGUgQ1NS IGl0c2VsZiBNVVNUIGhhdmUgYXR0cmlidXRlcyAocmlnaHQ/KSBzbywgaWYgbm90IHNwZWNpZmll ZCwgd2hhdCBkZWZhdWx0IHZhbHVlcyBhcmUgdXNlZD8NCg0KQmFsYXpzPiBJbiBSRkMyOTg2PGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMyOTg2I3NlY3Rpb24tMz4gdGhlIGF0dHJpYnV0 ZXMgYXJlIHNhaWQgdG8gYmUgb3B0aW9uYWwuIFdlIGp1c3QgbmVlZCB0aGUgc3ViamVjdCBETiBh cyBtYW5kYXRvcnksIGRvbuKAmXQgd2U/DQoNCg0KDQoNCiAgICAgICAgMS4gQSBDZXJ0aWZpY2F0 aW9uUmVxdWVzdEluZm8gdmFsdWUgY29udGFpbmluZyBhIHN1YmplY3QNCg0KICAgICAgICAgICBk aXN0aW5ndWlzaGVkIG5hbWUsIGEgc3ViamVjdCBwdWJsaWMga2V5LCBhbmQgb3B0aW9uYWxseSBh DQoNCiAgICAgICAgICAgc2V0IG9mIGF0dHJpYnV0ZXMgaXMgY29uc3RydWN0ZWQgYnkgYW4gZW50 aXR5IHJlcXVlc3RpbmcNCg0KICAgICAgICAgICBjZXJ0aWZpY2F0aW9uLg0KDQpUaGFuayB5b3Uu ICBJJ3ZlIHJlbW92ZWQgdGhlc2UgdG8gY29tbWVudHMsIHRodXMgbGVhdmluZyB0aGUgImF0dHJ1 YnR1dGUiIG5vZGVzIGFzIE5PVCBtYW5kYXRvcnkuDQoNCg0KDQoNCg0KMy4gICAgICAgUFNLIGFu ZCByYXcgcHVibGljIGtleXMNClRoZSB1c2UgY2FzZSBvZiBQU0sgYW5kIHJhdyBwdWJsaWMga2V5 cyBhcmUgbm90IHRoZSBtb3N0IHVyZ2VudCBpbiBteSBvcGluaW9uIHdoaWNoIG5vdyBzbG93cyBh IGJpdCB0aGUgcHJvZ3Jlc3Mgb2YgdGhlc2UgZHJhZnRzLCBidXQgbGV04oCZcyBtYWtlIGFuIGF0 dGVtcHQgdG8gZmluYWxpemUgdGhlbS4NCg0KQWdyZWVkLCBidXQgdGhleSBhcmUgbGVnYWwgZm9y IFRMUyBhbmQgYSBXRyBtZW1iZXIgc3RhdGVkIHRoYXQgdGhleSB3ZXJlIG5lZWRlZCBpbiBvcmRl ciB0byBzdXBwb3J0IGFub3RoZXIgSUVURiBXRydzIGVmZm9ydHMuICBBIHF1aWNrIHJlc29sdXRp b24gd291bGQgYmUgYmVzdCENCg0KDQoNCnJhdy1wdWJsaWMta2V5czogSSBzZWUgdGhlc2Ugd2Vy ZSBhZGRlZCBkdWUgdG8gUkZDIDcyNTAgYW5kIDg0NDYuIEkgZ3Vlc3MgaW4gdHJ1c3RzdG9yZSB0 aGlzIGlzIGEgc2VwYXJhdGUgY29udGFpbmVyIHRvIGRpc3Rpbmd1aXNoIGZyb20gU1NIIGhvc3Qg a2V5cy4gRm9yIGNvbmZpZ3VyaW5nIHRoZSBwcml2YXRlIHBhcnQgSSB0aGluayBrZXlzdG9yZSBh bHJlYWR5IGdpdmVzIHN1cHBvcnQgZm9yIHRoaXMgY2FzZSB3aXRoIHRoZSBhc3ltbWV0cmljIGtl eSAody9vIGNlcnQpIGFuZCBpbiB0aGUgY2xpZW50L3NlcnZlciBkcmFmdHMgS2VudOKAmXMgcHJv cG9zYWwgY291bGQgYmUgdXNlZCAoSSByZXBsYWNlZCByYXcgcHVibGljIGtleSB3aXRoIGV4aXN0 aW5nIHR5cGUsIHNob3VsZG7igJl0IHRoYXQgYmUgdXNlYWJsZSBzdHJhaWdodCBhd2F5PykNCg0K ICAgICAgICAgICAgICAgICAgICBjb250YWluZXIgPGNsaWVudC1pZGVudGl0eSBvciBzZXJ2ZXIt aWRlbnRpdHk+IHsNCiAgICAgICAgICAgICAgICAgICAgICBjaG9pY2UgYXV0aC10eXBlIHsNCiAg ICAgICAgICAgICAgICAgICAgICAgICB1c2VzIGtzOmxvY2FsLW9yLWtleXN0b3JlLWVuZC1lbnRp dHktY2VydC13aXRoLWtleS1ncm91cGluZzsNCiAgICAgICAgICAgICAgICAgICAgICAgICB1c2Vz IGtzOmxvY2FsLW9yLWtleXN0b3JlLWFzeW1tZXRyaWMta2V5LWdyb3VwaW5nOw0KDQoNCg0KSSB3 b3VsZCBhbHNvIHByZWZlciBpZiB0aGVzZSBjaG9pY2VzIGFyZSBpbiBmZWF0dXJlcywgc28gdGhh dCBhbiBpbXBsZW1lbnRhdGlvbiBjYW4gY2hvb3NlLg0KDQpUbyB5b3VyIGZpcnN0IHNlbnRlbmNl LCB5ZXMsICJwc2siIChhbmQgInJhdy1wdWJsaWMta2V5IikgYXJlIHRvcC1sZXZlbCBub2RlcyBp biB0cnVzdHN0b3JlLCBhcyBjYW4gYmUgc2VlbiBoZXJlIChodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1uZXRjb25mLXRydXN0LWFuY2hvcnMtMDcjc2VjdGlvbi0yLjEpLiAg IE5vdGUsIHRoZSB0cnVzdC1hbmNob3JzIGRyYWZ0IGFjY2lkZW50YWxseSBkb2Vzbid0IGluY2x1 ZGUgdGhlIGlldGYtdHJ1c3RzdG9yZS55YW5nIG1vZHVsZS4NCg0KVGhlIGJvZHkgb2YgeW91ciBj b21tZW50IGFib3ZlIHNlZW1zIHRvIGJlIGFib3V0IHN1cHBvcnRpbmcgdGhlIHNlY3JldC1oYWxm IG9mIHRoZSBQU0sgYW5kIFJQSyB3aXRoaW4gdGhlIEtleXN0b3JlLiAgSSd2ZSByYWlzZSB0aGlz IHF1ZXN0aW9uIGEgY291cGxlIHRpbWVzIHByZXZpb3VzbHkgdG8gSGVuayAod2hvJ3MgYXNraW5n IGZvciB0aGUgUFNLL1JQSyBhZGQpLCBidXQgaGUncyBub3QgcmVzcG9uZGVkIHlldCBhcyB0byBp ZiBkb2luZyBzbyBpcyBpbXBvcnRhbnQgKHRob3VnaCBJIGNhbiBvbmx5IGltYWdpbmUgdGhhdCBp dCBkb2VzKS4gICBXaXRoIHRoYXQgc2FpZCwgSSB0aGluayB5b3VyIFlBTkcgc25pcHBldCBpcyBt ZWFudCB0byBiZSBpbiBpZXRmLXRscy1zZXJ2ZXIgYW5kIGlldGYtdGxzLWNsaWVudCBtb2R1bGVz IChyaWdodD8pLiAgSSdtIGhhdmluZyBhIGhhcmQgdGltZSBmb2xsb3dpbmcgdGhlICJJIHJlcGxh Y2VkIHJhdyBwdWJsaWMga2V5IHdpdGggZXhpc3RpbmcgdHlwZSwgc2hvdWxkbuKAmXQgdGhhdCBi ZSB1c2VhYmxlIHN0cmFpZ2h0IGF3YXk/IiBjb21tZW50Lg0KDQpCYWxhenM6IFlvdSBoYWQgYW4g ZXhhbXBsZSBlYXJsaWVyIGluIGFuIGVtYWlsIGZyb20gMTAvOC8yMDE5LCB3aGljaCBpcyBhYm91 dCB0aGUgVExTIGNsaWVudC9zZXJ2ZXIgbW9kZWxzLiBCZWxvdywgeW91IGFyZSByZWZlcnJpbmcg dG8gc29tZSBwb3NzaWJseSBuZXcgZ3JvdXBpbmdzIHRoYXQgeW91IHdhbnRlZCB0byBwcm9wb3Nl LiBJIGRvbuKAmXQgdW5kZXJzdGFuZCB0aG91Z2ggd2h5IHlvdSBtZW50aW9uZWQgdGhlc2UgbmV3 IGdyb3VwaW5ncyBzaW5jZSDigJhrczpsb2NhbC1vci1rZXlzdG9yZS1hc3ltbWV0cmljLWtleS1n cm91cGluZ+KAmSAoUlBLKSBhbmQgc29tZXRoaW5nIG5ldyB0aGF0IGp1c3QgcmVmZXJzIHRvIGEg a2V5c3RvcmUgc3ltbWV0cmljIGtleSwgc3VjaCBhcyDigJhrczpsb2NhbC1vci1rZXlzdG9yZS1z eW1tZXRyaWMta2V5LWdyb3VwaW5n4oCZIChQU0spIHNob3VsZCBiZSBnb29kLiBUaGlzIGxhdHRl ciBJIHRoaW5rIHdvdWxkIGJlIGEgbmV3IGdyb3VwaW5nLCBidXQgd2l0aCBleGlzdGluZyB0ZXJt aW5vbG9neS4NCg0KQWxsLCBsb29raW5nIGF0IGlldGYtdGxzLWNsaWVudC55YW5nIGFuZCBpZXRm LXRscy1zZXJ2ZXIueWFuZywgYWRkaW5nIHRoZSBhYmlsaXR5IHRvIGNvbmZpZ3VyZSB0aGUgInBy aXZhdGUiIGhhbGYgb2YgYSBQU0sgb3IgcmF3IHB1YmxpYyBrZXkgd291bGQgYmUgc29tZXRoaW5n IGxpa2U6DQoNCiAgICAgICAgICAgICAgICBPTEQNCiAgICAgICAgICAgICAgICAgICAgY29udGFp bmVyIDxjbGllbnQtaWRlbnRpdHkgb3Igc2VydmVyLWlkZW50aXR5PiB7DQogICAgICAgICAgICAg ICAgICAgICAgdXNlcyBrczpsb2NhbC1vci1rZXlzdG9yZS1lbmQtZW50aXR5LWNlcnQtd2l0aC1r ZXktZ3JvdXBpbmc7DQogICAgICAgICAgICAgICAgTkVXDQogICAgICAgICAgICAgICAgICAgIGNv bnRhaW5lciA8Y2xpZW50LWlkZW50aXR5IG9yIHNlcnZlci1pZGVudGl0eT4gew0KICAgICAgICAg ICAgICAgICAgICAgIGNob2ljZSBhdXRoLXR5cGUgew0KICAgICAgICAgICAgICAgICAgICAgICAg IHVzZXMga3M6bG9jYWwtb3Ita2V5c3RvcmUtZW5kLWVudGl0eS1jZXJ0LXdpdGgta2V5LWdyb3Vw aW5nOw0KICAgICAgICAgICAgICAgICAgICAgICAgIHVzZXMga3M6bG9jYWwtb3Ita2V5c3RvcmUt cmF3LXB1YmxpYy1rZXktZ3JvdXBpbmc7DQogICAgICAgICAgICAgICAgICAgICAgICAgdXNlcyBr czpsb2NhbC1vci1rZXlzdG9yZS1wcmUtc2hhcmVkLWtleS1ncm91cGluZzsNCg0KDQpBaCwgbm93 IEkgdW5kZXJzdGFuZCwgSSBhbmQgYWdyZWUgdGhhdCB0aGlzIHNlZW1zIGxpa2UgdGhlIHJpZ2h0 IHdheSB0byBkbyBpdCwgYnV0IHNlZSBiZWxvdy4uLg0KDQoNCg0KVG8geW91ciBsYXN0IHNlbnRl bmNlIHJlZ2FyZGluZyBmZWF0dXJlcywgY291bGQgeW91IHByb3ZpZGUgYW4gZXhhbXBsZSBvZiB3 aGF0IHlvdSBtZWFuPw0KDQoNCmNvbnRhaW5lciA8Y2xpZW50LWlkZW50aXR5IG9yIHNlcnZlci1p ZGVudGl0eT4gew0KICAgIGNob2ljZSBhdXRoLXR5cGUgew0KICAgICAgICBtYW5kYXRvcnkgdHJ1 ZTsNCiAgICAgICAgY2FzZSBjZXJ0aWZpY2F0ZSB7DQogICAgICAgICAgICBpZi1mZWF0dXJlIHg1 MDktY2VydGlmaWNhdGUtYXV0aDsNCiAgICAgICAgICAgdXNlcyBrczpsb2NhbC1vci1rZXlzdG9y ZS1lbmQtZW50aXR5LWNlcnQtd2l0aC1rZXktZ3JvdXBpbmc7DQogICAgICAgfQ0KICAgICAgICBj YXNlIHJhdy1wdWJsaWMta2V5IHsNCiAgICAgICAgICAgIGlmLWZlYXR1cmUgcmF3LXB1YmxpYy1r ZXktYXV0aDsNCiAgICAgICAgICAgdXNlcyBrczpsb2NhbC1vci1rZXlzdG9yZS1hc3ltbWV0cmlj LWtleS1ncm91cGluZzsNCiAgICAgICB9DQogICAgICAgIGNhc2UgcHNrIHsNCiAgICAgICAgICAg IGlmLWZlYXR1cmUgcHNrLWF1dGg7DQogICAgICAgICAgIHVzZXMga3M6bG9jYWwtb3Ita2V5c3Rv cmUtc3ltbWV0cmljLWtleS1ncm91cGluZzsNCiAgICAgICB9DQoNCkJldHRlciEgIFRoaXMgdXNl cyB0aGUgZXhpc3RpbmcgZ3JvdXBpbmdzIChlLmcuLCBrczpsb2NhbC1vci1rZXlzdG9yZS1hc3lt bWV0cmljLWtleS1ncm91cGluZykgd2hlcmVhcyB0aGUgYWJvdmUgcHJvcG9zYWwgZGVmaW5lZCBu ZXcgb25lcy4gIChzZWUgR2l0SHViIGZvciBsYXRlc3QgZmlsZXMsIHRob3VnaCB0aGUgY29tbWl0 IGlzIGxhcmdlciB0aGFuIGl0IHNob3VsZCBiZSkNCg0KSGVuaywgd2hhdCBkbyB5b3UgdGhpbms/ DQoNCg0KSSBhc3N1bWUgdGhlc2UgZmVhdHVyZXMgd291bGQgdGhlbiBuZWVkIHRvIGJlIGRlZmlu ZWQgaW4gdGhlIFRMUyBjbGllbnQvc2VydmVyIGRyYWZ0Lg0KDQpZZXMuDQoNCg0KDQpQUzogbm9u ZSBvZiB0aGlzIGdvZXMgdG8gdGhlIEZJWE1FIGluIHRoZSBpZXRmLWNyeXB0by10eXBlcy4gIEkg aGFkIHByZXZpb3VzbHkgYXNrZWQgSGVuayB0byBwcm92aWRlIHNvbWUgdGV4dCBoZXJlIGFzIHdl bGwgYnV0LCBhcHBhcmVudGx5LCBsaWtlIGFsbCBvZiB1cyBhdCB0aGlzIHRpbWUsIGhlJ3MgYmVl biBidXN5IQ0KDQogcHNrOiBnaXZlbiB0aGF0IHRoZSBhc3ltbWV0cmljIGtleXMgd2l0aG91dCBj ZXJ0cyB3ZXJlIGNvdmVyZWQgYnkgaG9zdCBrZXlzIGFuZCByYXcgcHVibGljIGtleXMsIEkgdGhp bmsgcHNrIHNob3VsZCBvbmx5IGJlIHN5bW1ldHJpYyBrZXlzLiBTeW1tZXRyaWMga2V5cyBhcmUg dGhlbiBzZW5zaXRpdmUvc2VjcmV0IGRhdGEgYW5kIGFzIHN1Y2ggSSBiZWxpZXZlIHRoZXkgc2hv dWxkIG9ubHkgYmUgcmVmZXJlbmNlZCBmcm9tIGtleXN0b3JlLiBTZWVpbmcgdGhlbSBpbiB0cnVz dHN0b3JlIHdhcyB1bmV4cGVjdGVkIGZvciBtZS4gV2hlbiBpdCBjb21lcyB0byB0aGVpciB1c2Us IGNsaWVudHMgYW5kIHNlcnZlcnMgc2hvdWxkIGJlIGV4dGVuZGVkIHdpdGggZm9sbG93aW5nIGNv bmZpZ3VyYXRpb24gKGFuZCBJIGFzc3VtZSB3ZSB0YWxrIG9mIFRMUyBjbGllbnRzIGFuZCBzZXJ2 ZXJzIG9ubHkpOg0KDQogICAgICAgICAgICAgICAgICAgIGNvbnRhaW5lciA8Y2xpZW50LWlkZW50 aXR5IG9yIHNlcnZlci1pZGVudGl0eT4gew0KICAgICAgICAgICAgICAgICAgICAgIGNob2ljZSBh dXRoLXR5cGUgew0KICAgICAgICAgICAgICAgICAgICAgICAgIHVzZXMga3M6bG9jYWwtb3Ita2V5 c3RvcmUtZW5kLWVudGl0eS1jZXJ0LXdpdGgta2V5LWdyb3VwaW5nOw0KICAgICAgICAgICAgICAg ICAgICAgICAgIHVzZXMga3M6bG9jYWwtb3Ita2V5c3RvcmUtYXN5bW1ldHJpYy1rZXktZ3JvdXBp bmc7DQogICAgICAgICAgICAgICAgICAgICAgIHVzZXMga3M6bG9jYWwtb3Ita2V5c3RvcmUtc3lt bWV0cmljLWtleS1ncm91cGluZzsNCg0KTGF0dGVyIGdyb3VwaW5nIHdvdWxkIGJlIGEgbmV3IG9u ZSwgYnV0IGl0IHdvdWxkIHVzZSBleGlzdGluZyBjb25zdHJ1Y3RzIGFuZCB0ZXJtcyBmcm9tIGtl eXN0b3JlLiBJIGRvbuKAmXQgdGhpbmsgd2UgbmVlZCBuZXcgb25lcy4gU2VsZWN0ZWQgY2lwaGVy IHN1aXRlcyB3aWxsIG5lZWQgdG8gaGF2ZSBQU0sgaW4gdGhlbSBmb3IgdXNpbmcgc3ltbWV0cmlj IGtleSAoc2ltaWxhciBtYXRjaCBuZWVkZWQgZm9yIHRoZSBvdGhlcnMpLiBOb3RlIHRoYXQgc3lt bWV0cmljIGtleXMgY2FuIGJlIHVzZWQgZm9yIG90aGVyIGNhc2VzIHRoYW4gVExTIFBTSywgZm9y IGV4YW1wbGUgU05NUHYzIFVTTS4gQWdhaW4sIGZlYXR1cmVzIHdvdWxkIGJlIG5lY2Vzc2FyeSAo dGhvc2UgY291bGQgYmUgc2F5aW5nIHguNTA5IG9yIHJhdy1wdWJsaWMta2V5IG9yIHBzaykuDQoN Cg0KQ29ycmVjdCwgSSBzYWlkIHRoZSBzYW1lICh0aGF0IFBTS3MgYXJlIGVzc2VudGlhbGx5IHN5 bW1ldHJpYyBrZXlzKSBiZWZvcmUgYXMgd2VsbC4gIFJlZ2FyZGluZyBvbmx5IGJlaW5nIHJlZmVy ZW5jZWQgdG8ga2V5c3RvcmUsIHdoeSBub3QgYWxzbyBzdXBwb3J0IHRoZW0gYmVpbmcgbG9jYWwt ZGVmaW5pdGlvbnMgdG9vPyAgQ2VydGFpbmx5IG5vdCBhIHByb2JsZW0gaWYgZW5jcnlwdGVkIGFu ZCwgZXZlbiB3aGVuIG5vdCBlbmNyeXB0ZWQsIHRoZW4gdGhleSBjYW4gYmUgInByb3RlY3RlZCIg YnkgTkFDTS1saWtlIG1lY2hhbmlzbXMsIHJpZ2h0Pw0KDQpCYWxhenM+IExvY2FsIGRlZmluaXRp b25zIGFyZSBvayB0b28gdGhhdOKAmXMgd2h5IEkgdXNlZCBhIGh5cG90aGV0aWNhbCBncm91cGlu ZyBuYW1lICBrczpsb2NhbC1vci1rZXlzdG9yZS1zeW1tZXRyaWMta2V5LWdyb3VwaW5nLg0KDQpT b3JyeSwgSSBnbG9zc2VkIG92ZXIgdGhlICJsb2NhbC0iIHByZWZpeCBpbiB5b3VyIGVhcmxpZXIg c3RhdGVtZW50Lg0KDQpJIGFncmVlIHRoYXQgUFNLcyBzaG91bGQgYmUgaW4gS2V5c3RvcmUgd2hl biB1c2VkIGZvciBjbGllbnQtaWRlbnRpdHkvc2VydmVyLWlkZW50aXR5IG5vZGVzLi4uIChtb3Jl IGJlbG93KQ0KDQoNCiAgV2h5IHdhcy9pcyBzZWVpbmcgdGhlbSBpbiB0cnVzdHN0b3JlIGEgc3Vy cHJpc2UsIHBlcmhhcHMgYmVjYXVzZSB0aGV5J3JlIG5vdCBlbmNyeXB0YWJsZSB0aGVyZT8NCg0K QmFsYXpzPiBXaGVuIFBTS3MgYXJlIHVzZWQgdGhlbiBib3RoIGNvbW11bmljYXRpbmcgZW5kcyB1 c2UgdGhlIHNoYXJlZCBrZXkgZm9yIHNpZ25pbmcgYW5kIHZlcmlmeWluZyBtZXNzYWdlcy4gVGhl biBvbmUgY29uZmlndXJhdGlvbiBzZWVtcyBlbm91Z2ggdGhhdCBpcyBlaXRoZXIgbG9jYWwgb3Ig ZnJvbSBrZXlzdG9yZSwgd2h5IHdvdWxkIGl0IGJlIG5lY2Vzc2FyeSB0byBzZXQgaXQgdXAgeWV0 IGFub3RoZXIgdGltZSBmb3IgdmVyaWZpY2F0aW9uIGZyb20gbG9jYWwgb3IgdHJ1c3RzdG9yZT8g VGhpcyB3b3VsZCBtZWFuIHRoZXJlIGlzIG5vIG5lZWQgZm9yIGEgUFNLIG9wdGlvbiB3aGVuIGNv bmZpZ3VyaW5nIGhvdyB0byAgdmVyaWZ5IHRoZSBwZWVyLg0KDQpjb250YWluZXIgPGNsaWVudC1h dXRoZW50aWNhdGlvbiBvciBzZXJ2ZXItYXV0aGVudGljYXRpb24+IHsNCiAgICBjaG9pY2UgYXV0 aC10eXBlIHsNCiAgICAgICAgbWFuZGF0b3J5IHRydWU7DQogICAgICAgIGNhc2UgY2VydGlmaWNh dGUgew0KICAgICAgICAgICAgaWYtZmVhdHVyZSB4NTA5LWNlcnRpZmljYXRlLWF1dGg7DQogICAg ICAgICAgICBjb250YWluZXIgY2EtY2VydHMgew0KDQogICAgICAgICAgICAgICAgdXNlcyB0czps b2NhbC1vci10cnVzdHN0b3JlLWNlcnRzLWdyb3VwaW5nDQogICAgICAgICAgICB9DQogICAgICAg ICAgICBjb250YWluZXIgc2VydmVyLWNlcnRzIHsNCg0KICAgICAgICAgICAgICAgIHVzZXMgdHM6 bG9jYWwtb3ItdHJ1c3RzdG9yZS1jZXJ0cy1ncm91cGluZw0KICAgICAgICAgICAgfQ0KICAgICAg IH0NCiAgICAgICAgY2FzZSByYXctcHVibGljLWtleSB7DQogICAgICAgICAgICBpZi1mZWF0dXJl IHJhdy1wdWJsaWMta2V5LWF1dGg7DQogICAgICAgICAgICAgICAgdXNlcyBrczogbG9jYWwtb3It dHJ1c3RzdG9yZS1yYXctcHViLWtleXMtZ3JvdXBpbmcNCiAgICAgICB9DQoNCg0KTm8gbmVlZCBm b3IgUFNLIGNvbmZpZyBzaW5jZSBpdCBpcyBhbHJlYWR5IGNvbmZpZ3VyZWQgaW4gY2xpZW50L3Nl cnZlci1pZGVudGl0eS4NCg0KQWNrLiAgIChzZWUgR2l0SHViIGZvciBsYXRlc3QgZmlsZXMsIHRo b3VnaCB0aGUgY29tbWl0IGlzIGxhcmdlciB0aGFuIGl0IHNob3VsZCBiZSkNCg0KQW5kLCBhcyBh IGJvbnVzLCBLZXlzdG9yZSBhbHJlYWR5IGRlZmluZXMgc3VwcG9ydCBmb3IgZW5jcnlwdGlvbiAo dW5saWtlIFRydXN0c3RvcmUpLg0KDQoNCg0KIE9yIHdoYXQgaXMgdGhlIHJlYXNvbmluZyB3aHkg aXQgaXMgbmVjZXNzYXJ5IHRvIGNvbmZpZ3VyZSBhIFBTSyBmcm9tIHRydXN0c3RvcmU/DQoNClNv bWVob3cgSSB0aG91Z2h0IHRoYXQgd2VyZSBiZWluZyB1c2VkIGluIGNvbmNlcHR1YWxseSBkaWZm ZXJlbnQgd2F5cywgYnV0IEkgc2VlIG5vdyB0aGF0J3Mgbm90IHJlYWxseSB0aGUgY2FzZS4uLg0K DQoNClRoYW5rIHlvdSwgQmFsYXpzLCB0aGlzIG1lc3NhZ2Ugd2FzIG1vc3QgaGVscGZ1bCENCg0K S2VudCAvLyBjb250cmlidXRvcg0KDQoNCg== --_000_AM0PR07MB51870B440CA86FD39E0926C883770AM0PR07MB5187eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0xpc3RQYXJhZ3Jh cGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHls ZS1wcmlvcml0eTozNDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAu bXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5h bWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZv bnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bh bi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVk LXNwYWNlO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNw YW4uYXBwbGUtdGFiLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtdGFiLXNwYW47fQ0Kc3Bh bi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SGkgS2VudCw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkaW5nIHRoaXMgb25lOjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+WWVzLCB0aGUg cHJldmlvdXMgd2F5IChleGFtcGxlIGFib3ZlKSB3YXMgYWRlcXVhdGUsIGJ1dCBJIGJlbGlldmUg dGhlIG5ldyB3YXkgKGkuZS4gdXNpbmcgYSBrZXktZm9ybWF0IGxlYWYpIGlzIGJldHRlciBhczo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4xKSBpdCBlbmFibGVzIHRoZSBhIGtleS10eXBlIChlLmcuLCBhIHN5 bW1ldHJpYyBrZXkpIGRvIGJlIGV4cHJlc3NlZCBpbiBkaWZmZXJlbnQgd2F5cyBhcyBuZWVkZWQg KE9jdGV0U3RyaW5nIHZzLiZuYnNwO09uZVN5bW1ldHJpY0tleSB2cy4mbmJzcDtFbmNyeXB0ZWRE YXRhKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjIpIGl0IE1BWSAoaGF2ZW4ndCB0cmllZCB0byBtb2RlbCBpdCB5ZXQpIGJlIGFi bGUgdG8gc3VwcG9ydCBlbmNvZGluZyB2YXJpYXRpb25zIChERVIgdnMgUEVNLCBhbmQgQ01TIHZz LiBtdWx0aS1wYXJ0IFBFTSk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4zKSBpdCBkZWNvdXBsZXMgdGhlIHBhcnQgdGhhdCB3ZSBh cmUgc3R1Y2sgb24gKGkuZS4sIHRoZSAnYWxnb3JpdGhtJyBub2RlKSBhbmQgaXQgYmVpbmcgZmFj dG9yZWQtb3V0IG1heSBwcm92aWRlIG1vcmUgZmxleGliaWxpdHkgaW4gdGhhdCBkZWZpbml0aW9u LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPlRoZSBXRyBoYXNuJ3QgZGlzY3Vzc2VkIGtleS1mb3JtYXQgeWV0 LiAmbmJzcDtBYm92ZSBpcyB0aGUgZmlyc3QgZm9yYXkgaW50byBpdC4uLmRvIHRoZXNlIGFyZ3Vt ZW50cyBzb3VuZCBjb21wZWxsaW5nPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMgaW5kZWVk LiBTbyB0aGUgcHJvcG9zYWwgaXMgb2sgZm9yIG1lLiBJcyB0aGVyZSBhbnl0aGluZyB0byBkaXNj dXNzIG9uIHRoZSBkZXRhaWxzIG9mIHRoaXMgdG8gbWF0dGVyIG9yIHRoZSBoYXZlIHRoZSBXR+KA mXMgY29tbWl0bWVudD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnI8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJhbGF6czxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGI+RnJvbTo8L2I+IEtl bnQgV2F0c2VuICZsdDtrZW50JiM0MztpZXRmQHdhdHNlbi5uZXQmZ3Q7DQo8YnI+DQo8Yj5TZW50 OjwvYj4gTW9uZGF5LCBOb3ZlbWJlciAxMSwgMjAxOSA0OjA3IEFNPGJyPg0KPGI+VG86PC9iPiBC YWzDoXpzIEtvdsOhY3MgJmx0O2JhbGF6cy5rb3ZhY3NAZXJpY3Nzb24uY29tJmd0Ozxicj4NCjxi PkNjOjwvYj4gbmV0Y29uZkBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogRklYTUVz IGluIGlldGYtY3J5cHRvLXR5cGVzIGFuZCBjbGllbnQvc2VydmVyIG1vZGVsczxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj5IaSBCYWxhenMsPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxk aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6 MS41aW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O3RleHQtaW5kZW50Oi0uMjVpbiI+DQoxLjxzcGFu IHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8 L3NwYW4+S2V5LWZvcm1hdCAoc3ltbWV0cmljLWtleSwgcHVibGljLWtleSwgYXN5bW1ldHJpYy1r ZXktcGFpcik8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0K PGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SSBhc3N1bWUgdGhlIGlkZWEgaGVyZSBpcyB0byBtYWtlIGl0 IHBvc3NpYmxlIHRvIGhhdmUgY2hvaWNlcyBmb3IgdGhlIEFTTi4xIHR5cGVzIGhvbGRpbmcgdGhl IGtleXMuIElmIHRoaXMgZmxleGliaWxpdHkgZm9yIGZvcm1hdHMgaXMgbmVjZXNzYXJ5IEkgZG9u 4oCZdCBoYXZlIGFueSBvYmplY3Rpb24gdG8gdGhlbSBidXQgaGF2aW5nIGEgc2luZ2xlIGFncmVl ZCB0eXBlDQogZm9yIHRoZXNlIGRpZmZlcmVudCB1c2UgY2FzZXMgd291bGQgYWxzbyBzdWZmaWNl LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SSBiZWxpZXZlIGhlcmUgeW91J3JlIHJlZmVy cmluZyB0byB0aGUgMyBpbnN0YW5jZXMgb2YgbGluZXMgbGlrZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNw OyAmbmJzcDsgJm5ic3A7Jm5ic3A7bGVhZiZuYnNwO2tleSZuYnNwO3s8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsmbmJzcDtuYWNtOmRlZmF1bHQtZGVueS1hbGw7PGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7dHlwZSZuYnNwO2JpbmFyeTs8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsvL211c3QgJnF1b3Q7Li4va2V5LWZvcm1hdCZxdW90 OzsmbmJzcDsmbmJzcDtGSVhNRTogcmVtb3ZlIGNvbW1lbnQgaWYgYXBwcm9hY2ggb2s8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC4uLjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IH08 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5GV0lX LCB0aGUgd2hvbGUgJnF1b3Q7a2V5LWZvcm1hdCZxdW90OyBsZWFmIGlzIHN0aWxsIGJlaW5nIHN1 c3NlZCBvdXQgKHlvdXIgb3BpbmlvbiB3b3VsZCBiZSBoZWxwZnVsIG9uIHRoYXQgdGhyZWFkIGFz IHdlbGwpIGJ1dCwgc28gZmFyIGl0IHNlZW1zIHByb21pc2luZy4gJm5ic3A7VGhlIHJlYXNvbiB0 aGVzZSBsaW5lcyBhcmUgY29tbWVudGVkIG91dCBpcyBiZWNhdXNlIDEpIHRoZSBXRyBoYXNuJ3QN CiBjb21taXR0ZWQgdG8gdGhpcyBwYXRoIHlldCBhbmQgMikgSSBkaWRuJ3Qgd2FudCB0byB1cGRh dGUgYWxsIHRoZSBleGFtcGxlcyBpbiBhbGwgdGhlIGRyYWZ0cyAob3RoZXIgdGhhbiB0cnVzdHN0 b3JlIGFuZCBrZXlzdG9yZSkgdG8gYWRkIGEgJnF1b3Q7a2V5LWZvcm1hdCZxdW90OyBsZWFmIHVu dGlsIHRoZSBXRyBoYWQgbW9yZSBjb25zZW5zdXMgb24gdGhlICZxdW90O2tleS1mb3JtYXQmcXVv dDsgbGVhZnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JIGRvbid0IHVuZGVyc3RhbmQgeW91ciBsYXN0IGNvbW1l bnQvc2VudGVuY2UuICZuYnNwO0NhbiB5b3UgcHJvdmlkZSBhbiBleGFtcGxlPzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkJhbGF6cyZndDsgT2ssIHRoZW4g bGV04oCZcyB3YWl0IGZvciBXRyBkZWNpc2lvbi4gV2VsbCwgSSBqdXN0IHNheSB0aGF0IHRoZSBl YXJsaWVyIHdheXMgb2YgY29tbXVuaWNhdGluZyB0aGUga2V5IGZvcm1hdHMgd2VyZSBhZGVxdWF0 ZSBmcm9tIG15IHBvaW50IG9mIHZpZXcsIHdoaWNoIHdhcyB0aGF0IGluIGRvY3VtZW50YXRpb24g aXQgd2FzIHNhaWQgdGhhdCBmb3IgUlNBDQogdXNlIFJTQVByaXZhdGVLZXkgYW5kIGZvciBFQyB1 c2UgRUNQcml2YXRlS2V5LCBhbmQgc2ltaWxhcmx5IGZvciBvdGhlciB0eXBlcy4gSeKAmW0gYWxz byBvayB3aXRoIHRoZSBrZXktZm9ybWF0IGFwcHJvYWNoIGlmIHByZWZlcnJlZCBieSB0aGUgV0cu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JbiBlYXJsaWVyIHZlcnNpb25z OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgZGVzY3JpcHRpb248L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmcXVvdDtUaGUgdmFsdWUgb2YgdGhlIGJpbmFyeSBrZXkuJm5ic3A7IFRo ZSBrZXkncyB2YWx1ZSBpczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGludGVycHJldGVkIGJ5IHRoZSAnYWxnb3JpdGhtJy4mbmJzcDsg Rm9yIGV4YW1wbGUsIGEgRFNBIGtleTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlzIGFuIGludGVnZXIsIGFuIFJTQSBrZXkgaXMgcmVw cmVzZW50ZWQgYXMgUlNBUHJpdmF0ZUtleTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFzIGRlZmluZWQgaW48c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzgwMTciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPlJGQyA4MDE3 PC9zcGFuPjwvYT4sDQogYW5kIGFuIEVDQyBrZXkgaXMgcmVwcmVzZW50ZWQgYXM8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBFQ1ByaXZh dGVLZXkgYXMgZGVmaW5lZCBpbjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTkxNSI+ PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+UkZDDQogNTkxNTwvc3Bhbj48L2E+LiZxdW90Ozwv c3Bhbj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlllcywgdGhlIHByZXZpb3Vz IHdheSAoZXhhbXBsZSBhYm92ZSkgd2FzIGFkZXF1YXRlLCBidXQgSSBiZWxpZXZlIHRoZSBuZXcg d2F5IChpLmUuIHVzaW5nIGEga2V5LWZvcm1hdCBsZWFmKSBpcyBiZXR0ZXIgYXM6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+MSkgaXQgZW5hYmxlcyB0aGUg YSBrZXktdHlwZSAoZS5nLiwgYSBzeW1tZXRyaWMga2V5KSBkbyBiZSBleHByZXNzZWQgaW4gZGlm ZmVyZW50IHdheXMgYXMgbmVlZGVkIChPY3RldFN0cmluZyB2cy4mbmJzcDtPbmVTeW1tZXRyaWNL ZXkgdnMuJm5ic3A7RW5jcnlwdGVkRGF0YSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4yKSBpdCBNQVkg KGhhdmVuJ3QgdHJpZWQgdG8gbW9kZWwgaXQgeWV0KSBiZSBhYmxlIHRvIHN1cHBvcnQgZW5jb2Rp bmcgdmFyaWF0aW9ucyAoREVSIHZzIFBFTSwgYW5kIENNUyB2cy4gbXVsdGktcGFydCBQRU0pPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+MykgaXQgZGVjb3VwbGVzIHRoZSBwYXJ0IHRoYXQgd2UgYXJlIHN0 dWNrIG9uIChpLmUuLCB0aGUgJ2FsZ29yaXRobScgbm9kZSkgYW5kIGl0IGJlaW5nIGZhY3RvcmVk LW91dCBtYXkgcHJvdmlkZSBtb3JlIGZsZXhpYmlsaXR5IGluIHRoYXQgZGVmaW5pdGlvbi48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGUgV0cgaGFzbid0 IGRpc2N1c3NlZCBrZXktZm9ybWF0IHlldC4gJm5ic3A7QWJvdmUgaXMgdGhlIGZpcnN0IGZvcmF5 IGludG8gaXQuLi5kbyB0aGVzZSBhcmd1bWVudHMgc291bmQgY29tcGVsbGluZz88bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGJyPg0KPGJyPg0KPG86cD48L286 cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPGRpdiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW4iPjIuPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+YXR0cmlidXRlcyBpbiBhc3ltbWV0cmlj LWtleS1wYWlyLXdpdGgtY2VydChzKS1ncm91cGluZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPGRpdiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+SSB0aGluayBhdHRyaWJ1dGVzIHNob3VsZCBiZSBrZXB0IG9wdGlvbmFsLiBJZiB0aGVyZSBp cyBhbnl0aGluZyBlbHNlIGJlc2lkZXMgc3ViamVjdCBzZWVuIG1hbmRhdG9yeSBtYXliZSBpdCBz aG91bGQgYmUgZXh0cmFjdGVkIG91dCBmcm9tIGF0dHJpYnV0ZXMgYW5kIGJlIHNwZWxsZWQgb3V0 IGEgc2VwYXJhdGUgbGVhZiwgYnV0IEkgZG9u4oCZdCB0aGluayB0aGVyZSBpcy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPkkgYmVsaWV2ZSBoZXJlIHlvdSdyZSByZWZlcnJpbmcgdG8gdGhl IDIgaW5zdGFuY2VzIG9mIGxpbmVzIGxpa2U6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsmbmJzcDtsZWFmJm5ic3A7YXR0cmlidXRlcyZuYnNwO3s8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7dHlwZSZuYnNwO2JpbmFyeTsmbmJzcDsv LyBGSVhNRTogZG9lcyB0aGlzIG5lZWQgdG8gYmUgbWFuZGF0b3J5Pzxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLi4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyB9PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj5UaGVzZSBhcmUgaW4gdGhlICZxdW90O2dlbmVyYXRlLWNlcnRpZmlj YXRlLXNpZ25pbmctcmVxdWVzdCZxdW90OyBhY3Rpb25zIGZvdW5kIGluc2lkZSB0aGUmbmJzcDth c3ltbWV0cmljLWtleS1wYWlyLXdpdGgtY2VydChzKS1ncm91cGluZy48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkht bW0sIGFyZSB5b3UgY2xhaW1pbmcgdGhhdCAmcXVvdDthdHRyaWJ1dGVzJnF1b3Q7IGFyZSBub3Qg cmVxdWlyZWQgaW4gb3JkZXIgdG8gZ2VuZXJhdGUgYSBDU1I/ICZuYnNwO0kgdGhpbmsgdGhlIENT UiBpdHNlbGYgTVVTVCBoYXZlIGF0dHJpYnV0ZXMgKHJpZ2h0Pykgc28sIGlmIG5vdCBzcGVjaWZp ZWQsIHdoYXQgZGVmYXVsdCB2YWx1ZXMgYXJlIHVzZWQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkJhbGF6cyZndDsgSW48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzI5ODYjc2VjdGlvbi0zIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5SRkMy OTg2PC9zcGFuPjwvYT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+dGhlIGF0dHJpYnV0ZXMNCiBhcmUgc2FpZCB0byBiZSBvcHRpb25hbC4gV2UganVzdCBu ZWVkIHRoZSBzdWJqZWN0IEROIGFzIG1hbmRhdG9yeSwgZG9u4oCZdCB3ZT88bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHByZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxLiBB IENlcnRpZmljYXRpb25SZXF1ZXN0SW5mbyB2YWx1ZSBjb250YWluaW5nIGEgc3ViamVjdDxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGlzdGluZ3Vp c2hlZCBuYW1lLCBhIHN1YmplY3QgcHVibGljIGtleSwgYW5kIDxiPm9wdGlvbmFsbHkgYTwvYj48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNl dCBvZiBhdHRyaWJ1dGVzPC9iPiBpcyBjb25zdHJ1Y3RlZCBieSBhbiBlbnRpdHkgcmVxdWVzdGlu ZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY2Vy dGlmaWNhdGlvbi48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhhbmsgeW91LiAmbmJzcDtJJ3ZlIHJlbW92ZWQg dGhlc2UgdG8gY29tbWVudHMsIHRodXMgbGVhdmluZyB0aGUgJnF1b3Q7YXR0cnVidHV0ZSZxdW90 OyBub2RlcyBhcyBOT1QgbWFuZGF0b3J5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjUuMHB0 O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6MS41aW47bWFy Z2luLWJvdHRvbTouMDAwMXB0O3RleHQtaW5kZW50Oi0uMjVpbiI+DQozLjxzcGFuIHN0eWxlPSJm b250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNl cmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPlBTSyBhbmQgcmF3IHB1Ymxp YyBrZXlzPG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxk aXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPlRoZSB1c2UgY2FzZSBvZiBQU0sgYW5kIHJhdyBwdWJsaWMga2V5 cyBhcmUgbm90IHRoZSBtb3N0IHVyZ2VudCBpbiBteSBvcGluaW9uIHdoaWNoIG5vdyBzbG93cyBh IGJpdCB0aGUgcHJvZ3Jlc3Mgb2YgdGhlc2UgZHJhZnRzLCBidXQgbGV04oCZcyBtYWtlIGFuIGF0 dGVtcHQgdG8gZmluYWxpemUgdGhlbS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+QWdyZWVkLCBidXQg dGhleSBhcmUgbGVnYWwgZm9yIFRMUyBhbmQgYSBXRyBtZW1iZXIgc3RhdGVkIHRoYXQgdGhleSB3 ZXJlIG5lZWRlZCBpbiBvcmRlciB0byBzdXBwb3J0IGFub3RoZXIgSUVURiBXRydzIGVmZm9ydHMu ICZuYnNwO0EgcXVpY2sgcmVzb2x1dGlvbiB3b3VsZCBiZSBiZXN0ITxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5i c3A7PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5yYXctcHVibGljLWtleXM6IEkg c2VlIHRoZXNlIHdlcmUgYWRkZWQgZHVlIHRvIFJGQyA3MjUwIGFuZCA4NDQ2LiBJIGd1ZXNzIGlu IHRydXN0c3RvcmUgdGhpcyBpcyBhIHNlcGFyYXRlIGNvbnRhaW5lciB0byBkaXN0aW5ndWlzaCBm cm9tIFNTSCBob3N0IGtleXMuIEZvciBjb25maWd1cmluZyB0aGUgcHJpdmF0ZSBwYXJ0IEkgdGhp bmsga2V5c3RvcmUgYWxyZWFkeSBnaXZlcw0KIHN1cHBvcnQgZm9yIHRoaXMgY2FzZSB3aXRoIHRo ZSBhc3ltbWV0cmljIGtleSAody9vIGNlcnQpIGFuZCBpbiB0aGUgY2xpZW50L3NlcnZlciBkcmFm dHMgS2VudOKAmXMgcHJvcG9zYWwgY291bGQgYmUgdXNlZCAoSSByZXBsYWNlZCByYXcgcHVibGlj IGtleSB3aXRoIGV4aXN0aW5nIHR5cGUsIHNob3VsZG7igJl0IHRoYXQgYmUgdXNlYWJsZSBzdHJh aWdodCBhd2F5Pyk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBj bGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwv c3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Jm5i c3A7ICZuYnNwOyZuYnNwO2NvbnRhaW5lciZuYnNwOyZsdDtjbGllbnQtaWRlbnRpdHkmbmJzcDtv ciZuYnNwO3NlcnZlci1pZGVudGl0eSZndDsmbmJzcDt7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIGNsYXNzPSJhcHBsZS10 YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4mbmJzcDsgJm5ic3A7ICZu YnNwOyBjaG9pY2UgYXV0aC10eXBlIHs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDt1c2VzJm5ic3A7a3M6bG9jYWwtb3Ita2V5c3RvcmUtZW5kLWVudGl0eS1jZXJ0LXdp dGgta2V5LWdyb3VwaW5nOzxicj4NCjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7dXNlcyZuYnNwO2tzOmxvY2FsLW9yLWtleXN0b3JlLWFzeW1tZXRyaWMta2V5LWdyb3VwaW5n Ozxicj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SSB3 b3VsZCBhbHNvIHByZWZlciBpZiB0aGVzZSBjaG9pY2VzIGFyZSBpbiBmZWF0dXJlcywgc28gdGhh dCBhbiBpbXBsZW1lbnRhdGlvbiBjYW4gY2hvb3NlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+VG8geW91ciBmaXJzdCBzZW50ZW5jZSwgeWVzLCAmcXVvdDtwc2smcXVvdDsgKGFuZCAmcXVv dDtyYXctcHVibGljLWtleSZxdW90OykgYXJlIHRvcC1sZXZlbCBub2RlcyBpbiB0cnVzdHN0b3Jl LCBhcyBjYW4gYmUgc2VlbiBoZXJlICg8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1uZXRjb25mLXRydXN0LWFuY2hvcnMtMDcjc2VjdGlvbi0yLjEiPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLW5ldGNvbmYtdHJ1c3QtYW5jaG9ycy0wNyNzZWN0aW9uLTIuMTwvc3Bhbj48L2E+KS4NCiAm bmJzcDsgTm90ZSwgdGhlIHRydXN0LWFuY2hvcnMgZHJhZnQgYWNjaWRlbnRhbGx5IGRvZXNuJ3Qg aW5jbHVkZSB0aGUgaWV0Zi10cnVzdHN0b3JlLnlhbmcgbW9kdWxlLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhl IGJvZHkgb2YgeW91ciBjb21tZW50IGFib3ZlIHNlZW1zIHRvIGJlIGFib3V0IHN1cHBvcnRpbmcg dGhlIHNlY3JldC1oYWxmIG9mIHRoZSBQU0sgYW5kIFJQSyB3aXRoaW4gdGhlIEtleXN0b3JlLiAm bmJzcDtJJ3ZlIHJhaXNlIHRoaXMgcXVlc3Rpb24gYSBjb3VwbGUgdGltZXMgcHJldmlvdXNseSB0 byBIZW5rICh3aG8ncyBhc2tpbmcgZm9yIHRoZSBQU0svUlBLIGFkZCksDQogYnV0IGhlJ3Mgbm90 IHJlc3BvbmRlZCB5ZXQgYXMgdG8gaWYgZG9pbmcgc28gaXMgaW1wb3J0YW50ICh0aG91Z2ggSSBj YW4gb25seSBpbWFnaW5lIHRoYXQgaXQgZG9lcykuICZuYnNwOyBXaXRoIHRoYXQgc2FpZCwgSSB0 aGluayB5b3VyIFlBTkcgc25pcHBldCBpcyBtZWFudCB0byBiZSBpbiBpZXRmLXRscy1zZXJ2ZXIg YW5kIGlldGYtdGxzLWNsaWVudCBtb2R1bGVzIChyaWdodD8pLiAmbmJzcDtJJ20gaGF2aW5nIGEg aGFyZCB0aW1lIGZvbGxvd2luZyB0aGUgJnF1b3Q7SQ0KIHJlcGxhY2VkIHJhdyBwdWJsaWMga2V5 IHdpdGggZXhpc3RpbmcgdHlwZSwgc2hvdWxkbuKAmXQgdGhhdCBiZSB1c2VhYmxlIHN0cmFpZ2h0 IGF3YXk/JnF1b3Q7IGNvbW1lbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+QmFsYXpzOiBZb3UgaGFkIGFuIGV4YW1wbGUgZWFy bGllciBpbiBhbiBlbWFpbCBmcm9tIDEwLzgvMjAxOSwgd2hpY2ggaXMgYWJvdXQgdGhlIFRMUyBj bGllbnQvc2VydmVyIG1vZGVscy4gQmVsb3csIHlvdSBhcmUgcmVmZXJyaW5nIHRvIHNvbWUgcG9z c2libHkgbmV3IGdyb3VwaW5ncyB0aGF0IHlvdSB3YW50ZWQgdG8gcHJvcG9zZS4gSSBkb27igJl0 IHVuZGVyc3RhbmQNCiB0aG91Z2ggd2h5IHlvdSBtZW50aW9uZWQgdGhlc2UgbmV3IGdyb3VwaW5n cyBzaW5jZSDigJhrczpsb2NhbC1vci1rZXlzdG9yZS1hc3ltbWV0cmljLWtleS1ncm91cGluZ+KA mSAoUlBLKSBhbmQgc29tZXRoaW5nIG5ldyB0aGF0IGp1c3QgcmVmZXJzIHRvIGEga2V5c3RvcmUg c3ltbWV0cmljIGtleSwgc3VjaCBhcyDigJhrczpsb2NhbC1vci1rZXlzdG9yZS1zeW1tZXRyaWMt a2V5LWdyb3VwaW5n4oCZIChQU0spIHNob3VsZCBiZSBnb29kLiBUaGlzIGxhdHRlcg0KIEkgdGhp bmsgd291bGQgYmUgYSBuZXcgZ3JvdXBpbmcsIGJ1dCB3aXRoIGV4aXN0aW5nIHRlcm1pbm9sb2d5 LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxpPkFsbCwg bG9va2luZyBhdCZuYnNwO2lldGYtdGxzLWNsaWVudC55YW5nIGFuZCZuYnNwO2lldGYtdGxzLXNl cnZlci55YW5nLCBhZGRpbmcgdGhlIGFiaWxpdHkgdG8gY29uZmlndXJlIHRoZSAmcXVvdDtwcml2 YXRlJnF1b3Q7IGhhbGYgb2YgYSBQU0sgb3IgcmF3IHB1YmxpYyBrZXkgd291bGQgYmUgc29tZXRo aW5nIGxpa2U6PC9pPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxpPiZuYnNwOzwvaT48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPjxpPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOzwvaT48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+PGk+Jm5ic3A7PC9pPjwvc3Bhbj48aT5PTEQ8L2k+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj48aT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDs8L2k+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PjxpPiZuYnNwOzwvaT48L3NwYW4+PGk+Jm5ic3A7ICZuYnNwOyZuYnNwO2NvbnRhaW5lciAmbHQ7 Y2xpZW50LWlkZW50aXR5Jm5ic3A7b3ImbmJzcDtzZXJ2ZXItaWRlbnRpdHkmZ3Q7IHs8L2k+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFy Z2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPjxpPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvaT48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+PGk+Jm5ic3A7PC9pPjwvc3Bhbj48aT4mbmJzcDsgJm5ic3A7ICZuYnNw OyZuYnNwO3VzZXMmbmJzcDtrczpsb2NhbC1vci1rZXlzdG9yZS1lbmQtZW50aXR5LWNlcnQtd2l0 aC1rZXktZ3JvdXBpbmc7PC9pPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNw YW4iPjxpPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvaT48L3NwYW4+PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PGk+Jm5ic3A7PC9pPjwvc3Bhbj48aT5ORVc8 L2k+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj48aT4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L2k+PC9zcGFuPjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxpPiZuYnNwOzwvaT48L3NwYW4+PGk+Jm5ic3A7ICZuYnNw OyZuYnNwO2NvbnRhaW5lciZuYnNwOyZsdDtjbGllbnQtaWRlbnRpdHkmbmJzcDtvciZuYnNwO3Nl cnZlci1pZGVudGl0eSZndDsmbmJzcDt7PC9pPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIGNs YXNzPSJhcHBsZS10YWItc3BhbiI+PGk+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 PC9pPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48aT4mbmJzcDs8 L2k+PC9zcGFuPjxpPiZuYnNwOyAmbmJzcDsgJm5ic3A7IGNob2ljZSBhdXRoLXR5cGUgezwvaT48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPjxpPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvaT48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+PGk+Jm5ic3A7PC9pPjwvc3Bhbj48aT4mbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7dXNlcyZuYnNwO2tzOmxvY2FsLW9yLWtleXN0b3JlLWVuZC1lbnRp dHktY2VydC13aXRoLWtleS1ncm91cGluZzs8YnI+DQo8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNw YW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO3VzZXMmbmJzcDtrczpsb2NhbC1vci1rZXlzdG9yZS1yYXctcHVibGljLWtl eS1ncm91cGluZzs8YnI+DQo8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3Vz ZXMmbmJzcDtrczpsb2NhbC1vci1rZXlzdG9yZS1wcmUtc2hhcmVkLWtleS1ncm91cGluZzs8L2k+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkFoLCBub3cg SSB1bmRlcnN0YW5kLCBJIGFuZCBhZ3JlZSB0aGF0IHRoaXMgc2VlbXMgbGlrZSB0aGUgcmlnaHQg d2F5IHRvIGRvIGl0LCBidXQgc2VlIGJlbG93Li4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UbyB5b3VyIGxhc3Qgc2VudGVuY2UgcmVnYXJkaW5nIGZl YXR1cmVzLCBjb3VsZCB5b3UgcHJvdmlkZSBhbiBleGFtcGxlIG9mIHdoYXQgeW91IG1lYW4/PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+Y29udGFpbmVyJm5ic3A7Jmx0O2NsaWVudC1pZGVudGl0eSZuYnNwO29y Jm5ic3A7c2VydmVyLWlkZW50aXR5Jmd0OyZuYnNwO3s8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJz cDsmbmJzcDsmbmJzcDsgY2hvaWNlIGF1dGgtdHlwZSB7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO21hbmRhdG9yeSB0cnVlOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBjYXNlIGNlcnRpZmljYXRlIHs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaWYt ZmVhdHVyZSB4NTA5LWNlcnRpZmljYXRlLWF1dGg7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3Vz ZXMmbmJzcDtrczpsb2NhbC1vci1rZXlzdG9yZS1lbmQtZW50aXR5LWNlcnQtd2l0aC1rZXktZ3Jv dXBpbmc7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IH08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgY2FzZSByYXctcHVibGljLWtleSB7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGlmLWZlYXR1cmUgcmF3LXB1YmxpYy1rZXktYXV0aDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj4mbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7dXNlcyZuYnNwO2tzOmxvY2FsLW9yLWtleXN0b3JlLWFzeW1tZXRyaWMta2V5LWdy b3VwaW5nOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB9PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGNhc2UgcHNrIHs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaWYtZmVhdHVyZSBwc2st YXV0aDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dXNlcyZuYnNwO2tzOmxvY2FsLW9yLWtleXN0 b3JlLXN5bW1ldHJpYy1rZXktZ3JvdXBpbmc7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+QmV0dGVyISAmbmJzcDtUaGlzIHVzZXMgdGhlIGV4aXN0aW5nIGdyb3VwaW5ncyAo ZS5nLiwmbmJzcDtrczpsb2NhbC1vci1rZXlzdG9yZS1hc3ltbWV0cmljLWtleS1ncm91cGluZykg d2hlcmVhcyB0aGUgYWJvdmUgcHJvcG9zYWwgZGVmaW5lZCBuZXcgb25lcy4gJm5ic3A7KHNlZSBH aXRIdWIgZm9yIGxhdGVzdCBmaWxlcywgdGhvdWdoIHRoZSBjb21taXQgaXMgbGFyZ2VyIHRoYW4g aXQgc2hvdWxkDQogYmUpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+SGVuaywgd2hhdCBkbyB5b3UgdGhpbms/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPkkgYXNzdW1lIHRoZXNlIGZlYXR1cmVzIHdvdWxkIHRoZW4gbmVlZCB0byBiZSBkZWZp bmVkIGluIHRoZSBUTFMgY2xpZW50L3NlcnZlciBkcmFmdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ WWVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGJyPg0KPGJyPg0K PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+UFM6 IG5vbmUgb2YgdGhpcyBnb2VzIHRvIHRoZSBGSVhNRSBpbiB0aGUgaWV0Zi1jcnlwdG8tdHlwZXMu ICZuYnNwO0kgaGFkIHByZXZpb3VzbHkgYXNrZWQgSGVuayB0byBwcm92aWRlIHNvbWUgdGV4dCBo ZXJlIGFzIHdlbGwgYnV0LCBhcHBhcmVudGx5LCBsaWtlIGFsbCBvZiB1cyBhdCB0aGlzIHRpbWUs IGhlJ3MgYmVlbiBidXN5ITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ Jm5ic3A7cHNrOiBnaXZlbiB0aGF0IHRoZSBhc3ltbWV0cmljIGtleXMgd2l0aG91dCBjZXJ0cyB3 ZXJlIGNvdmVyZWQgYnkgaG9zdCBrZXlzIGFuZCByYXcgcHVibGljIGtleXMsIEkgdGhpbmsgcHNr IHNob3VsZCBvbmx5IGJlIHN5bW1ldHJpYyBrZXlzLiBTeW1tZXRyaWMga2V5cyBhcmUgdGhlbiBz ZW5zaXRpdmUvc2VjcmV0IGRhdGEgYW5kIGFzIHN1Y2ggSSBiZWxpZXZlIHRoZXkNCiBzaG91bGQg b25seSBiZSByZWZlcmVuY2VkIGZyb20ga2V5c3RvcmUuIFNlZWluZyB0aGVtIGluIHRydXN0c3Rv cmUgd2FzIHVuZXhwZWN0ZWQgZm9yIG1lLiBXaGVuIGl0IGNvbWVzIHRvIHRoZWlyIHVzZSwgY2xp ZW50cyBhbmQgc2VydmVycyBzaG91bGQgYmUgZXh0ZW5kZWQgd2l0aCBmb2xsb3dpbmcgY29uZmln dXJhdGlvbiAoYW5kIEkgYXNzdW1lIHdlIHRhbGsgb2YgVExTIGNsaWVudHMgYW5kIHNlcnZlcnMg b25seSk6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gY2xhc3M9 ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+ PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPiZuYnNwOyAm bmJzcDsmbmJzcDtjb250YWluZXImbmJzcDsmbHQ7Y2xpZW50LWlkZW50aXR5Jm5ic3A7b3ImbmJz cDtzZXJ2ZXItaWRlbnRpdHkmZ3Q7Jm5ic3A7ezxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNw YW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Y2hvaWNlIGF1dGgtdHlwZSB7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBjbGFz cz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bh bj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3VzZXMmbmJzcDtrczpsb2NhbC1vci1rZXlzdG9y ZS1lbmQtZW50aXR5LWNlcnQtd2l0aC1rZXktZ3JvdXBpbmc7PGJyPg0KPHNwYW4gY2xhc3M9ImFw cGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt1c2VzJm5ic3A7a3M6bG9jYWwtb3Ita2V5c3RvcmUtYXN5 bW1ldHJpYy1rZXktZ3JvdXBpbmc7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7dXNlcyZuYnNwO2tzOjxpPmxvY2FsLW9yLWtleXN0b3JlLXN5bW1ldHJpYy1r ZXktZ3JvdXBpbmc8L2k+OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj5MYXR0ZXIgZ3JvdXBpbmcgd291bGQgYmUgYSBuZXcgb25l LCBidXQgaXQgd291bGQgdXNlIGV4aXN0aW5nIGNvbnN0cnVjdHMgYW5kIHRlcm1zIGZyb20ga2V5 c3RvcmUuIEkgZG9u4oCZdCB0aGluayB3ZSBuZWVkIG5ldyBvbmVzLiBTZWxlY3RlZCBjaXBoZXIg c3VpdGVzIHdpbGwgbmVlZCB0byBoYXZlIFBTSyBpbiB0aGVtIGZvciB1c2luZyBzeW1tZXRyaWMg a2V5IChzaW1pbGFyDQogbWF0Y2ggbmVlZGVkIGZvciB0aGUgb3RoZXJzKS4gTm90ZSB0aGF0IHN5 bW1ldHJpYyBrZXlzIGNhbiBiZSB1c2VkIGZvciBvdGhlciBjYXNlcyB0aGFuIFRMUyBQU0ssIGZv ciBleGFtcGxlIFNOTVB2MyBVU00uIEFnYWluLCBmZWF0dXJlcyB3b3VsZCBiZSBuZWNlc3Nhcnkg KHRob3NlIGNvdWxkIGJlIHNheWluZyB4LjUwOSBvciByYXctcHVibGljLWtleSBvciBwc2spLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkNvcnJlY3QsIEkgc2FpZCB0aGUg c2FtZSAodGhhdCBQU0tzIGFyZSBlc3NlbnRpYWxseSBzeW1tZXRyaWMga2V5cykgYmVmb3JlIGFz IHdlbGwuICZuYnNwO1JlZ2FyZGluZyBvbmx5IGJlaW5nIHJlZmVyZW5jZWQgdG8ga2V5c3RvcmUs IHdoeSBub3QgYWxzbyBzdXBwb3J0IHRoZW0gYmVpbmcgbG9jYWwtZGVmaW5pdGlvbnMgdG9vPyAm bmJzcDtDZXJ0YWlubHkgbm90IGEgcHJvYmxlbSBpZg0KIGVuY3J5cHRlZCBhbmQsIGV2ZW4gd2hl biBub3QgZW5jcnlwdGVkLCB0aGVuIHRoZXkgY2FuIGJlICZxdW90O3Byb3RlY3RlZCZxdW90OyBi eSBOQUNNLWxpa2UgbWVjaGFuaXNtcywgcmlnaHQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+QmFsYXpzJmd0OyBMb2NhbCBkZWZpbml0aW9ucyBhcmUgb2sg dG9vIHRoYXTigJlzIHdoeSBJIHVzZWQgYSBoeXBvdGhldGljYWwgZ3JvdXBpbmcgbmFtZSAmbmJz cDtrczo8Yj48aT5sb2NhbDwvaT48L2I+PGk+LW9yLWtleXN0b3JlLXN5bW1ldHJpYy1rZXktZ3Jv dXBpbmcuPC9pPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5Tb3JyeSwgSSBnbG9zc2VkIG92ZXIgdGhl ICZxdW90O2xvY2FsLSZxdW90OyBwcmVmaXggaW4geW91ciBlYXJsaWVyIHN0YXRlbWVudC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JIGFncmVlIHRoYXQg UFNLcyBzaG91bGQgYmUgaW4gS2V5c3RvcmUgd2hlbiB1c2VkIGZvciBjbGllbnQtaWRlbnRpdHkv c2VydmVyLWlkZW50aXR5IG5vZGVzLi4uIChtb3JlIGJlbG93KTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7IFdoeSB3YXMvaXMg c2VlaW5nIHRoZW0gaW4gdHJ1c3RzdG9yZSBhIHN1cnByaXNlLCBwZXJoYXBzIGJlY2F1c2UgdGhl eSdyZSBub3QgZW5jcnlwdGFibGUgdGhlcmU/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+QmFsYXpzJmd0OyBXaGVuIFBTS3MgYXJlIHVzZWQgdGhlbiBib3Ro IGNvbW11bmljYXRpbmcgZW5kcyB1c2UgdGhlIHNoYXJlZCBrZXkgZm9yIHNpZ25pbmcgYW5kIHZl cmlmeWluZyBtZXNzYWdlcy4gVGhlbiBvbmUgY29uZmlndXJhdGlvbiBzZWVtcyBlbm91Z2ggdGhh dCBpcyBlaXRoZXIgbG9jYWwgb3IgZnJvbSBrZXlzdG9yZSwgd2h5IHdvdWxkIGl0IGJlIG5lY2Vz c2FyeQ0KIHRvIHNldCBpdCB1cCB5ZXQgYW5vdGhlciB0aW1lIGZvciB2ZXJpZmljYXRpb24gZnJv bSBsb2NhbCBvciB0cnVzdHN0b3JlPyBUaGlzIHdvdWxkIG1lYW4gdGhlcmUgaXMgbm8gbmVlZCBm b3IgYSBQU0sgb3B0aW9uIHdoZW4gY29uZmlndXJpbmcgaG93IHRvICZuYnNwO3ZlcmlmeSB0aGUg cGVlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5jb250 YWluZXImbmJzcDsmbHQ7Y2xpZW50LWF1dGhlbnRpY2F0aW9uJm5ic3A7b3ImbmJzcDtzZXJ2ZXIt YXV0aGVudGljYXRpb24mZ3Q7Jm5ic3A7ezxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNw OyZuYnNwOyBjaG9pY2UgYXV0aC10eXBlIHs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJz cDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7bWFuZGF0b3J5IHRydWU7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNh c2UgY2VydGlmaWNhdGUgezxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpZi1mZWF0dXJl IHg1MDktY2VydGlmaWNhdGUtYXV0aDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY29u dGFpbmVyIGNhLWNlcnRzIHs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHByZSBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7dXNlcyB0czpsb2NhbC1vci10cnVzdHN0b3JlLWNlcnRzLWdyb3VwaW5nPC9zcGFu PjxvOnA+PC9vOnA+PC9wcmU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGNvbnRhaW5lciBzZXJ2ZXItY2VydHMgezxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cHJlIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNw OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDt1c2VzIHRzOmxvY2FsLW9yLXRydXN0c3RvcmUtY2VydHMtZ3JvdXBp bmc8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjYXNlIHJhdy1wdWJs aWMta2V5IHs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaWYtZmVhdHVyZSByYXctcHVi bGljLWtleS1hdXRoOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDt1c2VzJm5ic3A7a3M6IGxvY2FsLW9yLXRydXN0c3RvcmUtcmF3LXB1Yi1rZXlz LWdyb3VwaW5nPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IH08YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5ObyBuZWVk IGZvciBQU0sgY29uZmlnIHNpbmNlIGl0IGlzIGFscmVhZHkgY29uZmlndXJlZCBpbiBjbGllbnQv c2VydmVyLWlkZW50aXR5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5BY2suICZuYnNwOyAoc2VlIEdp dEh1YiBmb3IgbGF0ZXN0IGZpbGVzLCB0aG91Z2ggdGhlIGNvbW1pdCBpcyBsYXJnZXIgdGhhbiBp dCBzaG91bGQgYmUpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+QW5kLCBhcyBhIGJvbnVzLCBLZXlzdG9yZSBhbHJlYWR5IGRlZmluZXMgc3VwcG9ydCBmb3Ig ZW5jcnlwdGlvbiAodW5saWtlIFRydXN0c3RvcmUpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4m bmJzcDtPciB3aGF0IGlzIHRoZSByZWFzb25pbmcgd2h5IGl0IGlzIG5lY2Vzc2FyeSB0byBjb25m aWd1cmUgYSBQU0sgZnJvbSB0cnVzdHN0b3JlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5Tb21laG93 IEkgdGhvdWdodCB0aGF0IHdlcmUgYmVpbmcgdXNlZCBpbiBjb25jZXB0dWFsbHkgZGlmZmVyZW50 IHdheXMsIGJ1dCBJIHNlZSBub3cgdGhhdCdzIG5vdCByZWFsbHkgdGhlIGNhc2UuLi48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj5UaGFuayB5b3UsIEJhbGF6cywgdGhpcyBtZXNzYWdlIHdhcyBtb3N0IGhlbHBm dWwhICZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPktlbnQgLy8gY29udHJpYnV0b3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_AM0PR07MB51870B440CA86FD39E0926C883770AM0PR07MB5187eurp_-- From nobody Tue Nov 12 02:28:26 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B39A120026; Tue, 12 Nov 2019 02:28:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.248 X-Spam-Level: X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhHiHJA9MBYW; Tue, 12 Nov 2019 02:28:22 -0800 (PST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50114.outbound.protection.outlook.com [40.107.5.114]) (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 AC3CD120013; Tue, 12 Nov 2019 02:28:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UKGB+J75gve/VCqV+dhcBt9PyPWg7siOyKnfXMDoiKt0wsgu5DsByHsYgvDjl1hGjQawgEQvBzoC2dG/H5jHD/OFu8U5El6SNh7XEsVeCijBpRS/hhNODMIT13ddtCt38s4Ap7rRJc9VkIhnfir84MlhkSoIGj53CLDE1VWGO8qHM5NGvBtuRCyvLmOB/UXVr/dqzYomMdMKK0FlUGWrxmnKAv8/bzMQvQQ7imedw+zqtHOz15N6jkUAI1ErqmuQ8UcLVFtjj/fDNdPLruRlr36ZsthfNQY0R+5zPkSE8ERRH0tAulOLNcbB/TRBX16iBGpL7RJxF6TCOW8n4+7W3Q== 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=QK/eDUIYFxmjMJMuOm/TbBNYoWvkiiAimFum9iK2JKU=; b=LSYgX6XvdEbc0oFL/DJCyLB9DHbjoeLjJiApFFBJnHTlgqA74lSJ2CknWUxoNa+YftGw0nJyJApWkOV2NRO5PuwJKQyOKakDgv1XwoHqlZ06suomWSc6xwtbarIMNWIjVTpENoInpUl3nKzC0ftS8Yg4kC7HMrgddl5P/+fJurOhHu0AW4DfXcxCLutUp6BWA2LvY2LK/bU6SqC7gz2+2m4h8wrBYIAI95vfCEPcKXbpawJar0n8G6tiS0Q/P7ArXfN/70vc262IFcG5EPEdzHg+p1nfp7M1Sxqx9UxJ7+p2YD5lb6MsCpiVDaQtRpbG/sP5AmqrVneUWXvWWiTaiA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QK/eDUIYFxmjMJMuOm/TbBNYoWvkiiAimFum9iK2JKU=; b=mPHmNCnmxjAaSYe2SLekHKnwGSxtRuuCurVmEqVrtIOG5xmglxvZh9kjM5VjGSM/Ehvj7MNA44STBUe3iiLgrlfrXwtkljlZwE8uhZkizdRI6V8FhYW+OvsipzyCrZhUeUwzSTEMY/LfLXAgU0Nn/C70nrsBliwNAMf74gK8vPU= Received: from DB7PR07MB5147.eurprd07.prod.outlook.com (20.178.42.32) by DB7PR07MB6138.eurprd07.prod.outlook.com (20.178.108.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.16; Tue, 12 Nov 2019 10:28:17 +0000 Received: from DB7PR07MB5147.eurprd07.prod.outlook.com ([fe80::e5bf:72e6:a66c:401a]) by DB7PR07MB5147.eurprd07.prod.outlook.com ([fe80::e5bf:72e6:a66c:401a%3]) with mapi id 15.20.2451.018; Tue, 12 Nov 2019 10:28:17 +0000 From: tom petch To: "Rob Wilton (rwilton)" , Kent Watsen , Martin Bjorklund CC: "httpbis-chairs@ietf.org" , "netconf@ietf.org" Thread-Topic: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04 Thread-Index: AQHVmUPlJ24iWD11Rk2SN1Li36cNJQ== Date: Tue, 12 Nov 2019 10:28:16 +0000 Message-ID: <025901d59943$dc7659e0$4001a8c0@gateway.2wire.net> References: <0100016e466ae626-e9821117-8286-4f26-bc91-284d7dcaa453-000000@email.amazonses.com> <20191107153342.gqtgyseqyvsppcul@anna.jacobs.jacobs-university.de> <0100016e46e53383-ec073c86-f9d4-4358-9d78-b337f9cd9a58-000000@email.amazonses.com> <20191107.205057.1889050828820990344.mbj@tail-f.com> <0100016e48af524e-96c5b2d0-6b19-4e26-b3b6-8bb8021851d8-000000@email.amazonses.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0184.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a::28) To DB7PR07MB5147.eurprd07.prod.outlook.com (2603:10a6:10:68::32) authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: Microsoft Outlook Express 6.00.2800.1106 x-originating-ip: [86.139.211.103] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ffd19823-973a-4973-ae23-08d7675b07d3 x-ms-traffictypediagnostic: DB7PR07MB6138: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 021975AE46 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(136003)(376002)(39860400002)(346002)(199004)(189003)(51444003)(13464003)(14496001)(52116002)(1556002)(76176011)(386003)(6506007)(81686011)(102836004)(62236002)(44716002)(66446008)(64756008)(66556008)(66946007)(81816011)(7736002)(4720700003)(66476007)(305945005)(86362001)(186003)(26005)(50226002)(6246003)(478600001)(81166006)(4326008)(6436002)(8936002)(44736005)(966005)(61296003)(6512007)(9686003)(6486002)(256004)(14444005)(110136005)(446003)(6306002)(25786009)(66066001)(8676002)(5660300002)(14454004)(486006)(99286004)(476003)(81156014)(229853002)(3846002)(6116002)(316002)(54906003)(2906002)(71200400001)(71190400001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB7PR07MB6138; H:DB7PR07MB5147.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: mEwjscmWSfs2FNoLdQsVAK51ckJIxAHTcdrwpHfU672NVskuT/SVTBnpGimy1IFuE615OWrkweO2YO91nowRtvrkaz2asVTjAFhHLLfdS8SJozVn7+ulmr608j9YmJ5hUBAoYlBGQfNL7DqtJvtTjzSKA+Hr+NMISAPetPTDR+Psxm32dWFRtVjxYfHY9WiUkN2O8fcEIsevrLXrF5GQeYJBPlAo6bQlUWnQFqVHH9bIK71YgP8O310RbbKrFDi+PuSh1OZItCMYCUKhX3Us8qWYDayioQKgAiZJsv4bU8BYqamlR/pir8CKVjeGtU14qBv6bCFOMHoI+XZXhgnQo8JBuMDAVT4y0za/Xi2Uv+N4AUoRQqCDvDn3aGSTQ1ZJLJXQ39cNZvDhnnOsIBEAa0/nr8jxHb4e3se1kqbF2lhXKwmUvkJPRgrVzr1OEvc2 x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7FCD09137714B749B4CF737F0B974EED@eurprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: ffd19823-973a-4973-ae23-08d7675b07d3 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2019 10:28:16.9871 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 1mh1dvB2YtTW81lgiWnqRYAFIqWPSdyHBqDwVXtfHTWPSoTnJCij6FuKF92b9n2O0Hmxm0yzknQgqpKU9uvwBw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB6138 Archived-At: Subject: Re: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04 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, 12 Nov 2019 10:28:24 -0000 ----- Original Message ----- From: "Rob Wilton (rwilton)" Sent: Monday, November 11, 2019 2:26 PM Hi Kent, I broadly agree with Martin here, in that I think that we want to get all of the "Client-Server" drafts finished. Defining groupings in one place is probably beneficial and I as such as support the adoption of this draft, but not if it going to cause the other drafts that depend on these modules to end up being blocked for another 8 months, or a year. Well, my view of groupings and similar constructs in a variety of languages is that they are mostly harmful, making the code more complex and harder to understand, requiring a reader to keep having to branch off and look up something else somewhere else. They are beneficial only when they encompass a well-defined meaningful entity, object, idea, collection of data. When the boundaries are ill-defined, I find them harmful. What I see is the same 'n' lines of code, where 'n' is a small, even very small, integer, appearing in more than one place and then those 'n' lines being taken out of context, given a wrapping, a name, a separate evolutionary path just to save < On Behalf Of Kent Watsen Sent: 08 November 2019 01:45 To: Martin Bjorklund Cc: httpbis-chairs@ietf.org; netconf@ietf.org Subject: Re: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04 Hi Martin, I think it is quite clear that the WG doesn't want more delays. Is it? I only know that Balazs K. wishes to have the first three drafts (crypto-types, truststore, and keystore) completed soon. The Nokia/BBF folks were interested in netconf-server, but forked long ago. Otherwise, I'm unaware of anyone stating a preference. For myself, I only hope to achieve a good result. So I think that either we simply don't add this grouping *at this point*, and define the necessary nodes in the higher-level modules, even though it is not perfect; or we define the "restful" module with these groupings, even though that is also perhaps not perfect. ietf-restful-client and ietf-restful-server sound nice, but not so much in a stack: tcp-server-parameters : { ... }, tls-server-parameters : { ... }, restful-server-parameters : { .... }, <---- end-user says "what's that?" restconf-server-parameters : { ... } or (for https-notif) tcp-client-parameters : { ... }, tls-client-parameters : { ... }, restful-client-parameters : { .... } <---- end-user says "what's that?" Actually, the above is purposely inaccurate. If you recall, we switched to having container-less groupings, thus the consuming module can name the container whatever it wants, so the net-net is no impact other than changing the import and uses statements. Though I still don't know why we should do even this, given the lack of any response to my Oct 30th message. Kent // contributor ------------------------------------------------------------------------ -------- > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Tue Nov 12 17:28:40 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FBAD120103; Tue, 12 Nov 2019 17:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qH_hj916cy6; Tue, 12 Nov 2019 17:28:32 -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 AD8191200F1; Tue, 12 Nov 2019 17:28:32 -0800 (PST) Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 9186CF039DD4B346F1C4; Wed, 13 Nov 2019 01:28:29 +0000 (GMT) Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 13 Nov 2019 01:28:28 +0000 Received: from DGGEML511-MBX.china.huawei.com ([169.254.1.41]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0439.000; Wed, 13 Nov 2019 09:28:24 +0800 From: Qin Wu To: tom petch , "Rob Wilton (rwilton)" , Kent Watsen , Martin Bjorklund CC: "httpbis-chairs@ietf.org" , "netconf@ietf.org" Thread-Topic: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04 Thread-Index: AdWZwaIxhgQXPPYEQrG4WcDrav91fA== Date: Wed, 13 Nov 2019 01:28:23 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.31.203] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04 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, 13 Nov 2019 01:28:37 -0000 SGksDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogbmV0Y29uZiBbbWFpbHRvOm5ldGNvbmYt Ym91bmNlc0BpZXRmLm9yZ10gtPqx7SB0b20gcGV0Y2gNCreiy83KsbzkOiAyMDE5xOoxMdTCMTLI 1SAxODoyOA0KytW8/sjLOiBSb2IgV2lsdG9uIChyd2lsdG9uKSA8cndpbHRvbkBjaXNjby5jb20+ OyBLZW50IFdhdHNlbiA8a2VudCtpZXRmQHdhdHNlbi5uZXQ+OyBNYXJ0aW4gQmpvcmtsdW5kIDxt YmpAdGFpbC1mLmNvbT4NCrOty806IGh0dHBiaXMtY2hhaXJzQGlldGYub3JnOyBuZXRjb25mQGll dGYub3JnDQrW98ziOiBSZTogW25ldGNvbmZdIEFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LWt3YXRz ZW4tbmV0Y29uZi1odHRwLWNsaWVudC1zZXJ2ZXItMDQNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2Fn ZSAtLS0tLQ0KRnJvbTogIlJvYiBXaWx0b24gKHJ3aWx0b24pIiA8cndpbHRvbkBjaXNjby5jb20+ DQpTZW50OiBNb25kYXksIE5vdmVtYmVyIDExLCAyMDE5IDI6MjYgUE0NCg0KSGkgS2VudCwNCg0K SSBicm9hZGx5IGFncmVlIHdpdGggTWFydGluIGhlcmUsIGluIHRoYXQgSSB0aGluayB0aGF0IHdl IHdhbnQgdG8gZ2V0IGFsbCBvZiB0aGUgIkNsaWVudC1TZXJ2ZXIiIGRyYWZ0cyBmaW5pc2hlZC4N Cg0KRGVmaW5pbmcgZ3JvdXBpbmdzIGluIG9uZSBwbGFjZSBpcyBwcm9iYWJseSBiZW5lZmljaWFs IGFuZCBJIGFzIHN1Y2ggYXMgc3VwcG9ydCB0aGUgYWRvcHRpb24gb2YgdGhpcyBkcmFmdCwgYnV0 IG5vdCBpZiBpdCBnb2luZyB0byBjYXVzZSB0aGUgb3RoZXIgZHJhZnRzIHRoYXQgZGVwZW5kIG9u IHRoZXNlIG1vZHVsZXMgdG8gZW5kIHVwIGJlaW5nIGJsb2NrZWQgZm9yIGFub3RoZXIgOCBtb250 aHMsIG9yIGEgeWVhci4NCg0KPHRwPg0KV2VsbCwgbXkgdmlldyBvZiBncm91cGluZ3MgYW5kIHNp bWlsYXIgY29uc3RydWN0cyBpbiBhIHZhcmlldHkgb2YgbGFuZ3VhZ2VzIGlzIHRoYXQgdGhleSBh cmUgbW9zdGx5IGhhcm1mdWwsIG1ha2luZyB0aGUgY29kZSBtb3JlIGNvbXBsZXggYW5kIGhhcmRl ciB0byB1bmRlcnN0YW5kLCByZXF1aXJpbmcgYSByZWFkZXIgdG8ga2VlcCBoYXZpbmcgdG8gYnJh bmNoIG9mZiBhbmQgbG9vayB1cCBzb21ldGhpbmcgZWxzZSBzb21ld2hlcmUgZWxzZS4NCg0KW1Fp bl06IEkgcHJlZmVyIHRoZXNlIGdyb3VwaW5nIGNhbiBiZSBibGVuZGVkIGludG8gY2xpZW50IHNl cnZlciBzZXJpZXMgZHJhZnQgaWYgd2UgY2FuIG5vdCBmaW5kIG90aGVyIGNvbnN1bWVyIGZvciB0 aGlzIGRyYWZ0IGJlc2lkZXMgb25lcyBpbiB0aGUgT1BTIGFyZWEuDQoNClRoZXkgYXJlIGJlbmVm aWNpYWwgb25seSB3aGVuIHRoZXkgZW5jb21wYXNzIGEgd2VsbC1kZWZpbmVkIG1lYW5pbmdmdWwg ZW50aXR5LCBvYmplY3QsIGlkZWEsIGNvbGxlY3Rpb24gb2YgZGF0YS4gIFdoZW4gdGhlIGJvdW5k YXJpZXMgYXJlIGlsbC1kZWZpbmVkLCBJIGZpbmQgdGhlbSBoYXJtZnVsLg0KDQpXaGF0IEkgc2Vl IGlzIHRoZSBzYW1lICduJyBsaW5lcyBvZiBjb2RlLCB3aGVyZSAnbicgaXMgYSBzbWFsbCwgZXZl biB2ZXJ5IHNtYWxsLCBpbnRlZ2VyLCBhcHBlYXJpbmcgaW4gbW9yZSB0aGFuIG9uZSBwbGFjZSBh bmQgdGhlbiB0aG9zZSAnbicNCmxpbmVzIGJlaW5nIHRha2VuIG91dCBvZiBjb250ZXh0LCBnaXZl biBhIHdyYXBwaW5nLCBhIG5hbWUsIGEgc2VwYXJhdGUgZXZvbHV0aW9uYXJ5IHBhdGgganVzdCB0 byBzYXZlIDw8biBsaW5lcyBvZiBjb2RlLiAgQXMgSSBzYXksIG1vc3RseSBoYXJtZnVsLg0KDQpJ IGRvIGFncmVlIHRoYXQgYW55IGZ1cnRoZXIgZGVsYXkgaW4gdGhlIGJhc2UgbW9kdWxlcyB0aGF0 IGRlcGVuZCBvbiB0aGlzIG1vZHVsZSBpcyB0byBiZSBhdm9pZGVkLg0KDQpbUWluXTorMSwgbXkg cHJlZmVyZW5jZSBpcyB0byBwcmlvcml0aXplIHNvbWUgb2YgY2xpZW50IHNlcnZlciBkcmFmdHMg YW5kIG1vdmUgZm9yd2FyZCwgaWYgZnVydGhlciBkZWxheSBjYW4gbm90IGJlIHJlc29sdmVkLg0K DQpUb20gUGV0Y2gNCg0KDQpDYW4gd2UgcXVpY2tseSBmaW5kIGEgbmFtZSBmb3IgdGhlc2UgbW9k dWxlcyB0aGF0IGlzIGdvb2QgZW5vdWdoIGZvciB1cywgYW5kIHdvdWxkIGFsc28gYmUgYWNjZXB0 YWJsZSB0byB0aGUgaHR0cGJpcyBXRz8NCg0KUGVyaGFwcyAiaHR0cC1yZXN0IiBpbnN0ZWFkIG9m ICJodHRwIiBvciAicmVzdGZ1bCI/DQoNClRoYW5rcywNClJvYg0KDQoNCkZyb206IG5ldGNvbmYg PG5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEtlbnQgV2F0c2VuDQpTZW50 OiAwOCBOb3ZlbWJlciAyMDE5IDAxOjQ1DQpUbzogTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwt Zi5jb20+DQpDYzogaHR0cGJpcy1jaGFpcnNAaWV0Zi5vcmc7IG5ldGNvbmZAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBbbmV0Y29uZl0gQWRvcHRpb24gY2FsbCBmb3INCmRyYWZ0LWt3YXRzZW4tbmV0 Y29uZi1odHRwLWNsaWVudC1zZXJ2ZXItMDQNCg0KSGkgTWFydGluLA0KDQpJIHRoaW5rIGl0IGlz IHF1aXRlIGNsZWFyIHRoYXQgdGhlIFdHIGRvZXNuJ3Qgd2FudCBtb3JlIGRlbGF5cy4NCg0KSXMg aXQ/ICAgSSBvbmx5IGtub3cgdGhhdCBCYWxhenMgSy4gd2lzaGVzIHRvIGhhdmUgdGhlIGZpcnN0 IHRocmVlDQpkcmFmdHMgKGNyeXB0by10eXBlcywgdHJ1c3RzdG9yZSwgYW5kIGtleXN0b3JlKSBj b21wbGV0ZWQgc29vbi4gIFRoZSBOb2tpYS9CQkYgZm9sa3Mgd2VyZSBpbnRlcmVzdGVkIGluIG5l dGNvbmYtc2VydmVyLCBidXQgZm9ya2VkIGxvbmcgYWdvLg0KT3RoZXJ3aXNlLCBJJ20gdW5hd2Fy ZSBvZiBhbnlvbmUgc3RhdGluZyBhIHByZWZlcmVuY2UuICAgRm9yIG15c2VsZiwgSQ0Kb25seSBo b3BlIHRvIGFjaGlldmUgYSBnb29kIHJlc3VsdC4NCg0KDQoNClNvIEkgdGhpbmsgdGhhdCBlaXRo ZXIgd2Ugc2ltcGx5IGRvbid0IGFkZCB0aGlzIGdyb3VwaW5nICphdCB0aGlzIHBvaW50KiwgYW5k IGRlZmluZSB0aGUgbmVjZXNzYXJ5IG5vZGVzIGluIHRoZSBoaWdoZXItbGV2ZWwgbW9kdWxlcywg ZXZlbiB0aG91Z2ggaXQgaXMgbm90IHBlcmZlY3Q7IG9yIHdlIGRlZmluZSB0aGUgInJlc3RmdWwi IG1vZHVsZSB3aXRoIHRoZXNlIGdyb3VwaW5ncywgZXZlbiB0aG91Z2ggdGhhdCBpcyBhbHNvIHBl cmhhcHMgbm90IHBlcmZlY3QuDQoNCmlldGYtcmVzdGZ1bC1jbGllbnQgYW5kIGlldGYtcmVzdGZ1 bC1zZXJ2ZXIgc291bmQgbmljZSwgYnV0IG5vdCBzbyBtdWNoIGluIGEgc3RhY2s6DQoNCiAgICB0 Y3Atc2VydmVyLXBhcmFtZXRlcnMgOiB7IC4uLiB9LA0KICAgIHRscy1zZXJ2ZXItcGFyYW1ldGVy cyA6IHsgLi4uIH0sDQogICAgcmVzdGZ1bC1zZXJ2ZXItcGFyYW1ldGVycyA6IHsgLi4uLiB9LCAg ICAgICAgPC0tLS0gZW5kLXVzZXIgc2F5cw0KIndoYXQncyB0aGF0PyINCiAgICByZXN0Y29uZi1z ZXJ2ZXItcGFyYW1ldGVycyA6IHsgLi4uIH0NCg0Kb3IgKGZvciBodHRwcy1ub3RpZikNCg0KICAg IHRjcC1jbGllbnQtcGFyYW1ldGVycyA6IHsgLi4uIH0sDQogICAgdGxzLWNsaWVudC1wYXJhbWV0 ZXJzIDogeyAuLi4gfSwNCiAgICByZXN0ZnVsLWNsaWVudC1wYXJhbWV0ZXJzIDogeyAuLi4uIH0g ICAgPC0tLS0gZW5kLXVzZXIgc2F5cyAid2hhdCdzDQp0aGF0PyINCg0KDQpBY3R1YWxseSwgdGhl IGFib3ZlIGlzIHB1cnBvc2VseSBpbmFjY3VyYXRlLiAgIElmIHlvdSByZWNhbGwsIHdlDQpzd2l0 Y2hlZCB0byBoYXZpbmcgY29udGFpbmVyLWxlc3MgZ3JvdXBpbmdzLCB0aHVzIHRoZSBjb25zdW1p bmcgbW9kdWxlIGNhbiBuYW1lIHRoZSBjb250YWluZXIgd2hhdGV2ZXIgaXQgd2FudHMsIHNvIHRo ZSBuZXQtbmV0IGlzIG5vIGltcGFjdA0Kb3RoZXIgdGhhbiBjaGFuZ2luZyB0aGUgaW1wb3J0IGFu ZCB1c2VzIHN0YXRlbWVudHMuICAgVGhvdWdoIEkgc3RpbGwNCmRvbid0IGtub3cgd2h5IHdlIHNo b3VsZCBkbyBldmVuIHRoaXMsIGdpdmVuIHRoZSBsYWNrIG9mIGFueSByZXNwb25zZSB0byBteSBP Y3QgMzB0aCBtZXNzYWdlLg0KDQoNCktlbnQgLy8gY29udHJpYnV0b3INCg0KDQoNCg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQotLS0tLS0tLQ0KDQoNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gbmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gbmV0Y29uZkBpZXRm Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCj4N Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldGNv bmYgbWFpbGluZyBsaXN0DQpuZXRjb25mQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg== From nobody Wed Nov 13 04:57:25 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F4C1208C1 for ; Wed, 13 Nov 2019 04:57:23 -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 rUeqm5WjJ39f for ; Wed, 13 Nov 2019 04:57:22 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 19C2E1208A9 for ; Wed, 13 Nov 2019 04:57:22 -0800 (PST) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id EF1EF1AE018B for ; Wed, 13 Nov 2019 13:57:19 +0100 (CET) Date: Wed, 13 Nov 2019 13:56:49 +0100 (CET) Message-Id: <20191113.135649.2218807015240802033.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund 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: [netconf] crypto-types and keystore comments 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, 13 Nov 2019 12:57:24 -0000 Hi, I have some comments on draft-ietf-netconf-crypto-types-12 and draft-ietf-netconf-keystore-14. o Is the key-format there to support multiple formats for the same kind of key (e.g., ssh key), or is it there to be able to have different kinds of keys in the same list? (Or both?) I.e., is the intentation that a client can freely pick any private-key-format (that is supported by the server), regardless of how the key is used? o One idea that was floating around was to have separate keystore lists for different things (see the ML archives, e.g. some mails in the thread "crypto-types fallback strategy"). I.e. instead of the current: +--rw keystore +--rw asymmetric-keys | +--rw asymmetric-key* [name] we would have something like: +--rw keystores +--rw ssh-keystore | ... +--rw tls-keystore // x509-keystore? ... If we don't have to support multiple formats for the same kind of key, I don't think we need the key-format in this case. With the current design it is not obvious to me how I can find all ssh keys, for example. This said, *if* we use a single generic list, I think the list in the current model works fine. It is a bit complicated, but some complexity is inevitable with a generic model like this. o iana- modules The iana modules have a list of supported algorithms, e.g.: list supported-asymmetric-algorithm I mentioned this before - I don't think a global list like this is sufficient. For example, perhaps my TLS code supports "secp521r1", but my SSH code does not. And some random small things I noticed: o ssh-public-key-format The crypto model has: identity ssh-public-key-formatp { base "public-key-format"; description "The public key format described by RFC 4716."; } I think that this should be: 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"; Note that the public key format in 4716 is textual: ---- BEGIN SSH2 PUBLIC KEY ---- Header-tag ':' ' ' Header-value BODY ---- END SSH2 PUBLIC KEY ---- Where BODY is: The body of a public key file is the base64 encoded ([RFC2045]) public key data as specified by [RFC4253], Section 6.6: string certificate or public key format identifier byte[n] key/certificate data So with your current definition we would take this textual format (that has the key base64-encoded), and base64 encode the whole thing (includign the already base64-encoded key). o subject-public-key-info-format The crypto model has: identity subject-public-key-info-format { base "public-key-format"; description "A SubjectPublicKeyInfo (from RFC 5280)."; } Should this be "DER encoded"? (this and other defintions have references to RFCs in the description; they should be moved to proper "reference" statements) o iana-hash-algs This module has a bunch of shake-*: enum shake-224 { value 7; description "The SHA3 algorithm with 224-bits output."; I think this should be "sha3-224" etc. (there are just two shake hash functions defined; shake 128 & 256, and they have variable output) (and BTW, FIPS PUB 202 doesn't define sha3-128) /martin From nobody Wed Nov 13 10:50:38 2019 Return-Path: <0100016e661a2f48-26561fed-a533-4aec-8ad1-d68582b82b39-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 B6E74120965 for ; Wed, 13 Nov 2019 10:50:35 -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 uwEGrbe9D5PH for ; Wed, 13 Nov 2019 10:50:30 -0800 (PST) Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C812512094A for ; Wed, 13 Nov 2019 10:50:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1573671023; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=5G+c99s/5Ba1jcs4IFt6S3wxD/m41XdXvKD/VsM8X0c=; b=VW6b3cXf45F/D/SKKMlDWMCl50b1j8yy1H8ASnslCxooTanQ8JFpn+SKsjIdm/A3 8W6p2iOgBU1N9g8ZFncGlpZEYupakCGZ4lTxLRCWyWFB6T2Z9g5Lj7DfzvXwgb3oksG f5Sksu54HRkERVkwmjBSzOJr8H2heISmPYpgIZNE= From: Kent Watsen Message-ID: <0100016e661a2f48-26561fed-a533-4aec-8ad1-d68582b82b39-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_64BFF454-6D5E-42B8-83C3-906749C8F468" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 13 Nov 2019 18:50:22 +0000 In-Reply-To: <20191111.110013.2019956803552089416.mbj@tail-f.com> Cc: "netconf@ietf.org" To: Martin Bjorklund References: <0100016e39631e46-c007fd65-2e51-47a6-bd27-764f5257a16c-000000@email.amazonses.com> <20191106.142822.2117534105126283386.mbj@tail-f.com> <0100016e4d8323b0-2a182947-485d-43e6-908c-13bc5ad2f210-000000@email.amazonses.com> <20191111.110013.2019956803552089416.mbj@tail-f.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.11.13-54.240.8.83 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] client identification in ietf-netconf-server 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, 13 Nov 2019 18:50:36 -0000 --Apple-Mail=_64BFF454-6D5E-42B8-83C3-906749C8F468 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Martin, > Martin Bjorklund wrote: >=20 > Hi, >=20 > Kent Watsen wrote: >>=20 >> Hi Martin, >>=20 >> [Not trimming down because too much context would be lost.] >>=20 >>=20 >>>>> The ietf-netconf-server module has this: >>>>>=20 >>>>> grouping netconf-server-grouping { >>>>> ... >>>>> container client-identification { >>>>> ... >>>>> container cert-maps { >>>>> when "../../../../tls"; >>>>> uses x509c2n:cert-to-name; >>>>> ... >>>>> } >>>>> } >>>>> } >>>>>=20 >>>>> Note the "when" expression. This means that the grouping has a = strong >>>>> depency on where is it used. We should try to avoid such a = design. >>>>=20 >>>>=20 >>>> Would this be better? =20 >>>>=20 >>>> OLD >>>> when "../../../../tls"; >>>>=20 >>>> NEW >>>> if-feature "tls-listen or tls-call-home"; >>>=20 >>> Yes, but see below. >>>=20 >>>=20 >>>>> But should't this cert-to-name list be available when x509-certs = are >>>>> used also with SSH? >>>>=20 >>>> Hmmm. I'd assumed that, with RFC 6187, the username was still = passed >>>> as its own field, but I see this in Section 4: >>>>=20 >>>> For the purposes of user authentication, the mapping between >>>> certificates and user names is left as an implementation and >>>> configuration issue for implementers and system administrators. >>>=20 >>> If the username was used as identification it would mean that with a >>> valid cert I could present myself as any user! >>>=20 >>>> So you may be right about that. I only ever looked at RFC 6187 = from >>>> the perspective of the server presenting an IDevID certificate. = But, >>>> assuming it's true, then perhaps this: >>>>=20 >>>> NEWEST: >>>> if-feature "tls-listen or tls-call-home or = sshcmn:ssh-x509-certs"; >>>=20 >>> Ok. >>>=20 >>> This gives: >>>=20 >>> grouping netconf-server-grouping { >>> description ...; >>> container client-identification { >>> description >>> "Specifies a mapping through which clients MAY be identified >>> (i.e., the NETCONF username) from a supplied certificate. >>> Note that a client MAY alternatively be identified via an >>> alternate authentication scheme."; >>> container cert-maps { >>> if-feature "tls-listen or tls-call-home or = sshcmn:ssh-x509-certs"; >>=20 >> Yes. >>=20 >>> But since the description of the "client-identification" says that = it >>> is used only with certificates, perhaps that container's name should >>> reflect this, and the if-feature statement moved to that container? >>> Perhaps: >>>=20 >>> container client-cert-identification >>> if-feature "tls-listen or tls-call-home or = sshcmn:ssh-x509-certs"; >>>=20 >>> and also perhaps remove 'cert-maps', and use the cert-to-name = grouping >>> directly here? >>=20 >> Good. My only hesitation is that someday there may be a need for >> another way to identify clients, but that sounds too far out (even = for >> me) to squabble over. But a better name is needed. >> "cert-based-client-identification" would be more accurate, but that >> seems overly long. Looking at a snippet of config might help... >>=20 >> netconf-server-parameters : { >> something-here : [ >> { >> cert-to-name : { ... } >> cert-to-name : { ... }, >> ... >> cert-to-name : { ... } >> } >> ] >> } >>=20 >> How about "cert-to-name-mappings"? ( know, almost the same length, >> but half the number of syllables!). But that name leaves out the = word >> "identity", which is may be important in security circles, so maybe >> "client-identity-mappings"? >=20 > I think this name is as generic as "client-identification". The best > so far imo is "cert-based-client-identification". A bit long, but > descripitive. Actually, I think we should go back to "client-identification" now that = raw-public-key and pre-shared/pairwise-symmetric key (PSK) has been = added as alternate ways that TLS clients and servers may identify = themselves and authenticate peers. Thus it seems that there is a need = to map usernames from things other than just certificates. >>>>> The current data model for ssh specifies certs on >>>>> a per-user basis. But this requires lots of configuration in the = case >>>>> that the cert encodes the user name (even though the name is in = the >>>>> cert you have to configure each user on each device). I suggest = we >>>>> align the model for SSH with the TLS model for cert = identification. >>>>=20 >>>> We certainly want to factor out configuration where possible. I'd >>>> need to look into this more. Perhaps you can send a diff? >>>=20 >>> Today we have under 'ssh-server-parameters/client-authentication': >>>=20 >>> +--:(local) {local-client-auth-supported}? >>> +--rw users >>> +--rw user* [name] >>> +--rw name string >>> +--rw password? ianach:crypt-hash >>> +--rw host-keys! >>> | +--rw (local-or-truststore) >>> | +--:(local) {local-definitions-supported}? >>> | | +--rw local-definition >>> | | +--rw host-key* ct:ssh-host-key >>> | | +--rw cert* = trust-anchor-cert-cms >>> | | +---n certificate-expiration >>> | | +-- expiration-date yang:date-and-time >>=20 >> Not to take away from your point, but the previous three lines don't >> exist in the model. >>=20 >>> | +--:(truststore) = {truststore-supported,ssh-host-keys}? >>> | +--rw truststore-reference? ts:host-keys-ref >>> +--rw ca-certs! {sshcmn:ssh-x509-certs}? >>> | +--rw (local-or-truststore) >>> | +--:(local) {local-definitions-supported}? >>> | | +--rw local-definition >>> | | +--rw cert* = trust-anchor-cert-cms >>> | | +---n certificate-expiration >>> | | +-- expiration-date yang:date-and-time >>> | +--:(truststore) = {truststore-supported,x509-certificates}? >>> | +--rw truststore-reference? ts:certificates-ref >>> +--rw client-certs! {sshcmn:ssh-x509-certs}? >>> +--rw (local-or-truststore) >>> +--:(local) {local-definitions-supported}? >>> | +--rw local-definition >>> | +--rw cert* = trust-anchor-cert-cms >>> | +---n certificate-expiration >>> | +-- expiration-date yang:date-and-time >>> +--:(truststore) = {truststore-supported,x509-certificates}? >>> +--rw truststore-reference? ts:certificates-ref >>>=20 >>> I think host-keys, ca-certs and client-certs should be moved out of >>> the user list: >>>=20 >>> +--:(local) {local-client-auth-supported}? >>> +--rw users >>> | +--rw user* [name] >>> | +--rw name string >>> | +--rw password? ianach:crypt-hash >>> +--rw host-keys! >>> | +--rw (local-or-truststore) >>> | +--:(local) {local-definitions-supported}? >>> | | +--rw local-definition >>> | | +--rw host-key* ct:ssh-host-key >>> | | +--rw cert* trust-anchor-cert-cms >>> | | +---n certificate-expiration >>> | | +-- expiration-date yang:date-and-time >>=20 >> Again, not to take away from your point, but the previous three lines >> don't exist in the model. >>=20 >>> | +--:(truststore) {truststore-supported,ssh-host-keys}? >>> | +--rw truststore-reference? ts:host-keys-ref >>> +--rw ca-certs! {sshcmn:ssh-x509-certs}? >>> | +--rw (local-or-truststore) >>> | +--:(local) {local-definitions-supported}? >>> | | +--rw local-definition >>> | | +--rw cert* trust-anchor-cert-cms >>> | | +---n certificate-expiration >>> | | +-- expiration-date yang:date-and-time >>> | +--:(truststore) {truststore-supported,x509-certificates}? >>> | +--rw truststore-reference? ts:certificates-ref >>> +--rw client-certs! {sshcmn:ssh-x509-certs}? >>> +--rw (local-or-truststore) >>> +--:(local) {local-definitions-supported}? >>> | +--rw local-definition >>> | +--rw cert* trust-anchor-cert-cms >>> | +---n certificate-expiration >>> | +-- expiration-date yang:date-and-time >>> +--:(truststore) {truststore-supported,x509-certificates}? >>> +--rw truststore-reference? ts:certificates-ref >>=20 >> I agree that "ca-certs" and "client-certs" should be pulled out (as >> they are in ietf-tls-server), but I'm unsure if "host-keys" can be, = at >> least not unless we introduce something like "host-key-to-name" maps, >> right? >>=20 >> For now, I only pulled out "ca-certs" and "client-certs". >=20 > Hmm, I realize that I have misunderstood 'host-keys' here. How > exactly is this supposed to be used? This is the client > authentication part of a server. How is the *host* key used here by > the server? I mean, the client doesn't present a host key to the > server, so I don't understand what this is. It seems that I've been overzealous with the term "host-key" here. In = SSH, a "host-key" is a special term for the server's public key. = Clients may also authenticate using a public key, but there isn't a = special term for that case. RFC 4252 states that clients can = authenticate using "publickey", "password", and "hostbased". Per RFC = 6187, section 1, 1st paragraph, the "publickey" algorithm is is also = used for X.509 certificates (e.g., x509v3-rsa2048-sha256). >>> But also here I think that the choice "local-or-external" isn't >>> ideal. I think that a system that implements some "external" >>> mechanism should/would augement this data model with specific nodes >>> for that mechanism. As a simplistic example: >>>=20 >>> augment /netconf-server/.../client-authentication { >>> leaf use-host-keys-in-filesystem { >>> leaf boolean; >>> } >>> } >>>=20 >>> In this case, requiring the client to configure both this new leaf = and >>> "client-auth-defined-elsewhere" seems redundant and non-intuitive. >>=20 >> Agreed. >>=20 >>> Another case is a system that *always* use the filesystem host keys. >>> It would simply just always do that, and again, requiring the client >>> to configure "client-auth-defined-elsewhere" seems incorrect. >>=20 >> Agreed. >>=20 >>> So my suggestion is to remove the choice "local-or-external" and >>> remove the external case, and instead document that (i) systems may >>> use some other hard-wired mechanism or (ii) other modules can = augment >>> this container with additional control parameters for other >>> mechanisms. >>=20 >> Agree in principle, but unsure about implementation. One thing >> important to me you didn't mention is having the "local" = configuration >> gated by a "feature" statement. So, do we float the >> "local-client-auth-supported" (renamed appropriately) up to the >> "client-authentication" container? If so, would that incorrectly >> cover the "supported-authentication-methods" descendent? >> Suggestions? >=20 > Perhaps just add the if-feature to the containers "users", "ca-certs", > "client-certs"? Sounds okay. I've updated my local copy, in all of SSH, TLS, and HTTP. >>>>> For TLS, the data model has the following structure: >>>>>=20 >>>>> +--rw netconf-server >>>>> +--rw listen! {ssh-listen or tls-listen}? >>>>> +--rw idle-timeout? uint16 >>>>> +--rw endpoint* [name] >>>>> +--rw name string >>>>> +--rw (transport) >>>>> ... >>>>> +--:(tls) {tls-listen}? >>>>>=20 >>>>> [ reset indentation to make the diagram easier to read ] >>>>>=20 >>>>> +--rw tls >>>>> +--rw tcp-server-parameters >>>>> ... >>>>> +--rw tls-server-parameters >>>>> | +--rw server-identity >>>>> ... >>>>> | +--rw client-authentication! >>>>> | | +--rw (required-or-optional) >>>>> | | | +--:(required) >>>>> | | | | +--rw required? empty >>>>> | | | +--:(optional) >>>>> | | | +--rw optional? empty >>>>> | | +--rw (local-or-external) >>>>> | | +--:(local) {local-client-auth-supported}? >>>>> | | | +--rw ca-certs! {ts:x509-certificates}? >>>>> | | | | +--rw (local-or-truststore) >>>>> | | | | +--:(local) {local-definitions-supported}? >>>>> | | | | | +--rw local-definition >>>>> | | | | | +--rw cert* trust-anchor-cert-cms >>>>> | | | | | +---n certificate-expiration >>>>> | | | | | +-- expiration-date >>>>> | | | | | yang:date-and-time >>>>> | | | | +--:(truststore) >>>>> | | | | = {truststore-supported,x509-certificates}? >>>>> | | | | +--rw truststore-reference? >>>>> | | | | ts:certificates-ref >>>>> | | | +--rw client-certs! {ts:x509-certificates}? >>>>> | | | +--rw (local-or-truststore) >>>>> | | | +--:(local) {local-definitions-supported}? >>>>> | | | | +--rw local-definition >>>>> | | | | +--rw cert* trust-anchor-cert-cms >>>>> | | | | +---n certificate-expiration >>>>> | | | | +-- expiration-date >>>>> | | | | yang:date-and-time >>>>> | | | +--:(truststore) >>>>> | | | = {truststore-supported,x509-certificates}? >>>>> | | | +--rw truststore-reference? >>>>> | | | ts:certificates-ref >>>>> | | +--:(external) >>>>> | | {external-client-auth-supported}? >>>>> | | +--rw client-auth-defined-elsewhere? >>>>> | | empty >>>>> ... >>>>> +--rw netconf-server-parameters >>>>> +--rw client-identification >>>>> +--rw cert-maps >>>>> +--rw cert-to-name* [id] >>>>> +--rw id uint32 >>>>> +--rw fingerprint >>>>> | x509c2n:tls-fingerprint >>>>> +--rw map-type identityref >>>>> +--rw name string >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>> It is not clear how this is used by the server to end up either = with >>>>> an authenticated user name or failed authentication. >>>>=20 >>>> Okay, let's fix that. >>>>=20 >>>>=20 >>>>> First of all, how is the "required-or-optional" choice used in a >>>>> NETCONF server? What happens if an operation configures this to >>>>> "optional"? (side note: why is this a choice of empty leafs = instead >>>>> of a leaf?) >>>>=20 >>>> Hmmm, this 'choice' seems unneeded for NETCONF. The "choice" is >>>> coming from the ietf-tls-server, and a similar "choice" is in >>>> ietf-http-server. It was put there, in part, for RESTCONF, as >>>> user-auth can occur at either (or both!) protocol layers... >>>=20 >>> Ok. Yes, the RESTCONF auth mechanism is interesting. Let's discuss >>> that in a separate thread. >>=20 >> Okay. For now, I'll leave the "required-or-optional" in both >> ietf-tls-server and ietf-http-server. However, to address the issue >> that it can never apply to NETCONF, it seems that a possible strategy >> would be to move both instances to augmentations defined in >> ietf-restconf-server... >>=20 >> That said, to go along with some of your thinking from above, it's = not >> clear how an application would consume the "required-or-optional" >> configuration. Case in point, in the RESTCONF server based product >> I'm working on, the configuration for each client, which is defined >> outside the restconf-server-grouping tree, has descendants nodes like >> "http-password" and "tls-trust-anchor", with meanings that, if >> defined, then the client MUST present said auth credentials at that >> protocol-layer. IIRC, the code doesn't check these flags at all. >>=20 >> So, rather than moving both "required-or-optional" instances to >> augmentations in ietf-restconf-server, maybe they can just be = deleted? >=20 > Yes I think so, altough I haven't yet studied the restconf model in > detail. I've updated my local copy, in both TLS-server and HTTP-server. >>>>> Second, I assume that the idea is that the server uses the config >>>>> params in "local-or-external" and the certificate presented by the >>>>> client and after this step is either accepted or rejected. It is = not >>>>> clear what is supposed to happen if someone configures >>>>> "client-auth-defined-elsewhere". I think it is better to not = define >>>>> this case, but (perhaps) keep the choice and explain that other >>>>> modules can augment additional config params here for other >>>>> authentication mechanisms. >>>>=20 >>>> Well that's just the thing, the goal is to enable user-auth to NOT = be >>>> defined here. As the description statement in ietf-tls-server = says: >>>>=20 >>>> "Configuring credentials externally enables applications >>>> to place client authentication with client definitions, >>>> rather then in a part of a data model principally >>>> concerned with configuring the TLS transport."; >>>=20 >>> I totally agree with this. I am questioning the solution. See = above >>> for my proposal. >>=20 >> Ack. >>=20 >>=20 >>>>> Next, my guess is that the intention is that if the cert was = accepted >>>>> in the step above, it is checked in cert-to-name to see if a user = name >>>>> can be derived. >>>>=20 >>>> Yes. >>>>=20 >>>>=20 >>>>> In another thread you mentioned that if a local cert is = configured, it >>>>> seems redundant to also configure the cert as a fingerprint in >>>>> cert-to-name. I'm not sure about this. But perhaps you can use = the >>>>> same "map-type" and "name" leafs in the "client-cert" container? = It >>>>> is not as easy for the "truststore-reference"; perhaps you'd have = to >>>>> augment the truststore with these leafs in this case. >>>>=20 >>>> In context, that statement I made before is a relatively minor >>>> objection. That said, I don't understand your proposal, are you >>>> suggesting to recreate the essence of 'cert-to-name'? Another idea = I >>>> had was that the fingerprint could be in a "union" with also a >>>> truststore-reference, which is only mildly better... >>>=20 >>> Aha, now I understand your suggestion of making fingerprint = optional. >>> I agree that this could work. However, I assume it must be used = with >>> care. If you know for sure that a successful result from the >>> authentication mechanism means that CA cert X has been used, you can >>> save some typing by not configuring the fingerprint of X. So the >>> question is if it is worth it? >>=20 >> Yes, saving typing is the gist of it, but I don't think handling with >> care is needed or, rather, it's no more care. As I understand it, a >> fingerprint would be redundant in the common case, i.e., most configs >> would not have to define a fingerprint, so the optimization seems >> worth it to me. >=20 > It would be interesting to hear other opinions on this, esp. from > security people. Personally I can accept both alternatives. I'll discuss the issue in the presentation. Kent // contributor >=20 >> Separately, be aware that calculating an x509c2n:tls-fingerprint is >> not a simple copy/paste. That is, the command `openssl x509 -in >> CERT.pem -noout -sha256 -fingerprint` is close, but not exactly what >> is needed. >=20 > Right; you have to prefix this fingerprint with "04:". >=20 >=20 > /martin --Apple-Mail=_64BFF454-6D5E-42B8-83C3-906749C8F468 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Martin,


Martin Bjorklund <mbj@tail-f.com> wrote:

Hi,
Kent Watsen <kent+ietf@watsen.net> wrote:

Hi Martin,

[Not trimming down because too much context would be = lost.]


The ietf-netconf-server module has this:

grouping netconf-server-grouping {
 ...
 container = client-identification {
   ...
   container cert-maps {
=      when "../../../../tls";
=      uses x509c2n:cert-to-name;
=      ...
   }
 }
}

Note = the "when" expression.  This means that the grouping has a = strong
depency on where is it used.  We should try to = avoid such a design.


Would this be better?   

OLD
     when = "../../../../tls";

NEW
= if-feature "tls-listen or tls-call-home";

Yes, but see below.


But should't this = cert-to-name list be available when x509-certs are
used = also with SSH?

Hmmm.  I'd = assumed that, with RFC 6187, the username was still passed
as its own field, but I see this in Section 4:

 For the purposes of user = authentication, the mapping between
 certificates = and user names is left as an implementation and
=  configuration issue for implementers and system administrators.

If the username was used as = identification it would mean that with a
valid cert I = could present myself as any user!

So you may be right about that.  I only = ever looked at RFC 6187 from
the perspective of the server = presenting an IDevID certificate.  But,
assuming it's = true, then perhaps this:

NEWEST:
= if-feature "tls-listen or tls-call-home or = sshcmn:ssh-x509-certs";

Ok.

This gives:

= grouping netconf-server-grouping {
=   description ...;
  container = client-identification {
=     description
=       "Specifies a mapping through which = clients MAY be identified
=        (i.e., the NETCONF username) = from a supplied certificate.
=        Note that a client MAY = alternatively be identified via an
=        alternate authentication = scheme.";
    container cert-maps = {
      if-feature = "tls-listen or tls-call-home or sshcmn:ssh-x509-certs";

Yes.

But since the = description of the "client-identification" says that it
is = used only with certificates, perhaps that container's name should
reflect this, and the if-feature statement moved to that = container?
Perhaps:

=   container client-cert-identification
=     if-feature "tls-listen or tls-call-home or = sshcmn:ssh-x509-certs";

and also perhaps = remove 'cert-maps', and use the cert-to-name grouping
directly here?

Good. =  My only hesitation is that someday there may be a need for
another way to identify clients, but that sounds too far out = (even for
me) to squabble over.  But a better name is = needed.
"cert-based-client-identification" would be more = accurate, but that
seems overly long.  Looking at a = snippet of config might help...

=      netconf-server-parameters : {
=        something-here : [
         {
=            cert-to-= name : { ... }
=            cert-to-= name : { ... },
=            ...
=            cert-to-= name : { ... }
=          }
=        ]
=      }

How about = "cert-to-name-mappings"?  ( know, almost the same length,
but half the number of syllables!).  But that name = leaves out the word
"identity", which is may be important = in security circles, so maybe
"client-identity-mappings"?

I think this name is as generic = as "client-identification".  The best
so far imo is = "cert-based-client-identification".  A bit long, but
descripitive.

Actually, I think we should go back to = "client-identification" now that raw-public-key and = pre-shared/pairwise-symmetric key (PSK) has been added as alternate ways = that TLS clients and servers may identify themselves and authenticate = peers.   Thus it seems that there is a need to map usernames from = things other than just certificates.


The current data model = for ssh specifies certs on
a per-user basis. But this = requires lots of configuration in the case
that the cert = encodes the user name (even though the name is in the
cert = you have to configure each user on each device).  I suggest we
align the model for SSH with the TLS model for cert = identification.

We certainly = want to factor out configuration where possible.  I'd
need to look into this more.  Perhaps you can send a = diff?

Today we have under = 'ssh-server-parameters/client-authentication':

+--:(local) {local-client-auth-supported}?
=    +--rw users
=       +--rw user* [name]
=          +--rw name =            string =          +--rw password? =       ianach:crypt-hash
=          +--rw = host-keys!
=          |  +--rw = (local-or-truststore)
=          | =     +--:(local) {local-definitions-supported}?
         | =     |  +--rw local-definition
=          | =     |     +--rw host-key* =             &n= bsp;   ct:ssh-host-key
=          | =     |     +--rw cert* =             &n= bsp;       trust-anchor-cert-cms
         | =     |     +---n = certificate-expiration
=          | =     |        +-- = expiration-date    yang:date-and-time

Not to take away from your point, = but the previous three lines don't
exist in the model.

=          | =     +--:(truststore) = {truststore-supported,ssh-host-keys}?
=          | =        +--rw truststore-reference? =   ts:host-keys-ref
=          +--rw ca-certs! = {sshcmn:ssh-x509-certs}?
=          |  +--rw = (local-or-truststore)
=          | =     +--:(local) {local-definitions-supported}?
         | =     |  +--rw local-definition
=          | =     |     +--rw cert* =             &n= bsp;       trust-anchor-cert-cms
         | =     |     +---n = certificate-expiration
=          | =     |        +-- = expiration-date    yang:date-and-time
=          | =     +--:(truststore) = {truststore-supported,x509-certificates}?
=          | =        +--rw truststore-reference? =   ts:certificates-ref
=          +--rw = client-certs! {sshcmn:ssh-x509-certs}?
=             +-= -rw (local-or-truststore)
=             &n= bsp;  +--:(local) {local-definitions-supported}?
=             &n= bsp;  |  +--rw local-definition
=             &n= bsp;  |     +--rw cert* =             &n= bsp;       trust-anchor-cert-cms
=             &n= bsp;  |     +---n = certificate-expiration
=             &n= bsp;  |        +-- = expiration-date    yang:date-and-time
=             &n= bsp;  +--:(truststore) = {truststore-supported,x509-certificates}?
=             &n= bsp;  +--rw truststore-reference? =   ts:certificates-ref

I think = host-keys, ca-certs and client-certs should be moved out of
the user list:

+--:(local) = {local-client-auth-supported}?
   +--rw = users
   |  +--rw user* [name]
   |     +--rw name =            string    |     +--rw = password?       ianach:crypt-hash
   +--rw host-keys!
=    |  +--rw (local-or-truststore)
=    |     +--:(local) = {local-definitions-supported}?
   | =     |  +--rw local-definition
=    |     | =     +--rw host-key* =             &n= bsp;   ct:ssh-host-key
   | =     |     +--rw cert* =             &n= bsp;       trust-anchor-cert-cms
   |     | =     +---n certificate-expiration
=    |     | =        +-- expiration-date =    yang:date-and-time

Again, not to take away from your point, but the previous = three lines
don't exist in the model.

   | =     +--:(truststore) = {truststore-supported,ssh-host-keys}?
   | =        +--rw truststore-reference? =   ts:host-keys-ref
   +--rw = ca-certs! {sshcmn:ssh-x509-certs}?
   | =  +--rw (local-or-truststore)
   | =     +--:(local) {local-definitions-supported}?
   |     |  +--rw = local-definition
   | =     |     +--rw cert* =             &n= bsp;       trust-anchor-cert-cms
   |     | =     +---n certificate-expiration
=    |     | =        +-- expiration-date =    yang:date-and-time
   | =     +--:(truststore) = {truststore-supported,x509-certificates}?
=    |        +--rw = truststore-reference?   ts:certificates-ref
=    +--rw client-certs! {sshcmn:ssh-x509-certs}?
      +--rw = (local-or-truststore)
=          +--:(local) = {local-definitions-supported}?
=          |  +--rw = local-definition
=          | =     +--rw cert* =             &n= bsp;       trust-anchor-cert-cms
         | =     +---n certificate-expiration
=          | =        +-- expiration-date =    yang:date-and-time
=          +--:(truststore) = {truststore-supported,x509-certificates}?
=             +-= -rw truststore-reference?   ts:certificates-ref

I agree that "ca-certs" and = "client-certs" should be pulled out (as
they are in = ietf-tls-server), but I'm unsure if "host-keys" can be, at
least not unless we introduce something like = "host-key-to-name" maps,
right?

For now, I only pulled out "ca-certs" and "client-certs".

Hmm, I realize that I have = misunderstood 'host-keys' here.  How
exactly is this = supposed to be used?  This is the client
authentication= part of a server.  How is the *host* key used here by
the server?   I mean, the client doesn't present a = host key to the
server, so I don't understand what this = is.

It seems that I've been overzealous with the term = "host-key" here.  In SSH, a "host-key" is a special term for the = server's public key.  Clients may also authenticate using a public = key, but there isn't a special term for that case.   RFC 4252 = states that clients can authenticate using "publickey", "password", and = "hostbased".   Per RFC 6187, section 1, 1st paragraph, the = "publickey" algorithm is is also used for X.509 certificates (e.g., = x509v3-rsa2048-sha256).


But also = here I think that the choice "local-or-external" isn't
ideal.  I think that a system that implements some = "external"
mechanism should/would augement this data model = with specific nodes
for that mechanism.  As a = simplistic example:

augment = /netconf-server/.../client-authentication {
=   leaf use-host-keys-in-filesystem {
=     leaf boolean;
  }
}

In this case, requiring the = client to configure both this new leaf and
"client-auth-defined-elsewhere" seems redundant and = non-intuitive.

Agreed.

Another = case is a system that *always* use the filesystem host keys.
It would simply just always do that, and again, requiring the = client
to configure "client-auth-defined-elsewhere" seems = incorrect.

Agreed.

So my = suggestion is to remove the choice "local-or-external" and
remove the external case, and instead document that (i) = systems may
use some other hard-wired mechanism or (ii) = other modules can augment
this container with additional = control parameters for other
mechanisms.

Agree in principle, but unsure = about implementation.  One thing
important to me you = didn't mention is having the "local" configuration
gated = by a "feature" statement.  So, do we float the
"local-client-auth-supported" (renamed appropriately) up to = the
"client-authentication" container?  If so, would = that incorrectly
cover the = "supported-authentication-methods" descendent?
Suggestions?

Perhaps = just add the if-feature to the containers "users", "ca-certs",
"client-certs"?
Sounds okay.  I've updated my local copy, in = all of SSH, TLS, and HTTP.



For TLS, the data model = has the following structure:

+--rw = netconf-server
  +--rw listen! {ssh-listen or = tls-listen}?
     +--rw = idle-timeout?   uint16
=      +--rw endpoint* [name]
=         +--rw name =         string
=         +--rw (transport)
=            ...
=            +--:(tls= ) {tls-listen}?

 [ reset indentation = to make the diagram easier to read ]

+--rw = tls
   +--rw tcp-server-parameters
   ...
   +--rw = tls-server-parameters
   |  +--rw = server-identity
=          ...
=    |  +--rw client-authentication!
=    |  |  +--rw (required-or-optional)
   |  |  |  +--:(required)
   |  |  |  |  +--rw = required?    empty
   | =  |  |  +--:(optional)
   | =  |  |     +--rw optional? =    empty
   |  | =  +--rw (local-or-external)
   | =  |     +--:(local) =  {local-client-auth-supported}?
   | =  |     |  +--rw ca-certs! =   {ts:x509-certificates}?
   | =  |     |  |  +--rw = (local-or-truststore)
   |  | =     |  |     +--:(local) =  {local-definitions-supported}?
   | =  |     |  |     | =  +--rw local-definition
   |  | =     |  |     | =     +--rw cert*   trust-anchor-cert-cms
   |  |     | =  |     |     +---n = certificate-expiration
   |  | =     |  |     | =        +-- expiration-date
   |  |     | =  |     | =             &n= bsp;  yang:date-and-time
   | =  |     |  | =     +--:(truststore)
=    |  |     |  | =             &n= bsp;{truststore-supported,x509-certificates}?
=    |  |     |  | =        +--rw truststore-reference?
   |  |     | =  | =             &n= bsp;  ts:certificates-ref
   | =  |     |  +--rw client-certs! =  {ts:x509-certificates}?
   |  | =     |     +--rw = (local-or-truststore)
   |  | =     | =        +--:(local) =  {local-definitions-supported}?
   | =  |     | =        |  +--rw = local-definition
   |  | =     |        | =     +--rw cert* =     trust-anchor-cert-cms
=    |  |     | =        | =     +---n certificate-expiration
=    |  |     | =        | =        +-- expiration-date
   |  |     | =        | =             &n= bsp;  yang:date-and-time
   | =  |     | =        +--:(truststore)
=    |  |     | =             &n= bsp;   {truststore-supported,x509-certificates}?
   |  |     | =           +--rw = truststore-reference?
   |  | =     | =             &n= bsp;     ts:certificates-ref
=    |  |     +--:(external)
   |  | =             &n= bsp;{external-client-auth-supported}?
   | =  |        +--rw = client-auth-defined-elsewhere?
   | =  | =             &n= bsp;  empty
=        ...
=    +--rw netconf-server-parameters
=       +--rw client-identification
         +--rw = cert-maps
=             +-= -rw cert-to-name* [id]
=             &n= bsp;  +--rw id =             ui= nt32
=             &n= bsp;  +--rw fingerprint
=             &n= bsp;  | =       x509c2n:tls-fingerprint
= =             &n= bsp;  +--rw map-type =       identityref
=             &n= bsp;  +--rw name =           string




It is not clear how this = is used by the server to end up either with
an = authenticated user name or failed authentication.

Okay, let's fix that.


First of all, how is the "required-or-optional" choice used = in a
NETCONF server?  What happens if an operation = configures this to
"optional"?  (side note: why is = this a choice of empty leafs instead
of a leaf?)

Hmmm, this 'choice' seems = unneeded for NETCONF.  The "choice" is
coming from = the ietf-tls-server, and a similar "choice" is in
ietf-http-server. It was put there, in part, for RESTCONF, = as
user-auth can occur at either (or both!) protocol = layers...

Ok.  Yes, the = RESTCONF auth mechanism is interesting.  Let's discuss
that in a separate thread.

Okay.  For now, I'll leave the "required-or-optional" in = both
ietf-tls-server and ietf-http-server.  However, = to address the issue
that it can never apply to NETCONF, = it seems that a possible strategy
would be to move both = instances to augmentations defined in
ietf-restconf-server...

That = said, to go along with some of your thinking from above, it's not
clear how an application would consume the = "required-or-optional"
configuration.  Case in point, = in the RESTCONF server based product
I'm working on, the = configuration for each client, which is defined
outside = the restconf-server-grouping tree, has descendants nodes like
"http-password" and "tls-trust-anchor", with meanings that, = if
defined, then the client MUST present said auth = credentials at that
protocol-layer.  IIRC, the code = doesn't check these flags at all.

So, = rather than moving both "required-or-optional" instances to
augmentations in ietf-restconf-server, maybe they can just be = deleted?

Yes I think so, = altough I haven't yet studied the restconf model in
detail.

I've updated my local copy, in both = TLS-server and HTTP-server.



Second, I assume that the idea is that the server uses the = config
params in "local-or-external" and the certificate = presented by the
client and after this step is either = accepted or rejected.  It is not
clear what is = supposed to happen if someone configures
"client-auth-defined-elsewhere".  I think it is better = to not define
this case, but (perhaps) keep the choice and = explain that other
modules can augment additional config = params here for other
authentication mechanisms.

Well that's just the thing, the = goal is to enable user-auth to NOT be
defined here. =  As the description statement in ietf-tls-server says:

=         "Configuring credentials = externally enables applications
=          to place client = authentication with client definitions,
=          rather then in a = part of a data model principally
=          concerned with = configuring the TLS transport.";

I totally agree with this.  I am questioning the = solution.  See above
for my proposal.

Ack.


Next, my = guess is that the intention is that if the cert was accepted
in the step above, it is checked in cert-to-name to see if a = user name
can be derived.

Yes.


In another thread you mentioned that if a local = cert is configured, it
seems redundant to also configure = the cert as a fingerprint in
cert-to-name.  I'm not = sure about this.  But perhaps you can use the
same = "map-type" and "name" leafs in the "client-cert" container?  It
is not as easy for the "truststore-reference"; perhaps you'd = have to
augment the truststore with these leafs in this = case.

In context, that = statement I made before is a relatively minor
objection. =  That said, I don't understand your proposal, are you
suggesting to recreate the essence of 'cert-to-name'? =  Another idea I
had was that the fingerprint could be = in a "union" with also a
truststore-reference, which is = only mildly better...

Aha, now = I understand your suggestion of making fingerprint optional.
I agree that this could work.  However, I assume it must = be used with
care.  If you know for sure that a = successful result from the
authentication mechanism means = that CA cert X has been used, you can
save some typing by = not configuring the fingerprint of X.  So the
question = is if it is worth it?

Yes, = saving typing is the gist of it, but I don't think handling with
care is needed or, rather, it's no more care.  As I = understand it, a
fingerprint would be redundant in the = common case, i.e., most configs
would not have to define a = fingerprint, so the optimization seems
worth it to me.

It would be interesting to hear = other opinions on this, esp. from
security people. =  Personally I can accept both alternatives.

I'll = discuss the issue in the presentation.

Kent // contributor



Separately, be aware that calculating an = x509c2n:tls-fingerprint is
not a simple copy/paste. =  That is, the command `openssl x509 -in
CERT.pem = -noout -sha256 -fingerprint` is close, but not exactly what
is needed.

Right; = you have to prefix this fingerprint with "04:".


/martin

= --Apple-Mail=_64BFF454-6D5E-42B8-83C3-906749C8F468-- From nobody Wed Nov 13 14:02:12 2019 Return-Path: <0100016e66c9b02d-382d9d6e-6d88-47ec-a117-5f38a3699fb1-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 63937120831 for ; Wed, 13 Nov 2019 14:02:09 -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 l_uVf0Z43J4M for ; Wed, 13 Nov 2019 14:02:06 -0800 (PST) Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F4098120830 for ; Wed, 13 Nov 2019 14:02:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1573682524; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=vRTb6tGl/I4fWhfzTJ1BPbm2hXnpXxFvpwz+J9Txjf8=; b=QO0ZWzb3v1fABq49C7sShXdfDxdJ6PDxiM/kgzXkR+1yFBKaIyg4L2yU9RvcYA1T CZRAs39qkZuE90GqTcoLbcdUwUFarvUSPmN5yNgkGIdbbLEioT/6wddZScpVG9kooxc Hir1hzCN5o20PvAC1eVA+gXPaWGvwj7ZGM4WXGaU= From: Kent Watsen Message-ID: <0100016e66c9b02d-382d9d6e-6d88-47ec-a117-5f38a3699fb1-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_63F7BFFB-920C-4349-BFCE-C5C9A87BD47B" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 13 Nov 2019 22:02:04 +0000 In-Reply-To: <20191113.135649.2218807015240802033.mbj@tail-f.com> Cc: "netconf@ietf.org" , Wang Haiguang To: Martin Bjorklund References: <20191113.135649.2218807015240802033.mbj@tail-f.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.11.13-54.240.8.96 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] crypto-types and keystore comments 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, 13 Nov 2019 22:02:10 -0000 --Apple-Mail=_63F7BFFB-920C-4349-BFCE-C5C9A87BD47B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Martin, > o Is the key-format there to support multiple formats for the same > kind of key (e.g., ssh key), or is it there to be able to have > different kinds of keys in the same list? (Or both?) >=20 > I.e., is the intentation that a client can freely pick any > private-key-format (that is supported by the server), regardless of > how the key is used? Firstly, see: = https://mailarchive.ietf.org/arch/msg/netconf/5Zpj8Xxh7bHvAJeQf2Lj0t6h8hg = That said, there are some limitations that are likely not represented = yet. For instance, an encrypted private key must use "identity = encrypted-private-key-format" and an encrypted symmetric key must use = "identity encrypted-symmetric-key-format", as there is no way to express = it otherwise. But your question is likely more regarding the other direction, for an = *unencrypted" asymmetric key, can a client arbitrarily choose one of the = *-private-key-format identities or "identity one-asymmetric-key-format"; = likewise, for an *unencrypted* symmetric key, can a client arbitrarily = use either "identity octet-string-key-format" or "identity = one-symmetric-key-format". The goal is for the use of OneAsymmetricKey and OneSymmetricKey formats = to be an advanced feature. As said above, these structures must be used = for encrypted keys, and should be used for unencrypted key (as the = structure carries security attributes not present in the raw formats), = but it's more likely that implementations will support the raw formats. My thoughts are that, if an implementation is updated to support for = One[A]SymmetricKey for encrypted keys, then letting a client optionally = use One[A]SymmetricKey for unencrypted keys isn't that big of an = implementation effort. Thus I suggest adding features called = "one-symmetric-key" and "one-asymmetric-key", and place if-feature = statements under these identities so that servers can express when they = support them. > o One idea that was floating around was to have separate keystore > lists for different things (see the ML archives, e.g. some mails in > the thread "crypto-types fallback strategy"). I.e. instead of the > current: >=20 > +--rw keystore > +--rw asymmetric-keys > | +--rw asymmetric-key* [name] >=20 >=20 > we would have something like: >=20 > +--rw keystores > +--rw ssh-keystore > | ... > +--rw tls-keystore // x509-keystore? > ... Right, but that approach was deemed not viable before. > If we don't have to support multiple formats for the same kind > of key, I don't think we need the key-format in this case. Maybe. > With the current design it is not obvious to me how I can find all > ssh keys, for example. That's because keys don't have to have a set purpose. For instance, an = IDevID shipped with the device could be used for either SSH or TLS. > This said, *if* we use a single generic list, I think the list in > the current model works fine. It is a bit complicated, but some > complexity is inevitable with a generic model like this. Yes and yes. > o iana- modules >=20 > The iana modules have a list of supported algorithms, e.g.: >=20 > list supported-asymmetric-algorithm >=20 > I mentioned this before - I don't think a global list like this is > sufficient. For example, perhaps my TLS code supports "secp521r1", > but my SSH code does not. Yes, well, this is a known problem (e.g., = https://github.com/netmod-wg/yang-next/issues/82 = ). I realize that = you're not specifically talking about feature statements, but it's = similar. One difference between #82 and this is that here, the = capabilities are presented in "config false" lists instead, which might = bring us to https://github.com/netmod-wg/yang-next/issues/41 = again... > And some random small things I noticed: >=20 > o ssh-public-key-format >=20 > The crypto model has: >=20 > identity ssh-public-key-formatp { > base "public-key-format"; > description > "The public key format described by RFC 4716."; > } >=20 > I think that this should be: >=20 > 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"; >=20 > Note that the public key format in 4716 is textual: >=20 > ---- BEGIN SSH2 PUBLIC KEY ---- > Header-tag ':' ' ' Header-value > BODY > ---- END SSH2 PUBLIC KEY ---- >=20 > Where BODY is: >=20 > The body of a public key file is the base64 encoded ([RFC2045]) > public key data as specified by [RFC4253], Section 6.6: >=20 > string certificate or public key format identifier > byte[n] key/certificate data >=20 > So with your current definition we would take this textual format > (that has the key base64-encoded), and base64 encode the whole > thing (includign the already base64-encoded key). I will say that the definition above was given because it is the only = *standards* based key that `openssh` can output (i.e., `ssh-keygen -e = [-m RFC4716] -f `). That said, if you refer to the link I provided at top, it is my belief = that the "key-format" node may be extended to support alternate = encodings (e.g., DER vs PEM and, potentially, CMS vs multi-part PEM). = To this end, perhaps we could support both the 4716 and 4253 formats.=20 > o subject-public-key-info-format >=20 > The crypto model has: >=20 > identity subject-public-key-info-format { > base "public-key-format"; > description > "A SubjectPublicKeyInfo (from RFC 5280)."; > } >=20 > Should this be "DER encoded"? >=20 > (this and other defintions have references to RFCs in the > description; they should be moved to proper "reference" statements) Yes. I put together these definitions in as a test/protocol to gauge = viability with the plan to enhance the definitions if the WG committed = to the approach. I just added some "FIXME" comments to my local copy. > o iana-hash-algs >=20 > This module has a bunch of shake-*: >=20 > enum shake-224 { > value 7; > description > "The SHA3 algorithm with 224-bits output."; >=20 > I think this should be "sha3-224" etc. >=20 > (there are just two shake hash functions defined; shake 128 & 256, > and they have variable output) >=20 > (and BTW, FIPS PUB 202 doesn't define sha3-128) I don't know. These are are/were specified by my co-author Haiguang = (CC-ed). Haiguang, can you comment? Kent // contributor --Apple-Mail=_63F7BFFB-920C-4349-BFCE-C5C9A87BD47B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii


Hi = Martin,


o  Is the = key-format there to support multiple formats for the same
=   kind of key (e.g., ssh key), or is it there to be able to = have
  different kinds of keys in the same = list?  (Or both?)

  I.e., = is the intentation that a client can freely pick any
=   private-key-format (that is supported by the server), = regardless of
  how the key is used?


That said, there = are some limitations that are likely not represented yet.  For = instance, an encrypted private key must use = "identity encrypted-private-key-format" and an encrypted symmetric = key must use "identity encrypted-symmetric-key-format", as there is = no way to express it otherwise.

But = your question is likely more regarding the other direction, for an = *unencrypted" asymmetric key, can a client arbitrarily choose one of the = *-private-key-format identities or = "identity one-asymmetric-key-format"; likewise, for an = *unencrypted* symmetric key, can a client arbitrarily use either = "identity octet-string-key-format" or "identity = one-symmetric-key-format".

The goal = is for the use of OneAsymmetricKey and OneSymmetricKey formats = to be an advanced feature.  As said above, these structures must be = used for encrypted keys, and should be used for unencrypted key (as the = structure carries security attributes not present in the raw formats), = but it's more likely that implementations will support the raw = formats.

My thoughts are that, if an = implementation is updated to support for One[A]SymmetricKey for = encrypted keys, then letting a client optionally use One[A]SymmetricKey = for unencrypted keys isn't that big of an implementation effort. =  Thus I suggest adding features called "one-symmetric-key" and = "one-asymmetric-key", and place if-feature statements under these = identities so that servers can express when they support = them.


o  One = idea that was floating around was to have separate keystore
=   lists for different things (see the ML archives, e.g. some = mails in
  the thread "crypto-types fallback = strategy").  I.e. instead of the
=   current:

  +--rw = keystore
     +--rw = asymmetric-keys
     | =  +--rw asymmetric-key* [name]


  we would have something like:

  +--rw keystores
=      +--rw ssh-keystore
=      |  ...
=      +--rw tls-keystore  // = x509-keystore?
=         ...

Right, = but that approach was deemed not viable before.


  If we don't have to support = multiple formats for the same kind
  of key, I = don't think we need the key-format in this = case.

Maybe.


  With the current design it is not obvious to me how I = can find all
  ssh keys, for example.

That's = because keys don't have to have a set purpose.  For instance, an = IDevID shipped with the device could be used for either SSH or = TLS.


  This = said, *if* we use a single generic list, I think the list in
  the current model works fine.  It is a bit = complicated, but some
  complexity is = inevitable with a generic model like this.

Yes = and yes.



o   iana- modules

 The iana modules have a list of supported algorithms, = e.g.:

=       list = supported-asymmetric-algorithm

 I = mentioned this before - I don't think a global list like this is
 sufficient.  For example, perhaps my TLS code = supports "secp521r1",
 but my SSH code does not.

Yes, = well, this is a known problem (e.g., https://github.com/netmod-wg/yang-next/issues/82). =  I realize that you're not specifically talking about feature = statements, but it's similar.  One difference between #82 and this = is that here, the capabilities are presented in "config false" lists = instead, which might bring us to https://github.com/netmod-wg/yang-next/issues/41 again= ...



And some random small things I noticed:

o  ssh-public-key-format

=  The crypto model has:

=    identity ssh-public-key-formatp {
=      base "public-key-format";
=      description
=        "The public key format = described by RFC 4716.";
   }

 I think that this should be:

   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
=             &n= bsp;     identifier
=         byte[n] =   key/certificate data.";
=    reference
=      "RFC 4253: The Secure Shell (SSH) = Transport Layer
=             &n= bsp;   Protocol";

=  Note that the public key format in 4716 is textual:

   ---- BEGIN SSH2 PUBLIC KEY = ----
   Header-tag ':' ' ' Header-value
   BODY
   ---- = END SSH2 PUBLIC KEY ----

 Where BODY = is:

  The body of a public key = file is the base64 encoded ([RFC2045])
  public = key data as specified by [RFC4253], Section 6.6:

        string =    certificate or public key format identifier
        byte[n] =   key/certificate data

 So = with your current definition we would take this textual format
 (that has the key base64-encoded), and base64 encode = the whole
 thing (includign the already = base64-encoded key).

I will say that the definition above was given = because it is the only *standards* based key that `openssh` can output = (i.e., `ssh-keygen -e [-m RFC4716] -f = <private-key-file>`).

That = said, if you refer to the link I provided at top, it is my belief that = the "key-format" node may be extended to support alternate encodings = (e.g., DER vs PEM and, potentially, CMS vs multi-part PEM).  To = this end, perhaps we could support both the 4716 and 4253 = formats. 



o =  subject-public-key-info-format

=  The crypto model has:

=    identity subject-public-key-info-format {
=      base "public-key-format";
=      description
=        "A SubjectPublicKeyInfo (from = RFC 5280).";
   }

 Should this be "DER encoded"?

 (this and other defintions have references to RFCs in = the
 description; they should be moved to proper = "reference" statements)

Yes.  I put together these definitions in as = a test/protocol to gauge viability with the plan to enhance the = definitions if the WG committed to the approach.   I just added = some "FIXME" comments to my local copy.



o  iana-hash-algs

=  This module has a bunch of shake-*:

=      enum shake-224 {
=        value 7;
=        description
=          "The SHA3 = algorithm with 224-bits output.";

 I = think this should be "sha3-224" etc.

=  (there are just two shake hash functions defined; shake 128 & = 256,
 and they have variable output)
 (and BTW, FIPS PUB 202 doesn't define sha3-128)

I = don't know.  These are are/were specified by my co-author Haiguang = (CC-ed).   Haiguang, can you comment?


Kent // contributor


= --Apple-Mail=_63F7BFFB-920C-4349-BFCE-C5C9A87BD47B-- From nobody Wed Nov 13 19:46:09 2019 Return-Path: <0100016e68049a12-bcb2acea-a4e2-42f9-8eab-05bab261d5dd-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 1A57E1200B1; Wed, 13 Nov 2019 19:46:08 -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 0U-2-yKBgKxS; Wed, 13 Nov 2019 19:46:06 -0800 (PST) Received: from a8-64.smtp-out.amazonses.com (a8-64.smtp-out.amazonses.com [54.240.8.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC95E120048; Wed, 13 Nov 2019 19:46:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1573703162; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=TZTU7vPYXYMA/VtFd5CpmvmX3K8c7SDyCXJb47psUtQ=; b=lnqRu20BkTuXUcXFtOcyU+vAKl0Xng+QCLAxvlZFiN3+XN3Nfk06OqF68wx9BZnX pzVjLrYskCidqFHiCZMPtUdWHB7f3JvGTvsCJ1UkbZVRO6BCSBizNPGOJkOrxpEHzaS ldxu54V2gsTBj03j2GaTvJY/Mqc6xL3UrtINszxg= From: Kent Watsen Message-ID: <0100016e68049a12-bcb2acea-a4e2-42f9-8eab-05bab261d5dd-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_371952EF-E87C-4A69-B753-73B32BF1194A" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 14 Nov 2019 03:46:02 +0000 In-Reply-To: Cc: tom petch , "Rob Wilton (rwilton)" , Martin Bjorklund , "httpbis-chairs@ietf.org" , "netconf@ietf.org" To: Qin Wu References: X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.11.14-54.240.8.64 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04 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, 14 Nov 2019 03:46:08 -0000 --Apple-Mail=_371952EF-E87C-4A69-B753-73B32BF1194A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Folks, It seems that the rough consensus is to rename the draft. Being a WG = document and me, a dutiful Editor, I'm happy to oblige. Assuming = adoption can proceed with this understanding, I'll make the change when = submitting the -00. As for the specific name, there is no great = fallback, but perhaps s/http/web/ or s/http/rest/ (i.e., = draft-ietf-netconf-web-client-server)? We can decide in Singapore. As the dissenter in the rough, let the record show that there is no = concrete technical reason to rename anything, and efforts to get = clarifications have be left unanswered. If there are issues, renaming = won't make them go away and, in any case, renaming to anything other = than the name of the protocol layer is both unhelpful and confusing. I = hereby request that the shepherd writeup captures this sentiment as = well. Kent // contributor --Apple-Mail=_371952EF-E87C-4A69-B753-73B32BF1194A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Folks,

It seems that the rough consensus is to = rename the draft.   Being a WG document and me, a dutiful Editor, = I'm happy to oblige.   Assuming adoption can proceed with this = understanding, I'll make the change when submitting the -00.  As = for the specific name, there is no great fallback, but perhaps = s/http/web/ or s/http/rest/ (i.e., = draft-ietf-netconf-web-client-server)?   We can decide in = Singapore.

As = the dissenter in the rough, let the record show that there is no = concrete technical reason to rename anything, and efforts to get = clarifications have be left unanswered.  If there are issues, = renaming won't make them go away and, in any case, renaming to anything = other than the name of the protocol layer is both unhelpful and = confusing.  I hereby request that the shepherd writeup captures = this sentiment as well.

Kent // contributor

= --Apple-Mail=_371952EF-E87C-4A69-B753-73B32BF1194A-- From nobody Wed Nov 13 23:52:30 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF041208E7 for ; Wed, 13 Nov 2019 23:52:28 -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 aigrIqj5VLUJ for ; Wed, 13 Nov 2019 23:52:26 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B720A1208D6 for ; Wed, 13 Nov 2019 23:52:25 -0800 (PST) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 291D91AE0312; Thu, 14 Nov 2019 08:52:23 +0100 (CET) Date: Thu, 14 Nov 2019 08:51:52 +0100 (CET) Message-Id: <20191114.085152.69723351117040013.mbj@tail-f.com> To: kent+ietf@watsen.net Cc: netconf@ietf.org From: Martin Bjorklund In-Reply-To: <0100016e661a2f48-26561fed-a533-4aec-8ad1-d68582b82b39-000000@email.amazonses.com> References: <0100016e4d8323b0-2a182947-485d-43e6-908c-13bc5ad2f210-000000@email.amazonses.com> <20191111.110013.2019956803552089416.mbj@tail-f.com> <0100016e661a2f48-26561fed-a533-4aec-8ad1-d68582b82b39-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] client identification in ietf-netconf-server 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, 14 Nov 2019 07:52:28 -0000 Kent Watsen wrote: > Hi Martin, > > > > Martin Bjorklund wrote: > > > > Hi, > > > > Kent Watsen wrote: > >> > >> Hi Martin, > >> > >> [Not trimming down because too much context would be lost.] > >> > >> > >>>>> The ietf-netconf-server module has this: > >>>>> > >>>>> grouping netconf-server-grouping { > >>>>> ... > >>>>> container client-identification { > >>>>> ... > >>>>> container cert-maps { > >>>>> when "../../../../tls"; > >>>>> uses x509c2n:cert-to-name; > >>>>> ... > >>>>> } > >>>>> } > >>>>> } > >>>>> > >>>>> Note the "when" expression. This means that the grouping has a strong > >>>>> depency on where is it used. We should try to avoid such a design. > >>>> > >>>> > >>>> Would this be better? > >>>> > >>>> OLD > >>>> when "../../../../tls"; > >>>> > >>>> NEW > >>>> if-feature "tls-listen or tls-call-home"; > >>> > >>> Yes, but see below. > >>> > >>> > >>>>> But should't this cert-to-name list be available when x509-certs are > >>>>> used also with SSH? > >>>> > >>>> Hmmm. I'd assumed that, with RFC 6187, the username was still passed > >>>> as its own field, but I see this in Section 4: > >>>> > >>>> For the purposes of user authentication, the mapping between > >>>> certificates and user names is left as an implementation and > >>>> configuration issue for implementers and system administrators. > >>> > >>> If the username was used as identification it would mean that with a > >>> valid cert I could present myself as any user! > >>> > >>>> So you may be right about that. I only ever looked at RFC 6187 from > >>>> the perspective of the server presenting an IDevID certificate. But, > >>>> assuming it's true, then perhaps this: > >>>> > >>>> NEWEST: > >>>> if-feature "tls-listen or tls-call-home or sshcmn:ssh-x509-certs"; > >>> > >>> Ok. > >>> > >>> This gives: > >>> > >>> grouping netconf-server-grouping { > >>> description ...; > >>> container client-identification { > >>> description > >>> "Specifies a mapping through which clients MAY be identified > >>> (i.e., the NETCONF username) from a supplied certificate. > >>> Note that a client MAY alternatively be identified via an > >>> alternate authentication scheme."; > >>> container cert-maps { > >>> if-feature "tls-listen or tls-call-home or sshcmn:ssh-x509-certs"; > >> > >> Yes. > >> > >>> But since the description of the "client-identification" says that it > >>> is used only with certificates, perhaps that container's name should > >>> reflect this, and the if-feature statement moved to that container? > >>> Perhaps: > >>> > >>> container client-cert-identification > >>> if-feature "tls-listen or tls-call-home or sshcmn:ssh-x509-certs"; > >>> > >>> and also perhaps remove 'cert-maps', and use the cert-to-name grouping > >>> directly here? > >> > >> Good. My only hesitation is that someday there may be a need for > >> another way to identify clients, but that sounds too far out (even for > >> me) to squabble over. But a better name is needed. > >> "cert-based-client-identification" would be more accurate, but that > >> seems overly long. Looking at a snippet of config might help... > >> > >> netconf-server-parameters : { > >> something-here : [ > >> { > >> cert-to-name : { ... } > >> cert-to-name : { ... }, > >> ... > >> cert-to-name : { ... } > >> } > >> ] > >> } > >> > >> How about "cert-to-name-mappings"? ( know, almost the same length, > >> but half the number of syllables!). But that name leaves out the word > >> "identity", which is may be important in security circles, so maybe > >> "client-identity-mappings"? > > > > I think this name is as generic as "client-identification". The best > > so far imo is "cert-based-client-identification". A bit long, but > > descripitive. > > Actually, I think we should go back to "client-identification" now that raw-public-key and pre-shared/pairwise-symmetric key (PSK) has been added as alternate ways that TLS clients and servers may identify themselves and authenticate peers. Thus it seems that there is a need to map usernames from things other than just certificates. I think I'll have to see how that works out. But if the container is more general than just client certificates, then the description text needs to be updated. > >>>>> The current data model for ssh specifies certs on > >>>>> a per-user basis. But this requires lots of configuration in the case > >>>>> that the cert encodes the user name (even though the name is in the > >>>>> cert you have to configure each user on each device). I suggest we > >>>>> align the model for SSH with the TLS model for cert identification. > >>>> > >>>> We certainly want to factor out configuration where possible. I'd > >>>> need to look into this more. Perhaps you can send a diff? > >>> > >>> Today we have under 'ssh-server-parameters/client-authentication': > >>> > >>> +--:(local) {local-client-auth-supported}? > >>> +--rw users > >>> +--rw user* [name] > >>> +--rw name string > >>> +--rw password? ianach:crypt-hash > >>> +--rw host-keys! > >>> | +--rw (local-or-truststore) > >>> | +--:(local) {local-definitions-supported}? > >>> | | +--rw local-definition > >>> | | +--rw host-key* ct:ssh-host-key > >>> | | +--rw cert* trust-anchor-cert-cms > >>> | | +---n certificate-expiration > >>> | | +-- expiration-date yang:date-and-time > >> > >> Not to take away from your point, but the previous three lines don't > >> exist in the model. > >> > >>> | +--:(truststore) {truststore-supported,ssh-host-keys}? > >>> | +--rw truststore-reference? ts:host-keys-ref > >>> +--rw ca-certs! {sshcmn:ssh-x509-certs}? > >>> | +--rw (local-or-truststore) > >>> | +--:(local) {local-definitions-supported}? > >>> | | +--rw local-definition > >>> | | +--rw cert* trust-anchor-cert-cms > >>> | | +---n certificate-expiration > >>> | | +-- expiration-date yang:date-and-time > >>> | +--:(truststore) {truststore-supported,x509-certificates}? > >>> | +--rw truststore-reference? ts:certificates-ref > >>> +--rw client-certs! {sshcmn:ssh-x509-certs}? > >>> +--rw (local-or-truststore) > >>> +--:(local) {local-definitions-supported}? > >>> | +--rw local-definition > >>> | +--rw cert* trust-anchor-cert-cms > >>> | +---n certificate-expiration > >>> | +-- expiration-date yang:date-and-time > >>> +--:(truststore) {truststore-supported,x509-certificates}? > >>> +--rw truststore-reference? ts:certificates-ref > >>> > >>> I think host-keys, ca-certs and client-certs should be moved out of > >>> the user list: > >>> > >>> +--:(local) {local-client-auth-supported}? > >>> +--rw users > >>> | +--rw user* [name] > >>> | +--rw name string > >>> | +--rw password? ianach:crypt-hash > >>> +--rw host-keys! > >>> | +--rw (local-or-truststore) > >>> | +--:(local) {local-definitions-supported}? > >>> | | +--rw local-definition > >>> | | +--rw host-key* ct:ssh-host-key > >>> | | +--rw cert* trust-anchor-cert-cms > >>> | | +---n certificate-expiration > >>> | | +-- expiration-date yang:date-and-time > >> > >> Again, not to take away from your point, but the previous three lines > >> don't exist in the model. > >> > >>> | +--:(truststore) {truststore-supported,ssh-host-keys}? > >>> | +--rw truststore-reference? ts:host-keys-ref > >>> +--rw ca-certs! {sshcmn:ssh-x509-certs}? > >>> | +--rw (local-or-truststore) > >>> | +--:(local) {local-definitions-supported}? > >>> | | +--rw local-definition > >>> | | +--rw cert* trust-anchor-cert-cms > >>> | | +---n certificate-expiration > >>> | | +-- expiration-date yang:date-and-time > >>> | +--:(truststore) {truststore-supported,x509-certificates}? > >>> | +--rw truststore-reference? ts:certificates-ref > >>> +--rw client-certs! {sshcmn:ssh-x509-certs}? > >>> +--rw (local-or-truststore) > >>> +--:(local) {local-definitions-supported}? > >>> | +--rw local-definition > >>> | +--rw cert* trust-anchor-cert-cms > >>> | +---n certificate-expiration > >>> | +-- expiration-date yang:date-and-time > >>> +--:(truststore) {truststore-supported,x509-certificates}? > >>> +--rw truststore-reference? ts:certificates-ref > >> > >> I agree that "ca-certs" and "client-certs" should be pulled out (as > >> they are in ietf-tls-server), but I'm unsure if "host-keys" can be, at > >> least not unless we introduce something like "host-key-to-name" maps, > >> right? > >> > >> For now, I only pulled out "ca-certs" and "client-certs". > > > > Hmm, I realize that I have misunderstood 'host-keys' here. How > > exactly is this supposed to be used? This is the client > > authentication part of a server. How is the *host* key used here by > > the server? I mean, the client doesn't present a host key to the > > server, so I don't understand what this is. > > It seems that I've been overzealous with the term "host-key" here. In SSH, a "host-key" is a special term for the server's public key. Clients may also authenticate using a public key, but there isn't a special term for that case. RFC 4252 states that clients can authenticate using "publickey", "password", and "hostbased". Per RFC 6187, section 1, 1st paragraph, the "publickey" algorithm is is also used for X.509 certificates (e.g., x509v3-rsa2048-sha256). So what is the conclusion? Remove host-key here? Or was the intention that this is the user's public key? /martin > >>> But also here I think that the choice "local-or-external" isn't > >>> ideal. I think that a system that implements some "external" > >>> mechanism should/would augement this data model with specific nodes > >>> for that mechanism. As a simplistic example: > >>> > >>> augment /netconf-server/.../client-authentication { > >>> leaf use-host-keys-in-filesystem { > >>> leaf boolean; > >>> } > >>> } > >>> > >>> In this case, requiring the client to configure both this new leaf and > >>> "client-auth-defined-elsewhere" seems redundant and non-intuitive. > >> > >> Agreed. > >> > >>> Another case is a system that *always* use the filesystem host keys. > >>> It would simply just always do that, and again, requiring the client > >>> to configure "client-auth-defined-elsewhere" seems incorrect. > >> > >> Agreed. > >> > >>> So my suggestion is to remove the choice "local-or-external" and > >>> remove the external case, and instead document that (i) systems may > >>> use some other hard-wired mechanism or (ii) other modules can augment > >>> this container with additional control parameters for other > >>> mechanisms. > >> > >> Agree in principle, but unsure about implementation. One thing > >> important to me you didn't mention is having the "local" configuration > >> gated by a "feature" statement. So, do we float the > >> "local-client-auth-supported" (renamed appropriately) up to the > >> "client-authentication" container? If so, would that incorrectly > >> cover the "supported-authentication-methods" descendent? > >> Suggestions? > > > > Perhaps just add the if-feature to the containers "users", "ca-certs", > > "client-certs"? > > Sounds okay. I've updated my local copy, in all of SSH, TLS, and HTTP. > > > > >>>>> For TLS, the data model has the following structure: > >>>>> > >>>>> +--rw netconf-server > >>>>> +--rw listen! {ssh-listen or tls-listen}? > >>>>> +--rw idle-timeout? uint16 > >>>>> +--rw endpoint* [name] > >>>>> +--rw name string > >>>>> +--rw (transport) > >>>>> ... > >>>>> +--:(tls) {tls-listen}? > >>>>> > >>>>> [ reset indentation to make the diagram easier to read ] > >>>>> > >>>>> +--rw tls > >>>>> +--rw tcp-server-parameters > >>>>> ... > >>>>> +--rw tls-server-parameters > >>>>> | +--rw server-identity > >>>>> ... > >>>>> | +--rw client-authentication! > >>>>> | | +--rw (required-or-optional) > >>>>> | | | +--:(required) > >>>>> | | | | +--rw required? empty > >>>>> | | | +--:(optional) > >>>>> | | | +--rw optional? empty > >>>>> | | +--rw (local-or-external) > >>>>> | | +--:(local) {local-client-auth-supported}? > >>>>> | | | +--rw ca-certs! {ts:x509-certificates}? > >>>>> | | | | +--rw (local-or-truststore) > >>>>> | | | | +--:(local) {local-definitions-supported}? > >>>>> | | | | | +--rw local-definition > >>>>> | | | | | +--rw cert* trust-anchor-cert-cms > >>>>> | | | | | +---n certificate-expiration > >>>>> | | | | | +-- expiration-date > >>>>> | | | | | yang:date-and-time > >>>>> | | | | +--:(truststore) > >>>>> | | | | {truststore-supported,x509-certificates}? > >>>>> | | | | +--rw truststore-reference? > >>>>> | | | | ts:certificates-ref > >>>>> | | | +--rw client-certs! {ts:x509-certificates}? > >>>>> | | | +--rw (local-or-truststore) > >>>>> | | | +--:(local) {local-definitions-supported}? > >>>>> | | | | +--rw local-definition > >>>>> | | | | +--rw cert* trust-anchor-cert-cms > >>>>> | | | | +---n certificate-expiration > >>>>> | | | | +-- expiration-date > >>>>> | | | | yang:date-and-time > >>>>> | | | +--:(truststore) > >>>>> | | | {truststore-supported,x509-certificates}? > >>>>> | | | +--rw truststore-reference? > >>>>> | | | ts:certificates-ref > >>>>> | | +--:(external) > >>>>> | | {external-client-auth-supported}? > >>>>> | | +--rw client-auth-defined-elsewhere? > >>>>> | | empty > >>>>> ... > >>>>> +--rw netconf-server-parameters > >>>>> +--rw client-identification > >>>>> +--rw cert-maps > >>>>> +--rw cert-to-name* [id] > >>>>> +--rw id uint32 > >>>>> +--rw fingerprint > >>>>> | x509c2n:tls-fingerprint > >>>>> +--rw map-type identityref > >>>>> +--rw name string > >>>> > >>>> > >>>> > >>>> > >>>>> It is not clear how this is used by the server to end up either with > >>>>> an authenticated user name or failed authentication. > >>>> > >>>> Okay, let's fix that. > >>>> > >>>> > >>>>> First of all, how is the "required-or-optional" choice used in a > >>>>> NETCONF server? What happens if an operation configures this to > >>>>> "optional"? (side note: why is this a choice of empty leafs instead > >>>>> of a leaf?) > >>>> > >>>> Hmmm, this 'choice' seems unneeded for NETCONF. The "choice" is > >>>> coming from the ietf-tls-server, and a similar "choice" is in > >>>> ietf-http-server. It was put there, in part, for RESTCONF, as > >>>> user-auth can occur at either (or both!) protocol layers... > >>> > >>> Ok. Yes, the RESTCONF auth mechanism is interesting. Let's discuss > >>> that in a separate thread. > >> > >> Okay. For now, I'll leave the "required-or-optional" in both > >> ietf-tls-server and ietf-http-server. However, to address the issue > >> that it can never apply to NETCONF, it seems that a possible strategy > >> would be to move both instances to augmentations defined in > >> ietf-restconf-server... > >> > >> That said, to go along with some of your thinking from above, it's not > >> clear how an application would consume the "required-or-optional" > >> configuration. Case in point, in the RESTCONF server based product > >> I'm working on, the configuration for each client, which is defined > >> outside the restconf-server-grouping tree, has descendants nodes like > >> "http-password" and "tls-trust-anchor", with meanings that, if > >> defined, then the client MUST present said auth credentials at that > >> protocol-layer. IIRC, the code doesn't check these flags at all. > >> > >> So, rather than moving both "required-or-optional" instances to > >> augmentations in ietf-restconf-server, maybe they can just be deleted? > > > > Yes I think so, altough I haven't yet studied the restconf model in > > detail. > > I've updated my local copy, in both TLS-server and HTTP-server. > > > > >>>>> Second, I assume that the idea is that the server uses the config > >>>>> params in "local-or-external" and the certificate presented by the > >>>>> client and after this step is either accepted or rejected. It is not > >>>>> clear what is supposed to happen if someone configures > >>>>> "client-auth-defined-elsewhere". I think it is better to not define > >>>>> this case, but (perhaps) keep the choice and explain that other > >>>>> modules can augment additional config params here for other > >>>>> authentication mechanisms. > >>>> > >>>> Well that's just the thing, the goal is to enable user-auth to NOT be > >>>> defined here. As the description statement in ietf-tls-server says: > >>>> > >>>> "Configuring credentials externally enables applications > >>>> to place client authentication with client definitions, > >>>> rather then in a part of a data model principally > >>>> concerned with configuring the TLS transport."; > >>> > >>> I totally agree with this. I am questioning the solution. See above > >>> for my proposal. > >> > >> Ack. > >> > >> > >>>>> Next, my guess is that the intention is that if the cert was accepted > >>>>> in the step above, it is checked in cert-to-name to see if a user name > >>>>> can be derived. > >>>> > >>>> Yes. > >>>> > >>>> > >>>>> In another thread you mentioned that if a local cert is configured, it > >>>>> seems redundant to also configure the cert as a fingerprint in > >>>>> cert-to-name. I'm not sure about this. But perhaps you can use the > >>>>> same "map-type" and "name" leafs in the "client-cert" container? It > >>>>> is not as easy for the "truststore-reference"; perhaps you'd have to > >>>>> augment the truststore with these leafs in this case. > >>>> > >>>> In context, that statement I made before is a relatively minor > >>>> objection. That said, I don't understand your proposal, are you > >>>> suggesting to recreate the essence of 'cert-to-name'? Another idea I > >>>> had was that the fingerprint could be in a "union" with also a > >>>> truststore-reference, which is only mildly better... > >>> > >>> Aha, now I understand your suggestion of making fingerprint optional. > >>> I agree that this could work. However, I assume it must be used with > >>> care. If you know for sure that a successful result from the > >>> authentication mechanism means that CA cert X has been used, you can > >>> save some typing by not configuring the fingerprint of X. So the > >>> question is if it is worth it? > >> > >> Yes, saving typing is the gist of it, but I don't think handling with > >> care is needed or, rather, it's no more care. As I understand it, a > >> fingerprint would be redundant in the common case, i.e., most configs > >> would not have to define a fingerprint, so the optimization seems > >> worth it to me. > > > > It would be interesting to hear other opinions on this, esp. from > > security people. Personally I can accept both alternatives. > > I'll discuss the issue in the presentation. > > Kent // contributor > > > > > >> Separately, be aware that calculating an x509c2n:tls-fingerprint is > >> not a simple copy/paste. That is, the command `openssl x509 -in > >> CERT.pem -noout -sha256 -fingerprint` is close, but not exactly what > >> is needed. > > > > Right; you have to prefix this fingerprint with "04:". > > > > > > /martin > From nobody Thu Nov 14 01:06:36 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD3C91208A5 for ; Thu, 14 Nov 2019 01:06:34 -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 Rio2IGbYu_yL for ; Thu, 14 Nov 2019 01:06:31 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFF4120232 for ; Thu, 14 Nov 2019 01:06:31 -0800 (PST) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id B2AF41AE0312; Thu, 14 Nov 2019 10:06:29 +0100 (CET) Date: Thu, 14 Nov 2019 10:05:58 +0100 (CET) Message-Id: <20191114.100558.1371995383202419404.mbj@tail-f.com> To: kent@watsen.net Cc: netconf@ietf.org, wang.haiguang.shieldlab@huawei.com From: Martin Bjorklund In-Reply-To: <0100016e66c9b02d-382d9d6e-6d88-47ec-a117-5f38a3699fb1-000000@email.amazonses.com> References: <20191113.135649.2218807015240802033.mbj@tail-f.com> <0100016e66c9b02d-382d9d6e-6d88-47ec-a117-5f38a3699fb1-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] crypto-types and keystore comments 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, 14 Nov 2019 09:06:35 -0000 Kent Watsen wrote: > > > Hi Martin, > > > > o Is the key-format there to support multiple formats for the same > > kind of key (e.g., ssh key), or is it there to be able to have > > different kinds of keys in the same list? (Or both?) > > > > I.e., is the intentation that a client can freely pick any > > private-key-format (that is supported by the server), regardless of > > how the key is used? > > Firstly, see: > https://mailarchive.ietf.org/arch/msg/netconf/5Zpj8Xxh7bHvAJeQf2Lj0t6h8hg > > > That said, there are some limitations that are likely not represented > yet. For instance, an encrypted private key must use "identity > encrypted-private-key-format" and an encrypted symmetric key must use > "identity encrypted-symmetric-key-format", as there is no way to > express it otherwise. > > But your question is likely more regarding the other direction, for an > *unencrypted" asymmetric key, can a client arbitrarily choose one of > the *-private-key-format identities or "identity > one-asymmetric-key-format"; likewise, for an *unencrypted* symmetric > key, can a client arbitrarily use either "identity > octet-string-key-format" or "identity one-symmetric-key-format". > > The goal is for the use of OneAsymmetricKey and OneSymmetricKey > formats to be an advanced feature. As said above, these structures > must be used for encrypted keys, and should be used for unencrypted > key (as the structure carries security attributes not present in the > raw formats), but it's more likely that implementations will support > the raw formats. > > My thoughts are that, if an implementation is updated to support for > One[A]SymmetricKey for encrypted keys, then letting a client > optionally use One[A]SymmetricKey for unencrypted keys isn't that big > of an implementation effort. Thus I suggest adding features called > "one-symmetric-key" and "one-asymmetric-key", and place if-feature > statements under these identities so that servers can express when > they support them. Suppose I want to configure a ssh host-key as the server-identity for my NETCONF server. Is the intention that a client can pick either "ssh-public-key-format" or "subject-public-key-info-format", and the server must support both? > > o One idea that was floating around was to have separate keystore > > lists for different things (see the ML archives, e.g. some mails in > > the thread "crypto-types fallback strategy"). I.e. instead of the > > current: > > > > +--rw keystore > > +--rw asymmetric-keys > > | +--rw asymmetric-key* [name] > > > > > > we would have something like: > > > > +--rw keystores > > +--rw ssh-keystore > > | ... > > +--rw tls-keystore // x509-keystore? > > ... > > Right, but that approach was deemed not viable before. > > > > If we don't have to support multiple formats for the same kind > > of key, I don't think we need the key-format in this case. > > Maybe. > > > > With the current design it is not obvious to me how I can find all > > ssh keys, for example. > > That's because keys don't have to have a set purpose. For instance, > an IDevID shipped with the device could be used for either SSH or TLS. > > > > This said, *if* we use a single generic list, I think the list in > > the current model works fine. It is a bit complicated, but some > > complexity is inevitable with a generic model like this. > > Yes and yes. > > > > > > o iana- modules > > > > The iana modules have a list of supported algorithms, e.g.: > > > > list supported-asymmetric-algorithm > > > > I mentioned this before - I don't think a global list like this is > > sufficient. For example, perhaps my TLS code supports "secp521r1", > > but my SSH code does not. > > Yes, well, this is a known problem (e.g., > https://github.com/netmod-wg/yang-next/issues/82 > ). That is quite different. You're using a normal config false list for this (which is fine), but I don't think you can use a single global list like this. > I realize that > you're not specifically talking about feature statements, but it's > similar. One difference between #82 and this is that here, the > capabilities are presented in "config false" lists instead, which > might bring us to https://github.com/netmod-wg/yang-next/issues/41 > again... > > > > > And some random small things I noticed: > > > > o ssh-public-key-format > > > > The crypto model has: > > > > identity ssh-public-key-formatp { > > base "public-key-format"; > > description > > "The public key format described by RFC 4716."; > > } > > > > I think that this should be: > > > > 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"; > > > > Note that the public key format in 4716 is textual: > > > > ---- BEGIN SSH2 PUBLIC KEY ---- > > Header-tag ':' ' ' Header-value > > BODY > > ---- END SSH2 PUBLIC KEY ---- > > > > Where BODY is: > > > > The body of a public key file is the base64 encoded ([RFC2045]) > > public key data as specified by [RFC4253], Section 6.6: > > > > string certificate or public key format identifier > > byte[n] key/certificate data > > > > So with your current definition we would take this textual format > > (that has the key base64-encoded), and base64 encode the whole > > thing (includign the already base64-encoded key). > > I will say that the definition above was given because it is the only > *standards* based key that `openssh` can output (i.e., `ssh-keygen -e > [-m RFC4716] -f `). With my proposal you can take the output of this openssh command and copy & paste the base64-encoded data from this output to a YANG node using ssh-public-key-format. With your proposal you have to copy the entire output, base64 encode it *again*, and then copy & paste that result to the YANG node. > That said, if you refer to the link I provided at top, it is my belief > that the "key-format" node may be extended to support alternate > encodings (e.g., DER vs PEM and, potentially, CMS vs multi-part PEM). > To this end, perhaps we could support both the 4716 and 4253 formats. Do we really want to go there? This is already quite complex, and having a multitude of optional formats for the same thing may make things even more complex, to understand and get right. > > o subject-public-key-info-format > > > > The crypto model has: > > > > identity subject-public-key-info-format { > > base "public-key-format"; > > description > > "A SubjectPublicKeyInfo (from RFC 5280)."; > > } > > > > Should this be "DER encoded"? > > > > (this and other defintions have references to RFCs in the > > description; they should be moved to proper "reference" statements) > > Yes. I put together these definitions in as a test/protocol to gauge > viability with the plan to enhance the definitions if the WG committed > to the approach. I just added some "FIXME" comments to my local copy. Ok. > > o iana-hash-algs > > > > This module has a bunch of shake-*: > > > > enum shake-224 { > > value 7; > > description > > "The SHA3 algorithm with 224-bits output."; > > > > I think this should be "sha3-224" etc. > > > > (there are just two shake hash functions defined; shake 128 & 256, > > and they have variable output) > > > > (and BTW, FIPS PUB 202 doesn't define sha3-128) > > I don't know. These are are/were specified by my co-author Haiguang > (CC-ed). Haiguang, can you comment? > > > Kent // contributor > > /martin From nobody Thu Nov 14 01:14:40 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44333120232; Thu, 14 Nov 2019 01:14:39 -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 yYu3HKe9oRnK; Thu, 14 Nov 2019 01:14: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 36FE01200E5; Thu, 14 Nov 2019 01:14:38 -0800 (PST) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id BCE681AE0312; Thu, 14 Nov 2019 10:14:36 +0100 (CET) Date: Thu, 14 Nov 2019 10:14:06 +0100 (CET) Message-Id: <20191114.101406.2087098792700938588.mbj@tail-f.com> To: kent+ietf@watsen.net Cc: bill.wu@huawei.com, ietfc@btconnect.com, rwilton@cisco.com, httpbis-chairs@ietf.org, netconf@ietf.org From: Martin Bjorklund In-Reply-To: <0100016e68049a12-bcb2acea-a4e2-42f9-8eab-05bab261d5dd-000000@email.amazonses.com> References: <0100016e68049a12-bcb2acea-a4e2-42f9-8eab-05bab261d5dd-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] Adoption call for draft-kwatsen-netconf-http-client-server-04 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, 14 Nov 2019 09:14:39 -0000 Hi, Kent Watsen wrote: > > Folks, > > It seems that the rough consensus is to rename the draft. Being a WG > document and me, a dutiful Editor, I'm happy to oblige. Assuming > adoption can proceed with this understanding, I'll make the change > when submitting the -00. As for the specific name, there is no great > fallback, but perhaps s/http/web/ or s/http/rest/ (i.e., > draft-ietf-netconf-web-client-server)? We can decide in Singapore. There's a thread in opsawg about renaming drafts... Conclusion (I think): keep the name of the draft, but change the title and name of the module. > As the dissenter in the rough, let the record show that there is no > concrete technical reason to rename anything, and efforts to get > clarifications have be left unanswered. If there are issues, renaming > won't make them go away If the name is too generic, and the issue is that the content is more specific than the name suggests, then renaming can help resolving the issue. > and, in any case, renaming to anything other > than the name of the protocol layer is both unhelpful and confusing. > I hereby request that the shepherd writeup captures this sentiment as > well. > > Kent // contributor /martin From nobody Thu Nov 14 03:35:05 2019 Return-Path: <0100016e69b1f262-27a7a4b7-4e6e-4553-9bc5-c76bb7739cee-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 C42FB120047; Thu, 14 Nov 2019 03:35:03 -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 iFGDEHZZkt9o; Thu, 14 Nov 2019 03:35:02 -0800 (PST) Received: from a8-32.smtp-out.amazonses.com (a8-32.smtp-out.amazonses.com [54.240.8.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9836120046; Thu, 14 Nov 2019 03:35:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1573731300; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=em1oVJt//TEI3GtDpB9beL4Yln29lFuM08QVPHFcMMw=; b=VWbBjnahBrz6ywDII8rq3VvFTd0iLnhrgPOOIGL+hNUL6L1UyenlpcCdv1FGrfue YndaxNfL9wzzfrSpZogPtIOIt0m5Rn7VPLIWUFivnKHJr2VBflCMm/cMbbhy9MxY1W+ NwilbeIRQ5O/LjHCUBAkrDae3ZI7VHXNiK989YdY= From: Kent Watsen Message-ID: <0100016e69b1f262-27a7a4b7-4e6e-4553-9bc5-c76bb7739cee-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_01CB5C8E-42CB-4F1B-AB86-853824E0D318" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 14 Nov 2019 11:35:00 +0000 In-Reply-To: <20191114.101406.2087098792700938588.mbj@tail-f.com> Cc: bill.wu@huawei.com, ietfc@btconnect.com, rwilton@cisco.com, httpbis-chairs@ietf.org, "netconf@ietf.org" To: Martin Bjorklund References: <0100016e68049a12-bcb2acea-a4e2-42f9-8eab-05bab261d5dd-000000@email.amazonses.com> <20191114.101406.2087098792700938588.mbj@tail-f.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.11.14-54.240.8.32 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04 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, 14 Nov 2019 11:35:04 -0000 --Apple-Mail=_01CB5C8E-42CB-4F1B-AB86-853824E0D318 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > There's a thread in opsawg about renaming drafts... Conclusion (I > think): keep the name of the draft, but change the title and name of > the module. I saw but didn't read the thread. Did it cover crossing from an = individual draft to a WG draft (i.e., kwatsen-05 --> ietf-00)? The = draft name must change, right? If this is a Datatracker history issue, = is it understood that the replace-by behavior enables diffs to cross the = individual to WG draft boundary, and it really doesn't matter what names = are used? > If the name is too generic, and the issue is that the content is more > specific than the name suggests, then renaming can help resolving the > issue. In principle, yes, but for this case, how is the "http" name too = generic? Do we have a single concrete reason that has been vetted? How = can the draft explain to readers why the most obvious name wasn't used? = What is the distinguishing characteristic that potential consumers = should use to ascertain if the modules are [in]appropriate for them? As for the title and module name, it seems the simplest thing is: OLD: title: Groupings for HTTP Clients and Servers module: ietf-http-client module: ietf-http-server NEW: title: Groupings for RESTful HTTP Clients and Servers module: ietf-restful-http-client module: ietf-restful-http-server But isn't there also an issue of names being overly specific? Some may = ask why the draft is limited to RESTful HTTP, being that it only = configures endpoints and has nothing to do with if the application is = RESTful or not. Kent // contributor --Apple-Mail=_01CB5C8E-42CB-4F1B-AB86-853824E0D318 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
There's a thread in opsawg about renaming drafts... =  Conclusion (I
think): keep the name of the draft, = but change the title and name of
the module.

I saw = but didn't read the thread.  Did it cover crossing from an = individual draft to a WG draft (i.e., kwatsen-05 --> ietf-00)?   = The draft name must change, right?  If this is a Datatracker = history issue, is it understood that the replace-by behavior enables = diffs to cross the individual to WG draft boundary, and it really = doesn't matter what names are used?


If the name is too generic, = and the issue is that the content is more
specific than = the name suggests, then renaming can help resolving the
issue.

In principle, yes, but for this case, how is the = "http" name too generic?  Do we have a single concrete reason that = has been vetted?  How can the draft explain to readers why the most = obvious name wasn't used?   What is the distinguishing = characteristic that potential consumers should use to ascertain if the = modules are [in]appropriate for them?

As for the title and module name, it seems the = simplest thing is:

= OLD:
title:  Groupings = for HTTP Clients and Servers
module: = ietf-http-client
module: = ietf-http-server

= NEW:
title:  Groupings for RESTful HTTP = Clients and Servers
module:  = ietf-restful-http-client
module:  = ietf-restful-http-server

But isn't there also an issue of names = being overly specific?  Some may ask why the draft is limited to = RESTful HTTP, being that it only configures endpoints and has nothing to = do with if the application is RESTful or not.



Kent // contributor

= --Apple-Mail=_01CB5C8E-42CB-4F1B-AB86-853824E0D318-- From nobody Thu Nov 14 04:01:21 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A764A12011E; Thu, 14 Nov 2019 04:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 sH_rpc767alC; Thu, 14 Nov 2019 04:01:17 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02on0628.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe07::628]) (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 D97A612011B; Thu, 14 Nov 2019 04:01:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Hy+5FWtBOAW2PEbiuSQmpFPduqiDypx51yCW3lH+HS3n3JFH/i7wPqCwlQw8YBexqb8jb8hXAY6J5eyhyUlwBbitIUTsAKJ0lgqcVbADUo5ZmGabSDKFdh9tjmDZ85q3RpsC8QKJtY3uwxM6I9o7aKaI0tdSbxrihZwvNVYdP1QF04enPbHpYOy1soxIhBUyk5EOHjl+QStzyyXQ0AvNLGyCUNiKHBfE28zEKauxuzcEljMv+DVNhqAR5xteUqIa8/Tje+2SqvLwnwX+QjY91slmRVdF8do22hERGkU+zPzjXXwlJPMwg6f6LSrHIQfL/gC5Sq1kUvakfvWm85LroQ== 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=1u4VwE8tCpjik0Av0SdOwXP0beNlkLxbctcCrz5GQBU=; b=TzsTx6LD1pi06hn9fxIpCzobq2fD+PVLnjEPPJekPzH0yoOIfJSmPESxT/H8UpzRwmMM8wYjnfRJYETXWkEHL4dIEWpbog0Bs5MiCoZ8MAggtdUrxuQ708j6D+Q11s1S1RQdLiKv2E4/HkodCCx2qI1xUIJvyeCGX9MT05/js6rcc41FOuVg/2yWE4/i2+ReQYq2MmRCxt2Um/7ILr5otcy9vPtQ2AbnCu4HeZGHYvcWGEAZa124l7ewwo7vgt7+o33IYb8CaYzbIUfSSiq9vhX+gXMqr4fmxZ1/9D5MC0cPQ/HhNi2T6mUZCMMLavR9PnwmISJcgs3ysWWTgN+edw== 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=1u4VwE8tCpjik0Av0SdOwXP0beNlkLxbctcCrz5GQBU=; b=t2ODwnDxT87YPK9C64YpXWvZNEk6MkcJPJ8QHd9Dq39Pnhi1q9prEeKzgeeaB5E0TD/mwBBpQRN5qYWS8/OsBLkEahaUKF3RPULFGCy1ONesx5LNp4gEvbqotMVUJt05p9TauCwswwoWDcNyhcg3lcdAPQ0y2oYKDT35eD2tyro= Received: from AM5P190MB0482.EURP190.PROD.OUTLOOK.COM (10.161.65.11) by AM5P190MB0548.EURP190.PROD.OUTLOOK.COM (10.161.66.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.20; Thu, 14 Nov 2019 12:01:14 +0000 Received: from AM5P190MB0482.EURP190.PROD.OUTLOOK.COM ([fe80::6c6c:2cd2:11dd:2aff]) by AM5P190MB0482.EURP190.PROD.OUTLOOK.COM ([fe80::6c6c:2cd2:11dd:2aff%5]) with mapi id 15.20.2451.024; Thu, 14 Nov 2019 12:01:13 +0000 From: =?iso-8859-1?Q?Sch=F6nw=E4lder=2C_J=FCrgen?= To: Kent Watsen CC: Martin Bjorklund , "httpbis-chairs@ietf.org" , "netconf@ietf.org" Thread-Topic: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04 Thread-Index: AQHVmt+YewsZIa3fiE+EFNtw9nVdC6eKkKyA Date: Thu, 14 Nov 2019 12:01:13 +0000 Message-ID: <20191114120113.ywm2a32s7vyjefoj@anna.jacobs.jacobs-university.de> References: <0100016e68049a12-bcb2acea-a4e2-42f9-8eab-05bab261d5dd-000000@email.amazonses.com> <20191114.101406.2087098792700938588.mbj@tail-f.com> <0100016e69b1f262-27a7a4b7-4e6e-4553-9bc5-c76bb7739cee-000000@email.amazonses.com> In-Reply-To: <0100016e69b1f262-27a7a4b7-4e6e-4553-9bc5-c76bb7739cee-000000@email.amazonses.com> 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: AM0PR0102CA0014.eurprd01.prod.exchangelabs.com (2603:10a6:208:14::27) To AM5P190MB0482.EURP190.PROD.OUTLOOK.COM (2603:10a6:206:1d::11) 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: d3b7f659-fd5e-4c90-3faa-08d768fa58cc x-ms-traffictypediagnostic: AM5P190MB0548: x-ms-exchange-purlcount: 1 x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 02213C82F8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(136003)(39850400004)(376002)(346002)(199004)(189003)(3450700001)(476003)(86362001)(66946007)(305945005)(66446008)(64756008)(66476007)(446003)(7736002)(102836004)(43066004)(66556008)(8936002)(2906002)(99286004)(186003)(81166006)(25786009)(81156014)(8676002)(786003)(316002)(6116002)(6506007)(478600001)(386003)(6486002)(6436002)(71190400001)(71200400001)(256004)(76176011)(52116002)(54906003)(11346002)(46003)(14454004)(6246003)(4744005)(6306002)(4326008)(486006)(5660300002)(1076003)(6512007)(561944003)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5P190MB0548; H:AM5P190MB0482.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: 5kWnUOQkOyIvAG44KOinS1SGnQc+aCzQDH5SdjpdHw5StS/yBwWmQ95sXOZbIRm53jLbfzs2tEibbiX6VEyGdCpDQ0o9c8Kng+DmDVI1mit1VizHCp4uORo87CGJgy/ul5wHsvLdJrjuBedidQyD+8wtPv/aHLzTY4GkBodPrLvA1d4hJp35pknyCcE4uPD6BWQoTHMTCJIjkN6Hz3+qHm1r1GYqJeVgu2SPqolimlwzKRhOG6kYAyPWPKOGepeOs/H4yLnu8oWsKZ2R0bumPqZoLTjNGIQKl27gERL9uswf90+Oe+11HsNaAohu4cMGFvdEeLyv56Id6zTAJDzpxuQGo2+JsaJ4WTRPoa2lMsSB2QfEsIIZ8T3cIEicDZsRbYc5j9uT99zJR9+PVvbv5+vaErLzjlxjo+y9O4x4y+8hbo/uRyXxNrxg3d3Tq37RqrOoIqPbYTkKReJj68SllNCT5gyJ4l6h437f5aqUCPc= Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: d3b7f659-fd5e-4c90-3faa-08d768fa58cc X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Nov 2019 12:01:13.8397 (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: Wfaw8Fuv0JvX2M0+MCyZ3HNYzBD6kWPN79MiDMEVgjgvJ0dNhLLoMg0f/2sygCuemj8FSCFA1ej+SZ5afCWMKWgZc4bBqxFrY8gnT5c1ejg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5P190MB0548 Archived-At: Subject: Re: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04 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, 14 Nov 2019 12:01:20 -0000 On Thu, Nov 14, 2019 at 11:35:00AM +0000, Kent Watsen wrote: >=20 > As for the title and module name, it seems the simplest thing is: >=20 > OLD: > title: Groupings for HTTP Clients and Servers > module: ietf-http-client > module: ietf-http-server >=20 > NEW: > title: Groupings for RESTful HTTP Clients and Servers > module: ietf-restful-http-client > module: ietf-restful-http-server >=20 > But isn't there also an issue of names being overly specific? Some may a= sk why the draft is limited to RESTful HTTP, being that it only configures = endpoints and has nothing to do with if the application is RESTful or not. > I do not think we should open the door to discussions what is RESTful and what is not... Perhaps we need something like "RESTCONF and similar" - not a serious proposal. ;-) /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Nov 14 04:04:05 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C328C120142; Thu, 14 Nov 2019 04:04:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 qY0CH-zCNV4v; Thu, 14 Nov 2019 04:04:00 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 53645120128; Thu, 14 Nov 2019 04:04:00 -0800 (PST) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 480AE1AE0312; Thu, 14 Nov 2019 13:03:59 +0100 (CET) Date: Thu, 14 Nov 2019 13:03:28 +0100 (CET) Message-Id: <20191114.130328.235293728895543729.mbj@tail-f.com> To: kent+ietf@watsen.net Cc: bill.wu@huawei.com, ietfc@btconnect.com, rwilton@cisco.com, httpbis-chairs@ietf.org, netconf@ietf.org From: Martin Bjorklund In-Reply-To: <0100016e69b1f262-27a7a4b7-4e6e-4553-9bc5-c76bb7739cee-000000@email.amazonses.com> References: <0100016e68049a12-bcb2acea-a4e2-42f9-8eab-05bab261d5dd-000000@email.amazonses.com> <20191114.101406.2087098792700938588.mbj@tail-f.com> <0100016e69b1f262-27a7a4b7-4e6e-4553-9bc5-c76bb7739cee-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] Adoption call for draft-kwatsen-netconf-http-client-server-04 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, 14 Nov 2019 12:04:03 -0000 Kent Watsen wrote: > > > There's a thread in opsawg about renaming drafts... Conclusion (I > > think): keep the name of the draft, but change the title and name of > > the module. > > I saw but didn't read the thread. Did it cover crossing from an > individual draft to a WG draft (i.e., kwatsen-05 --> ietf-00)? Yes. > The > draft name must change, right? If this is a Datatracker history > issue, is it understood that the replace-by behavior enables diffs to > cross the individual to WG draft boundary, and it really doesn't > matter what names are used? Personally I don't care; just pointing out a discussion that may be relevant. > > If the name is too generic, and the issue is that the content is more > > specific than the name suggests, then renaming can help resolving the > > issue. > > In principle, yes, but for this case, how is the "http" name too > generic? I think it is the name "ietf-http-server" that seems to indicate that this a module that can be used to configure any HTTP server. (See below!) > Do we have a single concrete reason that has been vetted? > How can the draft explain to readers why the most obvious name wasn't > used? What is the distinguishing characteristic that potential > consumers should use to ascertain if the modules are [in]appropriate > for them? > > As for the title and module name, it seems the simplest thing is: > > OLD: > title: Groupings for HTTP Clients and Servers > module: ietf-http-client > module: ietf-http-server > > NEW: > title: Groupings for RESTful HTTP Clients and Servers > module: ietf-restful-http-client > module: ietf-restful-http-server > > But isn't there also an issue of names being overly specific? Some > may ask why the draft is limited to RESTful HTTP, being that it only > configures endpoints and has nothing to do with if the application is > RESTful or not. I wonder if the names should be "ietf-http-server-groupings" instead? (and same for tcp / ssh / tls, but not netconf / restconf). We already have some "-types" modules. Or even "ietf-http-server-types", if by "type" we mean "typedef and/or grouping". This could also be a way to make the name less problematic. It makes it more obvious that these modules provide building blocks, rather than a complete solution. /martin From nobody Thu Nov 14 04:35:56 2019 Return-Path: <0100016e69e99e3c-893fbfb4-3dc8-4725-b7ef-87bbf491dc2c-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 273031201DE for ; Thu, 14 Nov 2019 04:35:53 -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 5fis3P2IdXt1 for ; Thu, 14 Nov 2019 04:35:50 -0800 (PST) Received: from a8-64.smtp-out.amazonses.com (a8-64.smtp-out.amazonses.com [54.240.8.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D83C1201A3 for ; Thu, 14 Nov 2019 04:35:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1573734948; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=C+/ECxGRnCfNknZE1/sTkJQgv5stFR+lalAa9W3NRNw=; b=dlAofpaZqXk7K4j7dJgEDk0KhUJogL8P92O2k6J2hhBFAasw8QT/qU6VSYg7d9dm 2dxsAEQPoFdP14mavj8wmiTPpgQCCKP2uLAFhBpYrYJNrsje2YNbhVKrjyUtSikpoog f0v6KZEjE9K3B77sLjeOswGVPJbaKF4SUA3l0iFA= From: Kent Watsen Message-ID: <0100016e69e99e3c-893fbfb4-3dc8-4725-b7ef-87bbf491dc2c-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_74709B82-5445-490A-8130-78E46E595098" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 14 Nov 2019 12:35:48 +0000 In-Reply-To: <20191114.100558.1371995383202419404.mbj@tail-f.com> Cc: "netconf@ietf.org" To: Martin Bjorklund References: <20191113.135649.2218807015240802033.mbj@tail-f.com> <0100016e66c9b02d-382d9d6e-6d88-47ec-a117-5f38a3699fb1-000000@email.amazonses.com> <20191114.100558.1371995383202419404.mbj@tail-f.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.11.14-54.240.8.64 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] crypto-types and keystore comments 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, 14 Nov 2019 12:35:53 -0000 --Apple-Mail=_74709B82-5445-490A-8130-78E46E595098 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Martin, > Suppose I want to configure a ssh host-key as the server-identity for > my NETCONF server. Is the intention that a client can pick either > "ssh-public-key-format" or "subject-public-key-info-format", and the > server must support both? It's assumed that the client would set the public key using = "ssh-public-key-format" (per RFC 4716, as that is the only = standards-based public key format that `openssh` is able to export). = While it's possible to convert the public key to a SubjectPublicKeyInfo = structure, doing so is unlikely. In either case, the same data is = conveyed. The issue presents itself when configuring the "server-identity" in = ietf-ssh-server, whether a local definition or a reference to a key in = the keystore. A "must" expression could be used to constrain the = supported key-formats allowed. Our modules could hardcode this for all = implementations or, if wanting to provide flexibility, we could let = implementations augment-in their own 'must' expression. >> Yes, well, this is a known problem (e.g., >> https://github.com/netmod-wg/yang-next/issues/82 >> ). >=20 > That is quite different. How so? Features are effectively opstate lists too and, in both cases, = YANG fails to support granular discrimination.=20 > You're using a normal config false list for this (which is fine), but > I don't think you can use a single global list like this. I don't understand this statement. >> I will say that the definition above was given because it is the only >> *standards* based key that `openssh` can output (i.e., `ssh-keygen -e >> [-m RFC4716] -f `). >=20 > With my proposal you can take the output of this openssh command and > copy & paste the base64-encoded data from this output to a YANG node > using ssh-public-key-format. >=20 > With your proposal you have to copy the entire output, base64 encode > it *again*, and then copy & paste that result to the YANG node. Not true or, rather, the intention is to support native encoding = formats, including DER vs PEM, and CMS vs multi-part PEM. That a = text-based format is base64 encoded is not an issue and, IMO, a feature = as it escaping concerns when the content is placed in an XML or JSON = document. >> That said, if you refer to the link I provided at top, it is my = belief >> that the "key-format" node may be extended to support alternate >> encodings (e.g., DER vs PEM and, potentially, CMS vs multi-part PEM). >> To this end, perhaps we could support both the 4716 and 4253 formats. >=20 > Do we really want to go there? This is already quite complex, and > having a multitude of optional formats for the same thing may make > things even more complex, to understand and get right. Binary formats (e.g., DER) are fundamental, but some raised usability = concerns, hence the exploration. As for complexity, how do we know = until we try? >>> o subject-public-key-info-format >>>=20 >>> The crypto model has: >>>=20 >>> identity subject-public-key-info-format { >>> base "public-key-format"; >>> description >>> "A SubjectPublicKeyInfo (from RFC 5280)."; >>> } >>>=20 >>> Should this be "DER encoded"? >>>=20 >>> (this and other defintions have references to RFCs in the >>> description; they should be moved to proper "reference" statements) >>=20 >> Yes. I put together these definitions in as a test/protocol to gauge >> viability with the plan to enhance the definitions if the WG = committed >> to the approach. I just added some "FIXME" comments to my local = copy. >=20 > Ok. It helps immensely when folks can provide spec-text, either on list or = as a pull request. Kent // contributor --Apple-Mail=_74709B82-5445-490A-8130-78E46E595098 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi Martin,


Suppose I want to configure a ssh host-key as the = server-identity for
my NETCONF server.  Is the = intention that a client can pick either
"ssh-public-key-format" or "subject-public-key-info-format", = and the
server must support both?

It's = assumed that the client would set the public key using = "ssh-public-key-format" (per RFC 4716, as that is the only = standards-based public key format that `openssh` is able to export). =  While it's possible to convert the public key to a = SubjectPublicKeyInfo structure, doing so is unlikely.  In either = case, the same data is conveyed.

The = issue presents itself when configuring the "server-identity" in = ietf-ssh-server, whether a local definition or a reference to a key in = the keystore.   A "must" expression could be used to constrain the = supported key-formats allowed.   Our modules could hardcode this = for all implementations or, if wanting to provide flexibility, we could = let implementations augment-in their own 'must' = expression.



Yes, well, this is a known problem (e.g.,
https://github.com/netmod-wg/yang-next/issues/82
<https://github.com/netmod-wg/yang-next/issues/82>).

That is quite different.

How so? =  Features are effectively opstate lists too and, in both cases, = YANG fails to support granular discrimination. 

You're using a normal config false list for this (which is = fine), but
I don't think you can use a single global list = like this.

I don't understand this statement.



I will say that the definition above was given = because it is the only
*standards* based key that = `openssh` can output (i.e., `ssh-keygen -e
[-m RFC4716] -f = <private-key-file>`).

With= my proposal you can take the output of this openssh command and
copy & paste the base64-encoded data from this output to = a YANG node
using ssh-public-key-format.

With your proposal you have to copy the entire output, base64 = encode
it *again*, and then copy & paste that result = to the YANG node.

Not true or, rather, the intention is to support = native encoding formats, including DER vs PEM, and CMS vs multi-part = PEM.   That a text-based format is base64 encoded is not an issue = and, IMO, a feature as it escaping concerns when the content is placed = in an XML or JSON document.



That said, if you refer to the link I provided at top, it is = my belief
that the "key-format" node may be extended to = support alternate
encodings (e.g., DER vs PEM and, = potentially, CMS vs multi-part PEM).
To this end, perhaps = we could support both the 4716 and 4253 formats.

Do we really want to go there? =  This is already quite complex, and
having a = multitude of optional formats for the same thing may make
things even more complex, to understand and get right.

Binary = formats (e.g., DER) are fundamental, but some raised usability concerns, = hence the exploration.  As for complexity, how do we know until we = try?



o  subject-public-key-info-format

The crypto model has:

=   identity subject-public-key-info-format {
=     base "public-key-format";
=     description
=       "A SubjectPublicKeyInfo (from RFC = 5280).";
  }

= Should this be "DER encoded"?

(this and = other defintions have references to RFCs in the
= description; they should be moved to proper "reference" statements)

Yes.  I put together these = definitions in as a test/protocol to gauge
viability with = the plan to enhance the definitions if the WG committed
to = the approach.  I just added some "FIXME" comments to my local = copy.

Ok.

It = helps immensely when folks can provide spec-text, either on list or as a = pull request.



Kent // contributor


= --Apple-Mail=_74709B82-5445-490A-8130-78E46E595098-- From nobody Thu Nov 14 04:41:38 2019 Return-Path: <0100016e69eedfd6-f718171a-d145-42bf-914b-77b3440bca90-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 0CCF2120846; Thu, 14 Nov 2019 04:41:36 -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 nboaSPZBEHxl; Thu, 14 Nov 2019 04:41:34 -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 54A92120824; Thu, 14 Nov 2019 04:41:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1573735293; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=lq6/rBzq4B0dTFu+TVh9SAdevDgpd2HmHE/w0dXKJv4=; b=k30ypvfaKFYYnTgqUv0yyU0i9m7Q+gaS3Pm2YA1VtbZ/DWI8sGDlld+oQptelOA7 E/SMA3m0FjRAT31p2wZMNXF7wUuiUgy1LgsUlUW3SZhUi9msaSTzF8vLdVWo8z04XKQ 0+eU757wytn9IbNehkQ28WQxwvZ1LfPj+8NKd+Zk= From: Kent Watsen Message-ID: <0100016e69eedfd6-f718171a-d145-42bf-914b-77b3440bca90-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_42DDC0C5-5079-4AA9-962D-484A2D1F9D58" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 14 Nov 2019 12:41:32 +0000 In-Reply-To: <20191114120113.ywm2a32s7vyjefoj@anna.jacobs.jacobs-university.de> Cc: Martin Bjorklund , "httpbis-chairs@ietf.org" , "netconf@ietf.org" To: Juergen Schoenwaelder References: <0100016e68049a12-bcb2acea-a4e2-42f9-8eab-05bab261d5dd-000000@email.amazonses.com> <20191114.101406.2087098792700938588.mbj@tail-f.com> <0100016e69b1f262-27a7a4b7-4e6e-4553-9bc5-c76bb7739cee-000000@email.amazonses.com> <20191114120113.ywm2a32s7vyjefoj@anna.jacobs.jacobs-university.de> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.11.14-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04 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, 14 Nov 2019 12:41:36 -0000 --Apple-Mail=_42DDC0C5-5079-4AA9-962D-484A2D1F9D58 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Juergen, > I do not think we should open the door to discussions what is RESTful > and what is not... No need, there are a ton of answers on stack overflow. The only = question is if its proper to put ourselves in that box. > Perhaps we need something like "RESTCONF and similar" - not a serious = proposal. ;-) Kek. The thing is that the "https-notif" draft isn't RESTCONF-based, = but it's "similar"! ;) Kent // contributor --Apple-Mail=_42DDC0C5-5079-4AA9-962D-484A2D1F9D58 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Juergen,


I do not think we should open the door to discussions what is = RESTful
and what is not... =

No need, there are a = ton of answers on stack overflow.  The only question is if its = proper to put ourselves in that box.


Perhaps we need something = like "RESTCONF and similar" - not a serious proposal. ;-)

Kek. =  The thing is that the "https-notif" draft isn't RESTCONF-based, = but it's "similar"!  ;)


Kent // contributor


= --Apple-Mail=_42DDC0C5-5079-4AA9-962D-484A2D1F9D58-- From nobody Thu Nov 14 05:02:10 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0384F12012E for ; Thu, 14 Nov 2019 05:02:09 -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 Y1GwZy_RuKoO for ; Thu, 14 Nov 2019 05:02:07 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4A77412001A for ; Thu, 14 Nov 2019 05:02:07 -0800 (PST) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id DEC011AE0312; Thu, 14 Nov 2019 14:02:05 +0100 (CET) Date: Thu, 14 Nov 2019 14:01:35 +0100 (CET) Message-Id: <20191114.140135.2027227966816173737.mbj@tail-f.com> To: kent+ietf@watsen.net Cc: netconf@ietf.org From: Martin Bjorklund In-Reply-To: <0100016e69e99e3c-893fbfb4-3dc8-4725-b7ef-87bbf491dc2c-000000@email.amazonses.com> References: <0100016e66c9b02d-382d9d6e-6d88-47ec-a117-5f38a3699fb1-000000@email.amazonses.com> <20191114.100558.1371995383202419404.mbj@tail-f.com> <0100016e69e99e3c-893fbfb4-3dc8-4725-b7ef-87bbf491dc2c-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] crypto-types and keystore comments 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, 14 Nov 2019 13:02:09 -0000 Kent Watsen wrote: > Hi Martin, > > > > Suppose I want to configure a ssh host-key as the server-identity for > > my NETCONF server. Is the intention that a client can pick either > > "ssh-public-key-format" or "subject-public-key-info-format", and the > > server must support both? > > It's assumed that the client would set the public key using > "ssh-public-key-format" (per RFC 4716, as that is the only > standards-based public key format that `openssh` is able to export). > While it's possible to convert the public key to a > SubjectPublicKeyInfo structure, doing so is unlikely. In either case, > the same data is conveyed. > > The issue presents itself when configuring the "server-identity" in > ietf-ssh-server, whether a local definition or a reference to a key in > the keystore. A "must" expression could be used to constrain the > supported key-formats allowed. Our modules could hardcode this for > all implementations Ok. This is worth exploring imo. > or, if wanting to provide flexibility, we could > let implementations augment-in their own 'must' expression. > > > > >> Yes, well, this is a known problem (e.g., > >> https://github.com/netmod-wg/yang-next/issues/82 > >> ). > > > > That is quite different. > > How so? Features are effectively opstate lists too and, in both > cases, YANG fails to support granular discrimination. > > > You're using a normal config false list for this (which is fine), but > > I don't think you can use a single global list like this. > > I don't understand this statement. My point is really just that a single global list like this is not sufficient. It doesn't matter if "feature" has problems; a single global config false list is not sufficient for what you're trying to do. > >> I will say that the definition above was given because it is the only > >> *standards* based key that `openssh` can output (i.e., `ssh-keygen -e > >> [-m RFC4716] -f `). > > > > With my proposal you can take the output of this openssh command and > > copy & paste the base64-encoded data from this output to a YANG node > > using ssh-public-key-format. > > > > With your proposal you have to copy the entire output, base64 encode > > it *again*, and then copy & paste that result to the YANG node. > > Not true or, rather, the intention is to support native encoding > formats, including DER vs PEM, and CMS vs multi-part PEM. But that would be different key-format identities, right? The issue here is about what the specfic format is for ssh-public-key-format. The format I suggest is also already used in RFC 7317, as was pointed out before by someone else. > That a > text-based format is base64 encoded is not an issue and, IMO, a > feature as it escaping concerns when the content is placed in an XML > or JSON document. > > > > >> That said, if you refer to the link I provided at top, it is my belief > >> that the "key-format" node may be extended to support alternate > >> encodings (e.g., DER vs PEM and, potentially, CMS vs multi-part PEM). > >> To this end, perhaps we could support both the 4716 and 4253 formats. > > > > Do we really want to go there? This is already quite complex, and > > having a multitude of optional formats for the same thing may make > > things even more complex, to understand and get right. > > Binary formats (e.g., DER) are fundamental, but some raised usability > concerns Do you have a pointer to this? > , hence the exploration. As for complexity, how do we know > until we try? I think we _are_ trying now... /martin > >>> o subject-public-key-info-format > >>> > >>> The crypto model has: > >>> > >>> identity subject-public-key-info-format { > >>> base "public-key-format"; > >>> description > >>> "A SubjectPublicKeyInfo (from RFC 5280)."; > >>> } > >>> > >>> Should this be "DER encoded"? > >>> > >>> (this and other defintions have references to RFCs in the > >>> description; they should be moved to proper "reference" statements) > >> > >> Yes. I put together these definitions in as a test/protocol to gauge > >> viability with the plan to enhance the definitions if the WG committed > >> to the approach. I just added some "FIXME" comments to my local copy. > > > > Ok. > > It helps immensely when folks can provide spec-text, either on list or > as a pull request. > > > > Kent // contributor > > From nobody Thu Nov 14 05:08:53 2019 Return-Path: <0100016e6a07d334-324f48f9-5dae-4aa4-8b6a-1c16a8a8033c-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 140A012086C; Thu, 14 Nov 2019 05:08:51 -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 BzIseajYEIDD; Thu, 14 Nov 2019 05:08: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 8E7F2120868; Thu, 14 Nov 2019 05:08:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1573736928; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=K9FXkeB+WAQu4Y2urZK8zdAi9Am4B6/LV7QDqfMpx0c=; b=Br46vlWVlploICgKgCsql+pn5Qdzxi3nKJvTIbw/x7+AZIO+sIu/6Xlj9M7lCb6x +ohaXjXSqSIrmju4W65pepxt8EXQ8VQnJkoUrbq7Du8+27IDuRBREht3jSqX3VfMpmg 1S6Xnv1sjwQncI2+RH+Aqsxm7NAiFOhY4HHCERAY= From: Kent Watsen Message-ID: <0100016e6a07d334-324f48f9-5dae-4aa4-8b6a-1c16a8a8033c-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_004D935A-E7E9-4540-9C3B-EF4E57123789" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 14 Nov 2019 13:08:48 +0000 In-Reply-To: <20191114.130328.235293728895543729.mbj@tail-f.com> Cc: bill.wu@huawei.com, ietfc@btconnect.com, rwilton@cisco.com, httpbis-chairs@ietf.org, "netconf@ietf.org" To: Martin Bjorklund References: <0100016e68049a12-bcb2acea-a4e2-42f9-8eab-05bab261d5dd-000000@email.amazonses.com> <20191114.101406.2087098792700938588.mbj@tail-f.com> <0100016e69b1f262-27a7a4b7-4e6e-4553-9bc5-c76bb7739cee-000000@email.amazonses.com> <20191114.130328.235293728895543729.mbj@tail-f.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.11.14-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04 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, 14 Nov 2019 13:08:51 -0000 --Apple-Mail=_004D935A-E7E9-4540-9C3B-EF4E57123789 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Martin, > Personally I don't care; just pointing out a discussion that may be > relevant. Ack. Let's focus on the module names, the draft name will fall out from = that discussion. > I think it is the name "ietf-http-server" that seems to indicate that > this a module that can be used to configure any HTTP server. (See > below!) It's more like a possible basis to configure any HTTP server, which to = me still seems like the right thing to do, until someone can provide a = concrete technical reason why it cannot be so. > I wonder if the names should be "ietf-http-server-groupings" instead? Hmmm, this is an interesting idea... > (and same for tcp / ssh / tls, but not netconf / restconf). =20 I see why you might say this, but the netconf/restconf drafts also = define groupings, which are (IMO) more important than the containers, = which we added under questionable conditions (i.e., the "client" = containers make almost no sense, and the "server" containers have = limited use, especially without the ability to augment/refine things = when "implemented"). =20 > We > already have some "-types" modules. Or even "ietf-http-server-types", > if by "type" we mean "typedef and/or grouping". ...and identities and features (and maybe something else I'm not = thinking about just now). > This could also be a way to make the name less problematic. It makes > it more obvious that these modules provide building blocks, rather > than a complete solution. I truly appreciate the intention behind this idea and love the idea of = sticking with an undiluted "http", but I question if putting "grouping" = into the module name is ideal, perhaps "base" or "basis" would be = better? Even for the NC/RC modules, they are merely a base/basis for = higher-level business logic. [note: I also thought about "params", but = the (IMO useless) containers in the NC/RC modules don't lend themselves = well to being called "params"] To help visualize these options: ietf-http-server-base ietf-http-server-basis ietf-http-server-params ietf-restconf-server-base ietf-restconf-server-basis ietf-restconf-server-params To be clear, I'm not yet agreeing to or promoting this approach yet, = though it seems promising. Kent // contributor --Apple-Mail=_004D935A-E7E9-4540-9C3B-EF4E57123789 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Martin,

Personally I don't care; just = pointing out a discussion that may be
relevant.

Ack. =  Let's focus on the module names, the draft name will fall out from = that discussion.


I think it is = the name "ietf-http-server" that seems to indicate that
this= a module that can be used to configure any HTTP server.  (See
below!)

It's more like a possible basis to configure any = HTTP server, which to me still seems like the right thing to do, until = someone can provide a concrete technical reason why it cannot be = so.


I wonder if the = names should be "ietf-http-server-groupings" instead?

Hmmm, this = is an interesting idea...

(and same for = tcp / ssh / tls, but not netconf / restconf). =  

I see why = you might say this, but the netconf/restconf drafts also define = groupings, which are (IMO) more important than the containers, which we = added under questionable conditions (i.e., the "client" containers make = almost no sense, and the "server" containers have limited use, = especially without the ability to augment/refine things when = "implemented").   

We
already = have some "-types" modules.  Or even "ietf-http-server-types",
if by "type" we mean "typedef and/or grouping".

...and = identities and features (and maybe something else I'm not thinking about = just now).

This could also be a way to = make the name less problematic.  It makes
it more = obvious that these modules provide building blocks, rather
than a complete solution.

I = truly appreciate the intention behind this idea and love the idea of = sticking with an undiluted "http", but I question if putting "grouping" = into the module name is ideal, perhaps "base" or "basis" would be = better?   Even for the NC/RC modules, they are merely a base/basis = for higher-level business logic.  [note: I also thought about = "params", but the (IMO useless) containers in the NC/RC modules don't = lend themselves well to being called "params"]

To help visualize these options:

= ietf-http-server-base
= ietf-http-server-basis
= ietf-http-server-params

= ietf-restconf-server-base
= ietf-restconf-server-basis
= ietf-restconf-server-params

To be clear, I'm not yet agreeing to or = promoting this approach yet, though it seems promising.

Kent // = contributor

= --Apple-Mail=_004D935A-E7E9-4540-9C3B-EF4E57123789-- From nobody Thu Nov 14 05:26:18 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D7E120112; Thu, 14 Nov 2019 05:26:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=X/kggOJ+; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=U7bvOMPp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMX_aEd3HxzO; Thu, 14 Nov 2019 05:26:13 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8858F1200EF; Thu, 14 Nov 2019 05:26:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15575; q=dns/txt; s=iport; t=1573737973; x=1574947573; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=eoe0SUQrxJDW1J+B739TW2cL4Vyyp37xJ79ibIQq4UQ=; b=X/kggOJ+sk1FBHxXfN7vImpmsuGcxI6tzr5f6ifyY5GwZIdDVdV8/K3M XQB7Bo3xd/fkqVqvFBZ9CtYGmNnUWQXK2FZIVS9hzMAVY8DdjKVZO9pQ5 9Mgbri6PGxiBvDCJ73hhcOsb0I31Z+BVmvr6MjGyrnq9j+aMMijn9GvRo o=; IronPort-PHdr: =?us-ascii?q?9a23=3ARlknKBC0n+NXCp5i572IUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs13kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuNuHrazA9GuxJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ALAADdVM1d/5FdJa1lGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYFqBQEBAQELAYEbL1AFbFggBAsqCodlA4Rahhq?= =?us-ascii?q?CXpMehGKBLoEkA1QJAQEBDAEBLQIBAYRAAoIgJDQJDgIDCwEBBAEBAQIBBQR?= =?us-ascii?q?thTcMhVEBAQEBAxILEBMBATcBDwIBCBEEAQEvMh0IAgQBDQUIEweDAYF5TQM?= =?us-ascii?q?uAQKnSAKBOIhggieCfgEBBYUZGIIXCYE2AYwUGIFAP4FXgU5+PoQeERiDQII?= =?us-ascii?q?slVUkiSCPCQqCKpVnlUiEPIIMhAyIL5oEAgQCBAUCDgEBBYFSOYFYcBWDJ1A?= =?us-ascii?q?RFII3jmODc4pTdIEojjCBMQGBDgEB?= X-IronPort-AV: E=Sophos;i="5.68,304,1569283200"; d="scan'208,217";a="664850037" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Nov 2019 13:26:10 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id xAEDQAvj027585 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Nov 2019 13:26:10 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 14 Nov 2019 07:26:10 -0600 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 14 Nov 2019 08:26:09 -0500 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 14 Nov 2019 07:26:09 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ctG6g+AMf+gh9t57Lx6Lvoodoo8yKhNK/YqMOx+9F5FQc9/qmQbDdRNU0v6xOE2H6zRY1ys0k0zyZsiRsAWk74CNzNPvk0sKBldQX0yrtGmCNYK+Y6zaSvy1GgoIiwAFJN8BEOdBx1SIUtkN7aWIPnzQ7VN5UzQuk9Gz4WA/Fg/xaNfIJF/GYSvJRp1kvlcCbVaMbWrlVej8aETcrZTSoyivzShnBjPcXxkc9LOzhFuP3krDmDvxacb9qlCfqSetcVmM7DTp0hjK7cifUu7Fkhh4knR8uW38hA4F2bESeYRBILipp+fLgmXbFVfUSYGL8SJeKx7pWFfZ0WGi9ZJFKA== 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=G2g0vjtpDyXJBMUPCaZzdOh+4OjJWx9zkBWMm+bTb6U=; b=e+NlU1Bgk8vbR7YgnSOSqHu2ZJH20hieEgcS1a3kRf/ubm5vKiwIoxwKrmRl82apoPKBQVn1rw8mchl73tnZJIkR032aGYnNUr5YaFWHEcEO5EAaNGtG/GH3veb+R7jqval0TLGI0LLaTBFOByPg+wz0jExqZj1RI+gbxeooT+OtcggTFTIts1KzGfd4oEWbRhE8IS3USHa+z5cSQCIyV7SGsjiCpNouxE+dQm6bdF/7NdCaB+cTwmIUY5fbP0UGqFFesA2rwfFPGMX0ZN86CmKACixTVrTQvC/woF1kWEk3DBJkswhC0GQYT7t0kigkwpk0Ek+vr3VrHRm4akZ91g== 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=G2g0vjtpDyXJBMUPCaZzdOh+4OjJWx9zkBWMm+bTb6U=; b=U7bvOMPpYff/T/JBeVToNaO7LYadcBM9356FBPPgkdTvkvnoTLE9ZjxWOBAhdwq/kk0IlCzhsbP/2PipC3BvlSHCQteLLeY2+qOG5iZ6KBy7UaK+Cs4CpOqSUL78lsw6yiFF8Y5I2KwFu8RdQy15NGUpWO5xpnJ7EEF0CNhFGm0= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB4205.namprd11.prod.outlook.com (52.135.39.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.27; Thu, 14 Nov 2019 13:26:08 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::49b6:bc5c:bd3e:203c]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::49b6:bc5c:bd3e:203c%5]) with mapi id 15.20.2430.027; Thu, 14 Nov 2019 13:26:08 +0000 From: "Rob Wilton (rwilton)" To: Kent Watsen , Martin Bjorklund CC: "bill.wu@huawei.com" , "ietfc@btconnect.com" , "httpbis-chairs@ietf.org" , "netconf@ietf.org" Thread-Topic: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04 Thread-Index: AdWZwaIxhgQXPPYEQrG4WcDrav91fAA3GaUAAAt1JQAABOu+AAAA/oMAAAJIIAAAADCnEA== Date: Thu, 14 Nov 2019 13:26:08 +0000 Message-ID: References: <0100016e68049a12-bcb2acea-a4e2-42f9-8eab-05bab261d5dd-000000@email.amazonses.com> <20191114.101406.2087098792700938588.mbj@tail-f.com> <0100016e69b1f262-27a7a4b7-4e6e-4553-9bc5-c76bb7739cee-000000@email.amazonses.com> <20191114.130328.235293728895543729.mbj@tail-f.com> <0100016e6a07d334-324f48f9-5dae-4aa4-8b6a-1c16a8a8033c-000000@email.amazonses.com> In-Reply-To: <0100016e6a07d334-324f48f9-5dae-4aa4-8b6a-1c16a8a8033c-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=rwilton@cisco.com; x-originating-ip: [173.38.220.45] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a42e47d0-19a5-4c37-1174-08d769063587 x-ms-traffictypediagnostic: MN2PR11MB4205: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02213C82F8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(366004)(346002)(376002)(136003)(199004)(189003)(54094003)(186003)(71200400001)(478600001)(229853002)(14454004)(11346002)(446003)(476003)(486006)(86362001)(7736002)(74316002)(54906003)(6246003)(256004)(316002)(33656002)(110136005)(55016002)(4326008)(6306002)(9686003)(54896002)(6436002)(790700001)(66946007)(66476007)(66556008)(64756008)(66446008)(6116002)(3846002)(9326002)(8676002)(2906002)(14444005)(71190400001)(25786009)(81156014)(81166006)(5660300002)(52536014)(76116006)(8936002)(26005)(99286004)(7696005)(76176011)(66066001)(6506007)(53546011)(102836004); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4205; 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: egPTpWQeWwkJyGB7hEULVWaSt2+neSsVp5BZI6U4WV1/GVeSyaWC3AgUMVxOoyhwuc7ceGGWCzFy/TirDEaAKbfOtG4kiv49Evs5WWe9eilcBUB79MIKLr/GJmKMRYimJCdVQlSSOA3qbWG/gkmdUOYIOJ0T93e+gcT3e2SG+J8E5AQTA/Am7R8zoxrDHAjIGCL3iM1tEe9SzAgVzESBII3mz/0DRCiKvcGThZ2Br3aK9qmkUadDYyVHv6TC/zbLMF9bLmL9NGruK418iY8CrSKu7/sugaq5RgCtiJvmXnX+F92CbEAAQqfIlCvZvS94kDkzr90z/nZ57ewpDc4S3kNWKAMu+4Mqa7/mNmrfSlsALdNCZSzo9NLi9yXIwEz3alM8yl5uvJhGQ/wAqvP8fxLxLY8NwtkiqcL1/Q1z1s/TY8hIioD9btZsZbewek2p x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB4366854186012165AA8EB752B5710MN2PR11MB4366namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a42e47d0-19a5-4c37-1174-08d769063587 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Nov 2019 13:26:08.1970 (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: 8c8iD3h+G7UGCrcUDZEQc4dOlLsppTuvfHxvD/Bol85YuKICuRCd/HJFEkRrOwfsxKCmcW/dzOwdMzl/zIUdtw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4205 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.19, xch-rcd-009.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04 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, 14 Nov 2019 13:26:17 -0000 --_000_MN2PR11MB4366854186012165AA8EB752B5710MN2PR11MB4366namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kent, From: Kent Watsen Sent: 14 November 2019 13:09 To: Martin Bjorklund Cc: bill.wu@huawei.com; ietfc@btconnect.com; Rob Wilton (rwilton) ; httpbis-chairs@ietf.org; netconf@ietf.org Subject: Re: [netconf] Adoption call for draft-kwatsen-netconf-http-client-= server-04 Hi Martin, Personally I don't care; just pointing out a discussion that may be relevant. Ack. Let's focus on the module names, the draft name will fall out from th= at discussion. I think it is the name "ietf-http-server" that seems to indicate that this a module that can be used to configure any HTTP server. (See below!) It's more like a possible basis to configure any HTTP server, which to me s= till seems like the right thing to do, until someone can provide a concrete= technical reason why it cannot be so. [RW] Do we require consensus from the httpbis WG if we want to use ietf-http-ser= ver.yang? If we do, then how long will that take? We really want to get t= hese drafts and YANG modules finished (even if they are not perfect). I wonder if the names should be "ietf-http-server-groupings" instead? Hmmm, this is an interesting idea... (and same for tcp / ssh / tls, but not netconf / restconf). I see why you might say this, but the netconf/restconf drafts also define g= roupings, which are (IMO) more important than the containers, which we adde= d under questionable conditions (i.e., the "client" containers make almost = no sense, and the "server" containers have limited use, especially without = the ability to augment/refine things when "implemented"). We already have some "-types" modules. Or even "ietf-http-server-types", if by "type" we mean "typedef and/or grouping". ...and identities and features (and maybe something else I'm not thinking a= bout just now). [RW] Probably also extensions. It is worth noting that iana-if-type.yang defines identities. Other "-type= s" YANG modules define some groupings. So, perhaps by type it really means a YANG module that does not define any = data-nodes (outside groupings), RPC, notifications, or actions. This could also be a way to make the name less problematic. It makes it more obvious that these modules provide building blocks, rather than a complete solution. I truly appreciate the intention behind this idea and love the idea of stic= king with an undiluted "http", but I question if putting "grouping" into th= e module name is ideal, perhaps "base" or "basis" would be better? Even f= or the NC/RC modules, they are merely a base/basis for higher-level busines= s logic. [note: I also thought about "params", but the (IMO useless) conta= iners in the NC/RC modules don't lend themselves well to being called "para= ms"] To help visualize these options: ietf-http-server-base ietf-http-server-basis ietf-http-server-params ietf-restconf-server-base ietf-restconf-server-basis ietf-restconf-server-params To be clear, I'm not yet agreeing to or promoting this approach yet, though= it seems promising. [RW] I quite like the idea of "ietf-http-server-types.yang" ... Thanks, Rob Kent // contributor --_000_MN2PR11MB4366854186012165AA8EB752B5710MN2PR11MB4366namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kent,<= o:p>

&nbs= p;

From: Kent Watsen <kent+ietf@watsen= .net>
Sent: 14 November 2019 13:09
To: Martin Bjorklund <mbj@tail-f.com>
Cc: bill.wu@huawei.com; ietfc@btconnect.com; Rob Wilton (rwilton) &l= t;rwilton@cisco.com>; httpbis-chairs@ietf.org; netconf@ietf.org
Subject: Re: [netconf] Adoption call for draft-kwatsen-netconf-http-= client-server-04

 

Hi Martin,

 

Personally I don't care= ; just pointing out a discussion that may be
relevant.

 

Ack.  Let's focus = on the module names, the draft name will fall out from that discussion.

 



I think it is the name = "ietf-http-server" that seems to indicate that
this a module that can be used to configure any HTTP server.  (See
below!)

 

It's more like a possib= le basis to configure any HTTP server, which to me still seems like the rig= ht thing to do, until someone can provide a concrete technical reason why i= t cannot be so.

[RW]

Do we require consensus from the httpbis WG if= we want to use ietf-http-server.yang?  If we do, then how long will t= hat take?  We really want to get these drafts and YANG modules finishe= d (even if they are not perfect).

 



I wonder if the names s= hould be "ietf-http-server-groupings" instead?

 

Hmmm, this is an intere= sting idea...



(and same for tcp / ssh= / tls, but not netconf / restconf).  

 

I see why you might say= this, but the netconf/restconf drafts also define groupings, which are (IM= O) more important than the containers, which we added under questionable co= nditions (i.e., the "client" containers make almost no sense, and the "server" containers have limited u= se, especially without the ability to augment/refine things when "impl= emented").   



We
already have some "-types" modules.  Or even "ietf-http= -server-types",
if by "type" we mean "typedef and/or grouping".

 

...and identities and f= eatures (and maybe something else I'm not thinking about just now).

[RW]

Probably also extensions.

 

It is worth noting that iana-if-type.yang defi= nes identities.  Other “-types” YANG modules define some g= roupings.

 

So, perhaps by type it really means a YANG mod= ule that does not define any data-nodes (outside groupings), RPC, notificat= ions, or actions.

 

This could also be a wa= y to make the name less problematic.  It makes
it more obvious that these modules provide building blocks, rather
than a complete solution.

 

I truly appreciate the = intention behind this idea and love the idea of sticking with an undiluted = "http", but I question if putting "grouping" into the m= odule name is ideal, perhaps "base" or "basis" would be better?   Even for the NC/RC modules, they are merely a base/basis fo= r higher-level business logic.  [note: I also thought about "para= ms", but the (IMO useless) containers in the NC/RC modules don't lend = themselves well to being called "params"]

 

To help visualize these= options:

 

           &= nbsp;   ietf-http-server-base

           &= nbsp;   ietf-http-server-basis

           &= nbsp;   ietf-http-server-params

 

           &= nbsp;   ietf-restconf-server-base

           &= nbsp;   ietf-restconf-server-basis

           &= nbsp;   ietf-restconf-server-params

 

To be clear, I'm not ye= t agreeing to or promoting this approach yet, though it seems promising.=

[RW]

I quite like the idea of “ietf-http-serv= er-types.yang” …

 

Thanks,

Rob

 

 

 

 

Kent // contributor

 

--_000_MN2PR11MB4366854186012165AA8EB752B5710MN2PR11MB4366namp_-- From nobody Thu Nov 14 05:40:46 2019 Return-Path: <0100016e6a250215-e89c9f24-60d9-419d-bc24-221786cb6f85-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 6C6CF1200EC for ; Thu, 14 Nov 2019 05:40: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, 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 DqBMdBrj1R1p for ; Thu, 14 Nov 2019 05:40:42 -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 6CA9F1200E5 for ; Thu, 14 Nov 2019 05:40:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1573738840; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=TNupkwAGfPNj1lR46+MsPOpffk8eF0wyR51P/4wwO8o=; b=FINAlzKVrn+xJD+XBqbeauJD7c56AEx8v7a1EaiPpya/SSzzxz0QLvhvuiBEiB1z 6Dfzr/ekj27cCP0UXio02/NvVDpl3tJnOD7payRVlQXRO5Qu94NAI1v5Hh+omWrDych pPACIuIv5XJWQlFnDT8kqq3gVTM+XkuAFURS3seg= From: Kent Watsen Message-ID: <0100016e6a250215-e89c9f24-60d9-419d-bc24-221786cb6f85-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_2B78E6D6-B382-4C1A-9729-91711F7EA2B1" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 14 Nov 2019 13:40:40 +0000 In-Reply-To: <20191114.140135.2027227966816173737.mbj@tail-f.com> Cc: "netconf@ietf.org" To: Martin Bjorklund References: <0100016e66c9b02d-382d9d6e-6d88-47ec-a117-5f38a3699fb1-000000@email.amazonses.com> <20191114.100558.1371995383202419404.mbj@tail-f.com> <0100016e69e99e3c-893fbfb4-3dc8-4725-b7ef-87bbf491dc2c-000000@email.amazonses.com> <20191114.140135.2027227966816173737.mbj@tail-f.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.11.14-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] crypto-types and keystore comments 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, 14 Nov 2019 13:40:44 -0000 --Apple-Mail=_2B78E6D6-B382-4C1A-9729-91711F7EA2B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Martin, >> The issue presents itself when configuring the "server-identity" in >> ietf-ssh-server, whether a local definition or a reference to a key = in >> the keystore. A "must" expression could be used to constrain the >> supported key-formats allowed. Our modules could hardcode this for >> all implementations >=20 > Ok. This is worth exploring imo. I added FIXME comments into all of ietf-[ssh/tls]-[client/server]. >>> You're using a normal config false list for this (which is fine), = but >>> I don't think you can use a single global list like this. >>=20 >> I don't understand this statement. >=20 > My point is really just that a single global list like this is not > sufficient. It doesn't matter if "feature" has problems; a single > global config false list is not sufficient for what you're trying to > do. True. But how can we define a way to get a list per instance? Should = there be a "config false" list wherever the "algorithm" node appears = (i.e., put the list into the crypto-type groupings having the algorithm = node?) >> Not true or, rather, the intention is to support native encoding >> formats, including DER vs PEM, and CMS vs multi-part PEM. >=20 > But that would be different key-format identities, right? =20 I think so, yes. > The issue > here is about what the specfic format is for ssh-public-key-format. > The format I suggest is also already used in RFC 7317, as was pointed > out before by someone else. That is the binary encoding for the on-the-wire public key. Yes, for = the binary encoding, this is a great option. But I thought a goal was = to try to use native tool formats when possible. Not that we want to = hardcode to OpenSSH, but `man ssh-keygen`: -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'' (PEM public key). The default conversion format is ``RFC4716''. Setting a format of ``PEM'' when generating or updating a supported private key type will cause the key to be stored in the legacy PEM private key format. >>>> That said, if you refer to the link I provided at top, it is my = belief >>>> that the "key-format" node may be extended to support alternate >>>> encodings (e.g., DER vs PEM and, potentially, CMS vs multi-part = PEM). >>>> To this end, perhaps we could support both the 4716 and 4253 = formats. >>>=20 >>> Do we really want to go there? This is already quite complex, and >>> having a multitude of optional formats for the same thing may make >>> things even more complex, to understand and get right. >>=20 >> Binary formats (e.g., DER) are fundamental, but some raised usability >> concerns >=20 > Do you have a pointer to this? There was an email from Juergen a few months back. >> , hence the exploration. As for complexity, how do we know >> until we try? >=20 > I think we _are_ trying now... Fair, but there's yet to be a concrete proposal for how to support, = e.g., multi-part PEM encoding and, in particular, how it is = distinguished from the PEM encoding of the equivalent CMS. Presumably = it's just another identity, but there maybe more to it... Kent // contributor --Apple-Mail=_2B78E6D6-B382-4C1A-9729-91711F7EA2B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Hi Martin,


The issue presents = itself when configuring the "server-identity" in
ietf-ssh-server, whether a local definition or a reference to = a key in
the keystore.  A "must" expression could be = used to constrain the
supported key-formats allowed. =  Our modules could hardcode this for
all = implementations

Ok.  This = is worth exploring imo.

I added FIXME comments into all of = ietf-[ssh/tls]-[client/server].



You're using a normal = config false list for this (which is fine), but
I don't = think you can use a single global list like this.

I don't understand this = statement.

My point is really = just that a single global list like this is not
sufficient. =   It doesn't matter if "feature" has problems; a single
global config false list is not sufficient for what you're = trying to
do.

True. =  But how can we define a way to get a list per instance? =  Should there be a "config false" list wherever the "algorithm" = node appears (i.e., put the list into the crypto-type groupings having = the algorithm node?)



Not true or, rather, the intention is to support native = encoding
formats, including DER vs PEM, and CMS vs = multi-part PEM.

But that would = be different key-format identities, right? =  

I think so, = yes.

The issue
here is about what = the specfic format is for ssh-public-key-format.
The = format I suggest is also already used in RFC 7317, as was pointed
out before by someone else.

That is the binary encoding for the = on-the-wire public key.  Yes, for the binary encoding, this is a = great option.  But I thought a goal was to try to use native tool = formats when possible.  Not that we want to hardcode to OpenSSH, = but `man ssh-keygen`:

    =  -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'' (PEM
        =       public key).  The default conversion = format is
              = ``RFC4716''.  Setting a format of ``PEM'' = when
            =   generating or updating a supported private = key
              type = will cause the key to be stored in the legacy
  =             PEM private key format.


That said, if you refer to the link I provided at top, it is = my belief
that the "key-format" node may be extended to = support alternate
encodings (e.g., DER vs PEM and, = potentially, CMS vs multi-part PEM).
To this end, perhaps = we could support both the 4716 and 4253 formats.

Do we really want to go there? =  This is already quite complex, and
having a = multitude of optional formats for the same thing may make
things even more complex, to understand and get right.

Binary formats (e.g., DER) are = fundamental, but some raised usability
concerns

Do you have a pointer to this?

There = was an email from Juergen a few months back.


, hence = the exploration.  As for complexity, how do we know
until we try?

I = think we _are_ trying now...

Fair, but there's yet to be a concrete proposal for how to = support, e.g., multi-part PEM encoding and, in particular, how it is = distinguished from the PEM encoding of the equivalent CMS. =  Presumably it's just another identity, but there maybe more to = it...


Kent // contributor

= --Apple-Mail=_2B78E6D6-B382-4C1A-9729-91711F7EA2B1-- From nobody Thu Nov 14 05:48:13 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC37C1200EF for ; Thu, 14 Nov 2019 05:48:11 -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 1mGmZBG_n78K for ; Thu, 14 Nov 2019 05:48:09 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C2E6B1200EC for ; Thu, 14 Nov 2019 05:48:09 -0800 (PST) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 80B0C1AE0312; Thu, 14 Nov 2019 14:48:08 +0100 (CET) Date: Thu, 14 Nov 2019 14:47:38 +0100 (CET) Message-Id: <20191114.144738.728144006347516638.mbj@tail-f.com> To: kent+ietf@watsen.net Cc: netconf@ietf.org From: Martin Bjorklund In-Reply-To: <0100016e6a250215-e89c9f24-60d9-419d-bc24-221786cb6f85-000000@email.amazonses.com> References: <0100016e69e99e3c-893fbfb4-3dc8-4725-b7ef-87bbf491dc2c-000000@email.amazonses.com> <20191114.140135.2027227966816173737.mbj@tail-f.com> <0100016e6a250215-e89c9f24-60d9-419d-bc24-221786cb6f85-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] crypto-types and keystore comments 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, 14 Nov 2019 13:48:12 -0000 Kent Watsen wrote: > > Hi Martin, > > > >> The issue presents itself when configuring the "server-identity" in > >> ietf-ssh-server, whether a local definition or a reference to a key in > >> the keystore. A "must" expression could be used to constrain the > >> supported key-formats allowed. Our modules could hardcode this for > >> all implementations > > > > Ok. This is worth exploring imo. > > I added FIXME comments into all of ietf-[ssh/tls]-[client/server]. > > > > >>> You're using a normal config false list for this (which is fine), but > >>> I don't think you can use a single global list like this. > >> > >> I don't understand this statement. > > > > My point is really just that a single global list like this is not > > sufficient. It doesn't matter if "feature" has problems; a single > > global config false list is not sufficient for what you're trying to > > do. > > True. But how can we define a way to get a list per instance? Should > there be a "config false" list wherever the "algorithm" node appears > (i.e., put the list into the crypto-type groupings having the > algorithm node?) I don't know, probably. Do we really want that? Probably not. This is exaclty why I suggested earlier that we don't spend time trying to solve this problem at all now. I'd rather not put in something that we know doesn't really work. > >> Not true or, rather, the intention is to support native encoding > >> formats, including DER vs PEM, and CMS vs multi-part PEM. > > > > But that would be different key-format identities, right? > > I think so, yes. > > > The issue > > here is about what the specfic format is for ssh-public-key-format. > > The format I suggest is also already used in RFC 7317, as was pointed > > out before by someone else. > > That is the binary encoding for the on-the-wire public key. Yes, for > the binary encoding, this is a great option. But I thought a goal was > to try to use native tool formats when possible. Not that we want to > hardcode to OpenSSH, but `man ssh-keygen`: > > -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'' (PEM > public key). The default conversion format is > ``RFC4716''. Setting a format of ``PEM'' when > generating or updating a supported private key > type will cause the key to be stored in the legacy > PEM private key format. > > > >>>> That said, if you refer to the link I provided at top, it is my belief > >>>> that the "key-format" node may be extended to support alternate > >>>> encodings (e.g., DER vs PEM and, potentially, CMS vs multi-part PEM). > >>>> To this end, perhaps we could support both the 4716 and 4253 formats. > >>> > >>> Do we really want to go there? This is already quite complex, and > >>> having a multitude of optional formats for the same thing may make > >>> things even more complex, to understand and get right. > >> > >> Binary formats (e.g., DER) are fundamental, but some raised usability > >> concerns > > > > Do you have a pointer to this? > > There was an email from Juergen a few months back. But that was based on a misunderstanding. (or you mean something else) > >> , hence the exploration. As for complexity, how do we know > >> until we try? > > > > I think we _are_ trying now... > > Fair, but there's yet to be a concrete proposal for how to support, > e.g., multi-part PEM encoding and, in particular, how it is > distinguished from the PEM encoding of the equivalent CMS. Presumably > it's just another identity, but there maybe more to it... > > > Kent // contributor > /martin From nobody Thu Nov 14 07:27:01 2019 Return-Path: <0100016e6a864f15-27f64057-4ac2-48d4-b4b0-404e8306afbf-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 9E9AC120169; Thu, 14 Nov 2019 07:27:00 -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 ANQKaUlFD1K5; Thu, 14 Nov 2019 07:26:59 -0800 (PST) Received: from a8-64.smtp-out.amazonses.com (a8-64.smtp-out.amazonses.com [54.240.8.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A8CD120129; Thu, 14 Nov 2019 07:26:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1573745217; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=Iq33LySoDcAjK1ka18mhYThM+idC8ATMm9A9iXdYcaQ=; b=RGysRfKh6rOGJXTxFasY4sYlymzRSHG7DWkEBgDyFy77COKihK5W28j3CfdJE6j4 LAPc286OlIPgeQ22JvX2636Om9+BNl42ozv3tFdcGqF4L1q3zdhmDHOVrFpaGAZTRQS 1Va8gt9WZ5MobneiMzwDjoIASdqG5LDw/YzRwy2Y= From: Kent Watsen Message-ID: <0100016e6a864f15-27f64057-4ac2-48d4-b4b0-404e8306afbf-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_832889FF-AD09-4FF7-B003-E38DC3E431C8" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 14 Nov 2019 15:26:57 +0000 In-Reply-To: Cc: "httpbis-chairs@ietf.org" , "netconf@ietf.org" To: "Rob Wilton (rwilton)" References: <0100016e68049a12-bcb2acea-a4e2-42f9-8eab-05bab261d5dd-000000@email.amazonses.com> <20191114.101406.2087098792700938588.mbj@tail-f.com> <0100016e69b1f262-27a7a4b7-4e6e-4553-9bc5-c76bb7739cee-000000@email.amazonses.com> <20191114.130328.235293728895543729.mbj@tail-f.com> <0100016e6a07d334-324f48f9-5dae-4aa4-8b6a-1c16a8a8033c-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.11.14-54.240.8.64 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04 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, 14 Nov 2019 15:27:01 -0000 --Apple-Mail=_832889FF-AD09-4FF7-B003-E38DC3E431C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Rob, > [RW] > Do we require consensus from the httpbis WG if we want to use = ietf-http-server.yang? As I understand it, WGs are allowed to standardize anything within their = charter without the need to consult other working groups, unless the = work falls within the scope of another WG's charter. Here is the = httpbis charter: https://datatracker.ietf.org/wg/httpbis/charter = . > If we do, then how long will that take? We really want to get these = drafts and YANG modules finished (even if they are not perfect). In my opinion, the very limited scope of the existing http-client-server = draft is right-sized and likely applies to *all* HTTP implementations. = I feel that the HTTP-chairs were/are (depending on how much of this = thread they're reading) simply unclear with regards to intention. Had = the clear majority of the NETCONF WG said that the existing name was = best, then the chairs could've declared "rough consensus" (and pass it = to the IESG in the shepherd writeup). Folks keep thinking that this one draft is going to delay things, but = forget that it is not the proverbial long pole in the tent. One thing = that would help things go faster would be to parallelize the effort. Me = driving everything isn't good. Does somebody want to drive running the = http-client-server draft by HTTP experts? Does anyone know an = HTTP-expert that has YANG-clue? Kent // contributor --Apple-Mail=_832889FF-AD09-4FF7-B003-E38DC3E431C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Hi Rob,


[RW]

Do we require consensus from the httpbis WG if we want to use = ietf-http-server.yang?


As I understand it, WGs are = allowed to standardize anything within their charter without the need to = consult other working groups, unless the work falls within the scope of = another WG's charter.  Here is the httpbis charter: https://datatracker.ietf.org/wg/httpbis/charter.
=

If we do, then how long will that take?  = We really want to get these drafts and YANG modules finished (even if = they are not = perfect).


In my opinion, the very limited scope of the = existing http-client-server draft is right-sized and likely applies to = *all* HTTP implementations.  I feel that the HTTP-chairs were/are = (depending on how much of this thread they're reading) simply unclear = with regards to intention.  Had the clear majority of the NETCONF = WG said that the existing name was best, then the chairs could've = declared "rough consensus" (and pass it to the IESG in the shepherd = writeup).

Folks keep thinking that = this one draft is going to delay things, but forget that it is not the = proverbial long pole in the tent.  One thing that would help things = go faster would be to parallelize the effort.  Me driving = everything isn't good.  Does somebody want to drive running the = http-client-server draft by HTTP experts?  Does anyone know an = HTTP-expert that has YANG-clue?


Kent // contributor
= --Apple-Mail=_832889FF-AD09-4FF7-B003-E38DC3E431C8-- From nobody Thu Nov 14 07:41:25 2019 Return-Path: <0100016e6a936a0d-47636ce9-345c-4009-8d74-9703905933aa-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 6795E120849 for ; Thu, 14 Nov 2019 07:41:19 -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 vyik_6_ZauB6 for ; Thu, 14 Nov 2019 07:41:17 -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 BF8EB120113 for ; Thu, 14 Nov 2019 07:41:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1573746076; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=HlhDfJCI9FHZg3zoylXx34arbpedxSALFXvIWsVL08Y=; b=j2aaDC4tGmuMgklcYnXQwtWvlftuLrt6Oq/fBE+EjND4F4bKVaelW7NKkGBlaCyL lNsaiY38bVNSfToPV9hSuAju6f6R9XXQ6faotBnjD4GrFUjpuNr4mMhbHMh2d0QOze5 uIV4/HtqnDJGlXKG0oE1nJlsaHL/G8eZVEYcy6io= From: Kent Watsen Message-ID: <0100016e6a936a0d-47636ce9-345c-4009-8d74-9703905933aa-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_8433317A-8DA1-470F-AAD4-F9401F8EE1E9" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 14 Nov 2019 15:41:16 +0000 In-Reply-To: <20191114.144738.728144006347516638.mbj@tail-f.com> Cc: "netconf@ietf.org" To: Martin Bjorklund References: <0100016e69e99e3c-893fbfb4-3dc8-4725-b7ef-87bbf491dc2c-000000@email.amazonses.com> <20191114.140135.2027227966816173737.mbj@tail-f.com> <0100016e6a250215-e89c9f24-60d9-419d-bc24-221786cb6f85-000000@email.amazonses.com> <20191114.144738.728144006347516638.mbj@tail-f.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.11.14-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] crypto-types and keystore comments 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, 14 Nov 2019 15:41:20 -0000 --Apple-Mail=_8433317A-8DA1-470F-AAD4-F9401F8EE1E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Martin, >> True. But how can we define a way to get a list per instance? = Should >> there be a "config false" list wherever the "algorithm" node appears >> (i.e., put the list into the crypto-type groupings having the >> algorithm node?) >=20 > I don't know, probably. Do we really want that? Probably not. Per-instance may be too granular. If thinking that said curations = occur of protocol boundaries, then maybe have a config false list in = ietf-ssh-common and ietf-tis-common? Not perfect, as an application = may use more than one SSH library or more than one TLS library, but it's = much less likely. > This is exaclty why I suggested earlier that we don't spend time > trying to solve this problem at all now. I'd rather not put in > something that we know doesn't really work. Wait, no, there is a very real issue here that cannot be ignored. Or do = you feel that we should give up entirely on trying to enable servers to = proactively express what algorithms they support? >>> Do you have a pointer to this? >>=20 >> There was an email from Juergen a few months back. >=20 > But that was based on a misunderstanding. (or you mean something > else) Now I'm unsure what you're talking about, do you have a pointer to it? Kent // contributor --Apple-Mail=_8433317A-8DA1-470F-AAD4-F9401F8EE1E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Martin,

True.  But how can we define a way to get a list per = instance?  Should
there be a "config false" list = wherever the "algorithm" node appears
(i.e., put the list = into the crypto-type groupings having the
algorithm = node?)

I don't know, probably. =  Do we really want that?  Probably not.

Per-instance may be too granular.   If = thinking that said curations occur of protocol boundaries, then maybe = have a config false list in ietf-ssh-common and ietf-tis-common?   = Not perfect, as an application may use more than one SSH library or more = than one TLS library, but it's much less likely.


This is exaclty why I suggested earlier that = we don't spend time
trying to solve this problem at all = now.  I'd rather not put in
something that we know = doesn't really work.

Wait, no, there is a very real issue here that = cannot be ignored.  Or do you feel that we should give up entirely = on trying to enable servers to proactively express what algorithms they = support?



Do you have a pointer to this?

There was an email from Juergen a few months back.

But that was based on a = misunderstanding.  (or you mean something
else)

Now = I'm unsure what you're talking about, do you have a pointer to = it?


Kent // = contributor

= --Apple-Mail=_8433317A-8DA1-470F-AAD4-F9401F8EE1E9-- From nobody Thu Nov 14 07:51:25 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2889F120129 for ; Thu, 14 Nov 2019 07:51: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, 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 aNopEJxvySeG for ; Thu, 14 Nov 2019 07:51:22 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 54063120113 for ; Thu, 14 Nov 2019 07:51:22 -0800 (PST) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id CC1E61AE0312; Thu, 14 Nov 2019 16:51:20 +0100 (CET) Date: Thu, 14 Nov 2019 16:50:50 +0100 (CET) Message-Id: <20191114.165050.356278327445084771.mbj@tail-f.com> To: kent+ietf@watsen.net Cc: netconf@ietf.org From: Martin Bjorklund In-Reply-To: <0100016e6a936a0d-47636ce9-345c-4009-8d74-9703905933aa-000000@email.amazonses.com> References: <0100016e6a250215-e89c9f24-60d9-419d-bc24-221786cb6f85-000000@email.amazonses.com> <20191114.144738.728144006347516638.mbj@tail-f.com> <0100016e6a936a0d-47636ce9-345c-4009-8d74-9703905933aa-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] crypto-types and keystore comments 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, 14 Nov 2019 15:51:24 -0000 Kent Watsen wrote: > Hi Martin, > > >> True. But how can we define a way to get a list per instance? Should > >> there be a "config false" list wherever the "algorithm" node appears > >> (i.e., put the list into the crypto-type groupings having the > >> algorithm node?) > > > > I don't know, probably. Do we really want that? Probably not. > > Per-instance may be too granular. If thinking that said curations > occur of protocol boundaries, then maybe have a config false list in > ietf-ssh-common and ietf-tis-common? Not perfect, as an application > may use more than one SSH library or more than one TLS library, but > it's much less likely. Yes, better. > > This is exaclty why I suggested earlier that we don't spend time > > trying to solve this problem at all now. I'd rather not put in > > something that we know doesn't really work. > > Wait, no, there is a very real issue here that cannot be ignored. Or > do you feel that we should give up entirely on trying to enable > servers to proactively express what algorithms they support? > > > > >>> Do you have a pointer to this? > >> > >> There was an email from Juergen a few months back. > > > > But that was based on a misunderstanding. (or you mean something > > else) > > Now I'm unsure what you're talking about, do you have a pointer to it? I am talking about this: https://mailarchive.ietf.org/arch/browse/netconf/?q= /martin From nobody Thu Nov 14 07:57:09 2019 Return-Path: <0100016e6aa1e34a-48a429a3-1b27-433a-b533-52748a0c29b1-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 C7A071200B8 for ; Thu, 14 Nov 2019 07:57:08 -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 lXOwfvsVs9RS for ; Thu, 14 Nov 2019 07:57:06 -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 48352120033 for ; Thu, 14 Nov 2019 07:57:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1573747024; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=W9KMRCyQ2JXGP0fGBqP+YK//crA4ypFdT8MScxOGh6o=; b=AW1Mb7KrGbe8wUp0nfugO06j8DW9jyc4VjY0cmHoBIF47OxXMymzt6nKHXOXeAP7 abZi6d/Xrxam2cb/pIyWybIaWrzjrl/Mb+ZBI3CvyVydInqWJPXJSSIsUiPGvuw5ptM EwKSct23jKXimIu4cdNgMnrJsQkpc8SlVlWYWldE= From: Kent Watsen Message-ID: <0100016e6aa1e34a-48a429a3-1b27-433a-b533-52748a0c29b1-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_736B9A22-F4BD-4ADC-8831-A5EB21DFAA91" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 14 Nov 2019 15:57:04 +0000 In-Reply-To: <20191114.085152.69723351117040013.mbj@tail-f.com> Cc: "netconf@ietf.org" To: Martin Bjorklund References: <0100016e4d8323b0-2a182947-485d-43e6-908c-13bc5ad2f210-000000@email.amazonses.com> <20191111.110013.2019956803552089416.mbj@tail-f.com> <0100016e661a2f48-26561fed-a533-4aec-8ad1-d68582b82b39-000000@email.amazonses.com> <20191114.085152.69723351117040013.mbj@tail-f.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.11.14-54.240.8.31 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] client identification in ietf-netconf-server 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, 14 Nov 2019 15:57:09 -0000 --Apple-Mail=_736B9A22-F4BD-4ADC-8831-A5EB21DFAA91 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Nov 14, 2019, at 2:51 AM, Martin Bjorklund wrote: >=20 > Kent Watsen wrote: >> Hi Martin, >>=20 >>=20 >>> Martin Bjorklund wrote: >>>=20 >>> Hi, >>>=20 >>> Kent Watsen wrote: >>>>=20 >>>> Hi Martin, >>>>=20 >>>> [Not trimming down because too much context would be lost.] >>>>=20 >>>>=20 >>>>>>> The ietf-netconf-server module has this: >>>>>>>=20 >>>>>>> grouping netconf-server-grouping { >>>>>>> ... >>>>>>> container client-identification { >>>>>>> ... >>>>>>> container cert-maps { >>>>>>> when "../../../../tls"; >>>>>>> uses x509c2n:cert-to-name; >>>>>>> ... >>>>>>> } >>>>>>> } >>>>>>> } >>>>>>>=20 >>>>>>> Note the "when" expression. This means that the grouping has a = strong >>>>>>> depency on where is it used. We should try to avoid such a = design. >>>>>>=20 >>>>>>=20 >>>>>> Would this be better? =20 >>>>>>=20 >>>>>> OLD >>>>>> when "../../../../tls"; >>>>>>=20 >>>>>> NEW >>>>>> if-feature "tls-listen or tls-call-home"; >>>>>=20 >>>>> Yes, but see below. >>>>>=20 >>>>>=20 >>>>>>> But should't this cert-to-name list be available when x509-certs = are >>>>>>> used also with SSH? >>>>>>=20 >>>>>> Hmmm. I'd assumed that, with RFC 6187, the username was still = passed >>>>>> as its own field, but I see this in Section 4: >>>>>>=20 >>>>>> For the purposes of user authentication, the mapping between >>>>>> certificates and user names is left as an implementation and >>>>>> configuration issue for implementers and system administrators. >>>>>=20 >>>>> If the username was used as identification it would mean that with = a >>>>> valid cert I could present myself as any user! >>>>>=20 >>>>>> So you may be right about that. I only ever looked at RFC 6187 = from >>>>>> the perspective of the server presenting an IDevID certificate. = But, >>>>>> assuming it's true, then perhaps this: >>>>>>=20 >>>>>> NEWEST: >>>>>> if-feature "tls-listen or tls-call-home or = sshcmn:ssh-x509-certs"; >>>>>=20 >>>>> Ok. >>>>>=20 >>>>> This gives: >>>>>=20 >>>>> grouping netconf-server-grouping { >>>>> description ...; >>>>> container client-identification { >>>>> description >>>>> "Specifies a mapping through which clients MAY be identified >>>>> (i.e., the NETCONF username) from a supplied certificate. >>>>> Note that a client MAY alternatively be identified via an >>>>> alternate authentication scheme."; >>>>> container cert-maps { >>>>> if-feature "tls-listen or tls-call-home or = sshcmn:ssh-x509-certs"; >>>>=20 >>>> Yes. >>>>=20 >>>>> But since the description of the "client-identification" says that = it >>>>> is used only with certificates, perhaps that container's name = should >>>>> reflect this, and the if-feature statement moved to that = container? >>>>> Perhaps: >>>>>=20 >>>>> container client-cert-identification >>>>> if-feature "tls-listen or tls-call-home or = sshcmn:ssh-x509-certs"; >>>>>=20 >>>>> and also perhaps remove 'cert-maps', and use the cert-to-name = grouping >>>>> directly here? >>>>=20 >>>> Good. My only hesitation is that someday there may be a need for >>>> another way to identify clients, but that sounds too far out (even = for >>>> me) to squabble over. But a better name is needed. >>>> "cert-based-client-identification" would be more accurate, but that >>>> seems overly long. Looking at a snippet of config might help... >>>>=20 >>>> netconf-server-parameters : { >>>> something-here : [ >>>> { >>>> cert-to-name : { ... } >>>> cert-to-name : { ... }, >>>> ... >>>> cert-to-name : { ... } >>>> } >>>> ] >>>> } >>>>=20 >>>> How about "cert-to-name-mappings"? ( know, almost the same length, >>>> but half the number of syllables!). But that name leaves out the = word >>>> "identity", which is may be important in security circles, so maybe >>>> "client-identity-mappings"? >>>=20 >>> I think this name is as generic as "client-identification". The = best >>> so far imo is "cert-based-client-identification". A bit long, but >>> descripitive. >>=20 >> Actually, I think we should go back to "client-identification" now = that raw-public-key and pre-shared/pairwise-symmetric key (PSK) has been = added as alternate ways that TLS clients and servers may identify = themselves and authenticate peers. Thus it seems that there is a need = to map usernames from things other than just certificates. >=20 > I think I'll have to see how that works out. But if the container is > more general than just client certificates, then the description text > needs to be updated. Agreed. Actually, saying just this was going to be my response a couple = days ago, but then I saw how everything flattened out and I held my = tongue. But, yes, updating the description text would be a = prerequisite. In an effort to stem the effort, unless someone else wants to drive it, = and the WG agrees, I think that it would be okay for the = NETCONF/RESTCONF modules to leave defining how to map PSK/RPK keys to = usernames to a future effort. We will have successfully added PSK/RPK = keys for Henk's needs (CoAP), while having a clear path for to proceed = if ever NETCONF wants to pick it up. >>> Hmm, I realize that I have misunderstood 'host-keys' here. How >>> exactly is this supposed to be used? This is the client >>> authentication part of a server. How is the *host* key used here by >>> the server? I mean, the client doesn't present a host key to the >>> server, so I don't understand what this is. >>=20 >> It seems that I've been overzealous with the term "host-key" here. = In SSH, a "host-key" is a special term for the server's public key. = Clients may also authenticate using a public key, but there isn't a = special term for that case. RFC 4252 states that clients can = authenticate using "publickey", "password", and "hostbased". Per RFC = 6187, section 1, 1st paragraph, the "publickey" algorithm is is also = used for X.509 certificates (e.g., x509v3-rsa2048-sha256). >=20 > So what is the conclusion? Remove host-key here? Or was the > intention that this is the user's public key? User's publickey. Kent // contributor --Apple-Mail=_736B9A22-F4BD-4ADC-8831-A5EB21DFAA91 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Nov 14, 2019, at 2:51 AM, Martin Bjorklund <mbj@tail-f.com> = wrote:

Kent Watsen <kent+ietf@watsen.net> wrote:
Hi Martin,


Martin Bjorklund <mbj@tail-f.com> = wrote:

Hi,

Kent = Watsen <kent+ietf@watsen.net> wrote:

Hi Martin,

[Not trimming down because too much context would be = lost.]


The ietf-netconf-server module has this:

grouping netconf-server-grouping {
...
container client-identification {
  ...
  container = cert-maps {
    when = "../../../../tls";
    uses = x509c2n:cert-to-name;
    ...
  }
}
}

Note the "when" expression.  This means = that the grouping has a strong
depency on where is it = used.  We should try to avoid such a design.


Would this be = better?   

OLD
=     when "../../../../tls";

NEW
if-feature "tls-listen or = tls-call-home";

Yes, but see = below.


But = should't this cert-to-name list be available when x509-certs are
used also with SSH?

Hmmm.  I'd assumed that, with RFC 6187, the username was = still passed
as its own field, but I see this in Section = 4:

For the purposes of user = authentication, the mapping between
certificates and user = names is left as an implementation and
configuration = issue for implementers and system administrators.

If the username was used as = identification it would mean that with a
valid cert I = could present myself as any user!

So you may be right about that.  I only = ever looked at RFC 6187 from
the perspective of the server = presenting an IDevID certificate.  But,
assuming it's = true, then perhaps this:

NEWEST:
= if-feature "tls-listen or tls-call-home or = sshcmn:ssh-x509-certs";

Ok.

This gives:

grouping netconf-server-grouping {
=  description ...;
 container = client-identification {
   description
     "Specifies a mapping through = which clients MAY be identified
=       (i.e., the NETCONF username) from a = supplied certificate.
=       Note that a client MAY alternatively = be identified via an
=       alternate authentication = scheme.";
   container cert-maps {
     if-feature "tls-listen or = tls-call-home or sshcmn:ssh-x509-certs";

Yes.

But since the description of the "client-identification" says = that it
is used only with certificates, perhaps that = container's name should
reflect this, and the if-feature = statement moved to that container?
Perhaps:

 container client-cert-identification
   if-feature "tls-listen or tls-call-home or = sshcmn:ssh-x509-certs";

and also perhaps = remove 'cert-maps', and use the cert-to-name grouping
directly here?

Good. =  My only hesitation is that someday there may be a need for
another way to identify clients, but that sounds too far out = (even for
me) to squabble over.  But a better name is = needed.
"cert-based-client-identification" would be more = accurate, but that
seems overly long.  Looking at a = snippet of config might help...

=     netconf-server-parameters : {
=       something-here : [
=         {
=           cert-to-name = : { ... }
=           cert-to-name = : { ... },
=           ...
=           cert-to-name = : { ... }
=         }
=       ]
=     }

How about = "cert-to-name-mappings"?  ( know, almost the same length,
but half the number of syllables!).  But that name = leaves out the word
"identity", which is may be important = in security circles, so maybe
"client-identity-mappings"?

I think this name is as generic = as "client-identification".  The best
so far imo is = "cert-based-client-identification".  A bit long, but
descripitive.

Actually, I think we should go back to = "client-identification" now that raw-public-key and = pre-shared/pairwise-symmetric key (PSK) has been added as alternate ways = that TLS clients and servers may identify themselves and authenticate = peers.   Thus it seems that there is a need to map usernames = from things other than just certificates.

I think I'll have to see how that works out.  But if the = container is
more general than just client certificates, = then the description text
needs to be updated.

Agreed.=  Actually, saying just this was going to be my response a couple = days ago, but then I saw how everything flattened out and I held my = tongue.  But, yes, updating the description text would be a = prerequisite.

In an effort to stem = the effort, unless someone else wants to drive it, and the WG agrees, I = think that it would be okay for the NETCONF/RESTCONF modules to leave = defining how to map PSK/RPK keys to usernames to a future effort.   = We will have successfully added PSK/RPK keys for Henk's needs (CoAP), = while having a clear path for to proceed if ever NETCONF wants to pick = it up.



Hmm, I realize that I have misunderstood 'host-keys' here. =  How
exactly is this supposed to be used?  This = is the client
authentication part of a server.  How = is the *host* key used here by
the server?   I = mean, the client doesn't present a host key to the
server, = so I don't understand what this is.

It seems that I've been overzealous with the term "host-key" = here.  In SSH, a "host-key" is a special term for the server's = public key.  Clients may also authenticate using a public key, but = there isn't a special term for that case.   RFC 4252 states = that clients can authenticate using "publickey", "password", and = "hostbased".   Per RFC 6187, section 1, 1st paragraph, the = "publickey" algorithm is is also used for X.509 certificates (e.g., = x509v3-rsa2048-sha256).

So = what is the conclusion?  Remove host-key here?  Or was the
intention that this is the user's public key?

User's = publickey.


Kent // contributor



= --Apple-Mail=_736B9A22-F4BD-4ADC-8831-A5EB21DFAA91-- From nobody Thu Nov 14 11:03:25 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1441A1200D7 for ; Thu, 14 Nov 2019 11:03:23 -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 lRa3Eb8iNgKZ for ; Thu, 14 Nov 2019 11:03:21 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2666C12002E for ; Thu, 14 Nov 2019 11:03:21 -0800 (PST) Received: from localhost (h-4-44.A165.priv.bahnhof.se [158.174.4.44]) by mail.tail-f.com (Postfix) with ESMTPSA id 664DD1AE0312; Thu, 14 Nov 2019 20:03:19 +0100 (CET) Date: Thu, 14 Nov 2019 20:03:19 +0100 (CET) Message-Id: <20191114.200319.376479893059194256.mbj@tail-f.com> To: kent+ietf@watsen.net Cc: netconf@ietf.org From: Martin Bjorklund In-Reply-To: <20191114.165050.356278327445084771.mbj@tail-f.com> References: <20191114.144738.728144006347516638.mbj@tail-f.com> <0100016e6a936a0d-47636ce9-345c-4009-8d74-9703905933aa-000000@email.amazonses.com> <20191114.165050.356278327445084771.mbj@tail-f.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] crypto-types and keystore comments 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, 14 Nov 2019 19:03:23 -0000 Martin Bjorklund wrote: > Kent Watsen wrote: > > Hi Martin, > > > > >> True. But how can we define a way to get a list per instance? Should > > >> there be a "config false" list wherever the "algorithm" node appears > > >> (i.e., put the list into the crypto-type groupings having the > > >> algorithm node?) > > > > > > I don't know, probably. Do we really want that? Probably not. > > > > Per-instance may be too granular. If thinking that said curations > > occur of protocol boundaries, then maybe have a config false list in > > ietf-ssh-common and ietf-tis-common? Not perfect, as an application > > may use more than one SSH library or more than one TLS library, but > > it's much less likely. > > Yes, better. > > > > This is exaclty why I suggested earlier that we don't spend time > > > trying to solve this problem at all now. I'd rather not put in > > > something that we know doesn't really work. > > > > Wait, no, there is a very real issue here that cannot be ignored. Or > > do you feel that we should give up entirely on trying to enable > > servers to proactively express what algorithms they support? > > > > > > > > >>> Do you have a pointer to this? > > >> > > >> There was an email from Juergen a few months back. > > > > > > But that was based on a misunderstanding. (or you mean something > > > else) > > > > Now I'm unsure what you're talking about, do you have a pointer to it? > > I am talking about this: > https://mailarchive.ietf.org/arch/browse/netconf/?q= Should have been: https://mailarchive.ietf.org/arch/msg/netconf/G9lHICXD5H9MzQ9D9-xMxdZIJRM /martin From nobody Thu Nov 14 13:57:47 2019 Return-Path: <0100016e6bec0c38-36cc14b7-8e2b-4995-9030-58959dbaaeaa-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 4421F120020; Thu, 14 Nov 2019 13:57:45 -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 Wb5AWMfr39mu; Thu, 14 Nov 2019 13:57:43 -0800 (PST) Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B38B012000F; Thu, 14 Nov 2019 13:57:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1573768662; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=IrmR5Xr04uPTSxBI99CVjL42aY35SaOn2n55RLybKys=; b=AFagtR7neF97iX3Sizb86jkD3WL5Xvm3WYP5ECFGekEN/9mtfOiBXWXtWZ4/PvYD HR7f6uvVx1L5/iRWVyhfq7m5UCZ/pT7cGJ8M/aQvRYJBf5gnWZUG4BnqQ8B/j5FTCNB TA85JEiU8ajoQOPMT/08CJn1WtUR44k37WYYn1VE= From: Kent Watsen Message-ID: <0100016e6bec0c38-36cc14b7-8e2b-4995-9030-58959dbaaeaa-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A96737EB-B671-4B9C-B279-3BF03D78BBDE" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 14 Nov 2019 21:57:42 +0000 In-Reply-To: <0100016df40225ff-4853b440-cb03-4edb-a9f4-4fd24a9adf90-000000@email.amazonses.com> Cc: "netconf-chairs@ietf.org" To: "netconf@ietf.org" References: <0100016df40225ff-4853b440-cb03-4edb-a9f4-4fd24a9adf90-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.11.14-54.240.8.83 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] Slides for NETCONF 106 Presentations 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, 14 Nov 2019 21:57:45 -0000 --Apple-Mail=_A96737EB-B671-4B9C-B279-3BF03D78BBDE Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Presenters, - Please try to send your slides by EOB tomorrow. - Be sure that your presentation contains slide numbers. - Be sure to send the PDF version of your presentation. - Send your slides to the "netconf-chairs" alias (CC-ed). Thanks! Kent (and Mahesh) --Apple-Mail=_A96737EB-B671-4B9C-B279-3BF03D78BBDE Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Presenters,

    - Please try to send your slides by EOB tomorrow.
    - Be sure that your presentation contains slide numbers.
    - Be sure to send the PDF version of your presentation.
    - Send your slides to the "netconf-chairs" alias (CC-ed).

Thanks!
Kent (and Mahesh)

--Apple-Mail=_A96737EB-B671-4B9C-B279-3BF03D78BBDE-- From nobody Fri Nov 15 04:48:17 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC40D120841 for ; Fri, 15 Nov 2019 04:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.248 X-Spam-Level: X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnzhVNObrKHm for ; Fri, 15 Nov 2019 04:48:14 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40119.outbound.protection.outlook.com [40.107.4.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C556120838 for ; Fri, 15 Nov 2019 04:48:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=B/yUTf4zLTSr2SnUYcfXzz1S0EKmAgnFycaG5ItpBkZFAjGFtyJOndsVu+7xdotjVCc5QgTtzDKLvXlVTkKTV6gKw8aOuv49qNMqxAMsFsMDgtP7tyTBOKWe4OVMtEOBKifoyFGGh9M/1SLJIcevEHYh4/98ek1NboVMIaZwg9CRncBXHv5VdN3vt8Lolf04+PO1FX1DVL3yh3TOJ4FZM15G43O9mGdIbuZRAGNX6vtxAEPqYnDbsBKPM90UxH1rsze+tWda9GWKp15vIy8nSLhz6xm41l2N2jutCJyZyopa0Fwz7cc6cUqmzL9wh+Wkow5q4Q+l+dHuhp9pj4kqhw== 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=7Wc9E8JYICRZdk41a2RVNp6OThfTCIl4bn9NZOfE5VI=; b=ROJXeGJS83J+6xYWkFBQ/IRs4Ae6Y4zvq5GKYxRQYCso9rBVIvwOdfGvu9vimMMndBKDpHi+JyGS362Gd9B4+tCbhiGRFeB/tyrKE96rSR8mNs27gr5U5rXpvniEE6bsX1LmhGUD559nqXWC1ccyzd+nM2N/OgnN5d/s17Vq4B/1WgoZHDiz7dwYAuRP+rrlRzg1ovYqllnom2wiFUs6czbRpWo3tQEvmATJsDr/sHgzWAWSaNjURieuCbTgVP7rKkCjOdfu+4/nIHu5OwAn5KOSuYPVUFb36cvn/PBFjtT0yajeP3M6F53IwU3mx4smVvvCekqpIY3Gtvrhe+8xCQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7Wc9E8JYICRZdk41a2RVNp6OThfTCIl4bn9NZOfE5VI=; b=f8JpxoXJUwJ5bKSChf6ezZ0ycCsMc1vSK9yA97Ngb7N1qs9NF9aoCqEhFoj1YNGhonViGXLQc/dOM4hwodgOuK35aiBaQ3VuQHOdZRdQiUTZK0zaKTXhki4biwHNcGz+nyFB9Zf6Np3vKPDJlN7zwtE7XzxKkncMh4MHyqMx3tA= Received: from DB7PR07MB5147.eurprd07.prod.outlook.com (20.178.42.32) by DB7PR07MB6091.eurprd07.prod.outlook.com (20.178.106.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.17; Fri, 15 Nov 2019 12:48:11 +0000 Received: from DB7PR07MB5147.eurprd07.prod.outlook.com ([fe80::e5bf:72e6:a66c:401a]) by DB7PR07MB5147.eurprd07.prod.outlook.com ([fe80::e5bf:72e6:a66c:401a%3]) with mapi id 15.20.2451.029; Fri, 15 Nov 2019 12:48:11 +0000 From: tom petch To: Kent Watsen , Martin Bjorklund CC: "bill.wu@huawei.com" , "rwilton@cisco.com" , "netconf@ietf.org" Thread-Topic: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04 Thread-Index: AQHVm7LwuMip8QrCR0uFvhT7rV9RMA== Date: Fri, 15 Nov 2019 12:48:11 +0000 Message-ID: <02e801d59bb2$e43a2f00$4001a8c0@gateway.2wire.net> References: <0100016e68049a12-bcb2acea-a4e2-42f9-8eab-05bab261d5dd-000000@email.amazonses.com> <20191114.101406.2087098792700938588.mbj@tail-f.com> <0100016e69b1f262-27a7a4b7-4e6e-4553-9bc5-c76bb7739cee-000000@email.amazonses.com> <20191114.130328.235293728895543729.mbj@tail-f.com> <0100016e6a07d334-324f48f9-5dae-4aa4-8b6a-1c16a8a8033c-000000@email.amazonses.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0136.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9f::28) To DB7PR07MB5147.eurprd07.prod.outlook.com (2603:10a6:10:68::32) authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: Microsoft Outlook Express 6.00.2800.1106 x-originating-ip: [86.139.211.103] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 43d3f265-fa39-4a3a-4069-08d769ca129a x-ms-traffictypediagnostic: DB7PR07MB6091: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02229A4115 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(376002)(39860400002)(366004)(346002)(396003)(54094003)(13464003)(189003)(199004)(66946007)(62236002)(44716002)(229853002)(81686011)(81816011)(76176011)(66556008)(64756008)(66446008)(9686003)(6512007)(44736005)(6486002)(6436002)(25786009)(86362001)(478600001)(50226002)(7736002)(4720700003)(256004)(186003)(6116002)(2906002)(3846002)(14454004)(14444005)(476003)(446003)(99286004)(14496001)(486006)(71190400001)(81156014)(8936002)(52116002)(305945005)(81166006)(66066001)(71200400001)(110136005)(8676002)(54906003)(316002)(386003)(5660300002)(6246003)(102836004)(6506007)(4326008)(66476007)(26005)(1556002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB7PR07MB6091; H:DB7PR07MB5147.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: slL7qSpwAioZI/6ufnz+qRUaSq4YuhxlrM5wFfWZgXPOQeW+GolOCnFILaOl2uRwFWI0NV7g8hDzi7Wq4n969S2Bo+vqolBlel47k+9a+0DT/TF52uY4D94h3RWm+O+zCpnsxjEsFPQRpwQ9WnzH1hVUBjMx6AHfqPYIpBElTKSd6LAyVVsN1OPfMLjKsaXw3n7sQw3aPlQK16wyXMxDlvMVFH3HxlZT04BeFbdUybvggVOBRKH98+ZZRba6pM0vzvczCVVPeQLbnoHap50uiKW289WkxiAK4zs8Keg1V2qKOCJ50TOt8c1iuFtJV1VNpze29qbo8ECkRsD1pTJmZ5au/xWGL0JygEhSSlTjPoVVRG2vK+8OoG+KToFezXyNZdH74ujOMlot87Gccp+5gQ60C4xE8L0vrQj2rV04fBxJbcdS/w4SmUbukxmGWMjO x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-ID: <0EAC99015A3EB947A367D4ED5BF1584E@eurprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 43d3f265-fa39-4a3a-4069-08d769ca129a X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2019 12:48:11.4002 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: o8JiViMvvucNmg+2ZRPye1YmwX9lpaK0RLiwJMtbo7izgMSnDhrGnTfEDrVTw8TX6aBzOG3i4f7q7a+BE6Xiew== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB6091 Archived-At: Subject: Re: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04 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, 15 Nov 2019 12:48:17 -0000 ---- Original Message ----- From: "Kent Watsen" To: "Martin Bjorklund" Cc: ; ; ; ; Sent: Thursday, November 14, 2019 1:08 PM Hi Martin, > Personally I don't care; just pointing out a discussion that may be > relevant. Ack. Let's focus on the module names, the draft name will fall out from that discussion. Kent I see this thread conflating names with names and names. Module name I see as the most important; it is permanent, will be seen by many people in many contexts and so must be an accurate reflection of the contents. If, during the development of the I-D, the contents change, then change the name! Yes, those with early implementations will have to change but that is always the price of implementing an I-D RFC Title also matters; it is permanent, widely seen in many contexts and should tell people whether or not to go further, to read the abstract. But the name of the I-D is quite different. It vanishes when the RFC appears and ceases to be of any relevance but must change from -- to -ietf- when an I-D is adopted. Otherwise it is just a string, an identifier and subject to the requirements of an identifier - like, stabillity. So any other change than the one I just mentioned I think a bad idea, which is what I said on OPSAWG; there the title is good, no need to change, the I-D name is just an identifier, leave it alone, do not try to give it semantic significance. Tom Petch > I think it is the name "ietf-http-server" that seems to indicate that > this a module that can be used to configure any HTTP server. (See > below!) It's more like a possible basis to configure any HTTP server, which to me still seems like the right thing to do, until someone can provide a concrete technical reason why it cannot be so. > I wonder if the names should be "ietf-http-server-groupings" instead? Hmmm, this is an interesting idea... > (and same for tcp / ssh / tls, but not netconf / restconf). I see why you might say this, but the netconf/restconf drafts also define groupings, which are (IMO) more important than the containers, which we added under questionable conditions (i.e., the "client" containers make almost no sense, and the "server" containers have limited use, especially without the ability to augment/refine things when "implemented"). > We > already have some "-types" modules. Or even "ietf-http-server-types", > if by "type" we mean "typedef and/or grouping". ...and identities and features (and maybe something else I'm not thinking about just now). > This could also be a way to make the name less problematic. It makes > it more obvious that these modules provide building blocks, rather > than a complete solution. I truly appreciate the intention behind this idea and love the idea of sticking with an undiluted "http", but I question if putting "grouping" into the module name is ideal, perhaps "base" or "basis" would be better? Even for the NC/RC modules, they are merely a base/basis for higher-level business logic. [note: I also thought about "params", but the (IMO useless) containers in the NC/RC modules don't lend themselves well to being called "params"] To help visualize these options: ietf-http-server-base ietf-http-server-basis ietf-http-server-params ietf-restconf-server-base ietf-restconf-server-basis ietf-restconf-server-params To be clear, I'm not yet agreeing to or promoting this approach yet, though it seems promising. Kent // contributor From nobody Fri Nov 15 08:51:55 2019 Return-Path: <0100016e6ffa57a2-cb6e666a-b4bb-4e8c-b69a-b117aaa79baa-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 6ECA31208D7 for ; Fri, 15 Nov 2019 08:51: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 eHP_vKKx9wYC for ; Fri, 15 Nov 2019 08:51:49 -0800 (PST) Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 992D0120013 for ; Fri, 15 Nov 2019 08:51:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1573836708; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=vvJc8xoIx0OUW85KqIsoZpLYbVvTjdGFsCT9LXCkc0I=; b=S2WTf1BZg5xVgyAiT8K9WzAFPRi4xiZfW508D+whKFDGEvCHIsO6sPPxDR43RBat qSBzvSW5FgL7PtowW68VxAvGWQrWGgkc08VOjw7WlZUQO0eXFxUFy/zhA9OZPO3y6DC MmsHoljH0FNghy7Agu3OmdaGLQbGPpdDUc5esvL4= From: Kent Watsen Message-ID: <0100016e6ffa57a2-cb6e666a-b4bb-4e8c-b69a-b117aaa79baa-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_5114464E-11C7-4AA9-8C85-1EB5B5509286" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 15 Nov 2019 16:51:48 +0000 In-Reply-To: <02e801d59bb2$e43a2f00$4001a8c0@gateway.2wire.net> Cc: Martin Bjorklund , "bill.wu@huawei.com" , "rwilton@cisco.com" , "netconf@ietf.org" To: tom petch References: <0100016e68049a12-bcb2acea-a4e2-42f9-8eab-05bab261d5dd-000000@email.amazonses.com> <20191114.101406.2087098792700938588.mbj@tail-f.com> <0100016e69b1f262-27a7a4b7-4e6e-4553-9bc5-c76bb7739cee-000000@email.amazonses.com> <20191114.130328.235293728895543729.mbj@tail-f.com> <0100016e6a07d334-324f48f9-5dae-4aa4-8b6a-1c16a8a8033c-000000@email.amazonses.com> <02e801d59bb2$e43a2f00$4001a8c0@gateway.2wire.net> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.11.15-54.240.8.83 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04 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, 15 Nov 2019 16:51:53 -0000 --Apple-Mail=_5114464E-11C7-4AA9-8C85-1EB5B5509286 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii At first I thought that there wouldn't be need to respond to this = message, as it retraces ground we covered before, but latching onto the = "the name of the draft doesn't matter" theme as opportunistically as = possible, I hereby recommend that we name the adopted draft = "draft-ietf-netconf-http-client-server" (yes, "http", as it I think it = should be), whilst having potentially different names for modules and = groupings inside and, of course, a title that makes everyone happy. With this understanding in place, it should be okay to close the WGLC = now, right? Mahesh? Kent // contributor (and recused chair) > On Nov 15, 2019, at 7:48 AM, tom petch wrote: >=20 > ---- Original Message ----- > From: "Kent Watsen" > To: "Martin Bjorklund" > Cc: ; ; ; > ; > Sent: Thursday, November 14, 2019 1:08 PM >=20 > Hi Martin, >=20 >> Personally I don't care; just pointing out a discussion that may be >> relevant. >=20 > Ack. Let's focus on the module names, the draft name will fall out = from > that discussion. >=20 > >=20 > Kent >=20 > I see this thread conflating names with names and names. >=20 > Module name I see as the most important; it is permanent, will be seen > by many people in many contexts and so must be an accurate reflection = of > the contents. If, during the development of the I-D, the contents > change, then change the name! Yes, those with early implementations > will have to change but that is always the price of implementing an = I-D >=20 > RFC Title also matters; it is permanent, widely seen in many contexts > and should tell people whether or not to go further, to read the > abstract. >=20 > But the name of the I-D is quite different. It vanishes when the RFC > appears and ceases to be of any relevance but must change > from -- to -ietf- when an I-D is adopted. Otherwise it is = just > a string, an identifier and subject to the requirements of an > identifier - like, stabillity. So any other change than the one I = just > mentioned I think a bad idea, which is what I said on OPSAWG; there = the > title is good, no need to change, the I-D name is just an identifier, > leave it alone, do not try to give it semantic significance. >=20 > Tom Petch >=20 >=20 >> I think it is the name "ietf-http-server" that seems to indicate that >> this a module that can be used to configure any HTTP server. (See >> below!) >=20 > It's more like a possible basis to configure any HTTP server, which to > me still seems like the right thing to do, until someone can provide a > concrete technical reason why it cannot be so. >=20 >=20 >> I wonder if the names should be "ietf-http-server-groupings" instead? >=20 > Hmmm, this is an interesting idea... >=20 >> (and same for tcp / ssh / tls, but not netconf / restconf). >=20 > I see why you might say this, but the netconf/restconf drafts also > define groupings, which are (IMO) more important than the containers, > which we added under questionable conditions (i.e., the "client" > containers make almost no sense, and the "server" containers have > limited use, especially without the ability to augment/refine things > when "implemented"). >=20 >> We >> already have some "-types" modules. Or even = "ietf-http-server-types", >> if by "type" we mean "typedef and/or grouping". >=20 > ...and identities and features (and maybe something else I'm not > thinking about just now). >=20 >> This could also be a way to make the name less problematic. It makes >> it more obvious that these modules provide building blocks, rather >> than a complete solution. >=20 > I truly appreciate the intention behind this idea and love the idea of > sticking with an undiluted "http", but I question if putting = "grouping" > into the module name is ideal, perhaps "base" or "basis" would be > better? Even for the NC/RC modules, they are merely a base/basis for > higher-level business logic. [note: I also thought about "params", = but > the (IMO useless) containers in the NC/RC modules don't lend = themselves > well to being called "params"] >=20 > To help visualize these options: >=20 > ietf-http-server-base > ietf-http-server-basis > ietf-http-server-params >=20 > ietf-restconf-server-base > ietf-restconf-server-basis > ietf-restconf-server-params >=20 > To be clear, I'm not yet agreeing to or promoting this approach yet, > though it seems promising. >=20 > Kent // contributor >=20 >=20 --Apple-Mail=_5114464E-11C7-4AA9-8C85-1EB5B5509286 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

At first I thought that there wouldn't = be need to respond to this message, as it retraces ground we covered = before, but latching onto the "the name of the draft doesn't matter" = theme as opportunistically as possible, I hereby recommend that we name = the adopted draft "draft-ietf-netconf-http-client-server" (yes, "http", = as it I think it should be), whilst having potentially different names = for modules and groupings inside and, of course, a title that makes = everyone happy.

With = this understanding in place, it should be okay to close the WGLC now, = right?   Mahesh?

Kent // contributor (and recused chair)



On Nov 15, 2019, at 7:48 AM, = tom petch <ietfc@btconnect.com> wrote:

---- = Original Message -----
From: "Kent Watsen" <kent+ietf@watsen.net>
To: "Martin = Bjorklund" <mbj@tail-f.com>
Cc: <bill.wu@huawei.com>; = <ietfc@btconnect.com>; <rwilton@cisco.com>;<httpbis-chairs@ietf.org>; <netconf@ietf.org>
Sent: Thursday, November 14, 2019 1:08 PM

Hi Martin,

Personally I don't care; just pointing out a = discussion that may be
relevant.

Ack.  Let's focus on the = module names, the draft name will fall out from
that = discussion.

<tp>

Kent

I see this thread = conflating names with names and names.

Module= name I see as the most important; it is permanent, will be seen
by many people in many contexts and so must be an accurate = reflection of
the contents.  If, during the = development of the I-D, the contents
change, then change = the name!  Yes, those with early implementations
will = have to change but that is always the price of implementing an I-D

RFC Title also matters; it is permanent, = widely seen in many contexts
and should tell people = whether or not to go further, to read the
abstract.

But the name of the I-D is quite different. =  It vanishes when the RFC
appears and ceases to be of = any relevance but must change
from -<author>- to = -ietf- when an I-D is adopted.  Otherwise it is just
a = string, an identifier and subject to the requirements of an
identifier - like, stabillity.   So any other = change than the one I just
mentioned I think a bad idea, = which is what I said on OPSAWG; there the
title is good, = no need to change, the I-D name is just an identifier,
leave= it alone, do not try to give it semantic significance.

Tom Petch


I think it is the name = "ietf-http-server" that seems to indicate that
this a = module that can be used to configure any HTTP server.  (See
below!)

It's more = like a possible basis to configure any HTTP server, which to
me still seems like the right thing to do, until someone can = provide a
concrete technical reason why it cannot be = so.


I wonder if the names should be "ietf-http-server-groupings" = instead?

Hmmm, this is an = interesting idea...

(and same for tcp / ssh / tls, but not netconf / = restconf).

I see why you might = say this, but the netconf/restconf drafts also
define = groupings, which are (IMO) more important than the containers,
which we added under questionable conditions (i.e., the = "client"
containers make almost no sense, and the "server" = containers have
limited use, especially without the = ability to augment/refine things
when "implemented").

We
already have some "-types" modules.  Or even = "ietf-http-server-types",
if by "type" we mean "typedef = and/or grouping".

...and = identities and features (and maybe something else I'm not
thinking about just now).

This could also be a way = to make the name less problematic.  It makes
it more = obvious that these modules provide building blocks, rather
than a complete solution.

I truly appreciate the intention behind this idea and love = the idea of
sticking with an undiluted "http", but I = question if putting "grouping"
into the module name is = ideal, perhaps "base" or "basis" would be
better? =   Even for the NC/RC modules, they are merely a base/basis = for
higher-level business logic.  [note: I also = thought about "params", but
the (IMO useless) containers = in the NC/RC modules don't lend themselves
well to being = called "params"]

To help visualize these = options:

ietf-http-server-base
ietf-http-server-basis
ietf-http-server-params
ietf-restconf-server-base
ietf-restconf-server-basis
ietf-restconf-server-params

To = be clear, I'm not yet agreeing to or promoting this approach yet,
though it seems promising.

Kent = // contributor



= --Apple-Mail=_5114464E-11C7-4AA9-8C85-1EB5B5509286-- From nobody Fri Nov 15 08:53:23 2019 Return-Path: <0100016e6ffbb644-6ceefcb4-0600-4c65-801f-b09b47cc4d58-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 EB20D1208D7 for ; Fri, 15 Nov 2019 08:53:21 -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 RgT7fe7QZWCD for ; Fri, 15 Nov 2019 08:53:19 -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 658A2120013 for ; Fri, 15 Nov 2019 08:53:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1573836798; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=vxZfpOul59dax8v8EE6POj4YAiJc67BCgCAbZoiYadk=; b=cnUs/8KbBVQny4J6GTHBklyTP8sRVhqXkNoZonYFPIJ3STwYJwgjCEo0oQgf72PB gfW1XsOCYjg1AB57ITJmTLoEiX02lJr1XXwGh6ebcTkHtDvVnE3oFAc1oeXrb91HFf5 4xjC3/AZuTayjR0liITQpmdU8jjjG4IN0gsFvOBU= From: Kent Watsen Message-ID: <0100016e6ffbb644-6ceefcb4-0600-4c65-801f-b09b47cc4d58-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E4FBDC26-54D6-4D91-93AC-56661F2F8E74" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 15 Nov 2019 16:53:17 +0000 In-Reply-To: <0D4EB33A-C8DE-4BE8-8EE8-DC335029D845@watsen.net> Cc: Martin Bjorklund , "bill.wu@huawei.com" , "rwilton@cisco.com" , "netconf@ietf.org" To: tom petch References: <0100016e68049a12-bcb2acea-a4e2-42f9-8eab-05bab261d5dd-000000@email.amazonses.com> <20191114.101406.2087098792700938588.mbj@tail-f.com> <0100016e69b1f262-27a7a4b7-4e6e-4553-9bc5-c76bb7739cee-000000@email.amazonses.com> <20191114.130328.235293728895543729.mbj@tail-f.com> <0100016e6a07d334-324f48f9-5dae-4aa4-8b6a-1c16a8a8033c-000000@email.amazonses.com> <02e801d59bb2$e43a2f00$4001a8c0@gateway.2wire.net> <0D4EB33A-C8DE-4BE8-8EE8-DC335029D845@watsen.net> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.11.15-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04 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, 15 Nov 2019 16:53:22 -0000 --Apple-Mail=_E4FBDC26-54D6-4D91-93AC-56661F2F8E74 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Sorry, I meant s/WGLC/adoption/ (edited below). K. > On Nov 15, 2019, at 11:51 AM, Kent Watsen = wrote: >=20 >=20 > At first I thought that there wouldn't be need to respond to this = message, as it retraces ground we covered before, but latching onto the = "the name of the draft doesn't matter" theme as opportunistically as = possible, I hereby recommend that we name the adopted draft = "draft-ietf-netconf-http-client-server" (yes, "http", as it I think it = should be), whilst having potentially different names for modules and = groupings inside and, of course, a title that makes everyone happy. >=20 > With this understanding in place, it should be okay to close the = adoption now, right? Mahesh? >=20 > Kent // contributor (and recused chair) >=20 >=20 >=20 >> On Nov 15, 2019, at 7:48 AM, tom petch > wrote: >>=20 >> ---- Original Message ----- >> From: "Kent Watsen" > >> To: "Martin Bjorklund" > >> Cc: >; = >; >; >> >; = > >> Sent: Thursday, November 14, 2019 1:08 PM >>=20 >> Hi Martin, >>=20 >>> Personally I don't care; just pointing out a discussion that may be >>> relevant. >>=20 >> Ack. Let's focus on the module names, the draft name will fall out = from >> that discussion. >>=20 >> >>=20 >> Kent >>=20 >> I see this thread conflating names with names and names. >>=20 >> Module name I see as the most important; it is permanent, will be = seen >> by many people in many contexts and so must be an accurate reflection = of >> the contents. If, during the development of the I-D, the contents >> change, then change the name! Yes, those with early implementations >> will have to change but that is always the price of implementing an = I-D >>=20 >> RFC Title also matters; it is permanent, widely seen in many contexts >> and should tell people whether or not to go further, to read the >> abstract. >>=20 >> But the name of the I-D is quite different. It vanishes when the RFC >> appears and ceases to be of any relevance but must change >> from -- to -ietf- when an I-D is adopted. Otherwise it is = just >> a string, an identifier and subject to the requirements of an >> identifier - like, stabillity. So any other change than the one I = just >> mentioned I think a bad idea, which is what I said on OPSAWG; there = the >> title is good, no need to change, the I-D name is just an identifier, >> leave it alone, do not try to give it semantic significance. >>=20 >> Tom Petch >>=20 >>=20 >>> I think it is the name "ietf-http-server" that seems to indicate = that >>> this a module that can be used to configure any HTTP server. (See >>> below!) >>=20 >> It's more like a possible basis to configure any HTTP server, which = to >> me still seems like the right thing to do, until someone can provide = a >> concrete technical reason why it cannot be so. >>=20 >>=20 >>> I wonder if the names should be "ietf-http-server-groupings" = instead? >>=20 >> Hmmm, this is an interesting idea... >>=20 >>> (and same for tcp / ssh / tls, but not netconf / restconf). >>=20 >> I see why you might say this, but the netconf/restconf drafts also >> define groupings, which are (IMO) more important than the containers, >> which we added under questionable conditions (i.e., the "client" >> containers make almost no sense, and the "server" containers have >> limited use, especially without the ability to augment/refine things >> when "implemented"). >>=20 >>> We >>> already have some "-types" modules. Or even = "ietf-http-server-types", >>> if by "type" we mean "typedef and/or grouping". >>=20 >> ...and identities and features (and maybe something else I'm not >> thinking about just now). >>=20 >>> This could also be a way to make the name less problematic. It = makes >>> it more obvious that these modules provide building blocks, rather >>> than a complete solution. >>=20 >> I truly appreciate the intention behind this idea and love the idea = of >> sticking with an undiluted "http", but I question if putting = "grouping" >> into the module name is ideal, perhaps "base" or "basis" would be >> better? Even for the NC/RC modules, they are merely a base/basis = for >> higher-level business logic. [note: I also thought about "params", = but >> the (IMO useless) containers in the NC/RC modules don't lend = themselves >> well to being called "params"] >>=20 >> To help visualize these options: >>=20 >> ietf-http-server-base >> ietf-http-server-basis >> ietf-http-server-params >>=20 >> ietf-restconf-server-base >> ietf-restconf-server-basis >> ietf-restconf-server-params >>=20 >> To be clear, I'm not yet agreeing to or promoting this approach yet, >> though it seems promising. >>=20 >> Kent // contributor >>=20 >>=20 >=20 --Apple-Mail=_E4FBDC26-54D6-4D91-93AC-56661F2F8E74 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Sorry, I meant s/WGLC/adoption/   (edited below).

K.


On Nov = 15, 2019, at 11:51 AM, Kent Watsen <kent+ietf@watsen.net> wrote:


At first I thought that there wouldn't be need to = respond to this message, as it retraces ground we covered before, but = latching onto the "the name of the draft doesn't matter" theme as = opportunistically as possible, I hereby recommend that we name the = adopted draft "draft-ietf-netconf-http-client-server" (yes, "http", as = it I think it should be), whilst having potentially different names for = modules and groupings inside and, of course, a title that makes everyone = happy.

With this = understanding in place, it should be okay to close the adoption now, = right?   Mahesh?

Kent // contributor (and recused chair)



On Nov 15, 2019, at 7:48 AM, tom petch <ietfc@btconnect.com>= wrote:

---- Original Message -----
From: "Kent Watsen" = <kent+ietf@watsen.net>
To: "Martin = Bjorklund" <mbj@tail-f.com>
Cc: <bill.wu@huawei.com>; = <ietfc@btconnect.com>; <rwilton@cisco.com>;<httpbis-chairs@ietf.org>; <netconf@ietf.org>
Sent: Thursday, November 14, 2019 1:08 PM

Hi Martin,

Personally I don't care; just pointing out a = discussion that may be
relevant.

Ack.  Let's focus on the = module names, the draft name will fall out from
that = discussion.

<tp>

Kent

I see this thread = conflating names with names and names.

Module= name I see as the most important; it is permanent, will be seen
by many people in many contexts and so must be an accurate = reflection of
the contents.  If, during the = development of the I-D, the contents
change, then change = the name!  Yes, those with early implementations
will = have to change but that is always the price of implementing an I-D

RFC Title also matters; it is permanent, = widely seen in many contexts
and should tell people = whether or not to go further, to read the
abstract.

But the name of the I-D is quite different. =  It vanishes when the RFC
appears and ceases to be of = any relevance but must change
from -<author>- to = -ietf- when an I-D is adopted.  Otherwise it is just
a = string, an identifier and subject to the requirements of an
identifier - like, stabillity.   So any other = change than the one I just
mentioned I think a bad idea, = which is what I said on OPSAWG; there the
title is good, = no need to change, the I-D name is just an identifier,
leave= it alone, do not try to give it semantic significance.

Tom Petch


I think it is the name = "ietf-http-server" that seems to indicate that
this a = module that can be used to configure any HTTP server.  (See
below!)

It's more = like a possible basis to configure any HTTP server, which to
me still seems like the right thing to do, until someone can = provide a
concrete technical reason why it cannot be = so.


I wonder if the names should be "ietf-http-server-groupings" = instead?

Hmmm, this is an = interesting idea...

(and same for tcp / ssh / tls, but not netconf / = restconf).

I see why you might = say this, but the netconf/restconf drafts also
define = groupings, which are (IMO) more important than the containers,
which we added under questionable conditions (i.e., the = "client"
containers make almost no sense, and the "server" = containers have
limited use, especially without the = ability to augment/refine things
when "implemented").

We
already have some "-types" modules.  Or even = "ietf-http-server-types",
if by "type" we mean "typedef = and/or grouping".

...and = identities and features (and maybe something else I'm not
thinking about just now).

This could also be a way = to make the name less problematic.  It makes
it more = obvious that these modules provide building blocks, rather
than a complete solution.

I truly appreciate the intention behind this idea and love = the idea of
sticking with an undiluted "http", but I = question if putting "grouping"
into the module name is = ideal, perhaps "base" or "basis" would be
better? =   Even for the NC/RC modules, they are merely a base/basis = for
higher-level business logic.  [note: I also = thought about "params", but
the (IMO useless) containers = in the NC/RC modules don't lend themselves
well to being = called "params"]

To help visualize these = options:

ietf-http-server-base
ietf-http-server-basis
ietf-http-server-params
ietf-restconf-server-base
ietf-restconf-server-basis
ietf-restconf-server-params

To = be clear, I'm not yet agreeing to or promoting this approach yet,
though it seems promising.

Kent = // contributor




= --Apple-Mail=_E4FBDC26-54D6-4D91-93AC-56661F2F8E74-- From nobody Fri Nov 15 20:50:49 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58EB61200B3; Fri, 15 Nov 2019 20:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVUPWQ-A28kd; Fri, 15 Nov 2019 20:50:46 -0800 (PST) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (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 6B5DD120089; Fri, 15 Nov 2019 20:50:46 -0800 (PST) Received: by mail-pg1-x534.google.com with SMTP id r18so6890582pgu.13; Fri, 15 Nov 2019 20:50:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=aWSRse88WTbN2VaIOp+dfpmdLt23LYnEYeHEg1tx2TU=; b=npjb7/CGIKJnDZRnFBJlf5LEGUPZivY6vdMv4b4oBa6gsfVOszoi2uvV0lRWKrPoJf 652LGRJl2BZ60LVlWeABSKlDCgg2atXs6vcw9cKQdIk41VZN73T7H3pDTSfYIfCBRcgV MHUXHD5Cji2sgBC/xRW+JVHsGcsDBS4SkplxjJMSTwLuyE5LiCT7InlTmnUpkZpnf4xk tFkLoe5Y7VM4T/A+SRVIq7ycg3wBulGGlLtz8zX3xvi2fWzX9Sh0v4umPTp6Ii/qOSRE TpZO0uW5GC0XRVkyz4mq1JJAMMxFfbraBvCzXfIrHYUkC3slkXMx+upIls1wLObYDhTF K4yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=aWSRse88WTbN2VaIOp+dfpmdLt23LYnEYeHEg1tx2TU=; b=EnWq7ptlbF8bP9bBFaCeoAwplYuz3nRtssZQMInYONyr4Lb0XNPvhls7+ko1CRgbhF Au6Y8EcjjkM9991PUlJr0+M8jvK85Ax4vvAnse6VccihlA8V8o++gXRNUEgYnLjcDExx sF0ToDGcEL4PnlrzoQt4HSNnHtQ7ciH7R1RlehN3TeIbPpqwFOQTKhy/qQRokrEJpl5Q YUN5RGbAZ8ADPnXbQx8DwOHlEwL0bgOUTx0s7Aw1kAZvAUbZFzFaLV0L8tyPQ2h5eiwT Y9URyltN95RvTvQ+ArOpaJJ7vp9vjtnoSGtmZw90IBgyqBmYiHiZWYLSI91R548eoHf6 bdJA== X-Gm-Message-State: APjAAAVDRss3KW88CHZl5wAdwzq4HliHYLba7h0sLlQfv0FgBuDZBh+O kEqprL3wUpkjpkkF0WhZgsaYIjgGogU= X-Google-Smtp-Source: APXvYqx8MmDxYnC+HqFJMqdx6GGCeoyL4rc/hVHPMsIQYix1N2VLVK3XcTpj2B5bhvyN1zzyuxXRcg== X-Received: by 2002:a63:798c:: with SMTP id u134mr6655390pgc.325.1573879845467; Fri, 15 Nov 2019 20:50:45 -0800 (PST) Received: from [10.154.8.180] ([222.255.147.115]) by smtp.gmail.com with ESMTPSA id l33sm11445050pgb.79.2019.11.15.20.50.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Nov 2019 20:50:44 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Mahesh Jethanandani In-Reply-To: <150E2E2A-26D9-4B61-8639-B9025E92AD70@gmail.com> Date: Sat, 16 Nov 2019 11:50:41 +0700 Cc: httpbis-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <150E2E2A-26D9-4B61-8639-B9025E92AD70@gmail.com> To: Netconf X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [netconf] Adoption call for draft-kwatsen-netconf-http-client-server-04 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, 16 Nov 2019 04:50:48 -0000 This adoption call was supposed to close last week, but as the = discussion was still ongoing, I wanted to let it play out.=20 It is apparent from the thread that the consensus to adopt was rough, = with the lone dissent came from Mark, the httpbis chair. That dissent = has been duly noted. It is also clear from the thread that this draft is = needed, and that the WG does not want to see any more delays. Adopting = the draft only means that the work now happens in the WG, and that there = will be plenty of time to debate any more name changes. In addition, I am going to encourage the author(s) to present the = document in httpbis WG and for the httpbis chairs to invite him for that = presentation, by giving him a slot. This draft is adopted. Author(s), please publish the existing draft as = draft-ietf-netconf-http-client-server with no other changes as soon as = datatracker opens up for submission. Thanks. Mahesh Jethanandani (as co-chair) mjethanandani@gmail.com > On Nov 3, 2019, at 5:22 AM, Mahesh Jethanandani = wrote: >=20 > =EF=BB=BFJust a reminder. This adoption call is still open. >=20 >> On Oct 21, 2019, at 3:52 PM, Mahesh Jethanandani = wrote: >>=20 >> Hi WG, >>=20 >> The author has posted a -04 version of the draft, and believes that = it ready for WG adoption. >>=20 >> This starts a 2 week poll ending on November 4, to decide whether = this document should be made a WG document or not. Please reply to this = email whether or not you support adoption of this draft by the WG. = Indications that the draft has been read will be also be appreciated. >>=20 >> Thanks. >>=20 >> Mahesh Jethanandani >> mjethanandani@gmail.com >>=20 >>=20 >>=20 >=20 > Mahesh Jethanandani > mjethanandani@gmail.com >=20 >=20 >=20 From nobody Sat Nov 16 19:51:00 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5203B120839; Sat, 16 Nov 2019 19:50:48 -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 5WHcVltFsvRq; Sat, 16 Nov 2019 19:50:46 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10055.outbound.protection.outlook.com [40.107.1.55]) (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 E468D120046; Sat, 16 Nov 2019 19:50:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CV1kfoWUnVSHGk7z34XCZASxvnI9bFbyJkLBgcsu9cBj8yvIHZIz7j1e21Yy3vwSPrYvBrJxbpxE9TAr/oSsQY6CKmMWLigEi9uN3XDTjSoUed1pRtdN+8d8jzEBSxRg+sip6ymUexClsfN726lvS1YBxPX7sjwhQfKC30R9Iq6e3VSP5n7CdqXy3kx8TLkez2xws2EpXMaXxi4pYV6nOyBtJ2I1tEeW6gIl0gnf/nAyb39vFrImMQOji8YmFkRyaoFAUnzY/5w/tmAp993EUbq/za6vckswNEBu9yVfO+aeqJDXUwxdaUaLi5xBHr3mzsdFfNXv5DUI460zu6ubYQ== 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=BhxEfDOGA9Nj/9uUjGf8AgHnfwDAkPrVgWKYY3TstC4=; b=dyKsLMJ/MTmudbm4A9BhecPo7f84x8oJfcj6/ho/oeMMbe26A2OH7mmimXHP4qsrHofA+gfDovHcOIDrRf5Nvj8N0sJrCz+hi+7yZlOPtsVdSYh4HSvyOALKIfIRRfcW6C0slzj5+jOcN28Enf+Go5+caOUnDFNGj75Utpla7yzzUC2YKpLEOqSziLnglAcjVsVUkmvY7Q5Ddnm/IX/Vpi2S9Ub8ZRV7xNcqNsyPu1mdgf7/UA9Zc5ANO3DaHheL345qAoUgyG40C90q2q3bjmfNG4SqfiTH6UKZF/CPYBjlpgsMtbpNHzqbvyR9O+r+Yxz5tBXxp/m8j2RCeLJQJw== 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=BhxEfDOGA9Nj/9uUjGf8AgHnfwDAkPrVgWKYY3TstC4=; b=YuX09vF/a4jznp+rOGZjFUjkUhuB8n3D8ifs4PpZqEvq5l+4oEYlS+bZne89Lpc1cV9iflcJp96dJnmRD2TgJzNU+e1bH9xRDL8/JOCwJTcVN6GCJpAxfRBLyggeEDG9mgd+PlQZLZI82suS4fInKW+pRFH6VvjriUCXoyC/eC4= Received: from AM7PR07MB6214.eurprd07.prod.outlook.com (10.186.170.77) by AM7PR07MB6310.eurprd07.prod.outlook.com (10.186.168.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.7; Sun, 17 Nov 2019 03:50:42 +0000 Received: from AM7PR07MB6214.eurprd07.prod.outlook.com ([fe80::749e:982d:1c62:367b]) by AM7PR07MB6214.eurprd07.prod.outlook.com ([fe80::749e:982d:1c62:367b%4]) with mapi id 15.20.2474.012; Sun, 17 Nov 2019 03:50:42 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: Ladislav Lhotka , "yang-doctors@ietf.org" CC: "last-call@ietf.org" , "netconf@ietf.org" , "draft-ietf-netconf-notification-capabilities.all@ietf.org" Thread-Topic: Yangdoctors last call review of draft-ietf-netconf-notification-capabilities-05 Thread-Index: AQHVjifxsBW2rOU/zkWUCQzU06Ifbqd63YyQgAH2goCAEgPC0A== Date: Sun, 17 Nov 2019 03:50:42 +0000 Message-ID: References: <157233302184.6593.3869700028694968875@ietfa.amsl.com> <352449f5e1398ccfca7591e0e4555b710c766802.camel@nic.cz> In-Reply-To: <352449f5e1398ccfca7591e0e4555b710c766802.camel@nic.cz> 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: [31.133.152.152] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6adf14d1-0fef-4e30-c776-08d76b1151cb x-ms-traffictypediagnostic: AM7PR07MB6310: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 02243C58C6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(346002)(366004)(39860400002)(396003)(376002)(189003)(199004)(13464003)(186003)(66946007)(7696005)(66616009)(66476007)(66556008)(81156014)(64756008)(66446008)(81166006)(86362001)(15650500001)(5660300002)(8936002)(14444005)(4326008)(256004)(229853002)(6246003)(26005)(7736002)(14454004)(305945005)(6506007)(102836004)(71190400001)(53546011)(9686003)(52536014)(4744005)(8676002)(3846002)(446003)(476003)(76116006)(55016002)(25786009)(6116002)(478600001)(11346002)(71200400001)(99286004)(66574012)(110136005)(66066001)(2906002)(74316002)(54906003)(6436002)(316002)(76176011)(2501003)(486006)(33656002)(85182001)(85202003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM7PR07MB6310; H:AM7PR07MB6214.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: kTXV5F7dZU/VyFzA8Gov9eCQf0S+WiVIDSY1tvkq51DMJLe36hmfdsLzZw1dhmxtoaWMwMaqv+GrLLtnBVt9B/mxw08k+9JAxfyrXyFdcgPRPPWK026WNSqRbLyoj45khKPr1iXEs+7P0d2n1rYA96y9JAZdrvY7Gj2kQTfwmmT1N4dGnW3e5MHQg7rRRU/kp11HJ6u0Ez52hs4BDd7CE4jy/x37H2YzCQnwOAD1bTcUAVoT5XLJtk8pKxjq9/gYzNxQUcAmZCwQx3zCUeck8jIqlOpBe9MP89vrYsU+bb4eMILhiPbLk7e1QZHMDYMCGpeu0a8Pp847NElC3qKX6Unjb48Bkc+0Ef4svm3gdG7+jz0p1IweGEL6PgvQHxzAzeWI2+WBZbRUlwnPo/PjawGp4ILo4nxg3UkV82p0ZzeEt9QeFwpjhqsr9D2DxmUV x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01F4_01D59D3D.3B8ADDA0" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6adf14d1-0fef-4e30-c776-08d76b1151cb X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2019 03:50:42.5686 (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: B+c4KWNjmrHxpOpDl3Oq/ZuwoQIn/0N9zvEUPTkqLjDZEtFoSICTlGjHrttnfW4yEdm8bJ4feaUNr9Pyo7UVsUgCVuJ4YAcig4yOw9SMN9E= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6310 Archived-At: Subject: Re: [netconf] Yangdoctors last call review of draft-ietf-netconf-notification-capabilities-05 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, 17 Nov 2019 03:50:48 -0000 ------=_NextPart_000_01F4_01D59D3D.3B8ADDA0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable -----Original Message----- From: Ladislav Lhotka =20 Sent: 2019. november 6., szerda 0:44 To: Bal=C3=A1zs Lengyel ; = yang-doctors@ietf.org Cc: last-call@ietf.org; netconf@ietf.org; = draft-ietf-netconf-notification-capabilities.all@ietf.org Subject: Re: Yangdoctors last call review of = draft-ietf-netconf-notification-capabilities-05 ***** Appendix A. Instance data examples > - Example in Fig. 2: the element has an incorrect > XML namespace (of the ietf-datastores module). > BALAZS: I don't understand the comment; I don't see the error. Could=20 > you please advise me what you think should be there? Exactly where? This element: ds:operational The re-declaration of the default XML namespace is wrong and should be = removed (as in Fig. 1). BALAZS2: OK ------=_NextPart_000_01F4_01D59D3D.3B8ADDA0 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 DTE5MTExNzAzNTAzOVowIwYJKoZIhvcNAQkEMRYEFMSMqy6a3hRQUcMbdxMcHQsLZwYjMEMGCSqG SIb3DQEJDzE2MDQwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG BSsOAwIaMGsGCSsGAQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8x ITBtBgsqhkiG9w0BCRACCzFeoFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITAN BgkqhkiG9w0BAQEFAASCAQA8jieaSecchrheO1BzOUhUVJEk37soIKzuGmevVWckOTW853gLGrM1 t3BxjEUucDPeHRo3AgMWcT4a+f8yqikaiomfnnoh80nMbN0L3P7bmsAE7QNhOEaOxgZNoX1QhA0t AlfTI7wmNyvkDDNjccEvvBIXL3mNToqUSv6/V4ktLzrIbAYSx3quupT5QS+ROAuoimFK96JaXTEo 39QxwJ3aMNY1g8VZQRN9h+zVbTli2fgSHmbxC1cKXMRZ4hUCsmA9TkAsvPJuwQt5I7AKZgGKMdx4 qiO4Y8U/jgRMmX7/o2wkd+RcLaDPvJD8scR8JWr7PW3Aa7pBsPmY9of484h8AAAAAAAA ------=_NextPart_000_01F4_01D59D3D.3B8ADDA0-- From nobody Sun Nov 17 01:03:00 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE84D1200B1; Sun, 17 Nov 2019 01:02:58 -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.110.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <157398137876.20814.9461441368775469834@ietfa.amsl.com> Date: Sun, 17 Nov 2019 01:02:58 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-notification-capabilities-06.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: Sun, 17 Nov 2019 09:02:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : YANG-Push Notification Capabilities Authors : Balazs Lengyel Alexander Clemm Benoit Claise Filename : draft-ietf-netconf-notification-capabilities-06.txt Pages : 19 Date : 2019-11-17 Abstract: This document proposes a YANG module that 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-06 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-notification-capabilities-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-notification-capabilities-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Nov 17 02:12:02 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB33E12007A; Sun, 17 Nov 2019 02:11:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJsU9T8_OjUF; Sun, 17 Nov 2019 02:11:55 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D36A12004D; Sun, 17 Nov 2019 02:11:55 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 3035FF406D5; Sun, 17 Nov 2019 02:11:44 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, netconf@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20191117101144.3035FF406D5@rfc-editor.org> Date: Sun, 17 Nov 2019 02:11:44 -0800 (PST) Archived-At: Subject: [netconf] =?utf-8?q?RFC_8650_on_Dynamic_Subscription_to_YANG_Eve?= =?utf-8?q?nts_and_Datastores_over_RESTCONF?= 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, 17 Nov 2019 10:11:57 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8650 Title: Dynamic Subscription to YANG Events and Datastores over RESTCONF Author: E. Voit, R. Rahman, E. Nilsen-Nygaard, A. Clemm, A. Bierman Status: Standards Track Stream: IETF Date: November 2019 Mailbox: evoit@cisco.com, rrahman@cisco.com, einarnn@cisco.com, ludwig@clemm.org, andy@yumaworks.com Pages: 23 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-netconf-restconf-notif-15.txt URL: https://www.rfc-editor.org/info/rfc8650 DOI: 10.17487/RFC8650 This document provides a RESTCONF binding to the dynamic subscription capability of both subscribed notifications and YANG-Push. This document is a product of the Network Configuration Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Sun Nov 17 08:52:50 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A940120892; Sun, 17 Nov 2019 08:52:45 -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.110.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <157400956545.20904.16699880852772454994@ietfa.amsl.com> Date: Sun, 17 Nov 2019 08:52:45 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-notification-capabilities-07.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: Sun, 17 Nov 2019 16:52:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : YANG-Push Notification Capabilities Authors : Balazs Lengyel Alexander Clemm Benoit Claise Filename : draft-ietf-netconf-notification-capabilities-07.txt Pages : 19 Date : 2019-11-17 Abstract: This document proposes a YANG module that 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-07 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-notification-capabilities-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-notification-capabilities-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Nov 17 15:29:37 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 631C0120144; Sun, 17 Nov 2019 15:29:31 -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.110.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <157403337136.20814.6438089318124399582@ietfa.amsl.com> Date: Sun, 17 Nov 2019 15:29:31 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-notification-messages-08.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: Sun, 17 Nov 2019 23:29:31 -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 : Notification Message Headers and Bundles Authors : Eric Voit Tim Jenkins Henk Birkholz Andy Bierman Alexander Clemm Filename : draft-ietf-netconf-notification-messages-08.txt Pages : 23 Date : 2019-11-17 Abstract: This document defines a new notification message format. Included are: o a new notification mechanism and encoding to replace the one way operation of RFC-5277 o a set of common, transport agnostic message header objects. o how to bundle multiple event records into a single notification message. o how to ensure these new capabilities are only used with capable receivers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-messages/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-notification-messages-08 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-notification-messages-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-notification-messages-08 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 Nov 18 01:06:25 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD08F1200C7 for ; Mon, 18 Nov 2019 01:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=Clw0Mi8H; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=henRmDE8 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wykBioMakKaB for ; Mon, 18 Nov 2019 01:06:22 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 145A4120104 for ; Mon, 18 Nov 2019 01:06:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3320; q=dns/txt; s=iport; t=1574067982; x=1575277582; h=from:to:subject:date:message-id:mime-version; bh=cdSEJyNFzZR1y/i4PPu8vg5fYk+pUWXbk4zXX6iOQWE=; b=Clw0Mi8HdAOqVBKss3D+bKkPS/JoKmfOrPi9a0z2sDS+Dcin8nwtzam/ H3odMCZs6LEOTTCUC6+oeqGAYNofU5k2NYhkAg5Q0z85OBS63W4VMWGQD 2nkIH9UAF1sGGn8uKWkKMtjeHpbhtkKS8AQxiTbBs/GE4vFCy8UMlaReu 8=; IronPort-PHdr: =?us-ascii?q?9a23=3Akb3wpR9DM78jC/9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+8ZB7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVdSaCEnnK/jCZC0hF8MEX1hgrDm2?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A6AQDrXdJd/51dJa1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgWsGAQELAYEbL1AFbFggBAsqh3ADinBOlS6EYoEugSQDVAkBAQE?= =?us-ascii?q?MAQEtAgEBhEACgiMkNQgOAgMBAwIDAgEBBAEBAQIBBQRthTcMhWobEwEBOBE?= =?us-ascii?q?BDHQmAQQBGhqDAYF5TQMuAQKjSQKBOIhggieCfgEBBYR+GIIXCYE2AYwUGIF?= =?us-ascii?q?AP4FXgwqER4NAgiyVWphTCoIqlWqaEY5ImggCBAIEBQIOAQEFgVMBN4FYcBW?= =?us-ascii?q?DJ1ARFJEag3OKU3SBKI04AQE?= X-IronPort-AV: E=Sophos;i="5.68,319,1569283200"; d="scan'208,217";a="382627074" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Nov 2019 09:06:21 +0000 Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id xAI96LKW019248 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 18 Nov 2019 09:06:21 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 18 Nov 2019 03:06:20 -0600 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 18 Nov 2019 04:06:18 -0500 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 18 Nov 2019 03:06:18 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TdX+zmCwUKPtwthcEhGopMGXDP8O0JhfxySMl4ngveOkpAyg4Q4XkNVQ/5LD9k5VbGCQvCLurtohP4mI/nxsHXjJr3r1c1UF6ZrEGTU+zTg9g7to6pj1npDjo3kqSDiENfqrbF5Y9jIs5dXd2A5LEKnCyHKdJ9krwv9hBzkTdB1Ay9m/tJHF5AXdKaP8SIAqQnre2UbobsEUmBA6d8qSscql1AUq1eC56IWz/iVdOdK3m6vzymiK4ZMpmnuYiGBaJEwIwQXxeChfUt3CRGevJid/75CF4em1U4XqLFAvdA8Jf5mee58W7AP3bvuGA/A6j0VasbIW/EOVv6EWE2wdww== 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=XVN1zN+Dink90z6T4vvDf2Fc5KPuH8sN88YU8P6fiI4=; b=TJMT0+9gsPNajbnb33mrHvkYvihDFjmdOGs68Ssj5d3vC77Ej6XRZOMNxbsWX5HBHpiOXiuhaJ137dTnvcIXB9VBFQE6/aoHp9qT0ykNJBWMcdrsxbCdhg58U3EENCnag3+VzsiyL6ms8C0KzqIKfJYujmPGQKZQ7DW6SSp+aMfHb7I+uHG/1BFASOR8xD7INFK69KaLxpHjnkWvKUUZgibZjCmUOIQbv8T17xOfCbDLdhJ041rmJoGHhEttiWtb43rYtax+0a93KFHrityBlVOdV/tnQ5CBoEgvf1UGVTQA1rlKvnPWOdRYOBC9JIqpTSXWgcmGl69ybHpUVMZuMA== 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=XVN1zN+Dink90z6T4vvDf2Fc5KPuH8sN88YU8P6fiI4=; b=henRmDE8Yz/oPZoTeDOhWTJglBibNqWB7VlgcNvY1JONfUl2cFBhfvAeqQN3cyg3pdAruCPveZyS2715T2jByrDALSqfjkoZbmM3bBl/wjIPwwpu+t0q4N4OJ3KvBEZnWgQKDpWnGbKCS7Tap2Whwo7oA0dt7KdOGo6zxaGoaPs= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB3935.namprd11.prod.outlook.com (10.255.180.93) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.29; Mon, 18 Nov 2019 09:06:17 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::49b6:bc5c:bd3e:203c]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::49b6:bc5c:bd3e:203c%5]) with mapi id 15.20.2451.029; Mon, 18 Nov 2019 09:06:17 +0000 From: "Rob Wilton (rwilton)" To: Kent Watsen , "netconf@ietf.org" Thread-Topic: draft-ietf-netconf-trust-anchors, deleting or:system certificates Thread-Index: AdWd72XC8lE/kvqOTuiErBpzDiHmPA== Date: Mon, 18 Nov 2019 09:06:17 +0000 Message-ID: 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: [2001:420:c0dc:1002::c3] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6d5bf436-8c5a-438d-29aa-08d76c069251 x-ms-traffictypediagnostic: MN2PR11MB3935: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0225B0D5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(396003)(366004)(376002)(39860400002)(136003)(199004)(189003)(66476007)(66556008)(64756008)(6306002)(9686003)(6436002)(25786009)(9326002)(8936002)(66946007)(478600001)(6506007)(14444005)(256004)(66446008)(71190400001)(71200400001)(102836004)(476003)(486006)(76116006)(74316002)(7736002)(14454004)(7696005)(790700001)(6116002)(46003)(2906002)(33656002)(186003)(4744005)(54896002)(55016002)(5660300002)(99286004)(81156014)(81166006)(52536014)(316002)(8676002)(86362001)(2501003)(110136005); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3935; 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: vNratbO2ALcCu6oeniVY5FvoVmZTC/cz2a9z3CLm726t6uTTeH8+Wifiv95YSns+uLujhR23XeKvKacbYDI1PKN3zSvGyMAth45Jbz/dYE/fapPg8e7cYoTHqubfqbUH+5Pj+zCcyj6wFkIWqFJJc23Mv9ukEnHPzx6Gjbz76MxfXGKaRmtAi5g9mT8pAnLdIH/I3omjT2y77DYNjjE8DzoJIe/UMwbFtH8X9yFa8QjPJhYWPW01eSPxrQDEHFldDN1PDVvBkY08pyHNKgPzdtgjqfsbssTrQbIrk+Xgx/cY7huaUz7VuWxYyaMFF7XcDZsDaQB4zPgA+SwzDgRnh4xi+HIMC++zTb6F5aOa/RCQIWHxvgYmUde0gYDiw7BFfqwcwPg0g+OEuP3O2XfumTOPZbgL72aYDVySYFyViZFzihOyFojQ7LnYTmWoeztz x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB43660F403072E460AF2FE12AB54D0MN2PR11MB4366namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6d5bf436-8c5a-438d-29aa-08d76c069251 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2019 09:06:17.5491 (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: TAAnd5JQeFnOZQ4RU1p/o99cW4BTA+BbaRaXC7pStPoj+3fycWEPCYRRou9UdJvP4pog4tnVoNdm4cbOmMt+Fw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3935 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.30, xch-rcd-020.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: [netconf] draft-ietf-netconf-trust-anchors, deleting or:system certificates 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, 18 Nov 2019 09:06:24 -0000 --_000_MN2PR11MB43660F403072E460AF2FE12AB54D0MN2PR11MB4366namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kent, The question that I would have asked: In the examples in the draft-ietf-netconf-trust-anchors draft, there are ex= amples of certificates that are "origin: system". Should it be possible fo= r clients to explicitly delete some of these certificates, and if so what m= echanism/configuration would they use to achieve this? Thanks, Rob --_000_MN2PR11MB43660F403072E460AF2FE12AB54D0MN2PR11MB4366namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kent,

 

The question that I would have asked:

 

In the examples in the draft-ietf-netconf-trust-anch= ors draft, there are examples of certificates that are “origin: syste= m”.  Should it be possible for clients to explicitly delete some= of these certificates, and if so what mechanism/configuration would they use to achieve this?

 

Thanks,

Rob

 

 

 

--_000_MN2PR11MB43660F403072E460AF2FE12AB54D0MN2PR11MB4366namp_-- From nobody Mon Nov 18 01:34:53 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE9F1208A9 for ; Mon, 18 Nov 2019 01:34:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuGyAXVYjYLl for ; Mon, 18 Nov 2019 01:34:50 -0800 (PST) Received: from bgl-iport-3.cisco.com (bgl-iport-3.cisco.com [72.163.197.27]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E50FD1201DB for ; Mon, 18 Nov 2019 01:34:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2287; q=dns/txt; s=iport; t=1574069690; x=1575279290; h=to:cc:from:subject:message-id:date:mime-version; bh=QT3zytfXjHeTrq1qGfd6K8yBMA5noEknr0UYtT7fGLc=; b=TET0NsV1mYN1h/UQ0aUwyGind9ILUKL197xkRM+jB078xqa4+FYwYDAW R6WpBIUvu11SsaobKl2XU3Oqg+A7linixMBpgvJpeqzAgIofgiNxri9sL IPM8gMZ/K4ALa3ksZjnWfSIE2ILxysv2xXbQTO/eQZSGzAZrODqHelWtH w=; X-IronPort-AV: E=Sophos; i="5.68,319,1569283200"; d="scan'208,217"; a="98465561" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Nov 2019 09:34:47 +0000 Received: from [10.68.221.200] ([10.68.221.200]) (authenticated bits=0) by bgl-core-4.cisco.com (8.15.2/8.15.2) with ESMTPSA id xAI9YhkX019628 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NO); Mon, 18 Nov 2019 09:34:47 GMT To: Balazs Lengyel Cc: "Robert Wilton -X (rwilton - Ensoft Ltd at Cisco)" , NETCONF From: Benoit Claise Message-ID: <71259b42-2e44-7584-36af-6eaa860c41cf@cisco.com> Date: Mon, 18 Nov 2019 17:34:43 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------0998BC4B6C528AFB0307CB91" Content-Language: en-US X-Authenticated-User: bclaise X-Outbound-SMTP-Client: 10.68.221.200, [10.68.221.200] X-Outbound-Node: bgl-core-4.cisco.com Archived-At: Subject: [netconf] NACM and draft-ietf-netconf-notification-capabilities-07 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, 18 Nov 2019 09:34:52 -0000 This is a multi-part message in MIME format. --------------0998BC4B6C528AFB0307CB91 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, Coming back to Rob Wilton's message at the mike about NACM reference to draft-ietf-netmod-rfc6991-bis-02 From draft-ietf-netconf-notification-capabilities-07 import ietf-netconf-acm { prefix nacm; } import ietf-yang-push { prefix yp; description "This module requires ietf-yang-push to be implemented."; } Along the same lines, I believe it makes sense to add "This module does not require NACM to be implemented." Thinking some more about it... Actually, I don't like "This module requires ietf-yang-push to be implemented." What if I want to implement this draft for gRPC and not YANG-push? This capability should be independent of the streaming protocol IMO Regards, Benoit --------------0998BC4B6C528AFB0307CB91 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Dear all,

Coming back to Rob Wilton's message at the mike about NACM reference to draft-ietf-netmod-rfc6991-bis-02
From draft-ietf-netconf-notification-capabilities-07
   import ietf-netconf-acm  { prefix nacm; }
   import ietf-yang-push    {
     prefix yp;
     description
       "This module requires ietf-yang-push to be implemented.";
   }
Along the same lines, I believe it makes sense to add "This module does not require NACM to be implemented."

Thinking some more about it... Actually, I don't like "This module requires ietf-yang-push to be implemented."
What if I want to implement this draft for gRPC and not YANG-push?
This capability should be independent of the streaming protocol IMO

Regards, Benoit
--------------0998BC4B6C528AFB0307CB91-- From nobody Mon Nov 18 02:28:12 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1AD5120851 for ; Mon, 18 Nov 2019 02:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.998 X-Spam-Level: X-Spam-Status: No, score=-6.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_HI=-5, 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 a-2hWiUEO1HE for ; Mon, 18 Nov 2019 02:28:07 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A844D1208FC for ; Mon, 18 Nov 2019 02:28:07 -0800 (PST) Received: from birdie (dhcp-9c3a.meeting.ietf.org [31.133.156.58]) by mail.nic.cz (Postfix) with ESMTPSA id 9B91A140E20 for ; Mon, 18 Nov 2019 11:28:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1574072885; bh=miKwi4cO0p8r2BkamWp6O9ZdNL3O8PaoUXYVAfKXhY8=; h=From:To:Date; b=efZUzBR5NyDF1U1GvrWauEwDT8ED3n7fyo5gurFHoH/P5wr/fHB63Df1qB9t0tPRu upa+hr8d7FBrhuIqcs0QTeFB6gtNrmEAUTaeUMfeGIVscw4NM0enN4FdSKmA40GBRF FLRy2iQCl97JJi7Ty/Avnl9r0Ef/Pviz9Z2Fg9Q4= Message-ID: <32b6be76986ed69bf3d2aec84866ef6dfa9b277c.camel@nic.cz> From: Ladislav Lhotka To: netconf@ietf.org Date: Mon, 18 Nov 2019 18:27:59 +0800 In-Reply-To: <71259b42-2e44-7584-36af-6eaa860c41cf@cisco.com> References: <71259b42-2e44-7584-36af-6eaa860c41cf@cisco.com> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.100.3 at mail.nic.cz X-Virus-Status: Clean Archived-At: Subject: Re: [netconf] NACM and draft-ietf-netconf-notification-capabilities-07 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, 18 Nov 2019 10:28:10 -0000 On Mon, 2019-11-18 at 17:34 +0800, Benoit Claise wrote: > Dear all, > > Coming back to Rob Wilton's message at the mike about NACM reference to draft- > ietf-netmod-rfc6991-bis-02 > From draft-ietf-netconf-notification-capabilities-07 > import ietf-netconf-acm { prefix nacm; } > import ietf-yang-push { > prefix yp; > description > "This module requires ietf-yang-push to be implemented."; > } > > Along the same lines, I believe it makes sense to add "This module does not > require NACM to be implemented." Yes, see also my Yang Doctor review: https://datatracker.ietf.org/doc/review-ietf-netconf-notification-capabilities-05-yangdoctors-lc-lhotka-2019-10-29/ > > Thinking some more about it... Actually, I don't like "This module requires > ietf-yang-push to be implemented." > What if I want to implement this draft for gRPC and not YANG-push? > This capability should be independent of the streaming protocol IMO This draft (of which you are a co-author:-) states explicitly that the capabilities are 'related to "Subscription to YANG Datastores" (YANG-Push)'. Lada > > Regards, Benoit > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Nov 18 09:44:17 2019 Return-Path: <0100016e7f9d6131-c242e4a9-f6a5-4488-92b9-998108b349a6-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 25D92120074 for ; Mon, 18 Nov 2019 09:44:14 -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 AMbmsPxftLC2 for ; Mon, 18 Nov 2019 09:44:12 -0800 (PST) Received: from a8-64.smtp-out.amazonses.com (a8-64.smtp-out.amazonses.com [54.240.8.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A28E3120019 for ; Mon, 18 Nov 2019 09:44:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1574099051; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=LXNjhmucY/VUVZbzHuWy2PQ3Mw7F2XDXNadlpvTVshg=; b=UkqC43KTvmM5sxAyfRWqAOMEBpLiMhTDHZ+2+55gCT/T6Y7EWlj6ius2uceQezyp DS5LuVh2zmJ9pZfTh60CQZuTQLr5cmxqMtPhRNvI7BxSM4C1TA1vfYqNENxKmIfUXfy brf971b6nB8A6J8U4QVRufbUQxYe2WJnp9pHz248= From: Kent Watsen Message-ID: <0100016e7f9d6131-c242e4a9-f6a5-4488-92b9-998108b349a6-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7898C32F-3E24-4659-B885-45A324A398FB" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 18 Nov 2019 17:44:11 +0000 In-Reply-To: Cc: "netconf@ietf.org" To: "Rob Wilton (rwilton)" References: X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.11.18-54.240.8.64 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] draft-ietf-netconf-trust-anchors, deleting or:system certificates 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, 18 Nov 2019 17:44:14 -0000 --Apple-Mail=_7898C32F-3E24-4659-B885-45A324A398FB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Rob, > In the examples in the draft-ietf-netconf-trust-anchors draft, there = are examples of certificates that are =E2=80=9Corigin: system=E2=80=9D. As a quick recap, since it hasn't been discussed in awhile, the = intention is to support built-in keys and trust anchors, which would = have origin "system". Inconsistently, the Truststore example shows "operational state" while = the Keystore example shows "configuration" (though the paragraph = preceding it mistaking says otherwise). Perhaps two examples (one for = each view) should be in both drafts. It may be better to just have the = configuration view in the main body while adding a new section to each = draft discussing support for built-in values... > Should it be possible for clients to explicitly delete some of these = certificates Maybe, but not likely for the driving use-cases: 1) a TPM-protected key and its associated IDevID certificates - values persisted in hardware (the TPM) - values presented in Keystore 2) any trusted-by-default certificates - values persisted in firmware/OS (can vary release-to-release) - values presented in Truststore It may be that an implementation allows these values to be "removed" = from , but it seems more plausible that operators would = just NOT copy them into . > , and if so what mechanism/configuration would they use to achieve = this? If possible at all, how such "deletions" are realized is outside the = scope of these documents. The new sections mentioned above, discussing = the support for built-in values, could say this, but it might be better = to not say anything. Kent // contributor --Apple-Mail=_7898C32F-3E24-4659-B885-45A324A398FB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Rob,

In the examples in the = draft-ietf-netconf-trust-anchors draft, there are examples of = certificates that are =E2=80=9Corigin: = system=E2=80=9D.

As a quick recap, since it hasn't been discussed = in awhile, the intention is to support built-in keys and trust anchors, = which would have origin "system".

Inconsistently, the Truststore example shows = "operational state" while the Keystore example shows "configuration" = (though the paragraph preceding it mistaking says otherwise). =  Perhaps two examples (one for each view) should be in both drafts. =  It may be better to just have the configuration view in the main = body while adding a new section to each draft discussing support for = built-in values...


Should it = be possible for clients to explicitly delete some of these = certificates

Maybe, but not likely for the driving = use-cases:

 1) a TPM-protected = key and its associated IDevID certificates
    =    - values persisted in hardware (the TPM)
  =      - values presented in Keystore

 2) any trusted-by-default = certificates
       - values persisted in = firmware/OS (can vary release-to-release)
      =  - values presented in Truststore

It may be that an implementation allows these = values to be "removed" from <operational>, but it seems more = plausible that operators would just NOT copy them into = <intended>.


, and if = so what mechanism/configuration would they use to achieve = this?

If = possible at all, how such "deletions" are realized is outside the scope = of these documents.   The new sections mentioned above, discussing = the support for built-in values, could say this, but it might be better = to not say anything.


Kent // contributor

= --Apple-Mail=_7898C32F-3E24-4659-B885-45A324A398FB-- From nobody Mon Nov 18 14:18:59 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65277120B47 for ; Mon, 18 Nov 2019 14:18:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gz_rtdYd1dk1 for ; Mon, 18 Nov 2019 14:18:52 -0800 (PST) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CC03120090 for ; Mon, 18 Nov 2019 14:18:52 -0800 (PST) Received: by mail-lj1-x22a.google.com with SMTP id m4so15905369ljj.8 for ; Mon, 18 Nov 2019 14:18:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YVk8tiaxFBKdcyA27dRAP80lMIEEONaWY0kbQ9m3wv0=; b=YJl3Gmre+UaHZYEsrX97Ii40ppvVcSaTFrJQJBXpHFHWvZR9gVajT4jSu912gGi1EE CAHRTFphFR1O/NYSgJeBNSbXRGnkXDQxzhyX30+ByNA9ncM3vPAyqbNm35Ar8ac9egKk dnoseLvWmlklCEfaM/TwwHp7pW9wLqL8OLVXhhwwR/UtN1XfzRSXQhEkNo1/mJ4WkKO4 BzGxNRUHlUtm2SuguejBgM5opZoSEiA0U6S2veFqv2eYGTWVHBBC3/1K+V8AnmDBMG66 x0w8g08pecZS2vTTbKt0/iV2lJm6rfFXya5yK87hlW5nipSzBHcnrkLorRFBhB8Fi635 kKvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YVk8tiaxFBKdcyA27dRAP80lMIEEONaWY0kbQ9m3wv0=; b=ckHBbePL+XjXVI9z1y2OO9cXj6hxihC6O9HXv6Mpznry/c51uxZ4UqdAs9SI2YDTeH 8GVzxBkM5TBxekXfg8iykLimEsL35kIKgG8aidK696RngThUKrf2Pmz8i07Ha+9flKlc CgySAL1eIqXlPBVHqug/gaFaGoVkSF7D2UMlmnhuDACv7N/1wUnPPav9dBYEsRkZ3F8v VVvGgsnMoyGmtMbEZbbo3R/eMJfIjuKLO4AA6F0bfwejcOwW6U9medmD9+nMKu2s7ID2 JkvYEhnNo6NFp2S4hwzlEKpMFQOmmyX3eMTveDwklp1nXvhgwj/U+xNZrganzQY0mxwy FjMQ== X-Gm-Message-State: APjAAAVqtrPG82GeHWFsXXAVWOBLK2tp2ENF6C50fWkN2aiTlIhkXHwb yIbHlwLzMfJZK6VHRpzh19EXqoU6Yz00++FXFhSETg== X-Google-Smtp-Source: APXvYqxgXEtLId5ReD8/gTgZjsLB3gxHqdsx2P4+Soi8F6a5iukbUFRGdEZJ1g7kti2CWmytwCIOoKVKYfaodGpn/LE= X-Received: by 2002:a05:651c:d3:: with SMTP id 19mr1259774ljr.202.1574115530107; Mon, 18 Nov 2019 14:18:50 -0800 (PST) MIME-Version: 1.0 References: <71259b42-2e44-7584-36af-6eaa860c41cf@cisco.com> <32b6be76986ed69bf3d2aec84866ef6dfa9b277c.camel@nic.cz> In-Reply-To: <32b6be76986ed69bf3d2aec84866ef6dfa9b277c.camel@nic.cz> From: Andy Bierman Date: Mon, 18 Nov 2019 14:18:39 -0800 Message-ID: To: Ladislav Lhotka Cc: Netconf Content-Type: multipart/alternative; boundary="000000000000020afd0597a65563" Archived-At: Subject: Re: [netconf] NACM and draft-ietf-netconf-notification-capabilities-07 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, 18 Nov 2019 22:18:58 -0000 --000000000000020afd0597a65563 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 18, 2019 at 2:28 AM Ladislav Lhotka wrote: > On Mon, 2019-11-18 at 17:34 +0800, Benoit Claise wrote: > > Dear all, > > > > Coming back to Rob Wilton's message at the mike about NACM reference to > draft- > > ietf-netmod-rfc6991-bis-02 > > From draft-ietf-netconf-notification-capabilities-07 > > import ietf-netconf-acm { prefix nacm; } > > import ietf-yang-push { > > prefix yp; > > description > > "This module requires ietf-yang-push to be implemented."; > > } > > > > Along the same lines, I believe it makes sense to add "This module does > not > > require NACM to be implemented." > > This is a rather ad-hoc way to declare module conformance and dependencies. Not sure it is even correct. In this draft it looks like all the objects that are related to yang-push use "if-feature yp:on-change". So does this module really require yang-push if feature on-change is not supported? For nacm, only a typedef is used and no objects are used at all. It seems clear that if the importing module augments the imported module, or if leafref nodes exist that point to the imported module, then it is supposed to be implemented. Andy Yes, see also my Yang Doctor review: > > > https://datatracker.ietf.org/doc/review-ietf-netconf-notification-capabilities-05-yangdoctors-lc-lhotka-2019-10-29/ > > > > > Thinking some more about it... Actually, I don't like "This module > requires > > ietf-yang-push to be implemented." > > What if I want to implement this draft for gRPC and not YANG-push? > > This capability should be independent of the streaming protocol IMO > > This draft (of which you are a co-author:-) states explicitly that the > capabilities are 'related to "Subscription to YANG Datastores" > (YANG-Push)'. > > Lada > > > > > Regards, Benoit > > _______________________________________________ > > netconf mailing list > > netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --000000000000020afd0597a65563 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Nov 18, 2019 at 2:28 AM Ladis= lav Lhotka <lhotka@nic.cz> wrote= :
On Mon, 2019-1= 1-18 at 17:34 +0800, Benoit Claise wrote:
> Dear all,
>
> Coming back to Rob Wilton's message at the mike about NACM referen= ce to draft-
> ietf-netmod-rfc6991-bis-02
> From draft-ietf-netconf-notification-capabilities-07
>=C2=A0 =C2=A0 import ietf-netconf-acm=C2=A0 { prefix nacm; }
>=C2=A0 =C2=A0 import ietf-yang-push=C2=A0 =C2=A0 {
>=C2=A0 =C2=A0 =C2=A0 prefix yp;
>=C2=A0 =C2=A0 =C2=A0 description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 "This module requires ietf-yang-push t= o be implemented.";
>=C2=A0 =C2=A0 }
>
> Along the same lines, I believe it makes sense to add "This modul= e does not
> require NACM to be implemented."



This is a rather ad-hoc= way to declare module conformance and dependencies.
Not sure it = is even correct.

In this draft it looks like all t= he objects that are related to yang-push
use "if-feature yp:= on-change".=C2=A0 So does this module really require yang-push if=C2= =A0
feature on-change is not supported?

<= div>For nacm, only a typedef is used and no objects are used at all.
<= div>
It seems clear that if the importing module augments the= imported module,
or if leafref nodes exist that point to the imp= orted module, then it is supposed to be implemented.


Andy


Yes, see also my Yang Doctor review:

https://datatracker.ietf.org/doc/review-ietf-netconf-notific= ation-capabilities-05-yangdoctors-lc-lhotka-2019-10-29/

>
> Thinking some more about it... Actually, I don't like "This m= odule requires
> ietf-yang-push to be implemented."
> What if I want to implement this draft for gRPC and not YANG-push?
> This capability should be independent of the streaming protocol IMO
This draft (of which you are a co-author:-) states explicitly that the
capabilities are 'related to "Subscription to YANG Datastores"= ; (YANG-Push)'.

Lada

>
> Regards, Benoit
> _______________________________________________
> netconf mailing list
> netconf@ietf.org=
> https://www.ietf.org/mailman/listinfo/netconf<= br> --
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

_______________________________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--000000000000020afd0597a65563-- From nobody Tue Nov 19 01:19:38 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E758C120C67 for ; Tue, 19 Nov 2019 01:19: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 j0oiVQFC9HNZ for ; Tue, 19 Nov 2019 01:19:22 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130048.outbound.protection.outlook.com [40.107.13.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FEBF120B90 for ; Tue, 19 Nov 2019 01:19:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mW1nEG1wEN2gkW5+QL3IhkuLa1K++tlni9dRfKxx6OVVTvfm1VL1bsxorKqhtnaqn1EWMgUtHUz/29PF8vyWEX4+1WVc6Yswsa9egCo2zfZ6XR54oo9n2Nsfi2DKuhT11BlhEqLGVaUXiU5XY28WzdDwWVamg7OptlcNAeuo+GEXnj7bDHtsSg9N0AjXDYci02/aZUQox+6tMczXsVZ8AbS/7G/OqlE031deOI1Nm8dE5aPgOmrATkpG+TAsfZQTZK5yBsx25CwPJ7WUCeVncxk+tGtq9XrtpEpO6C1eWF0Xq3AfmGwzz+N1H1WUsgIUF2cYW3JQzbQlXIS7aajUsQ== 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=ruxJO2OqBZBt914E6qd3LCeRIev7NsgYWTG5kCIsmj8=; b=aCxsJbET5TanmUaNa0Q3XvlTK9E2ZRhyHqw4oeLhCxpFNRbGPVpZH0qKuTrNoEoUCKB5IjzvSHNbTiz7XX+PNXZc+9C5IHYtwVBjA8Ke3gc43WQC2xzclH4bI37g5SzjWMoCDFLxnC2sQEMkZtjZqjlrB31Vadg6a8zBe0vzpYtbMb3xwzwlNd/uZBQ1bZRPMMjNvdBesExWmeMPWpZj0GY83fH40UNU3teel+0VUix0Wh0z8+tCsAqDMYTp5wzuzGeJ8l47kBeIqjZ/jsf7cL5yK/ofD70+vUaA55LvYIMzNAyLb7St1w7ZwUZFCXZRkNuW/PTRGG96nVLXLOYrDw== 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=ruxJO2OqBZBt914E6qd3LCeRIev7NsgYWTG5kCIsmj8=; b=IKuxFDpPSuH8zmQaap0QYNYkS2Y317Xx/B5H+mZgsiOyuSb67NaFBDDg+Z5kCeb1WWPekolhBEEjy3NG+28ciaa4AvEWSSG36wNVhUzye/WAatanGJORyZRA2M5JXAj08s41akYFPBd1PBEVbNiT7zG4gIyAcR/Rju9vH7ZLjt4= Received: from AM0PR07MB5187.eurprd07.prod.outlook.com (20.178.20.74) by AM0PR07MB6435.eurprd07.prod.outlook.com (10.186.174.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.9; Tue, 19 Nov 2019 09:19:12 +0000 Received: from AM0PR07MB5187.eurprd07.prod.outlook.com ([fe80::e485:83e7:ee62:53f8]) by AM0PR07MB5187.eurprd07.prod.outlook.com ([fe80::e485:83e7:ee62:53f8%5]) with mapi id 15.20.2474.015; Tue, 19 Nov 2019 09:19:11 +0000 From: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= To: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= , Kent Watsen CC: "netconf@ietf.org" Thread-Topic: FIXMEs in ietf-crypto-types and client/server models Thread-Index: AdWT66zB5kr5iNWxQ6yg/MeI8i6GNgAaO58AABS9kxAA5WCRgAA+4dkwAV7zxXA= Date: Tue, 19 Nov 2019 09:19:11 +0000 Message-ID: References: <0100016e3ed10fbb-8a5a44a9-6df6-4ac1-9b56-8dbf61ec64cc-000000@email.amazonses.com> <0100016e586dbe79-24514978-922b-479b-a523-3d2bbcdc56c4-000000@email.amazonses.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.kovacs@ericsson.com; x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 478590e5-672d-4325-ff83-08d76cd18a3f x-ms-traffictypediagnostic: AM0PR07MB6435: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 022649CC2C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(366004)(39860400002)(136003)(396003)(189003)(199004)(85182001)(33656002)(8936002)(76116006)(81156014)(19627405001)(81166006)(446003)(11346002)(8676002)(476003)(52536014)(85202003)(486006)(99286004)(5660300002)(66574012)(4326008)(66946007)(66476007)(66556008)(64756008)(66446008)(316002)(110136005)(30864003)(14444005)(6246003)(256004)(71200400001)(71190400001)(236005)(55016002)(9326002)(9686003)(54896002)(229853002)(25786009)(6436002)(6506007)(53546011)(2906002)(102836004)(76176011)(7696005)(26005)(3846002)(6116002)(790700001)(66066001)(561944003)(606006)(7736002)(74316002)(478600001)(14454004)(6306002)(86362001)(186003)(170073001)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB6435; 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: h2ePcDfra5EFgwGllrz4B1kuURoKwKIrZYk1y0RXnfffJDrREX4QH3YXgGGZIGSZ655b0E0dZskesw5gmYcZzwoO4ulPt+JT/5en+tq62S0YWxvD8lusEMt5xCIfxaF6zlKLHlg7Y06lyXa9zm5TB1+XMGne5gTiZz8Jurv/4XhLhtNW3V/+l9UP7/jo+W4gE5uUmGooWfekLhrjibTNjWrGRucJmnlgb7qxBw5cNgbyGuocq/ox5YpXMq3w9vQdrCEwiCrXtQBJWB7fGQmAjFwf8nCmaRhrHAhaqEiEJTRmaNG6i4oaQrXFRWAwj6YLsK0Cvmf6L6zG9/AjHsmRIUUf7pxQlHGuqZ24SPo07KFbtsrApnq/u3zcGtzl78ge359S437rSOQM60DIEsp3LPDR3o8vzornGgNgMrMP24Sf5R82eAHwk9vRyGhk6DbH1lCrE80R0wT/vX3GAReGHQ1mTBVPg8iRUYHCttiSzOs= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR07MB518797EFBA3FBF42F9B1C1D6834C0AM0PR07MB5187eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 478590e5-672d-4325-ff83-08d76cd18a3f X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Nov 2019 09:19:11.8729 (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: cAy9tu3dgC4/Q5H5gQm9c661FjBv9rCKqFeSaMiak0c6y73nWj4SvrNfYwntPTlS5vPaJGzfeJJvxqEHv/unwapPuv5MN84/YgpDHaCz73Y= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB6435 Archived-At: Subject: Re: [netconf] FIXMEs in ietf-crypto-types and client/server models 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, 19 Nov 2019 09:19:31 -0000 --_000_AM0PR07MB518797EFBA3FBF42F9B1C1D6834C0AM0PR07MB5187eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2VudCwNCg0KSSBoYWQgYSBsb29rIGF0IHlvdXIgY2hhbmdlcyByZWxhdGVkIHRvIG91ciBk aXNjdXNzaW9uLiBJbiBnZW5lcmFsIGl0IGxvb2tzIGdvb2QhDQoNClNvbWUgcXVlc3Rpb25zIGJl bG93Og0KDQoNCmNvbnRhaW5lciBzZXJ2ZXItYXV0aGVudGljYXRpb24gew0KDQrigKYNCg0KDQpj YXNlIHBzayB7DQoNCi8vIG5vIGNvbmZpZ3VyYXRpb24gcmVxdWlyZWQgc2luY2UgaXQNCg0KLy8g aXMgdGhlIHNhbWUgYXMgaW4gY2xpZW50LWlkZW50aXR5IQ0KfQ0KDQpEbyB3ZSBuZWVkIHRoZSBp Zi1mZWF0dXJlIGluIGNhc2Ugb2YgdGhpcyBlbXB0eSBjYXNlPyBJcyB0aGUgZW1wdHkgY2FzZSBv ayBpbiBnZW5lcmFsPw0KDQogIGdyb3VwaW5nIGxvY2FsLW9yLXRydXN0c3RvcmUtcmF3LXB1Yi1r ZXlzLWdyb3VwaW5nIHsNCuKApg0KICAgIGNob2ljZSBsb2NhbC1vci10cnVzdHN0b3JlIHsNCiAg ICAgIG1hbmRhdG9yeSB0cnVlOw0KICAgICAgY2FzZSBsb2NhbCB7DQogICAgICAgIGlmLWZlYXR1 cmUgImxvY2FsLWRlZmluaXRpb25zLXN1cHBvcnRlZCI7DQogICAgICAgIGNvbnRhaW5lciBsb2Nh bC1kZWZpbml0aW9uIHsNCuKApg0KICAgICAgICAgIGxpc3QgcmF3LXB1YmxpYy1rZXkgew0K4oCm DQogICAgICAgICAgICB9DQogICAgICAgICAgICB1c2VzIGN0OnB1YmxpYy1rZXktZ3JvdXBpbmc7 DQogICAgICAgICAgfQ0KICAgICAgICAgIHVzZXMgY3Q6dHJ1c3QtYW5jaG9yLWNlcnRzLWdyb3Vw aW5nOyAgICAgLy8vIDwtLSBJcyB0aGlzIGEgbWlzdGFrZT8NCiAgICAgICAgfQ0KICAgICAgfQ0K ICAgICAgY2FzZSB0cnVzdHN0b3JlIHsNCuKApg0KICAgICAgfQ0K4oCmDQogICAgfQ0KICB9DQoN CldhcyB0aGUgbWFya2VkIGxpbmUgbGVmdCBvdmVyIGFzIGEgbWlzdGFrZSBhZnRlciBhIGNvcHkg ZnJvbSBsb2NhbC1vci10cnVzdHN0b3JlLWNlcnRzLWdyb3VwaW5nPw0KDQpCciwNCkJhbGF6cw0K DQpGcm9tOiBuZXRjb25mIDxuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBC YWzDoXpzIEtvdsOhY3MNClNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDEyLCAyMDE5IDEwOjExIEFN DQpUbzogS2VudCBXYXRzZW4gPGtlbnQraWV0ZkB3YXRzZW4ubmV0Pg0KQ2M6IG5ldGNvbmZAaWV0 Zi5vcmcNClN1YmplY3Q6IFJlOiBbbmV0Y29uZl0gRklYTUVzIGluIGlldGYtY3J5cHRvLXR5cGVz IGFuZCBjbGllbnQvc2VydmVyIG1vZGVscw0KDQpIaSBLZW50LA0KDQpSZWdhcmRpbmcgdGhpcyBv bmU6DQoNClllcywgdGhlIHByZXZpb3VzIHdheSAoZXhhbXBsZSBhYm92ZSkgd2FzIGFkZXF1YXRl LCBidXQgSSBiZWxpZXZlIHRoZSBuZXcgd2F5IChpLmUuIHVzaW5nIGEga2V5LWZvcm1hdCBsZWFm KSBpcyBiZXR0ZXIgYXM6DQoNCjEpIGl0IGVuYWJsZXMgdGhlIGEga2V5LXR5cGUgKGUuZy4sIGEg c3ltbWV0cmljIGtleSkgZG8gYmUgZXhwcmVzc2VkIGluIGRpZmZlcmVudCB3YXlzIGFzIG5lZWRl ZCAoT2N0ZXRTdHJpbmcgdnMuIE9uZVN5bW1ldHJpY0tleSB2cy4gRW5jcnlwdGVkRGF0YSkNCjIp IGl0IE1BWSAoaGF2ZW4ndCB0cmllZCB0byBtb2RlbCBpdCB5ZXQpIGJlIGFibGUgdG8gc3VwcG9y dCBlbmNvZGluZyB2YXJpYXRpb25zIChERVIgdnMgUEVNLCBhbmQgQ01TIHZzLiBtdWx0aS1wYXJ0 IFBFTSkNCjMpIGl0IGRlY291cGxlcyB0aGUgcGFydCB0aGF0IHdlIGFyZSBzdHVjayBvbiAoaS5l LiwgdGhlICdhbGdvcml0aG0nIG5vZGUpIGFuZCBpdCBiZWluZyBmYWN0b3JlZC1vdXQgbWF5IHBy b3ZpZGUgbW9yZSBmbGV4aWJpbGl0eSBpbiB0aGF0IGRlZmluaXRpb24uDQoNClRoZSBXRyBoYXNu J3QgZGlzY3Vzc2VkIGtleS1mb3JtYXQgeWV0LiAgQWJvdmUgaXMgdGhlIGZpcnN0IGZvcmF5IGlu dG8gaXQuLi5kbyB0aGVzZSBhcmd1bWVudHMgc291bmQgY29tcGVsbGluZz8NCg0KWWVzIGluZGVl ZC4gU28gdGhlIHByb3Bvc2FsIGlzIG9rIGZvciBtZS4gSXMgdGhlcmUgYW55dGhpbmcgdG8gZGlz Y3VzcyBvbiB0aGUgZGV0YWlscyBvZiB0aGlzIHRvIG1hdHRlciBvciB0aGUgaGF2ZSB0aGUgV0fi gJlzIGNvbW1pdG1lbnQ/DQoNCkJyDQpCYWxhenMNCg0KDQpGcm9tOiBLZW50IFdhdHNlbiA8a2Vu dCtpZXRmQHdhdHNlbi5uZXQ8bWFpbHRvOmtlbnQraWV0ZkB3YXRzZW4ubmV0Pj4NClNlbnQ6IE1v bmRheSwgTm92ZW1iZXIgMTEsIDIwMTkgNDowNyBBTQ0KVG86IEJhbMOhenMgS292w6FjcyA8YmFs YXpzLmtvdmFjc0Blcmljc3Nvbi5jb208bWFpbHRvOmJhbGF6cy5rb3ZhY3NAZXJpY3Nzb24uY29t Pj4NCkNjOiBuZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPg0KU3ViamVj dDogUmU6IEZJWE1FcyBpbiBpZXRmLWNyeXB0by10eXBlcyBhbmQgY2xpZW50L3NlcnZlciBtb2Rl bHMNCg0KSGkgQmFsYXpzLA0KDQoNCg0KMS4gICAgICAgS2V5LWZvcm1hdCAoc3ltbWV0cmljLWtl eSwgcHVibGljLWtleSwgYXN5bW1ldHJpYy1rZXktcGFpcikNCkkgYXNzdW1lIHRoZSBpZGVhIGhl cmUgaXMgdG8gbWFrZSBpdCBwb3NzaWJsZSB0byBoYXZlIGNob2ljZXMgZm9yIHRoZSBBU04uMSB0 eXBlcyBob2xkaW5nIHRoZSBrZXlzLiBJZiB0aGlzIGZsZXhpYmlsaXR5IGZvciBmb3JtYXRzIGlz IG5lY2Vzc2FyeSBJIGRvbuKAmXQgaGF2ZSBhbnkgb2JqZWN0aW9uIHRvIHRoZW0gYnV0IGhhdmlu ZyBhIHNpbmdsZSBhZ3JlZWQgdHlwZSBmb3IgdGhlc2UgZGlmZmVyZW50IHVzZSBjYXNlcyB3b3Vs ZCBhbHNvIHN1ZmZpY2UuDQoNCkkgYmVsaWV2ZSBoZXJlIHlvdSdyZSByZWZlcnJpbmcgdG8gdGhl IDMgaW5zdGFuY2VzIG9mIGxpbmVzIGxpa2U6DQoNCiAgICAgIGxlYWYga2V5IHsNCiAgICAgICAg bmFjbTpkZWZhdWx0LWRlbnktYWxsOw0KICAgICAgICB0eXBlIGJpbmFyeTsNCiAgICAgICAgLy9t dXN0ICIuLi9rZXktZm9ybWF0IjsgIEZJWE1FOiByZW1vdmUgY29tbWVudCBpZiBhcHByb2FjaCBv aw0KICAgICAgICAuLi4NCiAgICAgIH0NCg0KRldJVywgdGhlIHdob2xlICJrZXktZm9ybWF0IiBs ZWFmIGlzIHN0aWxsIGJlaW5nIHN1c3NlZCBvdXQgKHlvdXIgb3BpbmlvbiB3b3VsZCBiZSBoZWxw ZnVsIG9uIHRoYXQgdGhyZWFkIGFzIHdlbGwpIGJ1dCwgc28gZmFyIGl0IHNlZW1zIHByb21pc2lu Zy4gIFRoZSByZWFzb24gdGhlc2UgbGluZXMgYXJlIGNvbW1lbnRlZCBvdXQgaXMgYmVjYXVzZSAx KSB0aGUgV0cgaGFzbid0IGNvbW1pdHRlZCB0byB0aGlzIHBhdGggeWV0IGFuZCAyKSBJIGRpZG4n dCB3YW50IHRvIHVwZGF0ZSBhbGwgdGhlIGV4YW1wbGVzIGluIGFsbCB0aGUgZHJhZnRzIChvdGhl ciB0aGFuIHRydXN0c3RvcmUgYW5kIGtleXN0b3JlKSB0byBhZGQgYSAia2V5LWZvcm1hdCIgbGVh ZiB1bnRpbCB0aGUgV0cgaGFkIG1vcmUgY29uc2Vuc3VzIG9uIHRoZSAia2V5LWZvcm1hdCIgbGVh ZnMuDQoNCkkgZG9uJ3QgdW5kZXJzdGFuZCB5b3VyIGxhc3QgY29tbWVudC9zZW50ZW5jZS4gIENh biB5b3UgcHJvdmlkZSBhbiBleGFtcGxlPw0KDQpCYWxhenM+IE9rLCB0aGVuIGxldOKAmXMgd2Fp dCBmb3IgV0cgZGVjaXNpb24uIFdlbGwsIEkganVzdCBzYXkgdGhhdCB0aGUgZWFybGllciB3YXlz IG9mIGNvbW11bmljYXRpbmcgdGhlIGtleSBmb3JtYXRzIHdlcmUgYWRlcXVhdGUgZnJvbSBteSBw b2ludCBvZiB2aWV3LCB3aGljaCB3YXMgdGhhdCBpbiBkb2N1bWVudGF0aW9uIGl0IHdhcyBzYWlk IHRoYXQgZm9yIFJTQSB1c2UgUlNBUHJpdmF0ZUtleSBhbmQgZm9yIEVDIHVzZSBFQ1ByaXZhdGVL ZXksIGFuZCBzaW1pbGFybHkgZm9yIG90aGVyIHR5cGVzLiBJ4oCZbSBhbHNvIG9rIHdpdGggdGhl IGtleS1mb3JtYXQgYXBwcm9hY2ggaWYgcHJlZmVycmVkIGJ5IHRoZSBXRy4NCg0KSW4gZWFybGll ciB2ZXJzaW9uczoNCg0KICAgICAgICAgICBkZXNjcmlwdGlvbg0KICAgICAgICAgICAgICJUaGUg dmFsdWUgb2YgdGhlIGJpbmFyeSBrZXkuICBUaGUga2V5J3MgdmFsdWUgaXMNCiAgICAgICAgICAg ICAgaW50ZXJwcmV0ZWQgYnkgdGhlICdhbGdvcml0aG0nLiAgRm9yIGV4YW1wbGUsIGEgRFNBIGtl eQ0KICAgICAgICAgICAgICBpcyBhbiBpbnRlZ2VyLCBhbiBSU0Ega2V5IGlzIHJlcHJlc2VudGVk IGFzIFJTQVByaXZhdGVLZXkNCiAgICAgICAgICAgICAgYXMgZGVmaW5lZCBpbiBSRkMgODAxNzxo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODAxNz4sIGFuZCBhbiBFQ0Mga2V5IGlzIHJl cHJlc2VudGVkIGFzDQogICAgICAgICAgICAgIEVDUHJpdmF0ZUtleSBhcyBkZWZpbmVkIGluIFJG QyA1OTE1PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1OTE1Pi4iDQoNClllcywgdGhl IHByZXZpb3VzIHdheSAoZXhhbXBsZSBhYm92ZSkgd2FzIGFkZXF1YXRlLCBidXQgSSBiZWxpZXZl IHRoZSBuZXcgd2F5IChpLmUuIHVzaW5nIGEga2V5LWZvcm1hdCBsZWFmKSBpcyBiZXR0ZXIgYXM6 DQoNCjEpIGl0IGVuYWJsZXMgdGhlIGEga2V5LXR5cGUgKGUuZy4sIGEgc3ltbWV0cmljIGtleSkg ZG8gYmUgZXhwcmVzc2VkIGluIGRpZmZlcmVudCB3YXlzIGFzIG5lZWRlZCAoT2N0ZXRTdHJpbmcg dnMuIE9uZVN5bW1ldHJpY0tleSB2cy4gRW5jcnlwdGVkRGF0YSkNCjIpIGl0IE1BWSAoaGF2ZW4n dCB0cmllZCB0byBtb2RlbCBpdCB5ZXQpIGJlIGFibGUgdG8gc3VwcG9ydCBlbmNvZGluZyB2YXJp YXRpb25zIChERVIgdnMgUEVNLCBhbmQgQ01TIHZzLiBtdWx0aS1wYXJ0IFBFTSkNCjMpIGl0IGRl Y291cGxlcyB0aGUgcGFydCB0aGF0IHdlIGFyZSBzdHVjayBvbiAoaS5lLiwgdGhlICdhbGdvcml0 aG0nIG5vZGUpIGFuZCBpdCBiZWluZyBmYWN0b3JlZC1vdXQgbWF5IHByb3ZpZGUgbW9yZSBmbGV4 aWJpbGl0eSBpbiB0aGF0IGRlZmluaXRpb24uDQoNClRoZSBXRyBoYXNuJ3QgZGlzY3Vzc2VkIGtl eS1mb3JtYXQgeWV0LiAgQWJvdmUgaXMgdGhlIGZpcnN0IGZvcmF5IGludG8gaXQuLi5kbyB0aGVz ZSBhcmd1bWVudHMgc291bmQgY29tcGVsbGluZz8NCg0KDQoNCg0KMi4gICAgICAgYXR0cmlidXRl cyBpbiBhc3ltbWV0cmljLWtleS1wYWlyLXdpdGgtY2VydChzKS1ncm91cGluZw0KSSB0aGluayBh dHRyaWJ1dGVzIHNob3VsZCBiZSBrZXB0IG9wdGlvbmFsLiBJZiB0aGVyZSBpcyBhbnl0aGluZyBl bHNlIGJlc2lkZXMgc3ViamVjdCBzZWVuIG1hbmRhdG9yeSBtYXliZSBpdCBzaG91bGQgYmUgZXh0 cmFjdGVkIG91dCBmcm9tIGF0dHJpYnV0ZXMgYW5kIGJlIHNwZWxsZWQgb3V0IGEgc2VwYXJhdGUg bGVhZiwgYnV0IEkgZG9u4oCZdCB0aGluayB0aGVyZSBpcy4NCg0KSSBiZWxpZXZlIGhlcmUgeW91 J3JlIHJlZmVycmluZyB0byB0aGUgMiBpbnN0YW5jZXMgb2YgbGluZXMgbGlrZToNCg0KICAgICAg ICBsZWFmIGF0dHJpYnV0ZXMgew0KICAgICAgICAgIHR5cGUgYmluYXJ5OyAvLyBGSVhNRTogZG9l cyB0aGlzIG5lZWQgdG8gYmUgbWFuZGF0b3J5Pw0KICAgICAgICAgIC4uLg0KICAgICAgICB9DQoN ClRoZXNlIGFyZSBpbiB0aGUgImdlbmVyYXRlLWNlcnRpZmljYXRlLXNpZ25pbmctcmVxdWVzdCIg YWN0aW9ucyBmb3VuZCBpbnNpZGUgdGhlIGFzeW1tZXRyaWMta2V5LXBhaXItd2l0aC1jZXJ0KHMp LWdyb3VwaW5nLg0KDQpIbW1tLCBhcmUgeW91IGNsYWltaW5nIHRoYXQgImF0dHJpYnV0ZXMiIGFy ZSBub3QgcmVxdWlyZWQgaW4gb3JkZXIgdG8gZ2VuZXJhdGUgYSBDU1I/ICBJIHRoaW5rIHRoZSBD U1IgaXRzZWxmIE1VU1QgaGF2ZSBhdHRyaWJ1dGVzIChyaWdodD8pIHNvLCBpZiBub3Qgc3BlY2lm aWVkLCB3aGF0IGRlZmF1bHQgdmFsdWVzIGFyZSB1c2VkPw0KDQpCYWxhenM+IEluIFJGQzI5ODY8 aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzI5ODYjc2VjdGlvbi0zPiB0aGUgYXR0cmli dXRlcyBhcmUgc2FpZCB0byBiZSBvcHRpb25hbC4gV2UganVzdCBuZWVkIHRoZSBzdWJqZWN0IERO IGFzIG1hbmRhdG9yeSwgZG9u4oCZdCB3ZT8NCg0KDQoNCg0KICAgICAgICAxLiBBIENlcnRpZmlj YXRpb25SZXF1ZXN0SW5mbyB2YWx1ZSBjb250YWluaW5nIGEgc3ViamVjdA0KDQogICAgICAgICAg IGRpc3Rpbmd1aXNoZWQgbmFtZSwgYSBzdWJqZWN0IHB1YmxpYyBrZXksIGFuZCBvcHRpb25hbGx5 IGENCg0KICAgICAgICAgICBzZXQgb2YgYXR0cmlidXRlcyBpcyBjb25zdHJ1Y3RlZCBieSBhbiBl bnRpdHkgcmVxdWVzdGluZw0KDQogICAgICAgICAgIGNlcnRpZmljYXRpb24uDQoNClRoYW5rIHlv dS4gIEkndmUgcmVtb3ZlZCB0aGVzZSB0byBjb21tZW50cywgdGh1cyBsZWF2aW5nIHRoZSAiYXR0 cnVidHV0ZSIgbm9kZXMgYXMgTk9UIG1hbmRhdG9yeS4NCg0KDQoNCg0KDQozLiAgICAgICBQU0sg YW5kIHJhdyBwdWJsaWMga2V5cw0KVGhlIHVzZSBjYXNlIG9mIFBTSyBhbmQgcmF3IHB1YmxpYyBr ZXlzIGFyZSBub3QgdGhlIG1vc3QgdXJnZW50IGluIG15IG9waW5pb24gd2hpY2ggbm93IHNsb3dz IGEgYml0IHRoZSBwcm9ncmVzcyBvZiB0aGVzZSBkcmFmdHMsIGJ1dCBsZXTigJlzIG1ha2UgYW4g YXR0ZW1wdCB0byBmaW5hbGl6ZSB0aGVtLg0KDQpBZ3JlZWQsIGJ1dCB0aGV5IGFyZSBsZWdhbCBm b3IgVExTIGFuZCBhIFdHIG1lbWJlciBzdGF0ZWQgdGhhdCB0aGV5IHdlcmUgbmVlZGVkIGluIG9y ZGVyIHRvIHN1cHBvcnQgYW5vdGhlciBJRVRGIFdHJ3MgZWZmb3J0cy4gIEEgcXVpY2sgcmVzb2x1 dGlvbiB3b3VsZCBiZSBiZXN0IQ0KDQoNCnJhdy1wdWJsaWMta2V5czogSSBzZWUgdGhlc2Ugd2Vy ZSBhZGRlZCBkdWUgdG8gUkZDIDcyNTAgYW5kIDg0NDYuIEkgZ3Vlc3MgaW4gdHJ1c3RzdG9yZSB0 aGlzIGlzIGEgc2VwYXJhdGUgY29udGFpbmVyIHRvIGRpc3Rpbmd1aXNoIGZyb20gU1NIIGhvc3Qg a2V5cy4gRm9yIGNvbmZpZ3VyaW5nIHRoZSBwcml2YXRlIHBhcnQgSSB0aGluayBrZXlzdG9yZSBh bHJlYWR5IGdpdmVzIHN1cHBvcnQgZm9yIHRoaXMgY2FzZSB3aXRoIHRoZSBhc3ltbWV0cmljIGtl eSAody9vIGNlcnQpIGFuZCBpbiB0aGUgY2xpZW50L3NlcnZlciBkcmFmdHMgS2VudOKAmXMgcHJv cG9zYWwgY291bGQgYmUgdXNlZCAoSSByZXBsYWNlZCByYXcgcHVibGljIGtleSB3aXRoIGV4aXN0 aW5nIHR5cGUsIHNob3VsZG7igJl0IHRoYXQgYmUgdXNlYWJsZSBzdHJhaWdodCBhd2F5PykNCg0K ICAgICAgICAgICAgICAgICAgICBjb250YWluZXIgPGNsaWVudC1pZGVudGl0eSBvciBzZXJ2ZXIt aWRlbnRpdHk+IHsNCiAgICAgICAgICAgICAgICAgICAgICBjaG9pY2UgYXV0aC10eXBlIHsNCiAg ICAgICAgICAgICAgICAgICAgICAgICB1c2VzIGtzOmxvY2FsLW9yLWtleXN0b3JlLWVuZC1lbnRp dHktY2VydC13aXRoLWtleS1ncm91cGluZzsNCiAgICAgICAgICAgICAgICAgICAgICAgICB1c2Vz IGtzOmxvY2FsLW9yLWtleXN0b3JlLWFzeW1tZXRyaWMta2V5LWdyb3VwaW5nOw0KDQoNCkkgd291 bGQgYWxzbyBwcmVmZXIgaWYgdGhlc2UgY2hvaWNlcyBhcmUgaW4gZmVhdHVyZXMsIHNvIHRoYXQg YW4gaW1wbGVtZW50YXRpb24gY2FuIGNob29zZS4NCg0KVG8geW91ciBmaXJzdCBzZW50ZW5jZSwg eWVzLCAicHNrIiAoYW5kICJyYXctcHVibGljLWtleSIpIGFyZSB0b3AtbGV2ZWwgbm9kZXMgaW4g dHJ1c3RzdG9yZSwgYXMgY2FuIGJlIHNlZW4gaGVyZSAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtbmV0Y29uZi10cnVzdC1hbmNob3JzLTA3I3NlY3Rpb24tMi4xKS4gICBO b3RlLCB0aGUgdHJ1c3QtYW5jaG9ycyBkcmFmdCBhY2NpZGVudGFsbHkgZG9lc24ndCBpbmNsdWRl IHRoZSBpZXRmLXRydXN0c3RvcmUueWFuZyBtb2R1bGUuDQoNClRoZSBib2R5IG9mIHlvdXIgY29t bWVudCBhYm92ZSBzZWVtcyB0byBiZSBhYm91dCBzdXBwb3J0aW5nIHRoZSBzZWNyZXQtaGFsZiBv ZiB0aGUgUFNLIGFuZCBSUEsgd2l0aGluIHRoZSBLZXlzdG9yZS4gIEkndmUgcmFpc2UgdGhpcyBx dWVzdGlvbiBhIGNvdXBsZSB0aW1lcyBwcmV2aW91c2x5IHRvIEhlbmsgKHdobydzIGFza2luZyBm b3IgdGhlIFBTSy9SUEsgYWRkKSwgYnV0IGhlJ3Mgbm90IHJlc3BvbmRlZCB5ZXQgYXMgdG8gaWYg ZG9pbmcgc28gaXMgaW1wb3J0YW50ICh0aG91Z2ggSSBjYW4gb25seSBpbWFnaW5lIHRoYXQgaXQg ZG9lcykuICAgV2l0aCB0aGF0IHNhaWQsIEkgdGhpbmsgeW91ciBZQU5HIHNuaXBwZXQgaXMgbWVh bnQgdG8gYmUgaW4gaWV0Zi10bHMtc2VydmVyIGFuZCBpZXRmLXRscy1jbGllbnQgbW9kdWxlcyAo cmlnaHQ/KS4gIEknbSBoYXZpbmcgYSBoYXJkIHRpbWUgZm9sbG93aW5nIHRoZSAiSSByZXBsYWNl ZCByYXcgcHVibGljIGtleSB3aXRoIGV4aXN0aW5nIHR5cGUsIHNob3VsZG7igJl0IHRoYXQgYmUg dXNlYWJsZSBzdHJhaWdodCBhd2F5PyIgY29tbWVudC4NCg0KQmFsYXpzOiBZb3UgaGFkIGFuIGV4 YW1wbGUgZWFybGllciBpbiBhbiBlbWFpbCBmcm9tIDEwLzgvMjAxOSwgd2hpY2ggaXMgYWJvdXQg dGhlIFRMUyBjbGllbnQvc2VydmVyIG1vZGVscy4gQmVsb3csIHlvdSBhcmUgcmVmZXJyaW5nIHRv IHNvbWUgcG9zc2libHkgbmV3IGdyb3VwaW5ncyB0aGF0IHlvdSB3YW50ZWQgdG8gcHJvcG9zZS4g SSBkb27igJl0IHVuZGVyc3RhbmQgdGhvdWdoIHdoeSB5b3UgbWVudGlvbmVkIHRoZXNlIG5ldyBn cm91cGluZ3Mgc2luY2Ug4oCYa3M6bG9jYWwtb3Ita2V5c3RvcmUtYXN5bW1ldHJpYy1rZXktZ3Jv dXBpbmfigJkgKFJQSykgYW5kIHNvbWV0aGluZyBuZXcgdGhhdCBqdXN0IHJlZmVycyB0byBhIGtl eXN0b3JlIHN5bW1ldHJpYyBrZXksIHN1Y2ggYXMg4oCYa3M6bG9jYWwtb3Ita2V5c3RvcmUtc3lt bWV0cmljLWtleS1ncm91cGluZ+KAmSAoUFNLKSBzaG91bGQgYmUgZ29vZC4gVGhpcyBsYXR0ZXIg SSB0aGluayB3b3VsZCBiZSBhIG5ldyBncm91cGluZywgYnV0IHdpdGggZXhpc3RpbmcgdGVybWlu b2xvZ3kuDQoNCkFsbCwgbG9va2luZyBhdCBpZXRmLXRscy1jbGllbnQueWFuZyBhbmQgaWV0Zi10 bHMtc2VydmVyLnlhbmcsIGFkZGluZyB0aGUgYWJpbGl0eSB0byBjb25maWd1cmUgdGhlICJwcml2 YXRlIiBoYWxmIG9mIGEgUFNLIG9yIHJhdyBwdWJsaWMga2V5IHdvdWxkIGJlIHNvbWV0aGluZyBs aWtlOg0KDQogICAgICAgICAgICAgICAgT0xEDQogICAgICAgICAgICAgICAgICAgIGNvbnRhaW5l ciA8Y2xpZW50LWlkZW50aXR5IG9yIHNlcnZlci1pZGVudGl0eT4gew0KICAgICAgICAgICAgICAg ICAgICAgIHVzZXMga3M6bG9jYWwtb3Ita2V5c3RvcmUtZW5kLWVudGl0eS1jZXJ0LXdpdGgta2V5 LWdyb3VwaW5nOw0KICAgICAgICAgICAgICAgIE5FVw0KICAgICAgICAgICAgICAgICAgICBjb250 YWluZXIgPGNsaWVudC1pZGVudGl0eSBvciBzZXJ2ZXItaWRlbnRpdHk+IHsNCiAgICAgICAgICAg ICAgICAgICAgICBjaG9pY2UgYXV0aC10eXBlIHsNCiAgICAgICAgICAgICAgICAgICAgICAgICB1 c2VzIGtzOmxvY2FsLW9yLWtleXN0b3JlLWVuZC1lbnRpdHktY2VydC13aXRoLWtleS1ncm91cGlu ZzsNCiAgICAgICAgICAgICAgICAgICAgICAgICB1c2VzIGtzOmxvY2FsLW9yLWtleXN0b3JlLXJh dy1wdWJsaWMta2V5LWdyb3VwaW5nOw0KICAgICAgICAgICAgICAgICAgICAgICAgIHVzZXMga3M6 bG9jYWwtb3Ita2V5c3RvcmUtcHJlLXNoYXJlZC1rZXktZ3JvdXBpbmc7DQoNCg0KQWgsIG5vdyBJ IHVuZGVyc3RhbmQsIEkgYW5kIGFncmVlIHRoYXQgdGhpcyBzZWVtcyBsaWtlIHRoZSByaWdodCB3 YXkgdG8gZG8gaXQsIGJ1dCBzZWUgYmVsb3cuLi4NCg0KDQpUbyB5b3VyIGxhc3Qgc2VudGVuY2Ug cmVnYXJkaW5nIGZlYXR1cmVzLCBjb3VsZCB5b3UgcHJvdmlkZSBhbiBleGFtcGxlIG9mIHdoYXQg eW91IG1lYW4/DQoNCg0KY29udGFpbmVyIDxjbGllbnQtaWRlbnRpdHkgb3Igc2VydmVyLWlkZW50 aXR5PiB7DQogICAgY2hvaWNlIGF1dGgtdHlwZSB7DQogICAgICAgIG1hbmRhdG9yeSB0cnVlOw0K ICAgICAgICBjYXNlIGNlcnRpZmljYXRlIHsNCiAgICAgICAgICAgIGlmLWZlYXR1cmUgeDUwOS1j ZXJ0aWZpY2F0ZS1hdXRoOw0KICAgICAgICAgICB1c2VzIGtzOmxvY2FsLW9yLWtleXN0b3JlLWVu ZC1lbnRpdHktY2VydC13aXRoLWtleS1ncm91cGluZzsNCiAgICAgICB9DQogICAgICAgIGNhc2Ug cmF3LXB1YmxpYy1rZXkgew0KICAgICAgICAgICAgaWYtZmVhdHVyZSByYXctcHVibGljLWtleS1h dXRoOw0KICAgICAgICAgICB1c2VzIGtzOmxvY2FsLW9yLWtleXN0b3JlLWFzeW1tZXRyaWMta2V5 LWdyb3VwaW5nOw0KICAgICAgIH0NCiAgICAgICAgY2FzZSBwc2sgew0KICAgICAgICAgICAgaWYt ZmVhdHVyZSBwc2stYXV0aDsNCiAgICAgICAgICAgdXNlcyBrczpsb2NhbC1vci1rZXlzdG9yZS1z eW1tZXRyaWMta2V5LWdyb3VwaW5nOw0KICAgICAgIH0NCg0KQmV0dGVyISAgVGhpcyB1c2VzIHRo ZSBleGlzdGluZyBncm91cGluZ3MgKGUuZy4sIGtzOmxvY2FsLW9yLWtleXN0b3JlLWFzeW1tZXRy aWMta2V5LWdyb3VwaW5nKSB3aGVyZWFzIHRoZSBhYm92ZSBwcm9wb3NhbCBkZWZpbmVkIG5ldyBv bmVzLiAgKHNlZSBHaXRIdWIgZm9yIGxhdGVzdCBmaWxlcywgdGhvdWdoIHRoZSBjb21taXQgaXMg bGFyZ2VyIHRoYW4gaXQgc2hvdWxkIGJlKQ0KDQpIZW5rLCB3aGF0IGRvIHlvdSB0aGluaz8NCg0K DQpJIGFzc3VtZSB0aGVzZSBmZWF0dXJlcyB3b3VsZCB0aGVuIG5lZWQgdG8gYmUgZGVmaW5lZCBp biB0aGUgVExTIGNsaWVudC9zZXJ2ZXIgZHJhZnQuDQoNClllcy4NCg0KDQpQUzogbm9uZSBvZiB0 aGlzIGdvZXMgdG8gdGhlIEZJWE1FIGluIHRoZSBpZXRmLWNyeXB0by10eXBlcy4gIEkgaGFkIHBy ZXZpb3VzbHkgYXNrZWQgSGVuayB0byBwcm92aWRlIHNvbWUgdGV4dCBoZXJlIGFzIHdlbGwgYnV0 LCBhcHBhcmVudGx5LCBsaWtlIGFsbCBvZiB1cyBhdCB0aGlzIHRpbWUsIGhlJ3MgYmVlbiBidXN5 IQ0KDQogcHNrOiBnaXZlbiB0aGF0IHRoZSBhc3ltbWV0cmljIGtleXMgd2l0aG91dCBjZXJ0cyB3 ZXJlIGNvdmVyZWQgYnkgaG9zdCBrZXlzIGFuZCByYXcgcHVibGljIGtleXMsIEkgdGhpbmsgcHNr IHNob3VsZCBvbmx5IGJlIHN5bW1ldHJpYyBrZXlzLiBTeW1tZXRyaWMga2V5cyBhcmUgdGhlbiBz ZW5zaXRpdmUvc2VjcmV0IGRhdGEgYW5kIGFzIHN1Y2ggSSBiZWxpZXZlIHRoZXkgc2hvdWxkIG9u bHkgYmUgcmVmZXJlbmNlZCBmcm9tIGtleXN0b3JlLiBTZWVpbmcgdGhlbSBpbiB0cnVzdHN0b3Jl IHdhcyB1bmV4cGVjdGVkIGZvciBtZS4gV2hlbiBpdCBjb21lcyB0byB0aGVpciB1c2UsIGNsaWVu dHMgYW5kIHNlcnZlcnMgc2hvdWxkIGJlIGV4dGVuZGVkIHdpdGggZm9sbG93aW5nIGNvbmZpZ3Vy YXRpb24gKGFuZCBJIGFzc3VtZSB3ZSB0YWxrIG9mIFRMUyBjbGllbnRzIGFuZCBzZXJ2ZXJzIG9u bHkpOg0KDQogICAgICAgICAgICAgICAgICAgIGNvbnRhaW5lciA8Y2xpZW50LWlkZW50aXR5IG9y IHNlcnZlci1pZGVudGl0eT4gew0KICAgICAgICAgICAgICAgICAgICAgIGNob2ljZSBhdXRoLXR5 cGUgew0KICAgICAgICAgICAgICAgICAgICAgICAgIHVzZXMga3M6bG9jYWwtb3Ita2V5c3RvcmUt ZW5kLWVudGl0eS1jZXJ0LXdpdGgta2V5LWdyb3VwaW5nOw0KICAgICAgICAgICAgICAgICAgICAg ICAgIHVzZXMga3M6bG9jYWwtb3Ita2V5c3RvcmUtYXN5bW1ldHJpYy1rZXktZ3JvdXBpbmc7DQog ICAgICAgICAgICAgICAgICAgICAgIHVzZXMga3M6bG9jYWwtb3Ita2V5c3RvcmUtc3ltbWV0cmlj LWtleS1ncm91cGluZzsNCg0KTGF0dGVyIGdyb3VwaW5nIHdvdWxkIGJlIGEgbmV3IG9uZSwgYnV0 IGl0IHdvdWxkIHVzZSBleGlzdGluZyBjb25zdHJ1Y3RzIGFuZCB0ZXJtcyBmcm9tIGtleXN0b3Jl LiBJIGRvbuKAmXQgdGhpbmsgd2UgbmVlZCBuZXcgb25lcy4gU2VsZWN0ZWQgY2lwaGVyIHN1aXRl cyB3aWxsIG5lZWQgdG8gaGF2ZSBQU0sgaW4gdGhlbSBmb3IgdXNpbmcgc3ltbWV0cmljIGtleSAo c2ltaWxhciBtYXRjaCBuZWVkZWQgZm9yIHRoZSBvdGhlcnMpLiBOb3RlIHRoYXQgc3ltbWV0cmlj IGtleXMgY2FuIGJlIHVzZWQgZm9yIG90aGVyIGNhc2VzIHRoYW4gVExTIFBTSywgZm9yIGV4YW1w bGUgU05NUHYzIFVTTS4gQWdhaW4sIGZlYXR1cmVzIHdvdWxkIGJlIG5lY2Vzc2FyeSAodGhvc2Ug Y291bGQgYmUgc2F5aW5nIHguNTA5IG9yIHJhdy1wdWJsaWMta2V5IG9yIHBzaykuDQoNCg0KQ29y cmVjdCwgSSBzYWlkIHRoZSBzYW1lICh0aGF0IFBTS3MgYXJlIGVzc2VudGlhbGx5IHN5bW1ldHJp YyBrZXlzKSBiZWZvcmUgYXMgd2VsbC4gIFJlZ2FyZGluZyBvbmx5IGJlaW5nIHJlZmVyZW5jZWQg dG8ga2V5c3RvcmUsIHdoeSBub3QgYWxzbyBzdXBwb3J0IHRoZW0gYmVpbmcgbG9jYWwtZGVmaW5p dGlvbnMgdG9vPyAgQ2VydGFpbmx5IG5vdCBhIHByb2JsZW0gaWYgZW5jcnlwdGVkIGFuZCwgZXZl biB3aGVuIG5vdCBlbmNyeXB0ZWQsIHRoZW4gdGhleSBjYW4gYmUgInByb3RlY3RlZCIgYnkgTkFD TS1saWtlIG1lY2hhbmlzbXMsIHJpZ2h0Pw0KDQpCYWxhenM+IExvY2FsIGRlZmluaXRpb25zIGFy ZSBvayB0b28gdGhhdOKAmXMgd2h5IEkgdXNlZCBhIGh5cG90aGV0aWNhbCBncm91cGluZyBuYW1l ICBrczpsb2NhbC1vci1rZXlzdG9yZS1zeW1tZXRyaWMta2V5LWdyb3VwaW5nLg0KDQpTb3JyeSwg SSBnbG9zc2VkIG92ZXIgdGhlICJsb2NhbC0iIHByZWZpeCBpbiB5b3VyIGVhcmxpZXIgc3RhdGVt ZW50Lg0KDQpJIGFncmVlIHRoYXQgUFNLcyBzaG91bGQgYmUgaW4gS2V5c3RvcmUgd2hlbiB1c2Vk IGZvciBjbGllbnQtaWRlbnRpdHkvc2VydmVyLWlkZW50aXR5IG5vZGVzLi4uIChtb3JlIGJlbG93 KQ0KDQoNCiAgV2h5IHdhcy9pcyBzZWVpbmcgdGhlbSBpbiB0cnVzdHN0b3JlIGEgc3VycHJpc2Us IHBlcmhhcHMgYmVjYXVzZSB0aGV5J3JlIG5vdCBlbmNyeXB0YWJsZSB0aGVyZT8NCg0KQmFsYXpz PiBXaGVuIFBTS3MgYXJlIHVzZWQgdGhlbiBib3RoIGNvbW11bmljYXRpbmcgZW5kcyB1c2UgdGhl IHNoYXJlZCBrZXkgZm9yIHNpZ25pbmcgYW5kIHZlcmlmeWluZyBtZXNzYWdlcy4gVGhlbiBvbmUg Y29uZmlndXJhdGlvbiBzZWVtcyBlbm91Z2ggdGhhdCBpcyBlaXRoZXIgbG9jYWwgb3IgZnJvbSBr ZXlzdG9yZSwgd2h5IHdvdWxkIGl0IGJlIG5lY2Vzc2FyeSB0byBzZXQgaXQgdXAgeWV0IGFub3Ro ZXIgdGltZSBmb3IgdmVyaWZpY2F0aW9uIGZyb20gbG9jYWwgb3IgdHJ1c3RzdG9yZT8gVGhpcyB3 b3VsZCBtZWFuIHRoZXJlIGlzIG5vIG5lZWQgZm9yIGEgUFNLIG9wdGlvbiB3aGVuIGNvbmZpZ3Vy aW5nIGhvdyB0byAgdmVyaWZ5IHRoZSBwZWVyLg0KDQpjb250YWluZXIgPGNsaWVudC1hdXRoZW50 aWNhdGlvbiBvciBzZXJ2ZXItYXV0aGVudGljYXRpb24+IHsNCiAgICBjaG9pY2UgYXV0aC10eXBl IHsNCiAgICAgICAgbWFuZGF0b3J5IHRydWU7DQogICAgICAgIGNhc2UgY2VydGlmaWNhdGUgew0K ICAgICAgICAgICAgaWYtZmVhdHVyZSB4NTA5LWNlcnRpZmljYXRlLWF1dGg7DQogICAgICAgICAg ICBjb250YWluZXIgY2EtY2VydHMgew0KDQogICAgICAgICAgICAgICAgdXNlcyB0czpsb2NhbC1v ci10cnVzdHN0b3JlLWNlcnRzLWdyb3VwaW5nDQogICAgICAgICAgICB9DQogICAgICAgICAgICBj b250YWluZXIgc2VydmVyLWNlcnRzIHsNCg0KICAgICAgICAgICAgICAgIHVzZXMgdHM6bG9jYWwt b3ItdHJ1c3RzdG9yZS1jZXJ0cy1ncm91cGluZw0KICAgICAgICAgICAgfQ0KICAgICAgIH0NCiAg ICAgICAgY2FzZSByYXctcHVibGljLWtleSB7DQogICAgICAgICAgICBpZi1mZWF0dXJlIHJhdy1w dWJsaWMta2V5LWF1dGg7DQogICAgICAgICAgICAgICAgdXNlcyBrczogbG9jYWwtb3ItdHJ1c3Rz dG9yZS1yYXctcHViLWtleXMtZ3JvdXBpbmcNCiAgICAgICB9DQoNCk5vIG5lZWQgZm9yIFBTSyBj b25maWcgc2luY2UgaXQgaXMgYWxyZWFkeSBjb25maWd1cmVkIGluIGNsaWVudC9zZXJ2ZXItaWRl bnRpdHkuDQoNCkFjay4gICAoc2VlIEdpdEh1YiBmb3IgbGF0ZXN0IGZpbGVzLCB0aG91Z2ggdGhl IGNvbW1pdCBpcyBsYXJnZXIgdGhhbiBpdCBzaG91bGQgYmUpDQoNCkFuZCwgYXMgYSBib251cywg S2V5c3RvcmUgYWxyZWFkeSBkZWZpbmVzIHN1cHBvcnQgZm9yIGVuY3J5cHRpb24gKHVubGlrZSBU cnVzdHN0b3JlKS4NCg0KDQogT3Igd2hhdCBpcyB0aGUgcmVhc29uaW5nIHdoeSBpdCBpcyBuZWNl c3NhcnkgdG8gY29uZmlndXJlIGEgUFNLIGZyb20gdHJ1c3RzdG9yZT8NCg0KU29tZWhvdyBJIHRo b3VnaHQgdGhhdCB3ZXJlIGJlaW5nIHVzZWQgaW4gY29uY2VwdHVhbGx5IGRpZmZlcmVudCB3YXlz LCBidXQgSSBzZWUgbm93IHRoYXQncyBub3QgcmVhbGx5IHRoZSBjYXNlLi4uDQoNCg0KVGhhbmsg eW91LCBCYWxhenMsIHRoaXMgbWVzc2FnZSB3YXMgbW9zdCBoZWxwZnVsIQ0KDQpLZW50IC8vIGNv bnRyaWJ1dG9yDQoNCg0K --_000_AM0PR07MB518797EFBA3FBF42F9B1C1D6834C0AM0PR07MB5187eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAu TXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3Jh cGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0K CW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2lu LWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0K cC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUt bmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0 OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpz cGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0 ZWQtc3BhY2U7fQ0Kc3Bhbi5hcHBsZS10YWItc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS10 YWItc3Bhbjt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N CnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bh bi5wbC1rDQoJe21zby1zdHlsZS1uYW1lOnBsLWs7fQ0Kc3Bhbi5wbC1zDQoJe21zby1zdHlsZS1u YW1lOnBsLXM7fQ0Kc3Bhbi5wbC1jDQoJe21zby1zdHlsZS1uYW1lOnBsLWM7fQ0Kc3Bhbi5wbC1j MQ0KCXttc28tc3R5bGUtbmFtZTpwbC1jMTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgS2VudCw8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSBoYWQgYSBsb29rIGF0IHlvdXIgY2hhbmdlcyByZWxhdGVkIHRvIG91 ciBkaXNjdXNzaW9uLiBJbiBnZW5lcmFsIGl0IGxvb2tzIGdvb2QhPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlNvbWUgcXVlc3Rpb25zIGJlbG93OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0i MCIgY2VsbHBhZGRpbmc9IjAiIHN0eWxlPSJtYXJnaW4tbGVmdDozMy43NXB0Ij4NCjx0Ym9keT4N Cjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5jb250YWluZXIgc2VydmVyLWF1dGhlbnRpY2F0aW9uIHs8bzpwPjwv bzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43 NXB0IC43NXB0IC43NXB0Ij48L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjMzLjc1cHQiPjxzcGFuIHN0eWxlPSJk aXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0i TXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIHN0eWxlPSJtYXJnaW4t bGVmdDozMy43NXB0Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzouNzVwdCAu NzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7igKY8bzpwPjwvbzpwPjwv cD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzMuNzVwdCI+PHNwYW4gc3R5bGU9ImRpc3BsYXk6bm9uZSI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJs ZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjMzLjc1cHQi Pg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43 NXB0Ij48L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjMzLjc1cHQiPjxzcGFuIHN0eWxlPSJkaXNwbGF5Om5vbmUi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFi bGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIHN0eWxlPSJtYXJnaW4tbGVmdDozMy43NXB0 Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAu NzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5jYXNlIHBzayB7PG86cD48L286cD48L3A+DQo8 L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAu NzVwdCI+PC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozMy43NXB0Ij48c3BhbiBzdHlsZT0iZGlzcGxheTpub25l Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRh YmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NjkuNzVw dCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQg Ljc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Ly8gbm8gY29uZmlndXJhdGlvbiByZXF1aXJl ZCBzaW5jZSBpdDxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9 InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4N CjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NjkuNzVw dCI+PHNwYW4gc3R5bGU9ImRpc3BsYXk6bm9uZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0i MCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjMzLjc1cHQiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxl PSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4vLyBpcyB0aGUgc2FtZSBhcyBpbiBjbGllbnQtaWRl bnRpdHkhPG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBzdHlsZT0icGFk ZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+PC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90 YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozMy43NXB0Ij59 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvIHdlIG5lZWQgdGhlIGlmLWZlYXR1cmUgaW4gY2Fz ZSBvZiB0aGlzIGVtcHR5IGNhc2U/IElzIHRoZSBlbXB0eSBjYXNlIG9rIGluIGdlbmVyYWw/PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsgZ3Jv dXBpbmcgbG9jYWwtb3ItdHJ1c3RzdG9yZS1yYXctcHViLWtleXMtZ3JvdXBpbmcgezxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPuKA pjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyBjaG9pY2UgbG9jYWwtb3ItdHJ1c3RzdG9yZSB7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1hbmRhdG9yeSB0cnVlOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjYXNlIGxvY2FsIHs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaWYtZmVhdHVyZSAmcXVvdDtsb2NhbC1k ZWZpbml0aW9ucy1zdXBwb3J0ZWQmcXVvdDs7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbnRhaW5lciBsb2NhbC1kZWZpbml0aW9uIHs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj7igKY8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgbGlzdCByYXctcHVibGljLWtleSB7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+4oCmPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgdXNlcyBjdDpwdWJsaWMta2V5LWdyb3VwaW5nOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVzZXMgY3Q6dHJ1 c3QtYW5jaG9yLWNlcnRzLWdyb3VwaW5nOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAvLy8NCjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3MiPsOfPC9zcGFuPiBJcyB0aGlzIGEgbWlz dGFrZT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGNhc2UgdHJ1c3RzdG9yZSB7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+4oCmPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj7igKY8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsg fTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPiZuYnNwOyB9PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldhcyB0aGUgbWFya2VkIGxp bmUgbGVmdCBvdmVyIGFzIGEgbWlzdGFrZSBhZnRlciBhIGNvcHkgZnJvbSBsb2NhbC1vci10cnVz dHN0b3JlLWNlcnRzLWdyb3VwaW5nPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Cciw8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJhbGF6czxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxiPkZyb206PC9iPiBuZXRjb25mICZsdDtuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmcm Z3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJhbMOhenMgS292w6Fjczxicj4NCjxiPlNlbnQ6PC9i PiBUdWVzZGF5LCBOb3ZlbWJlciAxMiwgMjAxOSAxMDoxMSBBTTxicj4NCjxiPlRvOjwvYj4gS2Vu dCBXYXRzZW4gJmx0O2tlbnQmIzQzO2lldGZAd2F0c2VuLm5ldCZndDs8YnI+DQo8Yj5DYzo8L2I+ IG5ldGNvbmZAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtuZXRjb25mXSBGSVhN RXMgaW4gaWV0Zi1jcnlwdG8tdHlwZXMgYW5kIGNsaWVudC9zZXJ2ZXIgbW9kZWxzPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkhpIEtlbnQsPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+UmVnYXJk aW5nIHRoaXMgb25lOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj5ZZXMsIHRoZSBwcmV2aW91cyB3YXkgKGV4 YW1wbGUgYWJvdmUpIHdhcyBhZGVxdWF0ZSwgYnV0IEkgYmVsaWV2ZSB0aGUgbmV3IHdheSAoaS5l LiB1c2luZyBhIGtleS1mb3JtYXQgbGVhZikgaXMgYmV0dGVyIGFzOjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBp biI+MSkgaXQgZW5hYmxlcyB0aGUgYSBrZXktdHlwZSAoZS5nLiwgYSBzeW1tZXRyaWMga2V5KSBk byBiZSBleHByZXNzZWQgaW4gZGlmZmVyZW50IHdheXMgYXMgbmVlZGVkIChPY3RldFN0cmluZyB2 cy4mbmJzcDtPbmVTeW1tZXRyaWNLZXkgdnMuJm5ic3A7RW5jcnlwdGVkRGF0YSk8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+Mikg aXQgTUFZIChoYXZlbid0IHRyaWVkIHRvIG1vZGVsIGl0IHlldCkgYmUgYWJsZSB0byBzdXBwb3J0 IGVuY29kaW5nIHZhcmlhdGlvbnMgKERFUiB2cyBQRU0sIGFuZCBDTVMgdnMuIG11bHRpLXBhcnQg UEVNKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjEuMGluIj4zKSBpdCBkZWNvdXBsZXMgdGhlIHBhcnQgdGhhdCB3ZSBhcmUgc3R1Y2sgb24g KGkuZS4sIHRoZSAnYWxnb3JpdGhtJyBub2RlKSBhbmQgaXQgYmVpbmcgZmFjdG9yZWQtb3V0IG1h eSBwcm92aWRlIG1vcmUgZmxleGliaWxpdHkgaW4gdGhhdCBkZWZpbml0aW9uLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDoxLjBpbiI+VGhlIFdHIGhhc24ndCBkaXNjdXNzZWQga2V5LWZvcm1hdCB5ZXQuICZuYnNwO0Fi b3ZlIGlzIHRoZSBmaXJzdCBmb3JheSBpbnRvIGl0Li4uZG8gdGhlc2UgYXJndW1lbnRzIHNvdW5k IGNvbXBlbGxpbmc/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+WWVzIGluZGVlZC4gU28gdGhlIHByb3Bvc2Fs IGlzIG9rIGZvciBtZS4gSXMgdGhlcmUgYW55dGhpbmcgdG8gZGlzY3VzcyBvbiB0aGUgZGV0YWls cyBvZiB0aGlzIHRvIG1hdHRlciBvciB0aGUgaGF2ZSB0aGUgV0figJlzIGNvbW1pdG1lbnQ/PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+QnI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj5CYWxhenM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPjxiPkZyb206PC9iPiBLZW50IFdh dHNlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtlbnQmIzQzO2lldGZAd2F0c2VuLm5ldCI+a2VudCYj NDM7aWV0ZkB3YXRzZW4ubmV0PC9hPiZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE5v dmVtYmVyIDExLCAyMDE5IDQ6MDcgQU08YnI+DQo8Yj5Ubzo8L2I+IEJhbMOhenMgS292w6FjcyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmJhbGF6cy5rb3ZhY3NAZXJpY3Nzb24uY29tIj5iYWxhenMua292 YWNzQGVyaWNzc29uLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86 bmV0Y29uZkBpZXRmLm9yZyI+bmV0Y29uZkBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IEZJWE1FcyBpbiBpZXRmLWNyeXB0by10eXBlcyBhbmQgY2xpZW50L3NlcnZlciBtb2Rl bHM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj5IaSBCYWxhenMsPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEu MGluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9t OjBpbjttYXJnaW4tbGVmdDoyLjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQ7dGV4dC1pbmRlbnQ6 LS4yNWluIj4NCjEuPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj5LZXktZm9ybWF0IChzeW1tZXRyaWMta2V5LCBwdWJsaWMt a2V5LCBhc3ltbWV0cmljLWtleS1wYWlyKTxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+SSBhc3N1bWUgdGhlIGlkZWEg aGVyZSBpcyB0byBtYWtlIGl0IHBvc3NpYmxlIHRvIGhhdmUgY2hvaWNlcyBmb3IgdGhlIEFTTi4x IHR5cGVzIGhvbGRpbmcgdGhlIGtleXMuIElmIHRoaXMgZmxleGliaWxpdHkgZm9yIGZvcm1hdHMg aXMgbmVjZXNzYXJ5IEkgZG9u4oCZdCBoYXZlIGFueSBvYmplY3Rpb24gdG8gdGhlbSBidXQgaGF2 aW5nIGEgc2luZ2xlIGFncmVlZCB0eXBlDQogZm9yIHRoZXNlIGRpZmZlcmVudCB1c2UgY2FzZXMg d291bGQgYWxzbyBzdWZmaWNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj5JIGJlbGll dmUgaGVyZSB5b3UncmUgcmVmZXJyaW5nIHRvIHRoZSAzIGluc3RhbmNlcyBvZiBsaW5lcyBsaWtl OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDox LjBpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjEuMGluIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwO2xlYWYmbmJzcDtrZXkm bmJzcDt7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7bmFjbTpkZWZhdWx0 LWRlbnktYWxsOzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwO3R5cGUmbmJz cDtiaW5hcnk7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7Ly9tdXN0ICZx dW90Oy4uL2tleS1mb3JtYXQmcXVvdDs7Jm5ic3A7Jm5ic3A7RklYTUU6IHJlbW92ZSBjb21tZW50 IGlmIGFwcHJvYWNoIG9rPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjEuMGluIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLi4uPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDoxLjBpbiI+RldJVywgdGhlIHdob2xlICZxdW90O2tleS1mb3JtYXQmcXVv dDsgbGVhZiBpcyBzdGlsbCBiZWluZyBzdXNzZWQgb3V0ICh5b3VyIG9waW5pb24gd291bGQgYmUg aGVscGZ1bCBvbiB0aGF0IHRocmVhZCBhcyB3ZWxsKSBidXQsIHNvIGZhciBpdCBzZWVtcyBwcm9t aXNpbmcuICZuYnNwO1RoZSByZWFzb24gdGhlc2UgbGluZXMgYXJlIGNvbW1lbnRlZCBvdXQgaXMg YmVjYXVzZSAxKSB0aGUgV0cNCiBoYXNuJ3QgY29tbWl0dGVkIHRvIHRoaXMgcGF0aCB5ZXQgYW5k IDIpIEkgZGlkbid0IHdhbnQgdG8gdXBkYXRlIGFsbCB0aGUgZXhhbXBsZXMgaW4gYWxsIHRoZSBk cmFmdHMgKG90aGVyIHRoYW4gdHJ1c3RzdG9yZSBhbmQga2V5c3RvcmUpIHRvIGFkZCBhICZxdW90 O2tleS1mb3JtYXQmcXVvdDsgbGVhZiB1bnRpbCB0aGUgV0cgaGFkIG1vcmUgY29uc2Vuc3VzIG9u IHRoZSAmcXVvdDtrZXktZm9ybWF0JnF1b3Q7IGxlYWZzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj5JIGRvbid0 IHVuZGVyc3RhbmQgeW91ciBsYXN0IGNvbW1lbnQvc2VudGVuY2UuICZuYnNwO0NhbiB5b3UgcHJv dmlkZSBhbiBleGFtcGxlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDoxLjBpbiI+QmFsYXpzJmd0OyBPaywgdGhlbiBsZXTigJlzIHdhaXQgZm9yIFdHIGRlY2lzaW9u LiBXZWxsLCBJIGp1c3Qgc2F5IHRoYXQgdGhlIGVhcmxpZXIgd2F5cyBvZiBjb21tdW5pY2F0aW5n IHRoZSBrZXkgZm9ybWF0cyB3ZXJlIGFkZXF1YXRlIGZyb20gbXkgcG9pbnQgb2Ygdmlldywgd2hp Y2ggd2FzIHRoYXQgaW4gZG9jdW1lbnRhdGlvbiBpdCB3YXMgc2FpZCB0aGF0IGZvciBSU0ENCiB1 c2UgUlNBUHJpdmF0ZUtleSBhbmQgZm9yIEVDIHVzZSBFQ1ByaXZhdGVLZXksIGFuZCBzaW1pbGFy bHkgZm9yIG90aGVyIHR5cGVzLiBJ4oCZbSBhbHNvIG9rIHdpdGggdGhlIGtleS1mb3JtYXQgYXBw cm9hY2ggaWYgcHJlZmVycmVkIGJ5IHRoZSBXRy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDoxLjBpbiI+SW4gZWFybGllciB2ZXJzaW9uczo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGVzY3JpcHRpb248L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MS4waW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7VGhl IHZhbHVlIG9mIHRoZSBiaW5hcnkga2V5LiZuYnNwOyBUaGUga2V5J3MgdmFsdWUgaXM8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MS4waW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW50 ZXJwcmV0ZWQgYnkgdGhlICdhbGdvcml0aG0nLiZuYnNwOyBGb3IgZXhhbXBsZSwgYSBEU0Ega2V5 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGlzIGFuIGludGVnZXIsIGFuIFJTQSBrZXkgaXMgcmVwcmVzZW50ZWQgYXMgUlNBUHJpdmF0 ZUtleTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBhcyBkZWZpbmVkIGluPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjwvc3Bhbj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjODAxNyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6cHVycGxlIj5SRkMNCiA4MDE3PC9zcGFuPjwvYT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+LCBhbmQgYW4gRUNDIGtleSBpcyByZXByZXNlbnRlZCBhczwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDoxLjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBFQ1ByaXZhdGVLZXkg YXMgZGVmaW5lZCBpbjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU5MTUi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOnB1cnBsZSI+UkZDDQogNTkxNTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi4m cXVvdDs8L3NwYW4+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjEuMGluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPlllcywgdGhl IHByZXZpb3VzIHdheSAoZXhhbXBsZSBhYm92ZSkgd2FzIGFkZXF1YXRlLCBidXQgSSBiZWxpZXZl IHRoZSBuZXcgd2F5IChpLmUuIHVzaW5nIGEga2V5LWZvcm1hdCBsZWFmKSBpcyBiZXR0ZXIgYXM6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MS4waW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj4xKSBpdCBl bmFibGVzIHRoZSBhIGtleS10eXBlIChlLmcuLCBhIHN5bW1ldHJpYyBrZXkpIGRvIGJlIGV4cHJl c3NlZCBpbiBkaWZmZXJlbnQgd2F5cyBhcyBuZWVkZWQgKE9jdGV0U3RyaW5nIHZzLiZuYnNwO09u ZVN5bW1ldHJpY0tleSB2cy4mbmJzcDtFbmNyeXB0ZWREYXRhKTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGlu Ij4yKSBpdCBNQVkgKGhhdmVuJ3QgdHJpZWQgdG8gbW9kZWwgaXQgeWV0KSBiZSBhYmxlIHRvIHN1 cHBvcnQgZW5jb2RpbmcgdmFyaWF0aW9ucyAoREVSIHZzIFBFTSwgYW5kIENNUyB2cy4gbXVsdGkt cGFydCBQRU0pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPjMpIGl0IGRlY291cGxlcyB0aGUgcGFydCB0 aGF0IHdlIGFyZSBzdHVjayBvbiAoaS5lLiwgdGhlICdhbGdvcml0aG0nIG5vZGUpIGFuZCBpdCBi ZWluZyBmYWN0b3JlZC1vdXQgbWF5IHByb3ZpZGUgbW9yZSBmbGV4aWJpbGl0eSBpbiB0aGF0IGRl ZmluaXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGlu Ij5UaGUgV0cgaGFzbid0IGRpc2N1c3NlZCBrZXktZm9ybWF0IHlldC4gJm5ic3A7QWJvdmUgaXMg dGhlIGZpcnN0IGZvcmF5IGludG8gaXQuLi5kbyB0aGVzZSBhcmd1bWVudHMgc291bmQgY29tcGVs bGluZz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDox LjBpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBp bjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjEuMGlu Ij4NCjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2IHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbiI+Mi48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj5hdHRy aWJ1dGVzIGluIGFzeW1tZXRyaWMta2V5LXBhaXItd2l0aC1jZXJ0KHMpLWdyb3VwaW5nPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+SSB0aGluayBhdHRyaWJ1dGVzIHNob3VsZCBiZSBrZXB0 IG9wdGlvbmFsLiBJZiB0aGVyZSBpcyBhbnl0aGluZyBlbHNlIGJlc2lkZXMgc3ViamVjdCBzZWVu IG1hbmRhdG9yeSBtYXliZSBpdCBzaG91bGQgYmUgZXh0cmFjdGVkIG91dCBmcm9tIGF0dHJpYnV0 ZXMgYW5kIGJlIHNwZWxsZWQgb3V0IGEgc2VwYXJhdGUgbGVhZiwgYnV0IEkgZG9u4oCZdCB0aGlu ayB0aGVyZQ0KIGlzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj5JIGJlbGlldmUgaGVy ZSB5b3UncmUgcmVmZXJyaW5nIHRvIHRoZSAyIGluc3RhbmNlcyBvZiBsaW5lcyBsaWtlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjEuMGluIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDtsZWFmJm5ic3A7YXR0 cmlidXRlcyZuYnNwO3s8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5i c3A7dHlwZSZuYnNwO2JpbmFyeTsmbmJzcDsvLyBGSVhNRTogZG9lcyB0aGlzIG5lZWQgdG8gYmUg bWFuZGF0b3J5Pzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLi4uPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGlu Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj5UaGVzZSBhcmUg aW4gdGhlICZxdW90O2dlbmVyYXRlLWNlcnRpZmljYXRlLXNpZ25pbmctcmVxdWVzdCZxdW90OyBh Y3Rpb25zIGZvdW5kIGluc2lkZSB0aGUmbmJzcDthc3ltbWV0cmljLWtleS1wYWlyLXdpdGgtY2Vy dChzKS1ncm91cGluZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MS4waW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+SG1tbSwgYXJlIHlvdSBjbGFpbWluZyB0aGF0 ICZxdW90O2F0dHJpYnV0ZXMmcXVvdDsgYXJlIG5vdCByZXF1aXJlZCBpbiBvcmRlciB0byBnZW5l cmF0ZSBhIENTUj8gJm5ic3A7SSB0aGluayB0aGUgQ1NSIGl0c2VsZiBNVVNUIGhhdmUgYXR0cmli dXRlcyAocmlnaHQ/KSBzbywgaWYgbm90IHNwZWNpZmllZCwgd2hhdCBkZWZhdWx0IHZhbHVlcyBh cmUgdXNlZD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MS4waW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj5C YWxhenMmZ3Q7IEluPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMyOTg2I3NlY3Rpb24t MyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+UkZDMjk4Njwvc3Bhbj48L2E+PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPnRoZSBhdHRyaWJ1dGVzDQog YXJlIHNhaWQgdG8gYmUgb3B0aW9uYWwuIFdlIGp1c3QgbmVlZCB0aGUgc3ViamVjdCBETiBhcyBt YW5kYXRvcnksIGRvbuKAmXQgd2U/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+Jm5ic3A7PG86 cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMS4gQSBDZXJ0aWZpY2F0aW9uUmVxdWVz dEluZm8gdmFsdWUgY29udGFpbmluZyBhIHN1YmplY3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkaXN0aW5ndWlzaGVkIG5hbWUsIGEgc3ViamVj dCBwdWJsaWMga2V5LCBhbmQgPGI+b3B0aW9uYWxseSBhPC9iPjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+PGI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNldCBvZiBhdHRyaWJ1dGVzPC9i PiBpcyBjb25zdHJ1Y3RlZCBieSBhbiBlbnRpdHkgcmVxdWVzdGluZzxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNlcnRpZmljYXRpb24uPG86cD48 L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDoxLjBpbiI+VGhhbmsgeW91LiAmbmJzcDtJJ3ZlIHJlbW92ZWQgdGhlc2UgdG8gY29tbWVu dHMsIHRodXMgbGVhdmluZyB0aGUgJnF1b3Q7YXR0cnVidHV0ZSZxdW90OyBub2RlcyBhcyBOT1Qg bWFuZGF0b3J5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBp biI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGlu Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDo1LjBwdDttYXJnaW4tcmln aHQ6MGluO21hcmdpbi1ib3R0b206MGluO21hcmdpbi1sZWZ0OjIuMGluO21hcmdpbi1ib3R0b206 LjAwMDFwdDt0ZXh0LWluZGVudDotLjI1aW4iPg0KMy48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj5QU0sgYW5kIHJhdyBwdWJsaWMga2V5czxvOnA+ PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8ZGl2IHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDoxLjBpbiI+VGhlIHVzZSBjYXNlIG9mIFBTSyBhbmQgcmF3IHB1YmxpYyBrZXlzIGFyZSBub3Qg dGhlIG1vc3QgdXJnZW50IGluIG15IG9waW5pb24gd2hpY2ggbm93IHNsb3dzIGEgYml0IHRoZSBw cm9ncmVzcyBvZiB0aGVzZSBkcmFmdHMsIGJ1dCBsZXTigJlzIG1ha2UgYW4gYXR0ZW1wdCB0byBm aW5hbGl6ZSB0aGVtLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPkFncmVlZCwgYnV0IHRoZXkgYXJl IGxlZ2FsIGZvciBUTFMgYW5kIGEgV0cgbWVtYmVyIHN0YXRlZCB0aGF0IHRoZXkgd2VyZSBuZWVk ZWQgaW4gb3JkZXIgdG8gc3VwcG9ydCBhbm90aGVyIElFVEYgV0cncyBlZmZvcnRzLiAmbmJzcDtB IHF1aWNrIHJlc29sdXRpb24gd291bGQgYmUgYmVzdCE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdp bi1yaWdodDowaW47bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6MS4waW4iPg0KJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+cmF3LXB1YmxpYy1rZXlzOiBJIHNlZSB0aGVzZSB3 ZXJlIGFkZGVkIGR1ZSB0byBSRkMgNzI1MCBhbmQgODQ0Ni4gSSBndWVzcyBpbiB0cnVzdHN0b3Jl IHRoaXMgaXMgYSBzZXBhcmF0ZSBjb250YWluZXIgdG8gZGlzdGluZ3Vpc2ggZnJvbSBTU0ggaG9z dCBrZXlzLiBGb3IgY29uZmlndXJpbmcgdGhlIHByaXZhdGUgcGFydCBJIHRoaW5rIGtleXN0b3Jl IGFscmVhZHkNCiBnaXZlcyBzdXBwb3J0IGZvciB0aGlzIGNhc2Ugd2l0aCB0aGUgYXN5bW1ldHJp YyBrZXkgKHcvbyBjZXJ0KSBhbmQgaW4gdGhlIGNsaWVudC9zZXJ2ZXIgZHJhZnRzIEtlbnTigJlz IHByb3Bvc2FsIGNvdWxkIGJlIHVzZWQgKEkgcmVwbGFjZWQgcmF3IHB1YmxpYyBrZXkgd2l0aCBl eGlzdGluZyB0eXBlLCBzaG91bGRu4oCZdCB0aGF0IGJlIHVzZWFibGUgc3RyYWlnaHQgYXdheT8p PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj48c3BhbiBjbGFzcz0iYXBw bGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Jm5ic3A7ICZuYnNw OyZuYnNwO2NvbnRhaW5lciZuYnNwOyZsdDtjbGllbnQtaWRlbnRpdHkmbmJzcDtvciZuYnNwO3Nl cnZlci1pZGVudGl0eSZndDsmbmJzcDt7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4i PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgY2hv aWNlIGF1dGgtdHlwZSB7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjEy LjBwdDttYXJnaW4tbGVmdDoxLjBpbiI+DQo8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO3VzZXMmbmJzcDtrczpsb2NhbC1vci1rZXlzdG9yZS1lbmQtZW50aXR5LWNlcnQtd2l0 aC1rZXktZ3JvdXBpbmc7PGJyPg0KPHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDt1c2VzJm5ic3A7a3M6bG9jYWwtb3Ita2V5c3RvcmUtYXN5bW1ldHJpYy1rZXktZ3JvdXBpbmc7 PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+SSB3b3VsZCBh bHNvIHByZWZlciBpZiB0aGVzZSBjaG9pY2VzIGFyZSBpbiBmZWF0dXJlcywgc28gdGhhdCBhbiBp bXBsZW1lbnRhdGlvbiBjYW4gY2hvb3NlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj5U byB5b3VyIGZpcnN0IHNlbnRlbmNlLCB5ZXMsICZxdW90O3BzayZxdW90OyAoYW5kICZxdW90O3Jh dy1wdWJsaWMta2V5JnF1b3Q7KSBhcmUgdG9wLWxldmVsIG5vZGVzIGluIHRydXN0c3RvcmUsIGFz IGNhbiBiZSBzZWVuIGhlcmUgKDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLW5ldGNvbmYtdHJ1c3QtYW5jaG9ycy0wNyNzZWN0aW9uLTIuMSI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt bmV0Y29uZi10cnVzdC1hbmNob3JzLTA3I3NlY3Rpb24tMi4xPC9zcGFuPjwvYT4pLg0KICZuYnNw OyBOb3RlLCB0aGUgdHJ1c3QtYW5jaG9ycyBkcmFmdCBhY2NpZGVudGFsbHkgZG9lc24ndCBpbmNs dWRlIHRoZSBpZXRmLXRydXN0c3RvcmUueWFuZyBtb2R1bGUuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPlRoZSBi b2R5IG9mIHlvdXIgY29tbWVudCBhYm92ZSBzZWVtcyB0byBiZSBhYm91dCBzdXBwb3J0aW5nIHRo ZSBzZWNyZXQtaGFsZiBvZiB0aGUgUFNLIGFuZCBSUEsgd2l0aGluIHRoZSBLZXlzdG9yZS4gJm5i c3A7SSd2ZSByYWlzZSB0aGlzIHF1ZXN0aW9uIGEgY291cGxlIHRpbWVzIHByZXZpb3VzbHkgdG8g SGVuayAod2hvJ3MgYXNraW5nIGZvciB0aGUgUFNLL1JQSyBhZGQpLA0KIGJ1dCBoZSdzIG5vdCBy ZXNwb25kZWQgeWV0IGFzIHRvIGlmIGRvaW5nIHNvIGlzIGltcG9ydGFudCAodGhvdWdoIEkgY2Fu IG9ubHkgaW1hZ2luZSB0aGF0IGl0IGRvZXMpLiAmbmJzcDsgV2l0aCB0aGF0IHNhaWQsIEkgdGhp bmsgeW91ciBZQU5HIHNuaXBwZXQgaXMgbWVhbnQgdG8gYmUgaW4gaWV0Zi10bHMtc2VydmVyIGFu ZCBpZXRmLXRscy1jbGllbnQgbW9kdWxlcyAocmlnaHQ/KS4gJm5ic3A7SSdtIGhhdmluZyBhIGhh cmQgdGltZSBmb2xsb3dpbmcgdGhlICZxdW90O0kNCiByZXBsYWNlZCByYXcgcHVibGljIGtleSB3 aXRoIGV4aXN0aW5nIHR5cGUsIHNob3VsZG7igJl0IHRoYXQgYmUgdXNlYWJsZSBzdHJhaWdodCBh d2F5PyZxdW90OyBjb21tZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+QmFsYXpzOiBZb3UgaGFkIGFuIGV4YW1wbGUgZWFy bGllciBpbiBhbiBlbWFpbCBmcm9tIDEwLzgvMjAxOSwgd2hpY2ggaXMgYWJvdXQgdGhlIFRMUyBj bGllbnQvc2VydmVyIG1vZGVscy4gQmVsb3csIHlvdSBhcmUgcmVmZXJyaW5nIHRvIHNvbWUgcG9z c2libHkgbmV3IGdyb3VwaW5ncyB0aGF0IHlvdSB3YW50ZWQgdG8gcHJvcG9zZS4gSSBkb27igJl0 IHVuZGVyc3RhbmQNCiB0aG91Z2ggd2h5IHlvdSBtZW50aW9uZWQgdGhlc2UgbmV3IGdyb3VwaW5n cyBzaW5jZSDigJhrczpsb2NhbC1vci1rZXlzdG9yZS1hc3ltbWV0cmljLWtleS1ncm91cGluZ+KA mSAoUlBLKSBhbmQgc29tZXRoaW5nIG5ldyB0aGF0IGp1c3QgcmVmZXJzIHRvIGEga2V5c3RvcmUg c3ltbWV0cmljIGtleSwgc3VjaCBhcyDigJhrczpsb2NhbC1vci1rZXlzdG9yZS1zeW1tZXRyaWMt a2V5LWdyb3VwaW5n4oCZIChQU0spIHNob3VsZCBiZSBnb29kLiBUaGlzIGxhdHRlcg0KIEkgdGhp bmsgd291bGQgYmUgYSBuZXcgZ3JvdXBpbmcsIGJ1dCB3aXRoIGV4aXN0aW5nIHRlcm1pbm9sb2d5 LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+PGk+QWxs LCBsb29raW5nIGF0Jm5ic3A7aWV0Zi10bHMtY2xpZW50LnlhbmcgYW5kJm5ic3A7aWV0Zi10bHMt c2VydmVyLnlhbmcsIGFkZGluZyB0aGUgYWJpbGl0eSB0byBjb25maWd1cmUgdGhlICZxdW90O3By aXZhdGUmcXVvdDsgaGFsZiBvZiBhIFBTSyBvciByYXcgcHVibGljIGtleSB3b3VsZCBiZSBzb21l dGhpbmcgbGlrZTo8L2k+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPjxpPiZuYnNwOzwvaT48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDoxLjBpbiI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj48aT4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L2k+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPjxpPiZuYnNwOzwvaT48L3NwYW4+PGk+T0xEPC9pPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjEuMGluIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPjxpPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOzwvaT48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+PGk+Jm5ic3A7PC9pPjwvc3Bhbj48aT4mbmJzcDsgJm5ic3A7Jm5ic3A7Y29udGFpbmVy ICZsdDtjbGllbnQtaWRlbnRpdHkmbmJzcDtvciZuYnNwO3NlcnZlci1pZGVudGl0eSZndDsgezwv aT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjEyLjBw dDttYXJnaW4tbGVmdDoxLjBpbiI+DQo8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPjxpPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvaT48L3NwYW4+PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+PGk+Jm5ic3A7PC9pPjwvc3Bhbj48aT4mbmJzcDsgJm5ic3A7 ICZuYnNwOyZuYnNwO3VzZXMmbmJzcDtrczpsb2NhbC1vci1rZXlzdG9yZS1lbmQtZW50aXR5LWNl cnQtd2l0aC1rZXktZ3JvdXBpbmc7PC9pPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+PHNwYW4gY2xhc3M9ImFwcGxl LXRhYi1zcGFuIj48aT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L2k+PC9zcGFu PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxpPiZuYnNwOzwvaT48L3NwYW4+ PGk+TkVXPC9pPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNw YW4iPjxpPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvaT48L3NwYW4+PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PGk+Jm5ic3A7PC9pPjwvc3Bhbj48aT4mbmJz cDsgJm5ic3A7Jm5ic3A7Y29udGFpbmVyJm5ic3A7Jmx0O2NsaWVudC1pZGVudGl0eSZuYnNwO29y Jm5ic3A7c2VydmVyLWlkZW50aXR5Jmd0OyZuYnNwO3s8L2k+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4i PjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+PGk+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7PC9pPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48 aT4mbmJzcDs8L2k+PC9zcGFuPjxpPiZuYnNwOyAmbmJzcDsgJm5ic3A7IGNob2ljZSBhdXRoLXR5 cGUgezwvaT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFu Ij48aT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L2k+PC9zcGFuPjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxpPiZuYnNwOzwvaT48L3NwYW4+PGk+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3VzZXMmbmJzcDtrczpsb2NhbC1vci1rZXlzdG9y ZS1lbmQtZW50aXR5LWNlcnQtd2l0aC1rZXktZ3JvdXBpbmc7PGJyPg0KPHNwYW4gY2xhc3M9ImFw cGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt1c2VzJm5ic3A7a3M6bG9jYWwtb3Ita2V5c3RvcmUtcmF3 LXB1YmxpYy1rZXktZ3JvdXBpbmc7PGJyPg0KPHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDt1c2VzJm5ic3A7a3M6bG9jYWwtb3Ita2V5c3RvcmUtcHJlLXNoYXJlZC1rZXktZ3Jv dXBpbmc7PC9pPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEu MGluIj5BaCwgbm93IEkgdW5kZXJzdGFuZCwgSSBhbmQgYWdyZWUgdGhhdCB0aGlzIHNlZW1zIGxp a2UgdGhlIHJpZ2h0IHdheSB0byBkbyBpdCwgYnV0IHNlZSBiZWxvdy4uLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjEuMGluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4t Ym90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDoxLjBpbiI+DQo8bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+VG8geW91ciBsYXN0IHNlbnRl bmNlIHJlZ2FyZGluZyBmZWF0dXJlcywgY291bGQgeW91IHByb3ZpZGUgYW4gZXhhbXBsZSBvZiB3 aGF0IHlvdSBtZWFuPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDox LjBpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPmNvbnRhaW5lciZuYnNwOyZsdDtjbGll bnQtaWRlbnRpdHkmbmJzcDtvciZuYnNwO3NlcnZlci1pZGVudGl0eSZndDsmbmJzcDt7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MS4waW4iPiZuYnNwOyZuYnNwOyZuYnNwOyBjaG9pY2UgYXV0aC10eXBlIHs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDoxLjBpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO21hbmRhdG9yeSB0cnVlOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY2FzZSBjZXJ0aWZpY2F0ZSB7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MS4waW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBpZi1mZWF0dXJlIHg1MDktY2VydGlmaWNhdGUtYXV0aDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDoxLjBpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO3VzZXMmbmJzcDtrczpsb2NhbC1vci1rZXlzdG9yZS1lbmQt ZW50aXR5LWNlcnQtd2l0aC1rZXktZ3JvdXBpbmc7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjYXNlIHJhdy1wdWJsaWMt a2V5IHs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlmLWZlYXR1cmUgcmF3LXB1Ymxp Yy1rZXktYXV0aDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3VzZXMmbmJzcDtrczpsb2NhbC1v ci1rZXlzdG9yZS1hc3ltbWV0cmljLWtleS1ncm91cGluZzs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08YnI+DQombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY2FzZSBwc2sgezxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEu MGluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgaWYtZmVhdHVyZSBwc2stYXV0aDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO3VzZXMmbmJzcDtrczpsb2NhbC1vci1rZXlzdG9yZS1zeW1tZXRyaWMta2V5LWdyb3VwaW5n OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDoxLjBpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPkJldHRlciEgJm5ic3A7 VGhpcyB1c2VzIHRoZSBleGlzdGluZyBncm91cGluZ3MgKGUuZy4sJm5ic3A7a3M6bG9jYWwtb3It a2V5c3RvcmUtYXN5bW1ldHJpYy1rZXktZ3JvdXBpbmcpIHdoZXJlYXMgdGhlIGFib3ZlIHByb3Bv c2FsIGRlZmluZWQgbmV3IG9uZXMuICZuYnNwOyhzZWUgR2l0SHViIGZvciBsYXRlc3QgZmlsZXMs IHRob3VnaCB0aGUgY29tbWl0IGlzIGxhcmdlciB0aGFuIGl0IHNob3VsZA0KIGJlKTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjEuMGluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+SGVuaywgd2hhdCBkbyB5 b3UgdGhpbms/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGlu Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPkkgYXNzdW1lIHRo ZXNlIGZlYXR1cmVzIHdvdWxkIHRoZW4gbmVlZCB0byBiZSBkZWZpbmVkIGluIHRoZSBUTFMgY2xp ZW50L3NlcnZlciBkcmFmdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MS4waW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj5ZZXMuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MS4waW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdp bi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjEuMGluIj4NCjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj5QUzogbm9uZSBvZiB0aGlz IGdvZXMgdG8gdGhlIEZJWE1FIGluIHRoZSBpZXRmLWNyeXB0by10eXBlcy4gJm5ic3A7SSBoYWQg cHJldmlvdXNseSBhc2tlZCBIZW5rIHRvIHByb3ZpZGUgc29tZSB0ZXh0IGhlcmUgYXMgd2VsbCBi dXQsIGFwcGFyZW50bHksIGxpa2UgYWxsIG9mIHVzIGF0IHRoaXMgdGltZSwgaGUncyBiZWVuIGJ1 c3khPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjEuMGluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXYgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPiZuYnNwO3Bzazog Z2l2ZW4gdGhhdCB0aGUgYXN5bW1ldHJpYyBrZXlzIHdpdGhvdXQgY2VydHMgd2VyZSBjb3ZlcmVk IGJ5IGhvc3Qga2V5cyBhbmQgcmF3IHB1YmxpYyBrZXlzLCBJIHRoaW5rIHBzayBzaG91bGQgb25s eSBiZSBzeW1tZXRyaWMga2V5cy4gU3ltbWV0cmljIGtleXMgYXJlIHRoZW4gc2Vuc2l0aXZlL3Nl Y3JldCBkYXRhIGFuZCBhcyBzdWNoIEkgYmVsaWV2ZSB0aGV5DQogc2hvdWxkIG9ubHkgYmUgcmVm ZXJlbmNlZCBmcm9tIGtleXN0b3JlLiBTZWVpbmcgdGhlbSBpbiB0cnVzdHN0b3JlIHdhcyB1bmV4 cGVjdGVkIGZvciBtZS4gV2hlbiBpdCBjb21lcyB0byB0aGVpciB1c2UsIGNsaWVudHMgYW5kIHNl cnZlcnMgc2hvdWxkIGJlIGV4dGVuZGVkIHdpdGggZm9sbG93aW5nIGNvbmZpZ3VyYXRpb24gKGFu ZCBJIGFzc3VtZSB3ZSB0YWxrIG9mIFRMUyBjbGllbnRzIGFuZCBzZXJ2ZXJzIG9ubHkpOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+PHNwYW4gY2xhc3M9ImFwcGxlLXRh Yi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPiZuYnNwOyAmbmJzcDsmbmJz cDtjb250YWluZXImbmJzcDsmbHQ7Y2xpZW50LWlkZW50aXR5Jm5ic3A7b3ImbmJzcDtzZXJ2ZXIt aWRlbnRpdHkmZ3Q7Jm5ic3A7ezxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPiZuYnNwOyAmbmJzcDsgJm5ic3A7IGNob2ljZSBh dXRoLXR5cGUgezxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPjxzcGFuIGNsYXNzPSJhcHBs ZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4mbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7dXNlcyZuYnNwO2tzOmxvY2FsLW9yLWtleXN0b3JlLWVuZC1l bnRpdHktY2VydC13aXRoLWtleS1ncm91cGluZzs8YnI+DQo8c3BhbiBjbGFzcz0iYXBwbGUtdGFi LXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO3VzZXMmbmJzcDtrczpsb2NhbC1vci1rZXlzdG9yZS1hc3ltbWV0cmlj LWtleS1ncm91cGluZzs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7dXNlcyZuYnNwO2tzOjxpPmxvY2FsLW9yLWtleXN0b3JlLXN5bW1ldHJpYy1rZXktZ3Jv dXBpbmc8L2k+OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPGRp diBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MS4waW4iPkxhdHRlciBncm91cGluZyB3b3VsZCBiZSBhIG5ldyBvbmUsIGJ1 dCBpdCB3b3VsZCB1c2UgZXhpc3RpbmcgY29uc3RydWN0cyBhbmQgdGVybXMgZnJvbSBrZXlzdG9y ZS4gSSBkb27igJl0IHRoaW5rIHdlIG5lZWQgbmV3IG9uZXMuIFNlbGVjdGVkIGNpcGhlciBzdWl0 ZXMgd2lsbCBuZWVkIHRvIGhhdmUgUFNLIGluIHRoZW0gZm9yIHVzaW5nIHN5bW1ldHJpYyBrZXkg KHNpbWlsYXINCiBtYXRjaCBuZWVkZWQgZm9yIHRoZSBvdGhlcnMpLiBOb3RlIHRoYXQgc3ltbWV0 cmljIGtleXMgY2FuIGJlIHVzZWQgZm9yIG90aGVyIGNhc2VzIHRoYW4gVExTIFBTSywgZm9yIGV4 YW1wbGUgU05NUHYzIFVTTS4gQWdhaW4sIGZlYXR1cmVzIHdvdWxkIGJlIG5lY2Vzc2FyeSAodGhv c2UgY291bGQgYmUgc2F5aW5nIHguNTA5IG9yIHJhdy1wdWJsaWMta2V5IG9yIHBzaykuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjEuMGluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+Q29ycmVjdCwgSSBzYWlkIHRoZSBz YW1lICh0aGF0IFBTS3MgYXJlIGVzc2VudGlhbGx5IHN5bW1ldHJpYyBrZXlzKSBiZWZvcmUgYXMg d2VsbC4gJm5ic3A7UmVnYXJkaW5nIG9ubHkgYmVpbmcgcmVmZXJlbmNlZCB0byBrZXlzdG9yZSwg d2h5IG5vdCBhbHNvIHN1cHBvcnQgdGhlbSBiZWluZyBsb2NhbC1kZWZpbml0aW9ucyB0b28/ICZu YnNwO0NlcnRhaW5seSBub3QgYSBwcm9ibGVtDQogaWYgZW5jcnlwdGVkIGFuZCwgZXZlbiB3aGVu IG5vdCBlbmNyeXB0ZWQsIHRoZW4gdGhleSBjYW4gYmUgJnF1b3Q7cHJvdGVjdGVkJnF1b3Q7IGJ5 IE5BQ00tbGlrZSBtZWNoYW5pc21zLCByaWdodD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MS4waW4iPkJhbGF6cyZndDsgTG9jYWwgZGVmaW5pdGlvbnMgYXJlIG9r IHRvbyB0aGF04oCZcyB3aHkgSSB1c2VkIGEgaHlwb3RoZXRpY2FsIGdyb3VwaW5nIG5hbWUgJm5i c3A7a3M6PGI+PGk+bG9jYWw8L2k+PC9iPjxpPi1vci1rZXlzdG9yZS1zeW1tZXRyaWMta2V5LWdy b3VwaW5nLjwvaT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MS4waW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj5Tb3JyeSwgSSBnbG9zc2VkIG92ZXIg dGhlICZxdW90O2xvY2FsLSZxdW90OyBwcmVmaXggaW4geW91ciBlYXJsaWVyIHN0YXRlbWVudC48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDoxLjBpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPkkgYWdyZWUg dGhhdCBQU0tzIHNob3VsZCBiZSBpbiBLZXlzdG9yZSB3aGVuIHVzZWQgZm9yIGNsaWVudC1pZGVu dGl0eS9zZXJ2ZXItaWRlbnRpdHkgbm9kZXMuLi4gKG1vcmUgYmVsb3cpPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MS4waW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj4mbmJzcDsgV2h5 IHdhcy9pcyBzZWVpbmcgdGhlbSBpbiB0cnVzdHN0b3JlIGEgc3VycHJpc2UsIHBlcmhhcHMgYmVj YXVzZSB0aGV5J3JlIG5vdCBlbmNyeXB0YWJsZSB0aGVyZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPkJhbGF6cyZndDsgV2hlbiBQU0tzIGFyZSB1c2Vk IHRoZW4gYm90aCBjb21tdW5pY2F0aW5nIGVuZHMgdXNlIHRoZSBzaGFyZWQga2V5IGZvciBzaWdu aW5nIGFuZCB2ZXJpZnlpbmcgbWVzc2FnZXMuIFRoZW4gb25lIGNvbmZpZ3VyYXRpb24gc2VlbXMg ZW5vdWdoIHRoYXQgaXMgZWl0aGVyIGxvY2FsIG9yIGZyb20ga2V5c3RvcmUsIHdoeSB3b3VsZCBp dCBiZSBuZWNlc3NhcnkNCiB0byBzZXQgaXQgdXAgeWV0IGFub3RoZXIgdGltZSBmb3IgdmVyaWZp Y2F0aW9uIGZyb20gbG9jYWwgb3IgdHJ1c3RzdG9yZT8gVGhpcyB3b3VsZCBtZWFuIHRoZXJlIGlz IG5vIG5lZWQgZm9yIGEgUFNLIG9wdGlvbiB3aGVuIGNvbmZpZ3VyaW5nIGhvdyB0byAmbmJzcDt2 ZXJpZnkgdGhlIHBlZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjEuMGluIj5jb250YWluZXImbmJzcDsmbHQ7Y2xpZW50LWF1dGhlbnRpY2F0aW9uJm5ic3A7b3Im bmJzcDtzZXJ2ZXItYXV0aGVudGljYXRpb24mZ3Q7Jm5ic3A7ezxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGlu Ij4mbmJzcDsmbmJzcDsmbmJzcDsgY2hvaWNlIGF1dGgtdHlwZSB7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4w aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDttYW5kYXRvcnkg dHJ1ZTs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGNhc2UgY2VydGlmaWNhdGUgezxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgaWYtZmVhdHVyZSB4NTA5LWNlcnRpZmljYXRlLWF1dGg7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4w aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBjb250YWluZXIgY2EtY2VydHMgezxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsm bmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dXNlcyB0czpsb2NhbC1vci10cnVzdHN0b3JlLWNl cnRzLWdyb3VwaW5nPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjEuMGluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgY29udGFpbmVyIHNlcnZlci1jZXJ0cyB7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt1c2VzIHRzOmxvY2FsLW9yLXRy dXN0c3RvcmUtY2VydHMtZ3JvdXBpbmc8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MS4waW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB9PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBjYXNlIHJhdy1wdWJsaWMta2V5IHs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGlmLWZlYXR1cmUgcmF3LXB1YmxpYy1rZXktYXV0aDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBp biI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3VzZXMmbmJzcDtrczogbG9jYWwt b3ItdHJ1c3RzdG9yZS1yYXctcHViLWtleXMtZ3JvdXBpbmc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6MS4w aW4iPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08YnI+DQo8YnI+DQo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDoxLjBpbiI+Tm8gbmVlZCBmb3IgUFNLIGNvbmZpZyBzaW5jZSBpdCBpcyBh bHJlYWR5IGNvbmZpZ3VyZWQgaW4gY2xpZW50L3NlcnZlci1pZGVudGl0eS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjEuMGluIj5BY2suICZuYnNwOyAoc2VlIEdpdEh1YiBmb3IgbGF0ZXN0IGZpbGVzLCB0aG91 Z2ggdGhlIGNvbW1pdCBpcyBsYXJnZXIgdGhhbiBpdCBzaG91bGQgYmUpPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MS4waW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj5BbmQsIGFzIGEgYm9udXMsIEtleXN0 b3JlIGFscmVhZHkgZGVmaW5lcyBzdXBwb3J0IGZvciBlbmNyeXB0aW9uICh1bmxpa2UgVHJ1c3Rz dG9yZSkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJn aW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjEuMGluIj4NCjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPiZuYnNwO09yIHdoYXQgaXMgdGhlIHJl YXNvbmluZyB3aHkgaXQgaXMgbmVjZXNzYXJ5IHRvIGNvbmZpZ3VyZSBhIFBTSyBmcm9tIHRydXN0 c3RvcmU/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGlu Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+U29tZWhvdyBJIHRob3VnaHQgdGhhdCB3ZXJl IGJlaW5nIHVzZWQgaW4gY29uY2VwdHVhbGx5IGRpZmZlcmVudCB3YXlzLCBidXQgSSBzZWUgbm93 IHRoYXQncyBub3QgcmVhbGx5IHRoZSBjYXNlLi4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+VGhhbmsg eW91LCBCYWxhenMsIHRoaXMgbWVzc2FnZSB3YXMgbW9zdCBoZWxwZnVsISAmbmJzcDsmbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDoxLjBpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPktlbnQgLy8g Y29udHJpYnV0b3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4w aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_AM0PR07MB518797EFBA3FBF42F9B1C1D6834C0AM0PR07MB5187eurp_-- From nobody Tue Nov 19 03:28:01 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4CF12091B; Tue, 19 Nov 2019 03:27:55 -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 8s8fwZ4oxrZL; Tue, 19 Nov 2019 03:27:52 -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 B2F5D12086E; Tue, 19 Nov 2019 03:27:52 -0800 (PST) Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 33E0ECB7DB9DA0B4AB63; Tue, 19 Nov 2019 11:27:51 +0000 (GMT) Received: from lhreml713-chm.china.huawei.com (10.201.108.64) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 19 Nov 2019 11:27:50 +0000 Received: from lhreml713-chm.china.huawei.com (10.201.108.64) by lhreml713-chm.china.huawei.com (10.201.108.64) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 19 Nov 2019 11:27:50 +0000 Received: from DGGEML424-HUB.china.huawei.com (10.1.199.41) by lhreml713-chm.china.huawei.com (10.201.108.64) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Tue, 19 Nov 2019 11:27:50 +0000 Received: from DGGEML511-MBX.china.huawei.com ([169.254.1.41]) by dggeml424-hub.china.huawei.com ([10.1.199.41]) with mapi id 14.03.0439.000; Tue, 19 Nov 2019 19:27:45 +0800 From: Qin Wu To: "netmod@ietf.org" , "netconf@ietf.org" , "opsawg@ietf.org" Thread-Topic: IETF YANG Side meeting on YANG Use Cases Thread-Index: AdWezIPD97i+gpdvQc+ol1zLtLScyQ== Date: Tue, 19 Nov 2019 11:27:44 +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.52.34.60] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAA945DC8Edggeml511mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [netconf] IETF YANG Side meeting on YANG Use Cases 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, 19 Nov 2019 11:27:55 -0000 --_000_B8F9A780D330094D99AF023C5877DABAA945DC8Edggeml511mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Folks: Continuing the last IETF side meeting on Next step of IETF YANG (which is n= ot targeted YANG modeling language discussion), we would like to have anoth= er YANG side meeting (https://trac.ietf.org/trac/ietf/meeting/wiki/106sidem= eetings) to investigate on some use cases to see how IETF YANG model intera= ct with other model or Mechanisms. How IETF YANG are put together to delive= r service. The meeting time is: Wednesday afternoon 4:30~5:30 The meeting room is : Bras Basah Feel free to join the discussion. Thanks! -Qin Wu --_000_B8F9A780D330094D99AF023C5877DABAA945DC8Edggeml511mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, = Folks:

Cont= inuing the last IETF side meeting on Next step of IETF YANG (which is not t= argeted YANG modeling language discussion), we would like to have another YANG side meeting (https://trac.ietf.org/tra= c/ietf/meeting/wiki/106sidemeetings) to investigate on some use cases to se= e how IETF YANG model interact with other model or Mechanisms. How IETF YAN= G are put together to deliver service.

The = meeting time is: Wednesday afternoon 4:30~5:30

The = meeting room is : Bras Basah

Feel= free to join the discussion. Thanks!

-Qin= Wu

--_000_B8F9A780D330094D99AF023C5877DABAA945DC8Edggeml511mbxchi_-- From nobody Tue Nov 19 07:18:56 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34B9C12092C for ; Tue, 19 Nov 2019 07:18:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_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 CsafREaDTDst for ; Tue, 19 Nov 2019 07:18:53 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7543C1200C4 for ; Tue, 19 Nov 2019 07:18:53 -0800 (PST) Received: from localhost (h-4-44.A165.priv.bahnhof.se [158.174.4.44]) by mail.tail-f.com (Postfix) with ESMTPSA id 986801AE018B for ; Tue, 19 Nov 2019 16:18:51 +0100 (CET) Date: Tue, 19 Nov 2019 16:18:51 +0100 (CET) Message-Id: <20191119.161851.678459934233941550.mbj@tail-f.com> To: 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-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, 19 Nov 2019 15:18:55 -0000 Hi, [What is the process when we have github issues? I thought that github would be used to track them, but discussion would be on the ML?. Right now I simply reply to the email I got. Don't know where it will end up.] [Turns out it didn't go to the ML, hence this email!] Mahesh Jethanandani 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. 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. > Also no comments/objections were received on keeping the node > 'receiver' as 'receiver' You are right that the namespace ensures that there won't be a conflict, but I think that the node names should be descriptive by themselves. The namespace / module name is there to ensure uniqueness, but the model will be easier to understand and use if the node names are descriptive. Note that it is quite common that implementations use these models to render CLIs as well. Do you think that the model will be worse if we make the suggested changes? /martin From nobody Tue Nov 19 07:57:23 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DED0120959 for ; Tue, 19 Nov 2019 07:57:22 -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, SPF_HELO_NONE=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 dt-rd6MX9eFE for ; Tue, 19 Nov 2019 07:57:20 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 334871208FF for ; Tue, 19 Nov 2019 07:57:20 -0800 (PST) Received: from localhost (h-4-44.A165.priv.bahnhof.se [158.174.4.44]) by mail.tail-f.com (Postfix) with ESMTPSA id A1DD01AE018B for ; Tue, 19 Nov 2019 16:57:18 +0100 (CET) Date: Tue, 19 Nov 2019 16:57:18 +0100 (CET) Message-Id: <20191119.165718.454243308165476160.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund 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: [netconf] issue #2 draft-ietf-netconf-https-notif (discover capabilities) 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, 19 Nov 2019 15:57:22 -0000 Hi, For the encoding I think we have four options: 1) define one fixed encoding 2) support multiple encodings and let the identity https derive from sn:configurable-encoding. this ties into the mechanism defined in RFC 8529. requires a "default encoding". 3) support multiple encodings and do not derive from sn:configurable-encoding. define a discovery mechanism that must be used to dynamically figure out which encoding to use. 4) combination of 2+3; make it configurable, but let the default encoding be dynamic I think it is quite clear that we don't want to do 1. People have expressed requirements for both text-based and binary encodings. To discover the encoding, isn't this possible with standard HTTP? Googling a bit showed an old I-D for an Accept-Post header that the server could return in response to OPTIONS; this could have been useful. (Hmm, it seems it is actually defined:https://www.iana.org/assignments/message-headers/message-headers.xhtml) Perhaps someone with HTTP knowledge can recommend a solution? As for the format of capabilities in general, I think a normal config false YANG model will work. If we use OPTIONS (or GET on some related uri) the client can send an Accept header to indicate which format it prefers for this config false data as usual ("application/yang-data+xml" or "application/yang-data+json" or some other media type for binary formats) /martin From nobody Tue Nov 19 16:04:37 2019 Return-Path: <0100016e861feb64-15823aa8-a77c-40ed-9e4c-2393f71e7465-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 E5BD112008C for ; Tue, 19 Nov 2019 16:04:34 -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 9rj-UqFmmD-M for ; Tue, 19 Nov 2019 16:04:32 -0800 (PST) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48D2D12018B for ; Tue, 19 Nov 2019 16:04:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1574208269; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=dwN6WwLSyLk9zbmr7UG4euVj/bDpfUZYQWH/Lz62peE=; b=Xa6qxwW6YpdFL97ou06MjuzqZFURNaTFLP7IOtXhl4Aw/djB0+ajcd3mf7KCexzA di/y3quS34W9lbkIyIk61rHJYtz08i4c/16thnjBXKF5HKkNCiUlNltqmkpL6RiuyiP fj1yjL4Kd1OM7ydXUNkmC3su4tHrKW74XJ5c8GGA= From: Kent Watsen Message-ID: <0100016e861feb64-15823aa8-a77c-40ed-9e4c-2393f71e7465-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_ED47AEFD-10A1-4547-B9E7-0A166289A4B2" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 20 Nov 2019 00:04:29 +0000 In-Reply-To: Cc: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= , "netconf@ietf.org" To: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= References: <0100016e3ed10fbb-8a5a44a9-6df6-4ac1-9b56-8dbf61ec64cc-000000@email.amazonses.com> <0100016e586dbe79-24514978-922b-479b-a523-3d2bbcdc56c4-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.11.20-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] FIXMEs in ietf-crypto-types and client/server models 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, 20 Nov 2019 00:04:35 -0000 --Apple-Mail=_ED47AEFD-10A1-4547-B9E7-0A166289A4B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Balazs, > I had a look at your changes related to our discussion. In general it = looks good! Excellent. > > Do we need the if-feature in case of this empty case? Is the empty = case ok in general? Yes, I added a feature statement to my local copy. > =20 > Was the marked line left over as a mistake after a copy from = local-or-truststore-certs-grouping? Yes, that was a mistake. Thanks for catching it! Kent // contributor --Apple-Mail=_ED47AEFD-10A1-4547-B9E7-0A166289A4B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Balazs,

I had a look at your changes related to our discussion. In = general it looks good!

Excellent.


<snip>
Do we need the if-feature in case of this empty case? = Is the empty case ok in general?

Yes, I added a feature statement to my local = copy.


<snip> 
Was the marked line left over as a mistake after a copy from = local-or-truststore-certs-grouping?

Yes, that was a mistake.  Thanks for catching = it!



Kent // contributor


= --Apple-Mail=_ED47AEFD-10A1-4547-B9E7-0A166289A4B2-- From nobody Wed Nov 20 01:33:23 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A34E120AC6 for ; Wed, 20 Nov 2019 01:33:22 -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, SPF_HELO_NONE=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 q8gkK2AkOpFP for ; Wed, 20 Nov 2019 01:33:21 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E877012009C for ; Wed, 20 Nov 2019 01:33:20 -0800 (PST) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 3E5F31AE0310 for ; Wed, 20 Nov 2019 10:33:19 +0100 (CET) Date: Wed, 20 Nov 2019 10:28:45 +0100 (CET) Message-Id: <20191120.102845.955854796704587579.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund In-Reply-To: <20191119.165718.454243308165476160.mbj@tail-f.com> References: <20191119.165718.454243308165476160.mbj@tail-f.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] issue #2 draft-ietf-netconf-https-notif (discover capabilities) 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, 20 Nov 2019 09:33:22 -0000 Martin Bjorklund wrote: > Hi, > > For the encoding I think we have four options: > > 1) define one fixed encoding > > 2) support multiple encodings and let the identity https derive from > sn:configurable-encoding. this ties into the mechanism defined in > RFC 8529. requires a "default encoding". > > 3) support multiple encodings and do not derive from > sn:configurable-encoding. define a discovery mechanism that must > be used to dynamically figure out which encoding to use. > > 4) combination of 2+3; make it configurable, but let the default > encoding be dynamic > > > I think it is quite clear that we don't want to do 1. People have > expressed requirements for both text-based and binary encodings. > > To discover the encoding, isn't this possible with standard HTTP? > Googling a bit showed an old I-D for an Accept-Post header that the > server could return in response to OPTIONS; this could have been > useful. (Hmm, it seems it is actually > defined:https://www.iana.org/assignments/message-headers/message-headers.xhtml) > Perhaps someone with HTTP knowledge can recommend a solution? > > As for the format of capabilities in general, I think a normal config > false YANG model will work. Sorry, this should be sx:structure. > If we use OPTIONS (or GET on some related > uri) the client can send an Accept header to indicate which format it > prefers for this config false data as usual > ("application/yang-data+xml" or "application/yang-data+json" or some > other media type for binary formats) /martin From nobody Wed Nov 20 10:18:09 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF065120906; Wed, 20 Nov 2019 10:18:07 -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.110.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <157427388788.30578.1364419881913994240@ietfa.amsl.com> Date: Wed, 20 Nov 2019 10:18:07 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-http-client-server-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2019 18:18:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : YANG Groupings for HTTP Clients and HTTP Servers Author : Kent Watsen Filename : draft-ietf-netconf-http-client-server-00.txt Pages : 19 Date : 2019-11-20 Abstract: This document defines two YANG modules: the first defines a grouping for configuring a generic HTTP client, and the second defines a grouping for configuring a generic HTTP server. It is intended that these groupings will be used by applications using the HTTP protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-http-client-server/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-http-client-server-00 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-http-client-server-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 20 10:21:29 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1841B12007C; Wed, 20 Nov 2019 10:21:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.110.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <157427408302.30634.18226437734757333472@ietfa.amsl.com> Date: Wed, 20 Nov 2019 10:21:23 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-crypto-types-13.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2019 18:21:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : Common YANG Data Types for Cryptography Authors : Kent Watsen Wang Haiguang Filename : draft-ietf-netconf-crypto-types-13.txt Pages : 54 Date : 2019-11-20 Abstract: This document defines four YANG modules for types useful to cryptographic applications. The modules defined include: o ietf-crypto-types o iana-symmetric-algs o iana-asymmetric-algs o iana-hash-algs The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-crypto-types/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-13 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-crypto-types-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-crypto-types-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 20 10:34:56 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C066E12006D; Wed, 20 Nov 2019 10:34: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.110.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <157427488971.30550.14896478334458805818@ietfa.amsl.com> Date: Wed, 20 Nov 2019 10:34:49 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-trust-anchors-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2019 18:34: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 : A YANG Data Model for a Truststore Author : Kent Watsen Filename : draft-ietf-netconf-trust-anchors-08.txt Pages : 21 Date : 2019-11-20 Abstract: This document defines a YANG 1.1 data model for configuring global sets of X.509 certificates, SSH host-keys, raw public keys, and PSKs (pairwise-symmetric or pre-shared keys) that can be referenced by other data models for trust. While the SSH host-keys are uniquely for the SSH protocol, certificates, raw public keys, and PSKs may have multiple uses, including authenticating protocol peers and verifying signatures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-trust-anchors/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-08 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-trust-anchors-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-trust-anchors-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 20 10:35:42 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBA512007C; Wed, 20 Nov 2019 10:35:36 -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.110.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <157427493628.30532.1462416188762341938@ietfa.amsl.com> Date: Wed, 20 Nov 2019 10:35:36 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-keystore-15.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2019 18:35:36 -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 : A YANG Data Model for a Keystore Author : Kent Watsen Filename : draft-ietf-netconf-keystore-15.txt Pages : 40 Date : 2019-11-20 Abstract: This document defines a YANG 1.1 module called "ietf-keystore" that enables centralized configuration of both symmetric and asymmetric keys. The secret value for both key types may be encrypted. Asymmetric keys may be associated with certificates. Notifications are sent when certificates are about to expire. Editorial Note (To be removed by RFC Editor) This draft contains many placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: o "AAAA" --> the assigned RFC value for [I-D.ietf-netconf-crypto-types]. o "XXXX" --> the assigned RFC value for this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: o "2019-11-20" --> the publication date of this draft The following Appendix section is to be removed prior to publication: o Appendix A. Change Log The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-keystore/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-keystore-15 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-keystore-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-keystore-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 20 10:43:33 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D78120945; Wed, 20 Nov 2019 10:43:32 -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.110.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <157427541234.30566.10542406711184888663@ietfa.amsl.com> Date: Wed, 20 Nov 2019 10:43:32 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-ssh-client-server-17.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2019 18:43:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : YANG Groupings for SSH Clients and SSH Servers Authors : Kent Watsen Gary Wu Liang Xia Filename : draft-ietf-netconf-ssh-client-server-17.txt Pages : 49 Date : 2019-11-20 Abstract: This document defines three YANG modules: the first defines groupings for a generic SSH client, the second defines groupings for a generic SSH server, and the third defines common identities and groupings used by both the client and the server. It is intended that these groupings will be used by applications using the SSH protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-ssh-client-server/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server-17 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-ssh-client-server-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-ssh-client-server-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 20 10:53:24 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E7826120020; Wed, 20 Nov 2019 10:53:22 -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.110.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <157427600287.30491.3168877750286938128@ietfa.amsl.com> Date: Wed, 20 Nov 2019 10:53:22 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-tls-client-server-17.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2019 18:53:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : YANG Groupings for TLS Clients and TLS Servers Authors : Kent Watsen Gary Wu Liang Xia Filename : draft-ietf-netconf-tls-client-server-17.txt Pages : 50 Date : 2019-11-20 Abstract: This document defines three YANG modules: the first defines groupings for a generic TLS client, the second defines groupings for a generic TLS server, and the third defines common identities and groupings used by both the client and the server. It is intended that these groupings will be used by applications using the TLS protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-tls-client-server/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-17 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-tls-client-server-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-tls-client-server-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 20 10:54:24 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C21B71200B2; Wed, 20 Nov 2019 10:54:22 -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.110.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <157427606272.30610.4918012294793502879@ietfa.amsl.com> Date: Wed, 20 Nov 2019 10:54:22 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-http-client-server-01.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2019 18:54:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : YANG Groupings for HTTP Clients and HTTP Servers Author : Kent Watsen Filename : draft-ietf-netconf-http-client-server-01.txt Pages : 16 Date : 2019-11-20 Abstract: This document defines two YANG modules: the first defines a minimal grouping for configuring an HTTP client, and the second defines a minimal grouping for configuring an HTTP server. It is intended that these groupings will be used to help define the configuration for simple HTTP-based protocols (not for complete webservers or browsers). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-http-client-server/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-http-client-server-01 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-http-client-server-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-http-client-server-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 20 10:55:39 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 611FF120142; Wed, 20 Nov 2019 10:55:37 -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.110.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <157427613733.30495.12361298726608453868@ietfa.amsl.com> Date: Wed, 20 Nov 2019 10:55:37 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-netconf-client-server-17.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2019 18:55:37 -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 : NETCONF Client and Server Models Author : Kent Watsen Filename : draft-ietf-netconf-netconf-client-server-17.txt Pages : 93 Date : 2019-11-20 Abstract: This document defines two YANG modules, one module to configure a NETCONF client and the other module to configure a NETCONF server. Both modules support both the SSH and TLS transport protocols, and support both standard NETCONF and NETCONF Call Home connections. Editorial Note (To be removed by RFC Editor) This draft contains many placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. This document contains references to other drafts in progress, both in the Normative References section, as well as in body text throughout. Please update the following references to reflect their final RFC assignments: o I-D.ietf-netconf-keystore o I-D.ietf-netconf-tcp-client-server o I-D.ietf-netconf-ssh-client-server o I-D.ietf-netconf-tls-client-server Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: o "XXXX" --> the assigned RFC value for this draft o "AAAA" --> the assigned RFC value for I-D.ietf-netconf-tcp-client- server o "YYYY" --> the assigned RFC value for I-D.ietf-netconf-ssh-client- server o "ZZZZ" --> the assigned RFC value for I-D.ietf-netconf-tls-client- server Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: o "2019-11-20" --> the publication date of this draft The following Appendix section is to be removed prior to publication: o Appendix B. Change Log The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-netconf-client-server/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-17 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-netconf-client-server-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-netconf-client-server-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 20 10:56:48 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB4FE1208BB; Wed, 20 Nov 2019 10:56:41 -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.110.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <157427620185.30554.15677751175798382776@ietfa.amsl.com> Date: Wed, 20 Nov 2019 10:56:41 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-restconf-client-server-17.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2019 18:56:42 -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 : RESTCONF Client and Server Models Author : Kent Watsen Filename : draft-ietf-netconf-restconf-client-server-17.txt Pages : 84 Date : 2019-11-20 Abstract: This document defines two YANG modules, one module to configure a RESTCONF client and the other module to configure a RESTCONF server. Both modules support the TLS transport protocol with both standard RESTCONF and RESTCONF Call Home connections. Editorial Note (To be removed by RFC Editor) This draft contains many placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. This document contains references to other drafts in progress, both in the Normative References section, as well as in body text throughout. Please update the following references to reflect their final RFC assignments: o I-D.ietf-netconf-keystore o I-D.ietf-netconf-tcp-client-server o I-D.ietf-netconf-tls-client-server o I-D.ietf-netconf-http-client-server Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: o "XXXX" --> the assigned RFC value for this draft o "AAAA" --> the assigned RFC value for I-D.ietf-netconf-tcp-client- server o "BBBB" --> the assigned RFC value for I-D.ietf-netconf-tls-client- server o "CCCC" --> the assigned RFC value for I-D.ietf-netconf-http- client-server Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: o "2019-11-20" --> the publication date of this draft The following Appendix section is to be removed prior to publication: o Appendix B. Change Log The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-client-server/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server-17 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-restconf-client-server-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-restconf-client-server-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 20 12:26:37 2019 Return-Path: <0100016e8a7ebfef-d490b1b8-f55b-45f9-885c-b5bf1d90ec7f-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 7EAFE120112 for ; Wed, 20 Nov 2019 12:26:36 -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 HIZeGXv2bV69 for ; Wed, 20 Nov 2019 12:26:35 -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 98CF5120113 for ; Wed, 20 Nov 2019 12:26:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1574281593; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=Aa4DCzHoPXTZapeJYl8iICGKWvzvxgOC8KFHr/oRtRs=; b=EYWme71XHrNhZ3RKmPsbt0aXtzEi+VYTOZyA3K64V2lt3V+5A4PMEArch5UReSz9 kplluo2kKk6rjhKd9W0080XhczaIqOwVcRUwqRME130fQ5fv6bnKlxXxV2hGXVf7SU1 sQKnktmgdsMKQRI1GWLF0EmiEla+0DapuIMG8xgc= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_7180A08F-BE6D-43FC-9F2F-F67387E2BD57" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-ID: <0100016e8a7ebfef-d490b1b8-f55b-45f9-885c-b5bf1d90ec7f-000000@email.amazonses.com> Date: Wed, 20 Nov 2019 20:26:33 +0000 To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.11.20-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] updates to client/server suite of drafts 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, 20 Nov 2019 20:26:36 -0000 --Apple-Mail=_7180A08F-BE6D-43FC-9F2F-F67387E2BD57 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I just pushed an update to all the client/server drafts (except TCP). = Below is the change log entry for each draft. The most noteworthy update is that the http-01 update should (hopefully) = resolve the concerns raised by the httpbis chairs. The biggest non-update is that the "config false" algs-supported lists = were NOT moved from crypto-types to the ssh/tls drafts, only because I = ran out of time (and I'm hoping that my co-authors all do it). There are still number of FIXME's remaining in the drafts. Kent // contributor crypto-types: - Added the four features: "[encrypted-]one-[a]symmetric-key- format", each protecting a 'key-format' identity of the same name. - Added 'must' expressions asserting that the 'key-format' leaf exists whenever a non-hidden key is specified. - Improved the 'description' statements and added 'reference' statements for the 'key-format' identities. - Added a questionable forward reference to "encrypted-*" leafs in a couple 'when' expressions. truststore: - Added new "Support for Built-in Trust Anchors" section. - Removed spurious "uses ct:trust-anchor-certs-grouping" line. keystore: - Added new "Support for Built-in Trust Anchors" section. - Added 'must' expressions asserting that the 'key-format' leaf whenever an encrypted key is specified. tcp-client-server: - No update ssh-client-server: - Removed choice local-or-external by removing the 'external' case and flattening the 'local' case and adding a "client-auth-config- supported" feature. - Updated examples to include the "*-key-format" nodes. - Augmented-in "must" expressions ensuring that locally-defined public-key-format are "ct:ssh-public-key-format" (must expr for ref'ed keys are TBD). tls-client-server: - Removed choice local-or-external by removing the 'external' case and flattening the 'local' case and adding a "client-auth-config- supported" feature. - Removed choice required-or-optional. - Updated examples to include the "*-key-format" nodes. - Augmented-in "must" expressions ensuring that locally-defined public-key-format are "ct:ssh-public-key-format" (must expr for ref'ed keys are TBD). http-client-server: - Modified Abstract and Intro to be more accurate wrt intended applicability. - In ietf-http-client, removed "protocol-version" and all auth schemes except "basic". - In ietf-http-client, factored out "client-identity-grouping" for proxy connections. - In ietf-http-server, removed "choice required-or-optional" and "choice local-or-external". - In ietf-http-server, moved the basic auth under a "choice auth- type" limited by new "feature basic-auth". netconf-client-server: - Updated examples to include the "*-key-format" nodes. - Updated examples to remove the "required" nodes. - Updated examples to remove the "client-auth-defined-elsewhere" nodes. restconf-client-server: - Updated examples to include the "*-key-format" nodes. - Updated examples to remove the "required" nodes. --Apple-Mail=_7180A08F-BE6D-43FC-9F2F-F67387E2BD57 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = just pushed an update to all the client/server drafts (except = TCP).  Below is the change log entry for each draft.

The most noteworthy = update is that the http-01 update should (hopefully) resolve the = concerns raised by the httpbis chairs.

The biggest non-update is that the = "config false" algs-supported lists were NOT moved from crypto-types to = the ssh/tls drafts, only because I ran out of time (and I'm hoping that = my co-authors all do it).

There are still number of FIXME's remaining in the = drafts.

Kent = // contributor


crypto-types:
   -  Added the four features: = "[encrypted-]one-[a]symmetric-key-
    =   format", each protecting a 'key-format' identity of the same = name.
   -  Added 'must' expressions = asserting that the 'key-format' leaf
    =   exists whenever a non-hidden key is specified.
   -  Improved the 'description' = statements and added 'reference'
    =   statements for the 'key-format' identities.
   -  Added a questionable forward = reference to "encrypted-*" leafs in a
    =   couple 'when' expressions.

truststore:
   -  Added new "Support for Built-in = Trust Anchors" section.
   -  Removed = spurious "uses ct:trust-anchor-certs-grouping" line.


keystore:
  =  -  Added new "Support for Built-in Trust Anchors" = section.
   -  Added 'must' = expressions asserting that the 'key-format' leaf
  =     whenever an encrypted key is specified.


tcp-client-server:
  - No update


ssh-client-server:
   -  Removed choice local-or-external by = removing the 'external' case
      and = flattening the 'local' case and adding a "client-auth-config-
      supported" feature.
   -  Updated examples to include the = "*-key-format" nodes.
  =  -  Augmented-in "must" expressions ensuring that = locally-defined
    =   public-key-format are "ct:ssh-public-key-format" (must expr = for
      ref'ed keys are TBD).


tls-client-server:
   -  Removed choice local-or-external by = removing the 'external' case
      and = flattening the 'local' case and adding a "client-auth-config-
      supported" feature.
   -  Removed choice = required-or-optional.
   -  Updated = examples to include the "*-key-format" nodes.
  =  -  Augmented-in "must" expressions ensuring that = locally-defined
    =   public-key-format are "ct:ssh-public-key-format" (must expr = for
      ref'ed keys are TBD).


http-client-server:
   -  Modified Abstract and Intro to be = more accurate wrt intended
    =   applicability.
   -  In = ietf-http-client, removed "protocol-version" and all auth
      schemes except "basic".
   -  In ietf-http-client, factored out = "client-identity-grouping" for
    =   proxy connections.
  =  -  In ietf-http-server, removed "choice = required-or-optional" and
    =   "choice local-or-external".
  =  -  In ietf-http-server, moved the basic auth under a = "choice auth-
      type" limited by = new "feature basic-auth".


netconf-client-server:
   -  Updated examples to include the = "*-key-format" nodes.
   -  Updated = examples to remove the "required" nodes.
  =  -  Updated examples to remove the = "client-auth-defined-elsewhere"
    =   nodes.


restconf-client-server:
   -  Updated examples to include the = "*-key-format" nodes.
   -  Updated = examples to remove the "required" nodes.


= --Apple-Mail=_7180A08F-BE6D-43FC-9F2F-F67387E2BD57-- From nobody Thu Nov 21 02:12:18 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F15E120980 for ; Thu, 21 Nov 2019 02:12:17 -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 aj5rBll8rpz3 for ; Thu, 21 Nov 2019 02:12:15 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04on0629.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0c::629]) (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 262331208B0 for ; Thu, 21 Nov 2019 02:12:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=axAdcmNBmUQgy1kYNDStkauagVJXmvizPZl0jTf++MFJHB+mzDtAEb+XB13MXiKdMxkaBI5kxabmm1LjfC70kMXM1M4G8sLxfQNQjFdpeSDPzIwYqMcnBc2V1FBiT+bQzdUXHmSO8oVJFFgeUMt1JMgRrqrOfUrnltn5eakkUfvquxXaMn4aXInP4iEeIXn8jk1H8kjQ1Ob9gX05bykahoHlX3KGRWcM/SNeZvgWURgAR7JbXfFTyfk6932hSInskJzhoNy2dwy88qC1FIqzo/Qi9WYJbjlh3/04L4HkoZ/GqvtkVa5YXglzuCu1hs0Q9voT6IUmETpWYQ+dhpld6A== 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=g59syyh8FNQJZvYqkgtvoEMgHIfMxoSQ9PgNTVsJDxw=; b=RCwUjW5+R4J0FAadjutZDRjIlCg7AFsXb2UeZ9Kn8zbSjKgRnYz4mmkM/CYtaSDNgBPhUp8wBTuubP88wmMNzeBSpMqFZ7dRds9bknTi3LJ8XGgFCZI2i6L+vavDnZaBbHMcE7YD2c2xyoo1F4e8nO+WmSmux35jUFxLGZTI3EHt6bhJ4cww3zxN+xKeYUcd5q0nY67ljDHWM5d/MXDIoXsITIp2srrxq8sT29AEzZ7i7c822pQW1ExKc7mVz4iv/L9ds13Slkjc0ssOmsNEcNPfspP8s6aAJ2MQT1sjcp8YsSRQ2Rj4Zm6ZLI6SeViWerPnDRk7csKH1s0+IuwD5g== 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=g59syyh8FNQJZvYqkgtvoEMgHIfMxoSQ9PgNTVsJDxw=; b=GIZB2K6Ai9nLmRr2J4qPex5ySuD+H23qb6aVIb3SKB+WscK1Mf7tm+Karc9EuH26dDZYpTj7g/55EnEkGfzMLGq/wRHgA8nfqKtAKMpn4b7wVh94vHIJnSzG+jpyTPFf8U1QRObNMJJLb5BKwFBINxEGzHNgIFsxSWr98Ubwaa4= Received: from AM0PR07MB5187.eurprd07.prod.outlook.com (20.178.20.74) by AM0PR07MB5170.eurprd07.prod.outlook.com (20.178.17.206) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.12; Thu, 21 Nov 2019 10:12:11 +0000 Received: from AM0PR07MB5187.eurprd07.prod.outlook.com ([fe80::e485:83e7:ee62:53f8]) by AM0PR07MB5187.eurprd07.prod.outlook.com ([fe80::e485:83e7:ee62:53f8%5]) with mapi id 15.20.2495.010; Thu, 21 Nov 2019 10:12:11 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Kov=E1cs?= To: "netconf@ietf.org" , Kent Watsen Thread-Topic: [netconf] I-D Action: draft-ietf-netconf-trust-anchors-08.txt Thread-Index: AQHVn9FEIYmE0id0x0Sc0BE/mi1FhaeVZ70A Date: Thu, 21 Nov 2019 10:12:11 +0000 Message-ID: References: <157427488971.30550.14896478334458805818@ietfa.amsl.com> In-Reply-To: <157427488971.30550.14896478334458805818@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.kovacs@ericsson.com; x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9f4d4559-b346-4ff7-bcf7-08d76e6b4670 x-ms-traffictypediagnostic: AM0PR07MB5170: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0228DDDDD7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(366004)(39860400002)(376002)(136003)(396003)(54534003)(13464003)(199004)(189003)(7736002)(99286004)(305945005)(26005)(86362001)(186003)(229853002)(110136005)(52536014)(446003)(11346002)(5660300002)(66066001)(71190400001)(71200400001)(25786009)(6306002)(9686003)(966005)(7696005)(81156014)(81166006)(316002)(8676002)(33656002)(256004)(14454004)(4001150100001)(8936002)(55016002)(6246003)(2906002)(6116002)(53546011)(74316002)(3846002)(2501003)(6506007)(66946007)(76116006)(76176011)(66574012)(102836004)(66476007)(66556008)(64756008)(66446008)(6436002)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB5170; H:AM0PR07MB5187.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: eTI8zkZSKZgm0NS3X2s4NzdmjMks5hJ3i2+C6QTDA/anwZsSZZdbobvdopY2XnU7RBxvedN1ycpw1HifzmAtFPkhC7sk6n79/8X0YDpHM4l5er7kBp5dhmrFjO5gYTaR7Oh927uADSSmMWz+k2rlWMMw9ISUT7Pal+7TZQ0N2kOQYgiJcjFGlMlNg/OWrKz9QgcZZMdkEwyi56M7P2yDgxLDfFb1OPCNUiMQX5aBODN3ZDUij+bZfa9iv1GVGVMc3r35lyekeqlMc+H17YWneLmtig2wQm8Bq55PCywapfhwsldc7Wwh/LjlHz8eBSsaVWDGPMtzl1plJvExqztpU5Lwbi8HUyVJqKdL3Bt+DVMiqZF03Gh43NwjbLjLT8QtVFIMxp/YudEXJAkxKmFNvacH71oh2HICKwET90xB/Zxmdcm5tgcSTzcXfYbzKpD5iE+zkblZ3Z07niKR8tEwQeDl1qt12ZJg442JCr/8cmQ= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9f4d4559-b346-4ff7-bcf7-08d76e6b4670 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Nov 2019 10:12:11.7824 (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: udNJgrlNT1joOpDiW0GKDchPyhI0ZQVqsI4RTtWs7rZ+SkFGtMYwwmt14CbBboqvP8RhEWE7jsb9v9FirPyqrxvkyZ9ZcFQ3G6PInWyD91Y= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5170 Archived-At: Subject: Re: [netconf] I-D Action: draft-ietf-netconf-trust-anchors-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 10:12:18 -0000 Hi, Thank you for the updates Kent! One comment though, the changelog and the text do not seem to reflect the c= hanges we have done in the models about the psk and the raw-public-key topi= c. For example, the truststore model does not have PSK keys now, but still = the introduction mentions them. As opposed to this, the addition of the new= local-or-keystore symmetric key grouping to keystore in relation to PSK is= not mentioned in keystore. Br, Balazs -----Original Message----- From: netconf On Behalf Of internet-drafts@ietf.= org Sent: Wednesday, November 20, 2019 7:35 PM To: i-d-announce@ietf.org Cc: netconf@ietf.org Subject: [netconf] I-D Action: draft-ietf-netconf-trust-anchors-08.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network Configuration WG of the IETF. Title : A YANG Data Model for a Truststore Author : Kent Watsen Filename : draft-ietf-netconf-trust-anchors-08.txt Pages : 21 Date : 2019-11-20 Abstract: This document defines a YANG 1.1 data model for configuring global sets of X.509 certificates, SSH host-keys, raw public keys, and PSKs (pairwise-symmetric or pre-shared keys) that can be referenced by other data models for trust. While the SSH host-keys are uniquely for the SSH protocol, certificates, raw public keys, and PSKs may have multiple uses, including authenticating protocol peers and verifying signatures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-trust-anchors/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-08 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-trust-anchors-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-trust-anchors-08 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ netconf mailing list netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From nobody Thu Nov 21 02:41:27 2019 Return-Path: <0100016e8d8d59b8-c6be1b53-65cd-47ce-870e-19a382636547-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 C249A120937 for ; Thu, 21 Nov 2019 02:41:24 -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 aPvXY5-r8UHX for ; Thu, 21 Nov 2019 02:41:23 -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 DE78712085F for ; Thu, 21 Nov 2019 02:41:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1574332881; h=Content-Type:Content-Transfer-Encoding:From:Mime-Version:Subject:Date:Message-Id:References:Cc:In-Reply-To:To:Feedback-ID; bh=tyNyPzsl5DuZ1WiqfzAxsQHADSe1PbXhVNa/N57abFU=; b=mj86R7MZDOBh6hd2fBww/uKZXwAtYxl1sz9vtB0TdZdhI6SgiJrzGZFZuMH1rKZz vs5Kmm0XVRcvRYGWrN41bBFLfcXYju6nD+EvwhS15N8r/j/G97LeR/BykCNMbAJ7gqr AHC6lTCH1fRRpTL1ZIdd/kHgHuY0+ar1oWN7VDhk= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Kent Watsen Mime-Version: 1.0 (1.0) Date: Thu, 21 Nov 2019 10:41:21 +0000 Message-ID: <0100016e8d8d59b8-c6be1b53-65cd-47ce-870e-19a382636547-000000@email.amazonses.com> References: Cc: "netconf@ietf.org" In-Reply-To: To: =?utf-8?Q?Bal=C3=A1zs_Kov=C3=A1cs?= X-Mailer: iPhone Mail (17A878) X-SES-Outgoing: 2019.11.21-54.240.8.31 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] I-D Action: draft-ietf-netconf-trust-anchors-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 10:41:25 -0000 balazs et al, please try to provide comments in the form of a diff of some sort. =20 thanks, kent // contributor=20 > On Nov 21, 2019, at 5:13 AM, Bal=C3=A1zs Kov=C3=A1cs wrote: >=20 > =EF=BB=BFHi, >=20 > Thank you for the updates Kent! >=20 > One comment though, the changelog and the text do not seem to reflect the c= hanges we have done in the models about the psk and the raw-public-key topic= . For example, the truststore model does not have PSK keys now, but still th= e introduction mentions them. As opposed to this, the addition of the new lo= cal-or-keystore symmetric key grouping to keystore in relation to PSK is not= mentioned in keystore. >=20 > Br, > Balazs >=20 > -----Original Message----- > From: netconf On Behalf Of internet-drafts@ietf= .org > Sent: Wednesday, November 20, 2019 7:35 PM > To: i-d-announce@ietf.org > Cc: netconf@ietf.org > Subject: [netconf] I-D Action: draft-ietf-netconf-trust-anchors-08.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. > This draft is a work item of the Network Configuration WG of the IETF. >=20 > Title : A YANG Data Model for a Truststore > Author : Kent Watsen > Filename : draft-ietf-netconf-trust-anchors-08.txt > Pages : 21 > Date : 2019-11-20 >=20 > Abstract: > This document defines a YANG 1.1 data model for configuring global > sets of X.509 certificates, SSH host-keys, raw public keys, and PSKs > (pairwise-symmetric or pre-shared keys) that can be referenced by > other data models for trust. While the SSH host-keys are uniquely > for the SSH protocol, certificates, raw public keys, and PSKs may > have multiple uses, including authenticating protocol peers and > verifying signatures. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netconf-trust-anchors/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-08 > https://datatracker.ietf.org/doc/html/draft-ietf-netconf-trust-anchors-08 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-trust-anchors-08 >=20 >=20 > Please note that it may take a couple of minutes from the time of submissi= on 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 From nobody Thu Nov 21 03:11:04 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9D2120844 for ; Thu, 21 Nov 2019 03:11:02 -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, SPF_HELO_NONE=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 eVRVJN3FwLiS for ; Thu, 21 Nov 2019 03:11:01 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2F21200C1 for ; Thu, 21 Nov 2019 03:11:01 -0800 (PST) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 5F2441AE018B; Thu, 21 Nov 2019 12:10:59 +0100 (CET) Date: Thu, 21 Nov 2019 12:10:27 +0100 (CET) Message-Id: <20191121.121027.792252830481287907.mbj@tail-f.com> To: kent+ietf@watsen.net Cc: netconf@ietf.org From: Martin Bjorklund In-Reply-To: <0100016e8a7ebfef-d490b1b8-f55b-45f9-885c-b5bf1d90ec7f-000000@email.amazonses.com> References: <0100016e8a7ebfef-d490b1b8-f55b-45f9-885c-b5bf1d90ec7f-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] updates to client/server suite of drafts 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, 21 Nov 2019 11:11:02 -0000 Hi, Two quick comments inline. Kent Watsen wrote: > I just pushed an update to all the client/server drafts (except TCP). Below is the change log entry for each draft. > > The most noteworthy update is that the http-01 update should (hopefully) resolve the concerns raised by the httpbis chairs. > > The biggest non-update is that the "config false" algs-supported lists were NOT moved from crypto-types to the ssh/tls drafts, only because I ran out of time (and I'm hoping that my co-authors all do it). > > There are still number of FIXME's remaining in the drafts. > > Kent // contributor > > > crypto-types: > - Added the four features: "[encrypted-]one-[a]symmetric-key- > format", each protecting a 'key-format' identity of the same name. > - Added 'must' expressions asserting that the 'key-format' leaf > exists whenever a non-hidden key is specified. This can be made simpler: OLD: leaf public-key-format { nacm:default-deny-write; when "../public-key"; type identityref { base public-key-format; } description "Identifies the key's format."; } leaf public-key { nacm:default-deny-write; type binary; must "../public-key-format"; mandatory true; description "The binary value of the public key. The interpretation of the value is defined by 'public-key-format' field."; } Now, since public-key is mandatory, the 'when' expression on public-key-format will always be true (in a valid config). Hence it isn't needed. And also, since public-key is mandatory the must on public-key really just says that public-key-format is also mandatory: NEW: leaf public-key-format { nacm:default-deny-write; mandatory true; type identityref { base public-key-format; } description "Identifies the key's format."; } leaf public-key { nacm:default-deny-write; type binary; mandatory true; description "The binary value of the public key. The interpretation of the value is defined by 'public-key-format' field."; } > - Improved the 'description' statements and added 'reference' > statements for the 'key-format' identities. > - Added a questionable forward reference to "encrypted-*" leafs in a > couple 'when' expressions. Questionable indeed. I suggest you remove the when expression instead. You have must expressions that says thatt the key-format leaf must exist in the relevant cases anyway. /martin From nobody Thu Nov 21 09:00:49 2019 Return-Path: <0100016e8ee89f30-bf2de747-ca32-4ccf-8922-cd8ee910a58f-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 ECBF9120CB5 for ; Thu, 21 Nov 2019 09:00: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, 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 jktuYMD1oXjk for ; Thu, 21 Nov 2019 09:00:42 -0800 (PST) Received: from a8-64.smtp-out.amazonses.com (a8-64.smtp-out.amazonses.com [54.240.8.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C27A4120C72 for ; Thu, 21 Nov 2019 09:00:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1574355640; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=n/x0tIs4EJ9EXm0GmG532EgdpUwVrouSsANklsspQGc=; b=MqwWpP/CNTdZNgtc0wo00Ar5BF4XacKaNUDXhO1iCti+FAnYZ/ksBq0MzOvuS4lR 7fNWDsXx1dy1n4uM1FdbG89LHYHvGbhXAiZkflOrBfT7QIdkwSqxPbMH4xuf6y61CQX PDV6owyMJ7KrbRHgn7LavTy+FyIpaQt6JlnmAkSg= From: Kent Watsen Message-ID: <0100016e8ee89f30-bf2de747-ca32-4ccf-8922-cd8ee910a58f-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4DFDC68B-296C-4569-9B5A-1749AAECC335" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 21 Nov 2019 17:00:40 +0000 In-Reply-To: <20191121.121027.792252830481287907.mbj@tail-f.com> Cc: "netconf@ietf.org" To: Martin Bjorklund References: <0100016e8a7ebfef-d490b1b8-f55b-45f9-885c-b5bf1d90ec7f-000000@email.amazonses.com> <20191121.121027.792252830481287907.mbj@tail-f.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.11.21-54.240.8.64 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] updates to client/server suite of drafts 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, 21 Nov 2019 17:00:48 -0000 --Apple-Mail=_4DFDC68B-296C-4569-9B5A-1749AAECC335 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Martin, >> - Added 'must' expressions asserting that the 'key-format' leaf >> exists whenever a non-hidden key is specified. >=20 > This can be made simpler: True. I got caught up in the following the pattern used for = symmetric/private key groupings. > OLD: >=20 > >=20 > Now, since public-key is mandatory, the 'when' expression on > public-key-format will always be true (in a valid config). Hence it > isn't needed. And also, since public-key is mandatory the must on > public-key really just says that public-key-format is also mandatory: >=20 > NEW: >=20 > Applied to my local copy. >> - Added a questionable forward reference to "encrypted-*" leafs in = a >> couple 'when' expressions. >=20 > Questionable indeed. I suggest you remove the when expression > instead. You have must expressions that says thatt the key-format leaf > must exist in the relevant cases anyway. Hmmm, but "private-key-format" should NOT be present (I think!) for a = "hidden-private-key". Maybe this? OLD: when "../private-key or ../encrypted-private-key" NEW: when "not(../hidden-private-key)" BTW, the forward reference was "needed" due to the inability for the = consuming module (ietf-keystone) to refine (?) the "when" expression = when using the grouping. Please add a YANG-next issue if you think = this should be supported someday. Kent // contributor --Apple-Mail=_4DFDC68B-296C-4569-9B5A-1749AAECC335 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Martin,


  - =  Added 'must' expressions asserting that the 'key-format' leaf
     exists whenever a non-hidden = key is specified.

This can be = made simpler:

True.  I got caught up in the following the = pattern used for symmetric/private key groupings.
OLD:

  =     <snip/>

Now, since = public-key is mandatory, the 'when' expression on
public-key-format will always be true (in a valid config). =  Hence it
isn't needed.  And also, since = public-key is mandatory the must on
public-key really just = says that public-key-format is also mandatory:

NEW:

    = <snip/>

Applied to my local copy.




  - =  Added a questionable forward reference to "encrypted-*" leafs in = a
     couple 'when' = expressions.

Questionable = indeed.  I suggest you remove the when expression
instead. You have must expressions that says thatt the = key-format leaf
must exist in the relevant cases = anyway.

Hmmm, but "private-key-format" should NOT be = present (I think!) for a "hidden-private-key".  Maybe = this?

OLD:
= when "../private-key or = ../encrypted-private-key"

NEW:
= when "not(../hidden-private-key)"



BTW, the forward reference was "needed" due to the = inability for the consuming module (ietf-keystone) to refine (?) the = "when" expression when using the grouping.   Please add a YANG-next = issue if you think this should be supported someday.


Kent // = contributor


= --Apple-Mail=_4DFDC68B-296C-4569-9B5A-1749AAECC335-- From nobody Fri Nov 22 00:23:27 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD439120143 for ; Fri, 22 Nov 2019 00: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, SPF_HELO_NONE=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 8JRYMgxPzn41 for ; Fri, 22 Nov 2019 00:23:24 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8275012003E for ; Fri, 22 Nov 2019 00:23:24 -0800 (PST) Received: from localhost (h-4-44.A165.priv.bahnhof.se [158.174.4.44]) by mail.tail-f.com (Postfix) with ESMTPSA id 85E4A1AE0310; Fri, 22 Nov 2019 09:23:22 +0100 (CET) Date: Fri, 22 Nov 2019 09:23:22 +0100 (CET) Message-Id: <20191122.092322.920833985355675307.mbj@tail-f.com> To: kent+ietf@watsen.net Cc: netconf@ietf.org From: Martin Bjorklund In-Reply-To: <0100016e8ee89f30-bf2de747-ca32-4ccf-8922-cd8ee910a58f-000000@email.amazonses.com> References: <0100016e8a7ebfef-d490b1b8-f55b-45f9-885c-b5bf1d90ec7f-000000@email.amazonses.com> <20191121.121027.792252830481287907.mbj@tail-f.com> <0100016e8ee89f30-bf2de747-ca32-4ccf-8922-cd8ee910a58f-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] updates to client/server suite of drafts 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, 22 Nov 2019 08:23:26 -0000 Kent Watsen wrote: > Hi Martin, > > > >> - Added 'must' expressions asserting that the 'key-format' leaf > >> exists whenever a non-hidden key is specified. > > > > This can be made simpler: > > True. I got caught up in the following the pattern used for symmetric/private key groupings. > > > OLD: > > > > > > > > Now, since public-key is mandatory, the 'when' expression on > > public-key-format will always be true (in a valid config). Hence it > > isn't needed. And also, since public-key is mandatory the must on > > public-key really just says that public-key-format is also mandatory: > > > > NEW: > > > > > > Applied to my local copy. > > > > > >> - Added a questionable forward reference to "encrypted-*" leafs in a > >> couple 'when' expressions. > > > > Questionable indeed. I suggest you remove the when expression > > instead. You have must expressions that says thatt the key-format leaf > > must exist in the relevant cases anyway. > > Hmmm, but "private-key-format" should NOT be present (I think!) for a "hidden-private-key". Maybe this? > > OLD: > when "../private-key or ../encrypted-private-key" > > NEW: > when "not(../hidden-private-key)" Or perhaps use a must in the 'hidden-private-key' instead: must 'not(../private-key-format)'; /martin > > > > BTW, the forward reference was "needed" due to the inability for the consuming module (ietf-keystone) to refine (?) the "when" expression when using the grouping. Please add a YANG-next issue if you think this should be supported someday. > > > Kent // contributor > > From nobody Fri Nov 22 05:56:42 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74DB91200B9 for ; Fri, 22 Nov 2019 05:56:40 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RgsRCmgWCX2 for ; Fri, 22 Nov 2019 05:56:38 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80084.outbound.protection.outlook.com [40.107.8.84]) (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 ADA6912007C for ; Fri, 22 Nov 2019 05:56:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aQ+GWexOqX89vgYU9di0MABtEDybetvkv7BXij5pd6t2aHc1gPu/3Ycfc1OY6KfhCelGAGU8YnTOg36ogOoejpFJunPnM16Sahf0mTL1HsJn1GFdlJqIvrCzmLqAAY4JQbMYEaeHTlXh1DqP6WXqb7y6rN1matYSQ9HNm0X17rMzlayc/J97HWTHBfWnR2O3VgZkGta4f6D6Kn1FjdN39qGaUHNmKxrHap1LefteXRKEcGomsuLRytjWRs4DOtVXVY9upV2wZdaAVThEwPwGALMstB8MXkddlgTaRA0z4qv0Oy6Xw1GYn7uPrHqnVgvPB94arhxjcMKKNNrLIJzZWA== 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=iGUMjRNcp0I2+I6H+QHGBniU1TakdM1Px6uy+jqUOxc=; b=M6R5h2FsIb8LBCxc8OhCz9Urtmz0V8blZb42ANQvmhGnYOz0fxl6PxV/+jf5oHg4eB8VG/Wav03EtjAV1zUx+mZaPboXmBRLX1zEmUQvZgvdLkuhJwhtpK4o9C7zsbkt9kuQ6VHY+EooRuxLrwo+qg3hRGul6iYidhs7aFQJeF3GiQUnO2t3rM9tK3D+e85ptaO6RwPiGuly6yluULzf3iDPc5chFh9iBbK12dImzrD4IX6p7wTN0wdVip3QnBzija/0v+230WCP55AN6PHcjaz2Jn5gbfZb2hFQV3yp0Y8mw64tsbLJKWCUZbjEXprT8HsvoD/45JY1tI+ZtnlTow== 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=iGUMjRNcp0I2+I6H+QHGBniU1TakdM1Px6uy+jqUOxc=; b=Jra/D3G05aAxJZgXEOoItuuOM1Xr5LD5qnXuN8OJcSqf8JgA62ylMW4rpxS/nf27Ap1t+EBqgRLNPX76DTmJUm2AXvTC61HIE/X5/j4tjTmKZqgqT8eixlxBr/kHNl2neATPluHL1p+9rCLw1neCfaePid5zclODpCXXOfvRKmo= Received: from AM0PR07MB5187.eurprd07.prod.outlook.com (20.178.20.74) by AM0PR07MB6402.eurprd07.prod.outlook.com (10.186.175.80) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.8; Fri, 22 Nov 2019 13:56:35 +0000 Received: from AM0PR07MB5187.eurprd07.prod.outlook.com ([fe80::e485:83e7:ee62:53f8]) by AM0PR07MB5187.eurprd07.prod.outlook.com ([fe80::e485:83e7:ee62:53f8%5]) with mapi id 15.20.2495.011; Fri, 22 Nov 2019 13:56:35 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Kov=E1cs?= To: Kent Watsen , "netconf@ietf.org" Thread-Topic: update to ssh-server draft Thread-Index: AdWhO0IZE1dC8qjAQkuUng0JdaMGKw== Date: Fri, 22 Nov 2019 13:56:35 +0000 Message-ID: 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: [129.192.74.10] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3d6224c7-dc4f-469f-195e-08d76f53c9ba x-ms-traffictypediagnostic: AM0PR07MB6402: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6108; x-forefront-prvs: 02296943FF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(366004)(39860400002)(396003)(136003)(189003)(199004)(14454004)(3846002)(6116002)(790700001)(478600001)(3480700005)(66066001)(110136005)(6436002)(55016002)(9686003)(54896002)(76116006)(2906002)(25786009)(316002)(6306002)(66446008)(86362001)(52536014)(66946007)(66476007)(66556008)(64756008)(4744005)(5660300002)(7736002)(33656002)(186003)(26005)(9326002)(2501003)(4001150100001)(6506007)(81156014)(102836004)(8676002)(256004)(14444005)(7696005)(81166006)(74316002)(71200400001)(71190400001)(8936002)(99286004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB6402; 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: B6NqGyAFGj1D8Gvd1AocKDbPtI6ulvJM5KA3+U1o1MBEIXe/NGxIYPsQM0oX3AixZqMXPQkGUdYChRrBPXXD6Rd75BOItqsf0aU2Apy/vploW82G7aoLFKSgHhudyg+R1u+U0gbvRwfXP/3UnABr3iWEjv1KTR+7e9vI6tXjQMMjxS6B4mD4PmkW1OQUtEEq+GizIDrAikDUpNC/pCJNv1MVgQoh/VtyL8/MvnsnqP7jJNBtEvrZebDaLBODdbQzH+uFWewCjwxFPsLHsfxdeKug1stPPEWRLWpvGyDp/ObnFfeCi2rzhAvKE0VHb1tDxatkPJa8/JR2XnbtVzoiEnHM805TKgMq/Y493qnTuWiLv+qNvvtzfVO5AbhJSiDQO6cRMwaPJMwPmtgK2d0cGgJ0o3X/39geI7+61HtkeU2RZtiAjfp2fwOVhnU6pzSc x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR07MB518786C90B2703FB6A9377CC83490AM0PR07MB5187eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3d6224c7-dc4f-469f-195e-08d76f53c9ba X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2019 13:56:35.3020 (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: CGwRRK40TRrFtslXB6mixFp1lbIz+hqDBseaz83ygGNryUAOA2ocuzMP5HpUKXcUmunYWlDb+lMy28tpspirNcyHNg4pfUBdqv13LtYvfvw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB6402 Archived-At: Subject: [netconf] update to ssh-server draft 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, 22 Nov 2019 13:56:40 -0000 --_000_AM0PR07MB518786C90B2703FB6A9377CC83490AM0PR07MB5187eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, The new local configuration in ssh-server draft seem to have some not appro= priate terminology. The public key of the users should be maybe not called = host keys? In RFC7317: +--rw user* [name] +--rw name string +--rw password? ianach:crypt-hash +--rw authorized-key* [name] +--rw name string +--rw algorithm string +--rw key-data binary In ietf-ssh-server@2019-11-20: | +-- supported-authentication-methods | | +-- publickey? empty | | +-- passsword? empty | | +-- hostbased? empty | | +-- none? empty | | +-- other* string | +-- users {client-auth-config-supported}? | | +-- user* [name] | | +-- name? string | | +-- password? ianach:crypt-hash | | +-- host-keys! | | +---u ts:local-or-truststore-host-keys-grouping Maybe this latter better serves hostbased key authentication? Was that real= ly the intention? Should it be possible to select between user authorized k= ey and host based auth? So for example, if one selects publickey, then shou= ld it still configure a trusted host key? /Balazs --_000_AM0PR07MB518786C90B2703FB6A9377CC83490AM0PR07MB5187eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

The new local configuration in ssh-server draft seem= to have some not appropriate terminology. The public key of the users shou= ld be maybe not called host keys?

 

In RFC7317:

 

         &nbs= p;  +--rw user* [name]

         &nbs= p;     +--rw name     &nbs= p;  string

         &nbs= p;     +--rw password?   ianach:crypt-has= h

         &nbs= p;     +--rw authorized-key* [name]

         &nbs= p;        +--rw name  &nbs= p;      string

         &nbs= p;        +--rw algorithm  = ;  string

         &nbs= p;        +--rw key-data  =    binary

 

In ietf-ssh-server@2019-11-20:

       |  +-- supported-authent=
ication-methods
       |  |  +-- publickey=
?   empty
       |  |  +-- passsword=
?   empty
       |  |  +-- hostbased=
?   empty
       |  |  +-- none?&nbs=
p;       empty
       |  |  +-- other*&nb=
sp;      string
       |  +-- users {client-aut=
h-config-supported}?
       |  |  +-- user* [na=
me]
       |  |    =
 +-- name?        string<=
/pre>

       |  |    =
 +-- password?    ianach:crypt-hash


       |  |    =
 +-- host-keys!


       |  |    =
    +---u ts:local-or-truststore-host-keys-grouping=



 


Maybe this latter better serves hostbased key authen=
tication? Was that really the intention? Should it be possible to select be=
tween user authorized key and host based auth? So for example, if one selec=
ts publickey, then should it still
 configure a trusted host key?


 


/Balazs


 


 
--_000_AM0PR07MB518786C90B2703FB6A9377CC83490AM0PR07MB5187eurp_-- From nobody Fri Nov 22 07:32:22 2019 Return-Path: <0100016e93be0fac-d8d79f7f-c31f-4c7b-8830-a81c339f0a5a-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 4360D120853 for ; Fri, 22 Nov 2019 07:32:20 -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 4p3hyLx8F68J for ; Fri, 22 Nov 2019 07:32:18 -0800 (PST) Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A722012004C for ; Fri, 22 Nov 2019 07:32:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1574436737; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=swtoWMOlyQf6uA0lL5nV5p/LtD+J8RRJ4ZsJGBT/rTs=; b=WAe2I2QmgINI/cAzw9pAe/rF17SEa9nRYdu71GsyeeV87Ca1piu1TGANB6d0PLgl qP6UJ2GClj544mV5CcHsNR8ehAK/l6N/sgdUqeEd67qyg5Q04MspWKwvo+itVZb4xor nnV27wd34E8htty7DZH5bSubobhIn5wuQO6TX5LM= From: Kent Watsen Message-ID: <0100016e93be0fac-d8d79f7f-c31f-4c7b-8830-a81c339f0a5a-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C2C5630A-C424-4E4D-8983-4A9B8FE4EF40" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 22 Nov 2019 15:32:17 +0000 In-Reply-To: <20191122.092322.920833985355675307.mbj@tail-f.com> Cc: "netconf@ietf.org" To: Martin Bjorklund References: <0100016e8a7ebfef-d490b1b8-f55b-45f9-885c-b5bf1d90ec7f-000000@email.amazonses.com> <20191121.121027.792252830481287907.mbj@tail-f.com> <0100016e8ee89f30-bf2de747-ca32-4ccf-8922-cd8ee910a58f-000000@email.amazonses.com> <20191122.092322.920833985355675307.mbj@tail-f.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.11.22-54.240.8.96 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] updates to client/server suite of drafts 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, 22 Nov 2019 15:32:20 -0000 --Apple-Mail=_C2C5630A-C424-4E4D-8983-4A9B8FE4EF40 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi Martin, > Or perhaps use a must in the 'hidden-private-key' instead: > > must 'not(../private-key-format)'; Better, more symmetric. Applied to my local copy. Thanks, Kent --Apple-Mail=_C2C5630A-C424-4E4D-8983-4A9B8FE4EF40 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi Martin,

Or perhaps use a must in the 'hidden-private-key' instead:

 must 'not(../private-key-format)';

Better, more symmetric.  Applied to my local copy.

Thanks,
Kent

--Apple-Mail=_C2C5630A-C424-4E4D-8983-4A9B8FE4EF40-- From nobody Fri Nov 22 07:49:26 2019 Return-Path: <0100016e93cdb1a3-6544deca-acbe-4c7c-a5eb-5efdbd8fe2c1-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 63151120976 for ; Fri, 22 Nov 2019 07:49:24 -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 6HagfdTKMSCP for ; Fri, 22 Nov 2019 07:49:23 -0800 (PST) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E23CC120952 for ; Fri, 22 Nov 2019 07:49:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1574437761; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=g9xUSfAw9cxSJJM+ceFGiyKsTTzy8KKF4I9k65ngCo8=; b=LKm+kx+V4YxN0VxQLd9Vxl2fbuTIa7uhnjhMu+bNxEt4xAAYZUe89TzphAk/mPcf SV6POslezjtIQIw2hZrWwjxjwWstLyPbeKKbNs2mApaXI/06/FQJ7zc65h25vhh/HUh wUvNAAY3KJntcUBcNcHz/f3qs7ucmLXW6e9Wmw4w= From: Kent Watsen Message-ID: <0100016e93cdb1a3-6544deca-acbe-4c7c-a5eb-5efdbd8fe2c1-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_276641A7-F5E3-40D5-B51E-AFCFFD7A46AE" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 22 Nov 2019 15:49:21 +0000 In-Reply-To: Cc: "netconf@ietf.org" To: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= References: X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.11.22-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] update to ssh-server draft 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, 22 Nov 2019 15:49:24 -0000 --Apple-Mail=_276641A7-F5E3-40D5-B51E-AFCFFD7A46AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Balazs, =20 > The new local configuration in ssh-server draft seem to have some not = appropriate terminology. The public key of the users should be maybe not = called host keys? Correct. Martin raised this point on the 13th too (subject: "client = identification in ietf-netconf-server") > In RFC7317: > =20 > +--rw user* [name] > +--rw name string > +--rw password? ianach:crypt-hash > +--rw authorized-key* [name] > +--rw name string > +--rw algorithm string > +--rw key-data binary > =20 > In ietf-ssh-server@2019-11-20: > | +-- supported-authentication-methods > | | +-- publickey? empty > | | +-- passsword? empty > | | +-- hostbased? empty > | | +-- none? empty > | | +-- other* string > | +-- users {client-auth-config-supported}? > | | +-- user* [name] > | | +-- name? string > | | +-- password? ianach:crypt-hash > | | +-- host-keys! > | | +---u ts:local-or-truststore-host-keys-grouping > =20 > Maybe this latter better serves hostbased key authentication? Was that = really the intention? Should it be possible to select between user = authorized key and host based auth? So for example, if one selects = publickey, then should it still configure a trusted host key? The intention was to support "publickey" based auth (not "hostbased"). = As I was telling Martin, it's the same key format, but it's called = "hostkey" for servers and has no special name for clients. I was being = overzealous with naming it "hostkey" here. =20 That said, there should be a way to configure authenticating clients for = *all* the methods, including "hostbased", which isn't supported in the = model yet... Could provide a diff that irons out these issues? Thanks, Kent=20 --Apple-Mail=_276641A7-F5E3-40D5-B51E-AFCFFD7A46AE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Balazs,
 
The new local = configuration in ssh-server draft seem to have some not appropriate = terminology. The public key of the users should be maybe not called host = keys?

Correct. =  Martin raised this point on the 13th too (subject: "client = identification in ietf-netconf-server")


 In RFC7317:
 
          &nb= sp; +--rw user* [name]
          &nb= sp;    +--rw = name        string
          &nb= sp;    +--rw password?   ianach:crypt-hash
          &nb= sp;    +--rw authorized-key* [name]
          &nb= sp;       +--rw = name         string
          &nb= sp;       +--rw = algorithm    string
          &nb= sp;       +--rw = key-data     binary
 
In = ietf-ssh-server@2019-11-20:
     =
  |  +-- supported-authentication-methods
       |  |  +-- =
publickey?   empty
       =
|  |  +-- passsword?   empty
       |  |  +-- =
hostbased?   empty
       =
|  |  +-- none?        =
empty
       |  |  +-- =
other*       string
       |  +-- users =
{client-auth-config-supported}?
       =
|  |  +-- user* [name]
       =
|  |     +-- =
name?        string
       |  =
|     +-- password?    =
ianach:crypt-hash
       |  =
|     +-- host-keys!
       =
|  |        +---u =
ts:local-or-truststore-host-keys-grouping
 
Maybe this latter better serves = hostbased key authentication? Was that really the intention? Should it = be possible to select between user authorized key and host based auth? = So for example, if one selects publickey, then should it still configure = a trusted host key?

The intention was to support "publickey" based = auth (not "hostbased").  As I was telling Martin, it's the same key = format, but it's called "hostkey" for servers and has no special name = for clients.  I was being overzealous with naming it "hostkey" = here.  

That said, there should = be a way to configure authenticating clients for *all* the methods, = including "hostbased", which isn't supported in the model = yet...

Could provide a diff that = irons out these issues?

Thanks,
Kent 


= --Apple-Mail=_276641A7-F5E3-40D5-B51E-AFCFFD7A46AE--