Since I have received a couple of notes about 802.11a/b/g specifics and relationships since posting my note, I want to reinforce one of Dave's points... --On Sunday, 13 March, 2005 13:15 -0800 Dave Crocker <dhc2@xxxxxxxxxxxx> wrote: >... >> * if we could run a pure and open 802.11b network >> without real problems a year and two years ago, maybe we >> should let the IEEE experiment with running a mixed >> 802.11a/b/c environment with and without WEP and with >> and without 802.11x and we should skip it... >> >> * if we need some of the more advanced features, let's >> pick one feature set and switch to it... >> >> Now DHCP _is_ our dogfood and, if we can't find >> implementations that work in a satisfactory way under heavy >> load, I have to hope that someone is wondering about where >> the protocols or their specifications might be weaker than >> they should be. But, again, since that basically worked a >> year or more ago, we may also need to ask whether we are >> "modernizing"... > > I don't have an opinion about the particulars of these two > points, but it is clear to me that they represent the style of > thinking that is needed here. It is precisely the style of thinking, and not the specifics, that I was trying to suggest and illustrate. I am not an 802.11 expert. I don't have a competent opinion as to whether we are better off with or without 802.11a, or how well 802.11g mixes with 802.11b. I do know, from long and painful experience, that complexity is often the enemy of smooth and productive operation. So the question I was trying to ask was not, e.g., "does 802.11a would well in an 802.11b/g environment" but rather, "does running both (or all three) protocols add complexity that is increasing the risks of failures". If the answer to that is "no", fine, but the question needs asking. Similar comments apply to the various security settings and protocols: whether or not they work is not the issue; the important question is whether they add complexity and opportunities for things to go wrong that we don't have the time or energy to diagnose and fix in the middle of an IETF meeting. Similar comments apply to shiny new notions about wireless network management and the associated software. Those may be wonderful ideas. They may even prevent problems that have bothered us in the past (but that we have mostly learned to live with). But an IETF meeting is not the right place to demonstrate or experiment with them: let's stay a bit behind the bleeding edge of the technology and stick to things that work. And, if we need to experiment, let's run the risks over _our_ stuff: I would be much more patient about problems (if any) encountered running IPv6, or even some new DHCP options, than problems encountered in 802.11 network management and suggest that others should be as well. And so on. In case it isn't clear, I think Dave and I are in violent agreement. john _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf