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

Adrian Farrel <adrian@olddog.co.uk> Wed, 19 August 2020 17:24 UTC

Return-Path: <adrian@olddog.co.uk>
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 B3C053A091F for <wgchairs@ietfa.amsl.com>; Wed, 19 Aug 2020 10:24:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MAY_BE_FORGED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 Xbto_Lk4jOWc for <wgchairs@ietfa.amsl.com>; Wed, 19 Aug 2020 10:24:10 -0700 (PDT)
Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (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 56CBD3A0907 for <wgchairs@ietf.org>; Wed, 19 Aug 2020 10:24:09 -0700 (PDT)
Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id 07JHO4qv013167; Wed, 19 Aug 2020 18:24:04 +0100
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 16D6422032; Wed, 19 Aug 2020 18:24:04 +0100 (BST)
Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs3.iomartmail.com (Postfix) with ESMTPS id 017D822040; Wed, 19 Aug 2020 18:24:04 +0100 (BST)
Received: from LAPTOPK7AS653V (121.128.51.84.dyn.plus.net [84.51.128.121] (may be forged)) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 07JHO3wM012107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 19 Aug 2020 18:24:03 +0100
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Vijay Gurbani'" <vijay.gurbani@gmail.com>
Cc: "'Alissa Cooper'" <alissa@cooperw.in>, "'Martin Duke'" <martin.h.duke@gmail.com>, <wgchairs@ietf.org>
References: <CAMMTW_+Di=ZBJFLNPaVK6f3w3Yq-V-qau8G_rfGt96SX_aYAAA@mail.gmail.com> <056801d6763c$f0296b90$d07c42b0$@olddog.co.uk> <CAMMTW_LDBPe5-m6y2pHkRhQ10phQmtYZ5JjCAJoNuiJ9EdRO6w@mail.gmail.com>
In-Reply-To: <CAMMTW_LDBPe5-m6y2pHkRhQ10phQmtYZ5JjCAJoNuiJ9EdRO6w@mail.gmail.com>
Subject: RE: An IETF repository for working code in our protocols?
Date: Wed, 19 Aug 2020 18:24:02 +0100
Organization: Old Dog Consulting
Message-ID: <058a01d6764d$889b0b30$99d12190$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_058B_01D67655.EA5FE860"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQFwg+L73cxMJIYIU3QWFfYQuftMLgIlrOlLAcbk7rap7CxC8A==
Content-Language: en-gb
X-Originating-IP: 84.51.128.121
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25614.001
X-TM-AS-Result: No--16.697-10.0-31-10
X-imss-scan-details: No--16.697-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25614.001
X-TMASE-Result: 10--16.697200-10.000000
X-TMASE-MatchedRID: 8HTFlOrbAtGzLTBwo8TJunFPUrVDm6jtRwz46rFZl/rtVaZhog8bXCDf zG18cfktyWqzt9wdL7tzJK5J+JFUlifiWWEH8aB82fov7TwhL8kHgh3sKJBzP8uSXx71bvSL4aL pwBcuD94LNO3i/VeeYabAvx2WNdF8Eqlg7JFUMEPKE9oA9cXOzaUB+KILVUD9XplsKAlw4/Ww0+ /uKQ5vdZAnWMGLBQ/G00BCilBQ2Lri7PM1aVrPpG3eycQ7QYZJS/ceBQrgS1EXY+gNTubOQBSM/ zWyxiCY/pLK2p8/HwnYJGrs4kfVeJkO53NqbmtY20204SCJw/oBKB8wuJvbkNbeAkxuakSWdhvu lh3yRlc1+FbwCpLVjHW84JpXU3C5dLu7XN4aj45ZXcakouWziZBhuZO8oasUfkiy7TTogYa4KIu vVeFJ/cWRE/vrHlTaYmLoekZST2wlJJdo4ek5qVN7BS4nAhYVQQshNJfmfwdWE37/I3lJfb/bNg L2ReUKcXPJvm08T64YvAwGWluDAblWwOF3HZyYD2tWc5ns1ra31I2PFWTbady56Kj8sQFgeJB4b YGjDayZmzC6PIjiNOvB3x3EedUPpBX2U3355FkkQUxgaZ8Yx8V0QyhMrtsxSxtq8sG7HPDv/72z C4hJFUtt4xcKCO29ftblt3CCdbwVlVZBrluia980oP25F8xpcQ43DruBJVxKddiF2Wo8edk2l7i 3oc4zRw3fpQHgw3uX6ygEq2dUrd/xBY6jZqnZJhFEQZiq2ZTySn2jEH/dZQwv1ZvdCH+FFXCUeF 7nROYU+O+bQPSZByqFmu/h/tw7WDbQH4TSNIOeAiCmPx4NwGmRqNBHmBve1B0Hk1Q1KyLr8uVzX avvg4QViJlGwPJ1QMwWBTzIo7aAVRJDr5kEzzVUL6JLWGwf4W0Yjv5blkDeaIsBlK1XoA==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/wgchairs/XnKgrFgDXht4o9hgotCsR8OSSQY>
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 17:24:13 -0000

Hi again Vijay (and noting Tommy’s important intervention)

 

[snip]

We felt that archiving this information in the RFC may be misleading and also unfair, and so we suggested removing the implementation status section of the document before publication.

Those are valid concerns, indeed.  However, I note that the entire RFC process is an iterative process itself.  When we release an RFC as a PS, we release it with the knowledge that there may be some design choices that could be revisited at a later stage.  Ergo, if an implementation tracks the RFC closely, the underlying assumption would be that the implementation may well be updated at some later time as the RFC moves through its states from Proposed to Draft to Internet Standard.  To be sure, I am not saying that we should simply archive any half-baked or incomplete implementation, rather rely on the knowledge of the authors of the I-D and the chairs, and perhaps even the IETF interoperability process for the RFC, to only archive those implementations that are worthy of being archived.

 

AF> You capture an important aspect, but I was concerned about the other side of it. It one company has implemented at the time the RFC is published, but others have not yet then the RFC stands forever (or at least until it is replaced or updated) without mentioning all of the other companies that implemented just a week to late to be documented. That is not very fair on the new companies and a little misleading for readers of the RFC.

 

AF> I don’t think we want to be publishing new RFCs just to update this list, so keeping the list out of the RFC seemed better.

 

[snip]

With author hat back off, I’m slightly wary about the IETF becoming a venue for advertisements, so I would encourage people to be quite careful about how this sort of information is collected and maintained.

I suspect that you imply advertisements as indicated by the domain name in an email address of the source code's author.  

 

AF> Ah, no. I meant (possibly as suggested by Joel) commercial advertisements (as in “promotional material”). In many cases, implementation is described as “Company X’s implementation of this specification” and includes product names and release numbers. We do want that information but we don’t want this to be used as a way of saying that Company X makes splendid boxes and Company Y produces rubbish.

 

The law of unintended consequences may yet still strike, I don't claim to foresee all problems.  But insofar as we seek "rough consensus and running code", having "running code" from multiple strains of company (or individual) DNAs seems like a reasonable goal.

 

AF> Absolutely! 

 

AF> In our RFC, we were looking at how information about running code may influence the standardisation process. You are looking at something slightly different, and that is a good thing. Engaging with Tommy on this sounds like a sound idea.

 

Best,

Adrian