[rpd] Draft inbound policy

[McTim]

Ok, so it has to be tracked in RS software but NOT added to Afrinic DB
witha "status"?

Or added to the database AND tracked by RS software?

I would support it either way, but just want to make implementation
clear for all.





On Fri, Jun 17, 2016 at 9:02 AM, Andrew Alston
<Andrew.Alston at liquidtelecom.com> wrote:
> Hi McTim,
>
> As to your first question, initially when Chris and I wrote this, we restricted the policy to v4 resources and 16 bit ASN’s, but after some reflection we decided to make it cover all resources.  The wording you see there is left over from that, and we are happy to revise it if necessary.
>
> What we meant be adding it to the AfriNIC database, is that if an organization had a /16 before a transfer, and they transferred in another /16, AfriNIC would consider them for all intensive purposes as having a /15, that is for billing purposes and evaluation purposes should the organization apply to AfriNIC for more space.
>
> Basically, any space transferred in, becomes as if it were a normal allocation post transfer, irrespective of if it used to be legacy or not.
>
> Thanks
>
> Andrew
>
> On 17/06/2016, 3:31 PM, "McTim" <dogwallah at gmail.com> wrote:
>
>>I can support this.
>>
>>I can't imagine anyone could have any objection to such a policy.
>>
>>Question:  What does "AfriNIC shall accept all inbound transfers of
>>all resources explicitly referred to in section 2"  mean?
>>
>>Does it mean that Afrinic will enter the space in the Afrinic
>>database?  What STATUS: would it have?
>>
>>Thanks,
>>
>>McTim
>>
>>
>>
>>On Fri, Jun 17, 2016 at 5:09 AM, Andrew Alston
>><Andrew.Alston at liquidtelecom.com> wrote:
>>> Hi All,
>>>
>>> The following has been submitted to policy-submission and I am also posting it here for discussion in the mean time.
>>>
>>> Thanks
>>>
>>> Andrew
>>>
>>> Draft Policy Name: Inbound Transfer Policy
>>> Unique Identifier:
>>> Status: Under Discussion
>>> Submission Date: 17 June 2016
>>> Amends: N/A
>>>
>>> Author(s):
>>> a. Andrew Alston (andrew.alston at liquidtelecom.com)
>>> b. Christopher Mwangi (Christopher.mwangi at liquidtelecom.com)
>>>
>>>
>>> 1. Introduction:
>>> The AfriNIC Service Region has the lowest amount of IPv4 space of any of the RIR defined regions.  As such, when AfriNIC depletes its current space, there will still be a need for further IPv4 addresses on the continent. In addition to this, there may be circumstances where companies wish to use specific v6 resources and ASN’s unavailable on the continent.
>>>
>>> While the community has voiced concerns that enacting a transfer policy will result in the flow of resources off the continent, this policy addresses that by purely catering for inbound transfers, without allowing or affecting transfers flowing out of the continent to other RIR service regions.
>>>
>>> 2. Resources covered under this policy
>>> This policy covers the inbound transfer of all IP resources, including ASN’s, both 16bit and 32bit, IPv4 space and IPv6 space
>>>
>>> 3. Details of inbound transfer requirements
>>> AfriNIC shall accept all inbound transfers of all resources explicitly referred to in section 2
>>> For transfers into the region, the recipient of IP space (v4 or v6) must provide a plan to AfriNIC for the use of at least 50% of the transferred resource within the next 5 years.
>>> Once received, the space shall form part of the recipient’s normal allocations for the purpose of evaluating the size of the recipient from an AfriNIC membership perspective.
>>> Should a recipient of transferred space apply for further resources from AfriNIC directly, all space received via transfers shall be included in any evaluation done for further resource allocation by AfriNIC.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> RPD mailing list
>>> RPD at afrinic.net
>>> https://lists.afrinic.net/mailman/listinfo/rpd
>>
>>
>>
>>--
>>Cheers,
>>
>>McTim
>>"A name indicates what we seek. An address indicates where it is. A
>>route indicates how we get there."  Jon Postel
>>
>



-- 
Cheers,

McTim
"A name indicates what we seek. An address indicates where it is. A
route indicates how we get there."  Jon Postel