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

Reply via email to