Keyboard Shortcuts
Thread View
j
: Next unread messagek
: Previous unread messagej a
: Jump to all threadsj l
: Jump to MailingList overview

Ray:
a couple of comments:
1) A global policy can change what is stated in a former one.
2) I assume that no RIR will request more than 2 /8s. If somebody think/feel that our agreement on this point is not firm, so it will be necessary to propose a modification in the current global policy to limit the number of /8s requested to 2.
Raúl
At 09:45 a.m. 27/09/2007, Ray Plzak wrote:
Comment on drc comment 1 - There is nothing to preclude an RIR from requesting to get what it can justify, albeit that the RIRs have informally said that they will only accept a max of 2 /8s. Thus the following scenario is highly possible:
IANA has 6 /8s remaining; RIR qualifies for 4 /8s and decides to accept what it qualifies for; what does IANA do with the remaining 2 /8s.
Ray
-----Original Message----- From: sig-policy-bounces@lists.apnic.net [mailto:sig-policy- bounces@lists.apnic.net] On Behalf Of Izumi Okutani Sent: Thursday, September 27, 2007 8:30 AM To: David Conrad Cc: Randy Bush; sig-policy@lists.apnic.net Subject: Re: [sig-policy] prop-046: IPv4 countdown policy proposal - returning to mailing list for development
Hi, I've commented inline.
David Conrad wrote: [...]
- IANA to distribute a single /8 to each RIR when the IANA free pool hits 5 /8s. This date is defined as 'IANA Exhaustion Date'.
Seems fine, although just to be explicit:
Suppose there are 6 /8s remaining in the free pool. An RIR comes to IANA and indicates they want another allocation. Current practice is to allocate 2 /8s (if justified). IANA allocates the 2 /8s, leaving 4 /8s. The obvious approach would be to allocate the remaining 4 /8s to the other 4 RIRs. Is that the intent?
right, thanks for clarifying.
... and a single /8 will be distributed to *5* RIRs if the RIR requested for 1 /8 instead of 2 /8s.
(i.e.the requesting RIR gets 2 /8s in total, remaining four RIRs get 1)
[...]
- RIRs should provide an official projection on the IANA Exhaustion Date to the community.
I'm not sure I see the point of having 5 different 'official' projections.
Not for job security for researchers though I did like the idea :-).
We weren't actually expecting each RIR to come with their own projections, but for them to provide latest information based on projections already available.
(which RIRs consider as reliable)
- RIRs should maintain the current address distribution criteria
until the IANA Exhaustion Date.
Perhaps not too surprisingly, I disagree with this particular clause. By analogy, we're driving down a road at 100 KPH and we see a brick wall ahead of us. This clause requires us to put the car on cruise control and close our eyes until we're about a meter from the wall.
What is the rationale for this clause?
The idea is to ensure LIRs can receive IPv4 address space they need (based on justifications) until the last minute with minimum confusion.
Going by road analogy, you increase confusion for drivers if you add extra rules changing from time to time, which may lead to accidents/traffic jam. Our intention is to avoid confusion by maintaining a consistent rule.
I would think a more rational approach would be for each RIR to encourage IPv4 conservation using whatever policies make sense in their region.
That could be one approach, and this is the part we intend to discuss as regional policies after IED (presented as informational in APNIC24).
- Is this proposal addressing a real need or problem?
It isn't clear to me what problem this policy is attempting to
address. When the remaining IANA pool is 5 /8s (or less), there are not enough blocks for all RIRs on consumption basis.
You can't tell if your turn to request will come before the IANA pool runs out as it all depends on timing of your + other RIRs' request.
This makes it more difficult for RIRs to plan distribution of the available pool in their regions.
- What advantages are there to distributing the last remaining /8 blocks equally to the RIRs?
Encouraging investment in developing countries by large ISPs in developed countries?
:-) I understand your point, but I imagine a single /8 won't attract too many investors. It probably won't last for more than few months to meet their needs.
I know quite a number of people are concerned about this point, so I'd be interested to hear more details on what people see as an issue.
izumi
sig-policy: APNIC SIG on resource management policy
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
sig-policy: APNIC SIG on
resource management policy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy

