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

Alexandru Petrescu <alexandru.petrescu@gmail.com> Thu, 27 October 2011 14:33 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 D871121F88B7 for <mif@ietfa.amsl.com>; Thu, 27 Oct 2011 07:33:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.249
X-Spam-Level:
X-Spam-Status: No, score=-7.249 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, 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 KU-HLUUilHxN for <mif@ietfa.amsl.com>; Thu, 27 Oct 2011 07:33:55 -0700 (PDT)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 3AAA521F8A4E for <mif@ietf.org>; Thu, 27 Oct 2011 07:33:55 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p9REXoHt026101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 27 Oct 2011 16:33:50 +0200
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p9REXn4K000839; Thu, 27 Oct 2011 16:33:49 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p9REXkpf021551; Thu, 27 Oct 2011 16:33:49 +0200
Message-ID: <4EA96BCA.204@gmail.com>
Date: Thu, 27 Oct 2011 16:33:46 +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: Tomasz Mrugalski <tomasz.mrugalski@gmail.com>
References: <4E88B6EF.9050800@gmail.com> <COL118-W23789C049B5BE989F7B721B1D20@phx.gbl> <4EA93870.4020302@gmail.com> <4EA94CB3.5090606@gmail.com> <4EA9654D.2010506@gmail.com>
In-Reply-To: <4EA9654D.2010506@gmail.com>
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: 8bit
Cc: mif <mif@ietf.org>, Margaret <margaretw42@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 14:33:57 -0000

[MIF list - this is ongoing private discussion about route-option vs
 drlo draft; much private discussion happened recently on this topic
 and I am now invited to publish this on the mailing list, so I do].

Tomasz,

Thank you for the remarks.  I am happy we have an opportunity to express
so obviously the difference in our points of view.

Let me try to reply.

Le 27/10/2011 16:06, Tomasz Mrugalski a écrit :
> On 27.10.2011 14:21, Alexandru Petrescu wrote:
>> I do not oppose the time decided by Chairs to do WGLC for 
>> route-option.
> I'm happy to learn that. Thank you.

Sure and genuinely wishing good luck.

>> Efficient (shorter messages) encoding is highly important for 
>> Machine-to-Machine communications which have stringent
>> requirements in terms of bandwidth usage (the lower the better).
> 
> That is a desired aspect of all protocols: choose shorter encoding if
> it is feasible. However, our perception is that the most optimal 
> approach is not to include redundant information at all.

Right, it is not good to include redundant information.  Our method of
encoding avoids redundancy as much as possible.  At its best it only
include the IPv6 address, and then if MAC is needed it is added without
inserting new subtype numbers - it just follows one after the other.

With your method - route option - if one needs to add MAC address then
one needs to add some separator, like suboption number, if I'm not mistaken.

> 
>>> I also ask for not postponing this process any further. There
>>> are customers who are asking for this feature and we would like
>>> to have it deployed sooner rather than later.
>> 
>> Are your customers asking for the draft?  Or for the
>> implementation of the features described in the draft?
> 
> I'll skip most of the rest of your post, because I find it 
> increasingly more inappropriate. Let me point out several things that
> I consider obvious.
> 
> 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?

> The approach you propose "I have a code that works. Let's write a 
> draft about it and make it a standard" is a negation of the very 
> spirit of IETF. I really hope I just mis-interpreted your mail.

Hm, I am not trying to expose the spirit of IETF.  You may have
misinterpreted me.

> 2. IETF is dedicated to development of protocols, recommendations
> and practices, not a sharing place for exchanging implementations.

But a protocol is made for two machines to exchange data understanding
each other.

> 3. Discussion about specific arrangements with customers is 
> definitely inappropriate in IETF.

I agree, so one would not mention as motivator for a Last Call the fact
that customers are waiting for this, no?

>> Can you provide me implementation of route-option to replace my 
>> existing draft-mouton implementation?
> 
> You chose to document your implementation (or implement -00 
> individual draft, doesn't matter), you publish -00 draft and are 
> expecting that it will not change a bit and be approved as is?

Right... please allow me to say I do not try to be arrogant.

I can agree to modify my implementation, but you're proposing is to get
rid of it alltogether.

> And now you asking that I provide a contingency solution for your 
> mis-planned project? This is ridiculous.

No no, I am not asking for a contingency plan; but what if we tried to
interoperate code?  Interoperability is useful right?

>> (I can provide you our implementation of draft-mouton, under a 
>> certain license.)
> 
> I believe you mentioned that on a list. You have patches for ISC
> DHCP (that is distributed under BSD license). You also have patches
> for wireshark (that you are obliged to publish as source code under
> GPLv2 as soon as you distribute patched wireshark in any form). That
> does say nothing about reasonableness (or lack of thereof) of 
> draft-moulton proposal.

It does say that there is implementation of draft-mouton, i.e. time
spent and software I don't want to through awat.

Hm... then tell me about your implementation and your licensing scheme?

At this point I have no indication whatsoever that route-option draft is
implemented at all.

What happens if I submit my code to ISC and to kernel.org?  Would they
accept it?  Would they ask whether a similar implementation exist?

> I'm sorry. I don't see any point in continuing this discussion any 
> further. If you want to continue it, I suggest that you your comments
> on a list. Maybe someone else is interested in continuing this
> conversation.

Let me Cc the list based on your invitation.

Alex

> 
> Tomek