Re: "The IETF has difficulty solving complex problems"

["JFC (Jefsey) Morfin" <[e-mail]>]

Dear Scott,
could we phrase it differently?
I submit that we could qualify (along with your own wording) "complex" 
changes as bringing a "revolution".
In that case the problem becomes simpler: to try to tink if there is a way 
to make the "revolution" a simple "evolution".

I will take an example. The Internet faces balkanisation. Balkanisation 
results from the unsatisfied general need for partitionning. Sovereignty, 
multilingualism, bandwidth management, risk containment, etc. call for it. 
Let analyse what is partitionning: it is to change the Internet 
architectural default parameters from "mono" to "multiple" (one single DNS, 
one single governance, one single IANA, one language, one ASCII, etc.) 
while staying homogenous and preserving end to end interoperability.

Once you have accepted that, partionning is no more a "revolution" IETF 
cannot tackle and a balkanisation a fate to be accepted. This is only a 
parameting "evolution" to work on (and test) which will permit the huge 
added value of a stable, consistant, secure, simplicity, innovative, end to 
end respectful compartmentailisation.

Just beware: before every ship on earth is compartmentatilised for security 
and strenght, we known the Titanic case. Experimentation is such needed 
before we can fully use externets (compartimented external networks 
look-alike), "the _usage_ networks _within_ the network of the logical and 
physical networks".

Today, I do not know anything the IETF cannot cope with. Except accepting 
RFC 1958 principle that there is only one thing which will not change: that 
everything may change. And that architecture comes before painting :-). 
Even ways to get funded while staying protected from commercial funding 
implications (RFC 3869) could be achieved.
jfc

At 07:05 04/08/2005, 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 mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf