Re: "The IETF has difficulty solving complex problems" or alternatively Why IMS is a big fat ugly incomprehensiable protocol

> standards bloat solution:
>
> anyone proposing a new feature has to propose two features to be retired.
> anyone proposing a new standard has to propose two standards to be 
> retired.

This is a fun thread, but if we ever decide to get serious
about complexity, we can't assume a static Internet or
static environment. When you keep on increasing the
number of users by orders of magnitude, increasing
the types of applications, and expanding to very different
types of devices, you ARE going to need more functionality.
Sign of success. There's no going back to the times of
telnet and ftp, even if many of us may think of those times
as the good old times when life was simple...

A bad sign, however, would be if we were
producing all this functionality in the wrong way,
making it unnecessarily complicated or limited, or if
the stuff that we produced would not match what people
really use in the Internet. I'm sure we can come up
with examples of all of these bad signs... but its harder
to determine how serious the situation is or is not.
Anyway, some of the tools that we can use going
forward include

- Good architecture and good design. Placement of
  functionality in the right place. I suspect that we
  don't do enough work in this area. Almost all
  of our activities are related to specific protocol
  pieces, not so much on how they work together,
  what the whole needs to do, what etc.

- Generalization of point solutions. Even major new
  functionality often starts out as the need of a specialized
  group of users. If you always do only what is needed
  right now and don't think ahead -- you will get bloat
  and an architecture that does not work well.

- Processes that ensure proposals and standards that
  don't get widely adopted are killed in a timely manner.
  We can decide that proposals don't have enough
  support behind them. We can deprecate standards.
  (Note that "widely" is relative term. I don't mean that
  we should never answer the needs of small
  groups. But if a solution for X does not appear to
  be used even in the potential user group, that's bad.)

- Allowing paths for experimentation, innovation, and
  market forces. E.g., some protocol proposals may be
  better produced in IRTF and tested & evolved, rather
  than being cast from day 1 as standards that affect
  all devices.

--Jari

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf