Complex Problems

[Dave Crocker]

I was going to reply to the details of a number of different postings,
but decided to formulate something seeking a little more coherence:


1.  The Internet and the IETF

The IETF is not responsible for everything about the Internet. It is
not even responsible for all of the technology used on the net. We are
quite explicit about some of this, such as in the agreement with the
W3C. So we need to make some effort at clarity about what work is
*excluded* from the IETF, as well as what is included.


2.  Scope of the current IETF problem effort

We have some immediate problems.  We should try to fix them.

It is well and good to want to work on other problems, but we have
quite a bit of experience that says that mixing such two different
goals is a good way to solve neither. So when someone says "I don't
know where this should be worked on" it is a pretty good sign that it
should *not* be part of the immediate discussion.


3.  Standards continuum

Just as the breadth of the IETF's involvement in Internet technical
issues is limited, so is its involvement in the total lifecycle of any
given Internet technology.  We are not a research group.  We are not a
"pre-standards" group.  We are not an industry consortium.  We are not
a testing organization.  We are not a certification organization.

The IETF occupies a specific segment along the lifeline of technology
and we need to be clear about the beginning point and the ending
point.

Frankly, most of what people seem to be discussing, with respect to
"complex problems" sounds like research. It's important stuff. Someone
should work it. But that someone is not the IETF.


4.  Near-term vs. Long-term

We have an established track record of being good at developing
near-term solutions to near-term problems. Our success at solving
large-scale/complex problems has been by creating a sequence of
discrete, near-term solutions. It is the aggregation of such a
sequence that creates the larger and longer-term effect. When we have
tried to tackle large problems all at once and in their entirety, we
have tended to take a long time -- and often thereby lose the market
window, as well as the attention of the workers -- to create large,
complicated solutions, and to have a very, very spotty adoption
record.

We ought to pay some attention to that track record, especially the
part about adoption.

When someone points out that IP was a big, successful effort, I will
join others in noting that it was a research project for roughly 10
years before it got to a category of effort that would be called
"standards" and that the work was, in fact, not done by the IETF.
That is, it was not done by an organization having the participation
demography and process style of the modern IETF.

I will also note that IP is actually a superb example of incremental
effort. Take a look at the independent, later work on dynamic IP
client configuration, routing (starting with a protocol developed
outside the IETF), incremental IP address structure definition, and so
on.

SMTP is based on careful refinement of the original FTP mail facility.
RFC822 (actually RFC 733) was primarily based on existing practise.
The specific points of innovation in email headers had no better than
a 50% success rate. SNMP was based on an operational protocol
developed outside the IETF. Over a 20+ year period, TCP has gone
through at least 3 discrete rounds of incremental enhancement, each
focused on specific problems. Etc. Etc.

We have real and immediate problems.  We should focus on them, in real
and immediate ways.

Everything else is a distraction.

d/