On 14/01/2025 18:48, Filippo Valsorda wrote:
Two participants sending a dozen emails in support of solution A, and
six participants sending one email each in support of solution B can
look a lot like there is no consensus, or that there is consensus for
solution A, especially if not all objections to solution B are
painstakingly addressed.
This is slightly adjacent to the point you were making, but I think
there's an implicit assumption here which is different from 'rough
consensus' as I understand it. RFC 2418 [1] lays out:
In general, the dominant view of the working group shall prevail.
(However, it must be noted that "dominance" is not to be determined on the
basis of volume or persistence,
but rather a more general sense of agreement.)
[...]
Note that 51% of the working group does not qualify as "rough consensus" and
99% is better than rough.
RFC 7282 [2], perhaps more an ideal rather than any actual description
of IETF practice, explores the last part further in the sections: "One
hundred people for and five people against might not be rough consensus"
and "Five people for and one hundred people against might still be rough
consensus".
I know at least a few implementers that don't engage with the IETF
because they don't have time for all that.
Coming back to your main point, I agree this is a real problem.
I don't know how it can be effectively addressed for when folks want to
change the core Internet protocols which are stewarded by the IETF.
However, I think many of the folks who are put off contributing are
instead trying to bring their new ideas and designs to a wider
community, rather than tinker with existing systems. The IETF could do a
much better job of helping them share their work with the community by
supporting and sign-posting lower process methods for publishing specs
(e.g. informational) which produce similarly useful outputs (IMO) but
don't incur the same overhead and drama on the mailing lists.
Best,
Dennis
[1] https://datatracker.ietf.org/doc/rfc2418/
[2] https://datatracker.ietf.org/doc/rfc7282/
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org