adapting IETF in light of github and similar tools (was: What's the alternative to "snarling"?)

Keith Moore <moore@network-heretics.com> Mon, 19 April 2021 22:22 UTC

Return-Path: <moore@network-heretics.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4478E3A46D0 for <ietf@ietfa.amsl.com>; Mon, 19 Apr 2021 15:22:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.017
X-Spam-Level:
X-Spam-Status: No, score=-0.017 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 1n9w4PERPfz7 for <ietf@ietfa.amsl.com>; Mon, 19 Apr 2021 15:22:36 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 838663A46CF for <ietf@ietf.org>; Mon, 19 Apr 2021 15:22:36 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 605B25C00B2; Mon, 19 Apr 2021 18:22:31 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Mon, 19 Apr 2021 18:22:31 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=FRIWXrEgmQfZAjWUVCzQ0f4VHuVcWNXDshVxz8ypt p4=; b=KLiggq6EbvcZ8tLp6mdXsqQ2nIy9Euk3IDo5dAHsHqfHjWp93johwWV1E yXOMhwyyNTcA2cKyCfvrcgJCm3DK5atMuOnhnAizHOfUJPpsLhRrK9L93w1s8jgK U0NhEmLb9MeyCF0mW2ZlXyO8tuCOT9g7H73kesPEz1riBgy8No6T0aDESLH3jkfG MGDSdK7nYeULypFiZjrRUS3s78tNAgWpZSIIOyYkld+tFmlvWsqKX+bXZA3lG3Oq 68Fmk9HSsTH4Z4fEeBqRJoljwv5gdpff2fCgFm0i0hq7CmBY2cb4tCREAHMSf6wn xRRilJJ2Wa22K7V3u3sjoiJyJAu7Q==
X-ME-Sender: <xms:pgJ-YCRuyrp8tebBZJxKXBwWXGstWkW0GrUCkY5EUis6ZjWsWcz9lg> <xme:pgJ-YJRn9q30n9on1nUOUhx3cgbSsMCbyIHwh1ESOHwBDDD1fjj0u-t9oMtQthKjU 1yrLGMxwmpupw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvddthedgtdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhkffffgggjggtgfesthekredttdefjeenucfhrhhomhepmfgvihht hhcuofhoohhrvgcuoehmohhorhgvsehnvghtfihorhhkqdhhvghrvghtihgtshdrtghomh eqnecuggftrfgrthhtvghrnhephefhuedtheefgfefgffhkeehgfeugfeiudeugeejkeef leelueeiffetfeeuudeunecukfhppeejfedruddufedrudeiledriedunecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhoohhrvgesnhgvthif ohhrkhdqhhgvrhgvthhitghsrdgtohhm
X-ME-Proxy: <xmx:pgJ-YP7OfnyZsCwg_g0ynOfJyaLAyaIakMp5ndfyrvCTuCJ0qRqDGQ> <xmx:pgJ-YN2vGgq9WWvEwzqusRsK7M4ZBeradIeaw5bezWKVgs6B2srxgg> <xmx:pgJ-YCC3UmNBdnHq7cljVWT3oMNf6-QqLIHjU1NYbCeGhAI--dhVFg> <xmx:pwJ-YG4XcHzCRa007qZoOf0xYgESGgcQeus6VEQYaqaeW5i0_M7XrQ>
Received: from [192.168.30.202] (c-73-113-169-61.hsd1.tn.comcast.net [73.113.169.61]) by mail.messagingengine.com (Postfix) with ESMTPA id 8E60924005D; Mon, 19 Apr 2021 18:22:30 -0400 (EDT)
Subject: adapting IETF in light of github and similar tools (was: What's the alternative to "snarling"?)
To: Richard Shockey <richard@shockey.us>, Leif Johansson <leifj@mnt.se>
Cc: ietf@ietf.org
References: <0b63d094-8c95-409f-282e-86231128f7b5@network-heretics.com> <1C5B7B67-27E5-41F5-89D4-765A407C1FC6@mnt.se> <EE6AD028-C5E9-4FA9-9756-0ACB32E298F9@shockey.us>
From: Keith Moore <moore@network-heretics.com>
Message-ID: <10029019-302a-dbf0-6a8e-eb0d26cd027a@network-heretics.com>
Date: Mon, 19 Apr 2021 18:22:29 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <EE6AD028-C5E9-4FA9-9756-0ACB32E298F9@shockey.us>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/Lt-W8j1Qf0BWP1UtUALc5fCwmTs>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Apr 2021 22:22:41 -0000

On 4/19/21 5:34 PM, Richard Shockey wrote:

> RS> GitHub.  The paradigm has shifted. It's no longer "rough consensus and running code." Its just running code.  Look at WEBRTC as a example.

Though at least at one time, the emphasis wasn't merely on "running 
code" so much as on "specifications that permit multiple running code 
implementations to interoperate".

These days there's less variation between platforms, so often it's at 
least possible for different implementations of some applications to 
share the same code base.   And with automatic software update, 
applications can be upgraded to support new protocol features without 
needing to get agreement on a protocol specification.  Rather than get 
rough consensus on the change, whoever controls the repository 
effectively wins.   (Though forking does happen sometimes.)

Webrtc is certainly an example of something, but people might have 
different opinions about whether it's a Good Thing.   At least the last 
time I looked, it was extremely complex and difficult to implement from 
a specification.  So it tends to be tied to these bloated 
privacy-violating codes called web browsers that have a huge attack 
surface and require very significant resources.

But I do think it's an example of how the paradigm has shifted, at least 
for some kinds of applications.    How can IETF respond constructively 
to that shift?    Somehow doing everything the github way doesn't seem 
like adding value.  But there's even more demand than ever to be nimble, 
to make huge changes quickly and without much time for review.   And yet 
in some areas, particularly security, and probably also other 
operational considerations, the need for careful design and 
implementation are greater than ever.   Could we restructure our 
processes to change the emphasis in our reviews to make sure we're 
adding value in these neglected areas?   Would it make sense to make 
running code part of our official work product, produced concurrently 
with the specification and reviewed for consistency with the 
specification?   Could we make greater use of protocol specification 
languages to reduce the difference between specification and running code?

Some of these things are already happening, of course, but could/should 
we make them a more explicit part of our process?

Keith