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 ]
Daniel Roesen
dr at cluenet.de
Wed Mar 23 16:18:59 CET 2005
On Wed, Mar 23, 2005 at 10:58:18AM +0100, Elmar K. Bins wrote: > I myself would prefer a defined range (say, a /32 block out of which > /48s are allocated), but I seem to be a minority with that opinion. > This range would allow operators to exclude it from their filters. I totally agree. Derriving policy from prefix length (at least in the range up to /48) is just bogus and shouldn't be supported by issuing /32s to guarrantee routability. The folks filtering ANYTHING longer than /32 or /35 are just wrong. A /48 is far more than enough. > > 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. > > Joining the minority? ;-) I certainly do. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0
- 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 ]