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 General Area Review Team (Gen-ART) (genart)
Deadline 2016-11-01
Requested 2016-10-20
Authors Ladislav Lhotka, Acee Lindem
Draft last updated 2016-10-25
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 Brian Carpenter 
State Completed
Review review-ietf-netmod-routing-cfg-24-genart-lc-carpenter-2016-10-25
Reviewed rev. 24 (document currently at 25)
Review result Ready with Issues
Review completed: 2016-10-25


I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

Document: draft-ietf-netmod-routing-cfg-24.txt
Reviewer: Brian Carpenter
Review Date: 2016-10-25
IETF LC End Date: 2016-11-03
IESG Telechat date: 2016-11-03

Summary: Ready with (minor) issues


This seems to be a fine document. FYI I am not a YANG expert.

There is a dissent on a point of principle in the WG archive at

"Given the historical opposition to revising models once they have been cast as RFCs
that we have seen within the IETF, then I feel that avoiding incomplete models going
to RFC is the best course of action."

My understanding is that YANG models are intrinsically extensible, and this is
noted in the Abstract and Introduction. So I don't find this dissent compelling.

Minor Issues:

Re on-link-flag and autonomous-flag: Please consider adding a normative
reference to the approved RFC-to-be draft-ietf-6man-multi-homed-host,
as well as RFC 4861. That document specifies that having both these flags
set to False is a legitimate combination, against current expectations.

Did you consider doing anything explicit for ULA prefixes, or would
this just be handled by special-next-hop/prohibit in border routers?

> Appendix B.  Minimum Implementation
>   Some parts and options of the core routing model, such as user-
>   defined RIBs, are intended only for advanced routers.  This appendix
>   gives basic non-normative guidelines for implementing a bare minimum
>   of available functions.  Such an implementation may be used for hosts
>   or very simple routers.

IPv6 hosts should definitely not send RFC4861 router advertisements.
Should that be stated in this appendix?