Telechat Review of draft-ietf-netmod-rfc8022bis-07
review-ietf-netmod-rfc8022bis-07-opsdir-telechat-clarke-2018-01-06-00
Request | Review of | draft-ietf-netmod-rfc8022bis |
---|---|---|
Requested revision | No specific revision (document currently at 11) | |
Type | Telechat Review | |
Team | Ops Directorate (opsdir) | |
Deadline | 2018-01-23 | |
Requested | 2017-12-27 | |
Authors | Ladislav Lhotka , Acee Lindem , Yingzhen Qu | |
I-D last updated | 2018-01-06 | |
Completed reviews |
Yangdoctors Early review of -05
by Martin Björklund
(diff)
Secdir Telechat review of -10 by Carl Wallace (diff) Genart Telechat review of -06 by Francis Dupont (diff) Opsdir Telechat review of -07 by Joe Clarke (diff) Rtgdir Telechat review of -08 by He Jia (diff) |
|
Assignment | Reviewer | Joe Clarke |
State | Completed | |
Request | Telechat review on draft-ietf-netmod-rfc8022bis by Ops Directorate Assigned | |
Reviewed revision | 07 (document currently at 11) | |
Result | Ready | |
Completed | 2018-01-06 |
review-ietf-netmod-rfc8022bis-07-opsdir-telechat-clarke-2018-01-06-00
I am completing this review as a representative of the ops directorate. This document describes an NMDA-compliant version of the ietf-routing family of YANG modules that obsoletes the revisions in RFC8022. Overall, I feel this document is ready, with some very minor spelling nits. The only substantive comment I have is in the comments ahead of the now-obsolete state branches. Currently, these comments just state "Obsolete State Data". I wonder if it would make sense to add a bit more text here to reference why these branches are now obsolete. Perhaps a reference to the NMDA document would be beneficial. Spelling-wise, search for Managment. There are four instances in the YANG modules themselves. Obviously, these should be "Management". Another minor nit I noticed (and this is likely an issue with pyang) is that when using a grouping, the YANG tree lists nodes like routing-state -> router-id with a '+' instead of a 'o' (i.e., indicating obsolete). Not a big deal since the parent container is obsolete. One comment I have is that the imports clauses here definitely point out a need to be able to import by some kind of version that will allow to set a minimum requirement (e.g., import by semantic version). Having comments such as are in the modules now are not machine-consumable, and will likely cause operational challenges for those that do not pay attention.