Re: [Gen-art] Gen-ART telechat review of draft-ietf-netmod-routing-cfg-24

[Ladislav Lhotka <[e-mail]>]

Brian,

after looking into draft-ietf-6man-multi-homed-host-10, it seems to me
that

- this document doesn't change the set of router configuration
  parameters specified in RFC 4861,

- our data model neither prevents nor discourages the settings
  recommended in draft-ietf-6man-multi-homed-host-10.

If this is correct, I would say that a normative reference to
draft-ietf-6man-multi-homed-host-10 is not needed. RFC 4861 is a
normative reference in routing-cfg only because it defines the
configuration parameters, which doesn't mean that routing-cfg endorses
RFC 4861 as a whole.

Thanks, Lada

Brian E Carpenter <[e-mail]> writes:

> 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 <[e-mail]> 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
>> 
>> 
>> 
>> 
>> 

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C