Re: [irsg] An IETF repository for working code in our protocols?

Toerless Eckert <> Thu, 20 August 2020 15:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B582F3A0C3E for <>; Thu, 20 Aug 2020 08:18:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.118
X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ho_FuLQX9KvX for <>; Thu, 20 Aug 2020 08:18:47 -0700 (PDT)
Received: from ( [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 64E083A0C0C for <>; Thu, 20 Aug 2020 08:18:47 -0700 (PDT)
Received: from ( [IPv6:2001:638:a000:4134::ffff:52]) by (Postfix) with ESMTP id 966D0548626; Thu, 20 Aug 2020 17:18:41 +0200 (CEST)
Received: by (Postfix, from userid 10463) id 9076C440059; Thu, 20 Aug 2020 17:18:41 +0200 (CEST)
Date: Thu, 20 Aug 2020 17:18:41 +0200
From: Toerless Eckert <>
To: Eliot Lear <>
Cc: Stephen Farrell <>, "" <>
Subject: Re: [irsg] An IETF repository for working code in our protocols?
Message-ID: <>
References: <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Working Group Chairs <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 20 Aug 2020 15:18:55 -0000

Good points, Eliot

Random thoughts:

I always thought sendmail was likely the earliest reference example for "single" (dominant)
implementation protocol back in the day (rfc822). Made popular of course by

I wonder if there would be in IETF land ever be value in official "reference software"
I remember this primarily from ISO/MPEG where it was/?is? common, e.g.:

I guess implicitly we have such reference software implicitly in our tooling chain, e.g.: 
tools written by IETF tooling team for e.g.: rfc7991 (RFC xml). Not sure if
there is anything similar for "technical" area work product (RFCs).


On Thu, Aug 20, 2020 at 04:45:28PM +0200, Eliot Lear wrote:
> > On 20 Aug 2020, at 01:09, Stephen Farrell <> wrote:
> > 
> > 
> > Hiya,
> > 
> > On 19/08/2020 23:51, Joel M. Halpern wrote:
> >> There is different value in open and closed source implementations.  But
> >> bother are valuable.
> > 
> > I maintain that, for implementers of RFCs, the existence of
> > open-source code is valuable in a way that closed-source
> > can never match. ISTM, that means OSS is inherently better
> > for the purpose we're discussing here.
> > 
> When we speak in generalities, some finer points get lost.  I can see value in open source in that people can take it and use it.  And this is good to a point.  One perversity is that if the standard is complex and there is source available, then that might be the ONLY implementation, or one of a very small number.  This is precisely what happened in 2002 with SNMP and the ASN.1 interpreter bug that hit the entire industry, and it has since happened with openssl, although there are now a good number of libraries out there that cover its ground.
> If the point is to test interoperability, then OSS and closed source can be of similar value if someone is running a test harness of some sort through the closed source, and we see that fairly often as well in the form of bakeoffs and test portals.  We do both OSS and closed now with MUD for instance.
> >> There is as far as I can tell no benefit in the IETF actually storing
> >> the source for these projects.
> > 
> > I disagree. Finding the commit that matches the time at
> > which the RFC was written can be non-trivial and will
> > sometimes be useful/needed.
> There is some value of a pointer.  First, very little code only implements one standard.  The code has a purpose in life that may extend beyond a POC.  And this also means that the only thing that the IETF has to worry about is how to update a list of pointers, and not who gets to commit on active projects.  And yeah, it might also keep the IPR just a bit simpler.
> Eliot