Re: [sig-policy] prop-119: Temporary transfers, to be discussed at APNIC 44 Polic y SIG
Dear David,
Thaank you for your comment.
The main point of our concern is if proposed with a set with prop-118,
it may encourage the IP address to be used for abusive activities, to
be able to regularly change IP address in a short time span.
Please see my comments inline as clarifications on feedback from the
Japanese community.
2017-09-08 17:52 GMT+08:00 David Hilario <d.hilario@laruscloudservice.net>:
> Dear Satoru,
>
> Thank you for conveying the feedback here.
>
>
> On 8 September 2017 at 09:32, Satoru Tsurumaki
> <satoru.tsurumaki@g.softbank.co.jp> wrote:
>> Dear Colleagues,
>>
>>
>> Satoru Tsurumaki, with Policy Working Group hat.
>>
>> I would like to share key feedback in our community for prop-119,
>> based on a meeting we organised on 5th Sep to discuss these proposals.
>>
>>
>> Many comments against this proposal were expressed. On the other hand,
>> some expressed support for temporary transfer as a measure to increase
>> accuracy in database.
>>
>>
>> Concerns/Opposing comments:
>> * Cannot understand the need of leasing, nor use of prefixes where
>> leasing is appropriate. Leasing of address space could encourage
>> prefixes to be used for abuse. (As it accommodates change of address
>> range if black listed)
>>
>
> The space will come from one LIR and returned to the same LIR.
> It really isn't the offering LIRs interest to have their space blacklisted.
> This is not different than when an LIR issues an IP delegation such as
> an Assignment of sub-allocation in the APNIC Database, just the lease
> is a bit more "formal: in that it is shown as a transfer of authority
> in the Database.
>
>> * It will be costly to the APNIC region to adopt complex scheme of leasing.
>>
>
> Same procedure as with any regular transfer, with the addition of a
> return timer.
> That should not be too costly.
I wasn't being clear enough here.
It will require some changes in APNIC database/WHOIS and add/change
the operations of hostmaster to accommodate temporary transfers as
well as for NIRs. The comment here was that it is not sure whether
there is enough benefit to balance these costs (which is not just
direct financial costs).
>
>> * Leasing should not be allowed to a third party where lease source do
>> not provide connectivity, to avoid fragmentation. Leasing should be
>> only within the scope where LIRs can take responsibility.
>>
>
> LIRs are currently allowed to issue address space to other
> organisation by giving them either Assignments or sub-allocations
> depending on their needs of their customers.
>
> So Policy wise this is already a fact that it is allowed, the
> temporary transfers would only formalise the transfer of authority in
> the APNIC database, also giving the recipient access to all the
> required tools to manage the space via MyAPNIC just like any other
> address space they have.
The implications of allowing lease to those who have connectivity with
LIRs and those who do not are not the same.
Under the current policy, LIRs must only delegate address space to
networks which they provide connectivity.
https://www.apnic.net/community/policy/resources#Part-1:-Policy-Environment
3.1.3. Aggregation
Address policies should seek to avoid fragmentation of address ranges.
Wherever possible, address space should be distributed in a
hierarchical manner, according to the topology of network
infrastructure. This is necessary to permit the aggregation of routing
information by network operators, and to limit the expansion of
Internet routing tables.
This goal is particularly important in IPv6 addressing, where the size
of the total address pool creates significant implications for both
internal and external routing.
It is a condition of all delegations made under initial or subsequent
LIR delegation criteria, that the address space is aggregated by the
LIR within a minimum number of route announcements (preferably one).
LIRs must only delegate addresses to customers who will be using those
addresses in relation to network connectivity services provided by the
LIR.
LIRs are expected to enter into agreements with their customers
specifying that the end-user will hold the addresses only for so long
as the end-user remains a customer of that LIR. Such agreements should
also be consistent with the license under which the address space is
being used by the LIR.
>
>
>> Supportive comments/Suggestions:
>> * It is better to allow temporary transfers and reflect the correct
>> user of an address prefix, than a situation where registry database
>> can no longer point to correct user of a prefix
>> * Period of lease should be specified, such as for two years
>
> That should be specified and agreed upon by the offering and receiving
> parties and communicated to APNIC.
>
>> * A suggestion to evaluate purpose of the address usage when approving
>> its request
>
> It should be evaluated like any other transfer.
> No distinction in the process, if the need base policy is still there,
> then it should be evaluated with a need base evaluation and approval.
"prop-118: No need policy in APNIC region, to be dis cussed at APNIC
44 Policy SIG" is proposed by yourself, to remove needs base
evaluation.
This suggestion to evaluate the purpose is hopefully to minimise
leased address space to be used for abuse,
>
>>
>>
>> Best Regards,
>>
>> Satoru Tsurumaki
>> Policy Working Group
>> Japan Open Policy Forum
>>
>> 2017-08-09 15:16 GMT+09:00 chku <chku@twnic.net.tw>:
>>> Dear SIG members
>>>
>>> The proposal "prop-119: Temporary transfers" was sent to the Policy SIG
>>> Mailing list in May 2017.
>>>
>>> It will be presented at the Open Policy Meeting at APNIC 44 which will
>>> be held in Taichung, Taiwan on Wednesday and Thursday, 14 & 15 September
>>> 2017.
>>>
>>> Information about the proposal is available from:
>>>
>>> http://www.apnic.net/policy/proposals/prop-119
>>>
>>> You are encouraged to express your views on the proposal:
>>>
>>> - Do you support or oppose the proposal?
>>> - Do you see any disadvantages in this proposal?
>>> - Is there anything in the proposal that is not clear?
>>> - What changes could be made to this proposal to make it more effective?
>>>
>>> Please find the text of the proposal below.
>>>
>>> Kind Regards,
>>>
>>> Sumon, Ching-Heng, Bertrand
>>> APNIC Policy SIG Chairs
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> prop-119-v001: Temporary transfers
>>>
>>> ------------------------------------------------------------------------
>>>
>>> Proposer: David Hilario
>>> d.hilario@laruscloudservice.net
>>>
>>> 1. Problem statement
>>> ------------------------------------------------------------------------
>>>
>>> It is currently not possible for an organisation to receive a temporary
>>> transfer under the current policy framework. Some organisations do not
>>> want to have address space registered as assignments or sub-allocations,
>>> but would rather have the address space registered as "ALLOCATED PA".
>>>
>>>
>>> 2. Objective of policy change
>>> ------------------------------------------------------------------------
>>>
>>> Create a possibility for temporary transfers that would allow
>>> organisations to have resources directly registered under them while
>>> they are the custodians of these resources on the Internet. While also
>>> guaranteeing that the offering party will under the APNIC policy be able
>>> to recover the resources once the “lease” time has expired unless
>>> specifically renewed.
>>>
>>>
>>> 3. Situation in other regions
>>> ------------------------------------------------------------------------
>>>
>>> RIPE region has a concept of temporary transfers in their policies. This
>>> concept is not found in the other RIRs for the moment.
>>>
>>>
>>> 4. Proposed policy solution
>>> ------------------------------------------------------------------------
>>>
>>> Adding to section "8.2.1. Conditions on the space to be transferred" the
>>> following paragraphs: It must be specified if the transfer is a
>>> permanent or temporary transfer.
>>>
>>> A temporary transfer must have an end date, upon the end date the
>>> resources will be transferred back to the same origin account or its
>>> successor in the event of merger and acquisitions, unless the transfer
>>> is specifically prolonged and confirmed by both parties.
>>>
>>> If the source account does no longer exist and has no successor, the
>>> space will then be returned to the origin RIR for the space. Temporary
>>> transfers cannot be further transferred.
>>>
>>>
>>> 5. Advantages / Disadvantages
>>> ------------------------------------------------------------------------
>>>
>>> Advantages:
>>> Gives a greater flexibility in how LIRs manage and distribute their free
>>> pool. Enables organisation to receive address space in the way they
>>> intend.
>>>
>>> Disadvantages:
>>> These transfers would be treated and appear as regular transfers, only
>>> APNIC the offering and receiving party will be aware of their temporary
>>> nature.
>>>
>>> Organisations receiving such space, if they further assign it, must make
>>> be ready to renumber/revoke space from their customers and services then
>>> the lease expires, this is no different than a sub-allocation and
>>> implies the same limitations.
>>>
>>>
>>> 6. Impact on resource holders
>>> ------------------------------------------------------------------------
>>> none
>>>
>>>
>>> 7. References
>>> -------------
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Sig-policy-chair mailing list
>>> Sig-policy-chair@apnic.net
>>> https://mailman.apnic.net/mailman/listinfo/sig-policy-chair
>>>
>>> * sig-policy: APNIC SIG on resource management policy *
>>> _______________________________________________
>>> sig-policy mailing list
>>> sig-policy@lists.apnic.net
>>> https://mailman.apnic.net/mailman/listinfo/sig-policy
>> * sig-policy: APNIC SIG on resource management policy *
>> _______________________________________________
>> sig-policy mailing list
>> sig-policy@lists.apnic.net
>> https://mailman.apnic.net/mailman/listinfo/sig-policy
>
>
> David Hilario
>
> IP Manager
>
> Larus Cloud Service Limited
>
> p: +852 29888918 m: +359 89 764 1784
> f: +852 29888068
> a: Flat B5, 11/F, TML Tower, No.3 Hoi Shing Road, Tsuen Wan, HKSAR
> w: laruscloudservice.net
> e: d.hilario@laruscloudservice.net