Subject: Complex extensions and active networks

From: [email-masked]
Date: Fri, 6 Nov 1998 09:27:56 -0800

*> 
  *> On a more serious note, I haven't seen anybody yet mention one of the
  *> most critical principles of the Internet standards process, even
  *> though it's widely known and documented in RFC2026: the requirement
  *> for multiple, independently created and demonstrably interoperable
  *> implementations of any protocol that is to advance along the standards
  *> track.
  *> 

Actually, Phil, I think this argument against active networks (unlike
the security issue and performance issues) is not exactly right.
The most you can say is that "Active Networks does it differently from
the way we have always done it, so it must be wrong."

A major objective of Active Networks, as I understand them, is to AVOID
the necessity of multiple interoperable implementations.  You make ONE
active implementation that works EVERYWHERE.  If (big if) you can
really do it, this seems like a win to me, not a lose.  Let's suppose
that for some reason the whole world used exactly one computer
architecture and operating system.  Then we would need exactly one TCP
implementation, for example; if there were multiple implementations,
the market would pick the best one.  And then we could put all our
energies into writing applications, which is presumably the point (The
fact that this imaginary nirvana would put you and me and half of the
IETF out of work is irrelevant to my point  ;-) ).

In short, the need for multiple interoperable implementations seems to
me to be a necessity forced upon us by the diversity of the real
world.  We have made this necessity into a virtue after the fact.
Active Networking hopes to remove the diversity.

If this really works, SOME of the concern about complexity and
gratuitous features (or one-size-has-to-be-wedged-into-fitting-all)
could be much less of an issue than they are when you know that
25 different implementations of a protocol will be needed.

In fact, of course, even if its difficult technical issues can be
solved, Active Networking won't remove diversity.  There will be
multiple active network flavors (currently called Execution
Environments in by the researchers), for all the reasons there are
multiple operating systems today.  So we will still be making multiple
interoperable implementations of active protocols.

So you can rest easy...

Bob Braden

  *> This requirement has long served us well in two important ways:
  *> 
  *> 1. It helps promote design modularity and to eliminate gratuitous
  *> features and/or unnecessary complexity, as doing so makes it easier to
  *> convince others to produce the required independent implementions of
  *> your pet protocol.
  *> 
  *> 2. Many errors and ambiguities in a spec make themselves known only
  *> when you actually try to implement it. In this way, the spec itself is
  *> debugged. This is crucial in lowering the barriers to entry for anyone
  *> entering the market after the spec is finished.
  *> 
  *> I posit that this very same requirement for multiple, independent
  *> implementations is our very best defense against the kinds of attacks
  *> on "commodity protocols" contemplated by the Evil Empire in that memo.
  *> I, for one, will defend this requirement to the death.
  *> 
  *> Phil
  *> 
  *>

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 06 Nov 1998 21:23:48 +0100

>world.  We have made this necessity into a virtue after the fact.

My personal opinion:
*In the context of the IETF standardization process*, the purpose
of the "two independent interoperable implemenations" is to debug
the protocol specification, not to prove that it's the right solution.

There are 2 possible reasons why when this isn't satisfied:

- It was not specified well enough to make implementations from.
  Then the standards must be fixed.
- Nobody cared enough to implement it.
  Then we haven't tested the standard, and can't claim that
  we know the specs are good enough.

The need for something to be *useful* is orthogonal to this.
But that's also a requirement - albeit at Standard level.

                    Harald A

-- 
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 06 Nov 1998 21:23:48 +0100

My personal opinion:

                    Harald A

---

From: Randy Bush <[email-masked]>
Date: Sat, 7 Nov 1998 09:56:44 -0800 (PST)

> the protocol specification, not to prove that it's the right solution.

i share this opinion.  i would add that, from a viewpoint of formality and
rigor, this is a very weak condition.  

those touting industry's great needs might consider possible consequesnces
of this lack of rigor, as opposed to whining about its delaying time to
market.

randy

---

From: Randy Bush <[email-masked]>
Date: Sat, 7 Nov 1998 09:56:44 -0800 (PST)

randy