IETF Logo Mail Archive

Re: [mif] I won't be in Taipei for MIF WG

Ted Lemon <Ted.Lemon@nominum.com> Thu, 27 October 2011 15: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 C406D21F8B8B for <mif@ietfa.amsl.com>; Thu, 27 Oct 2011 08:29:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.683
X-Spam-Level:
X-Spam-Status: No, score=-105.683 tagged_above=-999 required=5 tests=[AWL=-0.839, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 qZMnrK+54R4Z for <mif@ietfa.amsl.com>; Thu, 27 Oct 2011 08:29:47 -0700 (PDT)
Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0A121F8B80 for <mif@ietf.org>; Thu, 27 Oct 2011 08:29:46 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP; Thu, 27 Oct 2011 08:29:47 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 7C8E21B80BA for <mif@ietf.org>; Thu, 27 Oct 2011 08:29:39 -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 8D044190052; Thu, 27 Oct 2011 08:29:36 -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.0323.003; Thu, 27 Oct 2011 08:29:36 -0700
From: Ted Lemon <Ted.Lemon@nominum.com>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
Thread-Topic: I won't be in Taipei for MIF WG
Thread-Index: AQHMgTbc3T/2qJI6ZUqP6EfUEEdfzJWQgrEAgAAd4ACAABgogIAAHVSAgAAHvACAAA+WgA==
Date: Thu, 27 Oct 2011 15:29:35 +0000
Message-ID: <E6AE72A6-B520-475D-BC3C-27567745D1C0@nominum.com>
References: <4E88B6EF.9050800@gmail.com> <COL118-W23789C049B5BE989F7B721B1D20@phx.gbl> <4EA93870.4020302@gmail.com> <4EA94CB3.5090606@gmail.com> <4EA9654D.2010506@gmail.com> <4EA96BCA.204@gmail.com>
In-Reply-To: <4EA96BCA.204@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.1.10]
Content-Type: multipart/alternative; boundary="_000_E6AE72A6B520475DBC3C27567745D1C0nominumcom_"
MIME-Version: 1.0
Cc: mif <mif@ietf.org>, Margaret <margaretw42@gmail.com>, "<maximouton@gmail.com>" <maximouton@gmail.com>, Hui Deng <denghui02@hotmail.com>
Subject: Re: [mif] I won't be in Taipei for MIF WG
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: Thu, 27 Oct 2011 15:29:47 -0000

On Oct 27, 2011, at 10:33 AM, Alexandru Petrescu wrote:
1. While having working implementation helps if the design is sound,
you can't use working implementation to substantiate a proposal.

Hm?  How does this statement compare to "rough consensus and running
code" substantiating a proposal?

There is no rough consensus for your proposal, Alexandru.

If your implementation is so complicated that it requires you to contribute code to the ISC, that should already be a clue that it's a bad idea: DHCP options are simple, not complicated.   You aren't supposed to have to change the server source code to add an option.   You are supposed to be able to just specify the option format, and the existing server should be able to parse it.   This is a feature of every server I know of, certainly including the ISC server, which has an option format grammar, and the Nominum server, which has something very similar.

The ISC DHCP client is likewise configurable to allow new options to be described without source code changes.   So the sum total code required to implement the route option should be zero lines.

v2.23.0 | Report a Bug | By Email