Complex Problems

[Marshall Rose]

> Marshall,
> 
> Behind every architecture there are a set of assumptions. The assumptions
> behind the Internet architecture are largely values based (user choice,
> openness, etc.). The assumptions behind architectures done by other standards
> bodies are largely business model based (how to maximize revenue for
> vendors/operators, etc.). This is not to say that business model based
> assumptions don't play a part in decisions in the IETF, they do, but I don't
> believe they drive the basic discussions on architecture (or, at least, they
> have not up until now).
> 
> If we allow others to do the basic architecture, then we will end up accepting
> their assumptions. I don't think this is a very good idea for the Internet.

james - you raise a good point, and i think it's worth pursuing this
thread a bit.

i think that "basic" architectures have a set of principles or axioms
(that you may term "assumptions"). i think one of the most important
razors one can use in evaluating an architecture is the consistency and
complexity of those principles.

the original catanet model, which gave us the ip/tcp split, did a really
good job of articulating those principles (ip for a ubiquitous cloud,
tcp for reliability at the endpoints), and i think a reasoned argument
can be made that much of the ietf's success has been in refining
technologies that are consistent with those principles.

so, we're in agreement thus far.

clearly, successful working groups are one that, at a minimum, must
apply good architectural principals and engineering disciplines. but i
think the "architecture" we're talking about here is more along the
lines of "micro-architecture" (in the sense of micro-economics
v. macro-economics).
    
so, where i think we disagree is whether the ietf has to be the place
where the original macro-level architectural thought and design occurs.
    
i chose the catanet example above because the macro-architecture was
done by a small number of like-minded folks long before the ietf was
formed (some of the gads folks can comment on the exact timeline, but i
don't think i'm doing the early gads meetings a disfavor by saying that
they made substantive contributions to the macro-architecture).
    
however, as much as i'd like to have kahn, cerf, et.al., leave their
cushy dayjobs and go back to doing macro-architecture, i don't think
it's necessary. the reason is that i think that the ietf, as an
institution, understands the core architectural principles, and that we
can evaluate architectural work brought to us by third-parties in order
to determine whether the consistency and complexity metrics are appropriate.
    
so, i just don't have a problem letting other entities doing
macro-engineering, because i think the IETF can figure out how well the
thing fits. and there are some good examples of this where thing have
shown up at the IETF via the BOF mechanism and the IAB has produced
useful documents explaining architecture issues which are used both by
the IESG in deciding what to charter, and by the resulting WG management
in guiding the WG activity.
    
let's face it: the IETF does well when it does focused engineering. 
there are lots of reasons for this, and while we may disagree with what
the reasons are and how important each are, it's always best to play to
your strengths and i think we should keep doing that.
    
similarly, i think we should avoid trying to do macro-achitecture inside
the IETF because the skill-sets and processes are different than what
you need to do engineering, and the IETF doesn't select for the things
you need to do goood macro-level work. and i don't have a problem with
that because sometimes the skill-sets/processes for the two kinds of
work are contradictory rather than complimentary and we don't need to be
good at both things so long as we are good enough to understand what
fits and what doesn't...
    
/mtr