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

"Joel M. Halpern" <jmh@joelhalpern.com> Thu, 20 August 2020 00:50 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01CE53A0FD3 for <wgchairs@ietfa.amsl.com>; Wed, 19 Aug 2020 17:50:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.049
X-Spam-Level:
X-Spam-Status: No, score=-3.049 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gX-L3aTtaRy for <wgchairs@ietfa.amsl.com>; Wed, 19 Aug 2020 17:50:54 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC5103A0FD0 for <wgchairs@ietf.org>; Wed, 19 Aug 2020 17:50:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4BX5g24b4kz6GFF9; Wed, 19 Aug 2020 17:50:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1597884654; bh=JBbOmV6vVtEl+VKQ46BIcuDdQ0yDFgvr3HAS11P7wnw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=OCLHaSqL64n+z5g2jjCu+dm94yqtmlIMxblgnK4/gWBTRkIRoQ4vgJXYYTCXelFrG WutppFO1QRiMGjE+2uF5HrwImSmjzo09lWmsMMuyb1h27vp/kPJ/rjr6qMDZXo9VmT fHc5kepv6MTNZxQHiOuG3fxJx7Mh3qQmV1Qc80T8=
X-Quarantine-ID: <fZhGh9PzgT6S>
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4BX5g14WWSz6GF0l; Wed, 19 Aug 2020 17:50:53 -0700 (PDT)
Subject: Re: [irsg] An IETF repository for working code in our protocols?
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "Acee Lindem (acee)" <acee@cisco.com>
Cc: "wgchairs@ietf.org" <wgchairs@ietf.org>
References: <81300C20-AC38-465C-A17C-743F3D4CD947@nbcuni.com> <CAMMTW_+P60jB-MLsB6R_x7z3uk5xK56ZwkZnHOtzaxex3tDREA@mail.gmail.com> <90cb740e-8663-58df-5c99-cbc053142566@joelhalpern.com> <a484f593-d037-ca9e-c4e9-6e28731b3152@cs.tcd.ie> <e6ae9107-48a9-cf04-2772-90b4b357fe3b@joelhalpern.com> <e99af73a-0ffa-f4e3-dcc8-6666066ceaa6@cs.tcd.ie> <536362ab-3a8a-d584-eb17-b5e8c927bfc6@joelhalpern.com> <94c80120-c44d-3df9-c088-584cbba36dbf@cs.tcd.ie> <9B6E2247-621D-4C96-8A01-9030E39267FC@cisco.com> <18cf1d25-1fa8-5555-5134-7f6c4533f3b1@cs.tcd.ie>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <f3dea80d-f461-dd68-5668-6c64a297713b@joelhalpern.com>
Date: Wed, 19 Aug 2020 20:50:52 -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: <18cf1d25-1fa8-5555-5134-7f6c4533f3b1@cs.tcd.ie>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/wgchairs/uzFSOQMDmNjcEDefDu-FSuJdZns>
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Working Group Chairs <wgchairs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/wgchairs>, <mailto:wgchairs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/wgchairs/>
List-Post: <mailto:wgchairs@ietf.org>
List-Help: <mailto:wgchairs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/wgchairs>, <mailto:wgchairs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Aug 2020 00:50:56 -0000

I am missing something Stephen.  We can establish exactly the 
relationship you describe without the IETF archiving the source code.

So what is the advantage you see in the IETF making a snapshot of a 
project and storing it separately from that project?  For example, I 
work with fd.io.  That implements a lot of IETF RFCs.  Very effectively. 
  In open source.  I can not see any benefit in the IETF making one (or 
worse yet several) copies of fd.io.  I can see benefi, for cases where 
the fd.io developers want it, for the IETF to have pointers to the fd.io 
work with indications of what RFCs it implements (a lot).  If someone 
wants to do the work, that could include pointers to specific versions 
(which will fall out of maintenance), pointers to the most current 
versions, pointers to the whole project so people can get context, and 
pointers to specific sub-projects concerned with specific RFCs.  How 
elaborate it gets probably depends upon both what we want and how much 
work the fd.io developers care to put in.

But if we want to point to OSPF implementations, it would seem very 
strange not to point to the widely used implementations from Cisco and 
Juniper (multiple from each, and ones from a number of other vendors). 
Yes, we should point to the several open source ones (if the 
implementors want us to.)

We do regularly get asked / ask ourselves "who has implemented this". 
Improving and maintaining our ability to answer that question seems very 
useful.  Pretending that the only implementations that matter are the 
open source ones seems counter-productive.

Yours,
Joel

On 8/19/2020 8:22 PM, Stephen Farrell wrote:
> 
> 
> On 20/08/2020 01:01, Acee Lindem (acee) wrote:
>> What is the advantage of the IETF maintaining the repository as
>> opposed to pointing to a GitHub repository/repositories maintained
>> the open source implementor(s)? I see none.
> I do. Linking the RFC to the version of the code that
> claims to implement that is useful. Not depending on
> the kindness of, or lack of bitrot at, git<blah>.<tld>
> is good.
> 
> Doesn't need to be hard, could just be a snapshot
> of a git repo that's tied to the RFC (or I-D) via
> the tracker. (I don't much care exactly how.)
> 
> But claiming that's useless is not something I can
> grok TBH.
> 
> S.
> 
>