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: "Marshall Rose" <[email-masked]>
Date: Mon, 2 Nov 1998 19:05:13 -0800

hi. i agree with your concern, but i think we are talking truisms here.

> such a principle has never been a formal part of IETF tradition.

i don't know how well the terms "formal" and "IETF tradition" mix.

nonetheless, while there may be exceptions to the rule, i think that the
more experienced IETF folk (yourself included) have always tried to provide
guidance that a protocol should solve 90% of the problem as simply as it can
(and then remove the other 10% from the problem requirements).

> I believe

Too late! An observer with a substantive institutional history might observe
that as the IETF has become more inclusive the engineering quality of the
work product isn't quite what it used to be, say since the design of IP/TCP.
This appears to be a necessary trade-off for openness.

> contrary to the best technical design.

Too late! To name just one instance, remember the CMOT v. SNMP skirmishes of
the late 80's? Both camps were absolutely convinced that they each had a
superior technical design.

The problem is that an open process allows for judgement calls as to
engineering quality and feature necessity. For example, today the IESG
issued a last call on an extension mechanism for POP.  My judgement is that
the technical design of POP would be improved if we removed a few things
that I put into it 12 years ago. Instead we're giving people a way of
advertising stuff that they added to their implementation. But, the IESG's
judgement is different (and they did ask for my input some months ago), so
I'll live with it.

So, you are asking that the IETF exercise vigilence in practicing good
engineering principles. I agree.

/mtr

> ...

You left off two X's in the name. Ooops, I was thinking you meant the vendor
name not the product name!

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 3 Nov 98 0:09:51 EST

I am particularly concerned about the statements made in the
http://www.tuxedo.org/~esr/halloween.html document.  Microsoft has
developed a new Telnet authentication method based upon RFC 1416 and
has so far refused to publish the specs for it even though they have
already shipped their first release candidate.

It has taken months of my harassing them to get them to at least
request an Auth Type number from IANA.  According to the RFCs, IANA
does not have to issue a protocol, option, or any other number unless
appropriate documentation for the protocol, option, ... is published
for comment.

I think it is about time that IANA start to enforce its rights.

    Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
                 The Kermit Project * Columbia University
              612 West 115th St #716 * New York, NY * 10025
  http://www.kermit-project.org/k95.html * [email-masked]

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 3 Nov 1998 00:21:56 -0800

>> keeping implementation barriers for a new service reasonably low.

Funny, I have not recently heard of companies implementing routing
protocols (BGP in particular) describing the implementation barriers as
"low." Even simple protocols do not necessarily guarantee simple
implementations -- and if I had to make a criticism stick, it would be that
very often the impact of proposals on the overall architecture is not
considered. The result can be patchwork quilt of protocols that makes
very little sense in totality, while being defensible in the particulars.

>> could undermine the other related IETF principles over time.

With respect to complex protocols, it is hard to argue for them.
On the other hand, we do seem to be producing a lot of them lately, and in
some cases the complexity seems quite necessary. IPSEC, for example
is not simple. Neither is MPLS. However, both appear valuable, even
though there are considerable barriers to implementation in both cases.

>> contrary to the best technical design.

I am reminded of the proverb "he who lives in a glass house should
not throw stones." It's hard to find anyone who has not at some time made
a proposal that was less than elegant. In general, it seems more productive
to criticize the proposals themselves than to demonize the individuals
advancing them as potential subversives.

After all, one person's wonderful idea is another's "increase in
complexity."

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 03 Nov 1998 06:33:06 -0800

In message <19981103131405196.AAA44@rgm>, Robert Moskowitz writes:
>At 11:49 AM 11/3/98 +0000, Brian E Carpenter wrote:
>>In general IANA operates under guidelines set out in the relevant
>>RFCs. Of course, in the old days when everybody was perfect
>>the guidelines were very general. However, IANA is perfectly
>>entitled to ask for justification and to be parsimonious with
>>scarce resources. 
>>
>It would be interesting if the IANA could function with a desist order.
>Enforcemenrt would be for main ISPs to block unregistered traffic.  Then we
>might have prevented the RADIUS people from using a port number already
>assigned.

