Missing root cause: Internet has gotten more complex

todd glassey todd.glassey at worldnet.att.net
Wed Sep 17 14:42:43 CEST 2003


Thomas -
----- Original Message -----
From: "Thomas Narten" <narten at us.ibm.com>
To: <problem-statement at alvestrand.no>
Sent: Wednesday, September 17, 2003 7:15 AM
Subject: Missing root cause: Internet has gotten more complex


> Looking at the root causes, they appear to be:
>
> >    2.    Root Cause Problems  . . . . . . . . . . . . . . . . . . . .  8
> >    2.1   Participants in the IETF do not have a Common
> >          Understanding of its Mission . . . . . . . . . . . . . . . .  8
> >    2.2   The IETF does not Consistently use Effective Engineering
> >          Practices  . . . . . . . . . . . . . . . . . . . . . . . . .  9
> >    2.3   The IETF has Difficulty Handling Large and/or Complex
> >          Problems . . . . . . . . . . . . . . . . . . . . . . . . . . 12
> >    2.4   Three Stage Standards Hierarchy not properly Utilized  . . . 13
> >    2.5   The IETF's Workload Exceeds the Number of Fully Engaged
> >          Participants . . . . . . . . . . . . . . . . . . . . . . . . 14
> >    2.6   The IETF Management Structure is not Matched to the
> >          Current Size and Complexity of the IETF  . . . . . . . . . . 15
> >    2.7   Working Group Practices can make Issue Closure Difficult . . 20
> >    2.8   IETF Participants and Leaders are Inadequately Prepared
> >          for their Roles  . . . . . . . . . . . . . . . . . . . . . . 21
>
>
> But there is at least one root cause that I don't see called out
> explicitly:
>
>      The Internet Has Become More Complex and Requirements placed on
>      it by Users have Changed
>
> Examples:
>
> - increasing complexity of internet/protocols/deployments

and legal issues  as well. For instance, building a protocol that has no
real purpose but to allow the subversion of a local law in some country is
another problem. Not that we should use this as a metric, but the Napster
protocol is exactly this, and especially with how it was erected. Seeing the
results, at some point some Judge or group of lawyers is going to realize
that the IETF is a real target for vengence for the protocols of the world
that they cant control, and this is the last thing the IETF would need.

>
> - awareness that when deployed, protocols _will_ interact with each
>   other and there is a need to understand those interactions in order
>   to decide whether the protocol is reasonably well thought out and
>   that there will be no maor (bad) surpises when it becomes deployed.

This has both political and technical inplications...

>
> - desire to not have multiple protocols that do essentially the same
>   thing, thus, need to use other IETF components rather than point
>   solution. (but this view may not be shared by all of the community,
>   which gets back to Section 2.1)

Which then means that the IETF produces one and only one of each
protocol??? - My take is that doing thins makes the IETF of limited use to
businesses that want to compete with existing protocols. Which brings us to
another problem, and that there is no real way for any new protocol to
challenge and unseat the incumbant protocol if the incumbant protocol doesnt
want it...

>
> - The Internet has changed over the last 15 years, with a different
>   level of expectations (e.g., part of economic infrastructure).

Amen

>   Internet is no longer a toy for running half-thought-out experiments
>   on a wide-scale, where the consequences may be very hard to fix
>   after the fact.

Good point - so maybe a standard's process based on secret votes is a bit
passed its time as well too, Eh?

> Another way of stating this. Its one thing to run an
>   experiment of limited scope. It's another to put something into cell
>   phones, where the "experiment" involves millions of devices.
>
>   note: this point may well also go back to lack of agreement on
>   mission/core values.
>
> - The "low hanging fruit" has been picked. The easiest problems to
>   solve have been solved. We're now dealing with the harder ones; it
>   should be no surprise that finding solutions to them is not as easy.
>
> Thomas



More information about the Problem-statement mailing list