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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4F0BC3A1221 for <>; Thu, 20 Aug 2020 11:28:11 -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 XcvYsjkKVbgG for <>; Thu, 20 Aug 2020 11:28:09 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::533]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 652513A1220 for <>; Thu, 20 Aug 2020 11:28:09 -0700 (PDT)
Received: by with SMTP id ba10so2420139edb.3 for <>; Thu, 20 Aug 2020 11:28:09 -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=N3uWkzc9kaKClBOsQxjwt4ceJa3dR4K+V/958H8/jRU=; b=EOrYHC/bo4HNQ2SOjoJl1BBIy8ecPVliMF4mSgslGnaRV20GM/ZMCssn8g2ZMZz5PT sbsgkwN0ymYErGgz7s72l9aImOw+8S8nKzYxHdSbbM04ZK7HR98otbXYQtwpZh3X9r95 /0pzSS0v1JnyAlOwVOzWTSvHAGZ6zfKgHAALMHgJE/KppXGQKHZqIIqNen60gwwm534R bqMR8KA46zkHmLnBHMBtqCBtmT/GtKJbvA3z+oRREpAUF0kpUMt+yMWPin39kLEuKacU 0kL7RZpv8b1Nxp4gIIijRExUXgnUMv1gTQSJpky49u+faEiM7jvT5yZQVqVBL7qBT2R+ 9WdQ==
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=N3uWkzc9kaKClBOsQxjwt4ceJa3dR4K+V/958H8/jRU=; b=l4O3hyGgJYEQb9tBLxG0dh8nYjb2nH1LJhR9x5gktxTIIPNcGERIfIEYqaYQzgg87D knikivTdane/yqq/HYelRwdM/UBbcVQCGCjTxdEIhDvycgclJXAePO3OmerUQx+YLnJZ 7TNh6NmRzKwjnzMt4QqBfTPFuBfxGbt6VJJv+0i3hvPnChwjb6vzQG5feGj+IC9yxw9u 9zy56zbSlNvOfVvnp0k5PHL7sKgNI5knGSS2Dtbu9rDGodN/ea8XuXtkfAV7CNFvIcXD 8YCZPU8h9eR2mH/GHvMy4A4wDX6ADBDD0s3+qfG24dkjISfX3CvWck3PbhBSiQCkb3UG 6GwA==
X-Gm-Message-State: AOAM533Ut97NP6FNAdw1+t4CC0vjdZx0yBKcP1YUQKcRG61138GUtFBT kfk1BVALbisy+n5CcogS/+bQT8LhoFC4zDnQ1pUBprTz3jrJ1YIX
X-Google-Smtp-Source: ABdhPJyXLpyyNkePz9ZqdeV/28ln1Sp7yMvPQj+j9YkGOdJ6ArYqZ/53iYy/y7TjQe7kIvb/1gZKvpVskiUk86ywU3k=
X-Received: by 2002:aa7:d5d5:: with SMTP id d21mr4199624eds.229.1597948087711; Thu, 20 Aug 2020 11:28:07 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Vijay Gurbani <>
Date: Thu, 20 Aug 2020 13:26:38 -0500
Message-ID: <>
Subject: Re: An IETF repository for working code in our protocols?
To: Mark Nottingham <>
Cc: IETF WG Chairs <>
Content-Type: multipart/alternative; boundary="000000000000233b0805ad53483d"
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 18:28:11 -0000

Dear Mark: Nice to hear from you, and thanks for your comments.  A couple
of observations inline.

On Wed, Aug 19, 2020 at 8:30 PM Mark Nottingham <> wrote:

> Hi Vijay,
> Just my .02 - I'd be wary of an IETF repository of such code, as that
> would convey too much authority on it. It would also create a fair amount
> of overhead (especially for long-term maintenance).

Conveying too much authority is a valid concern, no doubt.  As others have
expressed, we do not want to condone a "reference implementation", or
engender some type of advertisements by submitting source code.   This
would have to be worked out through a process, if we get that far.
Regarding overhead for long-term maintenance, the effort of maintenance
could be made similar to the effort we spend on maintaining RFCs, where
most of the effort is in filing and validating errata.  Errata for source
code would mean a patch, and I can see supporting a patch or two for the
code that was submitted when the archive was established by the publication
of the RFC.  However, I do not foresee that we would constantly keep adding
new implementations to the archive, that should be out of bound.

> I also don't think that it's necessary, once a protocol is successful;
> after broad deployment, people don't need to go searching for
> implementations. It *is* useful when a project is starting, to help early
> implementers find each other, though.

Yes, agreed!  The idea would be light the fire of widespread implementation
by the kindling (code) that tracked the I-D as it became an RFC.

> In the WGs I participate in, we often use wiki pages to track early
> implementations; e.g.:
> *
> *

The problems with Wiki pages and datatracker hosted additions is that we
(i.e., the IETF community) know what these are and where to find them.  But
I maintain that the average developer who is implementing an RFC will not,
on the average, have the required background to know where in the
domain it should go to in order to find all of these additions.  They will
only know one thing, the RFC.  They will know the errata associated with
the RFC because a link to the errata is on the RFC title masthead.  It will
be great if there was a link to some starter code for new protocols.

(I suspect that I have not convinced you, but that is okay.  This is an
exchange of ideas so far to see how much of this is indeed workable.)


- vijay