From nobody Wed Jan 13 02:56:30 2021
Return-Path: <ietfc@btconnect.com>
X-Original-To: yang-doctors@ietfa.amsl.com
Delivered-To: yang-doctors@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>,
 =?iso-8859-1?Q?J=FCrgen_Sch=F6nw=E4lder?=
 <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: =?iso-8859-1?Q?HWwgurli0T2oCWMIrZ4pD6pAJfJjK0EDwU6J7mbUCc72KnOklheRsXY/ld?=
 =?iso-8859-1?Q?1Fo2f+FVeGmMtqcmBnR0T4UVHGU4XjhukZy4RYxxU3VJjXXePerLT2rKpZ?=
 =?iso-8859-1?Q?Vg1AoYQatka6Q+VIExpaQoQ4/u21FztWkwy283agQU2NtgNOxLG4qYzbzR?=
 =?iso-8859-1?Q?W8DTKWHjoX58zQNFITPYbRy73xDtJJuVHB8/399kk8SGun2m2hrBvzR1x9?=
 =?iso-8859-1?Q?DrC9dBUzhRt5kB8NuDMcty4z8SocbjM0ByG8uP/LBjRu4qvn2NMZ3QpecJ?=
 =?iso-8859-1?Q?z2STmiH++1HNCb2oEMVmZ89/6b8jUylzXffRQXqThwXmpmJRkVILgD/J26?=
 =?iso-8859-1?Q?37906jp2BlAZlY9PEsusfsu7MFPD04JozfYztxmVAuwCOnpk0qhLkT+mLE?=
 =?iso-8859-1?Q?Zz4UWgU3E+L/3uteVkShb7kCERjsuQ73h6/ODBnYWpBdwtq2eFyz3GyWQs?=
 =?iso-8859-1?Q?jf+THKna+QITvTAcBye5NK67tVGUC//783DO2km29I3VDJu6BfdrCkPp1A?=
 =?iso-8859-1?Q?b3jfun5ilc40blhsKaZiZSzVrbqSA2XlKuZxg1NBxnWd6CUT3kkW4Zede2?=
 =?iso-8859-1?Q?u2NckEpdmoPpcrr2M2Ubxc3Firk0A1PB/ZxM5lNS6a8BHYZH0nR/cCdhFN?=
 =?iso-8859-1?Q?kEasLicpUr6UcWADQ8FW7e/2U+4mCasN66ikCW+19R0l8KS+4pxNU3H5ij?=
 =?iso-8859-1?Q?jmMDp7gpHOEtGG00BPWfZBVvGXEkkn4sn0sKpHX+I0Mtuq/f1O4gDFQK0S?=
 =?iso-8859-1?Q?+x8jhQB70PU+lxUgi5yUfoMISX/8uOlgzQV+xiL7QkNc9mQuTLrnuNZPUA?=
 =?iso-8859-1?Q?/SZAR3ufYM3Z4UMdpaqjsLBdaut7FLSE91XN3ox+mG+mgrDjLVUQBMumaF?=
 =?iso-8859-1?Q?vwWxjpk2XHlSr1YTzD8X8P2RBn3t5LCh4zdIcTTIz4H9CjS6Z8gSlCCz3l?=
 =?iso-8859-1?Q?Jk6lV3j7a2S9LCjBxnZOekqn/uWzQHmtJPBq+EYw1INpd4pY3kynp8cRwB?=
 =?iso-8859-1?Q?AfJoCF5CJfsReKrqw=3D?=
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/yang-doctors/i_n4tXs_su9z416YTotN6EWTmX4>
Subject: [yang-doctors] Short prefix Re: [netconf] Yangdoctors last call
 review of draft-ietf-netconf-trust-anchors-13
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email list of the yang-doctors directorate  <yang-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/yang-doctors>,
 <mailto:yang-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/yang-doctors/>
List-Post: <mailto:yang-doctors@ietf.org>
List-Help: <mailto:yang-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yang-doctors>,
 <mailto:yang-doctors-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=FCrgen Sch=F6nw=E4l=
der via Datatracker <noreply@ietf.org>=0A=
Sent: 12 January 2021 18:41=0A=
Cc: last-call@ietf.org; netconf@ietf.org; draft-ietf-netconf-trust-anchors.=
all@ietf.org=0A=
Subject: [netconf] Yangdoctors last call review of draft-ietf-netconf-trust=
-anchors-13=0A=
=0A=
Reviewer: J=FCrgen Sch=F6nw=E4lder=0A=
Review result: Ready with Issues=0A=
=0A=
The crypto modules aim at providing a flexible reusable infrastructure=0A=
of groupings for modeling cryptographic keys and related concepts. The=0A=
flexibility of the definitions provided of course comes with a certain=0A=
amount of complexity.=0A=
=0A=
>From a YANG perspective, draft-ietf-netconf-trust-anchors-13.txt is in=0A=
a good and close to publish state (a couple of minor issues left).  I=0A=
also tried to understand what is being modeled here and hence I also=0A=
have some questions concerning the concepts modeled and I hope these=0A=
are easy to answer/resolve as well.=0A=
=0A=
- I have compiled the YANG modules using yanglint 0.16.105.=0A=
=0A=
- The prefix 'ts' is rather short, the set of two letter prefixes is=0A=
  rather small limited. This comment also applies to the other=0A=
  documents, crypto-types uses 'ct. Perhaps this is not a problem=0A=
  since collisions can be handled but if we go for rather short=0A=
  prefixes, we will have to exercise the collision resolution. (I see=0A=
  that 'ct' has already been used by ietf-complex-types, RFC 6095.) A=0A=
  possible alternative could be to use sec-ct, sec-ts, sec-ks, ...).=0A=
