YANG Data Model for Network Instances
draft-ietf-rtgwg-ni-model-12

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.

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.

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?