- address-policy-wg - mailman.ripe.net

Re: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy
by Wilfried Woeber, UniVie/ACOnet 29 Mar '05

29 Mar '05

>No, what it means is: "People who inject routes in the global routing >table, for whatever reason, increase the cost of operating routers. So >for reasons of fairness and as a mild deterrent, these people should >bear a generous share of the costs associated with operating the RIR >infrastructure." Again, this implies the existence of some sort of cross-domain funds- transfers. As there is no direct and transparent relationship between ensuring uniqueness of address space blocks (RIR business) and those covering the cost of implementing the routing layer for the global Internet, it would simply be an address tax raised by the RIRs. There's not even the concept of "reverse funds" transfer from the RIRs charging for such addresses back to the LIRs. >A good way to do this would be to require everyone who wants such a >block to become a RIR and to charge address based costs only on the >number of blocks and not on their size. No, see above. [btw, I assume the string "RIR" in the previous paragraph is just a typo and that you meant to type "LIR". Otherwise this would be a clever move to kill the proposal - by sending them to ICANN for recogition as an RIR :-] And, I presume that addresses would only be distributed by way of an LIR anyway. So where is the point? >Note that I'm not saying these people should pay an artificially >inflated fee (although deep in my heart I would love that), just their >fair share. With your definition of fair for something you don't like :-) Scary... > It shouldn't be cheaper to obtain a special prefix than a regular one. Indeed, and then it should not be smaller or, rather, more difficult and risky to use. >Also, there should be limits on the number of special prefixes. Ahem, how many - and why? Wilfried.

6 10

Re: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy
by Wilfried Woeber, UniVie/ACOnet 25 Mar '05

25 Mar '05

>If even they don't push their routers hard, then even with phenomenal growth >over the next 5 years or so then what ever the current routers are then will >probably be able to cope. >If the routers can cope then the size of the routing table becomes a non issue >- that's what I'm trying to say. Looking at the fact that for a couple of years already the majority no longer cares (or even reads? much less acts on) the weekly routing table reports suggests that you are right. >Jon Wilfried.

1 0

Re: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy
by Wilfried Woeber, UniVie/ACOnet 24 Mar '05

24 Mar '05

>personally, i have no answer. We seem to be coming to the bottom of the pit :-) > sorry to make you read all this rubbish to find that. Fine with me. > why not show a bit of wimsey and block out >42 /32 chunks for this and have a three month bidding period to see >how much money the rirs can collect to donate to heal some of the >horrifying wounds of the latest natural disaster or unnatural us >imperialism? Aah, so this time at least we don't want to raise money for poor routers, but for victims of some sort of disaster or another. And why 42? (other than being "this" universal number) Wouldn't we be able to raise more money if we would give away more prefixes ;-) Or maybe just 32 x /32? Funny times, Wilfried.

2 1

Re: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy
by Joao Damas 24 Mar '05

24 Mar '05

OK, so I guess my point altogether is that I dislike special-ness. There seems to be agreement that DNS anycasting is here to stay so the only point of contention is the size of the prefix. Using longer prefixes does not add much to the conservation and introduces more exceptions. Even if other RIRs are doing /48s already why would introducing an additional chunk of swamp space with the potential for more likely large scale failure be of any benefit? If people agree with assigning the addresses for this purpose, which seems to be the case, just issue a standard allocation and be done. Regarding the issue of flap damp(en)ing parameters, I think we should really revisit the flap damp(en)ing recommendations again at RIPE 50. Joao PS: regarding entries in the routing table and the pollution it causes, keep an eye on RFCs coming soon. PS: regarding the use of "wrong DNS software", the TLD operator is running *SERVERS* and providing services to resolvers/users. The best they can do is provide as good a service as they can to their consumers, not preach to them about them running the wrong client side software.

3 7

Re: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy
by Wilfried Woeber, UniVie/ACOnet 24 Mar '05

24 Mar '05

>I would also be very happy if RIPE would charge enough money to people >wanting to do this to make them consider whether they really need it. ...this is just a fuzzy wording for: "Make the RIRs sell address space at different (and maximum) premiums, depending on how dearly the applicant needs the addresses at that particular point in time." I would not support such a proposal. Wilfried.

2 1

Re: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy
by Wilfried Woeber, UniVie/ACOnet 23 Mar '05

23 Mar '05

Kurtis, >> Howeverm, the "out of a single block" is the part that really bothers >> me. Putting supposedly "critical infrastructure" as it is called >> elsewhere in a block that makes them all share fate in the event of >> network "optimisations" is still a bad idea. > >Well, this can be argued the otherway around as well. We know that ISPs >filter out previously unused space, and that they are not very active >in updating those filters when IANA starts allocating out of new >blocks. Having all in well-known block would limit that. ...wouldn't we/you/they/all have to do some filtering the "other way 'round" if all of those prefixes are contained in _one_ superblock to guard against someone/something announcing (and potentially black- holeing(sp?)) a route for that /32? >- - kurtis - Wilfried.

2 1

Registration Policy
by Thomas Thorne 11 Mar '05

11 Mar '05

To Whom It May Concern: How does a company or individual "own" the .biz, .info or similar URL suffix? Is it possible to register a new one? If so, at what cost? And do you allow someone to then own and profit from it? Thank you, Tom Thorne __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo

3 2

Status of open actions
by Hans Petter Holen 04 Mar '05

04 Mar '05

Dear all, the next RIPE meeting is approaching in a couple months - It is time to review the action list. I have added the status as far as I know. http://www.ripe.net/ripe/wg/address-policy/action-list.html 47.3 Andreas Bäß Anycast for ccTLD: Complete discussion through Mailing List to draft formal proposal. Ongoing - published as policy proposal #alpha 47.4 Chair AfriNIC proposal for /22 minimum allocation size: Seek final consensus through the Mailing List. completed 47.5 Chair Changing the 80% rule for IPv4 allocations: Start discussion through the Mailing List. 48.1 Chair HD Ratio for IPv4: Take discussion to the mailing list policy proposal #beta 48.2 Chair Issues seen in IPv6 Allocation requests: circulate input on the mailing list. 48.3 NCC Issues seen in IPv6 Allocation requests: Propose re-write following mailing list discussion. 49.1 Andy Furnel Draft formal proposal on removing the 200 customer requirements for IPv6 49.2 Rob Blokzijl Publish draft Policy Development process published http://www.ripe.net/ripe/maillists/archives/ripe-list/2004/msg00058.html 22 Dec 2004 49.3 Working Group Continue discussion on the list of the IANA-RIR IPv6 policy 49.4 Eva Ericsson-Rabete Take discussion on Whois to the list 49.5 Alain Bidron Make a formal proposal on use of HD ratio for IPv4 policy proposal #beta

1 0

Beta test of new PDP
by Hans Petter Holen 04 Mar '05

04 Mar '05

As the new policy process proposed by Rob http://www.ripe.net/ripe/maillists/archives/ripe-list/2004/msg00058.html has not been finalized yet I have deceided to "beta test" the new process on new proposals received after today. The new process is a bit more structured that the previous one, and the previous one is open enough in its definition to fit the new one in this framework. Until the new process is approved and fully implmenented I'll maintain the list of proposals myself. Please let me know if you have any concerns with this approach Best Regards, Hans Petter Holen Address POlicy WG Chair

1 0

New AS Number Block allocated to the RIPE NCC
by Filiz Yilmaz 03 Mar '05

03 Mar '05

Dear Colleagues, The RIPE NCC received the AS Number Block 34816 - 35839 from the IANA in February 2005. You may want to update your records accordingly. Kind regards, -- Filiz Yilmaz RIPE NCC

1 0