Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mif-dhcpv6-route-option-00.txt

From: Acee Lindem <[email-masked]>
Date: Thu, 10 Feb 2011 13:27:29 -0500

Hi Joel, Adrian, 

Let me be devil's advocate - since RFC 3442 provides similar function for IPv4, why would we want to do more ask for an similar applicability and scaling caveats? 

Thanks,
Acee
On Jan 13, 2011, at 6:54 PM, Adrian Farrel wrote:

> Hi,
> 
> Of course, the I-D is not in WG last call and has, in fact, only just been
> adopted by the WG, but I asked for an early Routing Directorate review because
> the Abstract of the I-D worried me.
> 
> Can we (authors, WG chairs, ADs, and Routing Directorate) have a discussion
> about the question Joel asks, and see whether this idea constitutes "dynamic
> configuration of static routes on a host" or something more scary?
> 
> Many thanks,
> Adrian
> 
>> -----Original Message-----
>> From: Joel M. Halpern [mailto:[email-masked]]
>> Sent: 13 January 2011 23:46
>> To: [email-masked]
>> Cc: [email-masked]; [email-masked]
>> Subject: RtgDir review: draft-ietf-mif-dhcpv6-route-option-00.txt
>> 
>> Hello,
>> 
>> I have been selected as the Routing Directorate reviewer for this draft.
>> The Routing Directorate seeks to review all routing or routing-related
>> drafts as they pass through IETF last call and IESG review. The purpose
>> of the review is to provide assistance to the Routing ADs. For more
>> information about the Routing Directorate, please see
>> http://www.ietf.org/iesg/directorate/routing.html
>> 
>> Although these comments are primarily for the use of the Routing ADs, it
>> would be helpful if you could consider them along with any other IETF
>> Last Call comments that you receive, and strive to resolve them through
>> discussion or by updating the draft.
>> 
>> Document: draft-ietf-mif-dhcpv6-route-option-00.txt
>> Reviewer: Joel M. Halpern
>> Review Date: 13-Jan-2011
>> IETF LC End Date: N/A
>> Intended Status: Standards Track
>> 
>> Summary: I have significant concerns about this document and recommend
>> that the Routing ADs discuss these issues further with the authors.
>> 
>> Comments:
>> 
>> Major Issues:
>>     Given the existence of RFC 3442, I will not investigate the
>> question of whether this is a sensible strategy for directing hosts.  I
>> do understand that there are good reasons for wanting to do this.
>> However, it seems to me that there needs to be a discussion of how this
>> will be made consistent with routing.  A configured preference of this
>> sort could easily cause a host to send messages into a long-lived
>> temporary black hole, even when there is another path.  Is there an
>> expectation that this will somehow be synchronized with teh routing
>> system?  If so, how?  If not, what are the consequences if things get
>> de-synchronized.
>> 
>> Minor Issues:
>>     I presume that the reason there is no discussion of size issues, as
>> there is in RFC 3442, is due to some difference in DHCPv6 vs DHCPv4?  It
>> would seem that even if this is a non-issue, this document should say
>> why it is a non-issue.  (It seems likely that excessive use of this
>> option by an administrator could cause difficulties.)
>> 
>> Nits:
>>     The introduction begins with the phrasing "The Neighbor Discovery
>> (ICMPv6) protocol".  While ND rides on top of ICMPv6, it is not the same
>> as ICMPv6.  The parenthetical is misleading rather than helpful.  Please
>> remove it.
>>     In contrast, it would be helpful if the beginning of the next
>> sentence, "Extensions to the protocol defined in [RFC4191]" actually
>> included the words "Router Advertisement" in the text, since that is
>> what protocol is referred to without being named.
>> 
>>     It would seem a good idea to include a reference to the current
>> specification of DHCPv6 the first time it is mentioned.
>> 
>>     It would be clearer (not technically different, but clearer) if the
>> first and second sentence in section 4 each indicated what message
>> (presumably request and response respectively) is being used to carry
>> this information.  Even if obvious, it would also be good if the second
>> sentence referred to whatever option holder the response message uses,
>> in parallel with the construction of the first sentence.
>> 
>>     The text in section 4.1 as written makes it appear that routes are
>> sent individually, rather than the description of the first part of
>> section 4 or the actual description of the format of the
>> OPTION_NEXT_HOP.  (As written in 4.1, one is led to expect pairs of
>> next-hops and routes, which is clearly not what you actually intend.)
>> 
>> Yours,
>> Joel M. Halpern
>