I can see the lawsuits now...

>
>But given the situation as it is, all we have is peer pressure and public
>embarrassment.  Of course there is nothing wrong with a wg registering
>numbers that they want and ignoring current, non-registered numbers...
>Remember, we are a society of rational anarchists!
>
>
>
>

---

From: "Marshall Rose" <[email-masked]>
Date: Tue, 3 Nov 1998 07:03:10 -0800

hi. thanks for the note.

please do not read into my note that i am criticizing the iesg's decision.

we both looked at the situation and came up with different solutions. it's
hard to argue that one solution is a lot better than the other, which was
the point i wanted to emphasize to chris about trying to enforce design
simplicity in standardization work.

/mtr

-----Original Message-----
From: Patrik Fdltstrvm <[email-masked]>
Newsgroups: internet.ietf
To: Marshall Rose <[email-masked]>; Chris Newman
<[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: Tuesday, November 03, 1998 03:55
Subject: Re: complex extensions attacking IETF protocols

>At 19.05 -0800 98-11-02, Marshall Rose wrote:
>>For example, today the IESG
>I did ask for your (and others) input, and I thank you for it. Your opinion
>was clear :-) so we do not talk about confusion from my side.
>
>But, my descision as AD was that the POP3 protocol is so confusing today
>for clients, because of the "optional" features the server can have even
>using the basic POP3 document. For example, the server can implicitely
>delete the mail after a mail is read, at a quit, even without an explicit
>DELE command.
>
>Because of these existing practices, I made the descision that there must
>be a way for a client to know what policy the server uses for optional
>features.
>
>So, yes, this expands the POP3 protocol, but it at the same time make (I
>think) the protocol more robust from an operational perspective, and no, it
>does not at all say that future extension will even be considered.
>
>There is an IESG note which states this, i.e. that no more extensions will
>be accepted.
>
>Because of all of this, I have recommended IESG to advance this POP3
>extension to an RFC.
>
>    Patrik
>
>------------------------------------------------------------------
>Area Director, Applications Area               Email: [email-masked]
>IETF                                             URL: http://paf.se
>                                          PGP Key ID: 0xBD236602
>
>   In theory there is no difference between theory and practice,
>   but in practice, there is.
>
>

---

From: "Marshall Rose" <[email-masked]>
Date: Tue, 3 Nov 1998 07:03:10 -0800

hi. thanks for the note.

/mtr

---

From: "Marshall Rose" <[email-masked]>
Date: Tue, 3 Nov 1998 07:53:37 -0800

>You are absulutely right, here. WGs chaired by Cisco and/or IBM people
>should give good examples. BTW, I think you know who is chairing
>IESG/IETF.

y'know: having been around for a while, i've don't recall anyone actually
making a complaint about either organization with respect to unfair behavior
at the IETF. and, while fred and i have had some disagreements in the past,
i've never heard anyone argue that he was ever being unfair or
employer-centric. of course, from time to time, i hear complains about
individuals from these companies, although these complaints are in the
social graces department; regardless, i've never heard a single complaint
about fred.

if you can cite a specific instance which contradicts my belief space,
please do so. otherwise, in the face of considerable experiential evidence
to the contrary, i can assign no positive credibility to your statements.

/mtr

---

From: "Marshall Rose" <[email-masked]>
Date: Tue, 3 Nov 1998 07:53:37 -0800

/mtr

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 3 Nov 1998 09:19:19 -0800

