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

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

Lada,

I don't feel strongly about it; it's between you and the IESG. FYI, that draft is in
the editing stage, so will certainly be an RFC before yours.

Regards
   Brian

On 03/11/2016 04:59, Ladislav Lhotka wrote:
> 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
>>>
>>>
>>>
>>>
>>>
>