Raul,
Comments in line below.
Ray
-----Original Message----- From: sig-policy-bounces@lists.apnic.net [mailto:sig-policy- bounces@lists.apnic.net] On Behalf Of Raul Echeberria Sent: Thursday, September 27, 2007 9:15 AM To: sig-policy@lists.apnic.net Subject: Re: [sig-policy] prop-046: IPv4 countdown policy proposal - returning to mailing list for development
Ray:
a couple of comments:
- A global policy can change what is stated in a former one.
Agree.
- I assume that no RIR will request more than 2
/8s. If somebody think/feel that our agreement on this point is not firm, so it will be necessary to propose a modification in the current global policy to limit the number of /8s requested to 2.
I didn't characterize whether it was firm or not, I just pointed out that this is an informal administrative arrangement. The reason that I point this out is that in recent APNIC meeting the JPNIC presenter and AfriNIC presenter said that this was a policy and used it as part of their justification and basis for their policy proposal. Also, all it really means is that the RIRs just come to the IANA table more frequently and that both the IANA and RIR staffs have to do more work.
Ray
Raúl
At 09:45 a.m. 27/09/2007, Ray Plzak wrote:
Comment on drc comment 1 - There is nothing to preclude an RIR from requesting to get what it can justify, albeit that the RIRs have informally said that they will only accept a max of 2 /8s. Thus the following scenario is highly possible:
IANA has 6 /8s remaining; RIR qualifies for 4 /8s and decides to accept what it qualifies for; what does IANA do with the remaining 2 /8s.
Ray
-----Original Message----- From: sig-policy-bounces@lists.apnic.net [mailto:sig-policy- bounces@lists.apnic.net] On Behalf Of Izumi Okutani Sent: Thursday, September 27, 2007 8:30 AM To: David Conrad Cc: Randy Bush; sig-policy@lists.apnic.net Subject: Re: [sig-policy] prop-046: IPv4 countdown policy proposal
returning to mailing list for development
Hi, I've commented inline.
David Conrad wrote: [...]
- IANA to distribute a single /8 to each RIR when the IANA free pool hits 5 /8s. This date is defined as 'IANA Exhaustion
Date'.
Seems fine, although just to be explicit:
Suppose there are 6 /8s remaining in the free pool. An RIR comes
to
IANA and indicates they want another allocation. Current
practice is
to allocate 2 /8s (if justified). IANA allocates the 2 /8s,
leaving
4 /8s. The obvious approach would be to allocate the remaining 4
/8s
to the other 4 RIRs. Is that the intent?
right, thanks for clarifying.
... and a single /8 will be distributed to *5* RIRs if the RIR requested for 1 /8 instead of 2 /8s.
(i.e.the requesting RIR gets 2 /8s in total, remaining four RIRs
get 1)
[...]
- RIRs should provide an official projection on the IANA
Exhaustion
Date to the community.
I'm not sure I see the point of having 5 different 'official' projections.
Not for job security for researchers though I did like the idea :-
).
We weren't actually expecting each RIR to come with their own projections, but for them to provide latest information based on projections already available.
(which RIRs consider as reliable)
- RIRs should maintain the current address distribution
criteria
until the IANA Exhaustion Date.
Perhaps not too surprisingly, I disagree with this particular clause. By analogy, we're driving down a road at 100 KPH and we
see
a brick wall ahead of us. This clause requires us to put the car
on
cruise control and close our eyes until we're about a meter from
the
wall.
What is the rationale for this clause?
The idea is to ensure LIRs can receive IPv4 address space they need (based on justifications) until the last minute with minimum
confusion.
Going by road analogy, you increase confusion for drivers if you add extra rules changing from time to time, which may lead to accidents/traffic jam. Our intention is to avoid confusion by maintaining a consistent rule.
I would think a more rational approach would be for each RIR to encourage IPv4 conservation using whatever policies make sense in their region.
That could be one approach, and this is the part we intend to
discuss
as regional policies after IED (presented as informational in
APNIC24).
- Is this proposal addressing a real need or problem?
It isn't clear to me what problem this policy is attempting to
address. When the remaining IANA pool is 5 /8s (or less), there are not
enough
blocks for all RIRs on consumption basis.
You can't tell if your turn to request will come before the IANA
pool
runs out as it all depends on timing of your + other RIRs' request.
This makes it more difficult for RIRs to plan distribution of the available pool in their regions.
- What advantages are there to distributing the last remaining /8 blocks equally to the RIRs?
Encouraging investment in developing countries by large ISPs in developed countries?
:-) I understand your point, but I imagine a single /8 won't
attract
too many investors. It probably won't last for more than few months to
meet
their needs.
I know quite a number of people are concerned about this point, so
I'd
be interested to hear more details on what people see as an issue.
izumi
sig-policy: APNIC SIG on resource management policy
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
sig-policy: APNIC SIG on
resource management policy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
sig-policy: APNIC SIG on resource management policy
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Activity Summary
- 5904 days inactive
- 5904 days old
- sig-policy@lists.apnic.net
- 2 participants
- 1 comments