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] 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 ]
Kurt Erik Lindqvist
kurtis at kurtis.pp.se
Wed Mar 23 14:54:27 CET 2005
-----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... > 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. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQkF1GaarNKXTPFCVEQLi+wCfTXZHrL4u+kAvRuDB1O6mc2AJWy0AoPN1 S4yfPNG+44ZYMKm7gZ3Z0nZq =FH9m -----END PGP SIGNATURE-----
- 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 ]