[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
- [OPSAWG] Yangdoctors last call review of draft-ie… Xufeng Liu via Datatracker
- Re: [OPSAWG] Yangdoctors last call review of draf… tirumal reddy