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

Vijay Gurbani <> Sat, 22 August 2020 03:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 564DD3A098A for <>; Fri, 21 Aug 2020 20:27:00 -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 BWkz0-V1c6F6 for <>; Fri, 21 Aug 2020 20:26:58 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 491CB3A0989 for <>; Fri, 21 Aug 2020 20:26:58 -0700 (PDT)
Received: by with SMTP id bo3so4815986ejb.11 for <>; Fri, 21 Aug 2020 20:26:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WYiSUTJtkzpJxb9o7DSFno2KAhq6mbMJM1R34nLBQoM=; b=Zwxa321ytu1xBNd1dVmgQsYXYkdM7Wc6xk5UsbQbqfqu+VpcwggV1s3r6LDaf7pCFn Mc7j7xiyQ5DaxtjUkBKqEgnEbfv535p07O44r6G83WK6TzCmNFsvb+6IVeD73su8Ufq/ I7wqFW9aAXbug2oyuFStMuSkwSEbSCIccBxZpgkzqddMvm3UoBx+NSQbSLi1wCnAPFwL IgBe45WDi0Wyug2Lgvme05xggNLHasF9eBbpi5qvkEPs96gPT0iI3687fj/D5ramBRvs 0DsV20JGcbjCAnanhWT4GPxk+zT6fDY740bgrvhJbToqHQf1ihJFOyk2mtyaM0gXZNzL z1xw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WYiSUTJtkzpJxb9o7DSFno2KAhq6mbMJM1R34nLBQoM=; b=L/F0RGV6D8v63uU/hAfqWXmApj8HWk3O8tUh1Iz0utWszYKrhaH82dbTg3QhF7Ovlc dEb5wOkYsTzuz5YCEdZKeLdH/beqqMuveDCSvC/HZwvMbhpOyqqCBL69p5UTsBQWhYGY PbyqwnQW8qUuXVCUMgt3tNQ4YnBW5RyPVrwCREpum3mmtHc0JgA9ml2wSj9vxq/pnVIX TsF4V0prqZm+nVxP0aKkMf/QubAdYyG06xMSR+u6jL6IAo/trCgtuIBVTcI7ZgaXSOEF O7s+FuRYh0uh4S/EIozeJjAtJTMmUlQhG8EC29QCOdi8y/u0eJexiXnNCP5+pHGwfiht 8Pdg==
X-Gm-Message-State: AOAM531noGEu2Njp+pdteHwXuRwFYaaobO7BetMVn3rPfni1p6Hqe5Fk Ofmq6MYn/VSLzWoLwSV4nET0U/chVgWpWbyOT1b3gAMxW+icbA==
X-Google-Smtp-Source: ABdhPJyzEO/TVt4O2hP7c6HjRZK/vU6ETQIvcQdVg74I4LI4SCLFTTQ5quMumb+F1Hdkcw0V8mVGZgiqxHGP46z3gcc=
X-Received: by 2002:a17:906:add7:: with SMTP id lb23mr5310534ejb.335.1598066816541; Fri, 21 Aug 2020 20:26:56 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <15396.1598028610@localhost> <>
In-Reply-To: <>
From: Vijay Gurbani <>
Date: Fri, 21 Aug 2020 22:25:26 -0500
Message-ID: <>
Subject: Re: [irsg] An IETF repository for working code in our protocols?
To: Jane Coffin <>
Cc: Michael Richardson <>, IETF WG Chairs <>
Content-Type: multipart/alternative; boundary="000000000000ed667505ad6eec1b"
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: Sat, 22 Aug 2020 03:27:00 -0000

On Fri, Aug 21, 2020 at 11:56 AM Jane Coffin <> wrote:

> I hope I do not sound too clueless, but is the objective in creating a
> repository to educate future coders?
> If yes, wouldn’t they see that already in running/operational code? Or, is
> the idea to show how code changed over time/got better?
> If no, what would the repository do to educate folks new to the IETF
> protocols.
> I ask these questions sincerely and with apologies if this is super clear
> and I missed the context.

Dear Jane: Good evening, and thank you for your note, and your interest.

So, let me start off by saying that the intent of what I proposed is *not*
to educate future coders.  That is the job of universities and bootcamps.

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 some
organization 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.  Not to many people who 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 this thread indicates
the passion of the participants around the issue.  However, I don't think
that the issues raised are insurmountable.

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

If you have further questions, I am happy to answer them.



- vijay