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

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 13 Jan 2011 18:45:46 -0500

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

---

From: Adrian Farrel <[email-masked]>
Date: Thu, 13 Jan 2011 23:54:20 +0000

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,
>