[OPSAWG] Yangdoctors last call review of draft-ietf-opsawg-mud-tls-10

Xufeng Liu via Datatracker <noreply@ietf.org> Sat, 10 December 2022 00:26 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: opsawg@ietf.org
Delivered-To: opsawg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C950C1522C2; Fri, 9 Dec 2022 16:26:14 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Xufeng Liu via Datatracker <noreply@ietf.org>
To: yang-doctors@ietf.org
Cc: draft-ietf-opsawg-mud-tls.all@ietf.org, last-call@ietf.org, opsawg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 9.2.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <167063197456.29432.6912041180293949341@ietfa.amsl.com>
Reply-To: Xufeng Liu <xufeng.liu.ietf@gmail.com>
Date: Fri, 09 Dec 2022 16:26:14 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/rJnfOS9coJKBL6D0bRswtp5mWHw>
Subject: [OPSAWG] Yangdoctors last call review of draft-ietf-opsawg-mud-tls-10
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.39
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Dec 2022 00:26:14 -0000

Reviewer: Xufeng Liu
Review result: Ready with Issues

This is a review of the YANG module in draft-ietf-opsawg-mud-tls-10.

Sec 5.1. and 5.2

1) The container “client-profile” is duplicated twice. Is there any reason for
the duplication?

2) As a convention, in IETF YANG modules, the node name of a list is in the
singular form. Above the list there can be a container with a name in the
plural form. For example, in RFC8519, there are a container “acls” and a list
“acl”. Using such a convention, the container “client-profile” would be better
named as “client-profiles”, and the list “tls-dtls-profiles” would be better
named as “tls-dtls-profile”. The same is applicable to other list names, such
as “tls-dtls-profiles”, “cipher-suites”, “extension-types”,  and
“signature-algorithms-cert”.

3) The leaf-list “acceptlist-ta-certs” can be better named as
“accept-list-ta-certs” per RFC8407.

4) Default values should be specified or explained for optional leaves like
“spki-hash-algorithm”.

5) The leaf “profile-name” is suggested to be renamed to “name”. As described
in Sec 4.3.1. of RFC8407, child nodes within a container or list SHOULD NOT
replicate the parent identifier.

Sec. 5.3. IANA (D)TLS profile YANG Module

1) This section indicates that there are no IANA-maintained values for
spki-pin-set, and certificate-authority parameters. If so, what are the reasons
to include these two types in this IANA YANG module? What do we expect IANA to
maintain and update?

Sec. 5.4. MUD (D)TLS Profile Extension

1) The file name of the YANG module is wrong. It seems to be a typo.

2) The statement “import ietf-mud” needs to have a “reference” sub-statement.

3) The leaf “is-tls-dtls-profile-supported” should have a default value or a
description of the default behavior.

Sec 7.

1) In the example, the leaf “profile-name” is needed as it is the key of the
list.

Sec 10.1.

1) For iana module, iana-tls-profile, instead of “Registrant Contact: IESG”, we
should have Registrant Contact: IANA

[Nit]:

1) The following code contains a line longer than 69 characters:
            leaf hash {
              type ianatp:hash-algorithm;
              description
                "Hash algorithm used with HKDF as defined in RFC5869.";
            }

Thanks,
- Xufeng