Re: [sig-policy] New proposal prop-122-v001: Updating "Subsequent IPv6 a

    • To: SIG policy <sig-policy at apnic dot net>
    • Subject: Re: [sig-policy] New proposal prop-122-v001: Updating "Subsequent IPv6 allocation " policy
    • From: JORDI PALET MARTINEZ <jordi.palet at consulintel dot es>
    • Date: Sat, 09 Sep 2017 12:42:42 +0800
    • Delivered-to: sig-policy at mailman dot apnic dot net
    • Dkim-signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1504932166; x=1505536966; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=vdj2uEiazyUh9quzRZxx1ipkA gW++V2I/Wz4ekYTi48=; b=i2E1IbevSMXSMeZJWDfVp5200NbfMAtKFbSoL9TPG 4Id3Y6bm5R3eG0ozEYXQXkNZMBIDt4j9TvFjYxhJwZQ2DX6kVvnVFB+OCirmPwE4 ZxNK4N/gFg4GxnvoQQYrYe/Rywi7AGUTgyoa3/oWVt7a8I1fpKxGmPNkutlgHkKz zA=
    • Domainkey-signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=Ih7TNE001z/zDtW/uWEb5OdlDVuTC9m8CVzuczFUWeW1x0mw4h9rKt/vU0FI NUlusg6lOBIM0thMER7XF1v4JV/QkhhZZnTIvju6zQixu78/J1WtYP+5Y cO+QKOH26rsZL75+cjFUlqOqmN2ZxXIniISFFsJ5IozTlMeZqS+45A=;
    • In-reply-to: <CAHXx+kTUimGT0F1r1t3iQ_TAL7VPZQGtjGnEOavhkqaLhV5RgA@mail.gmail.com>
    • List-archive: <http://mailman.apnic.net/mailing-lists/sig-policy/>
    • List-help: <mailto:sig-policy-request@lists.apnic.net?subject=help>
    • List-id: APNIC SIG on resource management policy <sig-policy.lists.apnic.net>
    • List-post: <mailto:sig-policy@lists.apnic.net>
    • List-subscribe: <https://mailman.apnic.net/mailman/listinfo/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=subscribe>
    • List-unsubscribe: <https://mailman.apnic.net/mailman/options/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=unsubscribe>
    • References: <1502259601.65733.chku@twnic.net.tw> <CAHXx+kTUimGT0F1r1t3iQ_TAL7VPZQGtjGnEOavhkqaLhV5RgA@mail.gmail.com>
    • Reply-to: jordi.palet@consulintel.es
    • Thread-topic: [sig-policy] New proposal prop-122-v001: Updating "Subsequent IPv6 allocation " policy
      • 
        Regards,
        Jordi
         
        
        -----Mensaje original-----
        De: <sig-policy-bounces at lists dot apnic dot net> en nombre de Satoru Tsurumaki <satoru.tsurumaki at g.softbank dot co dot jp>
        Responder a: <satoru.tsurumaki at g.softbank dot co dot jp>
        Fecha: viernes, 8 de septiembre de 2017, 14:34
        Para: SIG policy <sig-policy at apnic dot net>
        Asunto: Re: [sig-policy] New proposal prop-122-v001: Updating "Subsequent IPv6 allocation " policy
        
            Dear Colleagues,
            
            
            I am Satoru Tsurumaki from Policy Working Group in Japan.
            
            I would like to share key feedback in our community for prop-122,
            based on a meeting we organised on 5th Sep to discuss these proposals.
            
            
            Many opposing comments were expressed with the same reasons as for prop-121.
            
            * Under the current criteria, networks with IPv4 can receive IPv6
            easily. However, with adoption of this proposal, this consideration
            based on IPv4 network will be removed, and the policy could become
            more strict for some applications.
            
            * Would like to confirm how specifically APNIC secretariat will
            evaluate requests under this policy. The criteria becomes ambiguous
            with this proposal which would make it harder for applications to
            prepare for the evaluation.
            
            * Approach may not be the right one to achieve the objective of IPv6 promotion
            
            * From the current IPv6 allocation criteria, it is unlikely to have
            many cases where criteria. d is being the barrier to receive IPv6
            space.
            
            
            Best Regards,
            
            Satoru Tsurumaki
            Policy Working Group
            Japan Open Policy Forum
            
            2017-08-09 15:20 GMT+09:00 chku <chku at twnic dot net dot tw>:
            > Dear SIG members
            >
            > The proposal "prop-122-v001: Updating "Subsequent IPv6 allocation"
            > policy. " has been sent to the Policy SIG for review.
            >
            > 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.
            >
            > We invite you to review and comment on the proposal on the mailing list
            > before the meeting.
            >
            > The comment period on the mailing list before an APNIC meeting is an
            > important part of the policy development process. We encourage you to
            > express your views on the proposal:
            >
            >   - Do you support or oppose this proposal?
            >   - Does this proposal solve a problem you are experiencing? If so,
            >     tell the community about your situation.
            >   - 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?
            >
            > Information about this proposal is available at:
            >
            >     http://www.apnic.net/policy/proposals/prop-122
            >
            > Regards
            >
            > Sumon, Ching-Heng, Bertrand
            > APNIC Policy SIG Chairs
            >
            >
            > ------------------------------------------------------------------------
            >
            > prop-122-v001: Updating “Subsequent IPv6 allocation” policy
            >
            > ------------------------------------------------------------------------
            >
            > Proposer:       Jordi Palet Martinez
            >                 jordi.palet at consulintel dot es
            >
            > Problem Statement
            > -----------------
            > If we reach consensus on the Updating "Initial IPv6 allocation"
            > policy, it is necessary to align the text of the subsequent allocations,
            > in order to be coherent and not discriminate LIRs with existing
            > allocations.
            >
            > If consensus on that policy proposal is not reached, this proposal also
            > allows LIRs with existing allocations a better justification of their
            > new needs and not limited to a 2 years period.
            >
            > The actual policy text (9.3.4. Size of subsequent allocation) is
            > assuming that an LIR will need just doubling his actual block, and then
            > states the possibility of more space providing the relevant
            > documentation. However, it is limiting that to a two-years period.
            >
            >
            > Objective of policy change
            > --------------------------
            > To make sure that the subsequent IPv6 allocation policy is synchronized
            > with the initial allocation one.
            >
            >
            > Situation in other regions
            > --------------------------
            > Both RIPE and LACNIC have approved equivalent changes.
            >
            >
            > Proposed policy solution
            > ------------------------
            > Change some of the actual text as follows.
            >
            >
            > Actual text:
            >
            > 9.3.4. Size of subsequent allocation
            >
            > When an organization has achieved an acceptable utilization for its
            > allocated address space, it is immediately eligible to obtain an
            > additional allocation that results in a doubling of the address space
            > allocated to it. Where possible, except where separate disaggregated
            > ranges are requested for multiple discrete networks, the allocation will
            > be made from an adjacent address block, meaning that its existing
            > allocation is extended by one bit to the left.
            >
            > If an organization needs more address space, it must provide
            > documentation justifying its requirements for a two-year period. The
            > allocation made will be based on this requirement.
            >
            >
            > New text:
            >
            > 9.3.4. Size of subsequent allocation
            >
            > When an organization has achieved an acceptable utilization for its
            > allocated address space, it is immediately eligible to obtain an
            > additional allocation that results in a doubling of the address space
            > allocated to it.
            >
            > Where possible, except where separate disaggregated ranges are requested
            > for multiple discrete networks, the allocation will be made from an
            > adjacent address block, meaning that its existing allocation is extended
            > by one bit to the left.
            >
            > If an organization needs more address space, it must provide
            > documentation justifying its new requirements. The allocation size, will
            > be based on the new needs (the number of users, the extent of the
            > organisation's infrastructure, the hierarchical and geographical
            > structuring of the organisation, the segmentation of infrastructure for
            > security and the planned longevity of the allocation).
            >
            >
            > Advantages of the proposal
            > --------------------------
            > Fulfilling the objective above indicated.
            >
            >
            > Disadvantages of the proposal
            > -----------------------------
            > Possible abuse of the policy, which may be done equally creating new
            > LIRs, and it is expected that the evaluation process of a request from
            > APNIC will avoid it.
            >
            >
            > Impact on resource holders
            > --------------------------
            > None.
            >
            >
            > References
            > ----------
            > Links to the RIPE and LACNIC texts on request.
            >
            >
            >
            >
            >
            >
            >
            > _______________________________________________
            > Sig-policy-chair mailing list
            > Sig-policy-chair at apnic dot net
            > https://mailman.apnic.net/mailman/listinfo/sig-policy-chair
            >
            > *              sig-policy:  APNIC SIG on resource management policy           *
            > _______________________________________________
            > sig-policy mailing list
            > sig-policy at lists dot apnic dot net
            > https://mailman.apnic.net/mailman/listinfo/sig-policy
            *              sig-policy:  APNIC SIG on resource management policy           *
            _______________________________________________
            sig-policy mailing list
            sig-policy at lists dot apnic dot net
            https://mailman.apnic.net/mailman/listinfo/sig-policy
        
        
        
        **********************************************
        IPv4 is over
        Are you ready for the new Internet ?
        http://www.consulintel.es
        The IPv6 Company
        
        This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.