Hi, Phil. I'm glad you brought up this question, because it gives me a good opportunity to clear up some points of IETF process.
> I want to thank you for the re-introduction of the issues tracker. This will > greatly assist in tracking issues and building consensus. We hope it will. But, as you say, it's just a tool, and it's really the participants who develop consensus, and the chairs who manage the process. Sometimes, again, as you say, we can come to agreement after some discussion... but sometimes we get to a point where there's still disagreement, and we have to see where the rough consensus is. Not everyone will always be happy, but we hope we can get a result that most of us think will work and is technically sound. > In the past, we have had email votes, but the feedback was these email votes > are guidance only. This leaves me confused as to how consensus is being > achieved. Can the chairs clarify on what you believe the process is for the > OAuth WG? > There is also an issue that at times consensus is asked for far too early > when the proposals to be voted on are often unacceptable to a significant > community Let me start by saying that people sometimes use the word "vote" as a sort of shorthand term, but we need to be clear here: we do not "vote" in the usual sense. It's not just a semantic point, but something that's central to how the IETF works. We work on "rough consensus", and judging that is one of the jobs the chairs have. It doesn't go on a "one participant, one vote" line -- and remember, too, that participants here participate as individuals, so let's not make the mistake of thinking about one or another company's view (or, heavens, "vote"). Here's an example of what I mean by that: suppose we get to a point where, say, 15 people have expressed opinions, and 8 of them fall on one side of an issue, with 7 on the other. If we were "voting", we might say that the 8 votes win. But in most cases we'd say "We don't have rough consensus on this point." In fact, depending upon the issue and the arguments, 9 to 6, or even 10 to 5 might not be enough for "rough consensus". On the other hand, it doesn't have to be 15 to 0. Where rough consensus falls is a judgment the chairs have to make, on an issue-by-issue basis. We might make that differently for a cosmetic issue (the name of a protocol element, say) than for a technical point that has a significant effect on the interoperability, extensibility, or security of the protocol. It's also up to the chairs to decide how long to let the discussion go on, and when to make a consensus decision. Participants are, of course, free to offer their opinions on the matter, and I'm sure you won't be shy about that. But please, everyone: when someone does make such a suggestion, take that as a message to the chairs, and don't act on it unless it's the chairs who say it. We will be the ones issuing "last calls" for comments on issues, requesting straw polls when we think we need to, and so on. And, indeed, we might decide we need a straw poll to tease out the support for particular points. Remember that if we do that, it's not a formal vote, and a slim majority won't necessarily "win". See above. We also need your cooperation on reaching consensus. If you see an opportunity to accede to someone else's view in order to help reach consensus on an issue, please do so. There may be the occasional issue you really feel it's important to dig your heels in on, but most issues aren't like that, and some give and take will help get things finished while keeping the result technically sound -- even if it's not exactly as you'd like it to be. Finally, the chairs don't always get it right, and if you think we're cutting off discussion too soon -- or letting it run too long, beyond the point where it's useful and productive -- please let us know. Most of the time, it'll be best to tell us that *off* the mailing list, to avoid adding to the already busy list traffic with meta-discussion. We'd rather keep the discussion on the list to that which addresses the issues directly. We'll make sure things are recorded on the list for openness and archival purposes. The most convenient way to contact all the chairs together is with the tool alias: <[email protected]> Mostly, you needn't copy us on anything that's posted to the mailing list, because we're all subscribed to it. Barry, as chair _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
