Hi John, thank you for workign on moving back this discussion to its essence. I think we all agree that the "work" that we are doing in "working groups" is about consensus building, with maybe a different relative emphasis on the technical quality of the outcomes. This difference may also lead to a slightly different view of *why* consensus building is so important -- I care a lot about how that improves the documents, while you two seem to focus on a form of rejecting improperly build consensus (e.g., built by abuse of power) -- but that is OK, as the latter is a dysfunction that also is likely damaging the quality of the document. But I think these views are mostly compatible so far. Where the compatibility stops: As a participant in these consensus processes, I sometimes see misbahavior by other participants, possibly by chairs and ADs. What I'm mainly arguing against is the idea that such misbehavior automatically must destroy the work that others have invested. (In Germany we tend to identify this effect with a pretty bad word, Sippenhaft; I'm not aware of a useful translation into English.) One effect of Sippenhaft thinking among the leadership is that, people who want to damage some work going on may want to evoke bad consensus building behavior to get this effect. That incentive, of course, is an outcome of the rules that must be avoided at great cost. My early experience with standardization is permeated by the antics that one large organization played to damage standards work. (I'm not going to mention the organization because participants of the current discussion were employed by this organization -- certainly not in that function!) So I will react strongly to any suggestion that bad behavior during consensus building must be retaliated against by destroying the work. The WGLC/IETF LC *heals* such taints. (And I don't think our current rules on "checking" consensus automatically make us a rubber-stamping body, although there is always this danger, including rubberstamping work with a negative total outcome just because it is "deployed".) I'm also maybe a little less concerned about a solution winning that may not be technically superior in all ways, but where a theoretically superior competing solution has not received the work to complete it. In practice, incomplete solutions often have bugs that haven't been uncovered, so the feeling of theoretical superiority might not have lasted. Letting "worse is better" solutions through may elicit evil behavior, and that needs to be quashed, but at the time it happens. I believe that preventing "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" outcomes is an important job of the leadership, but in real time, not as a way to invalidate the "healing" properties of last-calls after the fact. And yes, we have to take these checks seriously. Grüße, Carsten
