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

[George, Wes E IV [NTK]]

I support this petition. I'm not necessarily in favor of the current proposal as written, but I think it raises a valid point and should be discussed further, especially in light of the discussions around 6RD and other transition technologies referenced in 2010-9 and 12. Petition has my contact info in a separate message.
Thanks,
Wes George


From: arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong
Sent: Wednesday, July 21, 2010 2:19 AM
To: arin-ppml at arin.net<mailto:arin-ppml at arin.net> List; petition at arin.net<mailto:petition at arin.net>
Subject: [arin-ppml] 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<mailto: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<mailto: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<mailto: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.

________________________________
This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.


________________________________
This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100729/e7c07427/attachment.htm>