> > 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf