Skip to main content

Last Call Review of draft-ietf-opsawg-mud-tls-10

Request Review of draft-ietf-opsawg-mud-tls-10
Requested revision 10 (document currently at 14)
Type Last Call Review
Team YANG Doctors (yangdoctors)
Deadline 2022-11-07
Requested 2022-10-18
Requested by Henk Birkholz
Authors Tirumaleswar Reddy.K , Dan Wing , Blake Anderson
I-D last updated 2022-12-09
Completed reviews Dnsdir Last Call review of -13 by R. (Miek) Gieben (diff)
Opsdir Last Call review of -13 by Qin Wu (diff)
Genart Last Call review of -13 by Christer Holmberg (diff)
Secdir Last Call review of -10 by Linda Dunbar (diff)
Yangdoctors Last Call review of -10 by Xufeng Liu (diff)
This is late in the process. The shepherd pointed out that this document never experienced the yangdoctors explicit attention. Considering the extensive discussion during adoption, I think a secdir review is also warranted at this stage. As this is so late and the request time is so close to the cut-off, I put the Monday of the IETF meeting as deadline. I hope that will not cause undue inconvenience.
Assignment Reviewer Xufeng Liu
State Completed
Request Last Call review on draft-ietf-opsawg-mud-tls by YANG Doctors Assigned
Posted at
Reviewed revision 10 (document currently at 14)
Result Ready w/issues
Completed 2022-12-09
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

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

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

Sec 10.1.

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


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

- Xufeng