-----Original Message-----
From: Bob Stewart <[email-masked]>
To: Masataka Ohta <[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: Tuesday, November 03, 1998 9:04 AM
Subject: Re: complex extensions attacking IETF protocols

>At 10:15 PM 11/3/98 +0900, Masataka Ohta wrote:
>As one who has worked hard for good engineering and simplicity for the
>benefit of the community no matter who my employer, I take this personally.
>

Bob, let's not go here. This is an excellent example of where we end up if
we focus on companies instead of proposals. We have enough work to
do (and sufficient difficulty in achieving those objectives) that getting
into
a cycle of accusation/counter-accusation would not be helpful.

Speaking of occam's razor, there is a corollary that may be worth
keeping in mind:

"Never ascribe to conspiracy what can be explained by incompetence."

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 3 Nov 1998 09:19:19 -0800

---

From: [email-masked] (Noel Chiappa)
Date: Tue, 3 Nov 98 12:59:56 -0500

From: Karl Denninger <[email-masked]>

    Someone (you, Bob) hasn't been around this industry very long.

Gee, Karl, you're absolutely right.

Can you please send your check to cover Fred's salary and benefits for 4
years to the appropriate oversight organization right away, so we can fix
this appearance of conflict of interest in having firms pay the salary of
IETF management personnel right away? Oh, better include money to pay the
salaries of all the IESG and IAB members, and WG chairs too.

Have fun picking an organization to do it - whichever one you pick, I'm
going to find fault with it. Of course, some of them, e.g. the Red Cross, I
might have to be a little creative with, but I'm sure there's some
pointless, stupid, pinheaded, nit I can find to pick.

After all, I've learned from watching a master.

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Tue, 3 Nov 98 12:59:56 -0500

Noel

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 3 Nov 1998 12:01:22 -0700 (MST)

> ...
> 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.
> ...

Fooey.

The IETF, like any big standards committee, does far more damage to its
own standards than any crassly commercial outfit could hoping to acheive.
The IETF, like any standards committee, is fully stocked with go-ers who
desparately need to prove to themselves and the folks back home that their
Participation in The Standards Process is valuable and positive.  In this
context, "positive" never means "make it simpler" but always means adding
something, since it's hard to show your "positive" value by pointing at
things you kept the working group from doing.  If you look a random RFC
of recent years, you will find more warts "raising the bar" than any
ponderous, desparate, half dead commercial outfit that needs to write down
the obvious could hope to add.  For that matter, if you pick a random RFC,
you're likely to find that it is 100% warts without redeeming value.
"Never attribute to malice that which can be ..."  
Such are the facts of life in any big standards organization.

If you think that any particular current outfit is the first, only, or
most dangerous outfit to play old fashioned standards committee politics,
then you've not been paying attention to the Standards Process.  There
are obvious reasons why certain other commercial outfits could be far more
dangerous to future IETF standards.  Sheesh--have you guys never before
heard the phrase "standards committee politics" or do you think that is
only about the egotistical concerns of individuals?  I've seen standard
standards committee politics played (eg. ANSI BASIC, by coincidence) since
Mr. Gates was still a student at Harvard, and I'm sure it predates my
observations by many decades.  It aint rocket science.

I really hope the suggestion that routers should be filtering packets that
contain bytes that do not match previously known profiles for their UDP
or TCP port numbers was a joke.  How else could you detect re-uses of
numbers assigned to other applications?

As for having the IANA only issue numbers to good designs--double sheesh!
I'd like to think statement was also a joke.  The old IANA gave numbers
to anyone who seemed determined to use them, regardless of how good the
ideas appeared.  Even non-IETF efforts could get numbers if they provided
a short, written description of the protocol.  That is as it must be,
unless you want what would inevitably become yet another committee with
plenty of go-ers to vote on the technical value of ideas from outsiders.

Or maybe that would be a good thing.  Finish turning the IETF into a
subcommittee of the OSI/ITU.  Let it be run by those who prefer to
legislate ideas instead of letting people create them.  If the IETF is
really as dead as some of the comments this week imply, then the sooner
it finishes being ossified, the sooner something else can displace it, as
the IETF displaced the standards organizations that came before.

Vernon Schryver    [email-masked]

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 4 Nov 1998 01:03:47 -0800

>the IAB (as well as the IESG) consider architecture A LOT - the
>problem is that we are in an evoliving situation - a prescriptive
>architectural approach would be restrictive of innovation - i think a
>lot of us feel that an evolutionary approach which permits many flower
>to blossom, and then the market garderner to come along and pick the
>best, is reasonable.....of course, we can prune completely abherrant
>proposals early, but...

I think that this underestimates the growing influence that the
IETF has on the marketplace.  Today many customers put
protocols into their "required list" as they approach proposed
standard status. While there are protocols where implementation
does not begin until proposed standards status has been reached,
it seems these represent a smaller fraction of the total. Rather,
there is increasing pressure in the marketplace to deliver
implementations coincident with reaching Proposed, or even
before.  Part of this results from the fact that trade magazines are
more closely tracking IETF activity. I cannot tell you how many
times I have heard the question "When are you going to
have X?" in the week after a trade magazine published an
article on IETF activity in a given area.

Similarly, the issuence of an Applicability Statement can
have a significant impact on customer perceived usefulness
of a document, deflating some of the demand.

The result of all this is that the decisions of the IESG have
significant impact on the market place. Rather than merely
offering the opportunity to "let a thousand flowers bloom" the
decision to advance a document to Proposed is in many
cases a work order for vendor implementation.

If a persuasive case cannot be made for a document, then advancing it
to Proposed may not be a good decision. Such proposals should
be published as Informational or Experimental instead.

>but we can distinguish between intra-protocol complexity, and
>inter-protocol complexity - the IETF
>Has historically been very good at both, but as the world gets richer
>in types of networks and applications, the latter just naturally gets
>harder -but the former as an engineering design goal should not be
>lost...
>

Indeed, dealing with intra-protocol complexity does become harder
and harder as time goes on. We are increasingly seeing unexpected
interactions between proposals. In order to deal with these interactions,
it seems to me that we are going to need to explicitly bring some new
considerations into the process. Some things to think about:

1.  What is the effect of the proposal on the overall configuration and
management complexity of the system?

       a. What is the diagnostic model for the proposal and how is this
model enabled by the MIB, if one exists?
       b. What parameters need to be set out of band and how
many can be managed via the MIB, if one exists?
       c. If ACLs are involved, how do these interact with other
system ACLs or ACLs in other proposals?
       d. If keys are involved, how are these keys to be managed?
       e. If policies are required, how are they to be distributed and how
is global consistency of these policies to be guaranteed?

2. How does a proposal interfact with other proposals?
      a. Does it duplicate the functionality of other proposals
and if so, is it envisaged that the mechanisms will coexist, and
if so, how?
      b. Is there an inherent contradiction between this proposal
and another proposal that is also advancing on the standards
track? If so, how is this to be resolved?

3. Is the proposal scalable for use on the Internet?
      a. Does the proposal impact the allocation of scarce resources
such as addresses or the efficiency of critical processes (i.e. routing
table size)?
If so, is the impact demonstrably benign?
      b. Is it possible to imagine a world in which this proposal would be
widely deployed? If not, why not?

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 4 Nov 1998 09:42:26 -0800

>
>Brian E Carpenter writes:
>> 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?
>

Here are some thoughts:

1. I think we need to pay more attention to the IANA considerations section
of proposals. Many of the worst abuses of the process occur in misuse
of number spaces, including attribute/message numbers, "domains of
interpretation",
vendor-specific extensions, etc. It is probably worthwhile to consider
requiring
an IANA considerations section be present earlier on in document
development,
and reducing the time period in which a non-IANA entity is in control of
such
number spaces. Presently, the transition may occur well after a document
reaches
proposed standard status, but I think that is often too late. The IANA
process,
while not perfect, does require disclosure of intent before granting use of
a number.
This has the effect of throwing light on an activity.

2. Particular care needs to be taken in preventing a document already at
proposed
standard from being used for a different purpose than the one for which it
was
developed, without explicit consideration of the new intended use.  I would
even
go so far as to suggest that new intended uses for existing proposed
standard protocols
should require formation of a new WG to define the scope of the new use. At
the
very least, the new use should be described in a document, and if not
deserving
of proposed status on its own, should be classified as experimental or
informational.

---

From: Pete Farmer <[email-masked]>
Date: Thu, 5 Nov 1998 04:33:39 -0800

Brant Knudson [mailto:[email-masked]] wrote:

>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.

I eagerly anticipate ActiveXnetworks(R), M****soft's extensions to the
Active Networks language.  Which really *will* make it more functional,
ya know.  Of course, your networking equipment must have WindowsXIP(R)
embedded in it to make use of this superset.  :-)

