A YANG Data Model for the Routing Information Protocol (RIP)
draft-ietf-rtgwg-yang-rip-11
Yes
(Alia Atlas)
No Objection
(Alexey Melnikov)
(Alissa Cooper)
(Alvaro Retana)
(Ben Campbell)
(Deborah Brungard)
(Eric Rescorla)
(Mirja Kühlewind)
(Spencer Dawkins)
(Suresh Krishnan)
Note: This ballot was opened for revision 07 and is now closed.
Warren Kumari
No Objection
Comment
(2018-01-10 for -08)
Unknown
Balloting No Objection ("I read the protocol action, and I trust the sponsoring AD so have no problem.") - ran out of time to review.
Alia Atlas Former IESG member
Yes
Yes
(for -07)
Unknown
Adam Roach Former IESG member
No Objection
No Objection
(2018-01-10 for -08)
Unknown
I have a few minor comments. In the YANG module, I find this definition: leaf address { type inet:ip-prefix; description "IPv4 address, in the form A.B.C.D, and the prefix length, separated by the slash (/) character; or IPv6 address, in the form A:B:C:D:E:F:G:H, and the prefix length, separated by the slash (/) character."; } The description -- which clearly says that IPv6 addresses need to be represented as eight discreet components -- implies that the use of :: (https://tools.ietf.org/html/rfc5952#section-4.1) and embedded IPv4 addresses (https://tools.ietf.org/html/rfc5952#section-5) is forbidden. This seems to be a restriction above and beyond that defined for ipv6-prefix in RFC 6991. Since I don't find any explanation of this in the accompanying text, I suspect this is an error. I think you want to cite RFC 5952 rather than trying to to describe the various valid formats for IPv6 addresses here. ____ I believe you want to update the copyright date that appears at the top of the YANG module definition. ____ Please consider updating the example in appendix A to conform to the IAB guidance found at <https://www.iab.org/2016/11/07/iab-statement-on-ipv6/>. This would involve changing the example to use IPv6 instead of IPv4, or adding an IPv6 example in addition to the IPv4 example.
Alexey Melnikov Former IESG member
No Objection
No Objection
(for -07)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(for -08)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(for -07)
Unknown
Ben Campbell Former IESG member
No Objection
No Objection
(for -07)
Unknown
Benoît Claise Former IESG member
(was No Record, No Objection)
No Objection
No Objection
(2018-01-11 for -08)
Unknown
Looking at the YANG modules dependencies. See https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-rip@2018-01-09.yang&recurse=0&rfcs=1&show_subm=1&show_dir=dependencies I would appreciate an update from the RTG ADs on these 3 normative references: [I-D.ietf-bfd-yang] Rahman, R., Zheng, L., Jethanandani, M., Networks, J., and G. Mirsky, "YANG Data Model for Bidirectional Forwarding Detection (BFD)", draft-ietf-bfd-yang-07 (work in progress), October 2017. [I-D.ietf-isis-yang-isis-cfg] Litkowski, S., Yeung, D., Lindem, A., Zhang, Z., and L. Lhotka, "YANG Data Model for IS-IS protocol", draft-ietf- isis-yang-isis-cfg-19 (work in progress), November 2017. [I-D.ietf-ospf-yang] Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem, "Yang Data Model for OSPF Protocol", draft-ietf-ospf- yang-09 (work in progress), October 2017. Any risk that the content will change and impact the YANG module in draft-ietf-rtgwg-yang-rip? All other YANG module dependencies are either on this telechat or the next one (RFC8022bis).
Deborah Brungard Former IESG member
No Objection
No Objection
(for -08)
Unknown
Eric Rescorla Former IESG member
No Objection
No Objection
(for -08)
Unknown
Kathleen Moriarty Former IESG member
(was Discuss)
No Objection
No Objection
(2018-01-10 for -08)
Unknown
Thanks for applying the Security Considerations template.
Mirja Kühlewind Former IESG member
No Objection
No Objection
(for -07)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -07)
Unknown
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -08)
Unknown