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

"Joel M. Halpern" <> Wed, 19 August 2020 22:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8260D3A0ECF for <>; Wed, 19 Aug 2020 15:51:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.047
X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HWqEfW8mzKRg for <>; Wed, 19 Aug 2020 15:51:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 160053A0EC7 for <>; Wed, 19 Aug 2020 15:51:43 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4BX31W68Wfz4TG1K; Wed, 19 Aug 2020 15:51:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=2.tigertech; t=1597877503; bh=xRXcBoIbAJe6r55f7QEJnm6+w/yYvDSfW3XOxt+ijfI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=ZIBVVMJGNZiW0R0EHlswVnwHwLETkTd69b3v8FcuczvN3coE49MsDzf3s2FTtIE7W fgy4nawmlBjM0iBXU6IjYlif6+GTbnpVJL3atydkj7+RebMNrned6YLjr5BEiLjrFr euEbM50BsypHTymWDbztAOiJn2RXbMWAV5maTZZU=
X-Quarantine-ID: <XK9NNi7Owv1X>
X-Virus-Scanned: Debian amavisd-new at
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4BX31W2ghWz4TG1J; Wed, 19 Aug 2020 15:51:43 -0700 (PDT)
Subject: Re: [irsg] An IETF repository for working code in our protocols?
To: Vijay Gurbani <>
Cc: "" <>
References: <> <> <> <>
From: "Joel M. Halpern" <>
Message-ID: <>
Date: Wed, 19 Aug 2020 18:51:41 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
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 22:51:46 -0000

There is different value in open and closed source implementations.  But 
bother are valuable.
There is as far as I can tell no benefit in the IETF actually storing 
the source for these projects.  Either they are being maintained or they 
aren't.  If they aren't, the source has much less value.  If they are, 
the maintained one is what people should look at.

So again, having an easily findable and easily maintained set of 
pointers to any implementations that folks want to list, with whatever 
terms those folks like (whether that be creative commons open source, 
GPL, or descriptions of proprietary implementations) seems very useful. 
The problem of findability is real, but is not different for an archive 
compared with a set of pointers.

A set of input / output vectors along the lines Erik suggested also 
sounds useful.  For some protocols.  (I don't quite know how one would 
do that for something like OSPF.)


On 8/19/2020 6:33 PM, Stephen Farrell wrote:
> Hiya,
> On 19/08/2020 23:22, Joel M. Halpern wrote:
>> One of the advantages of pointers to implementations is that it can
>> include equally pointers to open source and pointers to closed source of
>> various forms.  The IETF doesn't take a stance among implementations.
> Entirely surmountable problem IMO. Add caveats to avoid
> misperceptions wrt stance.
> That said, open source implementations are plainly more
> useful for people who want to implement RFCs, compared to
> equivalent closed-source implementations. It'd be folly
> to ignore that reality.
> I just now discovered that what I thought ought be a
> compressed-point representation of a DH shared secret is
> supposed to use the uncompressed format thanks to being
> able to add more trace lines to someone else's code. That's
> the kind of thing could suck up many more hours of effort,
> or that might lead to non-interop, (as it only affects some
> groups), if no open-source code were available.
> S.
>> Yours,
>> Joel
>> On 8/19/2020 2:46 PM, Vijay Gurbani wrote:
>>> 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