| ▲ | abhv 4 hours ago |
| 20+2 (conditional support) versus 7. 22/29 = 76% in some form of "yea" That feels like "rough consensus" |
|
| ▲ | stavros 2 hours ago | parent | next [-] |
| > That OMB rule, in turn, defines "consensus" as follows: "general agreement, but not necessarily unanimity, and includes a process for attempting to resolve objections by interested parties, as long as all comments have been fairly considered, each objector is advised of the disposition of his or her objection(s) and the reasons why, and the consensus body members are given an opportunity to change their votes after reviewing the comments". From https://blog.cr.yp.to/20251004-weakened.html#standards, linked in TFA. |
|
| ▲ | jcranmer 4 hours ago | parent | prev | next [-] |
| The standard used in the C and C++ committees is essentially a 2-to-1 majority in favor. I'm not aware of any committee where a 3-to-1 majority is insufficient to get an item to pass. DJB's argument that this isn't good enough would, by itself, be enough for me to route his objections to /dev/null; it's so tedious and snipey that it sours the quality of his other arguments by mere association. And overall, it gives the impression of someone who is more interested in derailing the entire process than in actually trying to craft a good standard. |
| |
| ▲ | crote an hour ago | parent | next [-] | | Standards - especially security-critical ones - shouldn't be a simple popularity contest. DJB provided lengthy, well-reasoned, and well-sourced arguments against adoption with his "nay" vote. The "aye" votes didn't make a meaningful counter-argument - in most cases they didn't even bother to make any argument at all and merely expressed support. This means there are clearly unresolved technical issues left - and not just the regular bikeshedding ones. If he'd been the only "nay" vote it might've been something which could be ignored as a mad hatter - but he wasn't. Six other people agreed with him. Considering the potential conflict of interest, the most prudent approach would be to route the unsubstantiated aye-votes to /dev/null: if you can't explain your vote, how can we be sure your vote hasn't been bought? | | |
| ▲ | jcranmer 31 minutes ago | parent [-] | | So there's a controversial feature added in C2y, named loops, that has spawned many a vociferous argument. Now, I'm a passionate supporter of this feature, for various reasons, that I can (and have, in the committee) brought up. And I know some people who are against this feature, for various reasons that have been brought up. And at the end of the day, it kind of is a popularity contest because weighing an argument of "based on my experience, this is going to be confusing for users" versus "based on my experience, this is not going to be confusing for users" is just a popularity contest among the voters on the committee, admittedly weighted by how much you trust the various people. And then there's a third category of person (really, just one person I think, though). This is responsible for the vast majority of the email traffic on the topic. They're always ready with a detailed point-by-point reply of any replies to their posts. And their argument is... um... they don't like the feature. And they so don't like the feature that they're hanging on to any scintilla of a process argument to make their displeasure derail the entire feature, without really being able to convince anybody else of their dislike (or being able to be convinced to change their mind to any argument). Now I don't have the cryptographic chops to evaluate DJB's arguments myself. But I also haven't seen any support for his arguments from people I'd trust to be able to evaluate them. And the way he's responding at this point reminds me very much of that third category of people, which is adversely affecting his credibility at this point. | | |
| ▲ | adgjlsfhk1 25 minutes ago | parent [-] | | The really big difference between named loops and cryptography is that if one gets approved and is bad, a couple new programmers get confused, while with the other, a significant chunk of the internet becomes vulnerable to hacking. | | |
| ▲ | jcranmer 15 minutes ago | parent [-] | | Just because a feature is standardized does not mean it gets implemented. This is actually even more true for cryptography than it is for programming language specifications. |
|
|
| |
| ▲ | pfortuny 2 hours ago | parent | prev | next [-] | | You are turning “consensus” into “majority” and those it not the same. | | |
| ▲ | jcranmer 2 hours ago | parent [-] | | There was a recent discussion within the C committee over what exactly constituted consensus owing to a borderline vote that was surprisingly ruled "no consensus" (and the gravitas of the discussion was over the difference between a "no" and an "abstain" vote for consensus purposes). The decision was that it had to be a ⅔ favor/(favor + against), and ¾ (favor + neutral) / (favor + against + neutral). These are the actual rules of the committee now for determining consensus. Similar rules exist for the C++ committee. If there is any conflation going on, I am not the one doing it. |
| |
| ▲ | vorpalhex 2 hours ago | parent | prev [-] | | We're talking about a landmine in a crypto spec and you're bikeshedding about consensus ratios. We should talk about the NSA designed landmine. | | |
|
|
| ▲ | f33d5173 2 hours ago | parent | prev | next [-] |
| A consensus is 100%. A rough consensus should be near 100%. 2/3 is a super majority. That's a very different standard. |
|
| ▲ | ImPostingOnHN an hour ago | parent | prev [-] |
| consensus is not a synonym for majority, supermajority, or for any fraction of the whole, unless the fraction is 100% |