Pete
______________________________________________________________________
Peter J. Farmer                    mailto:[email-masked]
Strategies Unlimited               Voice: +1 650 941 3438
201 San Antonio Circle, Suite 205  Fax:   +1 650 941 5120
Mountain View, CA 94040            WWW:   http://www.strategies-u.com

---

From: Pete Farmer <[email-masked]>
Date: Thu, 5 Nov 1998 04:33:39 -0800

Pete

---

From: "Marsh, Miles (Gene)" <[email-masked]>
Date: Thu, 5 Nov 1998 21:40:20 -0500

Scott,

You wrote:
"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."

Thank you for the endorsement to the IPv8 methodology.

Gene Marsh
Diebold Incorporated

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

> 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: Peter Ford <[email-masked]>
Date: Thu, 5 Nov 1998 21:30:14 -0800

Bob,

Is it the use of Kerberos for authentication that you find "proprietary" or
the use of IKE?

The IETF used to spend most of its time on protocols that had been spec'ed
and were in actual use.  IETF meetings and mail lists had people working to
iron out interoperability issues to get even better specs and  documents
such as host requirements, etc.  Today, the IETF is focussed on anticipatory
standards with  little focus placed on how useful a protocol might be
(measured by some relatively tangible measure: such as use!).  Three
separate implementations is a good measure of a protocol spec, but 3
separate implementations will not do much one way or another in getting
something used.  At most IETF meetings it is not common to find anything
that looks remotely like a customer for anything being discussed in the
meetings, and quite a lot of work appears to be done before even a test
flight with customers.   the most useful specs I encounter come when someone
(often at a company building systems - gasp) goes out, builds a new
capability to meet some customer requirement, actually gets some feedback
and  writes it up.   Often this work is done with the goal of making the
companies products more valuable to their customers!  And indeed, these
documents may lead to the development of an STD.

