Last Call Review of draft-ietf-opsawg-mud-tls-10
review-ietf-opsawg-mud-tls-10-yangdoctors-lc-liu-2022-12-09-00
Request | Review of | draft-ietf-opsawg-mud-tls-10 |
---|---|---|
Requested revision | 10 (document currently at 18) | |
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) Dnsdir Telechat review of -15 by R. (Miek) Gieben (diff) |
|
Comments |
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 | https://mailarchive.ietf.org/arch/msg/yang-doctors/U1WCa4juDnmdlY5SaT6Mfddlty8 | |
Reviewed revision | 10 (document currently at 18) | |
Result | Ready w/issues | |
Completed | 2022-12-09 |
review-ietf-opsawg-mud-tls-10-yangdoctors-lc-liu-2022-12-09-00
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