Re: [netconf] AD review of draft-ietf-netconf-sztp-csr

"Rob Wilton (rwilton)" <rwilton@cisco.com> Fri, 25 June 2021 10:51 UTC

Return-Path: <rwilton@cisco.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB223A115A; Fri, 25 Jun 2021 03:51:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.595
X-Spam-Level:
X-Spam-Status: No, score=-9.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=i+HSxhTf; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=dBHug9Cq
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mmf9820jm2jc; Fri, 25 Jun 2021 03:51:18 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B61C13A1158; Fri, 25 Jun 2021 03:51:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=53472; q=dns/txt; s=iport; t=1624618277; x=1625827877; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6TSF6iqJI2fsh4puA59z7QgnPwUjrtGxfNHc/7b75J0=; b=i+HSxhTfrmnO48yzITiwdCltxqUCzvJdb6Ggzu+ssLbTp+O1uiuUpgGG WU7ILZT9IxbiPUlfKCUWuK5B4euC+bTJoeJ01tPUEusUK4FJrgFiMGgUv k0ynfdFp9fauSpZ8JHVESswEXqL2qIQe2xsr4P2woqKDofDEiFS1+UHhr 8=;
X-IPAS-Result: =?us-ascii?q?A0AhAgDmtNVgl5xdJa1aHgEBCxIMggwLgSMwIy5+WjcxC?= =?us-ascii?q?4Q9g0gDhTmIeQOBDY5OikKBLhSBEQNUCwEBAQ0BAT8CBAEBhFICF4JYAiU0C?= =?us-ascii?q?Q4CBAEBAQEDAgMBAQEBBQEBBQEBAQIBBgQUAQEBAQEBAQFohWgNhkUBAQEEE?= =?us-ascii?q?hEKEwEBNwEPAgEIEQQBASEBCQICAjAdCAIEDgUIGoJPAYF+VwMvAQOaewGBO?= =?us-ascii?q?gKKH3qBMoEBggcBAQYEBIUuGIIyCYE6gnuEDAEBhmEnHIFJRIEVQ4IqNj6ED?= =?us-ascii?q?wESAQkagxU2gi6CQUIZBgI8JAIBAxQvD3QeIyUEDQ0LAQ8fAUKQbhMPNoMLi?= =?us-ascii?q?Bs2jG+SBAqDIJFKjF8Sg1+LLoYykD2XfJ1RBAmBW4MFAgICAgQFAg4BAQaBV?= =?us-ascii?q?DlrcHAVgyRQFwIOjh8MDQmDTopeczgCBgEJAQEDCXyKaQGBEAEB?=
IronPort-PHdr: A9a23:zl84KxIIjAkH5OUW6NmcuXkyDhhOgF28FhEc9oEqjfRIf7jwt5jhP UmK4/JrgReJWIjA8PtLhqLQtLyoQm0P55uN8RVgOJxBXhMIk4MaygonBsPWFkTnN/PsKSo3A JcKWFps5XruN09TFY73bEHTpXvn6zkUF13/OAN5K/6zFJTVipG81vu5/NvYZAAb7Ac=
IronPort-HdrOrdr: A9a23:kpYRaaoAAMurJ1fySZZpYYMaV5utL9V00zEX/kB9WHVpm5Oj9v xGzc506farslkssSkb6K+90KnpewK6yXcH2/huAV7CZnimhILMFuFfBOTZskbd8kHFh4tgPO JbAtRD4b7LfBhHZKTBkXOF+r8bqbHtms3F9ISurUuFDzsaFp2IhD0JbDpzZ3cGPDWucqBJba Z0iPA3wwaISDAyVICWF3MFV+/Mq5ngj5T9eyMLABYh9U2nkS6owKSSKWna4j4uFxd0hZsy+2 nMlAL0oo+5teug9xPa32jPq7xLhdrazMdZDsDksLlWFtyssHfsWG1SYczEgNkHmpDo1L/sqq iUn/4UBbU215oWRBDsnfKi4Xi67N9k0Q6S9bbRuwqSnSW+fkNhNyKE7rgpLicwLCEbzYxBOe twrhGknosSAhXakCvn4d/UExlsi0qvuHIn1fUelnpFTOIlGfJsRKEkjQho+a07bWjHAUEcYZ 9TJdCZ4OwTfUKRbnjfsGUqyNuwXm4rFhPDRkQZoMSa3zVfgXg8liIjtYMit2ZF8Ih4R4hP5u zCPKgtnLZSTtUOZaY4AOsaW8O4BmHEXBqJOmOPJlbsEr0BJhv22tLKCXUOlamXkbkzvdUPcb j6ISdlXF8JCgvT4Je1reh2Gzj2MRKAtBrWu7Nj26Q=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.83,298,1616457600"; d="scan'208,217";a="712671885"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Jun 2021 10:51:15 +0000
Received: from mail.cisco.com (xbe-aln-007.cisco.com [173.36.7.22]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 15PApBfS004322 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 25 Jun 2021 10:51:14 GMT
Received: from xfe-rtp-002.cisco.com (64.101.210.232) by xbe-aln-007.cisco.com (173.36.7.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Fri, 25 Jun 2021 05:51:11 -0500
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xfe-rtp-002.cisco.com (64.101.210.232) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.15; Fri, 25 Jun 2021 06:51:10 -0400
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.18 via Frontend Transport; Fri, 25 Jun 2021 06:51:10 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gXy5iNXj0MAyWPj/oOA0vZ2CgV25OvbC5xXVl+qo6GSvnRfMDBwWXpbbMop4jyi6uxOzm/BotLM3WY0G6kdY3S/28INkvxOx0WnrJ7nyiwZNYjuTKskjMXQ0b3ooX/S6vrWSqGn/YeK1d7IA83BeDQrLGsqLFBc3IwnX+EE84pHL9h3ZwprbBMeWn42yRWktjA9OxDlkSpGF8SjnwklxnUzui+tnGXRWByVI4YlYZQ7n/ctYmkUhNU6q1hxPI+rB/8eqjcivi1w7zZmbvnBlV/dDsF3JylUMHuo20tUfk3LMOI2OoSDs8Sznbl5iTTekGufeDvXz2fCTM9R1hGGE0g==
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=6TSF6iqJI2fsh4puA59z7QgnPwUjrtGxfNHc/7b75J0=; b=Fo6K/NMYnZMlia8MVb7ajAlr32eSz14xlXDO2Y0lJNwARUm0jtqe94DgM9TBRHdu/8cA6p0AN2zjDLsaU6Eo4masNa//RCDh/ZZ0Aq7yNrHHxC179Ncs7/6dtXM7HelqadS8qceanMRM5BkyHjDW2SRMOukEbKw4mrxA+CPOBcDujShhYXDBz5D6VwfzfY9OJdiobS4pz412mhbskcvf5HeRAPNwcmKi7OsgkmCHsnUlaqhRKQSspuLACi33HT5lFtlye+3lSubb37BXa5zvb0koIbQhmkiChU3+9r8fdVk9bROesluAWd803MzXAY+c3WfkdCn+FK3aR+orWjFSpw==
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=6TSF6iqJI2fsh4puA59z7QgnPwUjrtGxfNHc/7b75J0=; b=dBHug9Cqp7V4C+SpwSdR+RPveXKivWio2zodWHBEPcjWa4wlJ4JZRK6RMENK/5UIyrzX7zdlVnK5huNVN+t94OPSPLCSfKHfjfjJPzOegkE93syZiLleIoN/7VPJy0B4nF9eGsXRXC7wXPCixPR5cMJyJJRPCUi+1CEdmISg36Y=
Received: from DM4PR11MB5438.namprd11.prod.outlook.com (2603:10b6:5:399::21) by DM5PR1101MB2252.namprd11.prod.outlook.com (2603:10b6:4:52::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.22; Fri, 25 Jun 2021 10:51:08 +0000
Received: from DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::e14c:8880:1101:bb0c]) by DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::e14c:8880:1101:bb0c%7]) with mapi id 15.20.4264.023; Fri, 25 Jun 2021 10:51:08 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: Kent Watsen <kent+ietf@watsen.net>
CC: "netconf@ietf.org" <netconf@ietf.org>, "draft-ietf-netconf-sztp-csr@ietf.org" <draft-ietf-netconf-sztp-csr@ietf.org>, "netconf-chairs@ietf.org" <netconf-chairs@ietf.org>
Thread-Topic: AD review of draft-ietf-netconf-sztp-csr
Thread-Index: Addmei+76OsPA+grSaqUN2qOgkG4uAAMdT6AAAAewWAAmDJOgAABKWhQAAo/EwAAGKZHcA==
Date: Fri, 25 Jun 2021 10:51:08 +0000
Message-ID: <DM4PR11MB5438CA53561F81165429C3ABB5069@DM4PR11MB5438.namprd11.prod.outlook.com>
References: <DM4PR11MB543889219C08694C147C6DA4B50A9@DM4PR11MB5438.namprd11.prod.outlook.com> <0100017a2f082e6a-1197e3c8-f8be-4d59-ba1c-8d39029a31fc-000000@email.amazonses.com> <DM4PR11MB543824369BA6920C7FA67BDEB50A9@DM4PR11MB5438.namprd11.prod.outlook.com> <0100017a3ea111a8-680c5610-bc55-4a82-b7fd-7715656f4924-000000@email.amazonses.com> <DM4PR11MB54383EB098E3344A85A2DAA5B5079@DM4PR11MB5438.namprd11.prod.outlook.com> <0100017a3fcc223f-c6d25440-0346-4b41-9fa4-fad32b3e3b75-000000@email.amazonses.com>
In-Reply-To: <0100017a3fcc223f-c6d25440-0346-4b41-9fa4-fad32b3e3b75-000000@email.amazonses.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: watsen.net; dkim=none (message not signed) header.d=none;watsen.net; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [82.12.233.180]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 93b3fc9d-7e3c-4e48-f3b1-08d937c723c2
x-ms-traffictypediagnostic: DM5PR1101MB2252:
x-microsoft-antispam-prvs: <DM5PR1101MB22522BAD64438A83C68E38C9B5069@DM5PR1101MB2252.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 0sYsgTx0eI+QsVzQ35JhXVIETAsYQ1JAIyZ/vIiYbTxiWWTmNvFW9w5GGV5ubUDyhC1EKZGtFIK2T29HSFBb8Pdw36PESdoYj9oX6wOCe48aq7nlwa5d85pAD7C2DwDgx8US+y0ifY35Po+LioIb8jpN4W0sgIBYHxZri42bB/bscBZPyx+jHZkWiLbYD/XVa0d3iin+tszkKgFeTOo7a4rcci3poON7be8jKb74aTzjScRb5BqsrK8vGZXOoAmX9QlkWiy4jWvDdtUtFpNe7wPRSaifge2Q9sXHSIj8PkQFMKwDpNdz3V1pLNm9hYNYOtdCn/wKz5qmIfhOKHK3JVJ22mM2Uh4bS2Fu48ym0dt5FOaUZFc05U+xu8nKrs4R3jH8miZV8t6VUM8zHkHegLiRu6Wta2sJ/1Ns1T9ZKU2ck1ITQv0/J1FrwvrEJ5CDvSYDbd/zYa9uaZ/h9XD3gloZKVAy0V6tQl63PYRG9kuJxwJLi27X2LhWPBqtg0Uu7IIZ0uMEFucSNSjAkZ5c9l5FGVidI8xvNAgE+S2hHvTotScpFy/LgJWZRJ3JPi+adQ9ixZBcxXAFN5FfRJtXyFDs4cZGN9zwtnr8KzWNRAjNVyGayU/95+vETVtMt6Oo0H8cKfO2AeY/OoFsuPLt1A==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM4PR11MB5438.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(396003)(346002)(39860400002)(136003)(376002)(122000001)(316002)(8676002)(83380400001)(5660300002)(8936002)(7696005)(52536014)(9686003)(54906003)(38100700002)(186003)(55016002)(26005)(6506007)(478600001)(66946007)(76116006)(53546011)(71200400001)(4326008)(2906002)(66446008)(64756008)(66556008)(86362001)(66476007)(9326002)(33656002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?utf-8?B?ZE50YlVGY2tFSlpOVUZOODQ0Yml6NDB4SVUvOE93NG5XekNBcGExbE8vdDNE?= =?utf-8?B?aktOeForY05JZndMU1pycEhFWEVpR1pJZXZRbHRyZUlkQi83dm5hYTBjaUVa?= =?utf-8?B?K250cE1qdXFzS3NhalQ1cG9VZXU2ZnVSWHlJcTQwYnRIYXlpc2FYM202M0NP?= =?utf-8?B?VlhZS0NQcS9UZEc4QlFHcjhTZm9yNUdVQlY4aEtxZkJlQ1RnKzZHdjNtMU9X?= =?utf-8?B?Y29MR0t1OHVFU1dRS2xOZ2liaFNPeDVLREJJUzJ2bGlnSEpSamRMZTlpTldu?= =?utf-8?B?SHFRUUw2TGpKT3F1MDdNajdncE9jeTkrcFVGc2FldWpZY29TME80aXFCcDdQ?= =?utf-8?B?M3BaQkMvSCsrbXFhU3c1SmJlQ0o2aGx5L05hNEFCVUt4amV5SCs5dTByVjAy?= =?utf-8?B?TjNxZEdWbkJYdE9Ob2tRVzhzZzVvVHVlK3JCaXQxZjFoL1FDUnNIa2RCVytK?= =?utf-8?B?OWd6dDdtZFBQTi9uSmZjQjJVYzJiTGVtL3lxb3gxcy9nNmNTQTlXVExGYW15?= =?utf-8?B?V3dyU29iNVcxUk9oOVZsV1ZyUTYxai9vUWNxTTNHMm1qUm5SakxoN1NXMHZQ?= =?utf-8?B?b1NFRVNvOC81WWtrZnk0ckFuN0YrRkNpSW44bXBGdFhCQ1lpcGdwR21xdnRy?= =?utf-8?B?eENnODg4K3RTVm9IRGJZeUZiUGJNQ3RkWEE5V0kzejV4OHJJeFRGTW41U09E?= =?utf-8?B?aDVNdTVlTkcvelJ0Y1Z6VDAyQUFwL0NYZWlGenI4UlM0RTdIaEVjSCtRK2FQ?= =?utf-8?B?VlNBYldtcU5rN0lqWW9tZktXN292OGlVbFg3T3Q0aU1PN3BCQThrdkhwK0xF?= =?utf-8?B?MWtpQjhPTnZmcEl1SmdQSHVUZmhvUlplUnBuZEZkTy9QK21udlFRd0o1U0tr?= =?utf-8?B?NEFhMDBLMzFBaEJmaVJtMFlNUDI1ZGNSREpGbTU4VTZCbkg0cHJWS0Y4aVBR?= =?utf-8?B?NU1EUnRBVkVRQkx4ZjhpY3VmQTd5M0FZREswSE1mZnJqQnVobWxiNUNNUXJu?= =?utf-8?B?UFUrMXUzUHN0aWVidGEvelpqTlRnQ1E5bzZkbmI2aUQyZTh0L2RWdzJUWmZM?= =?utf-8?B?czVyOTV0Z2Q2WXZYQjJldFFEdHNQOU1EeERHdy9LS1NpTkRpUjRsck85ZXNF?= =?utf-8?B?TmZCTTI3TmZOa1p4SmIwUVBKUjY1NmtPbVZkS01RU2ZQc0g5NmpYclN4aW5o?= =?utf-8?B?WHVjTmp0RUFWRVFTY2NYSzl3K3hyYlVwVEhxL3k4VDlJSVhheGhmcHQwVVVm?= =?utf-8?B?TmswQy8wbTF4YVplWUs4N2J5N0VFMFFyQ0ExbFZYUG5ZZ1MxUS9KMGhyL09O?= =?utf-8?B?dTUraStnV2ZSKzVxdENUeWJmL2lIcDEveEdXU1BXMXZVUTBDekhFL2d6S21F?= =?utf-8?B?dUV1SWcyVEFnZnZkN3NNL21IRUxvV3kvZXRUL2s2d2FmN3NrUnp0MHFaR3NY?= =?utf-8?B?UFJYYlVuRUpNZWRQZWhUZnV5bVhQZzRJdU5HSTBCMUVhZktHUTVmYUFhNGt1?= =?utf-8?B?U1Y5QVBQZ3BjZHpkR2xVRVM4bXVSMVppSWZQZlZvS3dEUHpXV3Boem5OR1pl?= =?utf-8?B?bVk0Y3U2dzE5TC9tMVZLWDFuUEVqd2N4aTNpeis1L3RkQ2tsUU9STWk0Qmgz?= =?utf-8?B?U1dkL0hxTTdWeHB1OXdNYTFEa25heXQ0VWFsbWlTSVdEQThsWG0rdE0rVFJx?= =?utf-8?B?QlUzR1N2ZElLNzlLYTM0Q0pJRk5yRW5CcGdKUGpLa0tabkRaZUNhYXpwWktt?= =?utf-8?Q?nG9wwkhCC4qCoUoe66V4v0IPrgxlVkUWNRM4i8t?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_DM4PR11MB5438CA53561F81165429C3ABB5069DM4PR11MB5438namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB5438.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 93b3fc9d-7e3c-4e48-f3b1-08d937c723c2
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2021 10:51:08.6638 (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: ePh+pYUnhTGMSiVeSm+RT7ndfN4HsXff7u1Kcf2G27b+H5svyCNp4BfvT4jm+Il9Ot3+5ogH+emK5dGNfMZDiw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1101MB2252
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.22, xbe-aln-007.cisco.com
X-Outbound-Node: rcdn-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/kxufyrOGCy4vj2uL8XRThuIOoPU>
Subject: Re: [netconf] AD review of draft-ietf-netconf-sztp-csr
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Jun 2021 10:51:23 -0000

Hi Kent,

Thanks for the extra details/explanation.  Please see inline …

From: Kent Watsen <kent+ietf@watsen.net>
Sent: 24 June 2021 21:53
To: Rob Wilton (rwilton) <rwilton@cisco.com>
Cc: netconf@ietf.org; draft-ietf-netconf-sztp-csr@ietf.org; netconf-chairs@ietf.org
Subject: Re: AD review of draft-ietf-netconf-sztp-csr

Rob,

I’m not sure.  It feels less RESTful (at least to me) to not allow the data to be provided as a single message, even if in practice that might not make sense in most (almost all) cases.  If you were using a separate YANG RPC to send the crs-support and get the request-info then only including the crs node in the bootstrapping data RPC then I would have no complaints.  I.e., it only feels strange to handle a transactional dependency within the data structures of a single RPC on what is nominally a stateless API.

Also, worth noting that using a separate YANG RPC to transmit the capabilities avoids the need to return an error.  It could just return success with the required information.  Was this approach considered at all, and would this be too big a change?  I’m not trying to create extra work for you, or delay this document …

If a separate RPC to get the capabilities in undesirable or infeasible then changing to a choice seems reasonable, but I would probably suggest keeping “intended” and probably keeping the language on page 4 somewhat open, i.e., not strictly locking it down to doing a handshake.

I’m unsure it it makes sense to be concerned about the RESTfulness of this API.  Yes, it uses RESTCONF, but that is more out of convenience than any inherent need or desire for the API to be "RESTful”.  For instance, note that never could HTTP caches be used, as each message is distinct from any other.

That said, the “get-bootstrapping-data” RPC *is* idempotent, as the same POST (get-bootstrapping-data) returns the same response (assuming the server isn’t updated by an operator in the interim).  This is true also for when sending the “csr-support” and “csr” nodes, as described in the current document.   Of course, the idempotency of a YANG “rpc” statement isn’t that meaningful, relative to a RESTCONF "POST” used to edit configuration (e.g., like <edit-config>)…it’s likely fair to say that YANG RPCs are generally NOT RESTful.

Regarding using a separate RPC (returning a 2XX),  yes it was considered, however note that it is impossible for a generic device to anticipate what the specific deployment’s CA infrastructure will require in terms of 1) if *any* CSR is desired (most often not) and 2) when desired, what key-algorithm and CSR-attributes to use (rarely would the nearly-empty CSR a device could proactively send be viable).

