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

["Tony Hain" <[e-mail]>]

Well the simplest way to deal with this is to state that it is an IPv6
version of and existing DHCP option, therefore it doesn't belong in MIF, it
belongs in DHC which knows how to deal with updating options. Why it is
needed for mif use is something this WG will eventually need to come to
grips with, but for now we don't need MIF to make progress. 

People use 249 (MSFT private version) so much that it justified the RFC
specifying 121. I had just been looking for this and planned to do a 3442bis
before finding out that it was on the MIF agenda. We should take it offline
for the moment and revisit the wording to take it out of a MIF context per
se, then revisit the AD's about putting it in DHC. I have only scanned the
doc during the WG bashing, so I need to do a better read before knowing
exactly what to suggest.

Tony


-----Original Message-----
From: Ted Lemon [mailto:[e-mail]] 
Sent: Thursday, March 29, 2012 2:37 PM
To: Tony Hain
Cc: [e-mail]
Subject: RE: [mif] Route option for DHCPv6 - next steps?

> 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.