I think the current text isn’t really a problem because reasonable people apply a reasonable interpretation of intent rather than the literal meaning.
The proposal brings literal meaning more in line with well understood intent. While I don’t believe there is an actual problem to solve here, I do think the proposal provides greater clarity in the language and therefore support it. Owen > On Aug 23, 2019, at 01:11, Simon Sohel Baroi / Global Business / 01847102243 > / <simon.ba...@fiberathome.net> wrote: > > Dear Sir, > > Also, Requesting to the Author to represent the Proposal with Example and > Graphical Representation. > The example should have comparison with Present situation and the Propose > Solution of the problem. > > > - with regards > > SIMON. > >> On Sat, Aug 10, 2019 at 8:33 PM Sumon Ahmed Sabir <sasa...@gmail.com> wrote: >> 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 > > > -- > Simon Sohel Baroi | AGM | International Gateway and Cable | > Cell : +880-181-7022207 | Desk : +880-9666776677 Ext-1702 | > Mail : simon.ba...@fiberathome.net | Skype : tx.fttx | > > > > Reduce. Reuse. Recycle. Respect. It's the little things that really can make > a difference. > * 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
