At the plenary last night, Andrew Sullivan set off a series of conversations at the mic lines by asking what seems at first to be a fairly simple question: why is that we seem now to have more process and less reliance on common sense? As those at the plenary will have noticed, the conversation did not stick directly to that question, but went through some interesting history, called for a bit of data, entertained a plea for mentoring, and then questioned whether point solutions or major change would actually work to improve the IETF. Thinking a bit about the directions that conversation took, I think there is both a relatively simple answer to Andrew's question and a much larger piece of context that need to be teased out of the discussion. The relatively simple answer is that we don't just use common sense any more because we don't want to trust individuals as much as we used to. That lack of trust isn't directed at the current IESG, IAOC, or IAB, but at future incumbents. We have come to the idea that allowing a current set of office-holders to make ad hoc decisions implies that all later incumbents will share that ability. Since we don't know those later incumbents (how could we?), we don't trust them; since we don't trust them, we don't want to cede to them a power that might later get abused. So we attempt to use structure and process to restrict those unknown future incumbents. That's interesting in part because we believe in precedent enough to worry that ceding decision making will grant to later officer holders equivalent power, but we don't believe in it enough to believe it will guide what the later officer holders will do. That, again, likely stems from a lack of trust. So why don't we trust the future IETF NomCom that picks those folks or the incumbents when picked? I think that's where the larger context comes in. The IETF is not simply an engineering organization, it is a mission-based organization. Our mission is to make the Internet work and grow. Belief in that mission is something built into the context of the IETF, and it is part of what helps each of us guide our decisions here. Where some SDOs get compromises entirely by horse-trading, many of the compromises that let the IETF work by rough consensus actually come about because of that shared mission. We recognize that compromise to get interoperability is a key part of what lets the Internet continue to work and grow. We both give our technical insight to that mission and we subordinate our technical desires to it. That works in part because we know that others here share that mission. We don't recite it at meetings or make it the subject of ceremonies, but we recognize that spending enough time here will cause both that mission and the whole-Internet engineering perspective to seep into the bones of the participants. We get a direct sense of it from those with whom we interact (Pete and Murray's exchange last night was a great precis of that process), we get an indirect sense of it from broader social networks, and we have institutionalized it in things like the NomCom eligibility rules. I suspect that some of the trust issues we have with imagined future incumbents actually comes from a subconscious fear that we won't be as successful at passing on a belief in that mission as we have so far been. That may be because the current mechanisms are largely ad hoc (as Joe's comments on mentoring hinted); it may be more free form than that. To counter that concern, we may want to extend the methods we already do have (Edu teams, newcomers socials, and so on) for longer parts of the initial participation periods. We may even want to consider new ways of generating affiliation to our core goals. However we do it, it seems likely that energy put into making sure that the IETF's mission is part of each participant's understanding of their work will return benefits both to the IETF now and when those unknown future incumbents take office. The other thing that context suggests is probably equally important. As a mission-based organization, we have a natural touchstone for evaluating change. If a proposed change furthers the mission of the organization, we can likely manage the transition it implies, whatever the scale might be. If it hinders the mission of the organization, it shouldn't be taken on however cheaply and easily it might be done. Maintaining the power of the incumbents? Not important. Maintaining the current structures? Not important. Change for change's sake? Not valuable. Making sure the mission gets done? Pretty much the only thing that matters. Since this is all long since baked into the bones of most IETF participants, this no doubt seems a bit trite or even silly. But there are times when it is important to say things out loud, and this may be one of them. If we are considering why change in the IETF increasingly looks like ossification and if we are considering how to fix that, we should keep our mission in mind. My two cents as an individual, Ted Hardie