A YANG Data Model for Routing Information Protocol (RIP)
draft-ietf-rtgwg-yang-rip-11

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

(Alia Atlas) Yes

Deborah Brungard No Objection

(Ben Campbell) No Objection

(Benoît Claise) (was No Record, No Objection) No Objection

Comment (2018-01-11 for -08)
No email
send info
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).

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

Suresh Krishnan No Objection

Warren Kumari No Objection

Comment (2018-01-10 for -08)
No email
send info
Balloting No Objection ("I read the protocol action, and I trust the sponsoring AD so have no problem.") - ran out of time to review.

Mirja Kühlewind No Objection

Alexey Melnikov No Objection

(Kathleen Moriarty) (was Discuss) No Objection

Comment (2018-01-10 for -08)
No email
send info
Thanks for applying the Security Considerations template.

(Eric Rescorla) No Objection

Alvaro Retana No Objection

Adam Roach No Objection

Comment (2018-01-10 for -08)
No email
send info
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.