Subject: complex extensions attacking IETF protocols

From: Chris Newman <[email-masked]>
Date: Mon, 02 Nov 1998 17:08:30 -0800 (PST)

I was recently pointed to a web page which describes strategies for a
commercial company to compete with Open Source Software*.  That page
discusses one issue which I believe is of grave import for the IETF.

The gist of the IETF-related observation is that if complex or confusing
extensions are added to simple protocol standards and used by commercial
clients it can "de-commodotize" those simple protocols by making it very
hard to implement a server which fully interoperates with client features. 
This could give a large commercial organization a competitive advantage.

The IETF traditions of simple protocols, interoperability and design for
technical excellence rather than personal/company benefit have resulted in
keeping implementation barriers for a new service reasonably low.  But
such a principle has never been a formal part of IETF tradition. I believe
we should add "keep implementation barriers for a new service low" as a
tradition on-par with the others in the IETF.  An attack on this principle
could undermine the other related IETF principles over time. 

I also believe IETF participants should be alert to _individuals_ in the
IETF who are deliberately increasing the complexity of IETF protocols
contrary to the best technical design.

I found one unsubstantiated allegation on that web page about an IETF
protocol currently in last call quite disturbing: 

    HTTP-DAV. DAV is complex and the protocol spec provides an infinite
    level of implementation complexity for various applications (e.g. the
    design for XXXXXXX over DAV is good but certainly not the single
    obvious design).  Apache will be hard pressed to pick and choose the
    correct first areas of DAV to implement.**

As webDAV is likely scheduled for IESG debate on November 6th, I may not
have time to determine the validity of that allegation myself and make a
last call comment.  But I hope others might have the time to review it and
make a last call comment based on a solid technical evaluation. 

		- Chris

* I will not give out the URL to the web page as it contains
unsubstantiated claims which are not relevant to the issue and could be 
counter-productive.  Open Source Software is the term used on the web
page for projects such as Linux and Apache where the source is public.

** The XXXXXXX was the name of a specific product which I do not consider
revelent to this forum.

---

From: "John W. Noerenberg" <[email-masked]>
Date: Mon, 2 Nov 1998 17:33:34 -0800

At 5:08 PM -0800 11/2/98, Chris Newman wrote:
>I believe

This should be a goal for changes to old services as well.

I wholeheartedly agree with this point of view, but can't resist observing 
this really is a statement of good s/w engineering practice.  Of course, 
it's not necessarily true that good s/w engineering practice and good 
business practice (that is, building a profitable business) are always in 
concert.  We should be on guard to preserve our engineering integrity.

best,

john noerenberg
[email-masked]
  ----------------------------------------------------------------------
  no matter what a waste one has made of one's life, it is ever
  possible to find some path to redemption
  -- Charles Frazier, "Cold Mountain", Vintage Books, 1997
  ----------------------------------------------------------------------

---

From: "John W. Noerenberg" <[email-masked]>
Date: Mon, 2 Nov 1998 17:33:34 -0800

best,

john noerenberg
[email-masked]

---

From: Paul Jones <[email-masked]>
Date: Mon, 2 Nov 1998 21:21:58 -0500 (EST)

