Weekly posting summary for ietf@ietf.org
Total of 150 messages in the last 7 days. script run at: Fri Jun 12 00:53:02 EDT 2009 Messages | Bytes| Who +--++--+ 10.00% | 15 | 10.99% | 118718 | hal...@gmail.com 10.67% | 16 | 7.41% |8 | mo...@necom830.hpcl.titech.ac.jp 2.00% |3 | 11.91% | 128652 | martin.thom...@andrew.com 4.67% |7 | 6.80% |73481 | b...@estacado.net 3.33% |5 | 5.54% |59870 | mary.bar...@nortel.com 2.00% |3 | 4.54% |49006 | bernard_ab...@hotmail.com 3.33% |5 | 2.86% |30895 | david.wil...@isode.com 3.33% |5 | 2.59% |28007 | to...@isi.edu 3.33% |5 | 2.49% |26868 | a...@shinkuro.com 3.33% |5 | 2.46% |26566 | k...@bbn.com 2.67% |4 | 2.11% |22751 | ma...@isc.org 2.67% |4 | 2.10% |22650 | har...@alvestrand.no 2.00% |3 | 1.92% |20758 | s...@resistor.net 2.00% |3 | 1.85% |19928 | turn...@ieca.com 2.00% |3 | 1.52% |16465 | bob.hin...@gmail.com 2.00% |3 | 1.46% |15752 | spen...@wonderhamster.org 2.00% |3 | 1.31% |14110 | d...@cridland.net 2.00% |3 | 1.23% |13316 | sh...@isc.org 1.33% |2 | 1.42% |15379 | rbar...@bbn.com 1.33% |2 | 1.41% |15261 | iab-ch...@ietf.org 1.33% |2 | 1.26% |13566 | ietf...@comcast.net 1.33% |2 | 1.07% |11564 | melinda.sh...@gmail.com 1.33% |2 | 1.02% |11046 | hous...@vigilsec.com 1.33% |2 | 0.92% | 9982 | si...@josefsson.org 1.33% |2 | 0.86% | 9320 | d...@ewellic.org 1.33% |2 | 0.83% | 9006 | d...@dcrocker.net 1.33% |2 | 0.80% | 8611 | jari.ar...@piuha.net 0.67% |1 | 0.91% | 9786 | gregory.i...@gmail.com 0.67% |1 | 0.79% | 8495 | lars.egg...@nokia.com 0.67% |1 | 0.78% | 8402 | bapti...@publicroot.org 0.67% |1 | 0.74% | 7958 | doug.mtv...@gmail.com 0.67% |1 | 0.69% | 7424 | nar...@us.ibm.com 0.67% |1 | 0.63% | 6824 | doug...@stebila.ca 0.67% |1 | 0.63% | 6807 | huit...@windows.microsoft.com 0.67% |1 | 0.61% | 6552 | pasi.ero...@nokia.com 0.67% |1 | 0.57% | 6161 | erbli...@earthlink.net 0.67% |1 | 0.57% | 6152 | o...@ogud.com 0.67% |1 | 0.56% | 6053 | sisyp...@dial.pipex.com 0.67% |1 | 0.53% | 5671 | st...@shinkuro.com 0.67% |1 | 0.52% | 5616 | italo.b...@alcatel-lucent.it 0.67% |1 | 0.52% | 5609 | les...@thinkingcat.com 0.67% |1 | 0.52% | 5602 | j.schoenwael...@jacobs-university.de 0.67% |1 | 0.51% | 5548 | j...@joelhalpern.com 0.67% |1 | 0.51% | 5534 | dean.wil...@softarmor.com 0.67% |1 | 0.50% | 5440 | dbharring...@comcast.net 0.67% |1 | 0.50% | 5424 | t...@americafree.tv 0.67% |1 | 0.50% | 5356 | j...@apple.com 0.67% |1 | 0.49% | 5319 | o...@nlnetlabs.nl 0.67% |1 | 0.49% | 5290 | paul.hoff...@vpnc.org 0.67% |1 | 0.47% | 5087 | pek...@netcore.fi 0.67% |1 | 0.47% | 5024 | field...@gbiv.com 0.67% |1 | 0.46% | 4977 | d...@1-4-5.net 0.67% |1 | 0.46% | 4938 | wei...@watson.org 0.67% |1 | 0.45% | 4891 | d...@virtualized.org 0.67% |1 | 0.45% | 4875 | mansa...@besserwisser.org 0.67% |1 | 0.44% | 4707 | f...@cisco.com 0.67% |1 | 0.43% | 4684 | bmann...@isi.edu 0.67% |1 | 0.43% | 4677 | l...@cisco.com 0.67% |1 | 0.43% | 4641 | p...@xelerance.com 0.67% |1 | 0.39% | 4167 | rpellet...@isoc.org 0.67% |1 | 0.37% | 4045 | s...@cs.columbia.edu 0.67% |1 | 0.36% | 3929 | hartmans-i...@mit.edu 0.67% |1 | 0.32% | 3469 | ch...@ietf.org 0.67% |1 | 0.31% | 3380 | g...@amsl.com +--++--+ 100.00% | 150 |100.00% | 1080042 | Total ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Gen-ART review of draft-ietf-ospf-dynamic-hostname-03
Adding in Carlos who holds the pen for us, Please see inline starting with SH: -Original Message- From: Spencer Dawkins [mailto:spen...@wonderhamster.org] Sent: Friday, June 12, 2009 3:55 AM To: Subbaiah Venkata; Sanjay Harwani (sharwani); Danny McPherson Cc: ietf@ietf.org; General Area Review Team; Ross Callon; Acee Lindem; Abhay Roy (akr) Subject: Gen-ART review of draft-ietf-ospf-dynamic-hostname-03 I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-ospf-dynamic-hostname-03 Reviewer: Spencer Dawkins Review Date: 2009-06-11 IETF LC End Date: 2009-06-16 IESG Telechat date: (not known) Summary: This document is almost ready for publication as a Proposed Standard. I identified two minor issues listed below. 2. Possible solutions Another approach is having a centralized location where the name-to- Router ID mapping can be kept. DNS can be used for the same. A disadvantage with this centralized solution is that its a single Spencer (nit): s/its/it's/ point of failure; and although enhanced availability of the central mapping service can be designed, it may not be able to resolve the hostname in the event of reachability or network problems. Also, the response time can be an issue with the centralized solution, which can be particularly problematic in times of problem resolution. If Spencer (minor): good point on response times, but I'd also think you'd point out that looking up attributes on a centralized mapping table is exactly the wrong thing to do when you're resolving problems with routing - the centralized resource may not even be reachable. SH: I think we already have it covered just above in the same paragraph. (single point of failure) A disadvantage with this centralized solution is that its a single point of failure; and although enhanced availability of the central mapping service can be designed, it may not be able to resolve the hostname in the event of reachability or network problems. DNS is used as the centralized mapping table, a network operator may desire a different name mapping than the existing in the DNS, or new routers may not yet be in DNS. 3. Implementation The Dynamic Hostname TLV (see Section 3.1) is OPTIONAL. Upon receipt of the TLV a router may decide to ignore this TLV, or to install the symbolic name and Router ID in its hostname mapping table. Spencer (minor): I'm suspecting that if this attribute becomes widely deployed, network operators would train themselves to read the hostname and pay very little attention to the numeric router ID, so I'm wondering if it's worth saying anything (either here or in an Operations and Management Considerations section :-) about the possibility that two different routers may both insist they are "routerXYZ". That would be a misconfiguration, and the text as written allows the router to ignore the second attempt to claim the name "routerXYZ", but it would be irritating to troubleshoot a problem looking at logs that conflate two disjoint "routerXYZ" routers. I'm not a router guy, so I don't know what other responses might be appropriate - I don't think you'd declare an error for a perfectly good next-hop who's confused about its hostname, and I don't know if suggesting that this be SNMP TRAPped would make sense - but you guys would be the right ones to suggest an appropriate response. SH: This is a mis-configuration issue. Network Administrators need to be careful while configuring hostnames on the routers. I think we have text around this in 5. Security Considerations Since the hostname-to-Router ID mapping relies on information provided by the routers themselves, a misconfigured or compromised router can inject false mapping information. However I am open to the idea of elaborating it somewhere else too if every body else feels its needed. Regards Sanjay ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
In message , Phill ip Hallam-Baker writes: > So we have totally abandoned the idea of doing DNSSEC in the end point clie= > nt? No. Recursive nameserver need to validate the answers returned from the DNS for their own uses. This doesn't preclude other applications also validating answers. Having recursive nameserver validate answers is not the end point in DNSSEC deployment. It's just a good first step which is good enough is some operational envionments. There are however lots of operational envioronments where this would not be good enough and the validation really needs to be performed in the application. For your light switch example a validating recursive resolver is probably all you need. For laptops you most probably want to move the validation onto the laptop either in the application or by a running a validation recursive nameserver on the laptop which may or may not use the nameservers in the DHCP response as forwarders. I do this today. > Trust roots have to be valid for at least a decade to be acceptable to > the application vendor community. That's a unproved assumption. > And even though the current model of network administration is to > constantly fiddle with everything, I think that is going to have to > stop. Lots companies already use private roots. Equipment manufactures are not going to build equipment that can't be used by those markets. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
Hi, On Jun 11, 2009, at 8:35 PM, Stephen Kent wrote: But, in a DNSSEC environment, IANA performs two roles: - it coordinates the info from the gTLDs and ccTLDs and constructs the authoritative root zone file - it signs the records of that file Nope. Just to clarify things: IANA (well, ICANN as the IANA functions operator) receives and validates root zone changes. VeriSign constructs and publishes the root zone to the root server operators. In the context of DNSSEC, as documented at http://www.icann.org/en/announcements/announcement-2-03jun09-en.htm , VeriSign will have operational responsibility for the zone signing key and ICANN will manage the key signing process. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
Phil, The examples you give about backed-in trust anchors are valid, but they point to decisions by vendors to simplify their designs at the cost of secruity and functionality. I've been told that it is very hard, if not impossible, to permanently remove some vendor-supplied TAs in a popular browser. These are not fundamental results of architectural decisions of the sort the IETF makes, but vendor choices that lead to possible problems for user. I think I understand the multi-party, RP-centric threshold approach to managing the DNSSEC root that you outlined. But, in a DNSSEC environment, IANA performs two roles: - it coordinates the info from the gTLDs and ccTLDs and constructs the authoritative root zone file - it signs the records of that file Any scheme that allows multiple entities to "confirm" the content of the root zone file also has to include a means for these entities to independently acquire and verify the master file data and to create a separate, distinct master file if they disagree. This is a lot more complex that what you outlined in your message (from an from an administrative vs. crypto perspective). It also raises questions about how complex RP software has to be in dealing with multiple sets of quasi-authoritative root authorities. All experience to date suggests that RPs fare poorly when trying to deal with much less complex trust anchor situations in other PKI environments today. It is conceivable (under the new administration) that ICANN will stop being under the control of the U.S DoC, but it also is not clear that such a change would ameliorate the concerns of all governments with regard to this issue. I think the set of folks who feel a need to use other than the current, proposed model (IANA as the DNSSEC root) are a very small minority of the set of public Internet users and thus they should bear the burden of dealing with the resulting costs and complexity for managing alternative root schemes. I don't think that such costs and complexity should be borne by the vast majority of Internet users. Its also not clear how long one might spend debating the question of whether any single scheme would satisfy all of the players who are not comfortable with the current model. Steve___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
In message , Phill ip Hallam-Baker writes: > OK, how do you do that if the ICANN root is baked into your broadband > router? How about a light switch? Given that the ICANN root servers have a history of changing address I would not expect any vendor to not provide a mechanism for changing them. We build in the ICANN root servers in our products but we also provide mechanisms to change them. % grep ROOT-SE CHANGES 2328. [maint] Add addresses for A.ROOT-SERVERS.NET, F.ROOT-SERVERS.NET, H.ROOT-SERVERS.NET, J.ROOT-SERVERS.NET, K.ROOT-SERVERS.NET and M.ROOT-SERVERS.NET. 2255. [maint] L.ROOT-SERVERS.NET is now 199.7.83.42. 1567. [maint] B.ROOT-SERVERS.NET is now 192.228.79.201. 1397. [maint] J.ROOT-SERVERS.NET is now 192.58.128.30. % The same thing will have to be provided for and DNSKEY's embedded in software as the expectation is that these will change relatively often, much more often than CA certs. > Yes in theory I can reverse engineer the code. In practice this is not > practical. In theory the music industry could set up their own > alternative to iTunes, in practice they have no choice but to deal > with Apple. Governments are not private companies. Governments often do things no sane company would do. > Most cell phones ship with only a small number of SSL roots and the > end user has no ability to change them. > > You can change the signing key, but distributing and embedding the > verification key is a whole different issue. The reason that VeriSign > can charge a premium for certs is because its verification roots are > the most widely embedded. > > You may disagree with my arguments here, but you do not have the > standing to call them 'specious'. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Publicizing IETF nominee lists [Fwd: Last Call: draft-dawkins-nomcom-openlist (Nominating Committee Process: Open Disclosure of Willing Nominees) to BCP]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I do not debate the utility to the Nomcom of this change. I believe it comes with a cost, and I do not agree that it is a simple decision. I do not agree that the Nomcom is the only party here worth consideration. Joe Stephen Kent wrote: > Joe, > > Having served on NOMCOM more than once, and having been solicited for > inputs every year, I much prefer publishing the names of folks have > consented to be considered for IAB and IESG positions. The addition of > "ringers" to lists that are sent out (to hide the identities of the true > candidates) wastes the time of a lot of folks who are asked to provide > feedback on these non-candidates. It also means that someone who is a > real candidate may not receive feedback because people assume the > individual is a ringer! > > Steve -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoxo8kACgkQE5f5cImnZrtsewCeLOjG5iIYRgfDCbSHxiVw/GE1 ZFUAn39X8Z3OPmAm8lSFgdP/2AAwtPjY =8ZBh -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Publicizing IETF nominee lists [Fwd: Last Call: draft-dawkins-nomcom-openlist (Nominating Committee Process: Open Disclosure of Willing Nominees) to BCP]
Joe, Having served on NOMCOM more than once, and having been solicited for inputs every year, I much prefer publishing the names of folks have consented to be considered for IAB and IESG positions. The addition of "ringers" to lists that are sent out (to hide the identities of the true candidates) wastes the time of a lot of folks who are asked to provide feedback on these non-candidates. It also means that someone who is a real candidate may not receive feedback because people assume the individual is a ringer! Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Publicizing IETF nominee lists [Fwd: Last Call: draft-dawkins-nomcom-openlist (Nominating Committee Process: Open Disclosure of Willing Nominees) to BCP]
On Jun 11, 2009, at 3:01 PM, Phillip Hallam-Baker wrote: Actually, that raises a very good point. At present the list is neither secret, nor public. Any bad effect from the list being public will occur, any bad effect from it being secret can occur. I think that that is a "deep truth," since 1,$s/bad/good/ is also true. Regards Marshall On Thu, Jun 11, 2009 at 2:45 PM, Bob Hinden wrote: Joe, 1) exposing the full list to the entire community invites lobbying the nomcom This probably already happens to some extent, but do we really want to encourage this? It's not clear this will lead to more lobbying than we have now. I think lobbying happens a lot now and is driven by the candidate him/ herself, or the many people who get the "secret" lists. I think it would be more balanced if everyone knew. I would add that the current system gives a greater ability to comment on candidates to the leadership (IAB/IESG/WG Chairs) because they get the many of the "secret" nomcom candidate lists. The nomcom might get broader feedback if the lists are open. Bob ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART review of draft-ietf-ospf-dynamic-hostname-03
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-ospf-dynamic-hostname-03 Reviewer: Spencer Dawkins Review Date: 2009-06-11 IETF LC End Date: 2009-06-16 IESG Telechat date: (not known) Summary: This document is almost ready for publication as a Proposed Standard. I identified two minor issues listed below. 2. Possible solutions Another approach is having a centralized location where the name-to- Router ID mapping can be kept. DNS can be used for the same. A disadvantage with this centralized solution is that its a single Spencer (nit): s/its/it's/ point of failure; and although enhanced availability of the central mapping service can be designed, it may not be able to resolve the hostname in the event of reachability or network problems. Also, the response time can be an issue with the centralized solution, which can be particularly problematic in times of problem resolution. If Spencer (minor): good point on response times, but I'd also think you'd point out that looking up attributes on a centralized mapping table is exactly the wrong thing to do when you're resolving problems with routing - the centralized resource may not even be reachable. DNS is used as the centralized mapping table, a network operator may desire a different name mapping than the existing in the DNS, or new routers may not yet be in DNS. 3. Implementation The Dynamic Hostname TLV (see Section 3.1) is OPTIONAL. Upon receipt of the TLV a router may decide to ignore this TLV, or to install the symbolic name and Router ID in its hostname mapping table. Spencer (minor): I'm suspecting that if this attribute becomes widely deployed, network operators would train themselves to read the hostname and pay very little attention to the numeric router ID, so I'm wondering if it's worth saying anything (either here or in an Operations and Management Considerations section :-) about the possibility that two different routers may both insist they are "routerXYZ". That would be a misconfiguration, and the text as written allows the router to ignore the second attempt to claim the name "routerXYZ", but it would be irritating to troubleshoot a problem looking at logs that conflate two disjoint "routerXYZ" routers. I'm not a router guy, so I don't know what other responses might be appropriate - I don't think you'd declare an error for a perfectly good next-hop who's confused about its hostname, and I don't know if suggesting that this be SNMP TRAPped would make sense - but you guys would be the right ones to suggest an appropriate response. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC Review of draft-hollenbeck-rfc4933bis-01
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-hollenbeck-rfc4933bis-01 Reviewer: Ben Campbell Review Date: 2009-06-11 IETF LC End Date: 2009-06-11 IESG Telechat date: (if known) Summary: This draft is ready for publication as a full standard. Note: The LC announcement mentions an implementation report at http://www.ietf.org/IESG/implementation.html . If there is in fact a report there for this draft, I did not find it. Major issues: None Minor issues: None Nits/editorial comments: None ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: End to End Secure Protocols are bogus.
Phillip Hallam-Baker wrote: > End to end ceases to have any value whatsoever once people attempt to > codify it into a rigid ideology. Exactly. That was what happening by those people with false claims that DNSSEC were secure end to end. The reality, however, is that attacking DNSSEC is as easy as plain old DNS by poisoning cache with forged certificate through glue (e.g. Kaminsky's attack). Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Publicizing IETF nominee lists [Fwd: Last Call: draft-dawkins-nomcom-openlist (Nominating Committee Process: Open Disclosure of Willing Nominees) to BCP]
Actually, that raises a very good point. At present the list is neither secret, nor public. Any bad effect from the list being public will occur, any bad effect from it being secret can occur. On Thu, Jun 11, 2009 at 2:45 PM, Bob Hinden wrote: > Joe, > >> 1) exposing the full list to the entire community invites lobbying the >> nomcom >> >> This probably already happens to some extent, but do >> we really want to encourage this? > > It's not clear this will lead to more lobbying than we have now. I think > lobbying happens a lot now and is driven by the candidate him/herself, or > the many people who get the "secret" lists. I think it would be more > balanced if everyone knew. > > I would add that the current system gives a greater ability to comment on > candidates to the leadership (IAB/IESG/WG Chairs) because they get the many > of the "secret" nomcom candidate lists. The nomcom might get broader > feedback if the lists are open. > > Bob > > > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Publicizing IETF nominee lists [Fwd: Last Call: draft-dawkins-nomcom-openlist (Nominating Committee Process: Open Disclosure of Willing Nominees) to BCP]
The deliberative process of NOMCON means that it is more likely that consensus will be reached on the candidates that fewest people object to rather than those that have the strongest support. On Thu, Jun 11, 2009 at 11:32 AM, Joe Touch wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > > Melinda Shore wrote: >> SM wrote: >>> Hi Phillip, >>> At 08:32 10-06-2009, Phillip Hallam-Baker wrote: A more useful change would be to abolish NOMCON and for those currently qualified to sit on NOMCON to elect the IAB and ADs directly. >>> The implications of the above is much more than publicizing the IETF >>> list of nominees. The discussion of that document highlighted how a >>> simple statement like "we want an open list" is not as simple as it >>> sounds. >> >> Indeed. Having elections means determining who's >> eligible to vote, and that has all kinds of cascading >> consequences. > > We already have that. The only difference is that: > > - - voters are selected randomly from among those not "running for office" > > - - voters are required to participate in interviews and meetings, which > may make them more informed > > In the end, though, all voting systems are popularity contests. > > Joe > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkoxI5wACgkQE5f5cImnZrtsvwCfduYzOIzSe5WBKPMW7Faiw48v > VMsAoKZlZRGzIsPhwj9NIJt2FfjjNM3O > =eV6t > -END PGP SIGNATURE- > -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
OK, how do you do that if the ICANN root is baked into your broadband router? How about a light switch? Yes in theory I can reverse engineer the code. In practice this is not practical. In theory the music industry could set up their own alternative to iTunes, in practice they have no choice but to deal with Apple. Most cell phones ship with only a small number of SSL roots and the end user has no ability to change them. You can change the signing key, but distributing and embedding the verification key is a whole different issue. The reason that VeriSign can charge a premium for certs is because its verification roots are the most widely embedded. You may disagree with my arguments here, but you do not have the standing to call them 'specious'. On Thu, Jun 11, 2009 at 10:28 AM, Richard Barnes wrote: > Phil, > > That's a specious argument. As several others have noted on this list, it's > perfectly feasible for any relying parties (sovereign nations or otherwise) > to not use the IANA root, simply by creating their own root. This is a > little more complicated than just redirecting IP traffic, but not by much. > > To quote from Mark's earlier message: > > Mark Andrews wrote: >> Stephen Kent writes: >>> >>> You have argued that DNSSEC is not viable because it requires that >>> everyone adopt IANA as the common root. >> >> Which isn't even a requirement. Alternate root providers just need >> to get copy of the root zone with DS records and sign it with their >> own DNSKEY records for the root. > > --Richard > > > > > > > > Phillip Hallam-Baker wrote: >> >> Steve, >> >> The sovereign nations that object to US control of the root are >> willing to accept the current status quo preciely because they have an >> exit option. Should the US defect on its obligations and order ICANN >> to drop Cuba or Palestine out of the root or to take any other action >> that was considered to be abusive, the countries that objected could >> simply direct their local ISPs to redirect all IP traffic to the A >> thru M root servers to another set of servers of their choice. >> >> At the moment the ICANN has the theoretical ability to defect, but can >> only do so at the cost of becomming irrelevant. The global DNS outside >> the US would swiftly pass to the ITU. >> >> With the proposed root arrangement for DNSSEC, this changes. Not only >> does the US have effective control, it has perpetual control of any >> apparatus that chains to the ICANN root of trust. >> >> This is bad for the US, bad for ICANN and bad for other sovereign >> states. First, consider the likely source of a defection, some idiot >> member of Congress from Florida grandstanding for votes. Such a move >> is going to give the career civil service a fit, particularly the >> diplomats who prefer to end rather than begin international crises. I >> have spoken to very enior members of this administration on this >> topic, they had come to the exact same conclusion themselves. >> >> Now consider ICANN. Let us imagine that they do hold the master root >> key. What is then to stop some armed terrorist nut cases laying siege >> to the key repository? Their objective might not be to drop a country >> out, they might want to insert some irredentist domain of their own. >> >> >> Ordinary PKIs are not subject to this type of pressure, because they >> are not the lynchpin of the global communication system. >> >> While the various splinter-roots may appear to be complete jokes, they >> have had one significant result, they have drawn attention to the >> issue. In particular very much doubt that the Turkish secret service >> are too amused at the whole process given some of their experiences. >> >> >> >> On Wed, Jun 10, 2009 at 1:11 PM, Stephen Kent wrote: >>> >>> Joe, >>> >>> You have argued that DNSSEC is not viable because it requires that >>> everyone >>> adopt IANA as the common root. I agree that under the current IANA >>> management situation many folks may be uncomfortable with IANA as the >>> root. >>> However, in practice, the world has lived with IANA as the root for the >>> non-secure version of DNS for a long time, so it's not clear that a >>> singly-rooted DNSSEC is not viable based on this one concern. Moreover, >>> DNSSEC is a form of PKI, an din ANY PKI, it is up to the relying parties >>> to >>> select the trust anchors they recognize. In a hierarchic system like >>> DNS, >>> the easiest approach is to adopt a single TA, the DNS root. But, it is >>> still >>> possible for a relying party to do more work and select multiple points >>> as >>> TAs. I would expect military organizations in various parts of the world >>> to >>> adopt a locally-managed TA store model for DNSSEC, to address this >>> concern. >>> However the vast majority of Internet users probably are best served by >>> the >>> single TA model. >>> >>> As for DNSCurve, I agree with the comments that several others have made, >>> i.e., it doe snot provide the fundamental security one wan
Re: Publicizing IETF nominee lists [Fwd: Last Call: draft-dawkins-nomcom-openlist (Nominating Committee Process: Open Disclosure of Willing Nominees) to BCP]
The idea that we would not want to return to the current system sounds like an argument against the status quo, rather than in favor of it. To answer Melinda, yes, the FSF would probably try to get a person onto the IAB. Let us imagine that they did so. Either the person is a raving lunatic, in which case all that happens is that the effective membership of the IAB drops by one, or they are sensible. If they are sensible they would almost certainly end up being co-opted and end up exporting our world view to the FSF. On Thu, Jun 11, 2009 at 9:23 AM, Andrew Sullivan wrote: > On Thu, Jun 11, 2009 at 06:32:56AM -0400, Melinda Shore wrote: > >> worth a shot. If MonsterCorp starts larding up the >> leadership with their own employees or it turns into >> a popularity contest it can be undone, > > I doubt that it can be undone once done. Any attempt to undo will be > decried as an attempt to hide something, move things into smoky back > rooms, &c. That will be especially true if it turns out that > companies who want to put resources into "getting people on the IESG" > (or whatever) are successful: they'll be able to use the same > resources to oppose changes that will undo that advantage. > > This isn't to say it's a bad idea (I haven't formed an opinion), but I > do think the move towards publicising these candidacies is a one-way > door. > > A > > -- > Andrew Sullivan > a...@shinkuro.com > Shinkuro, Inc. > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Voting (Re: Publicizing IETF nominee lists)
Yelling? How about reasoned arguments. ISO standards are merely accreditations, like getting your facilities ISO9000 certified. The criteria for getting an ISO accreditation is no more than documenting your specification and surrendering change control. Word was a de-facto industry standard, there was absolutely no justification for not accepting it as an ISO standard. The game the ODF side was attempting to play was to get various governments to insert support for open standards into procurement contracts and then ensure that only the ODF format was allowed to become a specification. That is not a strategy I consider to be ethical. If they had been lobbying corporations rather than government entities it would be a very clear anti-trust violation. Playing that type of game in ISO does not have anti-trust issues as they have recognition as an international treaty organization. But playing the same game in IETF would lead to serious lawsuits. What sound like quaint customs inside the IETF would likely sound rather different in court under cross examination by plaintiff's counsel. Do you want to explain to m'lud how the issue was decided on a hum? On Thu, Jun 11, 2009 at 9:22 AM, Harald Alvestrand wrote: > Phillip Hallam-Baker wrote: >> >> On Thu, Jun 11, 2009 at 6:58 AM, Harald Alvestrand >> wrote: >> >>> >>> Voting has all kinds of issues. >>> >> >> Precisely the type of vague, non reason that I was complaining about. >> > > Consider the last ten years of yelling to be included by reference. >> >> >>> >>> I like the current Nomcom process because it depends on 2 things: >>> >>> - A pool of qualified volunteers >>> - Luck in picking a nomcom that behaves sensibly (for whatever that means >>> to >>> you) >>> >>> Given that luck is involved, many of the possible attacks that people >>> could >>> mount in order to gain more IETF influence won't happen - simply because >>> they have a significant chance of failure. Trying, failing, and being >>> detected as having tried, would be harmful to the group that tried it. >>> >> >> The last time I was aware of anything like that happening in any >> standards group was when XrML was killed in OASIS, but the issue there >> was people opposed to DRM, not a company driven thing. >> >> Where companies want to tilt the playing field they usually have to >> start the organization to succeed. Or get in early like the XRI folk >> did with OpenID. And fat lot of good it did them. >> >> >> As a former corporate rep, I can assure you that there is precisely >> zero value in gaining the imprimatur of the IETF (or OASIS or W3C for >> that matter) if you short circuit the process. The point of standards >> participation is to get buy in from other parties you need to build >> common infrastructure. >> > > Sure. That's why Microsoft spent so much resource (and credibility) making > sure the OOXML vote went through; they did not gain anything of value. > Or perhaps the value proposition is different for ISO than for the IETF. > > > -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Voting (Re: Publicizing IETF nominee lists)
On Thu, Jun 11, 2009 at 6:58 AM, Harald Alvestrand wrote: > Voting has all kinds of issues. Precisely the type of vague, non reason that I was complaining about. > I like the current Nomcom process because it depends on 2 things: > > - A pool of qualified volunteers > - Luck in picking a nomcom that behaves sensibly (for whatever that means to > you) > > Given that luck is involved, many of the possible attacks that people could > mount in order to gain more IETF influence won't happen - simply because > they have a significant chance of failure. Trying, failing, and being > detected as having tried, would be harmful to the group that tried it. The last time I was aware of anything like that happening in any standards group was when XrML was killed in OASIS, but the issue there was people opposed to DRM, not a company driven thing. Where companies want to tilt the playing field they usually have to start the organization to succeed. Or get in early like the XRI folk did with OpenID. And fat lot of good it did them. As a former corporate rep, I can assure you that there is precisely zero value in gaining the imprimatur of the IETF (or OASIS or W3C for that matter) if you short circuit the process. The point of standards participation is to get buy in from other parties you need to build common infrastructure. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Publicizing IETF nominee lists [Fwd: Last Call: draft-dawkins-nomcom-openlist (Nominating Committee Process: Open Disclosure of Willing Nominees) to BCP]
And why did XMPP leave IETF process in the first place? On Thu, Jun 11, 2009 at 7:27 AM, Dave Cridland wrote: > On Wed Jun 10 16:32:37 2009, Phillip Hallam-Baker wrote: >> >> A more useful change would be to abolish NOMCON and for those >> currently qualified to sit on NOMCON to elect the IAB and ADs >> directly. > > A complete disaster for me, at least, since I - along with a substantial > number of reasonably active and involved IETF participants - am no qualified > to sit on NOMCOM. > > With the current state of affairs, I can still ensure my voice is heard by > NOMCOM, whereas with direct voting, I could not. Given the current climate, > and particularly how it affects corporate-sponsored travel, I strongly > suspect that there'll be many more in my boat - indeed, it's substantially > worse for those of us not in continental north america anyway. > > Of course, you could change the criteria, but the real critieria which - I > assume - the NOMCOM consider how much to weigh an opinion is presumably on > some ethereal "participation level", which is exceedingly difficult to > measure. > > FWIW, the XMPP Standards Foundation has an actual membership, who do actual > voting. I'm deeply unconvinced it provides the best solution there, and I've > been successfully voted in to the XMPP Council twice. (Which may, of course, > be evidence of it not working at all, to some). > > Dave. > -- > Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net > - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ > - http://dave.cridland.net/ > Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade > -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Publicizing IETF nominee lists [Fwd: Last Call: draft-dawkins-nomcom-openlist (Nominating Committee Process: Open Disclosure of Willing Nominees) to BCP]
I was reading the Appeals court ruling in the VeriSign case last night and Michael Froomkin's paper on the anti-trust issues affecting ICANN. If you follow the logic of the Appeals court opinion it is highly unlikely that ICANN can remain a private organization. Since the administration already understands that ICANN is a liability, that only leaves the ITU. http://www.discourse.net/archives/2009/06/9th_cir_revives_com_antitrust_case.html One thing that struck me as a real risk is that similar concerns that may affect the IETF might have been ignored because of the people and the manner in which they were raised rather than on the merits. That does not make them any less of a liability. The current structures pretty much ensure that these issues only get raised by fringe elements. On Thu, Jun 11, 2009 at 6:20 AM, SM wrote: > Hi Phillip, > At 08:32 10-06-2009, Phillip Hallam-Baker wrote: >> >> A more useful change would be to abolish NOMCON and for those >> currently qualified to sit on NOMCON to elect the IAB and ADs >> directly. > > The implications of the above is much more than publicizing the IETF list of > nominees. The discussion of that document highlighted how a simple > statement like "we want an open list" is not as simple as it sounds. > >> Direct elections provide accountability and authority. Today we have > > Direct elections can also turn into a popularity contest. Instead of > democracy, we can end up with "mediacracy". > >> Instead of the outcome of proposals to change the standards process >> being 'the IESG didn't like them', we the broader membership[*] of the >> IETF can demand reasons and persons. And we can kick out the people >> who are being obstacles to change or proposing changes we disagree >> with. > > You can already ask for reasons. There's even a "face the participants" at > each IETF meeting where you can ask a question to the IAB, the IESG or a > particular member of the body. > > There will always be obstacles to change. There are advantages to having > these obstacles or else we end up with proposals that suit the whim of the > day. The is also room in the current process to kick out people. > >> Direct elections allow for contrarian views to enter into the >> discussions. The priority of successive NOMCONs has been to ensure > > Contrarian views can be labelled as the view of the fringe when they are > only shared by a small minority. And such views or the people holding then > will be cast away. > >> Yes, there is a risk of factions, but not a very large one. I am a >> member of the Oxford Union society and I know quite a bit about that >> type of politics. A Cisco or a Microsoft faction would be entirely >> counter-productive for the companies involved who come to the IETF to >> build industry support for adoption of their proposals and to be part >> of the consensus that emerges. The only type of faction that could be >> sustained long-term would be one committed to a particular technical >> principle such as preventing wiretap-friendly protocols or copyright >> enforcement schemes and only then if there was a sizable >> counter-faction or some group idiot enough to try to do that type of >> thing in IETF. > > Although a Cisco or Microsoft faction may be counter-productive, there will > be an incentive for factions to be formed as the proposed system provides an > environment conducive for that. In the new system, you'll also have to do > away with the notion of consensus. After all, that's not democratic. The > factions that will emerge in the long run are those that can use the system > to their advantage. When you have direct elections, you cannot aim for long > term goals as the people expect immediate results. Or else you won't stand > a chance when you put your name up for reelection. > >> We should try democracy. It is an old idea, seems to work. > > For some, yes. As someone on this mailing list put it, we are guided by our > interests. The new system will only amplify that. The rule of the majority > is only effective if there is participation. We only have to look at the > amount of participation in here to see that there will always be a silent > majority which only springs to life when a narrowly focused issue captures > their attention. > >> [*] Yes, we should demand consideration as citizens, not serfs. The >> pretense that the IETF has no members is very convenient for those >> appointed, not so great for the rest of us. > > You get the amount of consideration you deserve. If you behave like a serf, > you will be considered as one. :-) For the IETF to have members, it needs > to define a criteria for membership. This opens a debate about "currently > qualified to sit on NomCom". Most organizations that have adopted the > NomCom model have found it difficult to define a formal constituency and > devise an appropriate structure for it. You'll have to build in the check > and balances to keep the authority in check. > > Readers ar
Re: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
It is possible for people set their own roots, but it is not very practical to maintain them. And this is going to be particularly difficult if we ever get DNSSEC deployed in platform distributions and end-entities are configured to check their own DNS chains up to a baked-in ICANN root. It is not a sustainable model. Here is what I propose instead, it is a variation of ideas Carl Ellison and Phil Zimmerman have proposed in the past, it is thus entirely unencumbered: 1) There are multiple public signers for the apex zone signing key. These are moderately serious entities employing trustworthy hardware, secure facilities etc. They publish a CPS describing their practices. 2) Each relying party selects the subset of apex signers they are willing to trust and the conditions for accepting a signature. This may be 3 out of 5 or 4 out of 7 or anything the relying party decides. 3) Applications, Servers, etc. ship with default quorum conditions configured but these can be over-ridden. This has a number of interesting effects: 1) We have eliminated the incentive to default, not just placed controls that make it difficult to default. While an apex signatory can defect, they cannot profit unless they can persuade others to collude with them. Relying parties can make this rather unlikely by choosing apex signers that are entirely unlikely to collude (Cuba, France and the US). 2) Parties that feel that the US has too much influence in the DNS have something that they can do to counter that influence. Instead of sitting on the sidelines and throwing spanners into the works, the countries concerned about their sovereignty being infringed can start their own apex signatory authority. 3) The system can be stable over very long periods of years, centuries even, even if the apex signer authorities are not stable. This makes it viable for a corporation to be a signer. While it is most unlikely that Google will disappear in the next 5 years, any company can go bust over a course of decades, as GM and Chrysler are demonstrating. The same approach can be extended to support long term repositories of digital data. So imagine that we wanted to set up a long term repository of academic journal articles in electronic form. Most people who propose these things understand the necessity of physical duplication of the data storage, but not the need for failsafe design of the management institutions. On Wed, Jun 10, 2009 at 8:41 PM, Mark Andrews wrote: > > In message , Stephen Kent writes: >> Joe, >> >> You have argued that DNSSEC is not viable because it requires that >> everyone adopt IANA as the common root. > > Which isn't even a requirement. Alternate root providers just need > to get copy of the root zone with DS records and sign it with their > own DNSKEY records for the root. > > ISP's that choose to use alternate roots might get complaints however > from their customers if they are validating the answers using the > trust-anchors provided by IANA. This however should be seen as a > good thing as the ISP can no longer tamper with the DNS without > being detected. If a ISP can convince all their customers that the > alternate roots are a good thing then this won't become a issue. > >> I agree that under the >> current IANA management situation many folks may be uncomfortable >> with IANA as the root. However, in practice, the world has lived >> with IANA as the root for the non-secure version of DNS for a long >> time, so it's not clear that a singly-rooted DNSSEC is not viable >> based on this one concern. Moreover, DNSSEC is a form of PKI, an din >> ANY PKI, it is up to the relying parties to select the trust anchors >> they recognize. In a hierarchic system like DNS, the easiest >> approach is to adopt a single TA, the DNS root. But, it is still >> possible for a relying party to do more work and select multiple >> points as TAs. I would expect military organizations in various parts >> of the world to adopt a locally-managed TA store model for DNSSEC, to >> address this concern. However the vast majority of Internet users >> probably are best served by the single TA model. >> >> As for DNSCurve, I agree with the comments that several others have >> made, i.e., it doe snot provide the fundamental security one wants in >> DNS, i.e., an ability to verify the integrity and authenticity of >> records as attested to by authoritative domains, din the face of >> caching. >> >> >> Steve >> ___ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantum
Re: End to End Secure Protocols are bogus.
End to end ceases to have any value whatsoever once people attempt to codify it into a rigid ideology. Security does not respond at all well to ideological mandates. We have tried to deploy end-to-end solutions and failed. In many cases we could easily have succeeded if we had been less inflexible in the approach. You are not doing David any favors whatsoever here. He is not a dogmatic ideologue. The end-to-end paper was originally written when rigid ideologues such as yourself considered the telephone network to be the ultimate communications infrastructure. Above all, it is an argument against dogmatic approaches to system architecture. You are completely misrepresenting his work. On Wed, Jun 10, 2009 at 7:22 PM, Masataka Ohta wrote: > Phillip Hallam-Baker wrote: > >> I really see no value in debating whether DNSSEC is 'end to end'. > > Being end to end has practical benefits, which is why the Internet > has been so successful, which is why some people have been insisting > on a false statement that DNSSEC were secure end to end. > > For example, the following statement of you in another subthread: > >> The >> current design would establish the root key holder as the perpetual >> controller of the DNS. > > means DNSSEC involves the root key holder as a third party and not > end to end. > > Feel free to see no value on your statements. > >> Clearly DNSSEC is only one component in a security solution and >> whether it is 'end-to-end' depends on what you decide to call an >> endpoint. > > According to the terminology of David Clark, DNSSEC is not end > to end. > >> When Kaminsky discovered his cache poisoning vulnerability, some >> companies put out PR saying that the issue was already known, as if >> that made things better somehow. > > The issue is that the concept of "bailiwick" is broken, which > was already pointed out. > > Kaminsky's attack can be protected against by proper handling > of glue, without which DNSSEC cache can also be poisoned. > > Masataka Ohta > > > -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Publicizing IETF nominee lists [Fwd: Last Call: draft-dawkins-nomcom-openlist (Nominating Committee Process: Open Disclosure of Willing Nominees) to BCP]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bob Hinden wrote: > Joe, > >> 1) exposing the full list to the entire community invites lobbying the >> nomcom >> >> This probably already happens to some extent, but do >> we really want to encourage this? > > It's not clear this will lead to more lobbying than we have now. I > think lobbying happens a lot now and is driven by the candidate > him/herself, or the many people who get the "secret" lists. I think it > would be more balanced if everyone knew. If everyone knew, there would be more lobbying since there would be more people participating. I doubt the direct or secret-list lobbying would wane much as a result. > > I would add that the current system gives a greater ability to comment > on candidates to the leadership (IAB/IESG/WG Chairs) because they get > the many of the "secret" nomcom candidate lists. The nomcom might get > broader feedback if the lists are open. Yes, they might, but as I pointed out that's not the only effect. Joe -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKMWUfE5f5cImnZrsRAopTAJ9LzCputw2o+RomPkDcPMpyDfAJtwCfVITj +w7oZ/qhGo3xxQ7gs0YmOFw= =7Tg8 -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Publicizing IETF nominee lists [Fwd: Last Call: draft-dawkins-nomcom-openlist (Nominating Committee Process: Open Disclosure of Willing Nominees) to BCP]
Actually, that raises a very good point. At present the list is neither secret, nor public. Any bad effect from the list being public will occur, any bad effect from it being secret can occur. Right, it's a "secret" that many people know. Better to have it be public. Bob ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Publicizing IETF nominee lists [Fwd: Last Call: draft-dawkins-nomcom-openlist (Nominating Committee Process: Open Disclosure of Willing Nominees) to BCP]
Joe, 1) exposing the full list to the entire community invites lobbying the nomcom This probably already happens to some extent, but do we really want to encourage this? It's not clear this will lead to more lobbying than we have now. I think lobbying happens a lot now and is driven by the candidate him/ herself, or the many people who get the "secret" lists. I think it would be more balanced if everyone knew. I would add that the current system gives a greater ability to comment on candidates to the leadership (IAB/IESG/WG Chairs) because they get the many of the "secret" nomcom candidate lists. The nomcom might get broader feedback if the lists are open. Bob ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Publicizing IETF nominee lists [Fwd: Last Call: draft-dawkins-nomcom-openlist (Nominating Committee Process: Open Disclosure of Willing Nominees) to BCP]
At 10:51 AM +0200 6/11/09, Lars Eggert wrote: Content-Type: multipart/signed; boundary=Apple-Mail-5-115115602; micalg=sha1; protocol="application/pkcs7-signature" I agree with Sam and Jari. This is a good and overdue change. Lars I also agree with this proposal, based on several experiences serving on NOMCOM. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Publicizing IETF nominee lists [Fwd: Last Call: draft-dawkins-nomcom-openlist (Nominating Committee Process: Open Disclosure of Willing Nominees) to BCP]
At 03:32 11-06-2009, Melinda Shore wrote: worth a shot. Enough people feel the current process isn't working to suggest that the current process really isn't working. It suggests that there is a perception that the current process isn't working. At 04:51 11-06-2009, Phillip Hallam-Baker wrote: One thing that struck me as a real risk is that similar concerns that may affect the IETF might have been ignored because of the people and the manner in which they were raised rather than on the merits. That does not make them any less of a liability. I don't know whether there is risk or not. It's not the manner or the people that raised the concerns that matters (to me). The current structures pretty much ensure that these issues only get raised by fringe elements. I won't qualify people who raise such issues as fringe elements. I believe that they are an important, and somewhat overlooked, part of the process. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Publicizing IETF nominee lists [Fwd: Last Call: draft-dawkins-nomcom-openlist (Nominating Committee Process: Open Disclosure of Willing Nominees) to BCP]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Phillip Hallam-Baker wrote: > The deliberative process of NOMCON means that it is more likely that > consensus will be reached on the candidates that fewest people object > to rather than those that have the strongest support. Deliberation means that weak objections are as likely to be influenced by discussions by strong supporters. I.e., deliberation can just as easily contributes to amplification of strong support, rather than suppression of it. Tuning the process is fine, but let's not be deluded into thinking it will be any better than "flawed, but sufficient". Selectees don't need to be (further) encouraged they've been anointed by some perfect process. We should be considering Nomcom's primary role in making the shortlist, i.e., in making a threshold. Frankly, the community would be better served IMO by selecting from among the shortlist using the same (random) process used in selecting the Nomcom. Joe > On Thu, Jun 11, 2009 at 11:32 AM, Joe Touch wrote: > > > Melinda Shore wrote: SM wrote: > Hi Phillip, > At 08:32 10-06-2009, Phillip Hallam-Baker wrote: >> A more useful change would be to abolish NOMCON and for those >> currently qualified to sit on NOMCON to elect the IAB and ADs >> directly. > The implications of the above is much more than publicizing the IETF > list of nominees. The discussion of that document highlighted how a > simple statement like "we want an open list" is not as simple as it > sounds. Indeed. Having elections means determining who's eligible to vote, and that has all kinds of cascading consequences. > We already have that. The only difference is that: > > - voters are selected randomly from among those not "running for office" > > - voters are required to participate in interviews and meetings, which > may make them more informed > > In the end, though, all voting systems are popularity contests. > > Joe >> -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoxKdgACgkQE5f5cImnZrvNiACgqYFrs7rSkSFg7DdAHZ7SY0Rq gNgAoOWKOmxP1fgE0hD8ob2PGc+0h/OY =ZJ9H -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Publicizing IETF nominee lists [Fwd: Last Call: draft-dawkins-nomcom-openlist (Nominating Committee Process: Open Disclosure of Willing Nominees) to BCP]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I am concerned about this development for several reasons: 1) exposing the full list to the entire community invites lobbying the nomcom This probably already happens to some extent, but do we really want to encourage this? 2) exposing the willing participation of individuals for certain position could be a disincentive E.g., consider someone whose current employer won't/can't support the level of commitment required for a position, and that a new employer has agreed to hire them - either contingent on the position or just at some point in the future so that they can accept the position if appointed. Exposing this list could expose intentions to shift employers, which would be a disincentive to some. If the Nomcom cannot make this decision without wide community input (which I tend to agree with), then we either need open lists with open elections or we need closed lists with closed elections. I do not see utility in mixing the two. Joe Leslie Daigle wrote: > > I know Spencer has brought one item of discussion from this last call to > the general IETF mailing list, but I'd like to draw attention to the > whole document, which, if passed, will make a significant change in IETF > practice: the lists of willing nominees for IETF positions will be > published publicly. > > This has been discussed on the ietf-nomcom list: > >> ___ >> ietf-nomcom mailing list >> ietf-nom...@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-nomcom > > > So, if you're interested, check out the mailing list archives to see how > potential issues were discussed. > > Leslie. > > Original Message > Subject: Last Call: draft-dawkins-nomcom-openlist (Nominating > Committee Process: Open Disclosure of Willing Nominees) to BCP > Date: Fri, 5 Jun 2009 16:45:11 -0700 (PDT) > From: The IESG > Reply-To: ietf@ietf.org > To: IETF-Announce > > The IESG has received a request from an individual submitter to consider > the following document: > > - 'Nominating Committee Process: Open Disclosure of Willing Nominees ' > as a BCP > > 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 2009-07-03. 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. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-dawkins-nomcom-openlist-04.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18213&rfc_flag=0 > > > ___ > IETF-Announce mailing list > ietf-annou...@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoxJSUACgkQE5f5cImnZruvlQCeM371Wb3S4csZaht0aWMVVEHh VrgAn0itTIPxA7wqEHHl81zmCq0307ql =cLQ8 -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Publicizing IETF nominee lists [Fwd: Last Call: draft-dawkins-nomcom-openlist (Nominating Committee Process: Open Disclosure of Willing Nominees) to BCP]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Melinda Shore wrote: > SM wrote: >> Hi Phillip, >> At 08:32 10-06-2009, Phillip Hallam-Baker wrote: >>> A more useful change would be to abolish NOMCON and for those >>> currently qualified to sit on NOMCON to elect the IAB and ADs >>> directly. >> The implications of the above is much more than publicizing the IETF >> list of nominees. The discussion of that document highlighted how a >> simple statement like "we want an open list" is not as simple as it >> sounds. > > Indeed. Having elections means determining who's > eligible to vote, and that has all kinds of cascading > consequences. We already have that. The only difference is that: - - voters are selected randomly from among those not "running for office" - - voters are required to participate in interviews and meetings, which may make them more informed In the end, though, all voting systems are popularity contests. Joe -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoxI5wACgkQE5f5cImnZrtsvwCfduYzOIzSe5WBKPMW7Faiw48v VMsAoKZlZRGzIsPhwj9NIJt2FfjjNM3O =eV6t -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Publicizing IETF nominee lists [Fwd: Last Call: draft-dawkins-nomcom-openlist (Nominating Committee Process: Open Disclosure of Willing Nominees) to BCP]
On Thu, Jun 11, 2009 at 10:34:08AM -0400, Phillip Hallam-Baker wrote: > The idea that we would not want to return to the current system sounds > like an argument against the status quo, rather than in favor of it. Again, I don't have an opinion on the draft one way or the other, but the above strikes me as relying on an equivocation. That "we" does not obviously pick out the same group across the time we're talking about. If some people who would otherwise be engaged stop participating because of discomfort with a more political campaign-style leadership process, then the people who will make the rules in the later stage are not the same ones as those who will be adopting this change. Moreover, those who dislike those political campaign-style processes are unlikely to participate in one when it is required in order to change the rules, so even if they stick around they're unlikely to have much influence in an effort to undo the change we're contemplating. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IAB] I-D ACTION:draft-iab-mpls-tp-uncoord-harmful-00.txt
Dave,Indeed, I second Russ' request. That sort of positive example / success story would help the current interactions around MPLS, and this document a lot. Gregory. On Thu, Jun 11, 2009 at 7:31 AM, Russ Housley wrote: > Dave: > > Can you offer a paragraph or so of text to go with the list of documents? > Are there any lessons learned or principles that need to be added to the > list based on the this experience? > > Russ > > > > At 02:59 PM 6/10/2009, Dave CROCKER wrote: > > > internet-dra...@ietf.org wrote: >> >>> In particular, this was >>> achieved via the establishment of the "Joint working team on MPLS-TP" >>> which was the first ever joint ITU/IETF group. >>> >> >> >> How quickly we forget: >> >> ITU's T.37 and IETF's: >> >> RFC4142 - Full-mode Fax Profile for Internet Mail (FFPIM) >> RFC3950 - Tag Image File Format Fax eXtended (TIFF-FX) - >> image/tiff-fx MIME Sub-type Registration >> RFC3949 - File Format for Internet Fax >> RFC3192 - Minimal FAX address format in Internet Mail >> RFC3249 - Implementers Guide for Facsimile Using Internet Mail >> RFC3192 - Minimal FAX address format in Internet Mail >> RFC2880 - Internet Fax T.30 Feature Mapping >> RFC2879 - Content Feature Schema for Internet Fax (V2) >> RFC2542 - Terminology and Goals for Internet Fax >> RFC2534 - Media Features for Display, Print, and Fax >> RFC2532 - Extended Facsimile Using Internet Mail >> RFC2531 - Content Feature Schema for Internet Fax >> RFC2304 - Minimal FAX address format in Internet Mail >> RFC2301 - File Format for Internet Fax >> >> were the result of an 8-year closely cooperative relationship between the >> two groups. >> >> But it had an extremely rocky start that required careful negotiation to >> resolve. >> >> d. >> >> -- >> >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >> > > -- IETF related email from Gregory M. Lebovitz Juniper Networks ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IAB] I-D ACTION:draft-iab-mpls-tp-uncoord-harmful-00.txt
Dave: Can you offer a paragraph or so of text to go with the list of documents? Are there any lessons learned or principles that need to be added to the list based on the this experience? Russ At 02:59 PM 6/10/2009, Dave CROCKER wrote: internet-dra...@ietf.org wrote: In particular, this was achieved via the establishment of the "Joint working team on MPLS-TP" which was the first ever joint ITU/IETF group. How quickly we forget: ITU's T.37 and IETF's: RFC4142 - Full-mode Fax Profile for Internet Mail (FFPIM) RFC3950 - Tag Image File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type Registration RFC3949 - File Format for Internet Fax RFC3192 - Minimal FAX address format in Internet Mail RFC3249 - Implementers Guide for Facsimile Using Internet Mail RFC3192 - Minimal FAX address format in Internet Mail RFC2880 - Internet Fax T.30 Feature Mapping RFC2879 - Content Feature Schema for Internet Fax (V2) RFC2542 - Terminology and Goals for Internet Fax RFC2534 - Media Features for Display, Print, and Fax RFC2532 - Extended Facsimile Using Internet Mail RFC2531 - Content Feature Schema for Internet Fax RFC2304 - Minimal FAX address format in Internet Mail RFC2301 - File Format for Internet Fax were the result of an 8-year closely cooperative relationship between the two groups. But it had an extremely rocky start that required careful negotiation to resolve. d. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
Phil, That's a specious argument. As several others have noted on this list, it's perfectly feasible for any relying parties (sovereign nations or otherwise) to not use the IANA root, simply by creating their own root. This is a little more complicated than just redirecting IP traffic, but not by much. To quote from Mark's earlier message: Mark Andrews wrote: > Stephen Kent writes: >> >> You have argued that DNSSEC is not viable because it requires that >> everyone adopt IANA as the common root. > > Which isn't even a requirement. Alternate root providers just need > to get copy of the root zone with DS records and sign it with their > own DNSKEY records for the root. --Richard Phillip Hallam-Baker wrote: Steve, The sovereign nations that object to US control of the root are willing to accept the current status quo preciely because they have an exit option. Should the US defect on its obligations and order ICANN to drop Cuba or Palestine out of the root or to take any other action that was considered to be abusive, the countries that objected could simply direct their local ISPs to redirect all IP traffic to the A thru M root servers to another set of servers of their choice. At the moment the ICANN has the theoretical ability to defect, but can only do so at the cost of becomming irrelevant. The global DNS outside the US would swiftly pass to the ITU. With the proposed root arrangement for DNSSEC, this changes. Not only does the US have effective control, it has perpetual control of any apparatus that chains to the ICANN root of trust. This is bad for the US, bad for ICANN and bad for other sovereign states. First, consider the likely source of a defection, some idiot member of Congress from Florida grandstanding for votes. Such a move is going to give the career civil service a fit, particularly the diplomats who prefer to end rather than begin international crises. I have spoken to very enior members of this administration on this topic, they had come to the exact same conclusion themselves. Now consider ICANN. Let us imagine that they do hold the master root key. What is then to stop some armed terrorist nut cases laying siege to the key repository? Their objective might not be to drop a country out, they might want to insert some irredentist domain of their own. Ordinary PKIs are not subject to this type of pressure, because they are not the lynchpin of the global communication system. While the various splinter-roots may appear to be complete jokes, they have had one significant result, they have drawn attention to the issue. In particular very much doubt that the Turkish secret service are too amused at the whole process given some of their experiences. On Wed, Jun 10, 2009 at 1:11 PM, Stephen Kent wrote: Joe, You have argued that DNSSEC is not viable because it requires that everyone adopt IANA as the common root. I agree that under the current IANA management situation many folks may be uncomfortable with IANA as the root. However, in practice, the world has lived with IANA as the root for the non-secure version of DNS for a long time, so it's not clear that a singly-rooted DNSSEC is not viable based on this one concern. Moreover, DNSSEC is a form of PKI, an din ANY PKI, it is up to the relying parties to select the trust anchors they recognize. In a hierarchic system like DNS, the easiest approach is to adopt a single TA, the DNS root. But, it is still possible for a relying party to do more work and select multiple points as TAs. I would expect military organizations in various parts of the world to adopt a locally-managed TA store model for DNSSEC, to address this concern. However the vast majority of Internet users probably are best served by the single TA model. As for DNSCurve, I agree with the comments that several others have made, i.e., it doe snot provide the fundamental security one wants in DNS, i.e., an ability to verify the integrity and authenticity of records as attested to by authoritative domains, din the face of caching. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Publicizing IETF nominee lists [Fwd: Last Call: draft-dawkins-nomcom-openlist (Nominating Committee Process: Open Disclosure of Willing Nominees) to BCP]
On Thu Jun 11 13:21:22 2009, Phillip Hallam-Baker wrote: And why did XMPP leave IETF process in the first place? And have you stopped beating your wife yet? The XSF never followed the IETF process in the first place, and therefore could not leave it - I doubt many of the formers were aware of the Nomcom process when the Jabber Software Foundation, as it was then, was formed. After all, it was formed in August 2001, and the Jabber BOF wasn't until about a year later. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
At 10:41 AM +1000 6/11/09, Mark Andrews wrote: In message , Stephen Kent writes: Joe, You have argued that DNSSEC is not viable because it requires that everyone adopt IANA as the common root. Which isn't even a requirement. Alternate root providers just need to get copy of the root zone with DS records and sign it with their own DNSKEY records for the root. ISP's that choose to use alternate roots might get complaints however from their customers if they are validating the answers using the trust-anchors provided by IANA. This however should be seen as a good thing as the ISP can no longer tamper with the DNS without being detected. If a ISP can convince all their customers that the alternate roots are a good thing then this won't become a issue. Fair point, although I think we all want to avoid the sort of Balkionization that this suggests. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: opsdir review of draft-green-secsh-ecc-08
Hi Douglas, For the most part, I really like the new security considerations section in 09. I found it far more enlightening (and even interesting). Thanks. I usually look for security considerations in a form that points out the threats and how they are mitigated (or can be mitigated by configuration decisions). I do not insist on this form; but I think it makes it easier for people to understand. For the most part, your new section does this well. You may be more detailed than is necessary in the security considerations. I am not quite sure who the target audience is for this draft - SSH operators/users or crypto developers implementing support for this cipher suite. probably both. Your discussion is probably way more detailed than needed for most operators and users and programmers, but possibly right for crypto implementers. Paragraph 3 in the security considerations discusses prime, and characteristic 2, and composite. I don't know what these mean, except the prime (which I assume is the mathematical prime). I can live with not understanding these terms, but I am not sure of the implications of the last sentence. "All of the RECOMMENDED curves of characteristic 2 in section 10 have prime m." As I read this paragraph, am I correct in believing that the next to last sentence states the threat (susceptible to attack by the Weil descent), and the last sentence says the prime m mitigates that attack? If so, it would help to append to the last sentence ", which helps to protect against such attack." or something similar. For operators deploying this in today's networks, I am pretty sure the discussion of quantum computers is not really relevant, but it is interesting ;-) No complaint; just an observation. In paragraph 6, I think the "As such," is unnecessary (and I found it slightly distracting that it was there, because unnecessary introductory phrases are a pet peeve for me). I found paragraph 10 hard to understand. "strong security at the security levels indicated" seems a bit convoluted. Is there a better way to express what you mean? When you say "in this section", are you referring to the security considerations section? -- Manageability We are actively working to decide what should be said in documents about manageability. Adrian's draft was a good place to start. The opsawg has a draft on operations and management (by me) that might have some additional guidelines that hopefully would be helpful. For the most part, I am happy with the new management considerations, and think they are sufficient to satisfy my review comments. I have some additional questions that you might consider discussing, and a few minor edits. section 8 looks good. In section 8.1, I think this would be better expressed as "Implementers should allow administrators to disable some curves, including some REQUIRED or RECOMMENDED curves, to meet local security policy." The initial setup and installation presumably will be done using normal SSH config methods. Are there any ECC-specific parameters that must be configured? Are there specific parameters that should not be disclosed in a config file? Are there defaults that would be useful to help ensure interoperability (or have you already discussed all the necessary defaults when you discuss specific ciphers? For administartively-configurable parameters, are there any that must be preserved across reboots? others that do not? section 8.2 looks good. Is ECC computationally expensive? Could that impact SSH performance, for example? Are there any fault or threshold conditions for ECC processing? If they occur, is this something the operator should be informed of, e.g. via syslog, or are all ECC fault and threshold conditions already dealt with within the SSH fault and threshold handling mechanisms? ECC is susceptible to certain types of attacks. Can an implementation detect such attacks (without significant computational impact)? Are there anomalous patterns that can be discerned? If so, would it be useful to have a counter in the system's management interface to count specific anomalies, so an operator or an IDS could monitor the counter(s) and raise an alarm if the system might be under attack? Good job, Thanks. > -Original Message- > From: Douglas Stebila [mailto:doug...@stebila.ca] > Sent: Thursday, June 11, 2009 7:57 AM > To: ietf...@comcast.net > Subject: Re: opsdir review of draft-green-secsh-ecc-08 > > Hi David, > > Thanks for the extensive review. I am attaching a proposed revision > of the draft to address your concerns about the manageability > considerations and security considerations sections. The security > considerations section has been substantially rewritten to, I hope, > provide a more self-contained analysis of the security issues > at play > when using elliptic curve cryptography. I was unable to find many > examples of manageability considerations sections (I worked off of > draft-ietf-pce-manageability-requirement
Re: Publicizing IETF nominee lists [Fwd: Last Call:draft-dawkins-nomcom-openlist(Nominating Committee Process: Open Disclosure of Willing Nominees) toBCP]
Doug Ewell wrote: It's a safe bet that the FSF people who show up on this list once or twice a year to "vote" on a proposal that they have been told to "vote" on, would also show up at election time to vote for or against candidates according to what they have been told. Not if they're ineligible. At any rate there's no serious proposal right now to choose I-people through direct voting, so we're heading down a rabbit hole. I think a more immediate question is whether or not publishing the names of candidates will tend to lead to election-like behavior. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Publicizing IETF nominee lists [Fwd: Last Call:draft-dawkins-nomcom-openlist(Nominating Committee Process: Open Disclosure of Willing Nominees) toBCP]
Melinda Shore wrote: Indeed. Having elections means determining who's eligible to vote, and that has all kinds of cascading consequences. It's a safe bet that the FSF people who show up on this list once or twice a year to "vote" on a proposal that they have been told to "vote" on, would also show up at election time to vote for or against candidates according to what they have been told. That's not democracy, and in order to prevent it, you have to establish full formal membership policies. -- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Publicizing IETF nominee lists [Fwd: Last Call: draft-dawkins-nomcom-openlist (Nominating Committee Process: Open Disclosure of Willing Nominees) to BCP]
On Thu, Jun 11, 2009 at 06:32:56AM -0400, Melinda Shore wrote: > worth a shot. If MonsterCorp starts larding up the > leadership with their own employees or it turns into > a popularity contest it can be undone, I doubt that it can be undone once done. Any attempt to undo will be decried as an attempt to hide something, move things into smoky back rooms, &c. That will be especially true if it turns out that companies who want to put resources into "getting people on the IESG" (or whatever) are successful: they'll be able to use the same resources to oppose changes that will undo that advantage. This isn't to say it's a bad idea (I haven't formed an opinion), but I do think the move towards publicising these candidacies is a one-way door. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Voting (Re: Publicizing IETF nominee lists)
Phillip Hallam-Baker wrote: On Thu, Jun 11, 2009 at 6:58 AM, Harald Alvestrand wrote: Voting has all kinds of issues. Precisely the type of vague, non reason that I was complaining about. Consider the last ten years of yelling to be included by reference. I like the current Nomcom process because it depends on 2 things: - A pool of qualified volunteers - Luck in picking a nomcom that behaves sensibly (for whatever that means to you) Given that luck is involved, many of the possible attacks that people could mount in order to gain more IETF influence won't happen - simply because they have a significant chance of failure. Trying, failing, and being detected as having tried, would be harmful to the group that tried it. The last time I was aware of anything like that happening in any standards group was when XrML was killed in OASIS, but the issue there was people opposed to DRM, not a company driven thing. Where companies want to tilt the playing field they usually have to start the organization to succeed. Or get in early like the XRI folk did with OpenID. And fat lot of good it did them. As a former corporate rep, I can assure you that there is precisely zero value in gaining the imprimatur of the IETF (or OASIS or W3C for that matter) if you short circuit the process. The point of standards participation is to get buy in from other parties you need to build common infrastructure. Sure. That's why Microsoft spent so much resource (and credibility) making sure the OOXML vote went through; they did not gain anything of value. Or perhaps the value proposition is different for ISO than for the IETF. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-dawkins-nomcom-openlist (Nominating Committee Process: Open Disclosure of Willing Nominees) to BCP
I support changing these to "must". We don't of course have any mechanisms to enforce this (especially discussions by other IETF community members on non-IETF mailing lists)... but currently, asking people to treat nominee lists *as if* they were confidential (even though they were not) has had the effect of preventing public discussions about the candidates (on e.g. ietf@ietf.org mailing list). I don't think such discussions would be helpful for the goals of the NomCom process (or the IETF in general), and I think the document should send a clear message that they're not acceptable in the future either (instead of leaving wiggle room that they might be OK in some circumstances). Best regards, Pasi > -Original Message- > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of > ext Spencer Dawkins > Sent: 09 June, 2009 23:33 > To: ietf@ietf.org > Cc: brian.e.carpen...@gmail.com > Subject: Fw: Last Call: draft-dawkins-nomcom-openlist (Nominating > Committee Process: Open Disclosure of Willing Nominees) to BCP > > Brian Carpenter had a Last Call comment that I needed to follow up > on... > > > > Hi, > > > > (IETF list not copied as I'm on leave and minimising email, but > > there is nothing confidential about this comment.) > > > >> Feedback on nominees should always be provided privately to > >> NomCom. Nominees should not solicit support, and other IETF > >> community members should not post statements of support/ > >> non-support for nominees in any public forum. > > > > I believe these three occurrences of 'should' need to be 'must'. > > I don't think there should be any wiggle room on this point. > > > >Brian > > Russ thinks I should check on this with the rest of the community, so > I'm > asking for feedback now. > > Thanks, > > Spencer > > > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Publicizing IETF nominee lists [Fwd: Last Call: draft-dawkins-nomcom-openlist (Nominating Committee Process: Open Disclosure of Willing Nominees) to BCP]
On Wed Jun 10 16:32:37 2009, Phillip Hallam-Baker wrote: A more useful change would be to abolish NOMCON and for those currently qualified to sit on NOMCON to elect the IAB and ADs directly. A complete disaster for me, at least, since I - along with a substantial number of reasonably active and involved IETF participants - am no qualified to sit on NOMCOM. With the current state of affairs, I can still ensure my voice is heard by NOMCOM, whereas with direct voting, I could not. Given the current climate, and particularly how it affects corporate-sponsored travel, I strongly suspect that there'll be many more in my boat - indeed, it's substantially worse for those of us not in continental north america anyway. Of course, you could change the criteria, but the real critieria which - I assume - the NOMCOM consider how much to weigh an opinion is presumably on some ethereal "participation level", which is exceedingly difficult to measure. FWIW, the XMPP Standards Foundation has an actual membership, who do actual voting. I'm deeply unconvinced it provides the best solution there, and I've been successfully voted in to the XMPP Council twice. (Which may, of course, be evidence of it not working at all, to some). Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fw: Last Call: draft-dawkins-nomcom-openlist (Nominating Committee Process: Open Disclosure of Willing Nominees) to BCP
I support the use of "should". Spencer Dawkins wrote: Brian Carpenter had a Last Call comment that I needed to follow up on... Hi, (IETF list not copied as I'm on leave and minimising email, but there is nothing confidential about this comment.) Feedback on nominees should always be provided privately to NomCom. Nominees should not solicit support, and other IETF community members should not post statements of support/ non-support for nominees in any public forum. I believe these three occurrences of 'should' need to be 'must'. I don't think there should be any wiggle room on this point. Brian Russ thinks I should check on this with the rest of the community, so I'm asking for feedback now. Thanks, Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Voting (Re: Publicizing IETF nominee lists)
Voting has all kinds of issues. I like the current Nomcom process because it depends on 2 things: - A pool of qualified volunteers - Luck in picking a nomcom that behaves sensibly (for whatever that means to you) Given that luck is involved, many of the possible attacks that people could mount in order to gain more IETF influence won't happen - simply because they have a significant chance of failure. Trying, failing, and being detected as having tried, would be harmful to the group that tried it. Besides, knowing that the IETF fundamentally depends on luck gives me a good feeling when the pomposity gets too overwhelming :-) Phillip Hallam-Baker wrote: This is a useful and necessary change. A more useful change would be to abolish NOMCON and for those currently qualified to sit on NOMCON to elect the IAB and ADs directly. Direct elections provide accountability and authority. Today we have an Internet Architecture Board that stopped trying to do architecture after the Kobe revolt. That is a problem because the architecture is not a static property, without direction it degrades over time. Instead of the outcome of proposals to change the standards process being 'the IESG didn't like them', we the broader membership[*] of the IETF can demand reasons and persons. And we can kick out the people who are being obstacles to change or proposing changes we disagree with. Direct elections allow for contrarian views to enter into the discussions. The priority of successive NOMCONs has been to ensure that the members of the IAB get along and to keep out anyone who might rock the boat. As a result the only members of the awkward squad who get appointed are the ones who are committed to defending the status quo at all costs, not the people who point out what is not working. Yes, there is a risk of factions, but not a very large one. I am a member of the Oxford Union society and I know quite a bit about that type of politics. A Cisco or a Microsoft faction would be entirely counter-productive for the companies involved who come to the IETF to build industry support for adoption of their proposals and to be part of the consensus that emerges. The only type of faction that could be sustained long-term would be one committed to a particular technical principle such as preventing wiretap-friendly protocols or copyright enforcement schemes and only then if there was a sizable counter-faction or some group idiot enough to try to do that type of thing in IETF. We should try democracy. It is an old idea, seems to work. [*] Yes, we should demand consideration as citizens, not serfs. The pretense that the IETF has no members is very convenient for those appointed, not so great for the rest of us. On Wed, Jun 10, 2009 at 10:11 AM, Sam Hartman wrote: Thanks for bringing this to our attention. Having reviewed the draft, I support publication of this document as a BCP. I think it is a long-needed change. I understand that there are important tradeoffs involved, and while I acknowledge that there are disadvantages to this change, I think that it is a significant net good. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Publicizing IETF nominee lists [Fwd: Last Call: draft-dawkins-nomcom-openlist (Nominating Committee Process: Open Disclosure of Willing Nominees) to BCP]
SM wrote: Hi Phillip, At 08:32 10-06-2009, Phillip Hallam-Baker wrote: A more useful change would be to abolish NOMCON and for those currently qualified to sit on NOMCON to elect the IAB and ADs directly. The implications of the above is much more than publicizing the IETF list of nominees. The discussion of that document highlighted how a simple statement like "we want an open list" is not as simple as it sounds. Indeed. Having elections means determining who's eligible to vote, and that has all kinds of cascading consequences. A kind of funny one is that it could provide incentives to attend meetings, which isn't necessarily good (in the past there have been instances of companies wanting very much to get one of their employees on the IESG or IAB). I'm not that crazy about publicizing nominations, for the reasons you mention, but the pressure's been on for a number of years to do it and it may be worth a shot. If MonsterCorp starts larding up the leadership with their own employees or it turns into a popularity contest it can be undone, but it may be worth a shot. Enough people feel the current process isn't working to suggest that the current process really isn't working. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Publicizing IETF nominee lists [Fwd: Last Call: draft-dawkins-nomcom-openlist (Nominating Committee Process: Open Disclosure of Willing Nominees) to BCP]
Hi Phillip, At 08:32 10-06-2009, Phillip Hallam-Baker wrote: A more useful change would be to abolish NOMCON and for those currently qualified to sit on NOMCON to elect the IAB and ADs directly. The implications of the above is much more than publicizing the IETF list of nominees. The discussion of that document highlighted how a simple statement like "we want an open list" is not as simple as it sounds. Direct elections provide accountability and authority. Today we have Direct elections can also turn into a popularity contest. Instead of democracy, we can end up with "mediacracy". Instead of the outcome of proposals to change the standards process being 'the IESG didn't like them', we the broader membership[*] of the IETF can demand reasons and persons. And we can kick out the people who are being obstacles to change or proposing changes we disagree with. You can already ask for reasons. There's even a "face the participants" at each IETF meeting where you can ask a question to the IAB, the IESG or a particular member of the body. There will always be obstacles to change. There are advantages to having these obstacles or else we end up with proposals that suit the whim of the day. The is also room in the current process to kick out people. Direct elections allow for contrarian views to enter into the discussions. The priority of successive NOMCONs has been to ensure Contrarian views can be labelled as the view of the fringe when they are only shared by a small minority. And such views or the people holding then will be cast away. Yes, there is a risk of factions, but not a very large one. I am a member of the Oxford Union society and I know quite a bit about that type of politics. A Cisco or a Microsoft faction would be entirely counter-productive for the companies involved who come to the IETF to build industry support for adoption of their proposals and to be part of the consensus that emerges. The only type of faction that could be sustained long-term would be one committed to a particular technical principle such as preventing wiretap-friendly protocols or copyright enforcement schemes and only then if there was a sizable counter-faction or some group idiot enough to try to do that type of thing in IETF. Although a Cisco or Microsoft faction may be counter-productive, there will be an incentive for factions to be formed as the proposed system provides an environment conducive for that. In the new system, you'll also have to do away with the notion of consensus. After all, that's not democratic. The factions that will emerge in the long run are those that can use the system to their advantage. When you have direct elections, you cannot aim for long term goals as the people expect immediate results. Or else you won't stand a chance when you put your name up for reelection. We should try democracy. It is an old idea, seems to work. For some, yes. As someone on this mailing list put it, we are guided by our interests. The new system will only amplify that. The rule of the majority is only effective if there is participation. We only have to look at the amount of participation in here to see that there will always be a silent majority which only springs to life when a narrowly focused issue captures their attention. [*] Yes, we should demand consideration as citizens, not serfs. The pretense that the IETF has no members is very convenient for those appointed, not so great for the rest of us. You get the amount of consideration you deserve. If you behave like a serf, you will be considered as one. :-) For the IETF to have members, it needs to define a criteria for membership. This opens a debate about "currently qualified to sit on NomCom". Most organizations that have adopted the NomCom model have found it difficult to define a formal constituency and devise an appropriate structure for it. You'll have to build in the check and balances to keep the authority in check. Readers are cautioned not to draw any conclusions from the information below without a thorough analysis. The following is a distribution by company: RFC authors Attendance Cisco 12%6% Ericsson 3%3% Microsoft 2%2% Nokia 2%2% Juniper2%3% Nortel 2%1% IBM2%0% NTT2%2% One or more companies might have a significant advantage in a membership-based organization. There may even be an increase in membership as the economic factors favor some companies. There would be pressure to change the model from individuals to corporate. I don't think that the current model is perfect. If you want to rock the boat, I'm all for it. But before you do that, I'd like to have some assurance that the boat won't sink. :-) Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listi
Re: Publicizing IETF nominee lists [Fwd: Last Call: draft-dawkins-nomcom-openlist (Nominating Committee Process: Open Disclosure of Willing Nominees) to BCP]
I agree with Sam and Jari. This is a good and overdue change. Lars On 2009-6-10, at 17:21, Jari Arkko wrote: I also support the publication of this document (modulo some nits that were discussed earlier). Yes, there are trade-offs. But having observed the process from various sides over the years, I do I believe adopting the more open model is the right thing to do. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
