Policy 6 - Single organizations with multiple aggregation poi nts

[Sweeting, John]

Just a quick reminder that we would like all comments/suggestions submitted
to this list NLT 1200 AM (midnight) EST on November 8th. Thank you.

-----Original Message-----
From: Sweeting, John [mailto:John.Sweeting at teleglobe.com]
Sent: Wednesday, October 31, 2001 10:24 AM
To: 'Andrew Dul '; 'ppml at arin.net '
Subject: RE: Policy 6 - Single organizations with multiple aggregation
poi nts


Hello to all,

I would like to inform the mailing list members of the results of the ARIN
Advisory Council's discussion of this policy from our meeting last night,
October 30th. The AC has agreed to support and forward this policy to the
BOT in principle but would like your input as to the final wording of the
proposal. The AC will hold a conference call on 9 November, 1100 AM EST, to
finalize the wording and vote on endorsing this proposal to the BOT. Once we
have agreed to the final wording, the proposal will be sent out to this list
for final comments (IAW the ARIN Policy process it will be posted for 10
working days). Our goal is to have this all completed so that the BOT will
be able to finalize this proposal during their December 11th meeting. We
would like to have all recommendations and comments sent to this list NLT
than 1200 AM (midnight) EST on November 8th. I will send out reminders over
the next week to remind you all of this deadline. The AC would like to
recognize Andrew for his involvement in the policy process and thank him for
his time and commitment. Thank you.

John

-----Original Message-----
From: Andrew Dul
To: ppml at arin.net
Sent: 10/31/01 9:25 AM
Subject: Re: Policy 6 - Single organizations with multiple aggregation
points

Here is the revised text after discussions yesterday.

------

ARIN VIII - Policy Proposal 6
Single organizations with multi-homed discrete networks

Criteria for the application of this policy:

* The organization should be a single entity, and not a consortium of
smaller independent entities.  (Example: Not a group of independent
network operators who form a group specifically for this policy)

* This policy applies only to organizations that have been previously
granted address space by an RIR.  This policy does not apply to
organizations with only legacy address space.

* The organization must have multiple (at least two) discrete
multi-homed
networks.

* The organization should have a compelling criteria for creating
discrete
networks.
	Examples: 1) regulatory restrictions for data transmission
                  2) geographic distance and diversity between networks
                  3) autonomous multi-homed discrete networks

* An organization which would like to use this policy must apply for
this
policy to be applied to their maintainer account.

Requirements for additional allocations from RIR:

* The organization must record allocations or assignments down to the
current RIR bit boundary (currently /29 for ARIN) and record them in an
approved RIR public database.

* The organization must keep detailed records of how it has allocated
space to each discrete network.  This should include the block
allocated,
any reserved blocks, and date of allocation/reservation.  The discrete
network allocation information should also be present in a public
database
(Example:  routing registry, rWhois, or SWIP).

* The organization must not allocate additional space to a discrete
network unless all the blocks allocated to that network show utilization
greater than 80% individually and as a whole.

* The organization must not allocate a CIDR block larger than the
current
minimum assignment size of the RIR (currently /20 for ARIN) to a new
network.

* The organization must not allocate an additional CIDR block larger
than
the current minimum assignment size of the RIR (currently /20 for ARIN)
to
an existing network, unless previous growth rates for that network
indicate that it is likely to utilize a larger CIDR block before the
time
the organization will be requesting an additional block from the RIR.
The suggested minimum allocation size for an additional block for a
network is the current minimum assignment size of the RIR.

* When allocating a block larger than the minimum assignment size to an
existing network the organization should use the smallest allocation
possible out of a larger reserved block.  This requirement is to reduce
the number of routes the organization will announce from that autonomous
system.  Example:  A fast growing network is allocated a /20 out of a
reserved /19, when the /20 is 80% utilized the announcement is expanded
to
a /19 and the /20 announcement is removed.  This practice also allows
the
reserved /20 to be used by another discrete network should the 'fast
growing network' not use the address space as anticipated.

* When applying for additional address space, from an RIR, for new
networks or additional space for existing networks the organization must
show greater than 50% utilization for the last block granted by the RIR
and their allocations as a whole.  Any reserved blocks must be allocated
to a discrete network before the RIR will grant additional address
space.

* The organization must follow guidelines of RFC 2050 (or its
replacement)
and the policy of the granting RIR for allocations that are assigned or
allocated to downstream networks.  This includes record keeping of
allocation and reassignment requests and network utilization documents
for
audits by the RIR.