This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/address-policy-wg@ripe.net/
[address-policy-wg] Assignments for Critical Infrastruction
- Previous message (by thread): [address-policy-wg] Assignments for Critical Infrastruction
- Next message (by thread): [address-policy-wg] Assignments for Critical Infrastruction
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Greg L.
bgp2 at linuxadmin.org
Mon Nov 17 21:25:50 CET 2008
Yes, correct.. my main point was not to block any proposals, I just wanted to comment that PI assignations must be more open to businesses that require it for BGP anycasting (multihoming etc) in Ripe region as it is in Arin region. My apologies for the comments that I sent in reply to your emails - probably a wrong discussion/thread. I just remember the problems we had and how easy it was when we moved our client to Arin IP space. However, I believe http://www.ripe.net/ripe/policies/proposals/2006-05.html "PI Assignment Size" proposal is aimed to solve the problem with PI allocation of /24 when routing is the major issue. This is something that Arin already has in their policy and works like a charm. Unfortunately, I haven't heard much about this proposal lately - it's been in "Awaiting Decision from WG Chair " status. Greg At 21:46 2008.11.17.t Cá', OndÅ™ej Surý wrote: >2008/11/17 Greg L. <bgp2 at linuxadmin.org>: > > One /24 prefix for TLD's DNS should be more than enough anyway. > >Why do you think so? > > > If you are hosting ccTLD or gTLD it shouldn't automatically qualify you > > for "Critical infrastructure". A small country with 200 ccTLD domains > > registered is not more critical than some business hosting 120,000 > > .com/.net domains (a DNS service not ccTLD or gTLD). Maybe a high > > reliability and uptime for this company is more critical to be in business > > than a small ccTLD with just 2 million of DNS queries. > >I agree here with you. My proposal is same as ARINs policy that CI MAY get >more then one prefix and it should be up to RIPE NCC hostmaster decision >if they allow TLD to get more then one prefix. Something like a plan >of deployment, etc. - small TLD would not be able to deploy many anycast >nodes around the globe. > > > However, the small ccTLD get's /24 allocated without problems in Ripe > > region, the other company does NOT. > >Again "the other company does NOT" should not be a reason why TLD should not >be able to get more than one prefix. If you don't like current policy change >it or at least try to change it. Blocking reasonable (my POV) proposal just >because you're angry that you had to move to Arin region will get us nowhere. > > > Well I do not care much anyway since we have moved clients to Arin IP space > > and meet all the requirements there and we are happy. > >Alright now you are saying that Arin's policy is good. Maybe you should >started your email conversation with proposal that you would like to see >RIPE policy to allow PI assignments to other businesses as well. > > > I just wanted to comment that /24 prefix for anycast should be more open > > to businesses that meet some other criteria not just ccTLD or gTLD hosting. > >Here we may get to some level of agreement. Constructive proposals are most >welcome. > >Ondrej. >-- > Ondrej Sury > technicky reditel/Chief Technical Officer > ----------------------------------------- > CZ.NIC, z.s.p.o. -- .cz domain registry > Americka 23,120 00 Praha 2,Czech Republic > mailto:ondrej.sury at nic.cz http://nic.cz/ > sip:ondrej.sury at nic.cz tel:+420.222745110 > mob:+420.739013699 fax:+420.222745112 > -----------------------------------------
- Previous message (by thread): [address-policy-wg] Assignments for Critical Infrastruction
- Next message (by thread): [address-policy-wg] Assignments for Critical Infrastruction
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]