Subject: Re: Draft: IETF listing of open source implementations of IETF specs

From: Vernon Schryver <[email-masked]>
Date: Sun, 31 Jan 1999 22:54:01 -0700 (MST)

>  From the discussion on the IETF list, some rather clear points of 
> consensus seem to have emerged.  The two that I discern the easiest are:

I disagree with the claim that consensus exists; count the respondents.
Moreover, the latest proposal is different from the original or even from
what was proposed a little while ago.  It doesn't seem cricket to claim
consensus exists before the target stops moving.

> 1.  It would be quite useful to list references to open source implementations

It's usefulness has not been established, except by ignoring the problems
that afflict the current lists.  I don't see how anything that the IETF
might do would affect the status quo, other than to offer a vanity listing
that would at best be an advertising medium and IETF endorsement for
consultants and vendors.

Someone mentioned http://www.ietf.org/IESG/implementation.html.
One of the few open source implementations of an IETF protocol among those
pages is my rewrite of Sam Leffler's ancient BSD `routed`, mentioned on
http://www.ietf.org/IESG/RIPV2-implementation under "FreeBSD, NetBSD".
I guess I don't qualify as unlikely to benefit from the advertising.
Still, I don't like this idea.

> ...
> Creation of "open source" implementations of IETF specifications is often a 
> major contribution to development of support and success for IETF 
> standards.  The decision to create such  implementations, and the effort to 
> create and maintain them, is entirely through private means, outside the 
> IETF.  Without endorsing or certifying such software, but in the interest 
> of assisting access to open source software for IETF specifications, the 
> IETF will maintain a listing of such software.

Why would the IETF listing to contain fewer stale and more good references
than the search engines?  How would an IETF listing differ from the search
engines's, other than the endorsement by the IETF?  As others have said,
any disavows of IETF endorsement would verge on disingenous.  They would
be just as effective as the disclaimers on Internet Drafts that prevent
their abuse...NOT!

> a)  Purports to implement IETF specifications having reached a status of 
> Draft Standard, or better

Why only Draft Standard?  By the time a protocol gets to Draft, there are
usually plenty of commercial implementations.  Research and educational
outfits can often get free copies, in vendor dreams of market share (and
"mind share").  That's also when an IETF endorsement would have the most
commercial value for vendors and consultants.

> b)  Is made available by an organization which agrees to long-term, on-line 
> availability to the source

What is long-term availability?  Please cite one or two examples of free
source repositories that has been on-line and permanently open.   I can
list a lot that weren't, including RIPv2 & OSPF (Gated), PPP, HTTP, and
most of TCP (with the death of BSD/CSRG).  The solitary open repository
I can think of that can be called long term is for NTP at udel.edu, and
it certainly does not need an IETF endorsement or listing.

> c) Permits direct use of the software for research and education, at no charge

And so permit charging an arm and a leg for all other uses of the IETF
endorsed code?  That's a definition of "open source"?  You should at least
let the IETF get a share of the gross on the sale of the code it endorses.

Are you sure this isn't just a way to advertise consultants and vendors?

Vernon Schryver    [email-masked]

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 1 Feb 1999 14:01:28 -0700 (MST)

> Why not any prototype at any level?  If someone comes up with an I-D and
> says "here's some code I did" do we want to refuse it?

I-Ds expire, so there is no justification for a long term repository for
their corresponding code.  I-Ds also come with announcements in which
authors can already advertise the location of their code, which surely
will be around for 6 months.  Then there are the working group mailing
lists.
The pointers must at least be limited to products of working groups.
Otherwise, you've really opened Pandora's box to having the IETF endorse
every random protocol in the world.

> It would certainly be good for the net if those doing commercial
> implementations could make use of the prototypes in some way.  We could
> encourage that prototypes be either freely usable in that way or that the
> authors consider liberal licences for such a limited use.  We wouldn't
> want the IETF involved in the details.  Rather, it would be useful to
> suggest, but not require, that those submitting prototypes provide a
> contact name/address for such purposes.

SHEESH!

If no IETF endorsement is involved, then why won't the pointers in the
repository be worse than http://www.ietf.org/IESG/implementation.html ?
My rough count finds about 20% of those are bad, although it's only 18
months old, and each listing was required for a standard to advance. 
The IETF is a volunteer outfit.  Who will maintain this new list that has
nothing to do with IETF operations?  If the search engines cannot maintain
good lists by spending money on wages, how can the IETF do even as poorly
for nothing on something the IESG and IAB do not care about?

On the other hand, there are big incentives for consultants and vendors
to get their stuff listed, especially if it need not be Open Source.  If
the IETF endorsed part of Cisco's IOS for "research and educational use",
should Bay be unhappy?  Can't you see the marketeers dreaming of ietf.org
web pages that say "this is how you implement X; call the Acme sales office
if you're not R&E"?  Contemplate the implications for Microsoft and Sun
for which Java implementation would be listed.  (Yes, Java is outside the
IETF, but if you don't know of IETF equivalents, then you don't work for
or have contacts at any router vendors.)

What if Joe Programmer builds a product for any of the protocols in the
list?  Regardless of whether Joe checks the IETF website, won't his
employer receive lawyer letters from IETF endorsed vendors demanding
license fees or proof that Joe's code is not based on the IETF endorsed
source?  If Joe's code has a bug not in the IETF endorsed code, won't Joe
be risking a lawsuit for negligence if he does not look at the IETF
endorsed code?

Please propose the initial contents of this list.  I have two possibles.
One is useless, consisting of sites we all already know.  The other is
horrendous, consisting of a typical trade rag product survey with pointers
to teaser sample products.

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 1 Feb 1999 14:01:28 -0700 (MST)

SHEESH!

---

From: "William Allen Simpson" <[email-masked]>
Date: Tue, 2 Feb 99 17:31:04 GMT

To put in my two cents worth, I'm not at all sure we really need a
separate site for IETF related source, and think the Draft Standard
implementations list is probably enough.

My own memory includes some references in RFC-1144 that went stale
pretty quickly, resulting in a rather a lot of people asking (too many
times) where a current version of the code could be found.  And that was
for code that is already in the RFC, ready to cut and paste!

My suggestion for IETF related code is that the IETF site point to
[Free|Net|Open]BSD and the various Linux repositories.

And we should just continue our long tradition of working together on
open source implementations.

[email-masked]
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32

---

From: "William Allen Simpson" <[email-masked]>
Date: Tue, 2 Feb 99 17:31:04 GMT

[email-masked]

---

From: "Harald Alvestrand (outlook)" <[email-masked]>
Date: Thu, 4 Feb 1999 10:25:31 +0100

IMNSHO, I think the maintenance of such a list of implementations
is a perfect job for an IETF-friendly organization like the IMC.

This achieves two things:

- There is no question about IETF endorsement of the list
- It does not add to the workload of the IETF bureaucracy.

I think the value of having such a list would be that it only contained
implementations that *claimed* to implement the standard; it would,
for instance, not contain references to software that the implementors
knew was incomplete or in conflict with the standards.

Of course, a "notepad" for people who claim that the listed product does
not implement the standard correctly should be maintained, too;
I guess a clone of freshmeat.net would be a perfect tool for the job.

                      Harald A