Dear All,
I'm commenting on the proposals in my personal capacity.
In the first place, APNIC secretariat only refused very few requests, who fails
to demonstrate the need for the transfer, and if anyone wants to grow their
network, they have IPv6 address space available, I think the network should
also demonstrate they are not capable of deploying IPv6 address space in their
networks. This policy proposal will only help address brokers and will hinder
the growth of IPv6 networks.
Thanks & Regards,
Shiva Upadhyay
On Tuesday, 11 September, 2018, 8:32:59 AM IST,
<sig-policy-requ...@lists.apnic.net> wrote:
Send sig-policy mailing list submissions to
sig-policy@lists.apnic.net
To subscribe or unsubscribe via the World Wide Web, visit
https://mailman.apnic.net/mailman/listinfo/sig-policy
or, via email, send a message with subject or body 'help' to
sig-policy-requ...@lists.apnic.net
You can reach the person managing the list at
sig-policy-ow...@lists.apnic.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of sig-policy digest..."
Today's Topics:
1. Re: A new version of the proposal "prop-118: No need policy
in APNIC region" (Satoru Tsurumaki)
2. Re: Prop124 version 4 (Satoru Tsurumaki)
----------------------------------------------------------------------
Message: 1
Date: Tue, 11 Sep 2018 14:01:06 +1100
From: Satoru Tsurumaki <satoru.tsurum...@g.softbank.co.jp>
To: "sig-pol...@apnic.net" <sig-pol...@apnic.net>
Subject: Re: [sig-policy] A new version of the proposal "prop-118: No
need policy in APNIC region"
Message-ID:
<CAHXx+kRXg3ReO_8PBPnR_jTcxhQ+fZAMKzKz0shQqsto=e-...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
*Dear Colleagues,I am Satoru Tsurumaki from Japan Open Policy Forum.I would
like to share key feedback in our community for prop-118,based on a meeting
we organised on 22nd Aug to discuss these proposals.Many supporting
opinions were expressed on this proposal.However, many comments were
expressed that proposer should feedback for the discussion which we
discussed in past OPM. Below are details of opinions expressed. - Demand
for 5 years: It is difficult to clarify a demand of address needs for both
APNIC and LIR. - The policy should be looser. it will increase a
possibilities of address transfer if time frame are expand from 2 years to
5 years. - The reason why APNIC clarify the request of transfer is for
tranferring from ARIN. So inter-APNIC case, it not need originally and
there is no reason to make a a clarification strictly.I agree with the
purpose of the proposal. - Nevertheless, proposer should respond to the
past comments. - I'd like to request to proposer to explain the intention
of copying the implementation contents of RIPE NCC as it is. - The content
of the previous discussion has not been reflected and it is not refined.
Although the position of the proposal is not in an opposite position, the
proponent should explain more. Please answer the discussion at APNIC 44.*
Regards,
Satoru Tsurumaki
2018-08-08 4:44 GMT+11:00 Sumon Ahmed Sabir <sasa...@gmail.com>:
> Dear SIG members
>
> A new version of the proposal "prop-118: No need policy in APNIC region"
> has been sent to the Policy SIG for review.
>
> Information about earlier versions is available from:
>
> https://www.apnic.net/community/policy/proposals/prop-118/
>
> 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,
>
> Sumon, Bertrand, Ching-Heng
> APNIC Policy SIG Chairs
>
>
> ----------------------------------------------------------------------
>
> prop-118-v002: No need policy in APNIC region
>
> ----------------------------------------------------------------------
>
> Proposer: Heng Lu
> h...@laruscloudservice.net
>
>
> 1. Problem Statement
> --------------------
>
> Whenever a transfer of IPv4 is taking place within the APNIC region, the
> recipient needs to demonstrate the "need" for the IPv4 space they intend
> to transfer.
>
> Companies transferring IPv4 space to their pool do this in ordcer to
> enable further growth in their network, since the space is not coming
> from the free public pool, regular policies that are intended to protect
> the limited pool of IPv4 space can be removed in transfers.
>
>
> 2. Objective of policy change
> -----------------------------
>
> Simplify transfer of IPv4 space between resource holders.
> Ease some administration on APNIC staff, increase database accuracy.
>
>
> 3. Situation in other regions
> -----------------------------
>
> RIPE region has an all around no need policy in IPv4, even for first
> allocation, transfers do not require the recipient to demonstrate their
> intended use of the resources.
>
> ARIN, need base for both transfers and resources issued by ARIN.
>
> AFRINIC, need based policy on transfers (not active yet) and resource
> request from AFRINIC based on needs.
>
> LACNIC, no transfers, need based request.
>
> Out of all these RIR, only ARIN and RIPE NCC have inter-RIR transfer
> policies, ARIN has made clear in the past that the "no need" policy
> from the RIPE region would break inter-RIR transfers from ARIN to RIPE
> region.
>
>
> 4. Proposed policy solution
> ---------------------------
>
> Simply copy the RIPE policy to solve the ARIN transfer incompatibility:
>
> - APNIC shall accept all transfers of Internet number resources to its
> service region, provided that they comply with the policies relating
> to transfers within its service region.
>
> - For transfers from RIR regions that require the receiving region to
> have needs-based policies, recipients must provide a plan to the
> APNIC for the use of at least 50% of the transferred resources within
> 5 years.
>
> - When transferring Internet number resources to another RIR, the APNIC
> will follow the transfer policies that apply within its own service
> region.
> The APNIC will also comply with the commitments imposed by the
> receiving
> RIR in order to facilitate the transfer.
>
>
> 5. Advantages / Disadvantages
> -----------------------------
>
> Advantages:
>
> - Harmonisation with RIPE region.
> - Makes transfer simpler and smoother within APNIC and between APNIC
> and RIPE.
> - Maintains a compatibility with ARIN.
> - Removes the uncertainty that a transfer may be rejected based on
> potentially badly documented needs.
> - Lowers the overall administrative burden on APNIC staff.
>
> Disadvantages:
>
> None.
>
>
> 6. Impact on resource holders
> -----------------------------
>
> None.
>
>
> 7. References
> -------------
>
> * 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mailman.apnic.net/mailing-lists/sig-policy/attachments/20180911/a5a458fc/attachment.html>
------------------------------
Message: 2
Date: Tue, 11 Sep 2018 14:02:07 +1100
From: Satoru Tsurumaki <satoru.tsurum...@g.softbank.co.jp>
To: SIG policy <sig-pol...@apnic.net>
Subject: Re: [sig-policy] Prop124 version 4
Message-ID:
<CAHXx+kSu+TPqhKavrQVcQN4=bz4q_veo4kvpx74senc6144...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
*Dear Colleagues,I am Satoru Tsurumaki from Japan Open Policy Forum.I would
like to share key feedback in our community for prop-124,based on a meeting
we organised on 22nd Aug to discuss these proposals.Many supporting
opinions were expressed on this proposal.However, also many concerning
comment was expressed to explain the specific examples.For this matter, the
same opinion was given also at JPOPM34. - It is better to stop specific
examples because they tend to fall into discussion of adding / not applying
/ not applicable. - I think that specific examples should be stated in
the guidelines rather than policies.*
Regards,
Satoru Tsurumaki
2018-09-09 18:37 GMT+11:00 Bertrand Cherrier <b.cherr...@micrologic.nc>:
> Dear SIG members
>
> A new version of the proposal "prop-124: Clarification on IPv6
> Sub-Assignments"
> has been sent to the Policy SIG for review.
>
> Information about earlier versions is available from:
>
> https://www.apnic.net/community/policy/proposals/prop-124
>
> 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,
>
> Sumon, Bertrand, Ching-Heng
> APNIC Policy SIG Chairs
> ------------------------------
>
> prop-124-v004: Clarification on IPv6 Sub-Assignments
> ------------------------------
>
> Proposer: Jordi Palet Mart?nez
> jordi.pa...@theipv6company.com
> 1. Problem Statement
>
> When the policy was drafted, the concept of assignments/sub-assignments
> did not consider a practice very common in IPv4 which is replicated and
> even amplified in IPv6: the use of IP addresses for point-to-point links
> or VPNs.
>
> In the case of IPv6, instead of unique addresses, the use of unique
> prefixes (/64) is increasingly common.
>
> Likewise, the policy failed to consider the use of IP addresses in
> hotspots,
> or the use of IP addresses by guests or employees in Bring Your Own Device
> (BYOD) and many other similar cases.
>
> One more case is when an end-user contracts a third-party to do some
> services
> in their own network and they need to deploy their own devices, even
> servers,
> network equipment, etc. For example, security surveillance services may
> require
> that the contractor provides their own cameras, recording system, even
> their
> own firewall and/or router for a dedicated VPN, etc. Of course, in many
> cases,
> this surveillance system may need to use the addressing space of the
> end-user.
>
> Finally, the IETF has recently approved the use of a unique /64 prefix per
> interface/host (RFC8273) instead of a unique address. This, for example,
> allows users to connect to a hotspot, receive a /64 such that they are
> ?isolated? from other users (for reasons of security, regulatory
> requirements, etc.) and they can also use multiple virtual machines
> on their devices with a unique address for each one (within the same /64).
> 2. Objective of policy change
>
> Section 2.2.3. (Definitions/Assigned Address Space), explicitly prohibits
> such assignments, stating that ?Assigned ... may not be sub-assigned?.
>
> https://www.apnic.net/community/policy/resources#2.2.3.-
> Assigned-address-space
>
> This proposal clarifies this situation in this regard and better define the
> concept, particularly considering new uses of IPv6 (RFC 8273), by means of
> a new paragraph.
> 3. Situation in other regions
>
> This situation, has already been corrected in RIPE, and the policy was
> updated
> in a similar way, even if right now there is a small discrepancy between
> the
> policy text that reached consensus and the RIPE NCC Impact Analysis. A new
> policy proposal has been submitted to amend that, and the text is the same
> as presented by this proposal at APNIC. Same text has also been submitted
> to AfriNIC, LACNIC and ARIN.
> 4. Proposed policy solution
>
> Add a new paragraph after the existing one in 2.2.3
> https://www.apnic.net/community/policy/resources#2.2.3.-
> Assigned-address-space
>
> Actual text:
> 2.2.3. Assigned address space
> Assigned address space is address space that is delegated to an LIR, or
> end-user,
> for specific use within the Internet infrastructure they operate.
> Assignments must
> only be made for specific, documented purposes and may not be sub-assigned.
>
> New text:
> 2.2.3. Assigned address space
> Assigned address space is address space that is delegated to an LIR, or
> end-user,
> for specific use within the Internet infrastructure they operate.
> Assignments must
> only be made for specific, documented purposes and may not be sub-assigned.
>
> Providing addressing space to third party devices including addresses for
> point-to-point links and/or non-permanently providing addressing space to
> third
> parties, for use on a network managed and operated by the assignment
> holder,
> shall not be considered a sub-assignment.
>
> The provision of addressing space for permanent or semi-permanent
> connectivity,
> such as broadband services, is still considered a sub-assignment.
> 5. Advantages / Disadvantages
>
> Advantages:
> Fulfilling the objective above indicated and making sure to match the real
> situation
> in the market.
>
> Disadvantages:
> None foreseen.
> 6. Impact on resource holders
>
> None
> 7. References
>
> Links to RIPE policy amended and new policy proposal submitted.
>
> Cordialement,
> ------------------------------
>
> Bertrand Cherrier
> Administration Syst?mes - R&D
> Micro Logic Systems
> b.cherr...@micrologic.nc
> https://www.mls.nc
> T?l : +687 24 99 24
> VoIP : 65 24 99 24
> SAV : +687 36 67 76 (58F/min)
> ------------------------------
>
> * 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mailman.apnic.net/mailing-lists/sig-policy/attachments/20180911/2396afe5/attachment.html>
------------------------------
_______________________________________________
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy
End of sig-policy Digest, Vol 172, Issue 7
******************************************
* 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
