[netconf] Short prefix Re: Yangdoctors last call review of draft-ietf-netconf-trust-anchors-13
tom petch <ietfc@btconnect.com> Wed, 13 January 2021 10:56 UTC
Return-Path: <ietfc@btconnect.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 EAE3D3A00D2; Wed, 13 Jan 2021 02:56:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 bCilOgalemSQ; Wed, 13 Jan 2021 02:56:26 -0800 (PST)
Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2120.outbound.protection.outlook.com [40.107.20.120]) (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 92B383A00F7; Wed, 13 Jan 2021 02:56:25 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CQab1znfXihGGe6SJZE93BLEjQ7AiFHfIjihBa2JOqyZz3Klndx7LCUQrwHlv/q++9spdI0dPYeoAoBv48cUul1iHrjaOVPOOke7P4rSro7CBJ9myPFI4hDo4qGqgL+HbcEyXYwOLY4rxbonot+mYwxC12t58erMq6eXEkUXCKn68Smsmw9M07HStB+F52NtOSkNttiESKzFnzQszRsTRj8OVQOY/8lBbYIYEZa8uGE0gIb1n6bSkecrgXIohna4gHRikNOL/aTPzZ+/Jzs6YY6z1ZXp1aHJQrVqigG1kH89gxuHFvC4k6Sx42PQrV/jTteHLqu6zGhvIITacTtgMw==
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=l9+kk0RQzAVo1HCA/OAsQq72YEuOMjvvqjegzd8KDiA=; b=Dd3yuRlbP7Ar9s2aA0Tzl/3aNIW1JhKddrfpKotKiuKE5T8PlFnsofPGtqCEL+2v6MtNbdvj+pW7rDmDRaQ1iJd/8PHUuloVkFV9osdIenI+/IcFbaqYv11sUz5Ytt3Jn2cmhTKHp4YGsvthN+QkxtnMibp+jY7EbdwDUciTwVSsyudBSe97+Tc9LKvnBG1LKPJexnCFf8oS31dBJCBC8U+rYbfvgWlrAU8Pfqb47RZ9+n5x6cpdBMo5QKUX8ePAwOdP2vQV/eM7cGWerC/vq+cVBMggKjUvkoc8LFE1QiUuXQBJKdpYHKo0Tl9yx2b8P5IA8noOOMmskTvnd2KUNA==
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=l9+kk0RQzAVo1HCA/OAsQq72YEuOMjvvqjegzd8KDiA=; b=R9XEvSI/07l5NHuLOeybF/wWSMeMnZjMJEsPTl0NQczUvdJi7HoB6oVdXdvVDgTrvSgIXxmhrD+UGjzie9B+CqMKPvSNnwrdbMcIaRenbsTWequRlhIr2hW0Pas7etQ2xt4mUVlAB5+YHJ9lem85GLsrS031nlLpaik1svXf4Zo=
Received: from AM7PR07MB6248.eurprd07.prod.outlook.com (2603:10a6:20b:134::11) by AM6PR07MB6167.eurprd07.prod.outlook.com (2603:10a6:20b:65::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.2; Wed, 13 Jan 2021 10:56:23 +0000
Received: from AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::6d46:4f3c:643:4849]) by AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::6d46:4f3c:643:4849%5]) with mapi id 15.20.3763.009; Wed, 13 Jan 2021 10:56:23 +0000
From: tom petch <ietfc@btconnect.com>
To: "yang-doctors@ietf.org" <yang-doctors@ietf.org>, Jürgen Schönwälder <j.schoenwaelder@jacobs-university.de>
CC: "netconf@ietf.org" <netconf@ietf.org>, "draft-ietf-netconf-trust-anchors.all@ietf.org" <draft-ietf-netconf-trust-anchors.all@ietf.org>
Thread-Topic: Short prefix Re: [netconf] Yangdoctors last call review of draft-ietf-netconf-trust-anchors-13
Thread-Index: AQHW6RLOA86IN18iz0WS1xfHTKbb6aolYga9
Date: Wed, 13 Jan 2021 10:56:23 +0000
Message-ID: <AM7PR07MB624869BD8D84682C7C090CECA0A90@AM7PR07MB6248.eurprd07.prod.outlook.com>
References: <161047687248.13931.17900123352005904827@ietfa.amsl.com>
In-Reply-To: <161047687248.13931.17900123352005904827@ietfa.amsl.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=btconnect.com;
x-originating-ip: [86.146.121.140]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6affe13f-5cd6-4f90-a9c2-08d8b7b1ddf8
x-ms-traffictypediagnostic: AM6PR07MB6167:
x-microsoft-antispam-prvs: <AM6PR07MB6167680B78D5EA4C2490C0C8A0A90@AM6PR07MB6167.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: clIIMJWIc7XR105lv3H60/9lO3/P0bQYqUgbotBYTuGmEyMbf5tJrbvliz/8KiJzANtdzkUf5c8gqhEojln9VKYGCxbH+MhePC7FCwyuD5Ltb9Rttq2lNRmzvzMmL2Ukd2tT1/djH9zuXYMHXgRwpGX+bLVg1TrlAXiIe2U5/Ex6vcu9ZJ2WmELNrtqZQK1CSPTeDCnECz6WQ3b+Z/EDHIO9F02R5Ojxskcad0c+trpwWHMYFBUqNNc2PvUBSTed/h4ZhUqwVViTnOG9pEmFe66GwtREaBRPzDOVdgO0Uw+LYAerC/OIIbadsmIdWdv7JfW0UQ3ZELYtfA2FjQm2VaSySfA86xV3D+vzYr6Y4HNhp9/r5C45XciAldAOPrZlNv80G5uI5nbjETWf6u+XsVLDJhCQlAR+2Sffmrp7mHFgH26dn6w1QE8qmDpygmFiRewhGwcG7gYH55jw+PWo8GqFi542of15gXhUVcu4cFi5b+6ShSLk4QbRljtoHKNEFn/PM+hmvF3KmHkk5414jw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB6248.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(136003)(366004)(376002)(39860400002)(346002)(8936002)(110136005)(52536014)(2906002)(86362001)(54906003)(186003)(83380400001)(8676002)(26005)(6506007)(71200400001)(5660300002)(66946007)(55016002)(76116006)(66574015)(4326008)(66476007)(66556008)(64756008)(66446008)(9686003)(478600001)(316002)(91956017)(33656002)(7696005)(19607625011); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: HWwgurli0T2oCWMIrZ4pD6pAJfJjK0EDwU6J7mbUCc72KnOklheRsXY/ld1Fo2f+FVeGmMtqcmBnR0T4UVHGU4XjhukZy4RYxxU3VJjXXePerLT2rKpZVg1AoYQatka6Q+VIExpaQoQ4/u21FztWkwy283agQU2NtgNOxLG4qYzbzRW8DTKWHjoX58zQNFITPYbRy73xDtJJuVHB8/399kk8SGun2m2hrBvzR1x9DrC9dBUzhRt5kB8NuDMcty4z8SocbjM0ByG8uP/LBjRu4qvn2NMZ3QpecJz2STmiH++1HNCb2oEMVmZ89/6b8jUylzXffRQXqThwXmpmJRkVILgD/J2637906jp2BlAZlY9PEsusfsu7MFPD04JozfYztxmVAuwCOnpk0qhLkT+mLEZz4UWgU3E+L/3uteVkShb7kCERjsuQ73h6/ODBnYWpBdwtq2eFyz3GyWQsjf+THKna+QITvTAcBye5NK67tVGUC//783DO2km29I3VDJu6BfdrCkPp1Ab3jfun5ilc40blhsKaZiZSzVrbqSA2XlKuZxg1NBxnWd6CUT3kkW4Zede2u2NckEpdmoPpcrr2M2Ubxc3Firk0A1PB/ZxM5lNS6a8BHYZH0nR/cCdhFNkEasLicpUr6UcWADQ8FW7e/2U+4mCasN66ikCW+19R0l8KS+4pxNU3H5ijjmMDp7gpHOEtGG00BPWfZBVvGXEkkn4sn0sKpHX+I0Mtuq/f1O4gDFQK0S+x8jhQB70PU+lxUgi5yUfoMISX/8uOlgzQV+xiL7QkNc9mQuTLrnuNZPUA/SZAR3ufYM3Z4UMdpaqjsLBdaut7FLSE91XN3ox+mG+mgrDjLVUQBMumaFvwWxjpk2XHlSr1YTzD8X8P2RBn3t5LCh4zdIcTTIz4H9CjS6Z8gSlCCz3lJk6lV3j7a2S9LCjBxnZOekqn/uWzQHmtJPBq+EYw1INpd4pY3kynp8cRwBAfJoCF5CJfsReKrqw=
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: btconnect.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM7PR07MB6248.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6affe13f-5cd6-4f90-a9c2-08d8b7b1ddf8
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2021 10:56:23.2627 (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: TnR/ujiJmB3Bbm/hOEKN7nvfrav9JMZtCGsP+ISihdgCVFVKQvvp0FGnFlW/mt4iJ2BBDoVnGD+aKyfcI/B86Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB6167
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/9E_e6rBsWzHTW4ozDbEFvjlU0UA>
Subject: [netconf] Short prefix Re: Yangdoctors last call review of draft-ietf-netconf-trust-anchors-13
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: Wed, 13 Jan 2021 10:56:29 -0000
From: netconf <netconf-bounces@ietf.org> on behalf of Jürgen Schönwälder via Datatracker <noreply@ietf.org> Sent: 12 January 2021 18:41 Cc: last-call@ietf.org; netconf@ietf.org; draft-ietf-netconf-trust-anchors.all@ietf.org Subject: [netconf] Yangdoctors last call review of draft-ietf-netconf-trust-anchors-13 Reviewer: Jürgen Schönwälder Review result: Ready with Issues The crypto modules aim at providing a flexible reusable infrastructure of groupings for modeling cryptographic keys and related concepts. The flexibility of the definitions provided of course comes with a certain amount of complexity. >From a YANG perspective, draft-ietf-netconf-trust-anchors-13.txt is in a good and close to publish state (a couple of minor issues left). I also tried to understand what is being modeled here and hence I also have some questions concerning the concepts modeled and I hope these are easy to answer/resolve as well. - I have compiled the YANG modules using yanglint 0.16.105. - The prefix 'ts' is rather short, the set of two letter prefixes is rather small limited. This comment also applies to the other documents, crypto-types uses 'ct. Perhaps this is not a problem since collisions can be handled but if we go for rather short prefixes, we will have to exercise the collision resolution. (I see that 'ct' has already been used by ietf-complex-types, RFC 6095.) A possible alternative could be to use sec-ct, sec-ts, sec-ks, ...). <tp> I agree that two letter prefixes should be used sparingly, for widely deployed modules; interfaces is a good example. There is a bmwg module draft-vassilev-bmwg-network-interconnect-tester which uses ta and tg; I think that this is not a good example Tom Petch RFC 8407 provides the following guidelines (Section 4.2): Prefix values SHOULD be short but are also likely to be unique. Prefix values SHOULD NOT conflict with known modules that have been previously published. Well, having short and terse prefixes is actually nice and enhancing programmer readability. - s/is defines a truststore/defines a truststore/ - s/to be grouped references/to be grouped and referenced/ - In 2.2.1, I was not sure what CA certificates are and what EE certificates are. I then tried to guess EE = end entity cert, but this does not explain CA since the term used in crypto types is trust anchor cert. The description in the XML clarified that my guess was kind of correct. Perhaps explain upfront what these acronyms mean? Or perhaps the acronyms can be avoided by simply spelling things out? They do not appear to be used frequently. - s/<!-- Entity Certs/<!-- End Entity Certs/ - s/(Section 2.1.3.2), groupings/(Section 2.1.3.2) groupings/ - Is the feature truststore-supported really needed? Does the YANG library not already provide the information whether a module has been implemented or just imported to access type and grouping definitions? - In the YANG module, you seem to use Truststore to refer to /ts:truststore but in the surrounding text you also use just truststore. I am not sure it is necessary to have the capitalized version but if people think its necessary, it makes sense to define the difference and to make sure the proper capitalization is used throughout the document. (If it is necessary somewhere to be explicit, I would rather use /ts:truststore but that may be my subjective preference. Well, I started to use 'central truststore' below, not sure this is better as the term also would benefit from being defined.) - Does it make sense to be explicit about the fact that the cert/key references are all weak references in the sense that they can exist without the corresponding cert/key being present? In other words, in order to safely delete a cert/key, one would have to check that there are no dangling references left (which is difficult in case references are scattered over multiple (proprietary) data models). For YANG savvy people this may be obvious since there is no require-instance statement in the leafref type definition but not every implementer may recall this - and it would be good to document that using weak references was an explicit design decision and not an oversight. - Does it make sense to spell out that using the grouping in other YANG modules requires to define additional reference types since the ones provided by this modules only work for the central truststore store? And this as a consequence may require multiple leafs to refer to keys that exist in different truststores, i.e., having multiple truststores is possible but comes with a cost. - Would it make sense to add to all three documents an objectives section that summarizes the design objectives? For this module, a starting point might be this: 2.1. Objectives The design of the truststore data model was guided by the following design objectives: - provide a central truststore for storing keys or certificates - provide support for storing named bags of keys or certificates - provide types that can be used to reference keys or certificates stored in the central truststore - protect the truststore using suitable access control definitions - provide groupings that support locally configured keys or certificates or references to key or certificate bags in the central truststore - provide groupings that can be used to instantiate truststores in other data models (but this requires to introduce additional types to reference keys or certificates) I do not know whether this list is complete but I find it usually helpful to have the design objectives spelled out. - Section 3 talks about populating <running> with built-in trust anchors. In order for the built-in trust anchors to be referenced by configuration, the referenced certificates MUST first be copied into <running>. The certificates SHOULD be copied into <running> using the same "key" values, so that the server can bind them to the built- in entries. Is the idea that this copy operation is an explicit management operation or can implementations populate <running> with this data automatically? - Section 4.2 says: This module does not define any RPCs, actions, or notifications, and thus the security consideration for such is not provided here. Well, the module actually instantiates certificate-expiration notifications. - Registrant Contact: should be changed to the IESG. _______________________________________________ netconf mailing list netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf
- [netconf] Yangdoctors last call review of draft-i… Jürgen Schönwälder via Datatracker
- Re: [netconf] [Last-Call] Yangdoctors last call r… Michael Richardson
- [netconf] Short prefix Re: Yangdoctors last call … tom petch
- Re: [netconf] [Last-Call] Yangdoctors last call r… tom petch
- Re: [netconf] [Last-Call] Yangdoctors last call r… Juergen Schoenwaelder
- Re: [netconf] [Last-Call] Yangdoctors last call r… Kent Watsen
- Re: [netconf] [Last-Call] Yangdoctors last call r… Juergen Schoenwaelder
- Re: [netconf] [Last-Call] Yangdoctors last call r… Kent Watsen