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

Vijay Gurbani <> Thu, 20 August 2020 15:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3FA7D3A0C03 for <>; Thu, 20 Aug 2020 08:18:42 -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 Cv6IkIyQpOuz for <>; Thu, 20 Aug 2020 08:18:40 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::62c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 14E7C3A0BF7 for <>; Thu, 20 Aug 2020 08:18:36 -0700 (PDT)
Received: by with SMTP id jp10so2997526ejb.0 for <>; Thu, 20 Aug 2020 08:18:36 -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=Z9UQ2CQyfObqKmL56+6cnsHhSiGYbLWA6xPBxDBjEX8=; b=O1lfzA3DVXxHDIWXc1zCvCIarXdftr0zW/sCpI4f7k2w6k0i27C/KA0cAAo/0P7Lfq DMkx8SDAMieoxDG9YHWaZx2HwaVmNbcbl8TnkyzV1pg2zAq+4akqYLZXfBDmmRLs3Bfo 2B7JcAl8sGdWXaDgkOrfOR7RvlUTAd1achVfSHZXjbOGlthe0c66XPySAcu9ywV/EV9M VMTRMurnfd1s7ERKm/vuNnZr7T/i2bJrn16xukYl9bE8oJQga8BgknATFbT61YNheEbj aOpj/CZMtoX4DZjtYpS4b97wgNhvGGtJAUPMDcpnqUfEAbDdM0xFD/MQolJ4O2qpWLDq T4LA==
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=Z9UQ2CQyfObqKmL56+6cnsHhSiGYbLWA6xPBxDBjEX8=; b=QWtwba3ueT9UCOTOxvK6hpjPlFzK4TXoqbqApHYD08RqOwJ630oD0Lcd9L0wnh9jHN jM8spTzplkfScrs/IFfGA3kF/zyJLteIdZawBI5MPqKYx469OxZkjAYHpT2ukAegykF1 ZLn9otGhy3Us/lsr8ZP+YPuBTqsOvyPJP/PDhaZaDWzNCvkrWnzFpVo03PtZNQ2/W9I5 nfSdagflX0w2lQlGbMAxwk2iUTn1PIiUVtVdwy6EPpN2GH/YxpcXUZ7PKlLq/vumuExP 3zuoT/gBEig8fF5MNqRLmY1H7QY3fcyFSjMTOamB1wYlIqB7CPBEuMU7edcHtEcL5PyY S7PQ==
X-Gm-Message-State: AOAM531nfgfvHS2rYie4kpUDQ0T+tlwaa25mSvvkodLFIdGnPT10pH0A TeKUMalvX3Mx74MH1/YdLPI9Ha2+MSiXym7THdCh4vi763NTGg==
X-Google-Smtp-Source: ABdhPJzE5BDfwDMH9CC/0+GQNcleQal4DhP1i3xYY3Xa7+cn3WN+NqCsTJnuM0gllfiNMO3mte8C0yD7HfaXUOuakaE=
X-Received: by 2002:a17:906:d102:: with SMTP id b2mr3537041ejz.465.1597936714546; Thu, 20 Aug 2020 08:18:34 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
From: Vijay Gurbani <>
Date: Thu, 20 Aug 2020 10:17:04 -0500
Message-ID: <>
Subject: Re: [irsg] An IETF repository for working code in our protocols?
To: Paul Wouters <>
Cc: Stephen Farrell <>, "" <>
Content-Type: multipart/alternative; boundary="0000000000003e811005ad50a272"
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: Thu, 20 Aug 2020 15:18:43 -0000

Dear Paul: Good morning, and thanks for your comments.  Please see inline.

On Wed, Aug 19, 2020 at 9:10 PM Paul Wouters <> wrote:

> As a Fedora and RHEL package maintainer, and as a person who has forked an
> IKE implementation that still hears about the pre-fork code, i can tell you
> that unmaintained code _very_ quickly loses value and relevance. I do not
> think there is any value in the IETF keeping a copy of unmaintained code.

The proposal is not for the IETF to "maintain" code, with all of the fine
points and complexities that entails.  The proposal is simply to provide
starter code that implements a protocol, period.  There is no expectation
that this is production code.  There is no expectation that such code is
mandatory to provide, just that if someone has implemented the protocol and
wants to share their code, well, why not.  It may make it easy for others
to bootstrap themselves.

There is hardly any point in looking at 5 year old code. For one, it won't
> compile with current C compilers. Or to pick another example, 5 year old
> code using openssl (0.9) will be useless now with openssl 1.1.

That is a good point, but pragmatically speaking, an implementer looking at
a RFC that is 5 years old and contains a link to some code that was current
5 years ago should reset their expectations appropriately.

But taking an extremist view, I will note that for the most part, I can
still compile 10 years old code with the current version of gcc (10.2.1) on
my system.  Most languages, even as they evolve, tend to keep backward
compatibility.  Yes, there are cases like Python 3.0 not being compatible
with Python 2.x, but those are rare.  One of the reasons that Java Generics
have such a horrible syntax is to preserve backward compatibility at the
bytecode level.  So, at least I am a bit optimistic on the language front.

> I also share concerns with people who mentioned that leaving this in RFCs
> quickly becomes advertising.

That is a concern, but earlier emails in the thread touched upon it and
ways to mitigate it.

> Also, any bugs in "IETF references code" would become the new defacto RFC.

Respectfully, I don't see why that will be the general case.  I suspect it
will happen in some cases, nothing is ever perfect after all.  What is
under change control of the IETF is the RFC, not the code, which is an
artifact of the RFC.

> I think the current method of Implementation Status is exactly how we
> should want to keep it.

Yes, that is certainly one outcome.  Thank you for your thoughts.

- vijay