FWIW, if an out-of-band RPC were used, most of the time it would be a roundtrip for a no-op.  The in-band approach currently described is ideal in that it only consumes extra resources when needed.

I hadn’t picked up on that nuance, and I agree that this makes an out of band approach less efficient and less helpful.


That said, it does little harm for the draft to say (in addition to supporting the “in-band” mechanism) “a device MAY obtain the ‘request-info’ through an out-of-band mechanism outside the scope of this document”.  If this resolves your concern, then it’s an easy thing to add, and it may (to your point) provide some flexibility.  I think that it is consistent with your last paragraph above.

Not necessary.  I’m happy with your explanation as to why having it inband pragmatically makes more sense.


I still think we should put “csr-support” and “csr” under a "choice” though, as the use-case for sending both at the same time is very small and it seems wrong to encourage/suggest it’s a good idea or to ask servers to have to support the case.

Agreed.



4. References.  RFC 3688 probably should be normative for the XML
registry, noting that


RFC 6020 is normatively referenced.

Really?  I tend to disagree as I thought the litmus test for if something were
normative was if it had to be understood in order to implement the RFC.

I guess the logic here is that you need to understand RFC 6020 to understand the registry that is having entries added (given that RFC 7950 doesn't define the registry).

But, as per below, I'll check with the IESG on this one.




You raise an interesting point about RFC 6020 being Normative, as I see that
it is NOT normative in at least one of my other drafts.  I think that it is a
reasonable position that, if the RFC 6020 reference is only present in the
IANA Considerations section, then it is INFORMATIVE as far as the draft as a
whole goes.  Thoughts?

Let me check with the IESG and get back to you on this one.  Although, perhaps worth noting that both these references are normative in RFC 8343 (and they are only referenced from the IANA registry entries).

Ack, I will wait for your response on this item.

I didn’t really get a strong answer from other ADs on this.

Some of us felt that a normative reference is appropriate (because you need to understand the meaning of the registry that is being updated), and nobody objected to that characterization, but equally, some ADs didn’t think that Informative is necessarily wrong and it is probably not worth worrying about.

My recommendation is to make them normative, because that is what has been done for other RFCs with YANG modules (and consistency is good), and I don’t see any other ADs objecting to this approach.  I would regard this as the path of least resistance.

Regarding "because you need to understand the meaning of the registry that is being updated”, “you" only refers to IANA, right?   I don’t think SZTP-client and/or SZTP-server developers need to know about IANA registries to implement the document, right again?   Consistency is good, yes, but not when consistently-wrong  ;)   [I’m speaking theoretically here, not to any particular group of people]

