Carsten, Let me start with your last comment and then come back to the top. And let me try to make a distinction with which you might not agree and Keith, whom you implicitly cited, might not either. But maybe it will help us, and whomever is reading this, understand each other's perspectives. If there are cases in which destroying work, or even preventing work that falls within a WG charter and the provisions of RFCs 2026, 2418, and friends, I think they apply only were there are clear and intentional cases of trying to work around IETF procedures to accomplish some specific goal. Work done within the IETF that does not attain that level of abusive behavior should not be discarded (or destroyed) except as eliminated through a fair and informed consensus process. That leaves out another case that I'm concerned about but would rather not get distracted by today. That involves work done outside the IETF, perhaps by a small cluster of cooperating companies, deployed by those companies, then brought to the IETF for ratification and defended in a WG on the basis that it is already deployed and cannot be changed. I believe we need to do a better job of addressing those issues and setting conditions at charter time: raising the issues of that particular type of cabal later in the process is never going to come out well. And, as I said in my earlier note, I'm far more concerned about conditions under which well-intentioned but pathological behavior can result from rules that are not clear enough and/or create problems with meaningful consensus. And that brings me back to the top of your note; inline below. --On Monday, July 17, 2023 17:58 +0200 Carsten Bormann <cabo@xxxxxxx> wrote: > On 17. Jul 2023, at 17:45, John C Klensin <john-ietf@xxxxxxx> > wrote: >> >> "This document is a product of the Internet Engineering >> Task Force (IETF). It represents the consensus of the >> IETF community." > > We check WG consensus at WGLC, and IETF consensus at IETF last > call. > In a first approximation, the way we run interim meetings has > nothing to do with it. And that may lie at the core or where we _may_ disagree. I see almost everything we do in the IETF, especially within WGs, as a consensus development process, one in which representation of a broad range of perspectives and discussion of alternate views is critical. The more recent comments about LC being too late are part of this, but only part. When you start talking about "checking" consensus on a given document and treat the process leading up to that document as essentially irrelevant, we become far closer to a "stamp of approval" body or, perhaps more to the point, a legislative or imperial review body that is presented with a final proposal and then gets to either approve it, tweak it a bit, or reject it entirely. The latter might even carry with it negative consequences to the approval body, e.g. the risk of setting off a revolution. That distinction becomes very important if, e.g., the scheduling or announcement process for an interim (including timely posting of the agenda and adequate minutes from prior meetings) succeeds, however unintentionally, in excluding some people or perspectives from the WG discussions who would have wanted to contribute and might have had something useful to say. It becomes equally important if a document author, with the backing of the WG chairs and/or others in the WG behaves in a fashion that suppresses views with which they disagree and the people who hold those views walk away (from either the IETF or just from the WG). If that occurs, it becomes very easy for the WG to move forward efficiently (because all dissenting voices have been eliminated) and for the document to get through the WGLC "check". The effect is much the same if newcomers to the WG appear after work is already in progress and raise new issues. The most efficient way for the WG to proceed is to convince them to go away. Effective IETF consensus-building and quality results for a better Internet (as well as our Code of Conduct and anti-harassment policies) require that they be welcomed into the WG and that their input be respected and considered in a fair way. Now, if the issues those excluded people might have introduced in the WG are caught on IETF LC, possibly because they (having just given up on he WG but not on the IETF) raise them and the IESG and community listen, in theory no harm is done except to the WG's reputation (and maybe that of its leadership) and the desired schedule. In practice in recent years, it doesn't work that way. Most ADs seem very reluctant to hand a document back to the WG and say "Fail! Start over". And I think we've seen WGs (or authors) take positions equivalent to "we put in all the time and energy on this and reached WG consensus, time is pressing, and this is good enough so those objections should not undo things". Of course, if the work involves subject matter with which few IETF participants outside the WG are familiar or, e.g., interactions with standards developed elsewhere, if the WG succeeds (however unintentionally) in driving people with knowledge but different expertise away (or convinces regular IETF participants that interacting with them and their documents is just not worth the energy) then the odds of IETF LC actually turning up the issues is low. If documents are approved via either of those scenarios, we have a situation that is sometimes called consensus by exhaustion. That is not informed consensus of the IETF community and we should not, IMO, be doing business that way (no matter how efficient it might be for the "winners"). > Obvious, I am aware that intermediate decisions of a WG can > shape where effort is actually applied. So the consensus at > the end may be "let's accept that garbage because we never > got around to doing the right thing". This is one reason why > I'm lamenting about preventing (or destroying) work, and we > have to pay attention to where a WG is spending its limited > budget of computrons. I am far more concerned about the possibility of "let's accept that garbage because all of the people who might have argued for a different approach were driven away, either before or after we refused to consider their input". > But this doesn't detract from the way we detect consensus. I think the above reasoning suggests that it does. That is, unless we have moved from the advertised "consensus of the IETF community" (and I keep wishing we'd put "informed" in front of that) to something closer to "able to get past a couple or checks no matter what it takes". In the latter case, nothing makes any difference other than those checks (as an extreme interpretation of what you said would suggest) and we should be revising our claims about what IETF Stream publication and standards track publication mean. best, john
