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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf