Vladimir Vassilev <[email protected]> writes: > Hello, > > I have reviewed draft-acee-netmod-rfc8022bis-05. My conclusion is that > the YANG modules part of the draft have been successfully modified in > accordance with sec. '4.23.3 NMDA Transition Guidelines' of > draft-ietf-netmod-rfc6087bis-14. The modifications are coherent with the > [email protected] module in > draft-ietf-netmod-rfc7277bis-00 and [email protected] module in > draft-ietf-netmod-rfc7277bis-00. > > Vladimir > > > Review of draft-acee-netmod-rfc8022bis-05. > Vladimir Vassilev > 2017-10-30 > > 'Abstract': > 'Introduction 1': > - Both Abstract and Sec 1. contain duplicated text which can be removed > from Abstract. The text in Sec 1. can be simplified: > > OLD: > This version of these YANG modules uses new names for these YANG > models. The main difference from the first version is that this > version fully conforms to the Network Management Datastore > Architecture (NMDA). Consequently, this document obsoletes RFC 8022. > NEW: > This version of the Routing Management data model supports the Network > Management Datastore Architecture (NMDA) > [I-D.ietf-netmod-revised-datastores]. > > > '7. Routing Management YANG Module': > > - Why should address-family identity be different e.g. mandatory > "false"; for system created RIBs? I think this needs some explanation > (Page 21): > ... > uses address-family { > description > "Address family of the RIB. > > It is mandatory for user-controlled RIBs. For > system-controlled RIBs it can be omitted; otherwise, it > must match the address family of the corresponding state > entry."; > refine "address-family" { > mandatory "false"; > } > } > ... >
Following the logic of RFC 8022, address-family has to be a mandatory parameter for all RIB entries in <operational>, so there seems to be no other choice than make it "mandatory true" in the schema, as NMDA only has one schema for all datastores. Lada > - Suggested change of 'base address-family;' -> 'base > rt:address-family;' for identity ipv4 and ipv6 (ref. > draft-ietf-netmod-rfc6087bis-14#section-4.2): > > o The local module prefix MUST be used instead of no prefix in > all "default" statements for an "identityref" or "instance-identifier" > data type > > '8. IPv4 Unicast Routing Management YANG Module' > ([email protected]): > '9. IPv6 Unicast Routing Management YANG Module' > ([email protected]): > > > - The ietf-ipv4-unicast-routing and ietf-ipv6-unicast-routing modules > import the ietf-routing without revision (ref. rfc6087#section-4.6): > > > o The revision-date substatement within the imports statement SHOULD be > present if any groupings are used from the external module." > > > 'Appendix D. Data Tree Example': > > - The example in the Appendix D. has not been updated and it must be > extended in order to demonstrate a usecase of operational datastore of > configuration data with different origin (intended, system, etc.) > similar to the 'Appendix C. Example Data' of > draft-ietf-netmod-revised-datastores-05. > > > Nits: > - s/Figures 1/Figure 1/ > - s/systemindependently/system independently/ > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
