An IETF repository for working code in our protocols?

Vijay Gurbani <> Wed, 19 August 2020 15:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4E8583A0866 for <>; Wed, 19 Aug 2020 08:12:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 nGPaEbg7jnCo for <>; Wed, 19 Aug 2020 08:12:08 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AA8E83A0B05 for <>; Wed, 19 Aug 2020 08:12:07 -0700 (PDT)
Received: by with SMTP id w17so18380892edt.8 for <>; Wed, 19 Aug 2020 08:12:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=caAN0Prhtox8mFopSxBPi2qqTUQkpHugTv59oFwxvjc=; b=lZTLjAigN6TIp8Kf6GG478QAx/dl9NI6U9pu58r1rmOOIc3fpmiOKOhi/2CRyd7YA+ 7scYIuUVyPxMnXs1RSUScDPtBoXizub6VlzfFXUr7vT0pZxMDeY4MSdUqo6O9t+ukA/H M86TQia66NiUdicYRNhMNKso25R+nGNQpmPrjab3IBbqs7V3W+n+ptfxK4/iu0BWU52u g5sZtmbhiEdppkNxRDcr/hHZHoPjtiPHGe4u/rKdzVtJQ0xZBOFBJf/c+zPe3EFJxX0W EGBfD/DgWlnshgrKuB9vmeXIhY3VCW9CRzU8CFytqOIzey8AxY9/2OIkwrOaD1GNW9f1 Q7ug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=caAN0Prhtox8mFopSxBPi2qqTUQkpHugTv59oFwxvjc=; b=mwbasF8OfW4vcqzrgEM49KSnDhUQKlZUoDS3w3U00lXlNwFUTGZWWEcZGZwkMDNKBJ Ew8WH8X1S5N2MBHKUJeKQT4tWK/h5iPIUEQZsFSDFd4eLMDCDuPAUOYJweQM9bdWLLNS 1cVlK7wds2lcUegn4HVziO4TzrM3bQnqngoR9tdEyC6n1rQq+mok+2x5YgQhx2iE15DV ey9HrXTKtXS2ywcJ71g6kZl57GoG1FAFr3gOziOPidmOm0rH+tNAlXQi33tS4/wo3vJP gfaYKDE4rAMlIOPgUxWcLThPQA/Bf/LWB9oTGH8p1uochF3sJMW6c4FzXUiBjFde5hfN r2qw==
X-Gm-Message-State: AOAM532ms3I8n9bm7mwrbo1Lae2FKWYBOATXM9u6czRnFjEV15hz1YqK 3441kHVcLUbsq1sZS+yYNiAUx1c95PVg5rc3lp4=
X-Google-Smtp-Source: ABdhPJwkPwoIQSDhfHD7vr5IzDcG/KLiOJxciZzzfV17IphPMv/Bodrq6XNA3vMf7gKrmuVZN9YE68fOz7VkiyDuJ5E=
X-Received: by 2002:a50:ef0a:: with SMTP id m10mr25553725eds.226.1597849925873; Wed, 19 Aug 2020 08:12:05 -0700 (PDT)
MIME-Version: 1.0
From: Vijay Gurbani <>
Date: Wed, 19 Aug 2020 10:10:37 -0500
Message-ID: <>
Subject: An IETF repository for working code in our protocols?
To: Alissa Cooper <>, Martin Duke <>,
Content-Type: multipart/alternative; boundary="0000000000003c7c9e05ad3c6d7e"
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:12:10 -0000

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