Chris may be refering to Eric Raymond's posting and annotation of a
Microsoft document (now confirmed by MS according to Jamie Love and
news.com as real--news.com says "The document was originally written by
Microsoft's Vinod Valloppillil, an engineer who analyzes industry trends,
said Edmund Muth, the company's enterprise marketing group manager."

http://www.tuxedo.org/~esr/halloween.html for the ECR annotated document.

==========================================================================
                             Paul Jones
Certified Black Helicopter Pilot *** Unwitting Dupe of One World Gov'ment
http://sunsite.unc.edu/pjones/     The Unix Web Server Book (Ventana 1997)
  [email-masked]   voice: (919) 962-7600     fax: (919) 962-8071 
===========================================================================

---

From: Paul Jones <[email-masked]>
Date: Mon, 2 Nov 1998 21:21:58 -0500 (EST)

---

From: George Michaelson <[email-masked]>
Date: Tue, 03 Nov 1998 13:45:47 +1000

Since I can only understand the simple RFC's of course I preference them.

But I would be insane to believe that all the complex ones I can't understand
are completely bogus.

For instance, if an RFC doesn't cite a mathematical process but embeds it
directly, such as an RFC documenting an optimal checksum implementation
strategy, isn't it possibly breaking your own rule? Not everybody in the loop
these days is going to be a CS/EE major, and I bet some of them couldn't
actually explain what is going on without some struggle (myself included and
I *do* have a CS degree) And the Security algorithm RFC's such as Kerberos and
GSS-API and SSL are going to be cases in point.

Maybe you meant complex as in ".. to somebody with a clue-density >0.1" but
its well documented that as the size of the Internet process grows, the clue
density drops.

Or how about an RFC which has to document every single OSI X.400 header
field, and a mapping object into SMTP headers? God, the permutations of
meaning in that one..

Or how about the RADIUS specs, where the 'vendor-supplied attributes' appears
to consist of frozen state of warfare between vendor-A and vendor-<x> for
some point in time?

Actually, a long time ago before JANET shifted to IP, I was thrown a copy
of the SMTP protocol on lineprinter paper. The throwee commented that if
it took 1/2" of paper to document, it could hardly be described as "simple"
but that was set against UUCP which was documented by the code. Of course in
hindsight, SMTP  *is* a simple protocol. Compared to HTTP, which started simple
and now has to encompass language encodings, byte ranges, multiplexing, as well
as citing MIME and a host of other documents.

Maybe what you meant is that an RFC should be only as complex as it HAS to be
and no more. 

So how do you define gratuitous complexity?

cheers
	-George
--
George Michaelson         |  DSTC Pty Ltd
Email: [email-masked]    |  University of Qld 4072
Phone: +61 7 3365 4310    |  Australia
  Fax: +61 7 3365 4311    |  http://www.dstc.edu.au

---

From: George Michaelson <[email-masked]>
Date: Tue, 03 Nov 1998 13:45:47 +1000

cheers
	-George

---

From: Koen Holtman <[email-masked]>
Date: Tue, 3 Nov 1998 10:28:34 +0100 (MET)

On Mon, 2 Nov 1998, Chris Newman wrote:

[...]
> This could give a large commercial organization a competitive advantage.

The best-known example of this "de-commodotize" strategy in action is of
course HTML, though HTML is not an IETF protocol.  And I do feel that
standards organisations have a moral duty not to put their seal of
approval on such things.

There is a related problem which has to do with the creation of commodity
solutions to unsolved problems.  I have seen some cases where a
representative of a major vendor V effectively told an IETF working group
that

 1) though there is agreement that X is an important problem
 2) we, vendor V, are not interested in implementing any simple 
    commodity solution the IETF comes up with
 3) because we think we can solve it ourselves using the new
    proprietary technology Y we are developing
 4) so I suggest that the working group does not spend brainpower
    developing a commodity solution

The result is that the working group looses interest in providing a
commodity solution which could pre-empt proprietary solutions, or provide
an alternative to them.

I personally feel that it is both the right and duty of the IETF to
develop commodity solutions to new problems, with the express purpose of
weakening the chances of a proprietary approach.  But I know that this is
a political view which probably also reflects the fact that I am currently
in academia.  For a completely opposite view, see a message "Barrier to
entry must be low" from the WebDAV mailing list archived at

http://lists.w3.org/Archives/Public/w3c-dist-auth/1998AprJun/0136.html

from which I quote:

| One thing we must try to avoid is codifying 
| nonexistent practice. That is, designing functionality that 
| no one is currently providing, thereby designing future 
| systems for the industry as a side effect. Such designs are 
| unlikely to be optimal, since they do not have the benefit 
| of real world experience.

Koen.

---

