Re: consensus and anonymity
Henning Schulzrinne wrote: This is not some hypothetical case. In that WG, there had been no consensus for a year+ and it seemed unlikely that one would emerge, except by exhaustion. Thus, the ADs proceeded with a vote, with the properties described previously, which was then used as a basis for a protocol decision. (Disclosure: I was at the losing end of that decision.) You could have always done what megaco did: flip a coin. At least that's pretty hard to game. Mike, "before we flip that coin, lets be clear on the question again: 'heads I win, tails you lose' right?" On Jun 1, 2007, at 2:02 PM, Michael Thomas wrote: Henning Schulzrinne wrote: The current process doesn't work very well when voting is required, after hum-style consensus has been inconclusive. Why should voting be required? If the goal is consensus, "inconclusive" shows that you haven't achieved it. Right? That seems to me that the process is *working* as intended. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: consensus and anonymity
Henning Schulzrinne wrote: The current process doesn't work very well when voting is required, after hum-style consensus has been inconclusive. Why should voting be required? If the goal is consensus, "inconclusive" shows that you haven't achieved it. Right? That seems to me that the process is *working* as intended. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: consensus and anonymity
Michael, I am definitely with you. In practice, at least in some instances, it appears that the "decisions" are being made in meetings and you are right too there is that, but we have decided this in Timbuktu (did we ever meet there ;) ) or nowadays just the "fear" of it and people seem to say nothing when someone (AD or chair) declares that something was decided at a meeting. In the interest of being fair, now I have seen in one contentious INT area WG where the sense of the room was taken at a meeting (it was counting numbers, err, vote) and then verified on the list -- a few additional people spoke up -- and finally the consensus was declared. Now that I can live with. Everyone had a chance to say their piece and the decision was made. Kudos to the chairs and AD for making that happen. Finally, I will note that, if we look at the overall numbers, the consensus process seems to work alright (heavily skewed by "I don't care one way or another"), but I think if we look at all the contentious situations and tally them up, we may find a different story. regards, Lakshminath On 6/1/2007 9:52 AM, Michael Thomas wrote: Brian E Carpenter wrote: On 2007-05-31 22:08, Michael Thomas wrote: One thing that occurs to me is that in my initial message I implicitly felt that the room hands/hums were a more accurate assessment of consensus than the list. I guess that I should fess up that I've always felt that the "consensus is determined on the list" is something of a charming myth. I don't think people unable to travel to meetings would agree. Since our objective is to discover technical problems with a proposed consensus, I think it's essential to allow any netizen to raise problems. One email technical comment pointing out a serious flaw has far more weight than a hundred people in a room going "mmm". It seems that people have read more into my initial idea than I had really meant. I only meant it to be limited to consensus calls on the mailing list where somebody might not be comfortable publicly saying their +1. This is orthogonal to the question of anonymity of somebody who doesn't feel comfortable bringing up a technical problem on the list ala the example of Dean on the SIP list recently. The reason I say it's a charming myth is that the list is pretty lousy since it's usually a very small set of people who will speak up. Ie, the protagonists. At meetings, you get a broader sense including the intensity. As somebody who hasn't been to the last few IETF's, I well aware of the "not being there" part. Still, I think it's a myth that these hums are *just* the sense of the room and no more. They're clearly a lot more than that as it almost always brings a conclusion to some point of contention, and when it's brought up again on the list you can almost always be guaranteed a "but we decided this in Oslo!". Myth, meet reality. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: consensus and anonymity
Brian E Carpenter wrote: On 2007-05-31 22:08, Michael Thomas wrote: One thing that occurs to me is that in my initial message I implicitly felt that the room hands/hums were a more accurate assessment of consensus than the list. I guess that I should fess up that I've always felt that the "consensus is determined on the list" is something of a charming myth. I don't think people unable to travel to meetings would agree. Since our objective is to discover technical problems with a proposed consensus, I think it's essential to allow any netizen to raise problems. One email technical comment pointing out a serious flaw has far more weight than a hundred people in a room going "mmm". It seems that people have read more into my initial idea than I had really meant. I only meant it to be limited to consensus calls on the mailing list where somebody might not be comfortable publicly saying their +1. This is orthogonal to the question of anonymity of somebody who doesn't feel comfortable bringing up a technical problem on the list ala the example of Dean on the SIP list recently. The reason I say it's a charming myth is that the list is pretty lousy since it's usually a very small set of people who will speak up. Ie, the protagonists. At meetings, you get a broader sense including the intensity. As somebody who hasn't been to the last few IETF's, I well aware of the "not being there" part. Still, I think it's a myth that these hums are *just* the sense of the room and no more. They're clearly a lot more than that as it almost always brings a conclusion to some point of contention, and when it's brought up again on the list you can almost always be guaranteed a "but we decided this in Oslo!". Myth, meet reality. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
SeND & CGA Extensions BOF
Hi, we have proposed a BOF on SeND and CGA extensions for the Chicago IETF. I attach the proposed charter below. There is a mailing list created for the discussion (https://www1.ietf.org/mailman/listinfo/cga-ext) If you have comments about the proposed work, it would be appreciated. Thanks, marcelo Proposed charter for SeND & CGA Extensions BOF Secure Neighbour Discovery (SeND) protocol as defined in RFC 3971 provides the security mechanisms to protecting the different functions performed by the Neighbour Discovery (ND) protocol, including the discovery of other nodes on the link and their link-layer addresses, router discovery and reachability detection for the paths to active neighbors. However, current SeND specification lacks of support for ND Proxies as defined in RFC 4389. The SeND protocol relies on the usage of Cryptographically GEnerated Addresses (CGAs) to provide some of these functions, in particular to provide IPv6 address ownership proof to the other nodes on the link and authenticate node related information of the ND protocol. CGAs are defined in RFC 3972 which has been recently updated by RFC 4581 to define the CGA extension format and by RFC-to-be draft-bagnulo-multiple-hash-cga-03.txt to support multiple hash functions. While CGAs were originally defined for the SeND protocol, they have proved to be a useful security tool in other environments too, and its usage has been proposed to secure other protocols such as the Shim6 multihoming protocol and the Mobile IPv6 protocol. As the CGAs become more widely used for different purposes, it is necessary to produce some extensions to support such new usages. The objective of this working group is to define extensions related to both to the SeND protocol and to the CGAs. The following are charter items for the working group: - Extensions to the SeND protocol to support Neighbour Discovery Proxies: SeND protocol as currently defined in RFC 3971 lacks of support for ND Proxies defined in RFC 4389. Extensions to the SeND protocol will be defined in order to provide equivalent SeND security capabilities to ND Proxies. - Extensions to the IKEv2 protocol to create IPSec SAs associated to the CGA key. Because of their cryptographic nature, CGAs are inherently bound to the key pair that was used for their generation. This is used in existent protocols for proving address ownership. However, it would be possible also to use this cryptographic material to create a security association between peers. The key benefit of such approach is that it allows the creation of a security association that is cryptographically bound to the IP address of the end points without dependence on a common trust anchor point, eg. PKI. Such approach would provide additional protection compared to the opportunistic approaches. The proposed work will produce an analysis of this type of solution and the required extensions to CGAs and to the IKEv2 protocol in order to be able to create IPSec SA using the CGAs keys. - DHCP support for CGAs. An analysis of possible approaches to allow the usage of the DHCP protocol to assign CGAs will be produced. The output of the analysis will be an informational document describing the recommended approaches that will be provided as an input to the DHC working group where the actual DHCP extensions needed for the recommended approaches will be defined. - Define a CGA extension to support other public key algorithms: As currently defined, CGAs can only use RSA keys in the CGA Parameter Data Structure. An extension to update the CGA specification in order to multiple public key cryptographic algorithm support will be defined. Related drafts: draft-kempf-mobopts-ringsig-ndproxy-01.txt draft-laganier-ike-ipv6-cga-01.txt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: consensus and anonymity
Brian E Carpenter wrote: Combined response: On 2007-05-31 23:07, Andy Bierman wrote: I think the inability of the IETF to make decisions in an open, deterministic, and verifiable manner is a major flaw. It promotes indecision and inaction. I think the ability of some other SDOs to take go/no go decisions on unpublished documents by a fixed deadline, based on corporate voting, is a major flaw. It promotes superfical review and flawed documents. This has more to do with corporate culture and the low priority of 'quality' in the business model. The IETF's reluctance to accurately quantify consensus is a different matter. Making bad decisions on time is not the only other option. On 2007-06-01 01:14, Andy Bierman wrote: I don't understand why such a comment needs to be private. Once the issue comes to light in the WG, it is no longer going to be private. You are assuming the Chair can and should be a proxy for a WG member who wishes to remain anonymous. I disagree. Why is this a problem? Again, our goal is to discover technical flaws (or make technical improvements) in drafts. What does it matter if someone has good reason to request anonymity and to use the AD (or anyone else) as a proxy? This is only a problem as the debate escalates. It is not a problem bringing issues to light. I suppose if the Chair is willing to proxy for both sides of the issue, and make it clear when they are making a comment as a proxy or as a Chair, then it is not an issue. On 2007-06-01 04:09, Henning Schulzrinne wrote: I think a fair vote requires - a clear definition of who can vote Which is fundamentally impossible in the IETF. On 2007-06-01 04:22, Lakshminath Dondeti wrote: Can anyone point to me where it is written that voting at a meeting is the decision making process when rough consensus (hum or whatever) has been inconclusive? There must be something in between humming and corporate voting, which is better than flipping a coin and arbitrarily picking a winner. Definitely, nowhere. But there is a model that has been used where a WG agrees *by rough consensus* to accept an arbitrary decision method when a technical rough consensus cannot be reached. Example: http://www1.ietf.org/mail-archive/web/ietf/current/msg46040.html Brian __ Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Weekly posting summary for ietf@ietf.org
Total of 77 messages in the last 7 days. script run at: Fri Jun 1 00:53:01 EDT 2007 Messages | Bytes| Who +--++--+ 14.29% | 11 | 13.26% |68577 | [EMAIL PROTECTED] 6.49% |5 | 10.11% |52290 | [EMAIL PROTECTED] 6.49% |5 | 6.40% |33075 | [EMAIL PROTECTED] 6.49% |5 | 5.98% |30921 | [EMAIL PROTECTED] 5.19% |4 | 6.33% |32730 | [EMAIL PROTECTED] 5.19% |4 | 5.21% |26943 | [EMAIL PROTECTED] 5.19% |4 | 4.92% |25413 | [EMAIL PROTECTED] 5.19% |4 | 4.86% |25112 | [EMAIL PROTECTED] 5.19% |4 | 4.34% |22445 | [EMAIL PROTECTED] 5.19% |4 | 4.03% |20831 | [EMAIL PROTECTED] 3.90% |3 | 4.36% |22562 | [EMAIL PROTECTED] 2.60% |2 | 2.98% |15423 | [EMAIL PROTECTED] 2.60% |2 | 2.63% |13619 | [EMAIL PROTECTED] 2.60% |2 | 2.42% |12523 | [EMAIL PROTECTED] 2.60% |2 | 2.10% |10847 | [EMAIL PROTECTED] 1.30% |1 | 2.38% |12286 | [EMAIL PROTECTED] 1.30% |1 | 2.01% |10373 | [EMAIL PROTECTED] 1.30% |1 | 1.69% | 8759 | [EMAIL PROTECTED] 1.30% |1 | 1.68% | 8705 | [EMAIL PROTECTED] 1.30% |1 | 1.58% | 8183 | [EMAIL PROTECTED] 1.30% |1 | 1.38% | 7158 | [EMAIL PROTECTED] 1.30% |1 | 1.21% | 6242 | [EMAIL PROTECTED] 1.30% |1 | 1.17% | 6031 | [EMAIL PROTECTED] 1.30% |1 | 1.03% | 5330 | [EMAIL PROTECTED] 1.30% |1 | 1.03% | 5316 | [EMAIL PROTECTED] 1.30% |1 | 1.00% | 5187 | [EMAIL PROTECTED] 1.30% |1 | 0.91% | 4726 | [EMAIL PROTECTED] 1.30% |1 | 0.77% | 3981 | [EMAIL PROTECTED] 1.30% |1 | 0.77% | 3977 | [EMAIL PROTECTED] 1.30% |1 | 0.73% | 3764 | [EMAIL PROTECTED] 1.30% |1 | 0.71% | 3683 | [EMAIL PROTECTED] +--++--+ 100.00% | 77 |100.00% | 517012 | Total ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: consensus and anonymity
My apologies for insufficient smileys. :-( I consider that "makes voting seem reasonable" is still an insult in the IETF. Certainly not my intention to suggest voting as an alternative to secrecy. Spencer From: "Brian E Carpenter" <[EMAIL PROTECTED]> Combined response: On 2007-05-31 21:33, Spencer Dawkins wrote: The alternative - a WG chair who tells the working group that the apparent WG consensus on the mailing list is being overruled because of anonymous objections that the WG chair cannot share with the WG, or because of private objections that the WG chair is "channeling" from a back room - would make voting seem reasonable (or, to use Mark Allman's characterization in another thread, "seem charming"). I have to differ. This doesn't make voting seem reasonable; it makes secrecy seem unreasonable. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: consensus and anonymity
Combined response: On 2007-05-31 21:33, Spencer Dawkins wrote: The alternative - a WG chair who tells the working group that the apparent WG consensus on the mailing list is being overruled because of anonymous objections that the WG chair cannot share with the WG, or because of private objections that the WG chair is "channeling" from a back room - would make voting seem reasonable (or, to use Mark Allman's characterization in another thread, "seem charming"). I have to differ. This doesn't make voting seem reasonable; it makes secrecy seem unreasonable. On 2007-05-31 21:40, Hallam-Baker, Phillip wrote: If the wg chair is also on the iesg the appeals process is fatally compromised and littigation may be the only realistic prospect for redress. Not at all. That is why ADs and IAB members recuse from appeals in which they are materially concerned. On 2007-05-31 22:08, Michael Thomas wrote: One thing that occurs to me is that in my initial message I implicitly felt that the room hands/hums were a more accurate assessment of consensus than the list. I guess that I should fess up that I've always felt that the "consensus is determined on the list" is something of a charming myth. I don't think people unable to travel to meetings would agree. Since our objective is to discover technical problems with a proposed consensus, I think it's essential to allow any netizen to raise problems. One email technical comment pointing out a serious flaw has far more weight than a hundred people in a room going "mmm". On 2007-05-31 23:07, Andy Bierman wrote: I think the inability of the IETF to make decisions in an open, deterministic, and verifiable manner is a major flaw. It promotes indecision and inaction. I think the ability of some other SDOs to take go/no go decisions on unpublished documents by a fixed deadline, based on corporate voting, is a major flaw. It promotes superfical review and flawed documents. On 2007-06-01 01:14, Andy Bierman wrote: I don't understand why such a comment needs to be private. Once the issue comes to light in the WG, it is no longer going to be private. You are assuming the Chair can and should be a proxy for a WG member who wishes to remain anonymous. I disagree. Why is this a problem? Again, our goal is to discover technical flaws (or make technical improvements) in drafts. What does it matter if someone has good reason to request anonymity and to use the AD (or anyone else) as a proxy? On 2007-06-01 04:09, Henning Schulzrinne wrote: I think a fair vote requires - a clear definition of who can vote Which is fundamentally impossible in the IETF. On 2007-06-01 04:22, Lakshminath Dondeti wrote: Can anyone point to me where it is written that voting at a meeting is the decision making process when rough consensus (hum or whatever) has been inconclusive? Definitely, nowhere. But there is a model that has been used where a WG agrees *by rough consensus* to accept an arbitrary decision method when a technical rough consensus cannot be reached. Example: http://www1.ietf.org/mail-archive/web/ietf/current/msg46040.html Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
