YANG Data Model for Network Instances
RFC 8529

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

Yes ( for -06)
No email
send info

(Adam Roach; former steering group member) No Objection

No Objection (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.

(Alissa Cooper; former steering group member) No Objection

No Objection ( for -09)
No email
send info

(Ben Campbell; former steering group member) No Objection

No Objection ( for -09)
No email
send info

(Benoît Claise; former steering group member) No Objection

No Objection (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.

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -09)
No email
send info

(Kathleen Moriarty; former steering group member) No Objection

No Objection ( for -09)
No email
send info

(Mirja Kühlewind; former steering group member) No Objection

No Objection (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?

(Spencer Dawkins; former steering group member) No Objection

No Objection ( for -09)
No email
send info

(Suresh Krishnan; former steering group member) No Objection

No Objection ( for -09)
No email
send info

(Terry Manderson; former steering group member) No Objection

No Objection ( for -09)
No email
send info