From: Koen Holtman <[email-masked]>
Date: Tue, 3 Nov 1998 10:28:34 +0100 (MET)

[...]

from which I quote:

Koen.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 03 Nov 1998 11:56:16 +0000

Chris,

RFC 1958 says

>   3.5 Keep it simple. When in doubt during design, choose the simplest
>    solution.  

and other things close to what you want.

   Brian Carpenter

Chris Newman wrote:
...
> could undermine the other related IETF principles over time.
...

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 03 Nov 1998 11:56:16 +0000

Chris,

RFC 1958 says

   Brian Carpenter

Chris Newman wrote:
...
...

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 3 Nov 1998 13:35:59 +0000 (GMT)

> and other things close to what you want.

This variation on the theme of Occam's Razor tends to get referred to
as "Carpenter's Plain' down our way.

L.

the whole point of the RFC series is the subtle advertisement of bad puns.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 3 Nov 1998 13:35:59 +0000 (GMT)

L.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 03 Nov 1998 14:30:25 +0000

I suspect that when we drafted RFC 1958, this point came from
Postel, like so much else. 

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 03 Nov 1998 14:30:25 +0000

Brian

---

From: "Perry E. Metzger" <[email-masked]>
Date: Tue, 03 Nov 1998 12:39:15 -0500

> discusses one issue which I believe is of grave import for the IETF.

I have no qualms about mentioning the company. It is Microsoft, and
the press is reporting that the memorandum is, in fact, real.

see http://www.news.com/News/Item/0,4,28215,00.html for confirmation.
see http://www.tuxedo.org/~esr/halloween.html for the document itself.

Although the surface of the document describes strategies for
Microsoft to attack Linux, the document spends a lot of time
discussing ways to interfere with the markets by distorting protocols, 
including Internet protocols.

People should be taking this VERY seriously.

I'm sure Microsoft will be spinning this to try to do damage
control. I suggest people read the memo themselves in order to see
what it contains rather than believing my spin or anyone elses's.

> This could give a large commercial organization a competitive advantage.

This is not the first time we've seen this sort of thing happen, but
certainly the size of the company in question makes it a rather
dangerous situation. Doubtless, we are all aware of Microsoft
"extensions" to PPP and other protocols that have seemingly been
oblivious to the fact that they violated standards. We should perhaps
be watching this issue much more closely.

Perry

---

From: "Perry E. Metzger" <[email-masked]>
Date: Tue, 03 Nov 1998 12:39:15 -0500

Perry

---

From: "Steve Hultquist" <[email-masked]>
Date: Tue, 3 Nov 1998 11:57:34 -0700

Normally, I am merely a lurker, but this subject hits too close to freedom for
me to keep silent. The specific strategy recommended by the writer of the memo
is:

"OSS projects have been able to gain a foothold in many server applications
because of the wide utility of highly commoditized, simple protocols. By
extending these protocols and developing new protocols, we can deny OSS projects
entry into the market.

"David Stutz makes a very good point: in competing with Microsoft's level of
desktop integration, "commodity protocols actually become the means of
integration" for OSS projects. There is a large amount of IQ being expended in
various IETF working groups which are quickly creating the architectural model
for integration for these OSS projects."

This seems to me to recommend the subversion of the IETF and the open standards
process.

As others have before me, I encourage everyone to read the memo for yourself,
then consider defensive measures that may be necessary for the long-term
viability of interoperability and open protocols.

ssh
--
Steve Hultquist
ISOC Charter Member

>be watching this issue much more closely.

[snip]

---

From: "Steve Hultquist" <[email-masked]>
Date: Tue, 3 Nov 1998 11:57:34 -0700

ssh
--
Steve Hultquist
ISOC Charter Member

[snip]

---

From: Jim Whitehead <[email-masked]>
Date: Tue, 3 Nov 1998 16:46:38 -0800

First, some background.

