Hi Satoru,

Thanks for investing time in the several policy proposals.

I think that the last couple of emails could help all you to better understand 
the problem.

Clearly, if different people read the current policy text in a different way, 
it will be much better to find a way so we have a single and unique "reading" 
and no different ways to interpret it. Right?

Regards,
Jordi
@jordipalet
 
 

El 2/9/19 17:37, "Satoru Tsurumaki" <sig-policy-boun...@lists.apnic.net en 
nombre de satoru.tsurum...@g.softbank.co.jp> escribió:

    Dear Colleagues,
    
    I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team.
    I would like to share a feedback in our community for prop-124,based
    on a meeting we organized on 21th Aug to discuss these proposals.
    
    Many participants expressed a neutral for the proposal with reasons
    that the problem in the current policy is something vague.
    
    Best Regards,
    
    Satoru Tsurumaki
    JPOPF-ST
    
    2019年8月10日(土) 23:33 Sumon Ahmed Sabir <sasa...@gmail.com>:
    
    >
    > Dear SIG members
    >
    > A new version of the proposal "prop-124: Clarification on Sub-Assignments"
    > has been sent to the Policy SIG for review.
    >
    > It will be presented at the Open Policy Meeting at APNIC 48 in
    > Chiang Mai, Thailand on Thursday, 12 September 2019.
    >
    > 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-v006: Clarification on Sub-Assignments
    >
    > ----------------------------------------------------------------------
    >
    > Proposer: Jordi Palet Martínez
    >            jordi.pa...@theipv6company.com
    >
    >
    > 1. Problem Statement
    > --------------------
    >
    > Note that this proposal is ONLY relevant when end-users obtain direct
    > assignments
    > from APNIC, or when a LIR obtains, also from APNIC, and assignment for
    > exclusive
    > use within its infrastructure. Consequently this is NOT relevant in case
    > of LIR
    > allocations.
    >
    > 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 IPv4, typically, this is not a problem if NAT is being used, because
    > the assigned
    > addresses are only for the WAN link, which is part of the infrastructure
    > or interconnection.
    >
    > 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 hotspots
    > (when is not an ISP, for example, associations or community networks),
    > 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”.
    >
    > It also clarifies that the usage of sub-assignments in ISPs, data
    > centers and similar cases
    > is not allowed, according to the existing practices of APNIC.
    >
    >
    > 3. Situation in other regions
    > -----------------------------
    >
    > This situation, has already been corrected in AFRINIC, ARIN, LACNIC and
    > RIPE.
    >
    >
    > 4. Proposed policy solution
    > ---------------------------
    >
    > Current 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 exclusive use within the infrastructure they operate, as well as for
    > interconnection
    > purposes.
    >
    > The assigned address space must only be used by the original recipient
    > of the assignment,
    > as well as for third party devices provided they are operating within
    > said infrastructure.
    >
    > Therefore, sub-assignments to third parties outside said infrastructure
    > (for example
    > using sub-assignments for ISP customers), and providing addressing space
    > to third
    > parties in data-centers (or similar cases), are not allowed.
    >
    >
    > 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.
    >
    > *              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



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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.



*              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

Reply via email to