Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00

Ted Lemon <Ted.Lemon@nominum.com> Tue, 13 September 2011 21:29 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 ED04511E8109 for <mif@ietfa.amsl.com>; Tue, 13 Sep 2011 14:29:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.594
X-Spam-Level:
X-Spam-Status: No, score=-106.594 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 4+M1Pxk9sILd for <mif@ietfa.amsl.com>; Tue, 13 Sep 2011 14:29:14 -0700 (PDT)
Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 380CF11E80B8 for <mif@ietf.org>; Tue, 13 Sep 2011 14:29:14 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTm/LqfrZVXvGr9ua4PERXcvFkECwjZt7@postini.com; Tue, 13 Sep 2011 14:31:21 PDT
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 07AB2F8023 for <mif@ietf.org>; Tue, 13 Sep 2011 14:31:21 -0700 (PDT)
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 01C40190065; Tue, 13 Sep 2011 14:31:21 -0700 (PDT) (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.0289.001; Tue, 13 Sep 2011 14:31:21 -0700
From: Ted Lemon <Ted.Lemon@nominum.com>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
Thread-Topic: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00
Thread-Index: AcxxClosDL9zuhm1Q+CTqXShqzwWxAAw84cAAAfxtgAABv0IAAARg+mAAAbg3wAAAWjoAAAA9R+AAAEFqoAAAF3hgAAAk6wAAAAgVoAABVbiAAABH5cA
Date: Tue, 13 Sep 2011 21:31:20 +0000
Message-ID: <10031B1F-30BC-4475-8866-C21CD4E1E819@nominum.com>
References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <CFDF82EE-052B-4A61-AE1B-152337822B6E@nominum.com> <4E6F825C.3080303@gmail.com> <3D0B3661-8A8F-4BB2-A8EF-25007BEAF66C@nominum.com> <4E6F923F.7090304@gmail.com> <7061CEB8-8084-41D5-B31E-9F8E3B6C7091@nominum.com> <4E6F9B91.7010503@gmail.com> <B987CA14-569C-428C-8D8A-C97A0E42EF48@nominum.com> <4E6FA049.1040309@viagenie.ca> <4E6FC41E.6010002@gmail.com>
In-Reply-To: <4E6FC41E.6010002@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [173.162.214.218]
Content-Type: multipart/alternative; boundary="_000_10031B1F30BC44758866C21CD4E1E819nominumcom_"
MIME-Version: 1.0
Cc: "<mif@ietf.org>" <mif@ietf.org>
Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00
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: Tue, 13 Sep 2011 21:29:15 -0000

On Sep 13, 2011, at 4:59 PM, Alexandru Petrescu wrote:
One particular use case is:

Sorry, to be clear, a use case is an example of usage that requires new protocol action, because existing functionality cannot address the use case.   Use cases have to be real, concrete things, not hypotheticals.   I can always make up a hypothetical example to justify any sort of protocol extension, but if there is no real-world use case that requires it, all the work of doing that protocol extension is wasted.

What you've given in this particular message are a couple of examples of how the option could be used.   These are not relevant use cases, because they could also be addressed with the existing proposed option.   That is, they do not motivate additional work.