[dispatch] How the IETF works (was: Re: Demonstration of Implementer Support for Multibase and Multihash at IETF (was: Re: Finding a home for Multibase and Multihash))

[John C Klensin <[e-mail]>]

I guess I am going to be the one to follow the lead of earlier
comments and try to move this to the IETF list.   For those on
that list and not of [e-mail], a discussion about the
development of some particular work that was presented in the
DISPATCH WG last week and evolved into a discussion of how the
IETF does work and generational differences in the communication
mechanisms various people find useful (or even acceptable).  If
what follows does not provide enough context, the relevant
archives are at 
https://mailarchive.ietf.org/arch/browse/dispatch/

Inline below.

--On Monday, April 3, 2023 10:02 -0400 Manu Sporny
<[e-mail]> wrote:

> I'm just not sure that working through the mailing lists are
> in the same league of expected infrastructure by the younger
> generations. :) Again, as a data point, for the Multiformats
> work, mailing list engagement has been a challenge, where
> Github, Google Doc, Slack, and Signal engagement has been much
> easier.
> 
> Again, just a data point, no need to debate it on dispatch.

Let me give you a different datapoint (speaking as one of those
first-generation IETF --and ARPANET/Internet protocols even
earlier-- types but not for anyone else)...

Describing this situation as a generational one misses an
important point.  One of the historical strengths of the IETF is
that it brings together people from a wide variety of
perspectives.  That is one thing that makes it different from a
collection of people working together to develop and/or promote
a protocol (or other work) on a specific topic.  That model has
contributed significantly to our being able to produce
higher-quality output because it raises the odds of someone
being able to notice a problem external to the discussions of
the narrower group and say "hey, that will work fine as long as
everyone is part of the same club but it is not very robust
against X" or "that would be ok except that it conflicts with Y
or would mess up Z".  

Those are among the reasons we have often encouraged people to
drop in on meetings of WGs with which they are not actively
involved (an advantage of f2f rather than entirely or mostly
remote meetings), why WG Internet-Drafts are announced broadly
rather than just to the WG, and why we do IETF Last Calls on
documents.

While others may disagree, I (and historically others) have
suggested that having a small number of editors or authors for a
given document, ones who receive input from others and take
directions from WGs, usually produces better and more coherent
and comprehensible output than editing by committee.

Tools like Github --and Github specifically-- pose a problem for
that model.   In my experience, it is great for an effort in
which everyone involved is actively collaborating, watching
developments more or less in real time (or at least daily) and
expecting to read almost every transaction.  By contrast, for
someone trying to look in on work occasionally to get a sense of
status, what the issues are, etc., it can be extremely hard to
follow -- to the point of discouraging such efforts.   Perhaps
that, too, is a generational issue, but I have not found it a
problem for efforts I follow closely.

Unless it is a generational issue --in which case folks in the
IETF who are concerned with education and outreach had best
increase their skills and efforts to teach old dogs new tricks
-- it may be getting close to time for us to consider whether
those goals of getting broad perspectives into work and getting
it early are still relevant.

best,
   john