Hi Masato ,

I support this prop-116-v002






*Regards / Jahangir *On Sun, Oct 2, 2016 at 1:28 PM, Masato Yamanishi <
[email protected]> wrote:

> Dear Jahangir,
>
> So, do you support prop-116-v002 as written or oppose?
>
> Regards,
> Matt
>
>
> 2016-10-02 16:12 GMT+09:00 Jahangir Hossain <[email protected]>:
>
>> Dear all ,
>>
>> I'm latecomer of the race to get IPv4 . So as a latecomer of  the
>> community, may i have a last option or opportunity to get resources ?
>>
>> According to transfer statistics and member of this community, we are
>> responsible for maintaining the number resources policy and update when
>> needed for the community .
>>
>>
>> *Regards / Jahangir *
>>
>> On Fri, Sep 30, 2016 at 4:04 PM, Hiroki Kawabata <[email protected]>
>> wrote:
>>
>>> If the current situation of 103/8 distribution is different from the
>>> intention
>>> and concept of prop-062(*) as described in the proposal, I think we need
>>> to discuss it
>>> and revise the policy as necessary.
>>>
>>>   (*)103/8 block is intended to accommodate minimum IPv4 address block
>>>      for new comers.
>>>
>>>      prop-062: Use of final /8
>>>      https://www.apnic.net/policy/proposals/prop-062
>>>
>>> I think our community is responsible for maintaining the number
>>> resources policy.
>>> Regardless of IPv4 or IPv6, it is not appropriate to leave the policy
>>> untouched,
>>> and not to maintain what we have developed.
>>>
>>> Regards,
>>> Hiroki
>>>
>>> Subject: Re: [sig-policy] New version of prop-116: Prohibit to transfer
>>> IPv4 addresses in the final /8 block (SECURITY=UNCLASSIFIED)
>>> From: Mark Foster <[email protected]>
>>> Date: Tue Sep 27 2016 09:14:57 GMT+0900
>>>
>>> I agree that there's an element of 'deck chair rearrangement' but it's a
>>>> reality that there is a commercial market for IPv4 and competitive value in
>>>> having addresses available. To simply say 'who cares about IPv4, move on'
>>>> will simply encourage predatory practices.
>>>>
>>>> I have no doubt that the M&A process will be used to abuse the process,
>>>> and believe there needs to be a deterrent to the abuse of the bureaucratic
>>>> process.
>>>> But legitimate M&A needs to be permitted (having had to engage this
>>>> process in the last couple of years due to organisational and commercial
>>>> changes at my then-employer, I wouldn't want to see that process made any
>>>> more complex than necessary).
>>>>
>>>> I think that the modified proposal has merit for that reason, and would
>>>> support it.
>>>>
>>>> Mark.
>>>>
>>>>
>>>> On Tue, Sep 27, 2016 at 8:50 AM, Alastair Johnson <[email protected]
>>>> <mailto:[email protected]>> wrote:
>>>>
>>>>     I agree with Mike. I don't support this proposal.
>>>>
>>>>     AJ
>>>>
>>>>     On Sep 26, 2016, at 2:26 PM, HENDERSON MIKE, MR <
>>>> [email protected] <mailto:[email protected]>>
>>>> wrote:
>>>>
>>>>     The objectives of this proposal are laudable, but in my view policy
>>>>> development for IPv4 is just ‘rearranging the deck chairs on the Titanic’:
>>>>> a waste of time and effort.____
>>>>>
>>>>>     __ __
>>>>>
>>>>>     __ __
>>>>>
>>>>>     I do *not* support this proposal____
>>>>>
>>>>>     __ __
>>>>>
>>>>>     __ __
>>>>>
>>>>>     Regards____
>>>>>
>>>>>     __ __
>>>>>
>>>>>     __ __
>>>>>
>>>>>     */Mike/*____
>>>>>
>>>>>     __ __
>>>>>
>>>>>     *From:*[email protected] <mailto:
>>>>> [email protected]> [mailto:sig-policy-bounces@lis
>>>>> ts.apnic.net <mailto:[email protected]>] *On Behalf
>>>>> Of *Masato Yamanishi
>>>>>     *Sent:* Monday, 26 September 2016 11:06 p.m.
>>>>>     *To:* [email protected] <mailto:[email protected]
>>>>> .net>
>>>>>     *Subject:* [sig-policy] New version of prop-116: Prohibit to
>>>>> transfer IPv4 addresses in the final /8 block____
>>>>>
>>>>>     __ __
>>>>>
>>>>>     Dear SIG members
>>>>>
>>>>>     A new version of the proposal "prop-116: Prohibit to transfer IPv4
>>>>>     addresses in the final /8 block" has been sent to the Policy SIG
>>>>> for
>>>>>     review.
>>>>>
>>>>>     Information about earlier versions is available from:
>>>>>
>>>>>     http://www.apnic.net/policy/proposals/prop-116 <
>>>>> http://www.apnic.net/policy/proposals/prop-116>
>>>>>
>>>>>     You are encouraged to express your views on the proposal:
>>>>>
>>>>>      - Do you support or oppose the 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,
>>>>>
>>>>>     Masato, Sumon
>>>>>
>>>>>     -------------------------------------------------------
>>>>>
>>>>>     prop-116-v002: Prohibit to transfer IPv4 addresses in the final /8
>>>>> block
>>>>>
>>>>>     -------------------------------------------------------
>>>>>
>>>>>     Proposer:       Tomohiro Fujisaki
>>>>>                     [email protected] <mailto:[email protected]>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>     1. Problem statement
>>>>>     --------------------
>>>>>
>>>>>     There are a lot of transfers of IPv4 address blocks from 103/8
>>>>>     happening, both within the APNIC region and among RIRs.
>>>>>
>>>>>     Then number of transfer from 103/8 block are about 200, which is
>>>>>     about 12% of the total number of transfers. This looks so hight
>>>>>     high, since APNIC manages about 40/8.
>>>>>
>>>>>     And based on the information provided by APNIC secretariat, number
>>>>>     of transfers from the 103/8 block are increasing year by year.
>>>>>
>>>>>     Provided by George Kuo on the sig-policy ML at 8th September 2016:
>>>>>
>>>>>     1) M&A transfers containing 103/8 space
>>>>>
>>>>>     +------+-----------+-----------+-
>>>>>     |      |   Total   | Number of |
>>>>>     | Year | Transfers |   /24s    |
>>>>>     +------+-----------+-----------+-
>>>>>     | 2011 |         3 |         12 |
>>>>>     | 2012 |        10 |         46 |
>>>>>     | 2013 |        18 |         66 |
>>>>>     | 2014 |       126 |        498 |
>>>>>     | 2015 |       147 |        573 |
>>>>>     | 2016 |        45 |        177 |
>>>>>     +------+-----------+------------+-
>>>>>
>>>>>     2) Market transfers containing 103/8 space
>>>>>
>>>>>     +------+-----------+-----------+
>>>>>     |      |   Total   | Number of |
>>>>>     | Year | Transfers |   /24s    |
>>>>>     +------+-----------+-----------+
>>>>>     | 2011 |         2 |         2 |
>>>>>     | 2012 |        21 |        68 |
>>>>>     | 2013 |        16 |        61 |
>>>>>     | 2014 |        25 |        95 |
>>>>>     | 2015 |        67 |       266 |
>>>>>     | 2016 |        56 |       206 |
>>>>>     +------+-----------+-----------+
>>>>>
>>>>>
>>>>>     And also, transfers from the 103/8 block include:
>>>>>       - Take place within 1 year of distribution, or
>>>>>       - Multiple blocks to a single organization in case of beyond 1
>>>>> year.
>>>>>
>>>>>     Further, there is a case where a single organization have received
>>>>> 12
>>>>>     blocks transfers from 103 range.
>>>>>
>>>>>     see:  https://www.apnic.net/transfer-resources/transfer-logs <
>>>>> https://www.apnic.net/transfer-resources/transfer-logs>
>>>>>
>>>>>     From these figures, it is quite likely that substantial number of
>>>>> 103/8
>>>>>     blocks are being used for transfer purpose.
>>>>>
>>>>>     This conflicts with the concept of distribution of 103/8 block
>>>>>     (prop-062), which is intended to accommodate minimum IPv4 address
>>>>> blocks
>>>>>     for new comers.
>>>>>
>>>>>    prop-062: Use of final /8
>>>>>    https://www.apnic.net/policy/proposals/prop-062 <
>>>>> https://www.apnic.net/policy/proposals/prop-062>
>>>>>
>>>>>
>>>>>
>>>>>     2. Objective of policy change
>>>>>     -----------------------------
>>>>>
>>>>>     When stated problem is solved, distribution from 103/8 block will
>>>>> be
>>>>>     consistent with its original purpose, for distribution for new
>>>>> entrants
>>>>>     to the industry. Without the policy change, substantial portion of
>>>>> 103/8
>>>>>     blocks will be consumed for transfer purpose.
>>>>>
>>>>>
>>>>>     3. Situation in other regions
>>>>>     -----------------------------
>>>>>
>>>>>     RIPE-NCC has been discussing to prohibit transfer under the final
>>>>> /8
>>>>>     address block.
>>>>>
>>>>>
>>>>>     4. Proposed policy solution
>>>>>     ---------------------------
>>>>>
>>>>>     Prohibit transfer IPv4 address under /8 address block (103/8).
>>>>>     If the address block allocated to a LIR is not needed any more, it
>>>>> have
>>>>>     to return to APNIC to allocate to another organization.
>>>>>
>>>>>     In the case of transfers due to M&A, merged organization can have
>>>>>     up to /22 IPv4 address in the 103/8 block. The 103/8 IPv4 address
>>>>>     more than /22  have to return to APNIC to allocate to another
>>>>>     organization.
>>>>>
>>>>>
>>>>>     5. Advantages / Disadvantages
>>>>>     -----------------------------
>>>>>
>>>>>     Advantages:
>>>>>       - It makes 103/8 blocks available according to the original
>>>>> purpose,
>>>>>         as distribution for new entrants (rather than being consumed
>>>>> for
>>>>>         transfer purpose)
>>>>>
>>>>>       - IPv4 addresses under final /8 are not transferred to outside
>>>>> APNIC.
>>>>>
>>>>>       - By prohibiting transfer them, it is possible to keep one /22
>>>>> for
>>>>>         each LIRs state,  which is fair for all LIRs.
>>>>>
>>>>>     Disadvantages:
>>>>>
>>>>>     None.
>>>>>
>>>>>
>>>>>     6. Impact on resource holders
>>>>>     ------------------------------
>>>>>
>>>>>       - LIRs cannot transfer address blocks under 103/8. No big impact
>>>>> while
>>>>>         they use it.
>>>>>
>>>>>       - Organizations which needs to receive transferred IPv4 can
>>>>> continue
>>>>>         to do so, outside 103/8 blocks (which should be made available
>>>>> for
>>>>>         new entrants)
>>>>>
>>>>>
>>>>>     7. References
>>>>>     -------------____
>>>>>
>>>>>     The information contained in this Internet Email message is
>>>>> intended for the addressee only and may contain privileged information, 
>>>>> but
>>>>> not necessarily the official views or opinions of the New Zealand Defence
>>>>> Force.  If you are not the intended recipient you must not use, disclose,
>>>>> copy or
>>>>>     distribute this message or the information in it.  If you have
>>>>> received this message in error, please Email or telephone the sender
>>>>> immediately.
>>>>>     *              sig-policy:  APNIC SIG on resource management
>>>>> policy           *
>>>>>     _______________________________________________
>>>>>     sig-policy mailing list
>>>>>     [email protected] <mailto:[email protected]>
>>>>>     https://mailman.apnic.net/mailman/listinfo/sig-policy <
>>>>> https://mailman.apnic.net/mailman/listinfo/sig-policy>
>>>>>
>>>>
>>>>     *              sig-policy:  APNIC SIG on resource management
>>>> policy           *
>>>>     _______________________________________________
>>>>     sig-policy mailing list
>>>>     [email protected] <mailto:[email protected]>
>>>>     https://mailman.apnic.net/mailman/listinfo/sig-policy <
>>>> https://mailman.apnic.net/mailman/listinfo/sig-policy>
>>>>
>>>>
>>>>
>>>>
>>>> *              sig-policy:  APNIC SIG on resource management policy
>>>>        *
>>>> _______________________________________________
>>>> sig-policy mailing list
>>>> [email protected]
>>>> https://mailman.apnic.net/mailman/listinfo/sig-policy
>>>>
>>>> *              sig-policy:  APNIC SIG on resource management policy
>>>        *
>>> _______________________________________________
>>> sig-policy mailing list
>>> [email protected]
>>> https://mailman.apnic.net/mailman/listinfo/sig-policy
>>>
>>
>>
>>
>> --
>>
>>
>> *              sig-policy:  APNIC SIG on resource management policy
>>      *
>> _______________________________________________
>> sig-policy mailing list
>> [email protected]
>> https://mailman.apnic.net/mailman/listinfo/sig-policy
>>
>
>


--
*              sig-policy:  APNIC SIG on resource management policy           *
_______________________________________________
sig-policy mailing list
[email protected]
https://mailman.apnic.net/mailman/listinfo/sig-policy

Reply via email to