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
