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

Tommy Pauly <> Wed, 19 August 2020 17:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 709E23A0972 for <>; Wed, 19 Aug 2020 10:08:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Y8BzHkbp3QOt for <>; Wed, 19 Aug 2020 10:08:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F39FE3A0E4B for <>; Wed, 19 Aug 2020 10:07:44 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id 07JH3A8K046699; Wed, 19 Aug 2020 10:07:35 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=e7HgXrGL3ZCXSfb5v3NRHJYBWK5FHSIOK77YL7LlOJ8=; b=iYPgrOHAVfBFCgkLku/YGhpk5sXFFUn6ACq4Na+lzbO1ihvx9Tpad/veeyzjx9uk8WSu iBVMN65bHyKNF72hywV3CTBjHE7/NkYIhSEplUZStpdjk8O6FTjNuFc+1EmCN9SDXI/Y GMc14Dc63aYwVJXG5F+5/HEdIdMClDKe5D2G3QsopgChtHBilfRNzmWRJKkSTrbibSR0 Hy525dFXHRtxjIx2TZJ9YHXgDmfvKmiLFAbERHE3yn3vG8wghvmEACMGZDRT2Bnbgra+ 1SOvfGtkZpoOC8pLkcPHFcKQPiIXclvElUUok99vzM7yLGrR9nBVPtZ78w6X9za98+GG 0w==
Received: from ( []) by with ESMTP id 32xepvhur6-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 19 Aug 2020 10:07:35 -0700
Received: from ( []) by (Oracle Communications Messaging Server 64bit (built Jul 29 2020)) with ESMTPS id <>; Wed, 19 Aug 2020 10:07:34 -0700 (PDT)
Received: from by (Oracle Communications Messaging Server 64bit (built Jul 29 2020)) id <>; Wed, 19 Aug 2020 10:07:33 -0700 (PDT)
X-Va-T-CD: d3d7d3c5f6e88e1efd50052fb8185312
X-Va-E-CD: 9161b275cd0eb7bab6264a3cc805dfb3
X-Va-R-CD: b298229b013bcb621ea75c51a0a9e4e4
X-Va-CD: 0
X-Va-ID: b14e3657-0bab-4e5b-8b8b-1856416b8963
X-V-T-CD: d3d7d3c5f6e88e1efd50052fb8185312
X-V-E-CD: 9161b275cd0eb7bab6264a3cc805dfb3
X-V-R-CD: b298229b013bcb621ea75c51a0a9e4e4
X-V-CD: 0
X-V-ID: d186a39c-ce7a-4442-8033-fc847920f3c3
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-19_09:2020-08-19, 2020-08-19 signatures=0
Received: from [] (unknown []) by (Oracle Communications Messaging Server 64bit (built Jul 29 2020)) with ESMTPSA id <>; Wed, 19 Aug 2020 10:07:32 -0700 (PDT)
From: Tommy Pauly <>
Message-id: <>
Content-type: multipart/alternative; boundary="Apple-Mail=_6AE5DAC6-FBAE-4143-B3CA-08D9CF17252C"
MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Subject: Re: An IETF repository for working code in our protocols?
Date: Wed, 19 Aug 2020 10:07:30 -0700
In-reply-to: <>
Cc: Alissa Cooper <>, Martin Duke <>,
To: Vijay Gurbani <>
References: <>
X-Mailer: Apple Mail (2.3608.
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-19_10:2020-08-19, 2020-08-19 signatures=0
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: Wed, 19 Aug 2020 17:08:06 -0000

Hi Vijay,

As a note, we’re starting up a new IAB program that may be relevant. As we look at deployability and maintainability, we’re interested in looking at how working groups can host information about implementations and interop during protocol development, as well as after protocols have shipped and groups have closed. <>

I’d invite people to join the list if they want to discuss!


> On Aug 19, 2020, at 8:10 AM, Vijay Gurbani <> wrote:
> All: I was reviewing a draft [1] as part of Gen-ART.  In the draft, there is a section pertaining to "Implementation Status" as dictated by RFC 7942.  I found this section to be very interesting in that it captures the running code corresponding to the I-D, but RFC 7942 does not appear to provide the means to retain this section upon publication as a RFC.  (To be sure, it does not mandate that the section be removed, just suggests it.  However, most I-D authors simply will end up asking the RFC editor to remove the section, as [1] does.)
> I think that is rather counter productive.  After all, we standardize protocols so that others can write programs that implement the protocols, and I see a lot of value in preserving any running code.  In the particular case of the I-D I reviewed, there were two implementations, both from reputable organizations (APNIC and the Italian National Research Council).  By simply deleting the "Implementation Status" section when the I-D was published as an RFC, it seems that good, quality implementations that folks spent time on would be lost, perhaps not irrevocably, but for most practical purposes, the code would be orphaned.
> I am wondering whether the IETF should preserve some of this running code as an archive.  The IETF makes no guarantees of the correctness of the code, just provides a repository where code can be linked to a particular RFC to allow implementers to bootstrap themselves, if needed.  This repository will also contain the contact of the original author of the code.  The repository is sort of like an IANA registry of IETF working code corresponding to an RFC.  The authors of the I-D can be the "expert" and suggest which implementations they consider worthy of archival.  The boilerplate of implementations is given in Section 2 of RFC 7942 [2].  We would have to spec out an IANA-registry like process to do so, but I think that the ends will justify the means.
> I note that organizations like IEEE have evolved to provide a repository where authors of published papers can park their datasets for reproducibility (see IEEE DataPort [3]).  The 2017 ACM Task Force on Data, Software, and Reproducibility in Publication also recommended that, "The ACM Digital Library will need to interoperate with a number of recommended data repositories and software curation platforms..." [4]..  So this idea of the IETF maintaining a software repository is not entirely unheard of.
> I apologize for taking your time if this has been discussed before; if not, it is worth some discussion.
> [1] <>
> [2] <>
> [3] <>
> [4] <>
> Thank you,
> - vijay