=0A=
<tp>=0A=
I agree that two letter prefixes should be used sparingly, for widely deplo=
yed modules; interfaces is a good example.=0A=
=0A=
There is a bmwg module =0A=
draft-vassilev-bmwg-network-interconnect-tester  =0A=
which uses ta and tg;  I think that this is not a good example=0A=
=0A=
Tom Petch=0A=
=0A=
  RFC 8407 provides the following guidelines (Section 4.2):=0A=
=0A=
   Prefix values SHOULD be short but are also likely to be unique.=0A=
   Prefix values SHOULD NOT conflict with known modules that have been=0A=
   previously published.=0A=
=0A=
  Well, having short and terse prefixes is actually nice and enhancing=0A=
  programmer readability.=0A=
=0A=
- s/is defines a truststore/defines a truststore/=0A=
=0A=
- s/to be grouped references/to be grouped and referenced/=0A=
=0A=
- In 2.2.1, I was not sure what CA certificates are and what EE=0A=
  certificates are. I then tried to guess EE =3D end entity cert, but=0A=
  this does not explain CA since the term used in crypto types is=0A=
  trust anchor cert. The description in the XML clarified that my=0A=
  guess was kind of correct. Perhaps explain upfront what these=0A=
  acronyms mean? Or perhaps the acronyms can be avoided by simply=0A=
  spelling things out? They do not appear to be used frequently.=0A=
=0A=
- s/<!-- Entity Certs/<!-- End Entity Certs/=0A=
=0A=
- s/(Section 2.1.3.2), groupings/(Section 2.1.3.2) groupings/=0A=
=0A=
- Is the feature truststore-supported really needed? Does the YANG=0A=
  library not already provide the information whether a module has=0A=
  been implemented or just imported to access type and grouping=0A=
  definitions?=0A=
=0A=
- In the YANG module, you seem to use Truststore to refer to=0A=
  /ts:truststore but in the surrounding text you also use just=0A=
  truststore. I am not sure it is necessary to have the capitalized=0A=
  version but if people think its necessary, it makes sense to define=0A=
  the difference and to make sure the proper capitalization is used=0A=
  throughout the document. (If it is necessary somewhere to be=0A=
  explicit, I would rather use /ts:truststore but that may be my=0A=
  subjective preference. Well, I started to use 'central truststore'=0A=
  below, not sure this is better as the term also would benefit from=0A=
  being defined.)=0A=
=0A=
- Does it make sense to be explicit about the fact that the cert/key=0A=
  references are all weak references in the sense that they can exist=0A=
  without the corresponding cert/key being present? In other words, in=0A=
  order to safely delete a cert/key, one would have to check that=0A=
  there are no dangling references left (which is difficult in case=0A=
  references are scattered over multiple (proprietary) data models).=0A=
  For YANG savvy people this may be obvious since there is no=0A=
  require-instance statement in the leafref type definition but not=0A=
  every implementer may recall this - and it would be good to document=0A=
  that using weak references was an explicit design decision and not=0A=
  an oversight.=0A=
=0A=
- Does it make sense to spell out that using the grouping in other=0A=
  YANG modules requires to define additional reference types since the=0A=
  ones provided by this modules only work for the central truststore=0A=
  store? And this as a consequence may require multiple leafs to refer=0A=
  to keys that exist in different truststores, i.e., having multiple=0A=
  truststores is possible but comes with a cost.=0A=
=0A=
- Would it make sense to add to all three documents an objectives=0A=
  section that summarizes the design objectives? For this module,=0A=
  a starting point might be this:=0A=
=0A=
  2.1.  Objectives=0A=
=0A=
  The design of the truststore data model was guided by the following=0A=
  design objectives:=0A=
=0A=
  - provide a central truststore for storing keys or certificates=0A=
  - provide support for storing named bags of keys or certificates=0A=
  - provide types that can be used to reference keys or certificates=0A=
    stored in the central truststore=0A=
  - protect the truststore using suitable access control definitions=0A=
  - provide groupings that support locally configured keys or=0A=
    certificates or references to key or certificate bags in the=0A=
    central truststore=0A=
  - provide groupings that can be used to instantiate truststores=0A=
    in other data models (but this requires to introduce additional=0A=
    types to reference keys or certificates)=0A=
=0A=
  I do not know whether this list is complete but I find it usually=0A=
  helpful to have the design objectives spelled out.=0A=
=0A=
- Section 3 talks about populating <running> with built-in trust=0A=
  anchors.=0A=
=0A=
   In order for the built-in trust anchors to be referenced by=0A=
   configuration, the referenced certificates MUST first be copied into=0A=
   <running>.  The certificates SHOULD be copied into <running> using=0A=
   the same "key" values, so that the server can bind them to the built-=0A=
   in entries.=0A=
=0A=
  Is the idea that this copy operation is an explicit management=0A=
  operation or can implementations populate <running> with this=0A=
  data automatically?=0A=
=0A=
- Section 4.2 says:=0A=
=0A=
   This module does not define any RPCs, actions, or notifications, and=0A=
   thus the security consideration for such is not provided here.=0A=
=0A=
  Well, the module actually instantiates certificate-expiration=0A=
  notifications.=0A=
=0A=
- Registrant Contact: should be changed to the IESG.=0A=
=0A=
=0A=
=0A=
_______________________________________________=0A=
netconf mailing list=0A=
netconf@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/netconf=0A=

