A YANG Data Model for Layer 3 Topologies
draft-ietf-i2rs-yang-l3-topology-16

I have nothing substantive - obviously, Benoit's discuss needs to be addressed.

A nit (which the RFC Editor would have / will catch: 
 Section 9.  Security Considerations
 l3-topology-attributes: A malicious client could attempt to
      sabotage the configuration of any of the ctonained attributes,
      i.e. the name or the flag data nodes.
"ctonained " is a typo.

= Section 2 =

HTTP and ReST are defined, but they aren't used anywhere else in the
document in a way that requires definition.

= Section 5 =

"case interface-name {
             leaf interface-name {
               type string;
               description
                 "A name of the interface.  The name can (but does not
                  have to) correspond to an interface reference of a
                  containing node's interface, i.e. the path name of a
                  corresponding interface data node on the containing
                  node reminiscent of data type if-ref defined in
                  RFC 7223. It should be noted that data type if-ref of
                  RFC 7223 cannot be used directly, as this data type
                  is used to reference an interface in a datastore of
                  a single node in the network, not to uniquely
                  reference interfaces across a network.";
             }
           }"

In RFC 7223 the data type appears to be called interface-ref, not if-ref. Would an example of this in this document be, say, a MAC address? 

= Section 6.1.1 and 6.2.1 =

While notational explanations are given for "?," "*," etc., none is given for "!".

= Section 9 =

This section is missing a discussion of the potential sensitivity of the data this module exposes even in a read-only use case. Filling in the template at https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines and adding the text to this section should get that covered.

IDNits reports some unused references, please check.

Paul's Gen-ART comments did not receive a response, might be worth looking at them.

I agree with Alissa's comment that the YANG module security consideration section guidelines need to be followed and this shouldn't go forward until that is corrected.  I'm told it will be, thanks.

Two high level comments (please note that I’m not a yang expert and if this model is considered right by the vendor community that want to use it, I’m fine with it):
1) I’m not sure about the usefulness of the flag attribute, given that’s a very general reference to some kind of unspecified information (and it’s also not used in the examples as far as I can see)
2) Why are the is-is and ospf models only given as examples instead of also specifying them completely in this draft. These parts atually seem to me to be the more interesting bits of work…

* Section 3

OSPF and IS-IS are used later in the document as examples but this section (especially Figure 1) seems to treat them as more than examples. What is the actual intent? Is this draft supposed to be the canonical definition of ospf-topology and isis-topology? Please clarify.

* Section 4

Is there a reason that router-id is defined as capable of having multiple instances?