Well, this didn't come up in the Thursday plenary unless
my brain is more than normally fuzzy.
Firstly, it's worth re-reading section 2.3 of RFC 3774...
...OK, now you've read that, I wouldn't necessarily agree
with every word, but I think it's basically true. What I
meant to argue is that what we *are* good at is defining
elements of the Internet architecture, and the way we do
that tends to favour scaling and robustness without
needing an over-arching scalablity framework or robustness
framework. The latter part is the feature I was thinking of.
Brian
Scott W Brim wrote:
This conjecture was disturbing, but calling it a feature was even more
disturbing. After a bit of pondering, and wondering what different
groups in the IETF might mean by "complex", my first thought was that
the IETF has never, ever solved one. For example, we do QoS in small
pieces that don't fit together well. Some claim that CIDR was such a
solution but imho it was just a tweak on what we already had. Our
routing protocols have been fertile ground for evolution but not
revolution -- the path vector idea came directly from deprecating EGP
"metrics", we still aren't very stable and our policy capabilities are
frustrating.
However, after talking to a few people I thought that perhaps we are
very good at solving complex problems but we don't recognize our
greatness. Again let me take QoS as an example. The problem is huge
and essentially intractable because of all the competing goals. What
we have done, without a lot of architectural planning that I am aware
of, is to find ways to divide the problem up where there is minimum
coupling across the boundaries (see footnote (*)). That lowers the
complexity greatly. It is a lot cheaper to have independent,
apparently "unarchitected" solutions for different kinds of traffic
and situations.
I want us to understand what our skills are and use them consciously.
I don't know if we will have time tonight, but I'd like to hear from
the IESG/IAB on the foundation for Brian's statement and what was
initially a negative assessment of our skill. Let's look at some
example problems and think about what we have done poorly and well. I
predict we are better than we think, but that we are hard to satisfy.
We may think of some of the things we have done as crude hacks but
they are actually pretty good solutions. Look at tunnels, for
example. They are kind of abhorrent when thought of in isolation but
turn out to be an appropriate means to reduce complexity in specific
situations. Reducing complexity through cutting up the problem at the
right points is implicit now. We could make it one of our explicit
basic paradigms.
As a corollary to making it explicit, we should be aware of where we
use this kind of decoupling and be vigilant about it. Some users of
the IETF "product set" want to reintroduce coupling that we have
eliminated. Be sure the trade-offs are explicitly examined.
swb
(*) like Chuang Tzu's butcher ...
"The joints have openings,
And the knife's blade has no thickness.
Apply this lack of thickness into the openings,
And the moving blade swishes through,
With room to spare!
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf