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

"Deen, Glenn (NBCUniversal)" <Glenn.Deen@nbcuni.com> Wed, 19 August 2020 18:19 UTC

Return-Path: <Glenn.Deen@nbcuni.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 D4CCD3A082E for <wgchairs@ietfa.amsl.com>; Wed, 19 Aug 2020 11:19:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.796
X-Spam-Level:
X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nbcuni.onmicrosoft.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 oda16UTQJo3L for <wgchairs@ietfa.amsl.com>; Wed, 19 Aug 2020 11:19:26 -0700 (PDT)
Received: from mx0a-00176a04.pphosted.com (mx0a-00176a04.pphosted.com [67.231.149.53]) (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 F3F003A082B for <wgchairs@ietf.org>; Wed, 19 Aug 2020 11:19:25 -0700 (PDT)
Received: from pps.filterd (m0193508.ppops.net [127.0.0.1]) by m0193508.ppops.net-00176a04. (8.16.0.42/8.16.0.42) with SMTP id 07JIGPKQ026200 for <wgchairs@ietf.org>; Wed, 19 Aug 2020 14:19:25 -0400
Received: from usecmgip002.mail.tfayd.com ([50.228.147.34]) by m0193508.ppops.net-00176a04. with ESMTP id 3304nhg3p0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <wgchairs@ietf.org>; Wed, 19 Aug 2020 14:19:25 -0400
IronPort-SDR: Jf1EUgRsASsnD89W1fTFd1ODjepaYo7b/eDihGGsoESoG3VKDguWyhWMenHc5sA8RjeCz7gHuv 4kcrZqAJgBcw==
Received: from unknown (HELO ashemwp00008.mail.tfayd.com) ([100.126.24.32]) by USECMGIP002.mail.tfayd.com with ESMTP/TLS/ECDHE-RSA-AES128-SHA256; 19 Aug 2020 14:19:24 -0400
Received: from ashemwp00004.mail.tfayd.com (100.126.24.28) by ashemwp00004.mail.tfayd.com (100.126.24.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1913.5; Wed, 19 Aug 2020 14:19:22 -0400
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (10.56.130.76) by ashemwp00004.mail.tfayd.com (100.126.24.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1913.5 via Frontend Transport; Wed, 19 Aug 2020 14:19:22 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ILQmmeYCuuwc+ag081Msqzfi9NxcTtldu2XTi553UtLQIaOd/2AYDmLrjWixhqyesaFMv3K6tJwoAVYNaTX0nzTcJuLs5evXnLgtLplcXa/PYwI4bU/MzU6sQVE2lJ+CRvE1iCx9aUsPTbdByCBbf6ycfEgM57Q5l37mWMxKJYs3OJfXKy6r5pikdJPNc70s8fgYDckEUmixdddvBH66l6xDr865uErxS+3PMLokQ9qjgjkYx1sXbm84ramw8Vmg1pYVZ3buHglkAoUwUTS055uwF9QeZta5QQlpqxl2hYyin0FG9zznmy+a9EXZalvTD0oUgySZD2rtzK7DCPccYA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PMpgbvO4/clmSxE7O5EsfC/PtVW+JspBU0m8ckW+dxM=; b=nInDxwggfppM20HWbmEQK0pgKPdTfckjPevS9Ade0l+IuXDeHBqOKqyWPRaaecRrKrn4IXRj6zNumIumCoOfb/RxMW88JYqBbeSqyRADyLPx9D6YQ07eyFDgiX5Bvny4+gDfjvTdb0DtrklaU2+QKZZg0UZpGlp/m7iK4WvYDdKMLTA8Kqxq9crYQ9C1TS/jlpRGf772F1r+TJ/5Rtk/6pOTZLAwvZkmrdVVJXGlOxr3vGIsT6MqwvQF5jPeiWzamWyKApDxfB0ZnUZs2fx4iZun8aLluuOcbkHKFxiG4yzdBTGC6Ct1/Iy0mdXyzPoJjzGmE2y6O3N5pV5oDNxmEQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nbcuni.com; dmarc=pass action=none header.from=nbcuni.com; dkim=pass header.d=nbcuni.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NBCUNI.onmicrosoft.com; s=selector1-NBCUNI-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PMpgbvO4/clmSxE7O5EsfC/PtVW+JspBU0m8ckW+dxM=; b=DE2mgakIj50HHBGnZc3RHY+ClTx1Yj+vCX0sctVmjjGkG/73HUzewHJWcOf7gLUBKjIcUxh8tF+CzLryW1ZvuE8+deLdVGUBvwpYiAsYxWTtT6AzyqjnDA144hmmoCRbeeFxsy3TogjoRbSkAH4zDiNXTq6OYjxuqQvZVop4G2I=
Received: from BYAPR14MB3094.namprd14.prod.outlook.com (2603:10b6:a03:14d::30) by BY5PR14MB3589.namprd14.prod.outlook.com (2603:10b6:a03:1c4::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.20; Wed, 19 Aug 2020 18:19:21 +0000
Received: from BYAPR14MB3094.namprd14.prod.outlook.com ([fe80::c919:4f57:193a:4fec]) by BYAPR14MB3094.namprd14.prod.outlook.com ([fe80::c919:4f57:193a:4fec%6]) with mapi id 15.20.3283.027; Wed, 19 Aug 2020 18:19:21 +0000
From: "Deen, Glenn (NBCUniversal)" <Glenn.Deen@nbcuni.com>
To: Vijay Gurbani <vijay.gurbani@gmail.com>, Alissa Cooper <alissa@cooperw.in>, Martin Duke <martin.h.duke@gmail.com>, "wgchairs@ietf.org" <wgchairs@ietf.org>
Subject: Re: An IETF repository for working code in our protocols?
Thread-Topic: An IETF repository for working code in our protocols?
Thread-Index: AQHWdlVCxI8fqhJaDkmPR/oV4PiG7A==
Date: Wed, 19 Aug 2020 18:19:21 +0000
Message-ID: <81300C20-AC38-465C-A17C-743F3D4CD947@nbcuni.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.40.20081000
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nbcuni.com;
x-originating-ip: [2605:e000:141b:121:9cc:4c36:d85:ca48]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b9a3d4b2-c825-4395-4937-08d8446c652f
x-ms-traffictypediagnostic: BY5PR14MB3589:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BY5PR14MB3589D2711FB80ECE555E9FE0E25D0@BY5PR14MB3589.namprd14.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: aRtJAzD05CIyJY9ynFIHK5RR9K1Pqu2vrNjcIuq7wWCPzINyc0eHTDJ1A4zQcRl37g9n1Y3h4HmPCjDNG08bpx/6K+0j4Nt8eGIs/FAm/Lljf03f3otS/+pisUEKsItY6xJsxhIF4g9G4SekNjUWdVjTjfRqkx2fSGgUWpEyNO4dWY1ToAA7hHmZr7IF1hcskDYsbRdQfzFEJMzstyz/f2oQ0E+kbPrQ3yIbJgK1UMQ2mXSyyr5tuE6/kk2zPDLUh2Uq5PAHFVXYwhuqNrrDpPIRltFX050MqJ4RdcLNEShm9cGS/4vDONFP8fR76pPwnzRNYzcE2tqA7CtiVir4n3SVx4uIeCtpYogz/TN2kGuS4jxnN+U85ZIXsxUeaLNJ4gFoWLFIM3ZonLbIGY0vFg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR14MB3094.namprd14.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(39860400002)(346002)(136003)(366004)(396003)(4326008)(966005)(9326002)(86362001)(8936002)(6506007)(316002)(36756003)(6512007)(76116006)(2906002)(478600001)(186003)(71200400001)(66946007)(66446008)(66556008)(8676002)(66476007)(2616005)(5660300002)(110136005)(107886003)(83380400001)(166002)(6486002)(33656002)(64756008); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: ZynIeVGPg7ptUlXJWNf6YL+vv8XPwFXikHGLbCrCEkhpkcd0vxe8BYA+41RzAuNc3mQw2rk4zCeLf0Y42i7yGGngySb85JpXj3ZpgO6Pg6V9zh9M4yjGppcxHneFy00XqgOjeF6pvw7QihLe0QTPhd7B63MPVu9YtabubL5iTFjkH5xy6Uu8UkTxFYy0tudZgoJgilZjlfePX0a/OsRhO73alpJFA5yM7LqL2dw3xslANZIa8WRhDdXNEJ6w4HYANukUDsLgxwPFc8h/Z7+8aRjmE2neMxE9n5vxcBV8YyWLSR2btP9dA5nDORwP9naV8Is7xcg1r3aQ4E7QuT1ltjr2ZHJJqcYGgEqoonS1wS7VBwJfCzbqkaCnFvsTPUF2k/SuSmfaC3hHUEeTmqD0qtSNbXYZ7CbSUqD0yx75rbdaMuePXHQpva6AtxwfFIL2teE6uSG9bo6n2dxpu212rElF20kxijF28xTZ8Dnms4+vZwfr6P0FHg+0ReMVcPtqNPR/wQC163jI95TYzB5nan3BgBXtzWsDfubjT6VZk8kt96Gd/o8E9MhjXkrpAyF7Gu5y2J5xqU3keoTs9dMqa93Y9ZshdNYaNGonSmz3ZbDgEI8kzL55AqVMQFovs6nLAUnVvW7hiOoIDM+3gs373xVEdeb9gmdRmDhuQyfKNBL510BbW0wbK0lE3n1fjiykVL5Akz34mSy8obRApxxDmw==
Content-Type: multipart/alternative; boundary="_000_81300C20AC38465CA17C743F3D4CD947nbcunicom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR14MB3094.namprd14.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b9a3d4b2-c825-4395-4937-08d8446c652f
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Aug 2020 18:19:21.5710 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4f3526f9-97d6-412d-933a-4e30a73110f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 8z6G7sJlk0tn+UvabxBqiq7Q+eTlsuIgN6T9DusBwegoFQyymRbrhyEIEOlPQvp8x9UvIU6cZQI3QXP3VtjREQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR14MB3589
X-OriginatorOrg: nbcuni.com
X-EXCLAIMER-MD-CONFIG: 47edc00f-f2d6-45ef-be83-8a353bd47e45
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-19_11:2020-08-19, 2020-08-19 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 impostorscore=0 mlxscore=0 adultscore=0 malwarescore=0 clxscore=1015 priorityscore=1501 lowpriorityscore=0 bulkscore=0 phishscore=0 spamscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008190149
Archived-At: <https://mailarchive.ietf.org/arch/msg/wgchairs/2V004khhuOYQCED5oRk9SYYxOeI>
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: Wed, 19 Aug 2020 18:19:28 -0000

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.

The various IP issues that the IETF deals with  are captured in the Trust Legal Provisions (TLP) documented here:  https://trustee.ietf.org/license-info/IETF-TLP-4.htm

There’s a couple of points that jump out at first glance:


  1.  We would want the keep the licenses consistent and not allow a free for all of whatever license the authors liked – as you’ll see in the TLP  section 4.c the IETF uses as. Simplified BSD License for code components in IETF Contributions and IETF Documents.

From experience it can be hard to have simple consistent licensing because a lot of contributions have had some other license applied by the authors, the authors companies, or code that the new code is built on.

  2.  If you look at section 8. You’ll also see that different Document Streams are treated differently today, consideration would have to be given to how such different treatment might apply to code in this IETF repository would interest with the different Document Streams.



  1.  Of course there is the big question of who would be affected if some party tool legal action around the code in the repository.  While the license terms applied that the code always have limitations clauses such as clauses to remove any responsibility for function or reliability or indemnification expectations that doesn’t mean that someone with money to throw at it couldn’t still go ahead and sue the IETF around something in the repository – either that it’s in there, or IP that it infringes, or even how well it works or doesn’t work, or around security holes it might have.   The license would help in the defense, but it would cost the IETF money to defend itself.   We’ve had to do this in the past so it’s something we do know how to deal with, but adding a repository of code would open up a whole new set of things someone could decide to sue us about, or sue someone else like the co-contributor and include us as defendant in the lawsuit.



  1.  There would need to be some management of the repository applied to make sure legal issues didn’t pop up in contributions.   Today the RSE plays a bit of a role for documents as does everyone in the AD-WG process where documents get read and reviewed, but there isn’t any equivalent for code.


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.

regards
  glenn deen, wearing my IETF Trustee hat


On 8/19/20, 8:12 AM, "WGChairs on behalf of Vijay Gurbani" <wgchairs-bounces@ietf.org<mailto:wgchairs-bounces@ietf.org> on behalf of vijay.gurbani@gmail.com<mailto:vijay.gurbani@gmail.com>> wrote:

All: I was reviewing a draft [1] as part of Gen-ART.  In the draft, there is a section pertaining to "Implementation Status" as dictated by RFC 7942.  I found this section to be very interesting in that it captures the running code corresponding to the I-D, but RFC 7942 does not appear to provide the means to retain this section upon publication as a RFC.  (To be sure, it does not mandate that the section be removed, just suggests it.  However, most I-D authors simply will end up asking the RFC editor to remove the section, as [1] does.)

I think that is rather counter productive.  After all, we standardize protocols so that others can write programs that implement the protocols, and I see a lot of value in preserving any running code.  In the particular case of the I-D I reviewed, there were two implementations, both from reputable organizations (APNIC and the Italian National Research Council).  By simply deleting the "Implementation Status" section when the I-D was published as an RFC, it seems that good, quality implementations that folks spent time on would be lost, perhaps not irrevocably, but for most practical purposes, the code would be orphaned.

I am wondering whether the IETF should preserve some of this running code as an archive.  The IETF makes no guarantees of the correctness of the code, just provides a repository where code can be linked to a particular RFC to allow implementers to bootstrap themselves, if needed.  This repository will also contain the contact of the original author of the code.  The repository is sort of like an IANA registry of IETF working code corresponding to an RFC.  The authors of the I-D can be the "expert" and suggest which implementations they consider worthy of archival.  The boilerplate of implementations is given in Section 2 of RFC 7942 [2].  We would have to spec out an IANA-registry like process to do so, but I think that the ends will justify the means.

I note that organizations like IEEE have evolved to provide a repository where authors of published papers can park their datasets for reproducibility (see IEEE DataPort [3]).  The 2017 ACM Task Force on Data, Software, and Reproducibility in Publication also recommended that, "The ACM Digital Library will need to interoperate with a number of recommended data repositories and software curation platforms..." [4]..  So this idea of the IETF maintaining a software repository is not entirely unheard of.

I apologize for taking your time if this has been discussed before; if not, it is worth some discussion.

[1] https://tools.ietf.org/html/draft-ietf-regext-rdap-sorting-and-paging-15<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-regext-rdap-sorting-and-paging-15__;!!PIZeeW5wscynRQ!6LRzdhz1qyCdl5E-IAyg-txM3vLh5MRVyCisn5Uy82SHV3dp2HBGrsBcrCs0QPsH$>
[2] https://tools.ietf.org/html/rfc7942<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc7942__;!!PIZeeW5wscynRQ!6LRzdhz1qyCdl5E-IAyg-txM3vLh5MRVyCisn5Uy82SHV3dp2HBGrsBcrJzEst06$>
[3] https://bigdata.ieee.org/ieee-dataport<https://urldefense.com/v3/__https:/bigdata.ieee.org/ieee-dataport__;!!PIZeeW5wscynRQ!6LRzdhz1qyCdl5E-IAyg-txM3vLh5MRVyCisn5Uy82SHV3dp2HBGrsBcrMKWaHCt$>
[4] https://www.acm.org/publications/task-force-on-data-software-and-reproducibility<https://urldefense.com/v3/__https:/www.acm.org/publications/task-force-on-data-software-and-reproducibility__;!!PIZeeW5wscynRQ!6LRzdhz1qyCdl5E-IAyg-txM3vLh5MRVyCisn5Uy82SHV3dp2HBGrsBcrB5KC76r$>

Thank you,

- vijay