I hope the IETF will still consider these kinds of contribution. 
 
cheers, peter

P.S. It is interesting to contemplate whether we should have protocols that
can be extended (e.g. IKE, Kerberos, DHCP ...) or should we have relatively
"tighter" protocols such as Radius, where code point runout leads to the
evolutionary diversity we see leading to more protocols, such as DIAMETER.
I think most people fielding systems would prefer to have fewer, more
extensible protocols to aid in deployment, management, on the wire
debugging, etc.  Protocol "engineers" seem to prefer restrictive protocols,
perhaps to live for another day.  we can save these philosophical topics for
another discussion.

-----Original Message-----
From: Robert Moskowitz [mailto:[email-masked]]
Sent: Tuesday, November 03, 1998 3:50 PM
To: Vernon Schryver; [email-masked]
Subject: Re: complex extensions attacking IETF protocols

More to the point.  Request something, moderately document it and get it.
It might be foolish (DES40 for IPsec), it might be 'proprietary'
(Microsoft's version of Kerberos auth for IKE).  Document it enough so we
know who is using it.

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 4 Nov 1998 23:02:24 -0800

>I believe that the issue you raise has already been addressed. There
>is now a BCP RFC on this topic (RFC 2434 issued just last
>month).

Quoting from the RFC:

   "Designated experts.... are typically named at the time a document that
    creates a new numbering space is published as an RFC"

I think the issue here is that it may be necessary to require independent
review of name space allocation *prior* to publication as an RFC. From
what I can tell, there is no requirement that an IANA considerations section
be included early in the discussion process. This means
that it is possible for a document to reach Proposed Standards status
before control over the name space is ceded, and the name space
ownership becomes public knowledge. I for one would like to see an
IANA considerations section, as well as disclosure of name space usage,
included in documents advanced along the standards track. This would
make the scope of the protocol more explicit, making it more difficult to
produce "iceberg" documents which on the surface look like interoperable
protocols while carrying a hidden payload of private extensions.

---

From: Peter Furniss <[email-masked]>
Date: Fri, 6 Nov 1998 15:05:32 -0000

I was going to stay out of this, though interested, then 

> (measured by some relatively tangible measure: such as use!).  Three

and I read the Halloween articles, especially the first one, and some OSI experience came to mind.

In it's heyday (i.e. at the peak of the hype), OSI was known to be "important" - so any company had to make sure the features they needed were included. This led to the notorious featuritis of the protocols and the consequent perceived need to profile them back to something implementable.

People asked for (insisted on) features that they did not implement. Sometimes this was because they weren't the implementors - they were the architects, and it was someone else's manager's decision what got implemented. Sometimes, one suspected, it was because they (their company) had no intention of implementing at all, and the feature was just put in to slow up everyone else. This may be unfair though - because OSI was expected to be important, implementation was normally expected.

However high the status of the specification, it won't stop people implementing and deploying something else. (In terms of *claimed* status, an "International Standard" clearly outranks even a full Internet Standard, let alone (IETF) Draft or Proposed - this clearly had very little impact on what got used :-)

As to what the IETF should do, I think the change Peter Ford observes is considerably because the Internet is now so obviously important in a way it wasn't perceived as being in the past (say, when OSI was so perceived).  The running code demand is a powerful weapon, but it's difficult to enforce early, and, I suspect, too late at Draft and Internet Standard. But it would seem to be reasonable to challenge anyone "if you haven't implemented that <suggested feature>, do you expect to yourself in the next X months". An answer, "no, but my subordinate will", would be acceptable for a complex protocol :-)

