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

Alexandru Petrescu <alexandru.petrescu@gmail.com> Thu, 27 October 2011 16:42 UTC

Return-Path: <alexandru.petrescu@gmail.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 9152721F8492 for <mif@ietfa.amsl.com>; Thu, 27 Oct 2011 09:42:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.582
X-Spam-Level:
X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
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 zSm80muHEind for <mif@ietfa.amsl.com>; Thu, 27 Oct 2011 09:42:57 -0700 (PDT)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.144]) by ietfa.amsl.com (Postfix) with ESMTP id BD4A721F849E for <mif@ietf.org>; Thu, 27 Oct 2011 09:42:56 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p9RGgqPP022597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 27 Oct 2011 18:42:52 +0200
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p9RGgpPJ013122; Thu, 27 Oct 2011 18:42:51 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p9RGgoeX008506; Thu, 27 Oct 2011 18:42:51 +0200
Message-ID: <4EA98A0A.7090407@gmail.com>
Date: Thu, 27 Oct 2011 18:42:50 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Ted Lemon <Ted.Lemon@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> <E6AE72A6-B520-475D-BC3C-27567745D1C0@nominum.com> <4EA98398.5010901@gmail.com>
In-Reply-To: <4EA98398.5010901@gmail.com>
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: 8bit
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 16:42:57 -0000

Let me add further to this.

One of the first steps some implementers do is make sure their wireshark
understands their messages... has one tried that on route-option? (for
my information thanks).

(we have tried wireshark extensions for drlo and it works, dissectors
available upon request - that is C code as well).

Alex
Le 27/10/2011 18:15, Alexandru Petrescu a écrit :
> Le 27/10/2011 17:29, Ted Lemon a écrit :
>> 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.
> 
> And  is there running code for route-option?
> 
>> 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.
> 
> Efficiency sometimes rightfully implies code complexity (check e.g.
> PacketBB encoding for wireless settings).
> 
>> 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.
> 
> I believe the code format is C code currently (e.g. some quoted text).
> 
>> 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.
> 
> I am not sure about it.
> 
>> So the sum total code required to implement the route option should
>> be zero lines.
> 
> I am not sure really.  There should be some code (script? bash? textual
> conf lines?)
> 
> Please provide some sort of explanation or proof or so, if possible,
> thank you.
> 
> Alex
> 
>>
>