On Wed, Aug 01, 2007 at 11:11:18AM -0700, Joel Jaeggli wrote: > I'm one of those volunteers, operating that part of the service was not > my responsibility... My point is to both you and the people complaining > about the network, Drawing conclusions from an incomplete picture is > fraught with peril. I've drawn no final conclusions, and would similarly advise others not to do so. I certainly would say that, given what we can observe as users, the possible explanations for the DNS and DHCP service outages reside in a _very_ limited set; hardware, software, configuration, or some combination. None of those are "IETF business" in the sense of things which we can observe or change through "Reviewing our protocols and specifications" as John Klensin appears to have suggested. > At IETF 55 I had issues with all the terminal room macs coming up with A volunteer writing up an essay on the goings on, because he knows the work to be fruitful, is one thing. A bunch of bearded geeks surrounding a table, pounding their fists, and demanding the proverbial "answers" is entirely another. So if you feel like doing it, do it. But it shouldn't be an imperative. > We have a network contractor who has provided services at the ietf68 and > ietf69. We pay them money, they do stuff. We also have volunteers. If the contractor has an SLA to provide DHCP services, that's something IETF's administrative staff should take up with them. I suspect they don't. > Indeed. How do we (I'm being rather inclusive here) do better next time? I don't think we can. By its definition, the IETF network is built with different hardware, different software running on it, and different operators every time. This is an entropic nightmare...you're not just changing one variable... you change all of them. There's no sane way to expect 100% resilient network operations at every event put together like that unless you _really_ start spending money like water on it. Just give up and stop being so choosy. > I ask myself fairly frequently (about 3 times a year) "What can I do to > make the next one better?" Not everyone can or should volunteer to help > but the pool of volunteers is not that big... Involve the vendors earlier. They're probably (not) using the network that's broken anyway. Speaking from my own experience, I don't find out that our software is in use until after things are broken and someone manages to find me through a network of friends (7 layers of separation seems to be more like 3). Take ten minutes to write us a note with your plans beforehand, page us on ietf@ if you can't find us, and maybe we'll answer back with the cellphone that will work while we're in town, and ignore us if we send back a "you need to use fancy new features x, y z to test them for me". -- Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins
Attachment:
pgpcVVMn6BUt7.pgp
Description: PGP signature
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf