On Wed, Aug 01, 2007 at 03:01:40PM -0400, John C Klensin wrote: > I think you misunderstand my comment, or at least its intent. I absolutely did, but I think reasonably so. This version is no longer crazy, even noble. But I'm not sold on it. > Or do you still think we disagree or that my comments are > fallacious? We're half in agreement. Where a problem manifests, and an operator intended the configuration as being reasonable and correct, then the reasons why the setup is neither, or what failed, should be documented. I would expect we should hear very loud noises in any event where this is the case. Where a problem manifests, and it was an accidental mishap of misconfiguration? It's a waste of time to pursue and document these with the kind of rigorous investigation you suggest. I suspect this is just a position we will disagree on, but I will explain myself a little; First, people who make mistakes on accident are not going to read a document telling them not to do that beforehand. If they did read the document beforehand, well we're talking about _mistakes_ here... they're going to make mistakes anyway. Nor will they look to an RFC after it is done. They'll seek FAQs, mailing lists, and their products' support chains. They'll seek an expert on the subject because there are simply too many references to read in a timely fashion to find the one that tells you what mistake you made. So it is certain that documenting this will make no real difference to anyone, and I think the "IETF Mindshare" gains are dubious at best. Second, there are just so many different ways to misconfigure your network, we would be working at this until the heat death of the universe. Of course we'd want this to be a general investigation into accidental configurations, and not a DHCP Witch-Hunt. For IETF 69 alone, we'd have to look into why the DNS servers were reliably reachable but not reliably answering until Tuesday. To continue on beyond merely the mishaps of IETF 69, we'd have to provide such advice as: "Do not accidentally create ethernet duplex mismatches." "Do not accidentally load the full Internet BGP table into a 2501. Use Filters." "Do not accidentally urinate on your router while it is running. In fact, avoid accidental urination altogether. Messy." (True story, a housecat in Maui did this to one of our Portmasters) "Do not make typos, especially not ones which happen to pass parsing tests, such as but not limited to reversing digits on subnet masks." Or my personal favorite: "Do not accidentally run outdated software with known bugs, possibly including well-used security vulnerabilities. Upgrade!" This list could go on! Basically, I think the best thing to do is to just expect our network's operators to raise the flag themselves if they think it is useful. That is, that something might come of it. This ietf@ business of inserting ourselves into the situation because of some possibility of a difficult problem that we hope we might be useful in addressing is another waste of time. -- 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:
pgpg60RqDZb4K.pgp
Description: PGP signature
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf