On 22 okt 2009, at 17:03, Kevin Loch wrote:
If, on the other hand, the REAL desire is to have a DHCP server break the tie in the selection between several routers that advertise their presence, that wouldn't be unreasonable.
In some configurations not all hosts are supposed to use the same router. We need the _option_ to specify a default gateway and have the override any RA's a host may see.
Lots of people "need" a gun. If I were living in a place where bears walk around loose I might "need" one, too. But most guns are used to shoot the owner in the foot most of the time. The world would be a better place without them.
Like I said, if there's a bunch of routers announcing their presence and you want a DHCP option to provide guidance to a host as to which one to choose, that would be fine. But pointing to a potentially non- existing address in the hopes that there will magically be a router residing at that address would a serious regression in robustness.
There is no requirement that the IETF provides all functionality that someone can think up. The list of desired functionality is infinite, and much on that list is a bad idea and/or can be achieved in different ways.
Ok, lets start with not breaking the functionality we have today in IPv4. Once you get that working again we can look at new ideas (like RA) that might have utility.
What does that have to with anything? IPv6 stateless autoconfig predates the widespread use of DHCPv4.
Let the new stuff live/die on it's own merits. The Internet is very good at sorting out the useful technology from the crap.
Absolutely not. Give users the choice between something good that suits their needs 83% and a piece of crap tht suits their needs 84% and they'll choose the latter each and every time.
Users get to say what they need. They don't get to design the solution by committee any more than they get to design bridges or airplanes by committee, although of course they do get to choose which ones to use.
At conferences I keep hearing "It would be great if the IETF had more operator input." Yet whenever we try to provide operationally useful advice we are ridiculed for not being smart enough to know how things should work.
How do we fix that?
Tell the IETF your real requirements, don't try to do back seat protocol design. Protocol design is hard, the IETF gets it wrong most of the time (and they do better than some of their colleagues, still). Suggesting specific changes to a protocol as a solution to an unstated real requirement wastes everyone's time.
With writing, they tell you "listen when people say there is a problem, but ignore them when they tell you what the problem is". Same thing here. Users know their needs, but generally they don't know the best way to meet those needs.
