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

[Keith Moore <[e-mail]>]

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