Subject: Official listing of "public" reference software for IETF specs

From: Dave Crocker <[email-masked]>
Date: Thu, 28 Jan 1999 09:46:56 +0800

Folks,

The IETF process does not require development of a 'reference' 
implementation, but their creation is often a major contribution to 
development of support and success for our standards.  The decision to 
create such implementations, and the effort to create them, is through 
private mechanisms, entirely outside the IETF.  Personally, I think it is 
important to retain this "feature" to our culture, since it constitutes one 
of the methods of testing viability.

However, once reference software is developed, it might be helpful to 
permit citation of it in one or another IETF list, so that newcomers can 
locate it easily.

I suggest treating reference software similar to the way we treat reference 
to mailing list archives.  That is, the working group authorizes the 
reference, but the maintenance is private.  On the other hand, it isn't 
clear where to put the citations.

Thoughts?

d/

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Dave Crocker                                       Tel: +60 (19) 3299 445
<mailto:[email-masked]>             Post Office Box 296, U.P.M.
                                         Serdang, Selangor 43400  MALAYSIA
Brandenburg Consulting
<http://www.brandenburg.com>                       Tel: +1 (408) 246 8253
Fax: +1(408)273 6464             675 Spruce Dr., Sunnyvale, CA 94086  USA

---

From: "Mark Harrison" <[email-masked]>
Date: Thu, 28 Jan 1999 12:54:15 +0800

Dave Crocker <[email-masked]> wrote:
> [good ideas on reference implementation trimmed]

I think this is a good idea.  It's probably best
not to call it a "reference" implementation, since that
may seem to give it some force of authority.  Perhaps
"sample" or "proof" might better convey the meaning.

Mark.

[email-masked]
Mark Harrison, AsiaInfo Computer Networks,
Beijing, China

---

From: "Mark Harrison" <[email-masked]>
Date: Thu, 28 Jan 1999 12:54:15 +0800

Mark.

[email-masked]

---

From: Vernon Schryver <[email-masked]>
Date: Sat, 30 Jan 1999 11:01:14 -0700 (MST)

> Yeah, I agree with that.  However, I would avoid the term "distribution
> point" or anything that suggested any kind of "push" role here.  Rather,
> go with your "have sample code available" wording...or any equivalent
> that made it clear the repository would play only a "pull" role.
>
> And that would not preclude the IETF from placing guidelines on what
> gets into the repository.  One would hope such sample code should
> pass certain tests of standards compliance, clarity, and (above all)
> not include "hooks" into specific commercial products.  I guess
> adding a review for submitted sample code to the WG process might
> not be overly burdensome.  (Even though I know first-hand how
> slow WG progress can be! :-()

Yes, but ...

While I'm a radical believer in the doctrine that code matters more than
any standards blabber, including any and all RFC's, I'm not sure this is
such a good idea.  It's not as if there are not already plenty of
distributions of sample implementations of any and all protocols that an
IETF sample server might host.  There are an awful lot of opportunities
for fun and games in these proposals.

It's one thing for an outfit to generously offer to host sample
implementations.  It's a whole other thing for the IETF to in any way
sanction anything, in any language, outside of an RFC.

Who reviews the sample code for innocent bugs?  Who assumes the legal
liabilities, or whose lawyers are ready to defend the disclaimers?

Who decides whose code is annointed as a The Sample Implementation?
When well meaning people make different choices about what they consider
ambiguous words in an RFC, who decides which version becomes The Sample?

Annointing a sample implementation effectively delegates the power of the
working group to whomever writes the sample.  You can talk about
disclaimers all you want, but the code that people use is what matters.
Think back years ago to the complaints about the bugs in the BSD TCP
implementations.  Consider the current complaints about Microsoft's
consistent inability to read RFC's.

What about bug fixes?  Who determines which bugs are worth the costs to
users of the respository of changing the frozen sample?  Who decides which
bugs are really features, such as corrections of mistakes in the RFC?
Who detects intentional bugs designed to influence the next version of
the standard?

What about aspects of code that are not related to the relevant RFC?  A
popular sample implementation of a protocol strongly influences things
unrelated to the protocol.  Sockets are now universal because of the BSD
implementations of protocols that people cared about.  If the IETF had
been hosting sample implementations 13 years ago, how would you have
arbitrated between BSD and AT&T on sockets vs. TLI/STREAMS?  There were
big bucks involved in that fight.  Recall the big legal battles that axis
eventually involved.

Consider the opportunities for mischief by big commercial outfits whose
explicit plans have recently been widely reported to involve perverting
and assimilating standards.  To avoid offending anyone working for such
an outfit, let me phrase a scenario this way; say one of the kooks and
loons that infest this mailinglist offered supposed DNS code that is a
lame equivalent to `rdist` of host tables.  Who would be responsible for
reviewing the code to detect that perversion, and who has authority to
reject it as The Sample Implementation?  Never mind that there is already
a sample DNS implementation or any of the other specific implausibilies
in that loony sceneario; if you think about it, you'll recall real life
situations that were the sort of thing I'm talking about, but that would
be too distracting to talk about here.  You can't simply say "the
repository is not official; use at your own risk," because real world
effects are not prevented by disclaimers.  

What about code for RFCs that have not been finalized?  Consider the
opportunities for pressuring a working group to pick your notions of what
the standard should be by submitting a sample implementation before the
draft has a number.  Yes, there are other venues for that game, namely
all of the free-source distributions.  However, all of those venues that
matter are not as powerful as an IETF sanction sample distribution would
be, and they have strong willed individuals acting as gatekeepers on what
gets into their trees.  Who would act as gatekeeper for the IETF?  I've
no complaint about Paul Vixie acting as gatekeeper for BIND, but reviewing
sample code for all IETF standards is more than a full time job.

Besides, the situation of BIND or any popular, established code-base and
standard is vastly cleaner than the majority of IETF standards.  Even if
a big vendor or one of our kooks made Paul got an offer he couldn't refuse,
there's still not much he could do, because so many programmers are
watching.  BIND, HTTP, and other currently popular standads don't need
sample repositories because they already have them.  The other, new or
less popular protocols do, but a sanctioned respository would be terrible
attractive nuisances for fun and games.  The current distributions are
trusted because they've earned it; an IETF distribution would be trusted
for the wrong reasons.

Ask anyone who has coded in a commercial shop of more than a few dozen
people about tree wars.  The power to influence (not to mention determine)
what gets put into the trees is awesome, coveted, and the subject of wars.
Consider the stresses and strains that have resulted in FreeBSD, NetBSD,
386BSD, and OpenBSD, or the many Linux distributions.  Those stresses
involved little or no money, and so were not as stressful as what happens
when things with many $100M or $B at stake.

Vernon Schryver    [email-masked]

---

From: Vernon Schryver <[email-masked]>
Date: Sat, 30 Jan 1999 11:01:14 -0700 (MST)

Yes, but ...

---

From: Vernon Schryver <[email-masked]>
Date: Sat, 30 Jan 1999 20:14:46 -0700 (MST)

} From: "David R. Conrad" <[email-masked]>

}                                          ...  All I'm talking about is
} providing a home for sample protocol implementations so people don't
} have to wade through 20 pages in an Altavista listing to find the
} protocol implementation they're looking for.

