Last Call Review of draft-ietf-netmod-routing-cfg-24
review-ietf-netmod-routing-cfg-24-genart-lc-carpenter-2016-11-01-00

This didn't have a chance to be updated before the cutoff,
so technically it's still "Ready with Issues", but I am
completely happy with Lada's proposed changes.

Regards
   Brian

On 25/10/2016 20:56, Ladislav Lhotka wrote:
> Hi Brian,
>
> thank you for the review. Please see my replies inline.
>
>> On 25 Oct 2016, at 01:07, Brian E Carpenter <brian.e.carpenter at gmail.com>
wrote: >> >> 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 >> <

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>
>> 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
>> --------
>>
>> Comments:
>> ---------
>>
>> 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
>>

https://www.ietf.org/mail-archive/web/netmod/current/msg16705.html:

>> "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. > > Indeed, this data model is intended as a basis for other
models, e.g. for routing protocols. Several such model are already under way. >
>> >> Minor Issues: >> ------------- >> >> 1) >> 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. > > Will add. > >> >> 2)
>> Did you consider doing anything explicit for ULA prefixes, or would >> this
just be handled by special-next-hop/prohibit in border routers? > > > The
"ietf-ipv6-router-advertisements" submodule just tries to cover the parameters
specified in RFC 4861. I understand that configuration specific to ULA prefixes
is an add-on to this base set, and this can be implemented via augmenting the
core model from other modules. > >> >> 3) >>> 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? > >
Yes, good point, will do. > > Thanks, Lada > > -- > Ladislav Lhotka, CZ.NIC
Labs > PGP Key ID: E74E8C0C > > > > >