Re: ARIN / RIR Pragmatism (WAS: Re: RADB)
john To what extent is the ROA growth rate in the RIPE region (on page 5 of the NANOG slides) enabled by the IRR practices of that region? check out slide 3, lacnic has a 20% adoption rate. both ripe and lacnic have put energy into their own systems, educating users, ... ripe's curve would not seem to show correlation with recent liberalization of policy, but i doubt it is wise to twy to squeeze cause out of curves. I do recognize that there are issues (as Wes nicely identified in Baltimore and which we'll be working on) that get in the way of RPKI deployment in the ARIN region, but those issues are not present other non-RIPE regions - yet the number actual ROA's issued still appears to be rather low... 20% coverage in lacnic low? how do ipv6 and dnssec compare (which is damned sad)? over 2,000 in ripe and over 8%? how does that compare to ipv6? arin, 388 and 0.7%, a joke. slide 5 It’s What Happens When You Let Lawyers and Wannabe Regulators Run the Internet i really loved the arin ac guy i met in baltimore who did not think having arin meet at nanog was good because those operators just did not get how to regulate the internet. you've been captured by the tea party. randy
Re: ARIN / RIR Pragmatism (WAS: Re: RADB)
On Oct 26, 2014, at 6:46 AM, Randy Bush ra...@psg.com wrote: 20% coverage in lacnic low? how do ipv6 and dnssec compare (which is damned sad)? over 2,000 in ripe and over 8%? how does that compare to ipv6? arin, 388 and 0.7%, a joke. LACNIC numbers (as a percent) are quite good, but my question was why only RIPE has the very impressive total count of ROAs. You can clearly point to ARIN's legal treatment of the risks involved, but that is not applicable in the APNIC case You don't feel there's any correlation between RIPE's IRR approach and their RPKI success? /John John Curran President and CEO ARIN
Re: ARIN / RIR Pragmatism (WAS: Re: RADB)
it's just a consequence that our initial idea was just about to protect allocations of our members - not about secure routing at all On 26 Oct 2014, at 14:40, John Curran jcur...@arin.net wrote: On Oct 26, 2014, at 6:46 AM, Randy Bush ra...@psg.com wrote: 20% coverage in lacnic low? how do ipv6 and dnssec compare (which is damned sad)? over 2,000 in ripe and over 8%? how does that compare to ipv6? arin, 388 and 0.7%, a joke. LACNIC numbers (as a percent) are quite good, but my question was why only RIPE has the very impressive total count of ROAs. You can clearly point to ARIN's legal treatment of the risks involved, but that is not applicable in the APNIC case You don't feel there's any correlation between RIPE's IRR approach and their RPKI success? /John John Curran President and CEO ARIN
Re: ARIN / RIR Pragmatism (WAS: Re: RADB)
John - it is not about RPK I - our initial goal was to deploy some kind of certification to resources allocated to our members Dmitry If we use for it some SIDR developments - may be - it is a mistake or misentrepration - but what's true that we never thougy On 26 Oct 2014, at 14:40, John Curran jcur...@arin.net wrote: On Oct 26, 2014, at 6:46 AM, Randy Bush ra...@psg.com wrote: 20% coverage in lacnic low? how do ipv6 and dnssec compare (which is damned sad)? over 2,000 in ripe and over 8%? how does that compare to ipv6? arin, 388 and 0.7%, a joke. LACNIC numbers (as a percent) are quite good, but my question was why only RIPE has the very impressive total count of ROAs. You can clearly point to ARIN's legal treatment of the risks involved, but that is not applicable in the APNIC case You don't feel there's any correlation between RIPE's IRR approach and their RPKI success? /John John Curran President and CEO ARIN
Re: pay.gov and IPv6
On Sat, Oct 25, 2014 at 10:26 AM, Matthew Kaufman matt...@matthew.at wrote: Random IPv6 complaint of the day: redirects from FCC.gov to pay.gov fail when clients have IPv6 enabled. Work fine if IPv6 is off. One more set of Still broken, 7 months later. And again, I was too busy trying to pay to try to pull a full set of logs. But if you do something on the FCC site that requires payment, the redirection flow dies halfway through if you're coming from IPv6 and works fine if you turn it off... so yet another computer in the house has IPv6 disabled until manually turned back on. FWIW, eftps.gov is also unreachable via ipv6. I tried all of miredo, and my home Sixxs tunnel, and a HE tunnel from somewhere else. I used the 4or6 plugin to temporarily disable ipv6 and both sites loaded straight away. eftps.gov and pay.gov appear to be managed separately since both their ipv4 and ipv6 netblocks are not in the same netblocks, and my path to them is not the same: eftps.gov has IPv6 address 2620:10f:400e:a::13 mtr to eftps.gov via Sixxs: Host Loss% Snt Last Avg Best Wrst StDev 1. 2604:8800:100:82bc:ddcb:ae62:e3da:c91f 0.0%160.9 0.9 0.9 1.6 0.2 2. gw-701.chi-03.us.sixxs.net 0.0%16 71.6 72.4 68.6 78.3 2.4 3. uschi03.sixxs.net 0.0%16 70.2 71.8 69.2 78.8 2.4 4. 2620:0:6b0:a::1 0.0%15 67.3 73.3 67.3 79.7 3.2 5. tge3-1.fr3.ord4.ipv6.llnw.net 0.0%15 73.6 75.4 70.1 85.4 4.9 6. ve8.fr3.ord.ipv6.llnw.net 0.0%15 73.5 79.7 72.9 90.4 5.7 7. 2600:805:41f::5 0.0%15 104.4 81.9 74.2 104.4 9.0 8. 2600:806::120.0%15 105.2 104.0 100.6 109.8 2.9 9. 2600:806:12f::2e0.0%15 134.5 135.7 131.4 147.4 4.1 10. 2620:10f:400e:1::4004 0.0%15 161.5 145.9 131.5 163.8 9.9 11. ??? pay.gov has IPv6 address 2605:3100:fffd:100::15 mtr to pay.gov via Sixxs: Host Loss% Snt Last Avg Best Wrst StDev 1. 2604:8800:100:82bc:ddcb:ae62:e3da:c91f 0.0%110.9 0.9 0.7 1.1 0.1 2. gw-701.chi-03.us.sixxs.net 0.0%11 70.8 70.9 67.0 74.4 2.2 3. uschi03.sixxs.net 0.0%11 73.7 73.7 69.8 90.1 5.6 4. 2620:0:6b0:a::1 0.0%11 70.6 73.7 70.4 86.2 5.0 5. tge3-1.fr3.ord4.ipv6.llnw.net 0.0%11 72.4 75.6 71.5 82.6 3.2 6. ve8.fr3.ord.ipv6.llnw.net 0.0%11 76.1 79.3 74.7 87.9 4.0 7. tge32-3.fr3.dal.ipv6.llnw.net 0.0%11 99.1 100.1 96.4 106.2 2.7 8. sl-st30-dal-te0-14-0-1.v6.sprintlink.net0.0%11 98.2 102.0 98.2 111.0 4.4 9. sl-crs1-fw-be40.v6.sprintlink.net 0.0%11 99.5 100.5 96.2 105.5 2.5 10. sl-gw38-fw-po0-0.v6.sprintlink.net 0.0%11 96.4 98.8 96.4 105.1 2.6 11. 2600:4:2000:4::90.0%11 100.2 102.0 99.0 107.0 2.7 12. ??? I was hoping an eftps.gov or pay.gov employee was casting an eye this way, but it doesn't look like anybody from there is subscribed to NANOG. ...Todd -- The total budget at all receivers for solving senders' problems is $0. If you want them to accept your mail and manage it the way you want, send it the way the spec says to. --John Levine
Re: 4.2.2.2 4.2.2.21 High Packet Loss
On 10/25/14 02:03, Rafael Possamai wrote: Those addresses are anycasted, so you would have to do a bit of research and figure out what part of their network is having any packet loss. Here is an alternative: http://www.opennicproject.org/ On Fri, Oct 24, 2014 at 11:05 AM, Emir Sosa emirs...@gmail.com wrote: Any one else experiencing high packet loss*; *Any word out there what's happening? *Regards,Emir sosaemirs...@gmail.com emirs...@gmail.com* Are you familiar with mtr (my traceroute) try this: Konsole output erratic@laptop~ $mtr -c 10 --report 4.2.2.1 Start: Sun Oct 26 14:16:00 2014 HOST: laptop Loss% Snt Last Avg Best Wrst StDev 1.|-- 206.125.168.65 0.0%10 235.6 240.5 235.2 281.3 14.3 2.|-- 208.79.92.65 0.0%10 241.7 249.3 235.8 295.8 17.2 3.|-- 208.79.88.135 0.0%10 245.1 237.2 234.7 245.1 3.1 4.|-- 4.71.143.105 0.0%10 244.4 294.9 243.6 369.4 51.6 5.|-- 4.69.201.170.0%10 245.4 245.8 244.3 248.2 0.9 6.|-- 4.69.144.730.0%10 243.5 249.2 243.3 296.9 16.7 7.|-- 4.2.2.10.0%10 245.4 245.3 244.3 249.3 1.4 erratic@laptop~ $ was seeing quite a bit of loss on level3 a minute ago in --ncurses.
Re: Linux: concerns over systemd adoption and Debian's decision to switch [OT]
On Sat, 25 Oct 2014 17:56:52 -0500, Jimmy Hess said: The next thing you know, SystemD will add package management, ISO building, and eliminate the need for Debian, Ubuntu, SuSE, Redhat, Etc to even exist. That's already on Lennart's to-do list, you know. pgpsrz4mwPqsz.pgp Description: PGP signature
Re: pay.gov and IPv6
In message CAFG21ohZ6MV6Tef_sWuwV6kmAZmHQ3nFRLq-FkdU38g=vl3...@mail.gmail.com , Todd Lyons writes: On Sat, Oct 25, 2014 at 10:26 AM, Matthew Kaufman matt...@matthew.at wrote: Random IPv6 complaint of the day: redirects from FCC.gov to pay.gov fail when clients have IPv6 enabled. Work fine if IPv6 is off. One more set of Still broken, 7 months later. And again, I was too busy trying to pay to tr y to pull a full set of logs. But if you do something on the FCC site that requires payment, the redirection flow dies halfway through if you're comin g from IPv6 and works fine if you turn it off... so yet another computer in the house has IPv6 disabled until manually turned back on. FWIW, eftps.gov is also unreachable via ipv6. I tried all of miredo, and my home Sixxs tunnel, and a HE tunnel from somewhere else. I used the 4or6 plugin to temporarily disable ipv6 and both sites loaded straight away. If a site is unreachable your client should switch to IPv4 unless a IPv6 literal has been used. If your client take ages to switch over report a bug to the client vendor. It should not take ages to switch between multiple server addresses. IPv4 + IPv6 is just a example of multiple server addresses. eftps.gov and pay.gov appear to be managed separately since both their ipv4 and ipv6 netblocks are not in the same netblocks, and my path to them is not the same: eftps.gov has IPv6 address 2620:10f:400e:a::13 mtr to eftps.gov via Sixxs: Host Loss% Snt Last Avg Best Wrst StDev 1. 2604:8800:100:82bc:ddcb:ae62:e3da:c91f 0.0%160.9 0.9 0.9 1.6 0.2 2. gw-701.chi-03.us.sixxs.net 0.0%16 71.6 72.4 68.6 78.3 2.4 3. uschi03.sixxs.net 0.0%16 70.2 71.8 69.2 78.8 2.4 4. 2620:0:6b0:a::1 0.0%15 67.3 73.3 67.3 79.7 3.2 5. tge3-1.fr3.ord4.ipv6.llnw.net 0.0%15 73.6 75.4 70.1 85.4 4.9 6. ve8.fr3.ord.ipv6.llnw.net 0.0%15 73.5 79.7 72.9 90.4 5.7 7. 2600:805:41f::5 0.0%15 104.4 81.9 74.2 104.4 9.0 8. 2600:806::120.0%15 105.2 104.0 100.6 109.8 2.9 9. 2600:806:12f::2e0.0%15 134.5 135.7 131.4 147.4 4.1 10. 2620:10f:400e:1::4004 0.0%15 161.5 145.9 131.5 163.8 9.9 11. ??? pay.gov has IPv6 address 2605:3100:fffd:100::15 mtr to pay.gov via Sixxs: Host Loss% Snt Last Avg Best Wrst StDev 1. 2604:8800:100:82bc:ddcb:ae62:e3da:c91f 0.0%110.9 0.9 0.7 1.1 0.1 2. gw-701.chi-03.us.sixxs.net 0.0%11 70.8 70.9 67.0 74.4 2.2 3. uschi03.sixxs.net 0.0%11 73.7 73.7 69.8 90.1 5.6 4. 2620:0:6b0:a::1 0.0%11 70.6 73.7 70.4 86.2 5.0 5. tge3-1.fr3.ord4.ipv6.llnw.net 0.0%11 72.4 75.6 71.5 82.6 3.2 6. ve8.fr3.ord.ipv6.llnw.net 0.0%11 76.1 79.3 74.7 87.9 4.0 7. tge32-3.fr3.dal.ipv6.llnw.net 0.0%11 99.1 100.1 96.4 106.2 2.7 8. sl-st30-dal-te0-14-0-1.v6.sprintlink.net0.0%11 98.2 102.0 98.2 111.0 4.4 9. sl-crs1-fw-be40.v6.sprintlink.net 0.0%11 99.5 100.5 96.2 105.5 2.5 10. sl-gw38-fw-po0-0.v6.sprintlink.net 0.0%11 96.4 98.8 96.4 105.1 2.6 11. 2600:4:2000:4::90.0%11 100.2 102.0 99.0 107.0 2.7 12. ??? I was hoping an eftps.gov or pay.gov employee was casting an eye this way, but it doesn't look like anybody from there is subscribed to NANOG. ...Todd -- The total budget at all receivers for solving senders' problems is $0. If you want them to accept your mail and manage it the way you want, send it the way the spec says to. --John Levine -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: pay.gov and IPv6
Have you tried emailing the server admin at pay.gov.c...@clev.frb.org? On Sun, Oct 26, 2014 at 5:16 PM, Mark Andrews ma...@isc.org wrote: In message CAFG21ohZ6MV6Tef_sWuwV6kmAZmHQ3nFRLq-FkdU38g= vl3...@mail.gmail.com , Todd Lyons writes: On Sat, Oct 25, 2014 at 10:26 AM, Matthew Kaufman matt...@matthew.at wrote: Random IPv6 complaint of the day: redirects from FCC.gov to pay.gov fail when clients have IPv6 enabled. Work fine if IPv6 is off. One more set of Still broken, 7 months later. And again, I was too busy trying to pay to tr y to pull a full set of logs. But if you do something on the FCC site that requires payment, the redirection flow dies halfway through if you're comin g from IPv6 and works fine if you turn it off... so yet another computer in the house has IPv6 disabled until manually turned back on. FWIW, eftps.gov is also unreachable via ipv6. I tried all of miredo, and my home Sixxs tunnel, and a HE tunnel from somewhere else. I used the 4or6 plugin to temporarily disable ipv6 and both sites loaded straight away. If a site is unreachable your client should switch to IPv4 unless a IPv6 literal has been used. If your client take ages to switch over report a bug to the client vendor. It should not take ages to switch between multiple server addresses. IPv4 + IPv6 is just a example of multiple server addresses. eftps.gov and pay.gov appear to be managed separately since both their ipv4 and ipv6 netblocks are not in the same netblocks, and my path to them is not the same: eftps.gov has IPv6 address 2620:10f:400e:a::13 mtr to eftps.gov via Sixxs: Host Loss% Snt Last Avg Best Wrst StDev 1. 2604:8800:100:82bc:ddcb:ae62:e3da:c91f 0.0%160.9 0.9 0.9 1.6 0.2 2. gw-701.chi-03.us.sixxs.net 0.0%16 71.6 72.4 68.6 78.3 2.4 3. uschi03.sixxs.net 0.0%16 70.2 71.8 69.2 78.8 2.4 4. 2620:0:6b0:a::1 0.0%15 67.3 73.3 67.3 79.7 3.2 5. tge3-1.fr3.ord4.ipv6.llnw.net 0.0%15 73.6 75.4 70.1 85.4 4.9 6. ve8.fr3.ord.ipv6.llnw.net 0.0%15 73.5 79.7 72.9 90.4 5.7 7. 2600:805:41f::5 0.0%15 104.4 81.9 74.2 104.4 9.0 8. 2600:806::120.0%15 105.2 104.0 100.6 109.8 2.9 9. 2600:806:12f::2e0.0%15 134.5 135.7 131.4 147.4 4.1 10. 2620:10f:400e:1::4004 0.0%15 161.5 145.9 131.5 163.8 9.9 11. ??? pay.gov has IPv6 address 2605:3100:fffd:100::15 mtr to pay.gov via Sixxs: Host Loss% Snt Last Avg Best Wrst StDev 1. 2604:8800:100:82bc:ddcb:ae62:e3da:c91f 0.0%110.9 0.9 0.7 1.1 0.1 2. gw-701.chi-03.us.sixxs.net 0.0%11 70.8 70.9 67.0 74.4 2.2 3. uschi03.sixxs.net 0.0%11 73.7 73.7 69.8 90.1 5.6 4. 2620:0:6b0:a::1 0.0%11 70.6 73.7 70.4 86.2 5.0 5. tge3-1.fr3.ord4.ipv6.llnw.net 0.0%11 72.4 75.6 71.5 82.6 3.2 6. ve8.fr3.ord.ipv6.llnw.net 0.0%11 76.1 79.3 74.7 87.9 4.0 7. tge32-3.fr3.dal.ipv6.llnw.net 0.0%11 99.1 100.1 96.4 106.2 2.7 8. sl-st30-dal-te0-14-0-1.v6.sprintlink.net0.0%11 98.2 102.0 98.2 111.0 4.4 9. sl-crs1-fw-be40.v6.sprintlink.net 0.0%11 99.5 100.5 96.2 105.5 2.5 10. sl-gw38-fw-po0-0.v6.sprintlink.net 0.0%11 96.4 98.8 96.4 105.1 2.6 11. 2600:4:2000:4::90.0%11 100.2 102.0 99.0 107.0 2.7 12. ??? I was hoping an eftps.gov or pay.gov employee was casting an eye this way, but it doesn't look like anybody from there is subscribed to NANOG. ...Todd -- The total budget at all receivers for solving senders' problems is $0. If you want them to accept your mail and manage it the way you want, send it the way the spec says to. --John Levine -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: pay.gov and IPv6
This is why I need to pull logs the next time I need to pay the FCC. There are several rounds of redirects involved from clicking the payment button on the FCC site to the final landing at pay.gov, and one of the last steps never connects if IPv6 is enabled. Matthew Kaufman (Sent from my iPhone) On Oct 26, 2014, at 2:16 PM, Mark Andrews ma...@isc.org wrote: In message CAFG21ohZ6MV6Tef_sWuwV6kmAZmHQ3nFRLq-FkdU38g=vl3...@mail.gmail.com , Todd Lyons writes: On Sat, Oct 25, 2014 at 10:26 AM, Matthew Kaufman matt...@matthew.at wrote: Random IPv6 complaint of the day: redirects from FCC.gov to pay.gov fail when clients have IPv6 enabled. Work fine if IPv6 is off. One more set of Still broken, 7 months later. And again, I was too busy trying to pay to tr y to pull a full set of logs. But if you do something on the FCC site that requires payment, the redirection flow dies halfway through if you're comin g from IPv6 and works fine if you turn it off... so yet another computer in the house has IPv6 disabled until manually turned back on. FWIW, eftps.gov is also unreachable via ipv6. I tried all of miredo, and my home Sixxs tunnel, and a HE tunnel from somewhere else. I used the 4or6 plugin to temporarily disable ipv6 and both sites loaded straight away. If a site is unreachable your client should switch to IPv4 unless a IPv6 literal has been used. If your client take ages to switch over report a bug to the client vendor. It should not take ages to switch between multiple server addresses. IPv4 + IPv6 is just a example of multiple server addresses. eftps.gov and pay.gov appear to be managed separately since both their ipv4 and ipv6 netblocks are not in the same netblocks, and my path to them is not the same: eftps.gov has IPv6 address 2620:10f:400e:a::13 mtr to eftps.gov via Sixxs: Host Loss% Snt Last Avg Best Wrst StDev 1. 2604:8800:100:82bc:ddcb:ae62:e3da:c91f 0.0%160.9 0.9 0.9 1.6 0.2 2. gw-701.chi-03.us.sixxs.net 0.0%16 71.6 72.4 68.6 78.3 2.4 3. uschi03.sixxs.net 0.0%16 70.2 71.8 69.2 78.8 2.4 4. 2620:0:6b0:a::1 0.0%15 67.3 73.3 67.3 79.7 3.2 5. tge3-1.fr3.ord4.ipv6.llnw.net 0.0%15 73.6 75.4 70.1 85.4 4.9 6. ve8.fr3.ord.ipv6.llnw.net 0.0%15 73.5 79.7 72.9 90.4 5.7 7. 2600:805:41f::5 0.0%15 104.4 81.9 74.2 104.4 9.0 8. 2600:806::120.0%15 105.2 104.0 100.6 109.8 2.9 9. 2600:806:12f::2e0.0%15 134.5 135.7 131.4 147.4 4.1 10. 2620:10f:400e:1::4004 0.0%15 161.5 145.9 131.5 163.8 9.9 11. ??? pay.gov has IPv6 address 2605:3100:fffd:100::15 mtr to pay.gov via Sixxs: Host Loss% Snt Last Avg Best Wrst StDev 1. 2604:8800:100:82bc:ddcb:ae62:e3da:c91f 0.0%110.9 0.9 0.7 1.1 0.1 2. gw-701.chi-03.us.sixxs.net 0.0%11 70.8 70.9 67.0 74.4 2.2 3. uschi03.sixxs.net 0.0%11 73.7 73.7 69.8 90.1 5.6 4. 2620:0:6b0:a::1 0.0%11 70.6 73.7 70.4 86.2 5.0 5. tge3-1.fr3.ord4.ipv6.llnw.net 0.0%11 72.4 75.6 71.5 82.6 3.2 6. ve8.fr3.ord.ipv6.llnw.net 0.0%11 76.1 79.3 74.7 87.9 4.0 7. tge32-3.fr3.dal.ipv6.llnw.net 0.0%11 99.1 100.1 96.4 106.2 2.7 8. sl-st30-dal-te0-14-0-1.v6.sprintlink.net0.0%11 98.2 102.0 98.2 111.0 4.4 9. sl-crs1-fw-be40.v6.sprintlink.net 0.0%11 99.5 100.5 96.2 105.5 2.5 10. sl-gw38-fw-po0-0.v6.sprintlink.net 0.0%11 96.4 98.8 96.4 105.1 2.6 11. 2600:4:2000:4::90.0%11 100.2 102.0 99.0 107.0 2.7 12. ??? I was hoping an eftps.gov or pay.gov employee was casting an eye this way, but it doesn't look like anybody from there is subscribed to NANOG. ...Todd -- The total budget at all receivers for solving senders' problems is $0. If you want them to accept your mail and manage it the way you want, send it the way the spec says to. --John Levine -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: A translation (was Re: An update from the ICANN ISPCP meeting...)
David wrote: Indeed, and I must commend Warren and Eric for caring enough to actually engage in this stuff. While many people in the NANOG/IETF/DNS Operations communities complain about the latest abomination ICANN is inflicting upon the world, there aren't a whole lot of folks from those communities who take the (non-trivial) amount of time to try to understand and address the situation. While I fully understand the rationales for not participating, the lack of strong representation from the technical community does not help in preventing abominations. The number of technically capable with multi-meeting attendance records is wicked limited, and most are silo'd off -- into SSAC or TAC or ASO or ... or attending annual co-gigs like OARC, and so, with the exception of those working for registries, rarely involved in actual policy development where it actually happens -- at the GNSO Council -- as all policy relating to generic top-level domains originates in the GNSO, via a or the (by abuse of notation) Policy Development Process (PDP). So if there is a point to a ISPCP stakeholders group (formerly the ISP Constituency), it is to have votes in the GNSO Council and so be capable of (a) originating a policy activity (a PDP), and (b) being eligible to chair the resulting working group, and (c) being eligible to vote on the recommendation(s) of the working group. Otherwise it is ornamental, a reflection of one of the several errors of judgement of the Roberts/Dyson/Touton team back when multi-stakeholder(ism) was being made up as an alternative to the contractor-agency binary relationship. It takes years to get things done, and things happen, even on Constituency Day, as Warren noted, so this isn't a send-one-staffer-and-expect-goodness kind of investment. The competent teams are three or more, and work years of meetings to achieve their policy ends. I think it safe to say that much (but not all) of the warfare that goes on at ICANN meetings is between the folks interested in protecting IPR (in this context, trademarks) and folks interested in selling oodles of domain names. Generally true. Counter-examples: Sitefinder, FastFlux, ... There are other axis of evils, somewhat orthogonal to the infringement vs volume conflict of interests, but absent what I think of as operators (of oodles of wire or piles of cooling kit), all issues that involve name-to-resource mappings where ICANN policy, not national law, is dispositive, are and will continue to be determined by one or the other of the infringement vs volume parties. Eric
Re: ARIN / RIR Pragmatism (WAS: Re: RADB)
LACNIC numbers (as a percent) are quite good, but my question was why only RIPE has the very impressive total count of ROAs. conjecture follows of course one can never know. but i conject o the are the largest registry actively promotin registration o the ncc, particularly alex, tim, oleg, ... have put significant effort into making it very easy to register o they have a culture of cooperation and doing things well You can clearly point to ARIN's legal treatment of the risks involved, but that is not applicable in the APNIC case it is hard to register in apnic, ask folk who have tried. the most active folk are under NIRs, who are only now working on deployment. apnic is not really promoting it. You don't feel there's any correlation between RIPE's IRR approach and their RPKI success? that's the cooperative culture bit, actually interested in the net running well. randy
Re: A translation (was Re: An update from the ICANN ISPCP meeting...)
I think one missing or weak component are those who actually make this stuff work vs the pie-in-the-sky infringer/volume/policy crowd. I've sat in IPC meetings and suffice it to say there isn't much clue on that front and why should there be unless the go-fast/go-always crowd shows up? Sure it does tend to creep in as proposed policies escape and get the attention of the doers but the danger is by that time the infringer/volume crowd might be quite committed to their vision: Make PI=3.0 and full steam ahead. What's also often lacking is simply administrative and management insight but that's not particularly germaine to this group. But I did get into a minor shouting match with an IP lawyer last week in LA who just didn't understand why service providers won't drop everything we're doing to rush through their discovery needs, for free, without indemnification (or similar), or jurisdicational authority, on an as-needed basis. -- -Barry Shein The World | b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR, Canada Software Tool Die| Public Access Internet | SINCE 1989 *oo*
