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] Summary TLD Anycast Allocation Policy
- Previous message (by thread): [address-policy-wg] Summary TLD Anycast Allocation Policy
- Next message (by thread): [address-policy-wg] Summary TLD Anycast Allocation Policy
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Elmar K. Bins
elmi at 4ever.de
Tue Apr 5 13:52:53 CEST 2005
Mohsen.Souissi at nic.fr (Mohsen Souissi) wrote: > - comment: One /48 microallocation per TLD under a common > prefix ( a /32 or shorter per RIR) would ideally meet the goal. The > "well-known" prefix would be taken into account in BGP filters so > that /48 get the biggest chance not to be filtered. I second that, but in essence, it's down to operational issues here. Once the WG has expressed its confidence in the proposal, a few formulations are in order; yet, at this time there's no express consensus yet. Hopefully we'll reach that in Stockholm, even if I (and a couple other folks as well) would be very happy if this proposal would get the entire WG's support a bit sooner. > - suggestion: While waiting for the "ideal solution" to be > implemented. The wg should move forward with this proposal and > allocate one /32 per TLD applying for it. Probably, only a small > number of TLDs will ask for such allocations before the "ideal > solution" gets in place. In all cases, the number of requested > blocks is bounded and there must be no scaling issues since the > conditions are clearly stated: TLD + Anycast (+ potential problems > with growing DNS response size due to growing number of NS's and > glue RR's). I second this. Limiting the proposal to TLDs makes the number of potential users manageably small. I'd recommend to get the proposal done and into action instead of keeping to basic discussion of how an administrator/operator should run their services. The proposal should have a paragraph that encourages re-evaluation, so that discovered mistakes can be fixed. Yours, Elmi. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2 at ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---
- Previous message (by thread): [address-policy-wg] Summary TLD Anycast Allocation Policy
- Next message (by thread): [address-policy-wg] Summary TLD Anycast Allocation Policy
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]