A YANG Data Model for Network Topologies
draft-ietf-i2rs-yang-network-topo-20
Yes
(Alia Atlas)
No Objection
Warren Kumari
(Alexey Melnikov)
(Alvaro Retana)
(Deborah Brungard)
(Mirja Kühlewind)
(Spencer Dawkins)
(Suresh Krishnan)
(Terry Manderson)
Note: This ballot was opened for revision 09 and is now closed.
Warren Kumari
No Objection
Alia Atlas Former IESG member
Yes
Yes
(for -09)
Unknown
Benoît Claise Former IESG member
(was No Objection, Discuss, No Objection)
Yes
Yes
(2017-12-14 for -19)
Unknown
We're good now. Thanks, Benoit
Alexey Melnikov Former IESG member
No Objection
No Objection
(for -10)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(2017-01-05 for -10)
Unknown
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?
Alvaro Retana Former IESG member
No Objection
No Objection
(2017-12-11 for -18)
Unknown
Ben Campbell Former IESG member
No Objection
No Objection
(2017-12-13 for -19)
Unknown
My comments appear to have been addressed in the discussion resulting from Kathleen's DISCUSS.
Deborah Brungard Former IESG member
No Objection
No Objection
(for -10)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(2017-01-05 for -10)
Unknown
Stewart Bryant's Gen-ART comments are worthwhile to look at. Did the authors see them?
Joel Jaeggli Former IESG member
No Objection
No Objection
(2017-01-01 for -09)
Unknown
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 IESG member
(was Discuss)
No Objection
No Objection
(2017-12-20)
Unknown
Thanks for your work on this draft and addressing my discuss point.
Mirja Kühlewind Former IESG member
No Objection
No Objection
(for -10)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -10)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2017-01-05 for -10)
Unknown
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 IESG member
No Objection
No Objection
(for -10)
Unknown
Terry Manderson Former IESG member
No Objection
No Objection
(for -10)
Unknown