Re: [netconf] [Last-Call] Genart last call review of draft-ietf-netconf-crypto-types-28
"Salz, Rich" <rsalz@akamai.com> Mon, 22 January 2024 15:49 UTC
Return-Path: <rsalz@akamai.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 0F32BC14CF15; Mon, 22 Jan 2024 07:49:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.805
X-Spam-Level:
X-Spam-Status: No, score=-2.805 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, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVdhzK8G_wTJ; Mon, 22 Jan 2024 07:49:09 -0800 (PST)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCB5BC14F70F; Mon, 22 Jan 2024 07:49:06 -0800 (PST)
Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.17.1.24/8.17.1.24) with ESMTP id 40MCWiYD003433; Mon, 22 Jan 2024 15:49:06 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h= from:to:cc:subject:date:message-id:references:in-reply-to :content-type:content-id:content-transfer-encoding:mime-version; s=jan2016.eng; bh=giQFikcU46Wq2XJH5J8JTwt4Gp2hAGTKeW79fiYvVuM=; b= UWq6AWJCgeiqKQJZ+5nRlp6mJn8gvguBw9WF9/fp3kehew2uKxvWe+UFVDP1FawO kfi9RcKI3J2ABkhwKt6B/gbsVHRsRVuU6A08HR/pm86Yfd3yuGHRq82UvQrhrwVe Gx/bMr84E+gNDdEp/y8Q/KWHlyr6R0s4KAs2c9iPeJUb56uRpfzD9ymp20tFhaeX 8KybiC59d+AnaVyNr8yCENQdKF/3NBw7CuxW7ly0/8TjVej8WUwCIjKkS37vQ1cm 7BZrB4CBod+hy2REuIZF6GEWv3wIn46jv9ACsHHwSZCFGogBNuGLZVdpuNufXNeU FNn0wPSNRE/f5C0JMnvV+g==
Received: from prod-mail-ppoint7 (a72-247-45-33.deploy.static.akamaitechnologies.com [72.247.45.33] (may be forged)) by m0050093.ppops.net-00190b01. (PPS) with ESMTPS id 3vr6aungh1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 22 Jan 2024 15:49:05 +0000 (GMT)
Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.17.1.19/8.17.1.19) with ESMTP id 40MEdMMR009364; Mon, 22 Jan 2024 10:49:04 -0500
Received: from email.msg.corp.akamai.com ([172.27.50.206]) by prod-mail-ppoint7.akamai.com (PPS) with ESMTPS id 3vrad1xnt1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 22 Jan 2024 10:49:04 -0500
Received: from ustx2ex-dag4mb4.msg.corp.akamai.com (172.27.50.203) by ustx2ex-dag4mb7.msg.corp.akamai.com (172.27.50.206) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Mon, 22 Jan 2024 07:49:04 -0800
Received: from ustx2ex-dag4mb4.msg.corp.akamai.com ([172.27.50.203]) by ustx2ex-dag4mb4.msg.corp.akamai.com ([172.27.50.203]) with mapi id 15.02.1258.028; Mon, 22 Jan 2024 07:49:04 -0800
From: "Salz, Rich" <rsalz@akamai.com>
To: Kent Watsen <kent@watsen.net>
CC: "draft-ietf-netconf-crypto-types.all@ietf.org" <draft-ietf-netconf-crypto-types.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [Last-Call] Genart last call review of draft-ietf-netconf-crypto-types-28
Thread-Index: AQHaTUo9E7933THi7EGEzesEtn6JirDmLMGA
Date: Mon, 22 Jan 2024 15:49:04 +0000
Message-ID: <5E3EADC9-556B-425D-B5C1-69A7978B2E4B@akamai.com>
References: <170593840890.54102.14012506624636913765@ietfa.amsl.com>
In-Reply-To: <170593840890.54102.14012506624636913765@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.80.23121017
x-originating-ip: [172.27.118.139]
Content-Type: text/plain; charset="utf-8"
Content-ID: <65A400C4BC712C43BB6200BF73E17A60@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-01-22_06,2024-01-22_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 mlxlogscore=999 suspectscore=0 spamscore=0 malwarescore=0 adultscore=0 bulkscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311290000 definitions=main-2401220108
X-Proofpoint-ORIG-GUID: -Z2GPaATXf7D07CgT7NXlZOkTRX66bRA
X-Proofpoint-GUID: -Z2GPaATXf7D07CgT7NXlZOkTRX66bRA
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-01-22_05,2024-01-22_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 phishscore=0 impostorscore=0 mlxlogscore=999 clxscore=1011 suspectscore=0 malwarescore=0 adultscore=0 mlxscore=0 priorityscore=1501 lowpriorityscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2311290000 definitions=main-2401220107
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/-C8fz3GMi5MxJZgmL02Nh56j57U>
Subject: Re: [netconf] [Last-Call] Genart last call review of draft-ietf-netconf-crypto-types-28
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.39
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: Mon, 22 Jan 2024 15:49:14 -0000
Seems the Netconf Crypto stuff is almost out the door. Congrats! On 1/22/24, 10:47 AM, "last-call on behalf of Dale Worley via Datatracker" <last-call-bounces@ietf.org <mailto:last-call-bounces@ietf.org> on behalf of noreply@ietf.org <mailto:noreply@ietf.org>> wrote: Reviewer: Dale Worley Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://urldefense.com/v3/__https://trac.ietf.org/trac/gen/wiki/GenArtfaq__;!!GjvTz_vk!WP1AIKvopR5fAdu49leEn5l7T1tMA_QG7ZaNEffIBzhPf06pDJ1-Cn9DM1WCQcq3yAUrgUv7BWgy$ <https://urldefense.com/v3/__https://trac.ietf.org/trac/gen/wiki/GenArtfaq__;!!GjvTz_vk!WP1AIKvopR5fAdu49leEn5l7T1tMA_QG7ZaNEffIBzhPf06pDJ1-Cn9DM1WCQcq3yAUrgUv7BWgy$> >. Document: review-draft-ietf-netconf-crypto-types-28 Reviewer: Dale R. Worley Review Date: 2024-01-22 IETF LC End Date: 2024-01-24 IESG Telechat date: [not known] Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Nits/editorial comments: Editorial Note (To be removed by RFC Editor) Tree-diagrams in this draft may use the '/' line-folding mode defined in RFC 8792. However, nicer-to-the-eye is when the '//' line-folding mode is used. The AD suggested suggested putting a request here for the RFC Editor to help convert "ugly" '/' folded examples to use the '//' folding mode. "Help convert" may be interpreted as, identify what looks ugly and ask the authors to make the adjustment. Throughout this paragraph, slash '/' should be replaced by backslash '\'. 1.1. Relation to other RFCs The dependency relationship between the primary YANG groupings defined in the various RFCs is presented in the below diagram. Perhaps there is a convention that I am not aware of, but when I see in the figure e.g. crypto-types ^ ^ / \ / \ truststore keystore does that mean that crypto-types contains a reference to truststore, or does it mean that truststore contains a reference to crypto-types? The usual convention is that arrows point from referencer to referenced, but also the usual convention is that the referenced thing is written physically below the referencer. Perhaps add an explanatory sentence. Table 1: Label to RFC Mapping In -28, this caption appears visually to be the caption of both the dependency diagram at the top of page 5 and the label-to-RFC mapping table at the bottom of page 5, and so probably should be amended to describe both of them together. 1.4. Conventions Various examples used in this document use a placeholder value for binary data that has been base64 encoded (e.g., "BASE64VALUE="). This would be clearer if it stated directly that the (only) placeholder value used is "BASE64VALUE=". Perhaps Various examples in this document use "BASE64VALUE=" as a placeholder value for (usually binary) data has has been base64 encoded. 2.1.2. Identities +-- csr-format +-- p10-csr-format {p10-csr-format?} This construct ends with "?}", whereas a number of other constructs end with "}?". Are all of these correct? 2.1.3. Typedefs * Additionally, all the typedefs define a type for encoding an ASN.1 [ITU.X680.2021] structure using DER [ITU.X690.2021]. It seems like it would be useful to have a typedef "asn-1-der" that extends "binary", to be used specifically for DER-encoded ASN.1 data, and which in turn is extended here. E.g. binary +-- asn-1-der +-- csr-info +-- csr +-- x509 | +-- trust-anchor-cert-x509 ... Unfortunately, what would make such an extended type valuable is that DER-encoded ASH.1 strings are used in a number of RFCs, which means that this document might not be the best place to introduce such an extended type. 2.3. YANG Module I am no expert on Yang, so my examination of the module itself was superficial. The Datatracker says that Yang doctors looked at -18 on 2021-01-12, which presumably means that -19 reflected their report. The differences between the module in -19 and -28 appear to me to to be minor. 3.5. Strength of Keys Conveyed ... it is desireable ... Wiktionary describes "desireable" as "an archaic form of desirable". The RFC Editor's opinion on this should probably be sought. 3.10. The "ietf-crypto-types" YANG Module The title of this section seems to be uninformative given that 'The "ietf-crypto-types" YANG Module' is the subject of the entire document. Is this title what was intended? Some of the readable data nodes defined in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability: The use of "These" in the last sentence does not have an unambiguous referent as I read it. Perhaps "These subtrees/data nodes have these particular sensitivities/vulnerabilities:" Similar considerations apply to the last sentence of: Some of the operations in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control access to these operations. These are the operations and their sensitivity/vulnerability: [END] -- last-call mailing list last-call@ietf.org <mailto:last-call@ietf.org> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/last-call__;!!GjvTz_vk!WP1AIKvopR5fAdu49leEn5l7T1tMA_QG7ZaNEffIBzhPf06pDJ1-Cn9DM1WCQcq3yAUrgV8TlRY0$ <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/last-call__;!!GjvTz_vk!WP1AIKvopR5fAdu49leEn5l7T1tMA_QG7ZaNEffIBzhPf06pDJ1-Cn9DM1WCQcq3yAUrgV8TlRY0$>
- [netconf] Genart last call review of draft-ietf-n… Dale Worley via Datatracker
- Re: [netconf] [Last-Call] Genart last call review… Salz, Rich
- Re: [netconf] Genart last call review of draft-ie… Kent Watsen
- Re: [netconf] [Last-Call] Genart last call review… Kent Watsen
- Re: [netconf] Genart last call review of draft-ie… worley
- Re: [netconf] Genart last call review of draft-ie… Kent Watsen
- Re: [netconf] Genart last call review of draft-ie… worley
- Re: [netconf] [Gen-art] Genart last call review o… Lars Eggert
- Re: [netconf] [Gen-art] Genart last call review o… mohamed.boucadair