A YANG Data Model for Layer 3 Topologies
RFC 8346

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

Alvaro Retana No Objection

Warren Kumari No Objection

Comment (2017-12-13 for -13)
No email
send info
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.

(Alia Atlas; former steering group member) Yes

Yes ( for -08)
No email
send info

(Benoît Claise; former steering group member) (was Discuss) Yes

Yes (2017-12-14)
No email
send info

(Alexey Melnikov; former steering group member) No Objection

No Objection ( for -08)
No email
send info

(Alissa Cooper; former steering group member) No Objection

No Objection (2017-01-18 for -08)
No email
send info
= 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.

(Ben Campbell; former steering group member) No Objection

No Objection (2017-12-13 for -13)
No email
send info
IDNits reports some unused references, please check.

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -08)
No email
send info

(Jari Arkko; former steering group member) No Objection

No Objection (2017-01-19 for -08)
No email
send info
Paul's Gen-ART comments did not receive a response, might be worth looking at them.

(Joel Jaeggli; former steering group member) No Objection

No Objection ( for -08)
No email
send info

(Kathleen Moriarty; former steering group member) No Objection

No Objection (2017-01-18 for -08)
No email
send info
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.

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

No Objection (2017-01-17 for -08)
No email
send info
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…

(Spencer Dawkins; former steering group member) No Objection

No Objection ( for -08)
No email
send info

(Suresh Krishnan; former steering group member) No Objection

No Objection (2017-01-18 for -08)
No email
send info
* 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?

(Terry Manderson; former steering group member) No Objection

No Objection ( for -08)
No email
send info