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
pgpfE8V39JaU2.pgp
Description: PGP signature
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf