[arin-ppml] ARIN-PPML Digest, Vol 63, Issue 32
Rudolph Daniel
rudi.daniel at gmail.com
Wed Sep 29 10:49:38 EDT 2010
I cannot support 2010-13 presently because it still seems to me to be
overtly complex prone to misunderstanding.
One example: >ISPs can apply for /32s for customers as long as each customer
> meets the policy's detailed qualification criteria. As an ISP, I may not
be too happy imposing detailed qualification criteria which will be a beyond
my commercial requirement and may simply frustrate and complicate the
process at all levels.
Rudi Daniel
On Wed, Sep 29, 2010 at 10:33 AM, <arin-ppml-request at arin.net> wrote:
> Send ARIN-PPML mailing list submissions to
> arin-ppml at arin.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.arin.net/mailman/listinfo/arin-ppml
> or, via email, send a message with subject or body 'help' to
> arin-ppml-request at arin.net
>
> You can reach the person managing the list at
> arin-ppml-owner at arin.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ARIN-PPML digest..."
>
>
> Today's Topics:
>
> 1. Re: Final draft of 2010-13 for Atlanta (Rev 1.55)
> (Hannigan, Martin)
> 2. Re: Final draft of 2010-13 for Atlanta (Rev 1.55)
> (Chris Grundemann)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 28 Sep 2010 17:55:37 -0400
> From: "Hannigan, Martin" <marty at akamai.com>
> To: "arin-ppml at arin.net" <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Final draft of 2010-13 for Atlanta (Rev 1.55)
> Message-ID: <C8C7DC99.11B97%marty at akamai.com<C8C7DC99.11B97%25marty at akamai.com>
> >
> Content-Type: text/plain; charset="Windows-1252"
>
>
>
> I oppose this proposal. I think it's destructive; it's complicated and
> fails
> to establish any leadership and it's divisive; the reservation system and
> classes of requests create significant inequities for all that have need.
> It
> fails to allow anyone to plan. The end result is that we're going to pit
> all
> of our members against each other in open markets. Regardless of this
> proposal, that may happen still. When I supported the petition I had hoped
> that we could stretch this remaining space and provide some relief and
> define what's important with regards to continuing to grow the net while we
> transition. That is impossible with this proposal and perhaps impossible
> with any proposal and a single /8[1]. [ The recent CableLabs Draft is very
> interesting FWIW]
>
> This proposal still does not go far enough in offering some level of relief
> to all segments of the industry. I concur with the staff comments related
> and specifically comments related to the complexity.
>
> I did support "the concept" of the reservation system with different terms
> and provider relief with respect to CPE et. Al. The proposal fails to
> explain itself adequately with respect to both and if it were adequately
> explained it may seem less unfair if it were re-written. Transition not be
> without pain and some of us are already challenged by it.
>
> I don't have a suggestion other than a complete rewrite which is why I
> support completely abandoning it.
>
>
> Best,
>
> -M<
>
>
>
> 1. http://tools.ietf.org/html/draft-weil-opsawg-provider-address-space-00
>
>
>
>
>
>
> On 9/27/10 4:02 PM, "ARIN" <info at arin.net> wrote:
>
> > Draft Policy 2010-13
> > Permitted Uses of space reserved under NRPM 4.10
> >
> > Attached is the ARIN staff assessment of 2010-13. We assessed the 1.53
> > version of the draft policy (it's currently at 1.55). It is noted that
> > the time frame for reserves has been reduced from 36 to 24 months in
> > version 1.55.
> >
> > This draft policy is open for discussion on this mailing list and will
> > be on the agenda at the upcoming ARIN Public Policy Meeting in Atlanta.
> >
> > 2010-13 is below and available at:
> > https://www.arin.net/policy/proposals/2010_13.html
> >
> > Regards,
> >
> > Communications and Member Services
> > American Registry for Internet Numbers (ARIN)
> >
> >
> > ## * ##
> >
> >
> > Staff Assessment of Draft Policy 2010-13 (version 1.53 dated 19
> > September 2010)
> >
> > Permitted Uses of space reserved under NRPM 4.10
> >
> > 1. Proposal Summary (Staff Understanding)
> >
> > This policy modifies the existing NRPM policy 4.10 (?Dedicated IPv4
> > block to facilitate IPv6 Deployment?). It sets aside in its entirety
> > the last /8 ARIN receives from the IANA for issuance to networks
> > transitioning to a dual IPv4/IPv6 network rather than the /10 currently
> > cited in NRPM 4.10. Any IPv4 address space returned to ARIN (and not
> > subject to a global or regional transfer policy) will be added to this
> > transition pool. Under this policy there are four major classes of
> > requestors:
> >
> > - ISPs can apply for /32s for customers as long as each customer
> > meets the policy's detailed qualification criteria.
> >
> > - Any operator can apply for /32s for issuing to devices used to
> > serve-up internet facing content, within the constraints of the defined
> > qualifying criteria.
> >
> > - From the /8, a /10 will be set aside so that any operator can
> > request space for use in infrastructure numbering for the purposes of
> > deploying IPv6. Space can be issued from this /8 for applicants who
> > qualify under ARIN's Micro-allocation Policy (with additional
> > restrictions).
> >
> > - Finally, space can be issued from this /8 for applicants who
> > operate content distribution networks, again, within the context of the
> > policy's qualifying criteria.
> >
> > Organizations can request address space to meet their 3-year needs.
> > Space is allocated/assigned in quarterly installments. After the first
> > quarter, the requestor can only return to ARIN if they have utilized 80%
> > of the most recent assignment, and 90% of past assignments (issued under
> > this policy). The organization must have also assigned all IP addresses
> > issued under the policy to uses that are acceptable under the policy.
> > If the organization fails to meet the utilization criteria for four
> > consecutive quarters, then the policy directs ARIN staff to reduce the
> > amount of space reserved.
> >
> > 2. Comments
> >
> > A. ARIN Staff Comments
> >
> > ? The policy text has become very complex and complicated and the
> > general community will have a very hard time understanding the concepts
> > and criteria proposed within the policy.
> >
> > ? It seems to be out of order ? it starts out with reservations
> > before ever mentioning the initial qualifying criteria. The author
> > might want to consider re-ordering to start with the essential
> > qualification criteria first.
> >
> > ? Section 4.10.2 suggests that all allocations made under this policy
> > will initially be made from a 3-year reservation. In light of the
> > imminent depletion of IPv4 address space, it doesn't seem fair to allow
> > some organizations to retain/reserve this valuable resource for up to 3
> > years while others will be denied.
> >
> > ? The policy text in (in 4.10.3) appears to contradict itself, as it
> > first directs staff to remove one quarter's worth of reservation, and
> > then, if the organization continues this practice for three consecutive
> > quarters, remove the organization's reserves completely. Later, it
> > explicitly directs staff to revoke addresses issued under this policy
> > that are used by the organizations for purposes not permitted under this
> > policy.
> >
> > ? This proposal will essentially supplant the recently ratified
> > policy "Waiting List for Unmet Resources". That list will consist of
> > people waiting for resources to be returned or revoked so that ARIN can
> > then reissue them to requestors in need of IPv4 address space. This
> > proposal says that any IPv4 address space that comes back to ARIN
> > immediately goes into the IPv6 transition pool and can only be used for
> > that purpose.
> >
> > ? Under 4.10.4.B5, how would staff be able to verify that x percent
> > of an organization?s content is IPv6 reachable?
> >
> >
> > B. ARIN General Counsel
> > This policy is unlikely to cause any legal issues of any importance.
> >
> >
> > 3. Resource Impact
> >
> > This policy would have moderate to major resource impact. It is
> > estimated that implementation would occur within 6 to 9 months after
> > ratification by the ARIN Board of Trustees. The following would be
> > needed in order to implement:
> > ? Changes to the way ARIN manages reverse DNS (to handle in-addr.arpa
> > delegations for blocks smaller than /24)
> > ? Updated guidelines
> > ? Staff training
> >
> >
> >> -----Original Message-----
> >
> >> From: Owen DeLong [mailto:owen at delong.com]
> >
> >> Sent: Thursday, September 23, 2010 7:26 PM
> >
> >> To: arin-ppml at arin.net List; policy
> >
> >> Subject: Final draft of 2010-13 for Atlanta (Rev 1.55)
> >
> >>
> >
> >> Changes:
> >
> >>
> >
> >> 1. Set maximum reservation period to 24 months. This avoids creating
> >
> >> a 4-year reservation by CIDR-rounding 36 month reservations.
> >
> >> 2. Reduced minimum size for 4.10.4(b) to /28
> >
> >>
> >
> >> These changes will make the policy more balanced and reduce the extent
> >
> >> to
> >
> >> which larger organizations could be disadvantaged relative to smaller
> >
> >> smaller organizations if reservations have to be resized.
> >
> >>
> >
> >> The change to a 2-year system resolves an issue with the CIDR-Rounding
> >
> >> where a 36-month reservation is mathematically guaranteed to become a
> >
> >> 48-month reservation. The other alternative was to round-down instead
> >
> >> of
> >
> >> up which would have mathematically converted all reservations to 2
> >
> >> years.
> >
> >> As such, a 2-year reservation system seemed the cleanest and most
> >
> >> straightforward approach.
> >
> >>
> >
> >> Owen
> >
> >>
> >
> >> Draft Policy 2010-13: Permitted Uses of Space Reserved under NRPM 4.10
> >
> >> Proposal Originator: Owen DeLong, Chris Grundemann
> >
> >> Proposal Version: 1.55
> >
> >> Date: 23 September 2010
> >
> >> Proposal type: modify
> >
> >> Policy term: permanent
> >
> >> Policy statement:
> >
> >>
> >
> >> Remove section 4.1.8 (Unmet requests) from the NRPM.
> >
> >> Replace the text of section 4.10 in its entirety (including the name)
> >
> >> with:
> >
> >>
> >
> >> 4.10 IPv4 Transition Pool Post IANA Regular Pool Depletion
> >
> >>
> >
> >> When ARIN receives its /8 IPv4 allocation from IANA under the
> >
> >> global policy titled "Global Policy for the Allocation of the
> >
> >> Remaining IPv4 Address Space" ratified by ICANN Board
> >
> >> on 6 March, 2009, that /8 will form a dedicated pool to
> >
> >> facilitate IPv6 Deployment.
> >
> >>
> >
> >> Addresses returned to ARIN and not subject to a regional or
> >
> >> global transfer policy will be reserved for utilization in the
> >
> >> transition
> >
> >> pool.
> >
> >>
> >
> >> Allocations and assignments from this block must be justified by
> >
> >> IPv6 transition requirements.
> >
> >>
> >
> >> ARIN will use their discretion in determining whether a
> >
> >> particular
> >
> >> application meets the spirit of this policy.
> >
> >>
> >
> >> 4.10.1 Addressing Plan
> >
> >>
> >
> >> Any organization wishing to receive IPv4 addresses through this
> >
> >> policy must submit a detailed addressing plan for any request
> >
> >> that is made containing the following:
> >
> >> (a) Their addressing needs over the entire reservation period
> >
> >> and
> >
> >> (b) Methods of meeting all requirements (requirements are
> >
> >> explained in section 4.10.4.) over the entire reservation
> >
> >> period.
> >
> >>
> >
> >> 4.10.2 Reservation System
> >
> >>
> >
> >> Initially, all space assigned or allocated under this policy will
> >
> >> be
> >
> >> reserved in advance for a maximum period of 24 months, requests
> >
> >> for
> >
> >> shorter reservations will be accepted. The total reservation size
> >
> >> will be rounded up to a CIDR bit boundary.
> >
> >>
> >
> >> Each organization's reservation amount will be divided
> >
> >> into quarterly allotments. Allotments will be rounded up
> >
> >> to a CIDR bit boundary. The final quarterly allotment will
> >
> >> contain only the remaining space from the full reservation.
> >
> >>
> >
> >> An organization may request one reservation under each provision
> >
> >> listed in section 4.10.4. Once a reservation has been satisfied,
> >
> >> another may be requested.
> >
> >>
> >
> >> 4.10.2.1 Reservation Requests Prior to Initial ARIN Free Pool
> >
> >> Depletion
> >
> >>
> >
> >> Reservations will be accepted from the time that this policy
> >
> >> is adopted until the day that ARIN can no longer fill regular
> >
> >> requests from
> >
> >> space allocated to ARIN by IANA. At that time, if necessary, all
> >
> >> reservations
> >
> >> will be reduced by an equal amount to allow them to fit within
> >
> >> the total space available in the transition pool. No reservation
> >
> >> will be reduced lower than the minimum quarterly allotment for
> >
> >> it's category. Each organization may decide whether to adjust
> >
> >> the reservation period or the allotment size (within the stated
> >
> >> range) when reservations are reduced. Organizations must make
> >
> >> this decision within 30 days of announcement and may not alter
> >
> >> their choice once made. Any space added to the transition
> >
> >> pool during this time will cause a final recalculation of
> >
> >> reservation sizes. Once all necessary adjustments are
> >
> >> made, all reservations are guaranteed and the first quarterly
> >
> >> allotment is issued to each org.
> >
> >>
> >
> >> 4.10.2.2 Reservation Requests Post ARIN Free Pool Depletion
> >
> >>
> >
> >> Reservation requests received after ARIN free pool depletion
> >
> >> as defined in 4.10.2.1 will not be guaranteed. If approved, such
> >
> >> requests will be placed in a queue. As space becomes available in
> >
> >> the transition pool it will be used to provide allotments to
> >
> >> organizations with reservations in the queue on a first-approved
> >
> >> first-served basis. Partially filled allotments will remain at
> >
> >> the
> >
> >> front of the queue.
> >
> >>
> >
> >> 4.10.2.3 Abandonment of Reservation
> >
> >>
> >
> >> Any organization may abandon their remaining reservation at any
> >
> >> time by informing ARIN of their desire to do so. Upon
> >
> >> abandonment,
> >
> >> the remaining space in the reservation will be returned to the
> >
> >> transition pool.
> >
> >>
> >
> >> 4.10.3 Quarterly Requirements
> >
> >>
> >
> >> Organizations with approved reservations and address plans
> >
> >> are entitled to quarterly allotments. In order to receive each
> >
> >> additional allotment, an organization must submit evidence of
> >
> >> compliance with the following sub-sections:
> >
> >> (a) The most recent 4.10 allotment is at least 80% utilized.
> >
> >> (b) All prior 4.10 allotments within the same 4.10.4
> >
> >> category are at least 90% utilized.
> >
> >> (c) All utilization is permitted under the 4.10.4 category for
> >
> >> which it was initially requested.
> >
> >>
> >
> >> For purposes of this computation, space received under each
> >
> >> provision shall be considered separately if an organization has
> >
> >> received resources through multiple provisions.
> >
> >>
> >
> >> If an organization does not meet all obligations in any given
> >
> >> quarter, that organization shall not receive that quarter's
> >
> >> allotment
> >
> >> and shall have their reservation reduced by one quarterly
> >
> >> allotment.
> >
> >> If an organization does not meet all obligations
> >
> >> for three consecutive quarters, that organization forfeits the
> >
> >> remainder
> >
> >> of their reserved block.
> >
> >>
> >
> >> Utilization requirements (a) may be delayed at ARIN's discretion.
> >
> >>
> >
> >> If an organization is using space received under 4.10 in a manner
> >
> >> contrary to 4.10, that organization forfeits their remaining
> >
> >> reservation and may have their entire allocation or assignment
> >
> >> revoked.
> >
> >>
> >
> >> All 4.10. space forfeited, revoked or otherwise reclaimed shall
> >
> >> be returned to the ARIN transition pool.
> >
> >>
> >
> >> 4.10.4 Specific types of transitional uses have specific
> >
> >> requirements:
> >
> >>
> >
> >> (a) An ISP/LIR may request a block no smaller than a /25 nor
> >
> >> larger than a /18 per quarter to be used to provide single
> >
> >> IPv4 /32s to their customers which could justify a /28 or
> >
> >> more of IPv4 under ARIN policies in effect at the time of
> >
> >> IANA depletion.
> >
> >> 1. No customer site may receive more than a single
> >
> >> IPv4 /32 per 1,000 Internet connected hosts upto 8
> >
> >> /32s.
> >
> >> 2. The customer site must not have any IPv4
> >
> >> addresses not issued under this policy.
> >
> >> 3. The customer site must use the /32 to provide
> >
> >> IPv4 connectivity for hosts which have IPv6
> >
> >> addresses with IPv6 connectivity to the ISP/LIR.
> >
> >> 4. The ISP/LIR must demonstrate that it already
> >
> >> provides IPv6 addressing and connectivity to at
> >
> >> least one additional existing customer site for
> >
> >> each /32 requested, up to 90% of all customer sites
> >
> >> served (across all customers).
> >
> >> 5. An ISP/LIR customer which is not large enough to
> >
> >> qualify
> >
> >> under this provision and has no unassigned IPv4
> >
> >> addresses
> >
> >> may receive an appropriate number of /32s from their
> >
> >> upstream provider for reassignment to their customers
> >
> >> under the terms of 4.10.4(a).
> >
> >> 6. A customer site which terminates multiple connections
> >
> >> from the same provider on separate routers may
> >
> >> qualify
> >
> >> for one /32 per unique router with a direct
> >
> >> connection to
> >
> >> the provider, up to a total of 8 /32s.
> >
> >> 7. The total space issued to all organizations under
> >
> >> this provision shall not exceed an aggregate /9
> >
> >> or equivalent per /8 placed into the transition pool.
> >
> >>
> >
> >>
> >
> >> (b) An ISP/LIR or End user organization may request a block
> >
> >> no smaller than a /28 and no larger than a /18 per quarter
> >
> >> to provide single IPv4 /32s to each physical server used
> >
> >> to provide Internet reachable content.
> >
> >> 1. Space issued under this provision is an assignment,
> >
> >> not an allocation. An LIR may not distribute this
> >
> >> space to their customers.
> >
> >> 2. No server may receive more than a single IPv4 /32
> >
> >> under this provision.
> >
> >> 3. The server must have IPv6 addresses with IPv6
> >
> >> connectivity (must be dual-stacked).
> >
> >> 4. The receiving organization must demonstrate that it
> >
> >> already provides IPv6 addressing and connectivity
> >
> >> to at least one additional existing server
> >
> >> (organizations which can show 100% dual stack are
> >
> >> exempt from this requirement).
> >
> >> 5. The receiving organization must IPv6 enable all of
> >
> >> their content on the following schedule:
> >
> >>
> >
> >> + 25% of content IPv6 reachable within six
> >
> >> months of receiving their first addresses
> >
> >> under this policy
> >
> >> + 50% of content IPv6 reachable within one year
> >
> >> of receiving their first addresses under this
> >
> >> policy
> >
> >> + 75% of content IPv6 reachable within 18 months
> >
> >> of receiving their first addresses under this
> >
> >> policy
> >
> >> + 90% of content IPv6 reachable within 24 months
> >
> >> of receiving their first addresses under this
> >
> >> policy
> >
> >> 6. A network providing SSL terminations for applications
> >
> >> or content acceleration may receive a /32 for each
> >
> >> distinguished name by following all requirements in
> >
> >> this provision, substituting "distinguished name" for
> >
> >> "server."
> >
> >> 7. Networks using these addresses for authoritative
> >
> >> DNS servers can use 2 /32s per 1,000 authoritative
> >
> >> domains served up to 128 /32s total per organization.
> >
> >> 8. The total space issued to all organizations under
> >
> >> this provision shall not exceed an aggregate /9
> >
> >> or equivalent per /8 placed into the transition pool.
> >
> >>
> >
> >> (c) An ISP/LIR or End user organization may request a block no
> >
> >> smaller than a /29 and no larger than a /25 per quarter for
> >
> >> purposes relevant to their ability to deploy IPv6.
> >
> >> 1. Space issued under this provision is an assignment,
> >
> >> not an allocation. An LIR may not distribute this
> >
> >> space to their customers.
> >
> >> 2. Space issued under this provision must be used to
> >
> >> provide the required public IPv4 address(es) for
> >
> >> transitional technologies operated by the recipient
> >
> >> organization.
> >
> >>
> >
> >> Specific examples of permitted uses are:
> >
> >> a. Large scale or "Carrier Grade" NAT
> >
> >> b. NAT-PT
> >
> >> c. DS-LITE/B4/AFTeR
> >
> >> d. IVI
> >
> >> e. DNS64 or other transitional DNS enablers
> >
> >> f. Other technologies of similar purpose
> >
> >> and scope.
> >
> >>
> >
> >> 3. A /10 from the final /8 shall be reserved for
> >
> >> issuance
> >
> >> under this provision. In no case shall any addresses
> >
> >> from this /10 be issued for any purpose outside
> >
> >> of 4.10.4(c).
> >
> >>
> >
> >> (d) Applications which would qualify for IPv4 under section 4.4
> >
> >> of
> >
> >> the NRPM (critical infrastructure) may qualify for IPv4
> >
> >> space
> >
> >> under this policy if they meet the following criteria:
> >
> >> 1. The critical infrastructure to be numbered must also
> >
> >> have IPv6 addresses and must provide all services
> >
> >> provided on IPv4 over IPv6 on the same time table.
> >
> >> 2. Assignments under this provision shall be the
> >
> >> smallest technically feasible size for the critical
> >
> >> infrastructure in question.
> >
> >> 3. The total space assigned under this provision shall
> >
> >> not
> >
> >> exceed the equivalent of a /14.
> >
> >>
> >
> >> </pre>
> >
> >>
> >
> >> <pre>
> >
> >>
> >
> >>
> >
> >> 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.
> >
> >>
> >
> >> Additionally, there are a number of community segments that are not
> >
> >> well served by the original intent of 4.10 and several community
> >
> >> members requested a mechanism for providing a certain amount of
> >
> >> certainty with regards to obtaining space at the end. While it would be
> >
> >> impossible to guarantee organizations all the space they need as runout
> >
> >> is upon us, this policy seeks to provide a way for organizations to
> >
> >> sign up for and receive a reservation from the final space
> >
> >> proportionate to their need. The policy also includes guidelines
> >
> >> intended to ensure that this vital community resource is given only to
> >
> >> organizations working towards a smooth transition to IPv6 to the
> >
> >> benefit of the full community.
> >
> >>
> >
> >> In order to meet these needs, this policy has become very complex. It
> >
> >> is an unfortunate artifact of the complex issue it seeks to address. A
> >
> >> great deal of effort has been made to simplify the policy as much as
> >
> >> possible, and, special thinks go out to several members of the
> >
> >> community for their assistance in this matter.
> >
> >>
> >
> >> One provision in this draft policy calls for utilization criteria which
> >
> >> may be waived by ARIN staff discretion. The intent of this clause is to
> >
> >> allow staff to avoid penalizing an organization for successful address
> >
> >> conservation efforts.
> >
> >>
> >
> >> Runout is upon us. IANA will run out of the IANA free pool and issue
> >
> >> the last /8 this policy seeks to regulate before the next ARIN public
> >
> >> policy meeting. If we are to make any attempt at fair distribution for
> >
> >> the sake of IPv6 deployment, this is our final opportunity to do so
> >
> >> outside of an emergency action by the ARIN board.
> >
> >>
> >
> >> 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.
> >
> >
> >
> >
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 29 Sep 2010 08:32:59 -0600
> From: Chris Grundemann <cgrundemann at gmail.com>
> To: "arin-ppml at arin.net" <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Final draft of 2010-13 for Atlanta (Rev 1.55)
> Message-ID:
> <AANLkTimUxYeYO-F8gm-WA3_VyMakaZ1O8BJZ7k1fkr_A at mail.gmail.com>
> Content-Type: text/plain; charset=windows-1252
>
> I think the fact that ARIN Staff is concerned that this policy may
> favor organizations who are granted reservations too much and Marty
> believes that it does not go far enough to provide relief to those
> same organizations illustrates that we have actually found a pretty
> decent compromise.
>
> On Tue, Sep 28, 2010 at 15:55, Hannigan, Martin <marty at akamai.com> wrote:
> >
> > This proposal still does not go far enough in offering some level of
> relief
> > to all segments of the industry.
>
> The simple fact is that we are running out of IPv4 space. Absolutely
> no policy can change that. Advancing transition to IPv6 across the
> board is the best way (perhaps the only way) to ease all of our
> growing pains going forward.
>
> > On 9/27/10 4:02 PM, "ARIN" <info at arin.net> wrote:
> >>
> >> ? A. ? ?ARIN Staff Comments
> >>
> >> ? ?? Section 4.10.2 suggests that all allocations made under this policy
> >> will initially be made from a 3-year reservation. ?In light of the
> >> imminent depletion of IPv4 address space, it doesn't seem fair to allow
> >> some organizations to retain/reserve this valuable resource for up to 3
> >> years while others will be denied.
>
> I would like to point out that although the initial reservations are
> for [now two years], there is a built in "fairness valve" as well.
> Please see section 4.10.2.1 in the draft policy, which starts thus:
>
> Reservations will be accepted from the time that this policy
> is adopted until the day that ARIN can no longer fill regular
> requests from
> space allocated to ARIN by IANA. At that time, if necessary, all
> reservations
> will be reduced by an equal amount to allow them to fit within
> the total space available in the transition pool.
>
> So everyone who is granted a reservation before run-out gets *some*
> reservation, although it is not likely that anyone will get the full
> reservation requested. I think this is the best balance of
> predictability and inclusiveness possible.
>
> Also note the second phase, post-exhaustion, detailed in section
> 4.10.2.2 which reads:
>
> Reservation requests received after ARIN free pool depletion
> as defined in 4.10.2.1 will not be guaranteed. If approved, such
> requests will be placed in a queue. As space becomes available in
> the transition pool it will be used to provide allotments to
> organizations with reservations in the queue on a first-approved
> first-served basis. Partially filled allotments will remain at the
> front of the queue.
>
> So, *everyone* gets a shot at the transition space, and it comes down
> to how much space ends up being available.
>
> Overall, I think we have come up with the best possible (most fair)
> soft-landing policy under the current constraints (constraints which
> will only get tighter).
>
> ~Chris
>
> >>
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> >
>
> --
> @ChrisGrundemann
> weblog.chrisgrundemann.com
> www.burningwiththebush.com
> www.coisoc.org
>
>
> ------------------------------
>
> _______________________________________________
> ARIN-PPML mailing list
> ARIN-PPML at arin.net
> http://lists.arin.net/mailman/listinfo/arin-ppml
>
> End of ARIN-PPML Digest, Vol 63, Issue 32
> *****************************************
>
--
Rudi Daniel
*danielcharles consulting<http://www.facebook.com/pages/Kingstown-Saint-Vincent-and-the-Grenadines/DanielCharles/153611257984774>
**1-784 498 8277<http://www.facebook.com/pages/Kingstown-Saint-Vincent-and-the-Grenadines/DanielCharles/153611257984774>
*
*
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100929/12d80321/attachment.htm>
More information about the ARIN-PPML
mailing list