[Edm] A modest proposal (?) for archiving code

Vijay Gurbani <vijay.gurbani@gmail.com> Fri, 28 August 2020 15:12 UTC

Return-Path: <vijay.gurbani@gmail.com>
X-Original-To: edm@ietfa.amsl.com
Delivered-To: edm@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id A34BA3A0C75 for <edm@ietfa.amsl.com>; Fri, 28 Aug 2020 08:12:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 5Fn63GvSj5O5 for <edm@ietfa.amsl.com>; Fri, 28 Aug 2020 08:12:16 -0700 (PDT)
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D56083A0C7A for <edm@iab.org>; Fri, 28 Aug 2020 08:12:15 -0700 (PDT)
Received: by mail-ed1-x531.google.com with SMTP id ay8so1461859edb.8 for <edm@iab.org>; Fri, 28 Aug 2020 08:12:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Jipk0TKaDXlBjrNeJbzC/AHncTNl8Ho7gg9fe0yNJ7g=; b=L7MP7CD2kn92ZPwV//EKaYD6bbzPF0/dEB0okqbQ6QEcHTVyyr4DmolCPrch7VZLu+ 32XYZ9Ny3OJpu9L+zMY0guAX53dR79mJS2xmk5GVoNuTUGRfo/n3APoLEI6bNO6krvAq BlpNG1djLvKMIUSqycLlrVhTIOetzNNaGW3Eq8d7FMF0uQe7LF+XK/ejHerjnnthpkDz BHb5fR7OuHF6v8Kh8t3YHKs/AzfZBHCkPBNrmE2+NWsAT7tsoBEE9u+24E9vt85h6382 PR1OrO9Z8p8qsoRptOtzbICjkXK1EYsKB5J2e93oiSaYOXBjazk8BUC+3BKGrgwU71zq 8hVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Jipk0TKaDXlBjrNeJbzC/AHncTNl8Ho7gg9fe0yNJ7g=; b=Jrt5OgTkQrk4Eg2OLFSDlcfQbFEzRjYxFlK5MORyj/Rr8U+wBk5J/Ve6IpLCo5rKtZ d9cWnUHH7xAh79qxniJXzdV+afqY5zL9cOTihzkdCD3poaMKZGJNvJxMYEyvCf8o7h8A dH8Er/1RmjNOr7riLCmq2+12iBjzYMpnBMhCGNSnm7jcTTSBkLOwLt9RRfNhAhSXeJem XPGV1SdHK4DBGEMEaXH+YCbcffxM922jIWuU/UZQiHlDDouc0iPdgXvA/ZlmHo+UO8Mm h13esL/OmK3mpg97GLfPbRxMy8by1Xrn8Dscn+qPC/6mYR9+jCdP5OvqwVd5d+U8u6Ds BrSA==
X-Gm-Message-State: AOAM530WHERDNoGSHAGfJ35FmW51f1BC5zmOUUtSo+Gn8K3M/6vRdPuI mqFfrBaOH0kOoBWoo5zEz8Bcq23UWQTVQT9h6TR7qVt35JjeYA==
X-Google-Smtp-Source: ABdhPJypMWi3uWx40lq6RKvwLn7snJqbVfbyJ3eYts7aQvSofS3O0IDLr7S519UK5fq2d6NQ0aJtbYMvQUSl/PPiez0=
X-Received: by 2002:a50:cd08:: with SMTP id z8mr2454028edi.185.1598627533691; Fri, 28 Aug 2020 08:12:13 -0700 (PDT)
MIME-Version: 1.0
From: Vijay Gurbani <vijay.gurbani@gmail.com>
Date: Fri, 28 Aug 2020 10:12:01 -0500
Message-ID: <CAMMTW_KF9qZuFtwBS3O4Qe6Lw4z1L1LFsE=UBHbPV426nbmLiQ@mail.gmail.com>
To: edm@iab.org
Content-Type: multipart/alternative; boundary="000000000000461ef805adf17a39"
Archived-At: <https://mailarchive.ietf.org/arch/msg/edm/SYMiweW_-RsZzPoWq3Snijk1IJQ>
Subject: [Edm] A modest proposal (?) for archiving code
X-BeenThere: edm@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" <edm.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/edm>, <mailto:edm-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/edm/>
List-Post: <mailto:edm@iab.org>
List-Help: <mailto:edm-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/edm>, <mailto:edm-request@iab.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Aug 2020 15:12:18 -0000

All: I proposed what I write below in the WG Chairs list; the list saw a
good amount of discussion, ranging from summary dismissal to exploring the
issue further.  One feedback from there was to engage EDM.  So here we go.

Let me provide some context below, including links to the postings on the
WG chairs list for those of you who may be interested in exploring that
discussion further.

The genesis of what I am trying to affect is simple: We produce standards
that describe protocols. As a protocol is being defined in an I-D, there
are often implementers implementing the protocol or portions of it. These
implementations are important, enough that RFC 7942 [1] recognizes the
import of these implementations and exhorts I-D authors to create
an"Implementation Section" to document these implementations. RFC 7942 also
asks I-D authors to remove this section before the I-D becomes an RFC. My
question is if there are implementations that are worthy of being mentioned
in an "Implementation Section" of a I-D, why don't we preserve these
implementations in an IETF repository and link the repository in the
RFC.This way, new implementers of the protocol can quickly bootstrap their
implementations, leading to a diversity of implementations, which can only
be good for a protocol that is trying to find its footing.

Why is this important? Simple: Reaching out to developers outside of those
of us who are already in the IETF is my biggest incentive. They are the
ultimate consumers of what we produce.

When I talk to developers at companies and students at universities, if
they have heard of IETF at all, it is mostly through knowing that
someorganization called IETF produces these things called RFCs. That's
it.Perhaps for them that is enough. And if you buy that argument, then the
corollary is that we should do everything in our power to make sure that
they have all of the information they need to implement the protocol from
the RFC itself. Consider the errata we maintain in an RFC. Imagine instead
of us providing the errata, we simply told implementers that it is out
there, go find it. The errata is important, so we list it in an RFC.When a
protocol is finding its footing, early implementations that allow other
developers to understand its behaviour and derive their own implementations
from it is also important. So why not formalize the process of archiving
implementations that are worthy of being listed as per RFC 7942?

People have pointed out that we have WG pages, Wikis, datatrackers, and
other such accoutrements for this purpose? WG pages, WG Wiki pages,
datatrackers, all make sense to you and me. Many people will like to
implement our protocols without burying themselves deep into IETF to know
the difference between a WG page and datatracker. Their visibility into the
IETF is through the RFC. So, put as much information in there that will
make a developer productive.

I don't claim that this will be easy; the length of thread discussion in
the WG chairs list indicates the passion of the participants around the
issue. However, I don't think that the issues raised are insurmountable.
The fact that an entire RFC [1] was standardizes around the issue leads
credence to the fact that it is an issue deserving some sustained attention.

My initial email that started this discussion in the WG chairs list is in
[3]. It has more information and context, including how organizations like
IEEE and ACM have dealt with similar issues.

[1] https://tools.ietf.org/html/rfc7942


- vijay