Dear Sir, 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 Fri, Aug 9, 2019 at 3:59 PM Sumon Ahmed Sabir <sasa...@gmail.com> wrote: > > Dear SIG members, > > The proposal "prop-131-v001: Editorial changes in IPv6 Policy" 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. > > 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-131 > > Regards > > Sumon, Bertrand, Ching-Heng > APNIC Policy SIG Chairs > > > ---------------------------------------------------------------------- > > prop-131-v001: Editorial changes in IPv6 Policy > > ---------------------------------------------------------------------- > > Proposer: Jordi Palet Martínez > jordi.pa...@theipv6company.com > > > 1. Problem Statement > -------------------- > > This proposal suggests multiple (mainly) editorial changes in the IPv6 > Policy. > The intent is to remove non-necessary text, and simplify the policy. > > Section 5.2.4.2. is reworded to mention a RIPE BCOP, and 5.2.4.4. is > removed, > as it is something obvious that operators need to assign some space for > different > parts of their own infrastructure. > > Section 5.2.4.3. explicitly states that it was drafted at a time when > there was no > experience with IPv6 deployment, which is this is longer the case, it > does not make > sense to have NIR/RIR to evaluate each instance where an LIR has an End > User whose > end site(s) requires a shorter prefix than a /48. > > Finally, section 10.1.4.1. is reworded, taking advantage of some of the > editorial > changes in the precedent sections, so to avoid duplicating text. > > > > 2. Objective of policy change > ----------------------------- > > Fulfil the above indicated edits. > > > 3. Situation in other regions > ----------------------------- > > A similar proposal has been submitted to RIPE. > > > 4. Proposed policy solution > --------------------------- > > Current Text > 5.2.4.2. Assignment address space size > > ... > > End-users are assigned an end site assignment from their LIR or ISP. The > exact size of > the assignment is a local decision for the LIR or ISP to make, using a > minimum value of > a /64 (when only one subnet is anticipated for the end site) up to the > normal maximum of > /48, except in cases of extra large end sites where a larger assignment > can be justified. > > ... > > > New Text > 5.2.4.2. Assignment address space size > > ... > > End Users are assigned an end site assignment from their LIR or ISP. The > size of the > assignment is a local decision for the LIR or ISP to make, using a value > of "n" x /64. > BCOP RIPE690 Section 4.2, provides guidelines about this. > > ... > > ================================================== > > Current Text > 5.2.4.3. Assignment of multiple /48s to a single end site > > When a single end site requires an additional /48 address block, it must > request the > assignment with documentation or materials that justify the request. > Requests for multiple > or additional /48s will be processed and reviewed (i.e., evaluation of > justification) at > the RIR/NIR level. > > Note: There is no experience at the present time with the assignment of > multiple /48s to > the same end site. Having the RIR review all such assignments is > intended to be a temporary > measure until some experience has been gained and some common policies > can be developed. > In addition, additional work at defining policies in this space will > likely be carried out > in the near future. > > > New Text > 5.2.4.3. Assignment of multiple /48s to a single end site > > Assignment larger than /48 (shorter prefix) or additional assignments > exceeding a total of > /48 must be made based on address usage, or because different routing > requirements exist > for additional assignments. > > In case of a review or when making a request for a subsequent > allocation, the LIR must > be able to present documentation justifying the need for assignments > shorter than a > /48 to a single End-Site. > > ==================================================== > > Current Text > 5.2.4.4. Assignment to operator's infrastructure > > An organization (ISP/LIR) may assign a /48 per PoP as the service > infrastructure of an > IPv6 service operator. Each assignment to a PoP is regarded as one > assignment regardless > of the number of users using the PoP. A separate assignment can be > obtained for the > in-house operations of the operator. > > > New Text > (removed and following sections renumbered accordingly) > > ===================================================== > > Current Text > 10.1.4.1. Initial assignment > > ... > > The minimum assignment made under this policy is a /48. Larger blocks > may be delegated in > circumstances outlined in "APNIC guidelines for IPv6 allocation and > assignment requests". > > ... > > New Text > 10.1.4.1. Initial assignment > > The minimum size of the assignment is a /48. > The considerations of "5.2.4.3. Assignments shorter than a /48 to a > single End-Site" > must be followed if needed. > > ==================================================== > > > 5. Advantages / Disadvantages > ----------------------------- > > Advantages: > Fulfilling the objectives above indicated. > > > Disadvantages: > None foreseen. > > > 6. Impact on resource holders > ----------------------------- > > None. > > > 7. References > ------------- > AFRINIC and LACNIC don’t have this requirements in their IPv6 policies > and recommend an assignment > size of /48 > https://www.afrinic.net/policy/manual#Allocations-Assignments-Policies > (section 6.5.4.1 > Assignment address space size) https://www.lacnic.net/684/2/lacnic/ > (section 4.5.3.1 - Assignment > address space size) > > ARIN policy requires for larger initial assignments to be reasonably > justified with supporting > documentation, based on the number of sites in an organization’s network > and the number of subnets > needed to support any extra-large sites. > > https://www.arin.net/participate/policy/nrpm/#6-5-4-reassignments-from-lirs-isps > * 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
