[arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8
On Nov 16, 2010, at 12:07 PM, Charles O'Hern wrote:
> I'd like to thank these gentlemen for including love for the x-small ISPs out there. We love you guys.
> Question, section 22.214.171.124 (d) dealing with End Sites larger than /48, says "(they shall) count as the appropriate number of /48s that would be assigned under that policy." is that
> number to be counted towards the total number of End Sites that is then rounded up to the next nibble boundary? Or should the End Site assignment be on the nibble boundary (16
> /48's, 256 /48's, etc.) before adding to the total number of end sites per serving site?
Assuming that 2010-8 is adopted as is, the end site would receive a nibble boundary assignment and that nibble
boundary would be counted for purposes of this policy. If, for example, such an end site received a /44, then, under
this policy they would count as 16 /48s fully utilized.
> Some minor language suggestions included inline below. No change in meaning is intended. The only intention is to make meaning more clear and language more precise. Please let
> me know publicly if my suggestions imply that I'm misunderstanding your meaning. I noted my edits with pound (#) signs, hopefully facilitating visibility.
Thanks... Comments inline.
> On 11/16/10 6:09 AM, Owen DeLong wrote:
>> Template: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0
>> 1. Policy Proposal Name: Sensible IPv6 Allocation for ISPs
>> 2. Proposal Originators
>> 1. name: Owen DeLong
>> 2. e-mail: owen at delong.com <mailto:owen at delong.com>
>> 3. telephone: 408-890-7992
>> 4. organization: Hurricane Electric
>> 1. name: David Farmer
>> 2. e-mail: farmer at umn.edu <mailto:farmer at umn.edu>
>> 3. telephone: 612-812-9952
>> 4. organization: University of Minnesota
>> 1. name: Andrew Dul
>> 2. e-mail: andrew.dul at quark.net <mailto:andrew.dul at quark.net>
>> 3. telephone: 206-395-4004
>> 4. organization: Cascadeo Corp.
>> 1. name: Chris Grundemann
>> 2. e-mail: christopher.grundemann at twtelecom.com <mailto:christopher.grundemann at twtelecom.com>
>> 3. telephone: 303.542.6524
>> 4. organization: TW Telecom
>> 3. Proposal Version: 0.8
>> 4. Date: 16 November, 2010
>> 5. Proposal type: M
>> 6. Policy term: Permanent
>> 7. Policy statement:
>> Amend section 2 as follows:
>> Delete section 2.9 (Obsolete)
>> Replace section 2.10 with the following:
>> 2.10 The term End Site shall mean a single structure or service delivery address, or, in the case of a multi-tenant structure, a single tenant within said structure (a single customer location).
>> Add the following:
>> 2.12 The term serving site shall mean a location where an ISP terminates or aggregates customer connections, including, but, not limited to Points of Presence (POPs), Datacenters, Central or Local switching office or regional or local combinations thereof.
>> 2.13 The term provider assignment unit shall mean the prefix of the smallest block a given ISP assigns to end sites (recommended /48).
>> 2.14 The term utilized shall have the following definitions:
>> (i) A provider assignment unit shall be considered fully utilized when it is assigned to an end-site.
>> (ii) Larger blocks shall have their utilization defined by dividing the number of provider assignment units assigned ###from the containing block### by the total number of provider assignment units _contained in the larger block_. This ratio will often be expressed as a percentage (e.g. a/t*100, for a /36 3072/4096 * 100 = 75% utilization)
OK... I'll incorporate that one in the next revision.
>> Replace sections 6.5.1 through 6.5.3 with the following:
>> 6.5.1 Terminology
>> (a) The terms ISP and LIR are used interchangeably in this document and any use of either term shall be construed to include both meanings.
>> (b) The term nibble boundary shall mean a network mask which aligns on a 4-bit boundary (###in slash notation, /n, where n is evenly divisible by 4, allowing unit quantities### of X such that 2^n=X , such as 16, 256, 4096, etc.)
OK... I like this one to... I will incorporate it.
(There weren't any changes suggested beyond this point).