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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B03B73A0CFD for <>; Wed, 19 Aug 2020 09:44:24 -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 bOOPMYwoK1nn for <>; Wed, 19 Aug 2020 09:44:22 -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 0B20A3A0D0D for <>; Wed, 19 Aug 2020 09:44:21 -0700 (PDT)
Received: by with SMTP id t10so27084549ejs.8 for <>; Wed, 19 Aug 2020 09:44:21 -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=uTTKyclAE267DHD0F6egxsyUouw5proDNmM4mLHtuys=; b=asJT/RDfpmZBUCrQ9LCA2/I5/oK5Nab6n1ii3ySwO1gVJNJJSR11FVBZkWRdYeTEVM pqy9ttidAX2P5y1HTHVGOld/5LbGQHLd5I5qBr2oUgla52qfwh+9epvChzgi/jis9PcV Xsz20PeIWKwNwJEWmuQj2WoAyOv8w4B0ciQUrVwP+OCuMW2lW/hgIzIJT3l8cAs5tPew ufu4eCD4z6/Of98IOzkdrnbEbVHRCXdjhPIH9KWdAIAn9jYTBmSkvWsy8vAxIyG2wtj3 VpA83jol3El0xlrm9hakEgykd7Vi5nec4mF1ooEdy8iqyKoioywMJDorAb/lJBCvJcKz /S3Q==
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=uTTKyclAE267DHD0F6egxsyUouw5proDNmM4mLHtuys=; b=rkG3IDbUC0nbH50+RMLQjgibZQeI4xinnqeNSeK4G0EHrMtuOy+GB1prd68xBNnO+x 3xYRPQIpZp76wsa9mpug4QDEvAoMh/p7KxH5C4xpYWnFzn4XVJY7543nD19nJNuV1REU FpR7ism7M/XNTWhsRY8aFj2nQ7PSsuoVH2lbIDVOfSUtgGOi8nHVgl9y6FwjIhWOk3LL iE3YlHqgAzQXfxt6Ylexxaav7LW4EiVwfiCAKhkdfNNF0RPK1R9PNlM+RB1hL9GWODTI gO2AQLbnHc270CZpv8RoVljLLWPN+MQzk7jofKla1gp2U8cIw8B72yZLJUvqxN+n8y1B jxXw==
X-Gm-Message-State: AOAM533wO3KzYoawQTbjwybV6jZdMqO/lGaTzHpovIRs0qIVDaBVeBZO +D/rAtLw+C5ESpHhW17/EGyKCY8P9xdgL/iv03s=
X-Google-Smtp-Source: ABdhPJwXVwfGCGhoJQ2d3Gzd+TzuPVRCLge0PScwxdPZF4JECeMDyjFc7+MDwADGq1uFqEdjbP1lJi8zetOpAuFHbV0=
X-Received: by 2002:a17:907:7255:: with SMTP id ds21mr5412859ejc.44.1597855460416; Wed, 19 Aug 2020 09:44:20 -0700 (PDT)
MIME-Version: 1.0
References: <> <056801d6763c$f0296b90$d07c42b0$> <> <>
In-Reply-To: <>
From: Vijay Gurbani <>
Date: Wed, 19 Aug 2020 11:42:51 -0500
Message-ID: <>
Subject: Re: An IETF repository for working code in our protocols?
To: "Joel M. Halpern" <>
Cc:,, Martin Duke <>
Content-Type: multipart/alternative; boundary="0000000000001edf4205ad3db790"
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:44:25 -0000

Dear Joel: Thank you for your time and your thoughts.  Please see inline.

On Wed, Aug 19, 2020 at 11:19 AM Joel M. Halpern <>

> I would be very concerned about the IETF appearing to endorse particular
> implementations by archiving the source.  I would be much more comfortable
> with Adrian's suggestion of pointers to implementations that wish to be
> listed (open source or otherwise).

I believe that there is an implicit assumption that by archiving the source
code, the IETF is endorsing a particular implementation.  I can see reasons
why it may be construed as such, and perhaps this was what Adrian meant by "the
IETF becoming a venue for advertisements".  This is definitely not the
intended consequence of this process.  I can also foresee that if there is
a de-facto state-of-art archived implementation of a certain protocol, then
derivative implementations may become genetic variations of the de-facto
implementation, with all of the problems that this will entail.  So, yes,
this is a concern, and the question is whether we can mitigate it in some

> In terms of your concern about wiki maintenance, archives of source are in
> my opinion worse, since they will not have any fixes made after the archive.

Right; we cannot mandate the fixes, of course.  But the purpose of such a
repository would be to provide bootstrap code, and allow implementers to
find efficient ways around what they started off as.

In terms of visibility, I do not see why an archive is better than a  wiki
> page.  Neither should be called out in the RFC, since they are transient.

I understand and respect that point of view.  But I will note that RFCs
themselves are transient.  Even an Internet Standard can be made obsolete
at some time by a new RFC-to-be.  So I don't see the above as problematic,
and instead see that it benefits implementers who are not part of the IETF
lore and just look at the RFC to figure things out.  (And I suspect these
implementers are far more numerous than those of us who attend the IETF and
write the protocols.  My interest is in reaching out to these implementers.)


- vijay