[address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling)
- Previous message (by thread): [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling)
- Next message (by thread): [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Daniel Suchy
danny at danysek.cz
Mon May 23 18:06:28 CEST 2011
Hi, On 05/23/2011 05:49 PM, Janos Zsako wrote: > I am afraid the text of ripe-509 is very clear: > > "The following policies come into effect as soon as RIPE NCC is required > to make > allocations from the final /8 it receives from the IANA. > From then on the distribution of IPv4 address space will only be done > as follows:" Then article name isn't clear. As it doesn't apply these days, it doesn't matter, but in future this may confuse someone, as last /8 is only one. > I personally do not think it would be wise to allocate returned addresses > in accordance with policies applicable before the last /8, if we already > started to allocate from the last /8 (i.e. I do not think it would be wise > to have two sets of policies, both live at the same time, one applicable to > the last /8 and an other one to the returned address space). >From database point of view, there will be two sets of policies on single /8 - in future on all except 185.0.0.0/8 (the last one). One "historic" (for allocations made before some not-yet-known date) and some "current" for new allocations after that magic date - with real influence to RIPE-510 (operational impact I mentioned already). Current system is very clear in terms of each new /8 usage, proposed change will introduce new uncertainty to other exising /8. Daniel
- Previous message (by thread): [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling)
- Next message (by thread): [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]