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] Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA
- Previous message (by thread): [address-policy-wg] Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA
- Next message (by thread): [address-policy-wg] Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Scott Leibrand
scottleibrand at gmail.com
Wed Feb 5 21:37:00 CET 2014
I believe option A was the intent behind the global policy. There is no downside to choosing option A, but there could conceivably be a downside to option B (an RIR runs out of space, stops allocations, and then resumes when they get more from IANA). Therefore, I believe that the IANA should proceed based on option A. -Scott P.S. Yes, I am affiliated with ARIN, but also represent a RIPE member. My opinions in this case, though, are based on my evaluation of what is best for the Internet community as a whole, which seems to be the same for everyone involved. On Wed, Feb 5, 2014 at 10:57 AM, Filiz Yilmaz <koalafil at gmail.com> wrote: > Dear Colleagues, > > NRO NC is asked by the IANA Staff for a clarification on the reading of > this policy, Global Policy for post exhaustion IPv4 allocation mechanisms > by the IANA, in regards to "when" the first allocations from the Recovered > IPv4 pool can be made. > > The Council decided to check further with the communities, hence this mail. > > The policy document (http://www.ripe.net/ripe/docs/ripe-529) states the > following: > > ---- > > 1.0 Recovered IPv4 Pool > > .... > > When one of the RIRs declares it has less than a total of a /9 in its > inventory, the Recovered IPv4 pool will be declared active, and IP > addresses from the Recovered IPv4 Pool will be allocated as stated in > Section 2.0 below. > > 2.0 Allocation of returned IPv4 address space by the IANA > > 1. Allocations from the IANA may begin once the pool is declared active. > 2. In each "IPv4 allocation period", each RIR will receive a single "IPv4 > allocation unit" from the IANA. > 3. An "IPv4 allocation period" is defined as a 6-month period following 1 > March or 1 September in each year > > ... > ---- > > While clause 1 seems to be pretty clear, it contains a "may" and clauses 2 > and 3 together talk about "allocation periods" and that they are the > "6-month period following 1 March or 1 September in each year." > > In practice, if the pool is declared active on 1 January and IANA makes > the first allocations immediately this would be outside of the allocation > period, which begins at the start of March. > > So mainly the question is about the first allocations from the the > Recovered IPv4 pool; > > a) Should they be made straight away > or > b) Should IANA wait and make them at the start of the next "IPv4 > allocation period," the "6-month period following 1 March or 1 September. > > > In my personal opinion I see no problems with starting straight away > (option a above), and then continue the rest in the regularity of the > allocation periods as stated in the policy. > > Would you agree or is your reading towards option b above? > > Please let us know of your opinions on this list until 23 February 2014. > > > Kind regards > Filiz Yilmaz > as NRO NC Member from RIPE Region > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: </ripe/mail/archives/address-policy-wg/attachments/20140205/59833d6f/attachment.html>
- Previous message (by thread): [address-policy-wg] Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA
- Next message (by thread): [address-policy-wg] Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]