Hi Hiroki,

Just sent a response to this in the previous email.

Note this is only a minor editorial change in the policy proposal, the rest of 
the text is much more relevant than just this detail.

Regards,
Jordi
@jordipalet
 
 

El 6/9/19 15:45, "Hiroki Kawabata" <sig-policy-boun...@lists.apnic.net en 
nombre de kawab...@nic.ad.jp> escribió:

    Hi all,
    
    We oppose this proposal. APNIC should always check references to documents
    which written by other bodies, so we think that it should be kept to the 
minimum necessary.
    If the goal is to simplify the policy document, how about putting it in a 
guideline document?
    
    Regards,
    Hiroki
    
    ---
    Hiroki Kawabata
    Japan Network Information Center(JPNIC)
    
    
    Subject: [sig-policy] prop-131-v001: Editorial changes in IPv6 Policy
    Date: Fri, 9 Aug 2019 15:59:08 +0600
    From: Sumon Ahmed Sabir <sasa...@gmail.com>
    
    > 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
    > 
    *              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