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

Erik Kline <> Wed, 19 August 2020 20:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3899F3A0DC4 for <>; Wed, 19 Aug 2020 13:09:23 -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 LOrnl7ECRMHA for <>; Wed, 19 Aug 2020 13:09:21 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B42933A0DC2 for <>; Wed, 19 Aug 2020 13:09:21 -0700 (PDT)
Received: by with SMTP id z18so20104995otk.6 for <>; Wed, 19 Aug 2020 13:09: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=/Mh7uD5AaHbbTvw+cZ05K3YJve0grRxxT9PJnmGwhvA=; b=oBz2Vj+GYOu0h6Mp8TA4ROKG4ppgpFIAFQDSCtIL6C/bq14EWV/5epSvJEUjh/xzls GGvmC6Va3p8gEQGXrTIzhzFS3zJSyx2eTPKnRVU1ge26lU7N5zlwzPfAixnrdkgpmY2r IJZQxY3L98jZdW6gchxGNK1HO9P56StVPhSZQlW6mVbRMPIHFoj0O4SFXkelc7UKd2+T DhR65zEVUwhjGk8V/7aS9jO6lVs42q956DbgFz1RiYvGW8JpUNlqw3zr6Ex2/45FBRfN 2yBTFelsVum8Y++NOlU/smew9IR146wok/Hp2GQc2npAYAXLLjbSSmnh3TPm6dSSQ3TQ urdw==
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=/Mh7uD5AaHbbTvw+cZ05K3YJve0grRxxT9PJnmGwhvA=; b=N2gjbZhgHB/6xITAa2nfalrEbiWS8Z3X6EBua5AKfAjd+oQF+VBkkqH01xAmwuWpTo kZe4fvJ7pUrIATs4Izo0U4pJgN22JTLoZ8oQG/ya+XiXtqFNoyCaoAtPv2nWqGNvDB0I pTCuFYbWfzuZWue3kE8CutYyJBr3usAyl6dcx3RAjtegxKkXKpfAOPQQu8I5+eRHA8EA tGhcMLBjvDM86aFUVjw2jl49S4pnerXk7y8/U3njSpm7VljEuiHEkkAxVazxYFtfpBlJ quIgI716O0/3C9jq5ByXxpzpEC1s7X4eY3CEYSvXS6dpif9+zybvRcJd/YG+WLmQhBGf CN4Q==
X-Gm-Message-State: AOAM5304LQPLD1ds6aCnZri2pxEeGv8Di3Ji0J5ClKo1u+rh4i8MQZVw xYymEVJUueun9CyCwij3VU5Er+9OaDcHc7D4DS4=
X-Google-Smtp-Source: ABdhPJyQSn+/N6QDW9QYcdD0Y1eal00NCnd3fRcDn8IsAMFN5QHOwKvnC//HXTKjILp8HagSqJf2liZo9MR/C++Xc1o=
X-Received: by 2002:a9d:202f:: with SMTP id n44mr20181277ota.191.1597867761097; Wed, 19 Aug 2020 13:09:21 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Erik Kline <>
Date: Wed, 19 Aug 2020 13:09:10 -0700
Message-ID: <>
Subject: Re: An IETF repository for working code in our protocols?
To: Vijay Gurbani <>
Cc: "Deen, Glenn (NBCUniversal)" <>, "" <>, Martin Duke <>, Tommy Pauly <>
Content-Type: multipart/alternative; boundary="0000000000004c5ede05ad40943d"
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 20:09:23 -0000

I tend to think that the value of example implementation code varies over
time, in no small part because people often need to redo an implementation
because of development language requirements, or they're building a
component that subsumes/merges several protocols, etc.

The things I find most useful are the those like the NIST and crfg RFC
style of test vectors and expected outputs (and even sometimes expected
internal state!).

I would love to see some kind of standard approach for documenting what are
essentially unit tests: given these inputs/this state/this HTTP method
call/... -> expect these outputs/state changes/lists of observable

Given the centrality of interoperability to the IETF, this seems like
something we might be able to explore.

On Wed, Aug 19, 2020 at 11:48 AM Vijay Gurbani <>

> Dear Glenn: Thank you very much for your note.  More inline.
> On Wed, Aug 19, 2020 at 1:19 PM Deen, Glenn (NBCUniversal) <
>> wrote:
>> Hi Vijay,
>>  In additional to the points others have made, I’ll add that an IETF code
>> repository would need to carefully work out license issues and also how it
>> fits into the IETF’s Intellectual Property set up that is managed by the
>> IETF  Trust.
>> [...]
> There may be more that pop up once the topic was looked at deeper.
>> I’m not saying that any of these are show stoppers, but there’s a lot of
>> legal elements that would be need to worked out before any bits got checked
>> into a repository.
> Yes, absolutely.  All of what you listed are important and weighty
> concerns.  But none of them appear to be insurmountable if we decided to do
> this.  Clearly, the precedent set by IEEE and ACM in similar areas seems to
> point to the possible existence of a happy medium, should we go this route.
> Cheers,
> - vijay