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(_at_)dcrocker(_dot_)net> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf