YANG Data Model for Network Instances
RFC 8529
Yes
No Objection
Note: This ballot was opened for revision 06 and is now closed.
Alvaro Retana No Objection
Warren Kumari No Objection
(Alia Atlas; former steering group member) Yes
(Adam Roach; former steering group member) No Objection
All of the examples in §B.1 use IPv4 addresses exclusively. Please update these to use all-IPv6 or a mix of IPv4 and IPv6. See <https://www.iab.org/2016/11/07/iab-statement-on-ipv6/> for details.
(Alissa Cooper; former steering group member) No Objection
(Ben Campbell; former steering group member) No Objection
(Benoît Claise; former steering group member) No Objection
Same remark as in https://datatracker.ietf.org/doc/draft-ietf-rtgwg-lne-model/ballot/#benoit-claise The title should be: "YANG module for network instance" This document is NMDA compliant. I should be clearly mentioned. Like in the RFC7223bis abstract. No need to repeat the tree-diagram reference in: The NI model can be represented using the tree format defined in [I-D.ietf-netmod-yang-tree-diagrams] as: Like for the LNE YANG module, you still have the -state in the example. ================================================================ Some more feedback from Martin Bjorklund, as YANG doctor: In 3.1 they have: The network-instance module is structured to facilitate the definition of information models for specific types ^^^^^^^^^^^^^^^^^^ This should probably be "data models" -------------------------------- In 3.1 they show the pre-NMDA split tree: augment "/ni:network-instances/ni:network-instance/ni:ni-type" { case l3vpn { container l3vpn { ... } container l3vpn-state { ... } } } this should be just: augment "/ni:network-instances/ni:network-instance/ni:ni-type" { case l3vpn { container l3vpn { ... } } } -------------------------------- same in 3.1.2: +--rw (ni-type)? | +--:(l3vpn) | +--rw l3vpn:l3vpn | | ... // config data | +--ro l3vpn:l3vpn-state | | ... // state data should be +--rw (ni-type)? | +--:(l3vpn) | +--rw l3vpn:l3vpn | | ... ------------------- The example in appendix B.2 uses "ietf-routing:routing-state" and "ietf-interfaces:interfaces-state" but that node is pre-NMDA, and deprecated in 8022bis and 7022bis. This example should probably be updated.
(Deborah Brungard; former steering group member) No Objection
(Kathleen Moriarty; former steering group member) No Objection
(Mirja Kühlewind; former steering group member) No Objection
Two minor editorial comments: 1) Sec 1.2: I'm surprised to see an open issue listed here. Is there already any plan to address this somehow or is that listed to inform the reader, however, in the second case I would probably rather call it 'limitation' or something like this... 2) Sec 2: "In this document, we consider network devices that support protocols and functions defined within the IETF Routing Area, e.g, routers, firewalls, and hosts. " I assume that this yang module can also be used for routing protocols and functions that have not been defined in the IETF?
(Spencer Dawkins; former steering group member) No Objection
(Suresh Krishnan; former steering group member) No Objection
(Terry Manderson; former steering group member) No Objection