YANG Data Model for Network Instances
RFC 8529

Note: This ballot was opened for revision 06 and is now closed.

(Alia Atlas) Yes

Deborah Brungard No Objection

(Ben Campbell) No Objection

(Benoît Claise) No Objection

Comment (2018-02-08 for -09)
No email
send info
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.

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

(Suresh Krishnan) No Objection

Warren Kumari No Objection

(Mirja Kühlewind) No Objection

Comment (2018-02-05 for -08)
No email
send info
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?

(Terry Manderson) No Objection

(Kathleen Moriarty) No Objection

Alvaro Retana No Objection

(Adam Roach) No Objection

Comment (2018-02-07 for -09)
No email
send info
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.