RE: Last Call: draft-resnick-on-consensus-05.txt (On Consensus and Humming in the IETF) to Informational RFC
Hi Pete, At this point, a working week through the four week last call, I am wondering whether the volume of comments and changes merit waiting for a revised version before I do a last call review, or whether I should dive in with the current version and risk raising a number of points already covered by others. What do you think? Thanks, Adrian
Re: Last Call: draft-resnick-on-consensus-05.txt (On Consensus and Humming in the IETF) to Informational RFC
On 10/11/13 2:04 PM, Adrian Farrel wrote: At this point, a working week through the four week last call, I am wondering whether the volume of comments and changes merit waiting for a revised version before I do a last call review, or whether I should dive in with the current version and risk raising a number of points already covered by others. What do you think? Half of one, six dozen of the other. :-) There's no doubt in my mind that there will be a revision coming to address a bunch of comments, and you'll notice that I haven't even started to tackle the comments in the thread that Ted started. (That's in my edit buffer and is next on my list.) I certainly wouldn't mind hearing comments that haven't been brought up yet, or hearing disagreements with comments already made, but I certainly wouldn't be distressed if you waited for the next go-round either. My sense is that the revision is going to have a lot of little changes (sorting the actual history from the what's new is going to require a bunch of smallish edits), and I need to adjust some of the framing of some of the bigger points, but I don't see drastic thematic changes coming. (Obviously I've got some 'xplaining to do on some of the themes, and it's always possible that Ted convinces me that I'm completely wrongheaded on one or more of them, but that's my current assessment.) I've got a bunch of airplane time in the next 4 days, so I might even get this out by sometime next week. And remember, the Last Call ends during Vancouver, so there's certainly going to be longer than average time at the end to deal with comments. Does that help you decide? pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478
Re: Last Call: draft-resnick-on-consensus-05.txt (On Consensus and Humming in the IETF) to Informational RFC
FWIW, on the issue of Informational RFCs seen as cast in stone: I think I've seen that problem occasionally. I.e. people assigning a far too high value to a document, just because it is an RFC. The world changes, our understanding changes, and as Dave pointed out processes evolve… RFCs need to change now and then as well. I agree that the issue is much more serious for BCPs. But I think we really need to get over the issue. The best defense for that problem is to be seen publishing and revising RFCs. If we start to be afraid of publishing an RFC… I think we've already lost too much. I do not want to go there. Just a personal opinion, of course. Jari
Re: Last Call: draft-resnick-on-consensus-05.txt (On Consensus and Humming in the IETF) to Informational RFC
Pete, As usual, I really like your writing style, and I think you're addressing a very important issue. There are two aspects that I would suggest require further exploration, both having to do with the role of the chair (the whole document has to do with the role of the chair, I suppose): 1. No matter how you slice the definition of rough consensus, if the chair does not act in a fair and balanced way, the outcome will be incorrect. This is what the appeals process is for, and I would suggest mentioning it, perhaps in some detail. 2. The case of Section 7 is, as you say, a mind bender. I would suggest adding another use case: what if those 100 people write their own draft. Can they use the exact same process to get the draft adopted and approved, so long as they answer the technical issues that arise? In other words, if there are multiple valid alternatives, and one suits one vendor group and another suits another, can there be just one standard? At the neck of the hourglass, perhaps so? What happens in this case, from your point of view? What makes group (a) more special than group (b)? Eliot On 10/7/13 12:48 PM, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'On Consensus and Humming in the IETF' draft-resnick-on-consensus-05.txt as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-11-04. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The IETF has had a long tradition of doing its technical work through a consensus process, taking into account the different views among IETF participants and coming to (at least rough) consensus on technical matters. In particular, the IETF is supposed not to be run by a majority rule philosophy. This is why we engage in rituals like humming instead of voting. However, more and more of our actions are now indistinguishable from voting, and quite often we are letting the majority win the day, without consideration of minority concerns. This document is a collection of thoughts on what rough consensus is, how we have gotten away from it, and the things we can do in order to really achieve rough consensus. Note (to be removed before publication): This document is quite consciously being put forward as Informational. It does not propose to change any IETF processes and is therefore not a BCP. It is simply a collection of principles, hopefully around which the IETF can come to (at least rough) consensus. The file can be obtained via http://datatracker.ietf.org/doc/draft-resnick-on-consensus/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-resnick-on-consensus/ballot/ No IPR declarations have been submitted directly on this I-D.
Re: Last Call: draft-resnick-on-consensus-05.txt (On Consensus and Humming in the IETF) to Informational RFC
On Oct 9, 2013, at 1:30 AM, Melinda Shore melinda.sh...@gmail.com wrote: Rough consensus - An agreement by almost everyone that the proposed That's a lot like voting, I think. It's worse than voting, because it encourages people to invite their friends to sway the consensus. At least with voting you have the transparency of knowing who the electorate is. So if this were what rough consensus meant, rough consensus would most often be won by whoever has the most friends, which in practice is probably whoever works for the biggest company. So whatever rough consensus means, it can't mean only a few people disagree.
Re: Last Call: draft-resnick-on-consensus-05.txt (On Consensus and Humming in the IETF) to Informational RFC
On 2013-10-09 20:35, Ted Lemon wrote: On Oct 9, 2013, at 1:30 AM, Melinda Shore melinda.sh...@gmail.com wrote: Rough consensus - An agreement by almost everyone that the proposed That's a lot like voting, I think. It's worse than voting, because it encourages people to invite their friends to sway the consensus. At least with voting you have the transparency of knowing who the electorate is. So if this were what rough consensus meant, rough consensus would most often be won by whoever has the most friends, which in practice is probably whoever works for the biggest company. So whatever rough consensus means, it can't mean only a few people disagree. OK - I don't know what is wrong, but either - I can't write; or - some leading members of our community can't or don't care to read Ted, what you are describing is is not a group, it is a group or a loosely collection of people subject to manipulation. There is no room for that type of manipulation if we shall be able to talk about consensus/rough consensus (at least we seem to agree on that). If we have wg-chairs, ADs or chairs that are not able to detect this kind of manipulation we are in bad shape. What I tried to talk about is the the state of mind the (un-manipulated) group needs to be in before someone can make a consensus call; again not a definition, just a way of thinking about it. With that I rest my case. /Loa -- Loa Anderssonemail: l...@mail01.huawei.com Senior MPLS Expert l...@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64
Re: Last Call: draft-resnick-on-consensus-05.txt (On Consensus and Humming in the IETF) to Informational RFC
On 10/9/13 4:35 AM, Ted Lemon wrote: On Oct 9, 2013, at 1:30 AM, Melinda Shore melinda.sh...@gmail.com wrote: Rough consensus - An agreement by almost everyone that the proposed That's a lot like voting, I think. It's worse than voting, because it encourages people to invite their friends to sway the consensus. Excellent point. Melinda
Re: Last Call: draft-resnick-on-consensus-05.txt (On Consensus and Humming in the IETF) to Informational RFC
On Mon, Oct 7, 2013 at 12:34 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 08/10/2013 08:03, Ted Hardie wrote: ... were. On the second point, the truth is that informational RFCs are [not] treated as actual requests for comments much any more, but are taken as fixed; I've inserted the not that Ted certainly intended. Indeed, thanks for the correction. But I think he raises an important point. If the phrase Request For Comments no longer means what it says, we need another RFC, with a provisional title of Request For Comments Means What It Says. We still see comments on RFC 791 reasonably often, and I see comments on RFC 2460 practically every day. That's as it should be. And what are the RFC numbers for the comments? If none, as I suspect, then the comments aren't the same status as the documents--that's fine for RFC 791 and 2460, but it is not clear that Pete's document falls into the same class. I would argue it does not. So I'd like to dispute Ted's point that by publishing a version of resnick-on-consensus as an RFC, we will engrave its contents in stone. If that's the case, we have an even deeper problem than misunderstandings of rough consensus. Archival may not mean engraved in stone, but it does impute status. If we want, as a community, to create an archival document on this topic, then we should take on the work. Pete's document is a good spark for the conversation that might kick off that work, but I personally don't think it is a good output document for that; if it is meant to be a spark, I don't see why moving it into an archival series is useful for us at this stage. regards, Ted otoh Ted's specific points on the draft are all valuable. Brian
Re: Last Call: draft-resnick-on-consensus-05.txt (On Consensus and Humming in the IETF) to Informational RFC
On Mon, Oct 7, 2013 at 1:35 PM, Ted Lemon ted.le...@nominum.com wrote: On Oct 7, 2013, at 3:34 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: So I'd like to dispute Ted's point that by publishing a version of resnick-on-consensus as an RFC, we will engrave its contents in stone. If that's the case, we have an even deeper problem than misunderstandings of rough consensus. Right, I think what Ted is describing is a BCP, not an Informational RFC. To be clear here, I did not think Pete's document was going for BCP. I remain concerned that the publication of this document as an an AD-sponsored Informational RFC will impute status to it as a community conclusion, rather than the start of a conversation (or, rather, the continuation of one). Some of the comments of I've wanted something like this to hand to... are part of what cause me to believe that. And, to re-iterate, I do not think the document is ready, even if the IESG believes that a document of this type should be published; it needs a much clearer sense of audience as well as attention to the other points that have been raised. regards, Ted
Re: Last Call: draft-resnick-on-consensus-05.txt (On Consensus and Humming in the IETF) to Informational RFC
On 10/8/2013 8:36 AM, Ted Hardie wrote: And what are the RFC numbers for the comments? If none, as I suspect, then the comments aren't the same status as the documents--that's fine for RFC 791 and 2460, but it is not clear that Pete's document falls into the same class. I would argue it does not. Unfortunately the concern you are raising has often been applied to all sorts of IETF work. Many bits of IETF work are subject to on-going comments and often reach the practical status of de facto -- or, in the case of the errata mechanism, IETF de jure -- modifications to the published document. In fact, the line of argument you raise has frequently been lodged against the BCP construct. Yet we keep finding BCPs useful to create. 1. Does the IETF need a modern, thorough, community-approved statement of it's consensus model and the application of the model? That is, both theory and practice. So far, it looks as if the community certainly thinks we do, and strongly agree. In fact I think we suffer greatly by not having it. And as we've gone through multiple generations of participants, we've tended towards reliance on catch-phrases, without a shared understanding of their deeper meaning and specific practice. So folks invent their own meanings as best they can. Something like Pete's draft is needed to provide shared substance to what we mean when we talk about rough consensus. 2. Should the statement be an RFC or something more malleable (and therefore ephemeral)? Why would we not want something this essential to be available through our formal publishing and archiving mechanism? To the extent that later discussions prompt modifications, that's what the errata mechanism is for. And eventual revision to the RFC. Unless someone thinks that this core construct for the IETF is going to be subject to constant and fundamental modification??? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Last Call: draft-resnick-on-consensus-05.txt (On Consensus and Humming in the IETF) to Informational RFC
On 10/7/13 10:48 AM, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'On Consensus and Humming in the IETF' draft-resnick-on-consensus-05.txt as Informational RFC I would like to perform a thorough review and provide more detailed feedback, but time is short right now. Here are a few questions in the meantime... The Abstract states: It is simply a collection of principles, hopefully around which the IETF can come to (at least rough) consensus. Does that mean you aim to make *this* I-D an IETF stream RFC that will itself have consensus, or do you instead aim to use this document to generate discussion that might result in consensus in the future (e.g., as a BCP)? If the latter, publishing in the Independent Stream seems sensible. If the former, then I think we need to have more discussion (along the lines of other Last Call feedback I've glanced at). The Introduction states: Our ideal is full consensus, but we don't require it: Full consensus would allow a single intransigent person who simply keeps saying No! to stop the process cold. By full consensus do you mean unanimity? And do you think that unanimity or full consensus is our ideal, although an ideal that's not always reachable in practice? Or is our ideal actually rough consensus (i.e., something like general agreement without unanimity)? If unanimity or full consensus is our ideal then we might expend more energy to win over instransigent persons or those who are in the rough than we would if rough consensus were our ideal. So I think it's important to be clear on what we're aiming for. Peter -- Peter Saint-Andre https://stpeter.im/
Re: Last Call: draft-resnick-on-consensus-05.txt (On Consensus and Humming in the IETF) to Informational RFC
On Oct 8, 2013, at 11:39 AM, Ted Hardie ted.i...@gmail.com wrote: To be clear here, I did not think Pete's document was going for BCP. Indeed, but you are speaking of it as if it were, which was my point.
Re: Last Call: draft-resnick-on-consensus-05.txt (On Consensus and Humming in the IETF) to Informational RFC
Some comments in-line. On Tue, Oct 8, 2013 at 8:47 AM, Dave Crocker d...@dcrocker.net wrote: On 10/8/2013 8:36 AM, Ted Hardie wrote: And what are the RFC numbers for the comments? If none, as I suspect, then the comments aren't the same status as the documents--that's fine for RFC 791 and 2460, but it is not clear that Pete's document falls into the same class. I would argue it does not. Unfortunately the concern you are raising has often been applied to all sorts of IETF work. Many bits of IETF work are subject to on-going comments and often reach the practical status of de facto -- or, in the case of the errata mechanism, IETF de jure -- modifications to the published document. In fact, the line of argument you raise has frequently been lodged against the BCP construct. Yet we keep finding BCPs useful to create. 1. Does the IETF need a modern, thorough, community-approved statement of it's consensus model and the application of the model? That is, both theory and practice. So far, it looks as if the community certainly thinks we do, and strongly agree. In fact I think we suffer greatly by not having it. And as we've gone through multiple generations of participants, we've tended towards reliance on catch-phrases, without a shared understanding of their deeper meaning and specific practice. So folks invent their own meanings as best they can. Something like Pete's draft is needed to provide shared substance to what we mean when we talk about rough consensus. If the community believes that we need a community-approved statement of its decision-making model and how it is applied, then we should develop one in a community process. It may at that point be something that becomes a BCP. As an input draft to that discussion or community process, I think Pete's draft is very useful--it has sparked multiple rounds of discussion. But I don't think it is clear that this is its intended function (that unclear on the audience bit) and I think it might be read to be a proposed output document from that process. I don't think it is anywhere near ready to be considered as an output document, for reasons I already laid out. 2. Should the statement be an RFC or something more malleable (and therefore ephemeral)? Why would we not want something this essential to be available through our formal publishing and archiving mechanism? To the extent that later discussions prompt modifications, that's what the errata mechanism is for. And eventual revision to the RFC. Unless someone thinks that this core construct for the IETF is going to be subject to constant and fundamental modification??? Again, I think this is the question of the document's audience and function. If the aim is to use it to spark debate, than ephemeral is better than fixed. If it is meant to be a community statement of our process, in theory and practice, it should be fixed--but this document is not that community statement in its current form. regards, Ted d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Last Call: draft-resnick-on-consensus-05.txt (On Consensus and Humming in the IETF) to Informational RFC
At 09:48 07-10-2013, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'On Consensus and Humming in the IETF' draft-resnick-on-consensus-05.txt as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-11-04. Exceptionally, comments may be I found the review by Dave Crocker [1] interesting. Instead of reading the latest revision of the draft I wrote a draft [2]. I read what Pete Resnick said about consensus after that to compare notes. The intended status of draft-resnick-on-consensus-05 is Informational. What we have here is a document about consensus which will reflect the consensus of the IETF. Should the document reflect the consensus of the IETF or not? In Section 1: 'Our ideal is full consensus, but we don't require it: Full consensus would allow a single intransigent person who simply keeps saying No! to stop the process cold.' The above introduces the term full consensus. I took a quick look and I found at least one occurrence of the term in IETF discussions [3]. However, none of the IETF process documents use that term. If the chair of a working group determines that a technical issue brought forward by an objector has been truly considered by the working group, and the working group has made an informed decision that the objection has been answered or is not enough of a technical problem to prevent moving forward, the chair can declare that there is rough consensus to go forward, the objection notwithstanding. The word objector emphasizes that there is one person who dissents. My preference is to consider the objection and address it instead of viewing the issue as dissent from one person. This document attempts to explain some features of rough consensus, explain what is not rough consensus, and suggest ways that we might achieve rough consensus and judge it in the IETF. The title of the document is on consensus and humming in the IETF. According to the above sentence the document attempts to discuss about rough consensus. In my opinion there a nuance between consensus and rough consensus. As a quick reaction I would say that rough consensus provides a faster path to shape up a proposal. It helps to cut down on document delivery time to the IESG. The consensus part is sought by getting a broader perspective. Section 2 sounds like objection-based processing. A binary choice (re. technical question) can end up polarizing a discussion. The section provides a good discussion about lack of disagreement. One of the questions I wondered about is whether the person making the determination should use technical judgement or whether the person should only make a determination about the comments received. I mentioned in an unrelated discussion that if it is the consensus of the group that the sky is green, that's what goes in the document. The person making the determination can flag it as an issue as a matter of technical judgement. I'll highlight a point from Section 3: Remember, if the objector feels that the issue is so essential that it must be attended to, they always have the option to file an appeal. There are very few people who exercise that option. According to the title of Section 4 humming should be the start of a conversation, not the end. BCP 25 states that: Consensus can be determined by a show of hands, humming, or any other means on which the WG agrees (by rough consensus, of course). I am not sure whether hums are for a starting point or not. It can be argued in different ways, for example, see Section 4. Humming helps to get a sense of the room without people making a decision under duress. It is a useful way to resolve a controversy. I would say that it ties in Section 5, i.e. consensus is the path, not the destination. A show of hands is a disguised way to vote [4]. Section 5 identifies a few issues with the way people talk about consensus. I understand what Pete Resnick wrote as he has explained that to me in an unrelated discussion. The text discusses about making the call. I don't know whether the reader will easily understand the meaning of that. Section 6 and Section 7 attempt to explain that a high percentage of votes in a direction does not necessarily mean that there is rough consensus for that. I agree with the conclusion in Section 8. Regards, S. Moonesamy 1. http://www.ietf.org/mail-archive/web/ietf/current/msg82843.html 2. http://tools.ietf.org/html/draft-moonesamy-consensus-00 3. http://www.ietf.org/mail-archive/web/isms/current/msg00943.html 4. http://www.ietf.org/mail-archive/web/ietf/current/msg25014.html
Re: Last Call: draft-resnick-on-consensus-05.txt (On Consensus and Humming in the IETF) to Informational RFC
On Oct 8, 2013, at 1:56 PM, S Moonesamy sm+i...@elandsys.com wrote: I am not sure whether hums are for a starting point or not. It can be argued in different ways, for example, see Section 4. Humming helps to get a sense of the room without people making a decision under duress. Personally, I think focusing on Jeff Case's hums is missing the point. The point is the meaning of the term rough consensus, and how that plays out in working group process. The manner of measurement is a secondary issue. To my small and somewhat naive mind, the difference between rough consensus on a topic and a vote on the same topic is something about winners and losers. In a purely political process, when a set of parties vote on something and the preponderance (by some definition of preponderance) say something, the views of the losing set of parties are deemed irrelevant. In IETF process, and hopefully in any technical process, there is understanding that the parties who disagree may have valid reasons to disagree, and a phase of negotiation. When we talk about rough consensus, I understand it to mean - and would like to believe that we all understand it this way - that we investigate the reasons for disagreement, perhaps discover that some of them are valid, and address those issues to the satisfaction of those who raised them. As a result, the ultimate solution, even though it may not be the specific solution we would all have designed or selected, is one that in fact addresses all known issues. While we may not all agree, we don't disagree. I think the document on the table tries to address that. There are points of phraseology that I might express differently, but it's close enough that I don't disagree. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Last Call: draft-resnick-on-consensus-05.txt (On Consensus and Humming in the IETF) to Informational RFC
On 10/8/13 3:21 PM, Fred Baker (fred) wrote: To my small and somewhat naive mind, the difference between rough consensus on a topic and a vote on the same topic is something about winners and losers. In a purely political process, when a set of parties vote on something and the preponderance (by some definition of preponderance) say something, the views of the losing set of parties are deemed irrelevant. In IETF process, and hopefully in any technical process, there is understanding that the parties who disagree may have valid reasons to disagree, and a phase of negotiation. When we talk about rough consensus, I understand it to mean - and would like to believe that we all understand it this way - that we investigate the reasons for disagreement, perhaps discover that some of them are valid, and address those issues to the satisfaction of those who raised them. As a result, the ultimate solution, even though it may not be the specific solution we would all have designed or selected, is one that in fact addresses all known issues. While we may not all agree, we don't disagree. I've done a lot of work on consensus over the years and I think this is fundamentally correct, although I'd amend the last sentence to something along the lines of While we may not all agree, those who disagree can live with it. That is to say, it's not a binary question, and sometimes things we disagree with just aren't showstoppers. (I'd like to see people take that position more often - for some reason a lot of people seem to take disagreement as a reason to block a decision even when it doesn't matter that much). Melinda
Re: Last Call: draft-resnick-on-consensus-05.txt (On Consensus and Humming in the IETF) to Informational RFC
On Oct 8, 2013, at 8:23 PM, Melinda Shore melinda.sh...@gmail.com wrote: I've done a lot of work on consensus over the years and I think this is fundamentally correct, although I'd amend the last sentence to something along the lines of While we may not all agree, those who disagree can live with it. That is to say, it's not a binary question, and sometimes things we disagree with just aren't showstoppers. (I'd like to see people take that position more often - for some reason a lot of people seem to take disagreement as a reason to block a decision even when it doesn't matter that much). wfm signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Last Call: draft-resnick-on-consensus-05.txt (On Consensus and Humming in the IETF) to Informational RFC
All, FWIW - my personal way of thinking about consensus vd. rough consensus, please note that it my personal view not a definition. Consensus - An agreement by everyone in a group that a proposed solution is the best of all of all possible solutions Rough consensus - An agreement by almost everyone that the proposed solution is good enough for everyone to live with. /Loa On 2013-10-09 11:23, Melinda Shore wrote: On 10/8/13 3:21 PM, Fred Baker (fred) wrote: To my small and somewhat naive mind, the difference between rough consensus on a topic and a vote on the same topic is something about winners and losers. In a purely political process, when a set of parties vote on something and the preponderance (by some definition of preponderance) say something, the views of the losing set of parties are deemed irrelevant. In IETF process, and hopefully in any technical process, there is understanding that the parties who disagree may have valid reasons to disagree, and a phase of negotiation. When we talk about rough consensus, I understand it to mean - and would like to believe that we all understand it this way - that we investigate the reasons for disagreement, perhaps discover that some of them are valid, and address those issues to the satisfaction of those who raised them. As a result, the ultimate solution, even though it may not be the specific solution we would all have designed or selected, is one that in fact addresses all known issues. While we may not all agree, we don't disagree. I've done a lot of work on consensus over the years and I think this is fundamentally correct, although I'd amend the last sentence to something along the lines of While we may not all agree, those who disagree can live with it. That is to say, it's not a binary question, and sometimes things we disagree with just aren't showstoppers. (I'd like to see people take that position more often - for some reason a lot of people seem to take disagreement as a reason to block a decision even when it doesn't matter that much). Melinda -- Loa Anderssonemail: l...@mail01.huawei.com Senior MPLS Expert l...@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64
Re: Last Call: draft-resnick-on-consensus-05.txt (On Consensus and Humming in the IETF) to Informational RFC
On 10/8/13 9:20 PM, Loa Andersson wrote: FWIW - my personal way of thinking about consensus vd. rough consensus, please note that it my personal view not a definition. Consensus - An agreement by everyone in a group that a proposed solution is the best of all of all possible solutions Rough consensus - An agreement by almost everyone that the proposed That's a lot like voting, I think. Melinda
Re: Last Call: draft-resnick-on-consensus-05.txt (On Consensus and Humming in the IETF) to Informational RFC
On 2013-10-09 13:30, Melinda Shore wrote: On 10/8/13 9:20 PM, Loa Andersson wrote: FWIW - my personal way of thinking about consensus vs. rough consensus, please note that it my personal view not a definition. Consensus - An agreement by everyone in a group that a proposed solution is the best of all of all possible solutions Rough consensus - An agreement by almost everyone that the proposed solution is good enough for everyone to live with. That's a lot like voting, I think. Well - if you say so, but then we don't have even a rough consensus on what consensus and rough consensus means. Note I talked about what a group need to reach to be able to say that there is consensus or rough consensus. Not how it is measured, in IETF we trust the wg chairs to correctly judge if we have reached a rough consensus. /Loa Melinda -- Loa Anderssonemail: l...@mail01.huawei.com Senior MPLS Expert l...@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64
Re: Last Call: draft-resnick-on-consensus-05.txt (On Consensus and Humming in the IETF) to Informational RFC
First, I am always happy when folks take the time to think deeply about the IETF's processes and share those thoughts with the community. I think the conversation this has already started has been useful, and I hope that the last call conversation is the same. That said, I do not think this document is ready for publication as an RFC, and I personally suspect that it wouldn't be the best fate for it even it were. On the second point, the truth is that informational RFCs are treated as actual requests for comments much any more, but are taken as fixed; if the points this raises are to be maintained as items of conversation (which is my personal preference), then incorporating pieces of it into the Tao, Edu Team documents, or WG training may be appropriate instead. That is, put this into some form where folks will not take it as an item of dogma, but as the start of a conversation, and the community will be better served. Even as an Informational document, if it is published as an RFC by a sitting AD via the IETF stream, it may not get that treatment. If the IESG does believe that this should be published as an RFC, I think it continues to need serious work before publication. At the very base, I think it needs a much stronger sense of its audience (advice to WG chairs and those that deal with them? new participants in the IETF? those who want to understand the workings of the IETF from the outside?) and a structure which relates to that audience. I note, for example, that the document references none of the IETF's process documents or discussions that arose out previous work in this area; that's fine for some audiences but is going to be missed by folks who might get handed this as an explanatory document on how things work (or ought to) in the IETF. Once it has that audience, some of the issues with the current document may fall out, but among those with which I have personal disagreements: The document consistently describes a test for objection model of document processing; that's a fair summary of how the IETF works, but shoe-horning the description into rough consensus because we like the slogan is not really helping folks understand the IETF. The core of the IETF is a participatory process which is meant to be cooperative rather than adversarial; to that extent it is fair to describe it in consensus terms. Beyond that, however, we are really not seeking the consent of all parties, even as an ideal. We are trying to make sure that there are no known technical issues with a proposal and that there is sufficient support to believe that it will be implemented and deployed to the good of the network. Encouraging folks to believe that the ideal is full consensus is highly problematic, for exactly the reasons that Pete later raises with regards to voting: it is very difficult to determine when you have the consent of all parties if you cannot limit the parties in some way. We cannot name our members, so we cannot either count votes *or count all of them as consenting*. The document has vastly improved its description of compromise over its previous iterations, for which Pete should be commended. But it remains problematic in its description of participation. In the section Five people for and one hundred people against might still be rough consensus, the document describes what can occur when one proposal is favoured over another by a working group's active participants: one set of participants may recruit new voices to add to their preferences. The difficulty with the given description is that it is a strawman compared to that actual complexity of dealing with this situation, because it posits sales and marketing folks being the new voices. The far more difficult reality is that the voices often come from members of an impacted technical community who generally do not attend or participate in the IETF. Were they known participants in the IETF process, it is clear that their message I agree with X's points would be heard in one way, where them being new participants causes them, in this approach, to be discounted entirely if they raise no new points. Novelty is the wrong test here, as is length of participation; the test that WG chairs must use is the much messier judgement call of what the impact of the objections is on the likely implementation and deployment of the system under discussion. Lastly, I think Pete has failed to capture that one reason for using humming or hands is that it is easy for very active participants to dominate a conversation but much less easy for them to pretend to be a large group. Particularly in BoFs, using those methods to indicate the likely breadth of interest is critical. The same method can be used, with some of the caution Pete recommends, to gauge whether an issue which appears to be contentious based on a mic line is actually a problem. It can also, in some cases, be a valuable method of reinforcing the resolve a room that has already likely
Re: Last Call: draft-resnick-on-consensus-05.txt (On Consensus and Humming in the IETF) to Informational RFC
On 08/10/2013 08:03, Ted Hardie wrote: ... were. On the second point, the truth is that informational RFCs are [not] treated as actual requests for comments much any more, but are taken as fixed; I've inserted the not that Ted certainly intended. But I think he raises an important point. If the phrase Request For Comments no longer means what it says, we need another RFC, with a provisional title of Request For Comments Means What It Says. We still see comments on RFC 791 reasonably often, and I see comments on RFC 2460 practically every day. That's as it should be. So I'd like to dispute Ted's point that by publishing a version of resnick-on-consensus as an RFC, we will engrave its contents in stone. If that's the case, we have an even deeper problem than misunderstandings of rough consensus. otoh Ted's specific points on the draft are all valuable. Brian
Re: Last Call: draft-resnick-on-consensus-05.txt (On Consensus and Humming in the IETF) to Informational RFC
On Oct 7, 2013, at 3:34 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: So I'd like to dispute Ted's point that by publishing a version of resnick-on-consensus as an RFC, we will engrave its contents in stone. If that's the case, we have an even deeper problem than misunderstandings of rough consensus. Right, I think what Ted is describing is a BCP, not an Informational RFC.
Re: Last Call: draft-resnick-on-consensus-05.txt (On Consensus and Humming in the IETF) to Informational RFC
Brian E Carpenter brian.e.carpen...@gmail.com wrote: ... If the phrase Request For Comments no longer means what it says, we need another RFC, with a provisional title of Request For Comments Means What It Says. ;^) We still see comments on RFC 791 reasonably often, and I see comments on RFC 2460 practically every day. That's as it should be. Absolutely! So I'd like to dispute Ted's point that by publishing a version of resnick-on-consensus as an RFC, we will engrave its contents in stone. Well, of course, all RFCs have always been archival -- to that extent, they _are_ engraved in stone... If that's the case, we have an even deeper problem than misunderstandings of rough consensus. Alas, IMHO, we do. :^( Ted and Dave Crocker _have_ made very good comments on this I-D which is proposed to be an Informational RFC. For the most part, these comments could just as well come _after_ it is published as such. The _problem_ is that an RFC clearly labeled as an individual contribution _should_ have value _as_ an individual contribution. It should not have to pass muster of our famous peanut gallery before being published. The story is completely different for working-group documents published on the Standards Track. For those, our quality-control process is quite necessary. Perhaps the problem comes from the boilerplate for Informational: ] ] Status of This Memo ] ] This document is not an Internet Standards Track specification; it is ] published for informational purposes. ] ] This document is a product of the Internet Engineering Task Force ] (IETF). It represents the consensus of the IETF community. It has ] received public review and has been approved for publication by the ] Internet Engineering Steering Group (IESG). Not all documents ] approved by the IESG are a candidate for any level of Internet ] Standard; see Section 2 of RFC 5741. ] ] Information about the current status of this document, any errata, ] and how to provide feedback on it may be obtained at ] http://www.rfc-editor.org/info/rfc7017. The only differences between this boilerplate and the boilerplate for standards track is that the Standards Track has a different first paragraph ] ] This is an Internet Standards Track document. and the Standards Track boilerplate omits the sentence ] ] Not all documents approved by the IESG are a candidate for any level ] of Internet Standard; see Section 2 of RFC 5741. replacing it with ] ] Further information on Internet Standards is available in Section 2 ] of RFC 5741. (In fact, the IESG review is quite different for these categories.) We see that all these categories state, It represents the consensus of the IETF community. In fact, if there is an easy way to tell from the published RFC whether an Informational RFC represents an individual contribution or a Working Group output, it escapes me at the moment. :^( Thus perhaps Ted and Dave are right to hold this draft to a high consensus of the IETF community standard. I just wish that were not so... -- John Leslie j...@jlc.net
Re: Last Call: draft-resnick-on-consensus-05.txt (On Consensus and Humming in the IETF) to Informational RFC
Ted Lemon ted.le...@nominum.com wrote: On Oct 7, 2013, at 3:34 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: So I'd like to dispute Ted's point that by publishing a version of resnick-on-consensus as an RFC, we will engrave its contents in stone. If that's the case, we have an even deeper problem than misunderstandings of rough consensus. Right, I think what Ted is describing is a BCP, not an Informational RFC. Oh my! I just saw the IESG agenda, and this _is_ proposed for BCP. I retract anything I said which might criticize Ted and/or Dave Crocker for being too picky! -- John Leslie j...@jlc.net
Re: Last Call: draft-resnick-on-consensus-05.txt (On Consensus and Humming in the IETF) to Informational RFC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/7/13 5:23 PM, John Leslie wrote: Ted Lemon ted.le...@nominum.com wrote: On Oct 7, 2013, at 3:34 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: So I'd like to dispute Ted's point that by publishing a version of resnick-on-consensus as an RFC, we will engrave its contents in stone. If that's the case, we have an even deeper problem than misunderstandings of rough consensus. Right, I think what Ted is describing is a BCP, not an Informational RFC. Oh my! I just saw the IESG agenda, and this _is_ proposed for BCP. It might not be the first time that an IESG agenda has the wrong text for intended status. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSU0RxAAoJEOoGpJErxa2p2wcQAIjahTLFEiIK31muEQTY+ure Jx2ymwciHR/nhL/3GreeqBE6skMokaewsiBd4C1Umx/Gru3XmwGCgD5KBY/f729p Nt45TosOrP0Vqg9+qD516tuwDb+sUkTGws0AMoxbvSaz2NkDqgtfsUrY5U/+wZve v7+hNgqzfxCxEw7cjK7e8lK8RKRLk41Qyo3n1VhQhReEzJ7sNLGNzvZ3bwcHGE7A 0FrW8IV+SFaUWQJ6CTmlhFxxDyHjX84AjIje4P5RBaIuvTUUs7EorRYmI4YwmN3Z AqJvtiipJ+S/8JZVLCZ1x0I81mC0wtVP4sCMYFOUgCnlCeS57rtX1U/PQyZbEJjo 18HeMaKGJoar8ZILwoH/R2K0gZcnA3B/DnRCtTXIM1FQaMrHKHb1e04BZBB53PEo GG1qIfeGv0n71hs4rsnPW7ymZjEP+9UtjKb9dy926aiNasfGSvJOsIYgxzpfOEQX UMTHj7ET2b59bvTiQjzK5KrvOlzyMWIiArox/AS7NcFbXbZgot+0C/q3fzr92kGm uNYFzlz1wk22ChKYCTxIaZfZnZLJ4nMyTViZHk8jPBGriIY4ICt7sHSwajYMQ4Gr TQY8NNGW5KibayIU1geP1Jbx4A8Ry8WQzYR8Zvkl9+JgHkZE1AbSs/PgvAIFZI+a +B981ttjErcPGZyFBl01 =3AY7 -END PGP SIGNATURE-
Re: Last Call: draft-resnick-on-consensus-05.txt (On Consensus and Humming in the IETF) to Informational RFC
On 10/7/13 6:23 PM, John Leslie wrote: Oh my! I just saw the IESG agenda, and this_is_ proposed for BCP. No, it's not. I'm just prolific this month. What you see on the agenda is draft-resnick-retire-std1, not this document. That one *is* for BCP, but draft-resnick-on-consensus isn't. Remain calm. All is well. pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478
Last Call: draft-resnick-on-consensus-05.txt (On Consensus and Humming in the IETF) to Informational RFC
The IESG has received a request from an individual submitter to consider the following document: - 'On Consensus and Humming in the IETF' draft-resnick-on-consensus-05.txt as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2013-11-04. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The IETF has had a long tradition of doing its technical work through a consensus process, taking into account the different views among IETF participants and coming to (at least rough) consensus on technical matters. In particular, the IETF is supposed not to be run by a majority rule philosophy. This is why we engage in rituals like humming instead of voting. However, more and more of our actions are now indistinguishable from voting, and quite often we are letting the majority win the day, without consideration of minority concerns. This document is a collection of thoughts on what rough consensus is, how we have gotten away from it, and the things we can do in order to really achieve rough consensus. Note (to be removed before publication): This document is quite consciously being put forward as Informational. It does not propose to change any IETF processes and is therefore not a BCP. It is simply a collection of principles, hopefully around which the IETF can come to (at least rough) consensus. The file can be obtained via http://datatracker.ietf.org/doc/draft-resnick-on-consensus/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-resnick-on-consensus/ballot/ No IPR declarations have been submitted directly on this I-D.
