Re: [mif] Use case 42 [Re: Use cases for draft-ietf-mif-dhcpv6-route-option needed]

Ted Lemon <Ted.Lemon@nominum.com> Fri, 18 November 2011 05:11 UTC

Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3DF21F8BF4 for <mif@ietfa.amsl.com>; Thu, 17 Nov 2011 21:11:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.57
X-Spam-Level:
X-Spam-Status: No, score=-106.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgUuPuQxZm0R for <mif@ietfa.amsl.com>; Thu, 17 Nov 2011 21:11:06 -0800 (PST)
Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 7C97521F8BF3 for <mif@ietf.org>; Thu, 17 Nov 2011 21:11:06 -0800 (PST)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTsXo6l8ftcZPvDTJjeakQ3hE43rTmVpW@postini.com; Thu, 17 Nov 2011 21:11:06 PST
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 954F61B82E4 for <mif@ietf.org>; Thu, 17 Nov 2011 21:11:05 -0800 (PST)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 886AE19005D; Thu, 17 Nov 2011 21:11:05 -0800 (PST) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0339.001; Thu, 17 Nov 2011 21:11:05 -0800
From: Ted Lemon <Ted.Lemon@nominum.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Thread-Topic: Use case 42 [Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed]
Thread-Index: AQHMpZLTS1PZbX9WuEWWXuh7s0xwpZWx5l4NgACWgQD//5jtxA==
Date: Fri, 18 Nov 2011 05:11:05 +0000
Message-ID: <290FDB96-9329-4A97-997F-AEE9A665D4B7@nominum.com>
References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com>, <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com>, <4EC5B720.8020605@gmail.com> <83A7D27A-9036-4252-AC94-3A89125C961B@nominum.com>, <4EC5CEE0.4090001@gmail.com>
In-Reply-To: <4EC5CEE0.4090001@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "mif@ietf.org" <mif@ietf.org>
Subject: Re: [mif] Use case 42 [Re: Use cases for draft-ietf-mif-dhcpv6-route-option needed]
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Nov 2011 05:11:07 -0000

On Nov 18, 2011, at 11:20 AM, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote:
> I didn't read it as the same, and in any case I fail to see how
> a solution with some special features for CATV or ADSL or UMTS
> can solve the general problem of distributing routing info to
> hosts in an arbitary network, very possibly connected by none of
> those specific technologies.

This is true.   However, since the general problem is already nicely solved by RAs, I don't see how it supports your position.

> I don't know how to say it clearer: the use case is any IPv6
> network, such as an enterprise network, whose operator *chooses*
> to manage it using DHCPv6. It isn't for the IETF to decide for
> these operators, and a technology-specific "vendor" option is
> not going to solve the general purpose requirement.

It most certainly _is_ up to the IETF to decide whether we will standardize some mechanism for doing this. Of course we can't stop them engineering around us, but I think they would have to be motivated by some use case that RA *really doesn't address* before they'd go to that trouble.   So what's that use case?