My understanding is more along these lines:

To fully understand everything in the RFC (i.e., definition of a normative reference), a reader of the RFC would need to understand what is meant by the draft adding an entry to a registry.  I.e., I’m not saying that a normative reference is needed to understand the act of adding a field to a registry, but it is necessary to understand the significance of why that matters.  In this case, the author should understand that adding an entry to module name registry means that it should be a (hopefully globally) unique name for that module and not defined in another RFC with an entirely different definition.  I.e., it should be possible to fetch the module from a reputable source by (name, revision) without having to extract it from the RFC (which would be required if it was not uniquely named).

A separate argument is that this document logically has a dependency on that IANA registry existing, and often those dependencies between documents are often indicated as normative references to indicate the dependency.

Note, there is also a bit of text in section 3.1 of RFC 8216 which indicates that a reference to the RFC definition the registry is expected, but not what sort of reference that should be.


This is not something I care to block on, but I do want Normative references to adhere to the principle of they are for  *implementors* (which doesn’t include IANA, IMO).  Related, there’s also the XML Registry (RFC 3688); should all documents publishing a YANG module have a Normative reference due to an IANA instruction?  [PS: some RFCs exist (i.e., published) already having RFC 3688 as Informative…I wouldn’t by surprised if some also exist having RFC 6020 as Informative, but a quick search didn’t find any]
I also do not intend to block the document on this point.  But I don’t think that normative references are just for implementors, they also define anything that is required to be stable for the published standard to be stable, i.e., to avoid relying on something that could change under our feet.
On the XML registry question, the answer is yes.   I’m suggesting that all documents that update registries should normatively reference the document that defines the registry.
More generally, I’m not entirely sure that the split between normative and informative references is that helpful and seems to cause more discussion that it is worth.  I would really prefer that there were 3 categories of references (or perhaps one of the existing categories are split into 2).

  1.  Docs that an author is recommended to read before reading this doc.
  2.  Docs that this document relies on for this specification to be correct.
  3.  Other related docs that readers of this document might find helpful.
Today, I see that normative references cover both (1) and (2), but for most readers I suspect that is only (1) that is really useful to them.  FWIW, I would put the 6020 and 3688 references into the second category.
Another question that comes up are references for optional features (which according to the current rules need to be normative).  If these are features that readers are unlikely to care about, then again I see them as fitting into (2) rather than (1).
I suspect that most RFCs today, handle the split between (1) and (2) in an adhoc way, by having the introduction describe briefly reference the docs that fit into (1).


BTW, other drafts in your queue have "Informative” set for RFC 6020, and one (netconf-notification-capabilities) incorrectly references RFC 7950 instead of RFC 6020 (As shepherd, I apologize for missing it, but it’s one thing to test if all the references provided are accurate [i.e., the doc *does* have a normative dependency on 7950], and another to see if any references were missing altogether…i.e., finding the gaps).
Thanks.  I think that I picked up on this in my AD review.


PS: there’s a separate email thread (Reuse of SZTP-CSR YANG definition in BRSKI-AE) regarding this document that is pending your feedback.  Ideally I can collect that and thus apply all updates in one shot.
Sorry, I had missed this thread.  I’ve now replied.
Thanks,
Rob

K.