On the wider issue of "OSS" v large commercial player, 2 Kings 6 v 16 would seem a parallel : "Those who are with us are more than those who are with them".

Peter Furniss

--------------------------------------
Peter Furniss Consultants
58 Alexandra Crescent, Bromley, Kent BR1 4EX, UK
Phone & fax : +44 (0)181 313 1833 (or 0181 460 8553 if busy)
Email           : [email-masked]   << note change (9/97)

---

From: Peter Furniss <[email-masked]>
Date: Fri, 6 Nov 1998 15:05:32 -0000

Peter Furniss

---

From: [email-masked]
Date: Fri, 6 Nov 1998 15:39:51 -0800

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

Precisely.  Researchers experimenting with active networking were
speficially instructed by their sponsor to -get UNreal-.  Whatever
practicaly results eventually arise, it won't be real soon.

Bob Braden

---

From: [email-masked]
Date: Fri, 6 Nov 1998 15:39:51 -0800

*> 

Bob Braden

---

From: Peter Ford <[email-masked]>
Date: Fri, 6 Nov 1998 23:10:36 -0800

Ted,

The use of Kerberos in IKE complies with the Kerberos spec.  I suspect there
will be interoperable implementations, but I have no idea whether they will
be Open Source or not.  Microsoft and the IETF should probably leave that
decision up to the implementors.  NT 5.0 also supports PK/IKE and that
interoperability has been demonstrated at the last 2 (3?) IPSEC bakeoffs.
If someone, or one of many implementations, can not interoperate with one of
those IKE mechanisms with NT 5.0, they can use a static key as mandated in
the IPSEC architecture.  

peter

-----Original Message-----
From: Theodore Y. Ts'o [mailto:[email-masked]]
Sent: Friday, November 06, 1998 11:39 AM
To: Peter Ford
Cc: 'Robert Moskowitz'; [email-masked]
Subject: Re: complex extensions attacking IETF protocols

   From: Peter Ford <[email-masked]>
   Date: Thu, 5 Nov 1998 21:30:14 -0800 

   Is it the use of Kerberos for authentication that you find "proprietary"
or
   the use of IKE?

How about the propietary extensions to Kerberos which will either be
documented "sometime after Beta 2 ships", or "maybe we won't do publish
them after all", depending on who you talk to at Microsoft?

Adding propietary extensions to open protocols and then not releasing
the specifications for said propietary extensions is certainly a great
way to lock out open source implementations.  It's a perfect example of
what I call "embrace and engulf".

						- Ted