Last Call Review of draft-ietf-netmod-routing-cfg-24

Request Review of draft-ietf-netmod-routing-cfg
Requested rev. no specific revision (document currently at 25)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2016-11-01
Requested 2016-10-22
Authors Ladislav Lhotka, Acee Lindem
Draft last updated 2016-11-08
Completed reviews Genart Last Call review of -24 by Brian Carpenter (diff)
Genart Last Call review of -24 by Brian Carpenter (diff)
Opsdir Last Call review of -24 by Tim Chown (diff)
Assignment Reviewer Tim Chown 
State Completed
Review review-ietf-netmod-routing-cfg-24-opsdir-lc-chown-2016-11-08
Reviewed rev. 24 (document currently at 25)
Review result Has Nits
Review completed: 2016-11-08



I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments. 

This draft specifies a set of YANG data modules (ietf-routing, ietf-ipv4-unicast-routing, and ietf-ipv6-unicast-routing) and a submodule (ietf-ipv6-router-advertisements) that together form a core routing data model framework for configuring and managing a routing subsystem. It is expected that further modules will follow for control plane protocols, route filters and other functions, to be specified in other IETF WGs.

I am not a YANG guru, but I found the document well structured, and both intuitive and easy to follow. The quality of the writing is very good.

I only have one minor point to make, namely that there are some configuration variables that one might argue could be added in Section 5.4 for the ietf-ipv6-router-advertisements module. The listed variables do not appear to include RDNSS as specified in RFC6106, and support for RFC4191, for router preferences, is also not included. I assume such variables are ones the authors consider can be added by future additional specifications, though they do include M/O flag variables which are not core routing parameters. There may be other variables missing beyond those taken from RFC4861.

But overall I believe the document to be Ready for publication.