[arin-ppml] Petition for discussion of policy proposal 116 (Permitted Uses of Space Reserved Under NRPM 4.10)

[Member Services]

The message below started a petition regarding the ARIN Advisory
Council's decision to abandon "Policy Proposal 116. Permitted Uses of
space reserved under NRPM 4.10." ARIN staff posted on 20 July 2010 to
PPML that the ARIN Advisory Council (AC) had decided to abandon the
proposal.

If successful, this petition will change Proposal 116 into a Draft
Policy which will be published for adoption discussion on the PPML and
at the Public Policy Meeting in October. If the petition fails, the
proposal will be closed.

For this petition to be successful, the petition needs statements of
support from at least 10 different people from 10 different
organizations. If you wish to support this petition, post a statement of
support to PPML on this thread. Point of contact information is
required, either to the entire PPML or with a follow up post to
petition at arin.net with full POC information (name, organization, street
address, email, phone).

The duration of the petition is through five business days after the
AC's draft meeting minutes are published. ARIN staff will post the
result of the petition to PPML.

For more information on starting and participating in petitions, see PDP
Petitions at:
https://www.arin.net/policy/pdp_petitions.html

The proposal text is below and at:
https://www.arin.net/policy/proposals/index.html

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


#####


> -----Original Message-----
> From: Owen DeLong [mailto:owen at delong.com]
> Sent: Wednesday, July 21, 2010 2:19 AM
> To: arin-ppml at arin.net List; petition at arin.net
> Subject: Petition for discussion of policy proposal 116 (Permitted Uses
> of Space Reserved Under NRPM 4.10)
>
>     The AC abandoned the following proposal:
>
>      116. Permitted Uses of space reserved under NRPM 4.10
>
>     The AC voted to abandon this proposal because of a lack of
> sufficient
>     support to accept it as draft policy. Several AC members felt it
> not
>     appropriate that ARIN policy dictate any specific architecture or
> method
>     a network should use to transition from v4 to v6.
>
>
>
> This is my formal request to initiate a discussion petition of proposal
> 116.
>
> If you would like to sign this petition, please do the following:
>
> 1. Send a message stating "I support the petition for discussion of
> proposal 116"
> to arin-ppml at arin.net
>
> 2. Either include your contact information and organizational
> affiliation in
> the original message to ppml or send it in a separate message to
> petition at arin.net (use this address if you do not want your contact
> information disclosed to PPML).
>
> Thank you.
>
> I believe that the AC should not have abandoned this proposal for the
> following
> reasons:
>
> 1. I believe that there is community support for clarifying valid uses
> and
> preventing abuses of space reserved for transitional technologies under
> section 4.10.
>
> 2. The language of 116 states examples of valid uses of space under
> 4.10
> but does not specify or dictate specific architecture or methods. It
> attempts
> to prevent space reserved for transition from being used in a business-
> as-
> usual method that is not in direct support of a transition to IPv6
> because
> the author believes that is contrary to the community intent of 4.10.
>
> I refer specifically to 4.12(1)(a-e) which list a multitude of possible
> valid
> technologies and includes specifically (e) etc. to cover any possible
> valid technologies not yet contemplated.
>
> 3. The language in the existing 4.10 is not sufficiently specific to
> prevent
> a multitude of possible abuses of the reserved space that do not
> actually
> benefit a transition process.
>
> For these reasons, I encourage anyone who feels that section 4.10
> reflects the
> good intent of the community to sign this discussion petition to get
> this policy
> in front of the community in Atlanta. Even if you disagree with the
> specifics, those
> can be addressed in the development of the policy. If you have comments
> on
> those specifics, please direct them to ppml or to me.
>
>
> Author contact information as required in the petition process:
>
> Owen DeLong
> owen at delong.com
> +1.408.890.7992
>
> Here is the text of the proposal in question as required in the
> petition
> process:
>
> Policy Proposal 116: Permitted Uses of space reserved under NRPM 4.10
> Proposal Originator: Owen DeLong
> Proposal Version: 1
> Date: 18 June 2010
> Proposal type: modify
> Policy term: permanent
> Policy statement:
> Add the following to section 4.10 of the NRPM
> 6. No organization may receive more than 16 /24 equivalents under this
> section.
> Add the following to section 4 of the NRPM
> 4.11 Required utilization for subsequent allocation under section 4.10
> No organization shall receive more than one allocation or assignment
> under section 4.10 unless all prior space issued under 4.10 meets the
> utilization requirements of this section.
> 1. The most recent 4.10 allocation/assignment must be at least 80%
> utilized.
> 2. All utilization must be permitted under section 4.12
> 3. All prior 4.10 allocation/assignments must be at least 90% utilized.
> 4.12 Permitted uses of allocations or assignments under section 4.10
> No organization shall use space received under section 4.10 for any
> purpose other than as specified in this section
> 1. To provide the required public IPv4 address(es) for transitional
> technologies operated by the recipient organization.
> a. Large scale or "Carrier Grade" NAT
> b. NAT-PT
> c. DS-LITE/AFTeR
> d. DNS64 or other transitional DNS enablers
> e. etc.
> 2. For other transitional technologies not envisioned at the time of
> this proposal, but, in no case for general IPv4 addressing provided to
> customers.
> Rationale:
> The current terminology in section 4.10 is vague and could allow a
> variety of interpretations which could lead to allocations or
> assignments being made to ISPs intending to misuse the space for
> general
> deployment by using IPv6 overlay technologies as a "IPv6 deployments"
> requiring IPv4 space for transition. For example, the current policy
> could be interpreted to enable an ISP to require IPv4 addresses for all
> IPv6 customers to roll IPv6 out as 6rd to customers who would be
> otherwise unable to get IPv4 space. This is clearly outside of the
> original intent of the proposal which created 4.10 (6rd was not yet
> envisioned at the time that was written). This proposal seeks to
> clarify
> that intent and tighten up the requirements for organizations seeking
> to
> get space from this limited final resource so that it truly is
> available
> to facilitate transitional technologies.
> Timetable for implementation: immediate
> For reference, here is the current text of 4.10
> 4.10 Dedicated IPv4 block to facilitate IPv6 Deployment
> When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous
> /10 IPv4 block will be set aside and dedicated to facilitate IPv6
> deployment. Allocations and assignments from this block must be
> justified by immediate IPv6 deployment requirements. Examples of such
> needs include: IPv4 addresses for key dual stack DNS servers, and NAT-
> PT
> or NAT464 translators. ARIN staff will use their discretion when
> evaluating justifications.
> This block will be subject to a minimum size allocation of /28 and a
> maximum size allocation of /24. ARIN should use sparse allocation when
> possible within that /10 block.
> In order to receive an allocation or assignment under this policy:
> 1. the applicant may not have received resources under this policy in
> the preceding six months;
> 2. previous allocations/assignments under this policy must continue to
> meet the justification requirements of this policy;
> 3. previous allocations/assignments under this policy must meet the
> utilization requirements of end user assignments;
> 4. the applicant must demonstrate that no other allocations or
> assignments will meet this need;
> 5. on subsequent allocation under this policy, ARIN staff may require
> applicants to renumber out of previously allocated / assigned space
> under this policy in order to minimize non-contiguous allocations.