The WebDAV Distributed Authoring Protocol, <draft-ietf-webdav-protocol-09>,
extends the HTTP/1.1 protocol with the following capabilities:

  - Overwrite prevention - The ability to prevent overwrite conflicts
    between active WebDAV authoring clients.

  - Namespace management - The ability to create a collection, and to
    copy and move resources.

  - Properties - The ability to set, remove, and retrieve simple
    (name, value) pairs containing descriptive information about a
    Web resource (instances of metadata).

The rationale for these capabilities is set out in our requirements
document, RFC 2291, "Requirements for a Distributed Authoring and Versioning
Protocol for the World Wide Web."  This document went through many cycles of
review within the working group, then underwent a working group last call
for comments, before being submitted to the IESG for approval.

Similarly, the Distributed Authoring Protocol has had 10 major revisions,
has been carefully reviewed by at least 10 people, has been through two
working group last call periods, each lasting 3.5 weeks, and has been
through an IETF-wide last call period.  Throughout the development of this
standard I have kept discussions and decisions open and transparent.

The "Halloween Memo" alleges that WebDAV "provides an infinite level of
implementation complexity".  This assertion is false. In fact, there
currently exist two WebDAV servers and one WebDAV client which were not
developed by Microsoft, nor developed by editors of the WebDAV
specification.  Each of the servers was implemented by a single individual.
The client was implemented by a team of 5 UCI *undergraduates* over two
quarters.

This does not sound to me like "infinite implementation complexity."
Rather, it sounds like rough consensus and running code.

I have repeated over and over on the mailing list, now containing over 300
members, that the working group is the final arbiter of what constitutes
consensus on this protocol document.

It's more than a little ironic that *I* was the one who wanted to keep
features for versioning, partial updates, differences, and referential
members in the specification, and the working group members -- some of whom
even worked for Microsoft -- argued in favor of simplicity, and cutting
features.  Working group members who attended our meetings know well the
corporate affiliation of the person whose favorite quote was, "The spec's
not ready until there's nothing left to cut."

I'll give you a hint -- it wasn't U.C. Irvine.

- Jim

> -----Original Message-----
> From: Chris Newman [mailto:[email-masked]]
> Sent: Monday, November 02, 1998 5:09 PM
> To: [email-masked]
> Subject: complex extensions attacking IETF protocols
>
>
*snip*

---

From: Jim Whitehead <[email-masked]>
Date: Tue, 3 Nov 1998 16:46:38 -0800

First, some background.

- Jim

*snip*

---

From: [email-masked]
Date: Wed, 04 Nov 1998 03:20:49 -0500

> not ready until there's nothing left to cut."

