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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 20 August 2020 01:08 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 E17643A0FF2 for <wgchairs@ietfa.amsl.com>; Wed, 19 Aug 2020 18:08:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.948
X-Spam-Level:
X-Spam-Status: No, score=-2.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, 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=cs.tcd.ie
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 9TrYfUHKUnEw for <wgchairs@ietfa.amsl.com>; Wed, 19 Aug 2020 18:08:16 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 674513A0E4F for <wgchairs@ietf.org>; Wed, 19 Aug 2020 18:08:16 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 55EB8BE5B; Thu, 20 Aug 2020 02:08:14 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lpo50lcBiht7; Thu, 20 Aug 2020 02:08:11 +0100 (IST)
Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 22C75BE58; Thu, 20 Aug 2020 02:08:11 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1597885691; bh=UwIboifW360e+N0JM4C6Z+RdgyIWYVvwj0C2p7GpY/w=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=dbtiem4ALu64g1y8ShjO0sqAfdmcWvc5rPIwLuaChsIg5ne4QZNIYsck7jeWxACRa P7xoNKXW9O7e7/lvoQAuIO4nnogXT/5BbfAn6vaZW50H6WhBi64KWktqhbPKxfYnsb CnYWOPS7mIT++eA1C+989VvCgzvXMEJlCXDbfQ48=
Subject: Re: [irsg] An IETF repository for working code in our protocols?
To: "Joel M. Halpern" <jmh@joelhalpern.com>, "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> <f3dea80d-f461-dd68-5668-6c64a297713b@joelhalpern.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw==
Message-ID: <aacd6dee-9197-7eb0-71ea-5578da173120@cs.tcd.ie>
Date: Thu, 20 Aug 2020 02:08:09 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <f3dea80d-f461-dd68-5668-6c64a297713b@joelhalpern.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PBiGmGYEo7vBTfaqnpYUhNqt1xjPS2SIT"
Archived-At: <https://mailarchive.ietf.org/arch/msg/wgchairs/lmCTOsUN7vZqdiukpJOe5YXHkjI>
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 01:08:26 -0000

Hiya,

On 20/08/2020 01:50, Joel M. Halpern wrote:
> I am missing something Stephen.  We can establish exactly the
> relationship you describe without the IETF archiving the source code.

I don't believe I made any suggestion as to who would
claim/establish that some code maps to an RFC/I-D. I'd
imagine authors/chairs are far more likely to do that
than "the IETF."

> 
> So what is the advantage you see in the IETF making a snapshot of a
> project and storing it separately from that project? 

I believe I already said that. See my example wrt EC points. I could wax
lyrical but not sure that'd help
more;-)

> 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.

That all sounds good. I also already said why I do think
there's value in an IETF-archived copy. As another point,
fd.io (hadn't heard of 'em btw), was registered in 2013.
I've seen various excellent industry efforts come and go
over the years and would be more confident that ietf.org
might have the same function in 10 years than such well
meaning but likely more short-lived domains.

> 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.)

I'd have no objection to that, assuming all the same
caveats as ought apply to a pointer to any implementation.
All I claimed was that having the overall set of pointers
include some reasonable OSS adds value that is inherently
missing for closed-source.

> 
> 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.

I don't believe I advocated for "pretending" of any kind.

Cheers,
S.

> 
> 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.
>>
>>