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/[email protected]/
[address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy
- Previous message (by thread): [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy
- Next message (by thread): [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Joao Damas
Joao_Damas at isc.org
Wed Mar 23 17:00:44 CET 2005
On 23 Mar, 2005, at 14:54, Kurt Erik Lindqvist wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On 2005-03-23, at 14.39, Joao Damas wrote: >> On 23 Mar, 2005, at 10:36, Kurt Erik Lindqvist wrote: >>> I don't see why RIPE need to assign a /32 when the other regions are >>> /48s? I would also like to add that these assignments should be made >>> out of a single block. >> >> What would the problem be with the /32, really? Counting the >> addresses? > > "640k should be enough for anyone" :-) (Although Mr Gates disputes that > statement ever been said here : > http://www.nybooks.com/articles/15180#fn*). My main concern is that > this again is contrary to the "conservation" policy which is one of the > reasons we have RIRs at all... You really think so? Even for IPv6? For me the real value is that RIRs provide uniqueness, that is their true value. Just like a cadaster. Conservation has been an additional task that has been put on the RIRs thanks to the limitations of IPv4 (<mild sarcasm> and surely IPv6 will solve that </mild sarcasm>. Was the main goal of the RIPE NCC conservation (other than through promotion of CIDR) when it came into existence? > >> 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. > However that affects one at a time, rather than all at once. I mean if go shooting ducks I really prefer to have them all nicely bunched together so that it requires less skill, but if I am a duck I would rather make it more difficult for the hunter (or wild sniper entering the burger shop, as it may be) Joao
- Previous message (by thread): [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy
- Next message (by thread): [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]