That is a fine, public spirited thing to do.  It also has plenty of
precedent all over the Internet for the last 15+ years.  It needs no
help from the ISOC, IETF, IESG, or any other standards organization.
The standards bodies would only get in the way.

   ...

] From: Kent Crispin <[email-masked]>

]                      ...    Below the boilerplate would be another 
] button that would take me to a catalog of sample implementations.  I 
] scroll down to the appropriate spot, find the protocol I am 
] interested in (say PPP), and find 4 or 5 implementations that I can 
] study.
] 
] This would be a valuable service.  While it was pointed out that you 
] can always search the web for such things, in my experience such 
] searches are pretty hit and miss.

How would those maintaining the list ensure that it is representative?
How would you keep large corportations from doing bad things?  If your
ISOC list were only a specialized WWW search engine, then why not let the
search engine people continue doing it?

Getting the IETF involved in the free software biz just to save a few
minutes of search is a terrible idea.  Consider that you must do the
searching anyway, to ensure there is not something more suited to your
needs not listed by the IESG.  It's not as if all or even most free IP
protocol code comes from people who pay enough attention to the IETF to
register their code with the IESG or ISOC.

 ...

Validation and debugging by consensus, and today generally the consensus
of large standards committees where most members have never programmed,
or at least not in the last 10 or 15 years?  sheesh.

Before a IETF solution is created, let's size the problem.  Wasn't the
original problem statement something about needing a fixed address to
which RFC's could refer?  If that's fair, could someone list some
implementations that lack repositories?

What could the IETF do for the next verson of HTTP or SMTP except cause
confusion?  Which would be a better, a pointer to current, transient Apache
or sendmail source, or to code permanent and owned by the IETF?  People
who never actually use source might prefer the latter, but programmers
who need to build real implementations need real, current code.  Consider
the sample PPP implementations.   No competant programmer cares anything
about the initial code today, but instead uses the anu.edu.au or other
current source.  References by the IETF to the old PPP source would cause
major PPP interoperability problems.

It would be interesting to ask Paul Vixie how eager he would be to use an
IETF repository for the new versions of BIND, where the IESG imposed the
necessary bureaucratic protections/procedures.  Consider why he is not
publishing the latest versions on the FreeBSD, NetBDS, OpenBSD, or Redhat
CDROMs.  (Yes, those CDROMs have recent if not absolutely current versions
BIND, but not without effort by those who publish those CDROMs.)

If the IETF is going to get into the source business, then the source
should be in the RFC.  Not by refernece, but literally.  Half measures
like repositories and references are worse than either extreme.

---

From: Vernon Schryver <[email-masked]>
Date: Sat, 30 Jan 1999 20:14:46 -0700 (MST)

...

 ...