On 6/17/22 17:25, Phillip Hallam-Baker wrote:
That is completely wrong. I could not disagree more emphatically.
Miles' premise is utterly wrong.
Most ideas are relevant to a very specific time and not always the one in which they were proposed. Sometimes the solution to a problem came up long before the problem was recognized. And that makes it very difficult to get attention for that particular approach in academic circles because careers are built finding new bright shiny objects, the realization that the solution to the critical problem of today was discovered 20 years ago does not usually bring offers of tenure.
Most systems are the result of a set of compromises. The fact that X was considered and rejected 20 years ago because Y isn't a major concern is a poor argument for rejecting X now that Y has become a major problem.
I don't think that anyone is doing anyone else a service by driving away anyone who dares question the sacred principles of IETF protocols. The IETF's biggest problem has been group think for a very long time.
I often see newcomers fail to realize that there are deep, sound,
and often subtle reasons for particular design choices made long
ago, and naively suggest different choices. This sometimes
results in very heated and divisive discussions, in which the
newcomers might well conclude that "pissy greybeards" (or similar)
are hostile to them, foolish, etc., and the more experienced
participants write off the newcomers as fools.
But I also often see experienced participants fail to realize that conditions on the network have changed since certain choices were made, and stubbornly insist that those choices were carved in stone.
Few experienced people like to keep rehashing the same arguments every time a newcomer brings them up again. And few experienced people like to re-think design choices made long ago to see how the dominoes flip when changes are made.
None of these problems are due to any deficiency on anyone's
part. They're natural consequences of humans trying to keep
technology functioning stably and reliably in a constantly
changing world.
Keith
p.s. There's a concept I keep thinking of which I call "Interoperability Over Time". One example is when you need some very old hardware or system that really cannot be upgraded, to talk to a modern hardware platform or system. Another example is that some technologies evolve rather quickly but they may have to interact with technologies that (for economically and technically sound reasons) evolve rather slowly. Another example is when you need for people whose formative experiences in a discipline were decades ago, need to interact with people who learned at a different time or are still learning. Neither older nor younger is always better. The real trick is to keep some flexibility about how you think and work, be willing to try to wrap your head around others' ways of thinking without discarding the wisdom you've acquired.
