Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 published

[Alexandru Petrescu <[e-mail]>]

Lorenzo,

Let me take advantage of this.

With respect to the main point you make about dealing with the draft in
6man rather than mif - to me as a commenter it makes no difference as
long as it is in the Internet Area, the expertise be there, and the WG
works by rules typical in that area.  If 6man has cycles to take on this
then why not.

Some spare comments inserted below.

Le 27/03/2012 17:43, Lorenzo Colitti a écrit :
> On Fri, Feb 24, 2012 at 19:38, Tomek Mrugalski wrote:
>
>> Title           : DHCPv6 Route Options Author(s)       : Wojciech
>> Dec Tomasz Mrugalski Tao Sun Behcet Sarikaya Filename        :
>> draft-ietf-mif-dhcpv6-route-option-04.txt Pages           : 22 Date
>> : 2012-02-24
>
>
> [CCing a few of the folks we had a chat with about this in Taipei]
>
> Hi,
>
> I believe this document is not appropriate to be discussed in this
> working group, for two reasons:
>
> 1. It has almost nothing to do with multiple interfaces. Section 2
> contains text on why this document applies to "multi-homed
> scenarios". However, there is nothing in this option that makes it
> any more applicable to a multi-homed scenario than to a single-homed
>  scenario.
>
> At least 11 out of the 14 use cases cited (#1, #2, #3, #5, #6, #7,
> #10,#11, #12, #13, and #14) are equally applicable to hosts with only
> one interface.
>
> Further: a host needs to obtain routing information in both single
> and multi-homed scenarios, and how the information is obtained
> (DHCPv6, RA, HTTP, carrier pigeon) is completely orthogonal to
> whether the host has one or more interfaces.

In a sense I agree.  Moreover, the same would be the case for a router
as well.

> 2. This option provides a complete replacement for the ND
> functionality specified by RFC 4862 and RFC 4191, including default
> routes, more-specific routes, and on-link determination. This is all
>  in 6man's domain. So this option should be taken to 6man.

Well not quite a complete replacement.  There still are a number of RA
parameters absent from DHCP.  MTU comes to mind but there are more when
one considers the huge list of parameters and Flags in RA extensions
used in other protocols.

> I have a number other issues with the document as well. The use cases
> do not seem particularly convincing; it seems to me that some of them
> are niche use cases, some are circular arguments, and some are
> specious. The long-term implications of configuring routing via DHCP,
> which is a static protocol mediated by servers and suited to making
> promises, instead of using dynamic information originated by routers,
> does not seem to be worth it.
>
> But most importantly this document should be moved to 6man so that
> the people who are responsible for the architecture can see it,
> comment on it, and possibly reach consensus on it.

In the past 30 oct 2011 the document was ran through 6man by Chairs
asking for review.  IIRC, one comment was on who supersedes whom (ND or
DHCP) with respect to aspects like default route.  I believe that
comment was addressed by Authors in next versions (old versions said
DHCP supersedes, new versions give advice close to what 6man wanted) -
did that new version satisfy 6man commenters?

Also, if more comments can come from 6man, I think it would be a good
idea to run it again through it.

Moving to 6man - do you mean having a Charter item in it?  New
presentations in subsequent meetings?  Similar?

Alex

>
> Regards, Lorenzo
>
>
> _______________________________________________ mif mailing list
> [e-mail] https://www.ietf.org/mailman/listinfo/mif