A YANG Data Model for Network Topologies
draft-ietf-i2rs-yang-network-topo-20

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

Alvaro Retana No Objection

Warren Kumari No Objection

(Alia Atlas; former steering group member) Yes

Yes ( for -09)
No email
send info

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

Yes (2017-12-14 for -19)
No email
send info
We're good now.

Thanks, Benoit

(Alexey Melnikov; former steering group member) No Objection

No Objection ( for -10)
No email
send info

(Alissa Cooper; former steering group member) No Objection

No Objection (2017-01-05 for -10)
No email
send info
I agree with Kathleen's comments and always find it helpful when the security considerations templates are used in YANG documents as Juergen and Benoit suggested.

= Section 3 =

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

= Section 6.1 =

"leaf server-provided {
           type boolean;
           config false;
           description
             "Indicates whether the information concerning this
              particular network is populated by the server
              (server-provided true, the general case for network
              information discovered from the server),
              or whether it is configured by a client
              (server-provided true, possible e.g. for
              service overlays managed through a controller)."

I think the second instance of "server-provided true" is actually supposed to say "server-provided false," right?

(Ben Campbell; former steering group member) No Objection

No Objection (2017-12-13 for -19)
No email
send info
My comments appear to have been addressed in the discussion resulting from Kathleen's DISCUSS.

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -10)
No email
send info

(Jari Arkko; former steering group member) No Objection

No Objection (2017-01-05 for -10)
No email
send info
Stewart Bryant's Gen-ART comments are worthwhile to look at. Did the authors see them?

(Joel Jaeggli; former steering group member) No Objection

No Objection (2017-01-01 for -09)
No email
send info
seems worthwhile that the misref

draft-ietf-i2rs-ephemeral-state

be converged with this one for publication.

don't expect that's a big deal.

(Kathleen Moriarty; former steering group member) (was Discuss) No Objection

No Objection (2017-12-20)
No email
send info
Thanks for your work on this draft and addressing my discuss point.

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

No Objection ( for -10)
No email
send info

(Spencer Dawkins; former steering group member) No Objection

No Objection ( for -10)
No email
send info

(Stephen Farrell; former steering group member) No Objection

No Objection (2017-01-05 for -10)
No email
send info
I agree with Kathleen's discuss points and have one
more aspect to offer that I hope you include in that
discussion:

This model I think will lead designers to only think
about the nodes that are supposed to have access to
traffic.  (See also below about broadcast media.) The
model will generally not capture the reality that some
other nodes can also actually see or influence traffic
and I think that will lead to vulnerabilities not
being recognised. I don't have a good suggestion for
how to fix that problem but I do think you ought
mention it as a security consideration, e.g. something
like: "For models such as these - the real world
network may allow additional communications or links
that are not represented in the model and such links
may enable vulnerabilities that are liable to be
missed when considering only the model. These models
don't really capture the security or privacy aspects
of the network." 

- 4.2 and generally: It is not clear to me how to
represent broadcast media (e.g. radio) nor how IP
multicast would be reflected in this model. I assume
those can be done but as a bit of a hack.  

- nit: 6 authors and 4 contributors. I wish people
(esp chairs) would just enforce the 5 author guideline
and say why that's inappropriate in the few instances
in which that is the case.

(Suresh Krishnan; former steering group member) No Objection

No Objection ( for -10)
No email
send info

(Terry Manderson; former steering group member) No Objection

No Objection ( for -10)
No email
send info