This sounds like good software engineering practice.  However,
I believe that the reason for concern here is that a large number
of people on the IETF list are convinced that (especially given
Eric S Raymond's web posting) Microsoft is plotting to first
allow a simple, implementable standard to be drafted...

...and then ship a product with undocumented, non-interoperable
bells and whistles and gongs.

Now, *if* this were to happen, where would that leave us?

				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

---

From: [email-masked]
Date: Wed, 04 Nov 1998 03:20:49 -0500

Valdis Kletnieks

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 04 Nov 1998 10:50:58 +0100

>Now, *if* this were to happen, where would that leave us?

in a situation much like today.
Examples of places where we did this to ourselves:

SMTP headers:
   X-Face: I can't see Valdis' face, because my mailer doesn't support it.
LDAP attributes:
   anyone can add new ones, and frequently does.
   We can read them, but don't know what they mean.
SNMP MIBs:
   private MIBs are made by anyone who cares enough to make one.
   Sometimes we can get the MIB spec, sometimes we can't.
   Hidden meanings abound.

In all these cases, the open community survives because the subset that's
documented in the open, the "mandatory to implement" if you will, defines
functionality enough to be useful on its own; I understand what Valdis
means by "Subject:", and I know what an LDAP CommonName means, and where
to look for the telephone number, and number of bytes sent on an interface.

The dangerous case comes when something undocumented achieves critical
mass and "takes over the community" - some features of NNTP are examples.
So are Microsoft Word document formats; can't live without them....

(I'm reminded of this Franquin cartoon where the guy is sentenced to life
in prison, gets put into his cell, crying, and then wakes up from his
dream ..... only to find that he's still in prison.
We have seen the nightmare, and it's called Real Life....)

                          Harald A

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

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 04 Nov 1998 10:50:58 +0100

SMTP headers:

                          Harald A

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 04 Nov 1998 10:40:25 +0000

Let me ask an operational question: are there any specific changes 
we should make to RFC 2026 that would make the IETF more resistant to
the type of manipulation people have been hypothesising?

   Brian Carpenter

Perry E. Metzger wrote:
> I have no qualms about mentioning the company. ...

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 04 Nov 1998 10:40:25 +0000

Brian Carpenter

---

From: "Perry E. Metzger" <[email-masked]>
Date: Wed, 04 Nov 1998 10:45:26 -0500

> the type of manipulation people have been hypothesising?

In my opinion, what is needed is for people to be aware that such
efforts occur and that not all intentions are always
wholesome. Awareness in and of itself is probably sufficient to combat
the problem. When working group members and chairmen are aware that
such efforts might be mounted and are swift to recognise them for what
they are, the ability of the offenders to deliberately manipulate the
process swiftly declines. That's one of the advantages of the IETF
consensus driven model.

One of the reasons I made a fuss here on the IETF list is that, in my
opinion, making a fuss about it is about 80% of combatting the
problem, since, in and of itself, it raises awareness of the problem.

Perry

---

From: "Perry E. Metzger" <[email-masked]>
Date: Wed, 04 Nov 1998 10:45:26 -0500

Perry

---

From: [email-masked]
Date: Wed, 04 Nov 1998 13:21:03 -0500

> So are Microsoft Word document formats; can't live without them....

I rest my case ;)

/Valdis

---

From: [email-masked]
Date: Wed, 04 Nov 1998 13:21:03 -0500

I rest my case ;)

/Valdis

---

From: Brant Knudson <[email-masked]>
Date: Wed, 04 Nov 1998 23:40:14 +0000

To my Esteemed Colleagues,

A possible solution to this problem is Active Networks.

If I understand correctly, the concept is much like Java's "write once,
run everywhere", except applied to protocols.  A protocol is described
by a language that all network nodes are able to interpret.  So instead
of having different implementations of a protocol for each platform, a
single implementation runs on all of them.  If a protocol is modified,
the changes are distributed throughout the network.

For more information on Active Networks, a starting point is
http://www.sds.lcs.mit.edu/darpa-activenet/

Brant Knudson
[email-masked]

> discusses one issue which I believe is of grave import for the IETF.
(please refer to the original post for the rest of the message)

---

From: Brant Knudson <[email-masked]>
Date: Wed, 04 Nov 1998 23:40:14 +0000

Brant Knudson
[email-masked]

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 04 Nov 1998 19:51:22 -0500

>A possible solution to this problem is Active Networks.

An interesting research effort for sure, but there are all sorts of
security issues with it to say nothing of performance questions.  It will
need a lot more maturing before it is ready for IETF work.  But many of us
are watching it.

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 04 Nov 1998 19:51:22 -0500

---

From: Scott Michel <[email-masked]>
Date: Wed, 04 Nov 1998 20:12:32 -0800

> A possible solution to this problem is Active Networks.

No! No! No! No!

