Trigger 2.3.2.18 when a justified request larger than /22 is received which can not be allocated from any remaining pool of addresses at LACNIC. - N/D

General information

English
20/02/2015
Implemented
100 %.

Mike Burns - Version [1, 2]
In discussion
11/03/2015
Last call for comments
30/09/2015 - 14/11/2015
Ratification by the board
15/11/2015
Ratified
14/12/2015
Implemented
14/03/2016

Summary

Problem Statement:

LACNIC is currently in Phase 2 of the its IPv4 Exhaust plan, and in this period there is no way for LACNIC members to acquire all the IPv4 addresses they require if their justified need is greater than a /22. This puts LACNIC members at a competitive disadvantage to the rest of the world. Never in history has any RIR prevented its members from receiving their justifiably needed addresses. In every case, when an RIR could not meet a request they deemed justified, the RIR allowed that request to be met by a transfer. In LACNIC, staff has interpreted the following policy language under 2.3.2.18 to mean that transfers may not begin yet, because the gradual reserve pool is not empty:

NOTE: This section will come into force when LACNIC or any of its NIRs becomes unable, for the first time, to cover an IPv4 block allocation or assignment because of lack of resources.

We believe that it would be in the best interests of all LACNIC members if staff interpreted the language above to mean that when a justified request is received by LACNIC which can not be provided by LACNIC for any reason, that 2.3.2.18 has been officially triggered.

Rationale (Describe the problem you intend to solve)

Triggering 2.3.2.18 will have no effect on the remaining free pool of addresses. Addresses can continue to be allocated for requests between /24 and /22, with the recipients able to return in six months. The New Member pool will also not be affected by triggering 2.3.2.18.

Failing to fix this policy loophole will increase the risk of out-of-policy, underground transfers which could lead to incorrect Whois information.

Currently there are LACNIC members with justified needs for addresses who are prevented by the failure to trigger 2.3.2.18 from acquiring what they need. Certainly this imposes a restriction on these businesses found nowhere else in the world.

Current text

Change text in 2.3.2.18 from :

NOTE: This section will come into force when LACNIC or any of its NIRs becomes unable, for the first time, to cover an IPv4 block allocation or assignment because of lack of resources.

to :

NOTE: This section will come into force when LACNIC or any of its NIRs becomes unable, for the first time, to cover an IPv4 block allocation or assignment to a member with a justified need of any size, for any reason.

New text
Analyze diff

Change text in 2.3.2.18 from :

NOTE: This section will come into force when LACNIC or any of its NIRs becomes unable, for the first time, to cover an IPv4 block allocation or assignment because of lack of resources.

to :

NOTE: This section will come into force when LACNIC or any of its NIRs becomes unable, for the first time, to cover an IPv4 block allocation or assignment to a member with a justified need of any size, for any reason.

Additional information

We are aware of companies in this predicament currently.

Timetable

.

References

NA

Presented at:

-


Summary

Problem Statement:

LACNIC is currently in Phase 2 of the its IPv4 Exhaust plan, and in this period there is no way for LACNIC members to acquire all the IPv4 addresses they require if their justified need is greater than a /22. This puts LACNIC members at a competitive disadvantage to the rest of the world. Never in history has any RIR prevented its members from receiving their justifiably needed addresses. In every case, when an RIR could not meet a request they deemed justified, the RIR allowed that request to be met by a transfer. In LACNIC, staff has interpreted the following policy language under 2.3.2.18 to mean that transfers may not begin yet, because the gradual reserve pool is not empty:

NOTE: This section will come into force when LACNIC or any of its NIRs becomes unable, for the first time, to cover an IPv4 block allocation or assignment because of lack of resources.

We believe that it would be in the best interests of all LACNIC members if staff interpreted the language above to mean that when a justified request is received by LACNIC which can not be provided by LACNIC for any reason, that 2.3.2.18 has been officially triggered.

Rationale (Describe the problem you intend to solve)

Triggering 2.3.2.18 will have no effect on the remaining free pool of addresses. Addresses can continue to be allocated for requests between /24 and /22, with the recipients able to return in six months. The New Member pool will also not be affected by triggering 2.3.2.18.

Failing to fix this policy loophole will increase the risk of out-of-policy, underground transfers which could lead to incorrect Whois information.

Currently there are LACNIC members with justified needs for addresses who are prevented by the failure to trigger 2.3.2.18 from acquiring what they need. Certainly this imposes a restriction on these businesses found nowhere else in the world.

Current text

Remove text in 2.3.2.18 :

NOTE: This section will come into force when LACNIC or any of its NIRs becomes unable, for the first time, to cover an IPv4 block allocation or assignment because of lack of resources.

New text
Analyze diff

Remove text in 2.3.2.18 :

NOTE: This section will come into force when LACNIC or any of its NIRs becomes unable, for the first time, to cover an IPv4 block allocation or assignment because of lack of resources.

Additional information

We are aware of companies in this predicament currently.

Timetable

.

References

NA

Presented at:

LACNIC 23 (18/05/2015)

--> --> --> --> --> -->