Re: [mif] Route option for DHCPv6 - next steps?

Ted Lemon <Ted.Lemon@nominum.com> Thu, 29 March 2012 21:37 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 86CBD21F84FD for <mif@ietfa.amsl.com>; Thu, 29 Mar 2012 14:37:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.335
X-Spam-Level:
X-Spam-Status: No, score=-106.335 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315, 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 CkkovtzyTZ5u for <mif@ietfa.amsl.com>; Thu, 29 Mar 2012 14:37:26 -0700 (PDT)
Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6A021F84F8 for <mif@ietf.org>; Thu, 29 Mar 2012 14:37:25 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKT3TWFB9Cahw9uFBXI7gOWlxK3CnKUL1m@postini.com; Thu, 29 Mar 2012 14:37:25 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 62BA21B80C9 for <mif@ietf.org>; Thu, 29 Mar 2012 14:37:24 -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 596A9190064; Thu, 29 Mar 2012 14:37:24 -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.02.0247.003; Thu, 29 Mar 2012 14:37:24 -0700
From: Ted Lemon <Ted.Lemon@nominum.com>
To: Tony Hain <alh-ietf@tndh.net>
Thread-Topic: [mif] Route option for DHCPv6 - next steps?
Thread-Index: AQHNDL2jhfr6t6vyVEeGR+93z5NinJZ/3M2AgAG+LoD//4t2bYAAgpgAgAAAh4CAABcYAP//i0r4gAC0mQD//8qt3g==
Date: Thu, 29 Mar 2012 21:37:23 +0000
Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472D45F6@mbx-01.win.nominum.com>
References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <CAE97176.17DF4%wdec@cisco.com> <CANF0JMD_zfXGcfMy+rCOFXS1aCZ3RPHoRtkBeS8kDgOFcfQ8Fg@mail.gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <CANF0JMBbhrF0G=hSvcvyZAddAMW7oSO5KpzUmcJXCtwcnmyWOw@mail.gmail.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <DD1241D5-B794-49C3-A3A2-4294248DDD10@gmail.com> <4F719186.3060507@gmail.com> <CAKD1Yr3tSoDPcheriWdZEeKyhqpDANCP7Co0wVVqK5+mXc7e5A@mail.gmail.com> <4F72CD22.3080604@gmail.com> <CAKD1Yr3RUUthiawKrmxjSNqzEbJcOLpHvDGb9XLtdiU-tfEYyw@mail.gmail.com>, <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com>, <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com>, <069301cd0dd2$5954df00$0bfe9d00$@tndh.net>
In-Reply-To: <069301cd0dd2$5954df00$0bfe9d00$@tndh.net>
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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "mif@ietf.org" <mif@ietf.org>
Subject: Re: [mif] Route option for DHCPv6 - next steps?
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, 29 Mar 2012 21:37:27 -0000

> Why is this not RFC 3442bis?  DHCP option 121 already does this function for
> IPv4, so this is really just creating the IPv6 version of the existing
> option. It is required for VPN split tunnel, so the entire question about
> doing it or not is moot. People use 121 / 249 (MSFT private version that
> instigated 3442), so they need the IPv6 version of that.

This wasn't about what is needed.   This was about a  public lynching of a group that entertained an idea that is politically incorrect.   If you look at the reasons that were raised today, they were all garbage, with all due respect to the generally very sensible and wise people who had the poor judgment to offer them.   We had one person, an operator, saying "for god's sake don't make this option, because I would not want to run a network on which this option was used," at the same time that another couple of people who work for very large companies and have pretty close to final say in how their networks are operated saying "if we allow this draft, willfylly stupid people will deploy itin places where it will work really poorly, it will be widely adopted, and then network effects will force us to deploy it as well."

This document has been raised, in one form or another, every year or so for the past five or six years.   There's always a public lynching.   It always gets raised again, because there is demand.   Numerous contributors to the IETF have wasted years working on this.   Today many millions of tons of carbon were put into the atmosphere in order that we might have another public lynching rather than getting about the business of the mif working group.   As a consequence of this useless lynching, I didn't get to hear any of the presentations that followed it on the mif docket.

I wish I could claim that I had never unwisely participated in a public waste of time like the one we had today, but I can't.   I'm sure people reading this are laughing in their sleeves to hear me complaining about this.   But I really wish we could stop doing this.  The participants in today's lynching should take a lesson from the working group's response when today's draft was killed.   Everybody still wants it.   When we are done smarting from the spanking we got today, it will get raised again, maybe in a different working group.   This will keep happening until we all die of old age and our metaphorical children, who have no recollection of the prejudices of the day, finally write it up and wonder why it took so long for it to get done.

Tony, if you really think this option is a good idea, can you send me some email explaining why you think it is, privately, since the working group is at least temporarily not working on this?   I'd like to get some clarity on the reasons why people want this that can be used next time it comes up, so that we have a clear set of use cases to present next time.  The VPN split tunnel case isn't familiar to me.