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

From: Scott Bradner <[email-masked]>
Date: Sat, 30 Jan 1999 20:41:49 -0500 (EST)

Dave suggests:
> how about using a working group rough consensus process, agreeing to list
> software which the cognizant working believes is appropriate?

I'm far from convinced that IETF working groups would make all that
reliable a set of software reviewers

software to implement many of today's IETF standards is quite
complex and it would take a lot of work to be sure that all aspects
work correctly

I'd also be worried about the liability issues (people do throw lawyers
at each other over lots of things and I can just see the incoming lawyers
if some company finds out the reference implementation they 
are relying on for some critical service is broken )

if someone wants to maintain a web page of self-anounced open
implementations that could be quite helpful but having the IETF 
approve or validate implementations seems like playing goad the
lawyer

Scott

---

From: Scott Bradner <[email-masked]>
Date: Sat, 30 Jan 1999 22:26:52 -0500 (EST)

Kent (as a youth) thinks:
> I think you old-timers are overlooking something
> important here:  There is tremendous educational value to having 
> code easily available

well, as an old-ish-timer I agree and expect there would be
a safe (liability-wise) to have such a disclaimer-loaded page
and think it would be a good thing to do - but I'm not in favor
of any type of offical IETF blessing or working group review

Scott

---

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

> From: Peter Dawson <[email-masked]>

> What if the RFC editor included as part of
> RFC 2223 (Instructions to Authors) another editoral
> policy to include a 'code reference section' where the approriate
>
> links /ftp servers/ web servers are included /specified  *when
> required*
> by the RFC authors.
>
> The authors *must* include  this as part of the RFC
> documentation process and  IAB/IESG *recommends*
> such a practice.
>
> The normal bioler plate, disclamiers and updates to code,
> would be the *total* liability of the RFC authors as they
> will maintain the code,wither it interoprates , buggy or
> fully compliant.
>
> Hence IETF would not be getting into the source business.

That answers the objections to the IETF getting into source biz, but it
does not meet the goals of the original proposal.  As I recall them, those
goals included having pointers to source that would be suitable for a
standards document.  A reference in a standards document must be valid at
least as long as the document is around even in archives.  Unless the IETF
maintains the source, most pointers in RFCs would be bogus.  In theory,
you could ask authors to keep their source on line forever at the place
as it was originally announced in the RFC.  In practice, such a request
is obviously hopeless; people move and organizations change.

Another problem with this idea is that the authors or editors of RFCs
often have little to do with any of the sample implementations.   The
authors don't know about the sample implementations, and so can't mention
them.  Yet another problem is that the implementations are often built
after the RFC is published (and never mind that some people think that is
backwards).

All of those problems are exemplified in the histories of the freely
redistributable implementations of parts of PPP.  Can you find the Merit
PPP source on merit.edu?  Many of the people involved with the various
ancient PPP sources have long since changed their addresses and do not
control the ancient FTP archives.  Also as I said before, anyone who looks
at that source today would be making interoperablility mistakes.  As I
recall, Paul Mackerras's source has moved since it became the de facto
standard sample implementation--unless you happen to prefer an
implementations on one of the free UNIX CDROM's or FTP servers.  Paul
Mackerras has had little to do with the IETF PPP working group, and so
could not be expected to know he should register his code with the IESG.
Gated is another good example of why having the IETF get into the source
biz, even by redirection or reference, would be a Bad Thing(tm).
I've previously pointed out SMTP/sendmail and DNS/BIND as other examples.

If you want an RFC to refer to a sample implementation, then the right
answer is to put the source in the RFC.  I think that works fine.

What's wrong with the world as it is today?  I haven't had problems finding
source for anything I needed lately--at least not problems that could have
been solved by the IETF.  I do buy CDROM's of free source, but usually
don't bother to spin them up.  Friday I needed something, and found it
with google.com.  I did have to wade through a couple dozen dead links,
but that took only a few minutes.  After I found, compiled, and installed
it, I discovered it no longer works, because the protocol in question is
no longer commonly operated to support it--which is not something an IETF
repository or reference list could help.

Vernon Schryver    [email-masked]

---

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