> Something that could come out of this discussion that would be
> constructive and helpful might be a set of guidelines for
> hosts with respect to the network...
>
I agree that focus would be useful. But another issue, and
maybe part of that one, is that we may need a stronger "if it
ain't broke don't fix it" attitude toward all of this.
Intending only to build on Fred's and John's constructive comments:
My reference to the IETF wireless as a 'utility' is in terms of both the
maturity of the core technology (and its operations) as well as the role it now
plays in the IETF meeting.
By viewing this service as needing to be a utility -- and, yes, realizing that
it doesn't come to us automatically, like electricity or air-con -- then we
should take the (extra) steps necessary to ensure that it works reliably. That
is less a question of individual skill than it is of being clear about our
group requirements and our process of satisfying them.
Some of the problems we have come from experimentation. Yet this is not a
service that should be an experiment.
Some of the problems we have come from business transitions (like a vendor
being bought or going out of business) yet these are not sudden surprisises, so
they can be attended to and protected against.
This is most definitely not a matter of blaming or criticizing anyone. Rather
it is a matter of our deciding that this must be treated a certain way and then
ensuring that we set up a process to ensure it, where that process does not
overburden the folks doing the work.
The "same hotel"
property indicates that we should not be having surprises with
building structure or layout either.
exactly.
More generally, what most of us do when we are trying to
troubleshoot something that used to work better than it does now
is to ask "what changed" and hope we don't get a really complex
answer to that question.
yup.
* 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.
> The best bet, I think, would be for the IETF 62 team to put
> together a note (not to this list, but among the appropriate
> group) detailing the issues and making recommendations for
> future meetings.
>
Concur.
yes, but I think it would be better to add comments from the folks who
delivered earlier, less problematic nets, and maybe formulate a requirements or
planning document, for future use.
d/
---
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf