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

Vijay Gurbani <> Wed, 19 August 2020 16:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BBD033A0D3B for <>; Wed, 19 Aug 2020 09:05:52 -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 S4DBvMMrhqWa for <>; Wed, 19 Aug 2020 09:05:51 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F0C533A0D33 for <>; Wed, 19 Aug 2020 09:05:50 -0700 (PDT)
Received: by with SMTP id ba10so18554256edb.3 for <>; Wed, 19 Aug 2020 09:05:50 -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=dvyezLZ4MFyKaqQOol8fatdpgB0iePvHfxkqOT82Lp0=; b=LsBQrsD+qdKKjk0j5J7NSChbX6wzORFutCzhX+iZzaK0LWPi9f5FAXMg5wT73jNBuE 8sk1SWwIlEvrzeMANz3/khoQUA4MS5DwASlKVafoXmVRM2lCzB4exAHAkidEzPqztyd2 sAWqMJ7tpRc8fpplWJoQ+N635lb+7dG/SF8PDUj91R030YbMKQFfbj2VngcfCV8OXYt+ W5Wh1Bj6R1gugRdAULhXmvDbaWkyJiGqfpIBSIfgNP/YJZamijEd36J1TkjHnwQ/LEe2 9DIayJsy5Paw0q/wyhIF2oUU0mntrU+j3fsVuzSa++U10tM9DVpywmI66AgKt8X4cbZ2 dkRA==
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=dvyezLZ4MFyKaqQOol8fatdpgB0iePvHfxkqOT82Lp0=; b=brc1Y7YfOL3eKHd0uI7XQ2HC7SyaVOOdivqlPdMM4NSTe4PYwqf0tl+f0z+6LN9ozC Ix3TK23jyBN/7xDHmJM0X7QHLMAcV0BYlM4cGK3+hS1JVlO92bhCoQ8PfZgSNQReVXy2 GP83T9QL9WkKBPh8885HgcmXZWS9/1HPRTlhHFLNjEoV1+lk69M3xAqJQeOhqtvgy+Wg y8VrOWAKESEKjWqQdiz8NEuldgPt1bUV+kvFc7UeLehlXI9W2kUosKRPU78XjSnJvIoR ftq2RLKcFd5DL73T5zy0mo7noSkkM+C9orTcCSfQUu7TQ3HFX8oa1XQOGoq+S3EQVG1k 9h3g==
X-Gm-Message-State: AOAM5304n9XxLDmKWdpUP6b5O0PLcuweVpYpvU8KNuNRENVuTEq22mqD HB3N2sLSZ4JPw/2S6nEBqZBDAFRHIrvhpM+cdgk=
X-Google-Smtp-Source: ABdhPJzknQxqyYKxLGuXeZM1QRtk3b0qTgMAwhCbE32kNhfzWlJBPJQgCFnjh+uXib8gta+RZS7zw8se3K4iy4FCa9g=
X-Received: by 2002:a05:6402:1643:: with SMTP id s3mr26373646edx.185.1597853149239; Wed, 19 Aug 2020 09:05:49 -0700 (PDT)
MIME-Version: 1.0
References: <> <056801d6763c$f0296b90$d07c42b0$>
In-Reply-To: <056801d6763c$f0296b90$d07c42b0$>
From: Vijay Gurbani <>
Date: Wed, 19 Aug 2020 11:04:20 -0500
Message-ID: <>
Subject: Re: An IETF repository for working code in our protocols?
Cc: Alissa Cooper <>, Martin Duke <>,
Content-Type: multipart/alternative; boundary="0000000000005d1db805ad3d2ddf"
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 16:05:53 -0000

Dear Adrian: Thank you for your engagement as a co-author of RFC 7942 as
well as your individual comment.  Please see inline.

On Wed, Aug 19, 2020 at 10:25 AM Adrian Farrel <> wrote:

> 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.

Those are valid concerns, indeed.  However, I note that the entire RFC
process is an iterative process itself.  When we release an RFC as a PS, we
release it with the knowledge that there may be some design choices that
could be revisited at a later stage.  Ergo, if an implementation tracks the
RFC closely, the underlying assumption would be that the implementation may
well be updated at some later time as the RFC moves through its states from
Proposed to Draft to Internet Standard.  To be sure, I am not saying that
we should simply archive any half-baked or incomplete implementation,
rather rely on the knowledge of the authors of the I-D and the chairs, and
perhaps even the IETF interoperability process for the RFC, to only archive
those implementations that are worthy of being archived.

> 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).

I think the above choices are sound, but I also note that: (a) Wikis have a
history of starting strong, but subsequent updates wane; (b) the notion of
checking a datatracker will not even occur to the average implementer who
does not participate in the IETF as closely as we do, in fact, I would go
as far as to say that the average implementer who looks at a RFC for
implementation only knows the RFC and the information contained there.  I
doubt that they would even be aware of what the datatracker is.  This
observation is borne out by my individual observations of talking to
company R&D staff who know at a very high level what IETF is, but beyond
knowing that the protocol is specified in a RFC, they do not know the
accoutrements associated with IETF that we take for granted (working
groups, area directors, areas, datatracker, etc.).

Thus, just like we have a link to an errata on top of the RFC, we can
maintain a link to archived programs that implement a certain RFC under
strict assumptions laid out in some document.  (These would include no
guarantee of fitness, etc.)

> 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.

I suspect that you imply advertisements as indicated by the domain name in
an email address of the source code's author.  Indeed, that is a concern,
and we would not like to have half-baked or incomplete implementations
archived simply for perpetuating advertising.  I believe that this can be
mitigated by due diligence of the I-D authors, chair knowledge of the
protocol, and any bakeoffs that the WG has overseen.  (I recall that when
we were developing ALTO, there were multiple implementations of the
protocols and various extensions that could have been useful for
individuals and projects like the Open Daylight SDN controller and its
support for ALTO.)

The law of unintended consequences may yet still strike, I don't claim to
foresee all problems.  But insofar as we seek "rough consensus and running
code", having "running code" from multiple strains of company (or
individual) DNAs seems like a reasonable goal.


- vijay