It's hard enough understanding and controlling Java security
issues on the desktop in an isolated browser. You want to open
routers to the same set of problems? And given the rate at
which security bulletins propagate and software updates are
installed (or can't be installed), security issues are paramount.

The largest failing of AN is that it has lots of trouble migrating
OS type security to the network. Follow me here: the router should
be something analogous to the kernel. You don't allow random code
to get into kernels, the Exokernel and other nano/microkernels
notwithstanding. You use interfaces. In the network work, the
interfaces are protocols.

Sure, you can take a router down by sending bad protocol messages
the same way you can take down your home machine with bad system
call parameters. But those are the exception, not the rule. The
same is applies to Active Nets.

Of course, if you really want a nice hostile applet to crash
Mae-East or Mae-West or take replicate along the MCI routers,
the Active Nets is probably a good idea.

Lastly, Steve Deering just gave a talk at UCLA wrt keeping the IP
stack's waistline thin. Active Networks adds an inner tube to this
waistline.

-scooter

---

From: Scott Michel <[email-masked]>
Date: Wed, 04 Nov 1998 20:12:32 -0800

No! No! No! No!

-scooter

---

From: Phil Karn <[email-masked]>
Date: Wed, 4 Nov 1998 22:52:43 -0800 (PST)

Yes, Active Networks has inherent security problems that may prove
intractable. In the early 1980s, an amateur (ham) packet radio
research group at the University of Linkoping in Sweden prototyped
Softnet, based on essentially the same ideas. They're not new. Even
back then I remember immediately thinking that it was a nifty idea,
but that the security problems would probably be insurmountable.

But you have to admit the attraction here. Just think -- there could
be no such thing as a "proprietary" protocol, because the very
implementation of that protocol would automatically pirate copies of
itself all over the net as needed. What better mechanism to promote
open source software and to give Microsoft the willies!

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.

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: Phil Karn <[email-masked]>
Date: Wed, 4 Nov 1998 22:52:43 -0800 (PST)

Phil

---

From: "mark.paton" <[email-masked]>
Date: Thu, 5 Nov 1998 06:11:14 -0000

Most routers are open anyway to the hackers, the use of active networking would need to include the use of corporate firewalls and security devices on both the circuit tails and each device attaching to the network.

Sh!t, sounds like a wonderful marketing opportunity to the manufacturers to start selling some more kit!!

Get real, before opening the network up even more lets fix the existing ones first before embarking on chaotic network practises.

-----Original Message-----
From: Scott Michel [mailto:[email-masked]]
Sent: 05 November 1998 04:13
To: Brant Knudson
Cc: [email-masked]
Subject: Re: complex extensions attacking IETF protocols 

No! No! No! No!

-scooter

---

From: "mark.paton" <[email-masked]>
Date: Thu, 5 Nov 1998 06:11:14 -0000

-----Original Message-----
From: Scott Michel [mailto:[email-masked]]
Sent: 05 November 1998 04:13
To: Brant Knudson
Cc: [email-masked]
Subject: Re: complex extensions attacking IETF protocols 

No! No! No! No!

-scooter

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 05 Nov 1998 09:08:31 +0100

>>A possible solution to this problem is Active Networks.

the ietf WGs typically work on well defined, scoped pieces of work
where most of the technology for the solution is fairly well
understood.....there is an organisation that works on longer term
strategy called the IRTF  http://www.irtf.org/, 
and its research groups consider research
questions - the fact that Active Networks is a (recent) DARPA program
(and also is a topc of reseach within Europe - most probably in
Framework V) and in other continents, should be a hint that it is not
"ready for prime time" quite yet....
 
 >>the changes are distributed throughout the network.

there are various missing pieces from a convincing active networks
solution (actually, most of active networks is basically a re-run of
large scale distributed systems,. jsut re-vitalised by the idea that
we can write small portable code - there is a large classical
distributed systems literature on process migration - its a hard
problem)......missing pieces include
1/ integrity properties....plausible security models (esp. against denial of CPU service, but
just plain authentication - signing every packet program, and possibly
paying for it requires at least a few orders of magnitude performance
improvement in current micro-authentication and payment
implementations)
2/ safety and liveness properties.....provability (e.g. fixed code exutign a distributed algorithm, for
example a link state routing algorithm, is hard enough to get right -
move the code around as well, and you have something we dont have good
tools to reason about with yet).

there are lots of proofs of concept in the lab though, (some really
neat work at sussex university where the languages the have have both
good execution proof properties, and safe distribution properties...so
you can even talk about the topology of your program!) - see
http://www.cogs.susx.ac.uk/projects/safetynet/
for further info there....

3/ application level active nets are probably a good way to do a lot of
stuff (e.g. collaborative filtering, for multicast, for searching and
advisory knowbots etc etc) - our experience with 12 different java vm/byte
code interpreters and compilers is that it is not ready for prime time
yet as the vehicle for this, but your mileage may vary with other
products (sorry, cant say which ones we tried:-(

 cheers

   jon

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 05 Nov 1998 09:08:31 +0100

cheers

   jon

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 5 Nov 98 19:53:47 JST

> > A possible solution to this problem is Active Networks.

No, of course.

But, it is a misdirected counter argument.

The point here is that AN is helpless to stop Cisco, IBM or Microsoft
complicate Java with non standard (or, worse, IETF standard) extensions.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 5 Nov 98 19:53:47 JST

No, of course.

						Masataka Ohta

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 05 Nov 1998 08:14:48 -0500

> I, for one, will defend this requirement to the death.

Perhaps we coupld strengthen this defense by bringing the "multiple
implementations" requirement earlier in the process.

Multiple complete independant interoperable implementations seems a
bit much of a requirement for Proposed Standard, but it certainly
seems to me like it's reasonable to require that multiple independant
prototypes exist and that they've been tested against each other.

Perhaps refining what is meant by "independant" would also be
worthwhile.  A common interpretation focusses only on the source code
-- which means that the letter of the requirements can be met if an
"Evil Empire" funds two implementations, one for product, and the
other a throwaway just to satisfy the "draft standard" requirements
checkoff.

				- Bill

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 05 Nov 1998 08:14:48 -0500

- Bill

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 05 Nov 1998 14:31:48 +0100

In message <[email-masked]>, Bill Sommerfeld typ

 >>implementations" requirement earlier in the process.

originally, we didn't specify operating systems in this requirement

perhaps the problem is that everyone who does a prototypical
implementation does it on linux or netbsd or freebsd, which gives us 2
or three (usually source code avaialble ) reference implementations,
but what most people in business and the home and entertainment need
is an IOS, solaris, windows or playsos implementation (TM-
"implementation" is a trademark of the Free Plotware Foundation, a not
for profit global conspiracy of internet illuminati:-)

the problem is that the competent foks that contribute these free
reference implementations often vehemently refuse to work on some of
the aforesaid military strength and intelligence operating system
platforms....

 cheers

   jon

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 05 Nov 1998 14:31:48 +0100

cheers

   jon

---

From: Scott Michel <[email-masked]>
Date: Thu, 05 Nov 1998 11:02:34 -0800

> open source software and to give Microsoft the willies!

Conversely, it could easily do the opposite. Imagine an applet
from Microsoft/Microsloth/Mickeysofy/insert_favorite_sarcasm
which executes on your router and decides "Hmm... the needed extensions
aren't here. Guess I'll have to d/l them from Redmond."

Sun was doing this over the summer, IIRC, so ensure that Microsoft
platforms had the one, true JVM.

-scooter

---

From: Scott Michel <[email-masked]>
Date: Thu, 05 Nov 1998 11:02:34 -0800

-scooter

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Thu, 5 Nov 1998 17:24:14 -0500

Date: Thu, 05 Nov 1998 14:31:48 +0100
   From: Jon Crowcroft <[email-masked]>

Is this really a problem?  Typically it's not that hard to move
something from Linux or FreeBSD to a commercial OS like Solaris.  For
certain kernel-level issues it might be an issue, but for protocols
implemented user-level, it's a complete non-issue.

My experience is also that if there is a widely used free
implementation, even if commercial vendors have to (horrors!) pay
programmers to write a version which works with their own propietary
kernel, it's much easier to satisfy interoperability concerns if there's
a free version of the protocol to test against.

							- Ted

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Thu, 5 Nov 1998 17:24:14 -0500

- Ted