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

Adrian Farrel <> Wed, 19 August 2020 15:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4A5253A0B71 for <>; Wed, 19 Aug 2020 08:25:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MAY_BE_FORGED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dCeWdtWDkof4 for <>; Wed, 19 Aug 2020 08:25:24 -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 AE62C3A0C82 for <>; Wed, 19 Aug 2020 08:25:22 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id 07JFPGhv005857; Wed, 19 Aug 2020 16:25:16 +0100
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id 5FAF12203D; Wed, 19 Aug 2020 16:25:16 +0100 (BST)
Received: from (unknown []) by (Postfix) with ESMTPS id 4A5FC2203C; Wed, 19 Aug 2020 16:25:16 +0100 (BST)
Received: from LAPTOPK7AS653V ( [] (may be forged)) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id 07JFPF1F012791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 19 Aug 2020 16:25:15 +0100
Reply-To: <>
From: "Adrian Farrel" <>
To: "'Vijay Gurbani'" <>
Cc: "'Alissa Cooper'" <>, "'Martin Duke'" <>, <>
References: <>
In-Reply-To: <>
Subject: RE: An IETF repository for working code in our protocols?
Date: Wed, 19 Aug 2020 16:25:14 +0100
Organization: Old Dog Consulting
Message-ID: <056801d6763c$f0296b90$d07c42b0$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0569_01D67645.51EE6FD0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQFwg+L73cxMJIYIU3QWFfYQuftMLqoLb8cg
Content-Language: en-gb
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--5.072-10.0-31-10
X-imss-scan-details: No--5.072-10.0-31-10
X-TMASE-Result: 10--5.072300-10.000000
X-TMASE-MatchedRID: yebcs53SkkCzLTBwo8TJunFPUrVDm6jtP1EB4PPRVRt5xaVclJA5pc8J UuVypuWwBMB4GX/Gdj1xoPm2k2WMql2AYsCojQrlOGJyJBH/4NBbD9LQcHt6g1hs8uimgHNCSHg UVMoIv2FoNIm/LFsCSrO7dBCzgVaL0Izuock/1MllI0vGyCjKvxiDIOPlOJG1baZMa0fgRtbzPB GPMFcet0IlIhzTEW9vj+7mTuqX5StyC2HHtDPI+qmukiZOfPi2NGzPoDPB/1JWPcnrekBHfGTSm bUCgpfnWSLI7fNds3Bw8l2zyajsPXuuzcuRDfPkCXqEi7UOR/POuu1xUPUEK133rgHQQnWVl3WI ETBeWZ78lqLN99KnHtegtaASmupDFPfCRmGThsuHbVO48Fx2baxT+JfQDbCPY9tXPGh/u0OkwFT CCpbFR5gU4qZEVVvi1cmYpxfNT5olalBKWcFrBj8mh1cI7ZYGIiTd2l7lf6HX1cRD6e4P5KdUHA 2nZo7Zs1xoY26PdyEhMXMUFaDgT8kzkqzY5vbYT/xYdI676S8yfWkCe7NWWlR/FX36qpogKDTOH G1iwSPB3BpAaNieN6KI5sdMhQ9JIrDBDJBPVs4JuplsyNNdx35Lmbb/xUuawgME763sEiJyj1ov gn3IuqCsq4B/5cNNiUADBkvjIaX4515TanER7I6MisxJraxHghehpAfYfg9JfyfUaPjAAS0jJ4i sStdqXjrln/a2EPFP2K5ry2gNnq/zvofwBAw7EqvlxVs2gMoQtuqs6BbPJ2R6gxKNGoFmjXAMNd enagelPlLmvavB0h95HWtSnJR9AM0/G7XUdeOeAiCmPx4NwGmRqNBHmBveGtkvK5L7RXGw7M6dy uYKg16It0d3DpFXdGAf0DrQY5dy5UGSoMp/GwrthEc8eWD/5Epzt5w1fbRB4jjFSmB9sUK56u54 clpqYmsDDOKm3Vwz+ow3eY+G7LXDRBQVpMQHftwZ3X11IV0=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-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 15:25:26 -0000

Hi Vijay,


Responding as a co-author of RFC 7942.


When we first wrote the draft that became RFC 6982 and then matured into RFC 7942 we were conscious that any information about implementation held in an RFC is necessarily only true at the time of publication: it may be missing important details of implementations that existed at the time of publication, and obviously cannot be updated for new implementations.


We felt that archiving this information in the RFC may be misleading and also unfair, and so we suggested removing the implementation status section of the document before publication.


However, in Section 3 we note that there are alternative formats, and suggest that one reason for publishing the information elsewhere is:

   -  If the working group decides that the information is still

      valuable (and needs to be kept current) after the I-D is published

      as an RFC, and the Implementation Status section had been removed

      from it.

That seems to fit with the idea in your email.


Although out of scope of our draft, we suggested that working groups might like to use their wiki pages to track implementation and keep it up to date. We also (rather cheekily, IMHO) floated the idea that the datatracker page for a document might also contain a link to the implementation page (like it does for IPR disclosures).


With author hat back off, I’m slightly wary about the IETF becoming a venue for advertisements, so I would encourage people to be quite careful about how this sort of information is collected and maintained.





From: WGChairs <> On Behalf Of Vijay Gurbani
Sent: 19 August 2020 16:11
To: Alissa Cooper <>in>; Martin Duke <>om>;
Subject: An IETF repository for working code in our protocols?


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.







Thank you,


- vijay