From info at arin.net  Tue Mar  4 11:06:51 2008
From: info at arin.net (Member Services)
Date: Tue, 04 Mar 2008 11:06:51 -0500
Subject: Policy Proposal 2008-3: Community Networks IPv6 Allocation
Message-ID: <47CD739B.3060905@arin.net>

On 21 February 2008, the ARIN Advisory Council (AC) concluded its review
of "Community Networks IPv6 Allocation" and accepted it as a formal
policy proposal with the condition that the policy text be revised by
the author so that it can be put into the ARIN Number Resource Policy
Manual. The author submitted a revised version of the proposal.

The proposal is designated Policy Proposal 2008-3: Community Networks
IPv6 Allocation. The proposal text is below and can be found at:
http://www.arin.net/policy/proposals/2008_3.html

All persons in the community are encouraged to discuss Policy Proposal
2008-3 prior to it being presented at the upcoming ARIN XXI Public
Policy Meeting. Both the discussion on the Public Policy Mailing List
and at the Public Policy Meeting will be used to determine the community
consensus regarding this policy proposal.

The ARIN Internet Resource Policy Evaluation Process can be found at:
http://www.arin.net/policy/irpep.html

ARIN's Policy Proposal Archive can be found at:
http://www.arin.net/policy/proposals/proposal_archive.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Policy Proposal 2008-3
Community Networks IPv6 Allocation

Author: Joshua King

Proposal Version: 1

Date: 4 March 2008

Proposal type: new

Policy term: permanent

Policy statement:

[Add Section 2.8 to the NRPM.]

2.8 Community Network

A community network is a generic reference to any network that is
operated by a group of people living in a particular local area
organized for the purposes of delivery or provision of network services
to the residents of an incorporated or unincorporated regional
municipality, city, town, village, rural municipality, township, county,
district or other municipality or other such geographic space, however
designated.

[Modify 6.5.8.1b as follows.]

b. qualify for an IPv4 assignment or allocation from ARIN under the IPv4
policy currently in effect or be a Community Network as defined in
Section 2.8.

Rationale:

There are currently a number of projects globally that aim to develop
community network infrastructure and related technologies. These are
usually coordinated by volunteer-run, grassroots organizations which
lack many of the resources of traditional internet service providers and
other network operators. They have diverse goals, including public
policy, software development, and implementation of community services
and resources. Many of them provide services free of charge, and thus
lack any paying user base. However, in order to create and maintain
community networks that are often composed of hundreds if not thousands
of inexpensive, commodity hosts and devices, a significant amount of
address space will be required. Current-generation workarounds to this
problem, such as NAT, not only make it difficult to develop
next-generation decentralized network technology by segmenting the
community's architecture from the Internet as a whole, but will cease to
be as viable a stopgap as the Internet moves towards IPv6 integration.

Even now, common community networking software solutions such as
CUWiNware (http://www.cuwin.net) and Freifunk (http://www.freifunk.at)
have nascent IPv6 addressing support, but participating organizations
lack the address space for widespread testing or adoption. As such, it
is necessary to implement an procedure as soon as possible for these
segregated networks to acquire address space. These organizations do not
meet the criteria traditionally defined for LIR's, and thus cannot
acquire address allocations through existing templates. By establishing
a procedure by which these organizations can seek to acquire the
resources they require for further development, ARIN can reach out to
this active community and establish a small but definite space for them
in the future of Internet.

Timetable for implementation: Immediate.





From info at arin.net  Thu Mar  6 09:27:15 2008
From: info at arin.net (Member Services)
Date: Thu, 06 Mar 2008 09:27:15 -0500
Subject: Lame Delegations
Message-ID: <47CFFF43.5080608@arin.net>

ARIN has elected to remove the Lame Delegation identification and 
notification software from production.  Following several months of 
periodic issues, ARIN determined it is best to take the software 
offline, review, and retest several components.  One recent problem 
resulted in blank e-mail messages being sent to approximately one 
hundred organizations.  We apologize for this inconvenience.

The software is expected to be back online in early April 2008.  If
you have any further questions or comments, please contact info at arin.net.

Regards,

Mark Kosters
Chief Technology Officer




From info at arin.net  Fri Mar  7 17:19:07 2008
From: info at arin.net (Member Services)
Date: Fri, 07 Mar 2008 17:19:07 -0500
Subject: Policy Proposal 2008-2: IPv4 Transfer Policy Proposal - Revised Text
Message-ID: <47D1BF5B.9030707@arin.net>

Policy Proposal 2008-2, IPv4 Transfer Policy Proposal, has been revised.
This proposal is open for discussion on this mailing list and will be on
the agenda at the upcoming ARIN Public Policy Meeting in Denver.

The current policy proposal text is provided below and is also available
at: http://www.arin.net/policy/proposals/2008_2.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


### * ###


Policy Proposal 2008-2
IPv4 Transfer Policy Proposal

Author: ARIN Advisory Council

Proposal Version: 1.1

Date: 7 March 2008

Proposal type: modify

Policy term: permanent

Policy statement:

Replace the current NRPM section 8 with the following --

8. Transfers

[8.1. Transfers ? retain as is:

Number resources are non-transferable and are not assignable to any
other organization unless ARIN has expressly and in writing approved a
request for transfer. ARIN is tasked with making prudent decisions on
whether to approve the transfer of number resources.

It should be understood that number resources are not "sold" under ARIN
administration. Rather, number resources are assigned to an organization
for its exclusive use for the purpose stated in the request, provided
the terms of the Registration Services Agreement continue to be met and
the stated purpose for the number resources remains the same. Number
resources are administered and assigned according to ARIN's published
policies.

Number resources are issued, based on justified need, to organizations,
not to individuals representing those organizations. Thus, if a company
goes out of business, regardless of the reason, the point of contact
(POC) listed for the number resource does not have the authority to
sell, transfer, assign, or give the number resource to any other person
or organization. The POC must notify ARIN if a business fails so the
assigned number resources can be returned to the available pool of
number resources if a transfer is not requested and justified.]

[8.2 ? remove the word ?only?, and retitle to ?Transfers as an Artifact
of Change in Resource Holder Ownership?:

8.2. Transfers as an Artifact of Change in Resource Holder Ownership
ARIN will consider requests for the transfer of number resources upon
receipt of evidence that the new entity has acquired the assets which
had, as of the date of the acquisition or proposed reorganization,
justified the current entity's use of the number resource. Examples of
assets that justify use of the number resource include, but are not
limited to:
? Existing customer base
? Qualified hardware inventory
? Specific software requirements.]
[Renumber existing 8.3 to 8.2.1 and retitle to ?Documentation
Requirements for Transfers as an Artifact of Change in Resource Holder
Ownership?:

8.2.1. Documentation Requirements for Transfers as an Artifact of Change
in Resource Holder Ownership In evaluating a request for transfer, ARIN
may require the requesting organization to provide any of the following
documents, as applicable, plus any other documents deemed appropriate:
? An authenticated copy of the instrument(s) effecting the transfer of
assets, e.g., bill of sale, certificate of merger, contract, deed, or
court decree
? A detailed inventory of all assets utilized by the requesting party in
maintaining and using the number resource
? A list of the requesting party's customers using the number resource.
If further justification is required, the requesting party may be asked
to provide any of the following, or other supporting documentation, as
applicable:
? A general listing of the assets or components acquired
? A specific description of acquisitions, including:
o Type and quantity of equipment
o Customer base
? A description of how number resources are being utilized
? Network engineering plans, including:
o Host counts
o Subnet masking
o Network diagrams
o Reassignments to customers]

8.3. Simple Transfer of IPv4 Addresses

After the exhaustion of the IANA IPv4 free pool (when IANA allocates its
last unallocated unicast IPv4 address block), ARIN will also process
IPv4 address transfer requests subject to the following conditions.
These conditions apply only to Simple IPv4 transfers, not to transfers
performed according to section 8.2.

8.3.1 Conditions on the transferor (the organization providing addresses
for transfer):
? The transferor resides in the ARIN service area.
? The transferor has signed an RSA and/or a legacy RSA covering the IPv4
addresses transferred.
? The transferor has no outstanding balances with ARIN.
? The transferor has not received any IPv4 allocations or assignments
from ARIN (through ordinary allocations or assignments, or through this
Simple Transfer policy) within the preceding 24 months.
? The transferor may not request any IPv4 allocations or assignments
from ARIN (through ordinary allocations or assignments, or through this
Simple Transfer policy) within the subsequent 24 months.

8.3.2 Conditions on the transferee (the organization receiving the
transferred addresses):
? The transferee resides in the ARIN service area and intends to use the
transferred IPv4 addresses within the ARIN service area.
? The transferee has no outstanding balances with ARIN.
? The transferee?s need is confirmed by ARIN, according to current ARIN
policies, including but not limited to confirmation of utilization rate
of any prior IPv4 allocations, assignments, or previously transferred
IPv4 addresses held by the transferee.
? The transferee signs (or has previously signed) an RSA covering the
IPv4 addresses transferred.
? The transferee has not provided any IPv4 addresses for transfer
through this Simple Transfer process within the preceding 24 months.
? The transferee may not provide any IPv4 addresses for transfer through
this Simple Transfer process within the subsequent 24 months, except in
the case of business failure.
? The transferee may request and receive a contiguous CIDR block large
enough to provide a 12 month supply of IPv4 addresses.
? The transferee may only receive one IPv4 address transfer through this
Simple Transfer process every 6 months.

8.3.3 Conditions on the IPv4 address block to be transferred:
? The IPv4 block must comply with applicable ARIN requirements,
including minimum allocation size (i.e. NRPM 4.2.2., 4.2.4., 4.3.2.,
4.3.6.). However, an IPv4 allocation or assignment of /24 or larger, but
smaller than the current minimum allocation size, may be transferred as
a whole resource, but may not be subdivided.
? The IPv4 block must currently be registered for use within the ARIN
service area, either as part of an address block assigned by IANA to
ARIN, or as part of a legacy address block allocated within the ARIN
service area.
? There must exist no dispute as to the status of the IPv4 block or
regarding the allocation or assignment of such block to the transferor.
? The transferor may retain one contiguous address range out of their
original allocation or assignment for their own use, and transfer the
other contiguous address range. If the address range to be transferred
consists of multiple non-aggregatable CIDR blocks, each may be
transferred to a different transferee. The retained address range may
not be further subdivided or transferred for a period of 12 months.
Notwithstanding the preceding, the block may be subdivided as provided
in section 8.3.6.

8.3.4 Fees
? Completion of a transfer requires payment of a transfer fee according
to ARIN?s schedule of fees.
? The transferee will be subject to all future ARIN membership and
service fees according to the transferee?s total address holdings.

8.3.5 Pre-qualification

? An interested transferee must seek pre-qualification from ARIN to
confirm its eligibility to receive a transfer (including satisfaction of
need according to current ARIN policies) before making any solicitation
for transfer. Upon pre-qualification, ARIN will provide the transferee
with documentation of the pre-qualification, including the size (CIDR
prefix length) of the largest IPv4 address block the transferee is
eligible to receive, and the expiration date of the pre-qualification.
? An interested transferor must seek pre-qualification from ARIN to
confirm its eligibility to offer a transfer (including lack of
outstanding balances and having signed an RSA) before offering IPv4
address resources for transfer. Upon pre-qualification, ARIN will
provide the transferor with documentation of the pre-qualification,
including the network block and the expiration date of the
pre-qualification.

8.3.6 Deaggregation when Permitted by ARIN

If ARIN determines that there is an inadequate supply of small blocks,
ARIN may allow transferors to subdivide network blocks beyond the
limited subdivision permitted under 8.3.3. ARIN will attempt to ensure
an adequate supply of small blocks while minimizing deaggregation.

8.3.7. Safe Harbor for IPv4 Transfers through this Simple Transfer Process

When an IPv4 address resource is made available for transfer, it shall
be deemed exempt from ARIN utilization audit until 90 days after its
transfer pre-qualification or until the transfer is completed, whichever
comes first.

In the event that a transfer is not consummated within the
prequalification time period, the block may be immediately
re-prequalified for transfer. Notwithstanding the current offered state
of the address resource, however, the audit exemption period shall
expire untolled 90 days after the expiration of the first
pre-qualification period. After the expiration of any utilization audit
exemption period, ARIN shall have 90 days in which to initiate a
utilization audit. In no event shall non-exempt time be construed to
extend the end of the next exemption period.

8.3.8. Simple IPv4 Transfers to or from Organizations Under Common
Ownership or Control

If an IPv4 transferor or transferee is under common ownership or control
with any other organization that holds one or more IPv4 blocks, the IPv4
transfer request must report all such organizations under common
ownership or control.

When evaluating compliance with IPv4 Simple Transfer conditions, ARIN
may consider a transferor?s transfer request in light of requests from
other organizations under common ownership or control with the
transferor. Similarly, ARIN may consider a transferee?s request in light
of requests from other organizations under common ownership or control
with the transferee. In evaluating requests from other organizations
under common ownership or control, ARIN staff will consider the
relationship between the organizations, the degree of coordination
between the organizations, and the bona fide use of the addresses at
issue to determine whether all appropriate conditions are met.

8.3.9. Record-keeping and Publication of Simple Transfers of IPv4 Addresses

ARIN will develop and operate a listing service to assist interested
transferors and transferees by providing them a centralized location to
post information about IPv4 blocks available from prequalified
transferors and IPv4 blocks needed by prequalified transferees.
Participation in the listing service is voluntary.

After completion of the transfer, ARIN will update the registration
records pertaining to the IPv4 block at issue. ARIN will adjust its
records as to the holdings of the transferor and transferee.

After the transfer, ARIN will publish WHOIS data that reflects the
current allocation or assignment of the transferred block. ARIN will
also make available information about any prior recipient(s) of such
block. ARIN will also publish a log of all transfers, including block,
transferor, transferee, and date.



Rationale:
The ARIN Board of Trustees asked the Advisory Council to consider a set
of questions around the depletion of the free pool of IPv4 addresses,
the transition to IPv6 for Internet address needs in the future, and
ARIN's possible role in easing the transition.

Over the past few years the AC has spent a great deal of time reflecting
on these issues ? as a group, as individuals, and in consultation with
the community. One outcome of this process is this policy proposal,
which the AC is submitting for consideration at the next meeting. We are
proposing some changes to existing ARIN policy regarding the transfer of
IP address block registrations between subscribers, which will allow for
the emergence of trade in IPv4 address space, with ARIN to provide a
listing service for address blocks available for transfer under the
liberalized policy. We are aware that this proposal, if adopted, will
mark a major change in ARIN's role in the community and the Internet.

This policy proposal would create a transfer mechanism for IPv4 number
resources between those who have excess resources and those who have a
need, thereby allowing ARIN to continue to serve its mission after IANA
free pool exhaustion. This proposal would also set conditions on such
transfers intended to preserve as much as possible the existing policy
related to efficient, needs-based resource issuance, and would leverage
ARIN's extensive control systems, audit trails, and recognized position
as a trusted agent to avoid speculation and hoarding and diminish the
likelihood and extent of an uncontrolled 'black market' where the risk
and potential for fraud is immeasurably higher.

Many of the transfer conditions are self-explanatory, but some worth
highlighting are that:
? To discourage speculation, a waiting period (proposed at 24 months) is
required before a transferee (or ordinary resource recipient) can become
a transferor, or vice versa.
? Transferees must qualify for IPv4 space (just as they do today when
getting it from ARIN) before they can receive address space by transfer,
or solicit space on a listing service.
? To discourage unnecessarily rapid growth of routing tables, an
allocation or assignment may not be arbitrarily deaggregated. To allow a
transferor to downsize within their existing space, they may split off a
contiguous address range, once every 12 months, and transfer the
resulting netblock(s), which are subject to ARIN?s minimum allocation
size, to one or more transferee(s).
? A transferee may receive one transfer every 6 months, so they?ll be
incented to transfer a block appropriately sized for their needs, which
will further discourage deaggregation and keep smaller blocks available
for smaller organizations.
The proposal would also have ARIN develop and operate a listing service
to facilitate transfers and provide an authoritative central source of
information on space available and requested for transfer. It would not
prohibit private party transactions, but would require that potential
transferors and transferees be pre-qualified first, so that neither
party will encounter any unexpected surprises when they ask ARIN to
process the transfer.

Timetable for implementation: Immediately, with most aspects of policy
taking effect upon IANA exhaustion, per the policy text.



From info at arin.net  Tue Mar 11 11:44:18 2008
From: info at arin.net (Member Services)
Date: Tue, 11 Mar 2008 11:44:18 -0400
Subject: Policy Proposal 2007-21: PIv6 for legacy holders with RSA and
	efficient use - Revised Text
Message-ID: <47D6A8D2.50405@arin.net>

Policy Proposal 2007-21, PIv6 for legacy holders with RSA and efficient
use, has been revised. After ARIN XX this proposal was remanded to the
ARIN Advisory Council by the ARIN Board of Trustees. The AC asked the
author to revise the text and present the propsal again. The proposal is
open for discussion on this mailing list and is on the agenda at the
upcoming Public Policy Meeting in Denver.

The current policy proposal text is provided below and is also available
at: http://www.arin.net/policy/proposals/2007_21.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


### * ###


Policy Proposal 2007-21
PIv6 for legacy holders with RSA and efficient use

Author: Scott Leibrand

Proposal Version: 2.0

Date: 11 March 2008

Proposal type: modify

Policy term: permanent

Policy statement:

Modify NRPM section 6.5.8.1 (Direct assignments from ARIN to end-user
organizations: Criteria), to read:

To qualify for a direct assignment, an organization must:

1. not be an IPv6 LIR; and

2. qualify for an IPv4 assignment or allocation from ARIN under the IPv4
policy currently in effect, or demonstrate efficient utilization of all
direct IPv4 assignments and allocations, each of which must be covered
by a current ARIN RSA.

Rationale:

Current policy allows direct IPv6 allocations and assignments to nearly
all organizations with IPv4 allocations or assignments from ARIN. As a
result, such organizations can get IPv6 space just as easily as they can
get IPv4 space, making it easy for them to transition to IPv6 as soon as
they're ready to do so. However, there are some organizations who
received IPv4 /23's and /24's prior to the formation of ARIN, and use
that space in a multihomed, provider-independent fashion. Under current
policy, such organizations cannot get IPv6 PI space without artificially
inflating host counts, and are therefore discouraged from adopting IPv6.
This policy proposal aims to remove this disincentive, and allow such
organizations to easily adopt IPv6.

In addition, pre-ARIN assignments were issued through an informal
process, and many legacy resource holders have not yet entered into a
formal agreement with ARIN, the manager of many such IP numbering
resources. This policy proposal would require that such assignments be
brought under a current ARIN Registration Services Agreement, thereby
formalizing the relationship.

Some pre-ARIN assignments may not be used efficiently. As unallocated
IPv4 numbering resources are approaching exhaustion, it is important to
ensure efficient utilization of IPv4 assignments, and to arrange for
reclamation of unused space. Therefore, this policy would require that
the organization wishing to receive IPv6 PI space demonstrate efficient
utilization of their IPv4 assignment. (Efficient utilization is already
defined elsewhere in policy, and the exact mechanism for achieving and
determining efficient use is a matter of procedure, not of policy, so
detailed procedures are not included in the policy statement above. The
intent is that any organization with an assignment of /23 or larger
which is less than 50% utilized would renumber and return whole unused
CIDR blocks as necessary to bring the remaining CIDR block to 50%
utilization or higher. A /24 should be considered efficiently utilized
as long as it is in use for multihoming, as /25's and smaller are not
routable for that purpose.)

It has been suggested that this policy would be useful only until the
growth of IPv6 exceeds the growth of IPv4. I would agree with this, and
would further posit that the existing "qualify ... under the IPv4 policy
currently in effect" language should also be modified at that time. I
have therefore proposed this policy with a policy term of "permanent",
with the expectation that this section of policy (6.5.8.1) will be
rewritten at the appropriate time to entirely remove all IPv4 dependencies.

Timetable for implementation: immediate





From info at arin.net  Tue Mar 11 12:31:01 2008
From: info at arin.net (Member Services)
Date: Tue, 11 Mar 2008 12:31:01 -0400
Subject: ARIN XXI - Policy Proposals and Draft Agenda
Message-ID: <47D6B3C5.7030601@arin.net>

The following policy proposals have been under discussion on the ARIN
Public Policy Mailing List and will be presented for consideration at
the upcoming ARIN XXI Public Policy Meeting in Denver on 7-8 April 2008.

2008-3: Community Networks IPv6 Allocation
2008-2: IPv4 Transfer Policy Proposal
2008-1: SWIP support for smaller than /29 assignments
2007-27: Cooperative distribution of the end of the IPv4 free pool
2007-23: End Policy for IANA IPv4 allocations to RIRs
2007-21: PIv6 for legacy holders with RSA and efficient use
2007-17: Legacy Outreach and Partial Reclamation
2007-14: Resource Review Process

The full text for each proposal can be found at:
http://www.arin.net/policy/proposal_archive.html

Agenda information has been updated. Find the draft agenda as well as
hotel information at:
http://www.arin.net/ARIN-XXI/

ARIN XXI attendees are eligible for a special room rate of $189 (USD),
based on availability, if reservations are made before THIS Friday, 14
March. So make your hotel reservation and register for the meeting today!

Regards,

Member Services
American Registry for Internet Numbers (ARIN)




From info at arin.net  Tue Mar 18 10:45:09 2008
From: info at arin.net (Member Services)
Date: Tue, 18 Mar 2008 10:45:09 -0400
Subject: ARIN XXI Remote Participation and Webcast
Message-ID: <47DFD575.2070207@arin.net>

Are you unable to join us in Denver for ARIN XXI?  We have a solution! 
To facilitate community participation, ARIN offers free remote 
participation to any individual. Registered remote participants may post 
questions or comments, via e-mail, which will be moderated and presented 
during normal question and answer periods throughout the agenda.

All ARIN XXI activities involving public participation and comment, 
including the Sunday sessions on the Legacy RSA, Introduction to IRPEP 
and the Open Policy Hour, as well as the ARIN Public Policy and Members 
Meetings will be webcast, but only remote registrants will be able to 
submit questions and comments.  All remote participants are subject to 
the Remote Participation Acceptable Use Policy (AUP).

Registration for remote participation is available through our online 
meeting registration system. To register, please visit the ARIN XXI home 
page: http://www.arin.net/ARIN-XXI/, click the "Register for the 
Meeting" button at the top of the page, choose "ARIN XXI Remote 
Participant" from the drop-down box, and complete the subsequent form. 
The live meeting webcast is available without registering as a remote 
participant.

Additional information about remote participation and the webcast, 
including the Remote Participation AUP, is available at:

http://www.arin.net/ARIN-XXI/webcast.html

Webcast access details will be posted through the link above before the 
meeting. The webcast will begin Sunday, 6 April 2008 at 3:00 PM MDT 
(UTC/GMT -6 hours).

Regards,

Member Services
American Registry for Internet Numbers (ARIN)






From info at arin.net  Fri Mar 21 14:46:13 2008
From: info at arin.net (Member Services)
Date: Fri, 21 Mar 2008 14:46:13 -0400
Subject: Policy Proposal 2008-2 - Staff Assessment
Message-ID: <47E40275.3000601@arin.net>

Policy Proposal 2008-2
Title:  IPv4 Transfer Policy (authors ARIN AC)
Revision Submitted: Mar 7, 2008
Date of Assessment:  March 21, 2008

ARIN Staff Assessment

The assessment of this proposal includes comments from ARIN staff and
the ARIN General Counsel. It contains analysis of procedural, legal, and
resource concerns regarding the implementation of this policy proposal
as it is currently stated. Any changes to the language of the proposal
may necessitate further analysis by staff and Counsel.

I.      Proposal

Policy Proposal is available as Annex A below and at:
http://www.arin.net/policy/proposals/2008_2.html

II.           Understanding of the proposal:

ARIN staff understands that this proposal introduces a new set of
criteria to justify transfers of the available IANA IPv4 unicast address
pool following the depletion of this space. Specifically, the existing
Transfer Policy sections are consolidated from three sections to two
(8.1 and 8.2) and a new section 8.3 is added that defines criteria for
?Simple Transfers?, which allow an organization with excess IPv4
addresses to transfer those addresses to an organization with a need for
additional IPv4 addresses, and creates a listing service to bring the
two parties together.

III.     Issues and Concerns

A.      ARIN Staff Comments:

8.0      Transfers

General Observations

?	Policy language and stated criteria are generally broad and subjective
(most criteria contain words like ?may? and ?should? vs concrete words
like ?will? and ?must?).  This leads requestors to believe that they are
not obligated to provide documentation and justification for their
transfer.  The author should consider using a reference such as RFC 2119
to define how these words are generally interpreted.

8.1      Transfers

?	This policy does not cover those Internet Number Resources that are
neither covered the ARIN Registration Services Agreement or the ARIN
Legacy Registration Services Agreement.
?	The stated purpose for the original allocation may be difficult for an
organization to provide given the requester may not be the original
holder of the number resources.
?	It is unclear from the text whether all resources being transferred
have to be re-justified according to current ARIN policy.

8.2      Transfers as an Artifact of Change in Resource Holder Ownership

It is difficult if not impossible for a new requestor to provide
?evidence that the new entity has acquired the assets which had, as of
the date of the acquisition or proposed reorganization, justified the
current entity's use of the number resource."  Again, the requestor may
not be the original holder of the number resources.

8.2.1     Documentation Requirements

?	It maybe difficult for some requestors to obtain the legal instrument
that effected the transfer
?	Legal documents may be unavailable, particularly when the transactions
occurred years before
?	Transactions between small private entities are often difficult to
authenticate or verify due to lack of support documentation.  Some are
based on an anecdotal ?gentleman?s agreement.
?	Legal documents are often difficult to authenticate because parties to
maybe unreachable.
8.3. Simple Transfer of IPv4 Addresses
?	8.3.2 "business failure" is a nebulous term and could represent an
avenue of abuse.  Staff recommends removal of this term from the policy
text.

?	8.3.6 puts a great deal of responsibility into ARIN staff hands to
control the supply in the listing service. This will require a
significant amount of work to develop procedures, communication
practices, and staff training.  This will take approximately 3 to 6
months for this to occur.

?	8.3.7 provides for an audit exemption.  Under the current RSA, ARIN
has the right to audit a block at any given time.


B.    ARIN General Counsel

This policy is a major departure from existing ARIN policy which has
generally prohibited transfers except in specific, limited
circumstances. We therefore address the overall intent of the policy
from a legal perspective.

No matter what policy ARIN implements, it seems likely that there will
be more disputes, and hence more legal risk, once ARIN can no longer
satisfy requests for v4 resources.  But if ARIN attempted to continue
its existing policy to prohibit most transfers, counsel anticipates that
widespread transfers would nonetheless occur -- imposing significant
future legal costs including the costs of investigation, arbitration,
and litigation.  By providing a realistic mechanism for transfers to
occur, a broader and more permissive transfer policy would likely
relieve ARIN of many such costs.  We therefore consider risks under the
proposed policy compared to the risks of retaining the current policy.

We now turn to more specific concerns.

The first legal concern in evaluating the specifics of any transfer
policy is whether it is consistent with antitrust law. Currently, this
policy does not create concerns.  By creating a white market for
transfer of v4 resources, the policy arguably advances competition.

Second, a serious risk implicit in the creation of a transfer policy is
that it will lead to additional litigation if ARIN, for example, refuses
to permit a transfer it finds inconsistent with any policy eventually
adopted. However, we believe this risk is adequately managed in the
current draft, particularly because concern over this issue must be seen
the context of the likelihood of expensive litigation to enforce the
current policy if a new transfer policy is not adopted in some form.

Third, the new policy will have to be carefully reviewed to ensure it
supports to the legal theory of the Internet community that numbers are
not "owned."  In particular, ARIN will continue to claim that it does
not grant "ownership," and that what is being transferred is the right
to make beneficial use of number resources consistent with applicable
policy. Poorly drafted transfer policies could undercut this current
clear understanding. However, we currently have no serious concerns
about the language of this proposal.


IV. Resource Impact ? Moderate

The resource impact of implementing this policy is moderate. Barring any
unforeseen resource requirements, this policy could be implemented
within 180 days from the date of the ratification of the policy by the
ARIN Board of Trustees.  It will require the following:
? Updates to guidelines will be required
? Staff training will be required
? A new template will be required
? Software will be needed
? New hardware may be required
? Details of the systems to implement the request, pre-qualification
certification, transfer and listing service would need to be identified.
This would require additional information about the form of the document
to certify the pre-qualification and the mechanism and access
restrictions for the listing service.

Respectfully submitted,

Member Services
American Registry for Internet Numbers (ARIN)


####


Annex A

Policy Proposal 2008-2
IPv4 Transfer Policy Proposal

Author: ARIN Advisory Council

Proposal Version: 1.1

Date: 7 March 2008

Proposal type: modify

Policy term: permanent

Policy statement:

Replace the current NRPM section 8 with the following --

8. Transfers

[8.1. Transfers ? retain as is:

Number resources are non-transferable and are not assignable to any
other organization unless ARIN has expressly and in writing approved a
request for transfer. ARIN is tasked with making prudent decisions on
whether to approve the transfer of number resources.

It should be understood that number resources are not "sold" under ARIN
administration. Rather, number resources are assigned to an organization
for its exclusive use for the purpose stated in the request, provided
the terms of the Registration Services Agreement continue to be met and
the stated purpose for the number resources remains the same. Number
resources are administered and assigned according to ARIN's published
policies.

Number resources are issued, based on justified need, to organizations,
not to individuals representing those organizations. Thus, if a company
goes out of business, regardless of the reason, the point of contact
(POC) listed for the number resource does not have the authority to
sell, transfer, assign, or give the number resource to any other person
or organization. The POC must notify ARIN if a business fails so the
assigned number resources can be returned to the available pool of
number resources if a transfer is not requested and justified.]

[8.2 ? remove the word ?only?, and retitle to ?Transfers as an Artifact
of Change in Resource Holder Ownership?:

8.2. Transfers as an Artifact of Change in Resource Holder Ownership
ARIN will consider requests for the transfer of number resources upon
receipt of evidence that the new entity has acquired the assets which
had, as of the date of the acquisition or proposed reorganization,
justified the current entity's use of the number resource. Examples of
assets that justify use of the number resource include, but are not
limited to:
? Existing customer base
? Qualified hardware inventory
? Specific software requirements.]
[Renumber existing 8.3 to 8.2.1 and retitle to ?Documentation
Requirements for Transfers as an Artifact of Change in Resource Holder
Ownership?:

8.2.1. Documentation Requirements for Transfers as an Artifact of Change
in Resource Holder Ownership In evaluating a request for transfer, ARIN
may require the requesting organization to provide any of the following
documents, as applicable, plus any other documents deemed appropriate:
? An authenticated copy of the instrument(s) effecting the transfer of
assets, e.g., bill of sale, certificate of merger, contract, deed, or
court decree
? A detailed inventory of all assets utilized by the requesting party in
maintaining and using the number resource
? A list of the requesting party's customers using the number resource.
If further justification is required, the requesting party may be asked
to provide any of the following, or other supporting documentation, as
applicable:
? A general listing of the assets or components acquired
? A specific description of acquisitions, including:
o Type and quantity of equipment
o Customer base
? A description of how number resources are being utilized
? Network engineering plans, including:
o Host counts
o Subnet masking
o Network diagrams
o Reassignments to customers]

8.3. Simple Transfer of IPv4 Addresses

After the exhaustion of the IANA IPv4 free pool (when IANA allocates its
last unallocated unicast IPv4 address block), ARIN will also process
IPv4 address transfer requests subject to the following conditions.
These conditions apply only to Simple IPv4 transfers, not to transfers
performed according to section 8.2.

8.3.1 Conditions on the transferor (the organization providing addresses
for transfer):
? The transferor resides in the ARIN service area.
? The transferor has signed an RSA and/or a legacy RSA covering the IPv4
addresses transferred.
? The transferor has no outstanding balances with ARIN.
? The transferor has not received any IPv4 allocations or assignments
from ARIN (through ordinary allocations or assignments, or through this
Simple Transfer policy) within the preceding 24 months.
? The transferor may not request any IPv4 allocations or assignments
from ARIN (through ordinary allocations or assignments, or through this
Simple Transfer policy) within the subsequent 24 months.

8.3.2 Conditions on the transferee (the organization receiving the
transferred addresses):
? The transferee resides in the ARIN service area and intends to use the
transferred IPv4 addresses within the ARIN service area.
? The transferee has no outstanding balances with ARIN.
? The transferee?s need is confirmed by ARIN, according to current ARIN
policies, including but not limited to confirmation of utilization rate
of any prior IPv4 allocations, assignments, or previously transferred
IPv4 addresses held by the transferee.
? The transferee signs (or has previously signed) an RSA covering the
IPv4 addresses transferred.
? The transferee has not provided any IPv4 addresses for transfer
through this Simple Transfer process within the preceding 24 months.
? The transferee may not provide any IPv4 addresses for transfer through
this Simple Transfer process within the subsequent 24 months, except in
the case of business failure.
? The transferee may request and receive a contiguous CIDR block large
enough to provide a 12 month supply of IPv4 addresses.
? The transferee may only receive one IPv4 address transfer through this
Simple Transfer process every 6 months.

8.3.3 Conditions on the IPv4 address block to be transferred:
? The IPv4 block must comply with applicable ARIN requirements,
including minimum allocation size (i.e. NRPM 4.2.2., 4.2.4., 4.3.2.,
4.3.6.). However, an IPv4 allocation or assignment of /24 or larger, but
smaller than the current minimum allocation size, may be transferred as
a whole resource, but may not be subdivided.
? The IPv4 block must currently be registered for use within the ARIN
service area, either as part of an address block assigned by IANA to
ARIN, or as part of a legacy address block allocated within the ARIN
service area.
? There must exist no dispute as to the status of the IPv4 block or
regarding the allocation or assignment of such block to the transferor.
? The transferor may retain one contiguous address range out of their
original allocation or assignment for their own use, and transfer the
other contiguous address range. If the address range to be transferred
consists of multiple non-aggregatable CIDR blocks, each may be
transferred to a different transferee. The retained address range may
not be further subdivided or transferred for a period of 12 months.
Notwithstanding the preceding, the block may be subdivided as provided
in section 8.3.6.

8.3.4 Fees
? Completion of a transfer requires payment of a transfer fee according
to ARIN?s schedule of fees.
? The transferee will be subject to all future ARIN membership and
service fees according to the transferee?s total address holdings.

8.3.5 Pre-qualification

? An interested transferee must seek pre-qualification from ARIN to
confirm its eligibility to receive a transfer (including satisfaction of
need according to current ARIN policies) before making any solicitation
for transfer. Upon pre-qualification, ARIN will provide the transferee
with documentation of the pre-qualification, including the size (CIDR
prefix length) of the largest IPv4 address block the transferee is
eligible to receive, and the expiration date of the pre-qualification.
? An interested transferor must seek pre-qualification from ARIN to
confirm its eligibility to offer a transfer (including lack of
outstanding balances and having signed an RSA) before offering IPv4
address resources for transfer. Upon pre-qualification, ARIN will
provide the transferor with documentation of the pre-qualification,
including the network block and the expiration date of the
pre-qualification.

8.3.6 Deaggregation when Permitted by ARIN

If ARIN determines that there is an inadequate supply of small blocks,
ARIN may allow transferors to subdivide network blocks beyond the
limited subdivision permitted under 8.3.3. ARIN will attempt to ensure
an adequate supply of small blocks while minimizing deaggregation.

8.3.7. Safe Harbor for IPv4 Transfers through this Simple Transfer Process

When an IPv4 address resource is made available for transfer, it shall
be deemed exempt from ARIN utilization audit until 90 days after its
transfer pre-qualification or until the transfer is completed, whichever
comes first.

In the event that a transfer is not consummated within the
prequalification time period, the block may be immediately
re-prequalified for transfer. Notwithstanding the current offered state
of the address resource, however, the audit exemption period shall
expire untolled 90 days after the expiration of the first
pre-qualification period. After the expiration of any utilization audit
exemption period, ARIN shall have 90 days in which to initiate a
utilization audit. In no event shall non-exempt time be construed to
extend the end of the next exemption period.

8.3.8. Simple IPv4 Transfers to or from Organizations Under Common
Ownership or Control

If an IPv4 transferor or transferee is under common ownership or control
with any other organization that holds one or more IPv4 blocks, the IPv4
transfer request must report all such organizations under common
ownership or control.

When evaluating compliance with IPv4 Simple Transfer conditions, ARIN
may consider a transferor?s transfer request in light of requests from
other organizations under common ownership or control with the
transferor. Similarly, ARIN may consider a transferee?s request in light
of requests from other organizations under common ownership or control
with the transferee. In evaluating requests from other organizations
under common ownership or control, ARIN staff will consider the
relationship between the organizations, the degree of coordination
between the organizations, and the bona fide use of the addresses at
issue to determine whether all appropriate conditions are met.

8.3.9. Record-keeping and Publication of Simple Transfers of IPv4 Addresses

ARIN will develop and operate a listing service to assist interested
transferors and transferees by providing them a centralized location to
post information about IPv4 blocks available from prequalified
transferors and IPv4 blocks needed by prequalified transferees.
Participation in the listing service is voluntary.

After completion of the transfer, ARIN will update the registration
records pertaining to the IPv4 block at issue. ARIN will adjust its
records as to the holdings of the transferor and transferee.

After the transfer, ARIN will publish WHOIS data that reflects the
current allocation or assignment of the transferred block. ARIN will
also make available information about any prior recipient(s) of such
block. ARIN will also publish a log of all transfers, including block,
transferor, transferee, and date.


Rationale:
The ARIN Board of Trustees asked the Advisory Council to consider a set
of questions around the depletion of the free pool of IPv4 addresses,
the transition to IPv6 for Internet address needs in the future, and
ARIN's possible role in easing the transition.

Over the past few years the AC has spent a great deal of time reflecting
on these issues ? as a group, as individuals, and in consultation with
the community. One outcome of this process is this policy proposal,
which the AC is submitting for consideration at the next meeting. We are
proposing some changes to existing ARIN policy regarding the transfer of
IP address block registrations between subscribers, which will allow for
the emergence of trade in IPv4 address space, with ARIN to provide a
listing service for address blocks available for transfer under the
liberalized policy. We are aware that this proposal, if adopted, will
mark a major change in ARIN's role in the community and the Internet.

This policy proposal would create a transfer mechanism for IPv4 number
resources between those who have excess resources and those who have a
need, thereby allowing ARIN to continue to serve its mission after IANA
free pool exhaustion. This proposal would also set conditions on such
transfers intended to preserve as much as possible the existing policy
related to efficient, needs-based resource issuance, and would leverage
ARIN's extensive control systems, audit trails, and recognized position
as a trusted agent to avoid speculation and hoarding and diminish the
likelihood and extent of an uncontrolled 'black market' where the risk
and potential for fraud is immeasurably higher.

Many of the transfer conditions are self-explanatory, but some worth
highlighting are that:
? To discourage speculation, a waiting period (proposed at 24 months) is
required before a transferee (or ordinary resource recipient) can become
a transferor, or vice versa.
? Transferees must qualify for IPv4 space (just as they do today when
getting it from ARIN) before they can receive address space by transfer,
or solicit space on a listing service.
? To discourage unnecessarily rapid growth of routing tables, an
allocation or assignment may not be arbitrarily deaggregated. To allow a
transferor to downsize within their existing space, they may split off a
contiguous address range, once every 12 months, and transfer the
resulting netblock(s), which are subject to ARIN?s minimum allocation
size, to one or more transferee(s).
? A transferee may receive one transfer every 6 months, so they?ll be
incented to transfer a block appropriately sized for their needs, which
will further discourage deaggregation and keep smaller blocks available
for smaller organizations.
The proposal would also have ARIN develop and operate a listing service
to facilitate transfers and provide an authoritative central source of
information on space available and requested for transfer. It would not
prohibit private party transactions, but would require that potential
transferors and transferees be pre-qualified first, so that neither
party will encounter any unexpected surprises when they ask ARIN to
process the transfer.

Timetable for implementation: Immediately, with most aspects of policy
taking effect upon IANA exhaustion, per the policy text.




From info at arin.net  Fri Mar 21 14:46:27 2008
From: info at arin.net (Member Services)
Date: Fri, 21 Mar 2008 14:46:27 -0400
Subject: Policy Proposal 2008-1 - Staff Assessment
Message-ID: <47E40283.6010707@arin.net>

Policy Proposal 2008-1
Title:  SWIP Support for smaller than /29 Assignments
Proposal Submitted: Feb 26, 2008
Date of Assessment: Mar 21, 2008


ARIN Staff Assessment

The assessment of this proposal includes comments from ARIN staff and
the ARIN General Counsel. It contains analysis of procedural, legal, and
resource concerns regarding the implementation of this policy proposal
as it is currently stated. Any changes to the language of the proposal
may necessitate further analysis by staff and Counsel.

I.      Proposal

Policy Proposal is available as Annex A below and at:
http://www.arin.net/policy/proposals/2008_1.html


II.     Understanding of the proposal

Staff understands that this policy will allow upstream ISPs to report
utilization to ARIN by submitting their customer and/or internal
assignments of /29 or smaller via SWIP and RWHOIS server in addition to
the current accepted method which is a flat file in the form of an excel
spreadsheet of similar.  This will allow customers to use SWIP or RWHOIS
server as a single source for reporting their utilization data back to
ARIN.


III.    Issues and concerns

A.	ARIN Staff Comments

Staff foresees no problems with the implementation of this policy and no
conflicts with current policy.


B.	ARIN General Counsel

Counsel sees no significant legal or litigation issues related to this
policy.


IV. Resource Impact ? Minimal

The resource impact of implementing this policy is minimal. Barring any
unforeseen resource requirements, this policy could be implemented
within 90 days from the date of the ratification of the policy by the
ARIN Board of Trustees.  It will require the following:

? Changes to the registration software to accept the submission of /29s
and smaller via the various reassignment templates.
? Changes to Guidelines
? Minor template changes
? May increase RSD?s workload if an overwhelming number of people choose
to swip allocations smaller than /29
? Staff  anticipates no major issues with Whois (performance, storage,
gen, etc.)

Respectfully submitted,

Member Services
American Registry for Internet Numbers (ARIN)




##*##


Annex A

Policy Proposal 2008-1
SWIP Support for smaller than /29 Assignments

Author: Joe Maimon

Proposal Version: 1

Submission Date: 26 February 2008

Proposal type: modify

Policy term: permanent

Policy statement:

4.2.2.1.2.)

"
ISPs must provide reassignment information on the entire previously
allocated block(s) via SWIP or RWHOIS server for /29 or larger blocks.
For blocks smaller than /29 and for internal space, ISPs should provide
utilization data using the table format described in Section 4.2.3.7.5.
"

Replace with

"
ISPs must provide reassignment information on the entire previously
allocated block(s) via SWIP or RWHOIS server for /29 or larger blocks.
For blocks smaller than /29 and for internal space, ISPs should provide
utilization data either via SWIP or RWHOIS server or by using the table
format described in Section 4.2.3.7.5.
"

4.2.2.2.1.)

"
Utilization for blocks smaller than /29 can be documented using the
format described in Section 4.2.3.7.5.
"

Replace with

"
Utilization for blocks smaller than /29 can be documented via SWIP or
RWHOIS server or by using the format described in Section 4.2.3.7.5.
"

4.2.3.7.2.)

"
For blocks smaller than /29 and for internal space, ISPs should provide
utilization data using the format described in Section 4.2.3.7.5.
"

Replace with

"
For blocks smaller than /29 and for internal space, ISPs should provide
utilization data via SWIP or RWHOIS server or by using the format
described in Section 4.2.3.7.5.
"

4.2.3.7.5.) Accounting for additional utilization

"
The following format should be used to provide the required information
for utilization of blocks smaller than /29 and for describing internal
networks:
"

Replace with

"
The following format should be used to provide the required information
for utilization of blocks smaller than /29 and for describing internal
networks when either SWIP or RWHOIS server is not used:
"

Rationale:

With increasing frequency of smaller than /29 assignements to customers,
the ability for ISP's to utilize SWIP or RWHOIS as a single
comprehensive source of their utilization data should be supported. To
implement this policy change, ARIN SWIP would need to no longer reject
SWIP templates smaller then /29.

Timetable for implementation: Immediate




From info at arin.net  Fri Mar 21 14:47:08 2008
From: info at arin.net (Member Services)
Date: Fri, 21 Mar 2008 14:47:08 -0400
Subject: Policy Proposal 2007-21 - Staff Assessment
Message-ID: <47E402AC.3080009@arin.net>

Policy Proposal 2007-21
Title:  PIv6 for legacy holders with RSA and efficient use
Revision Submitted: Mar 11, 2008
Date of Assessment:  Mar 21, 2008

ARIN Staff Assessment

The assessment of this proposal includes comments from ARIN staff and
the ARIN General Counsel. It contains analysis of procedural, legal, and
resource concerns regarding the implementation of this policy proposal
as it is currently stated. Any changes to the language of the proposal
may necessitate further analysis by staff and Counsel.

I.	Proposal

Policy Proposal is available as Annex A below and at:
http://www.arin.net/policy/proposals/2007_21.html

II.	Understanding of the proposal

ARIN staff understands that this proposal would make direct assignments
of IPv6 space available to any organization with an efficiently utilized
v4 assignment or allocation covered under an RSA.

III. Issues and concerns

A.	ARIN Staff ? General Comment

The revised policy text is clear and could be implemented as written.


B.	ARIN General Counsel

This policy does not create any significant legal or litigation concerns.

IV. Resource Impact ? Minimal

The resource impact of implementing this policy is viewed as minimum.
Barring any unforeseen resource requirements, this policy could be
implemented within 30 ? 90 days from the date of the ratification of the
policy by the ARIN Board of Trustees.  It will require the following:

? Updates to Guidelines will be required
? Staff training will be required
? New process to manually add RSA coverage will be required

Respectfully submitted,

Member Services
American Registry for Internet Numbers (ARIN)


##*##


Annex A

Policy Proposal 2007-21
PIv6 for legacy holders with RSA and efficient use

Author: Scott Leibrand

Proposal Version: 2.0

Date: 11 March 2008

Proposal type: modify

Policy term: permanent

Policy statement:

Modify NRPM section 6.5.8.1 (Direct assignments from ARIN to end-user
organizations: Criteria), to read:

To qualify for a direct assignment, an organization must:
1. not be an IPv6 LIR; and
2. qualify for an IPv4 assignment or allocation from ARIN under the IPv4
policy currently in effect, or demonstrate efficient utilization of all
direct IPv4 assignments and allocations, each of which must be covered
by a current ARIN RSA.

Rationale:

Current policy allows direct IPv6 allocations and assignments to nearly
all organizations with IPv4 allocations or assignments from ARIN. As a
result, such organizations can get IPv6 space just as easily as they can
get IPv4 space, making it easy for them to transition to IPv6 as soon as
they're ready to do so. However, there are some organizations who
received IPv4 /23's and /24's prior to the formation of ARIN, and use
that space in a multihomed, provider-independent fashion. Under current
policy, such organizations cannot get IPv6 PI space without artificially
inflating host counts, and are therefore discouraged from adopting IPv6.
This policy proposal aims to remove this disincentive, and allow such
organizations to easily adopt IPv6.

In addition, pre-ARIN assignments were issued through an informal
process, and many legacy resource holders have not yet entered into a
formal agreement with ARIN, the manager of many such IP numbering
resources. This policy proposal would require that such assignments be
brought under a current ARIN Registration Services Agreement, thereby
formalizing the relationship.

Some pre-ARIN assignments may not be used efficiently. As unallocated
IPv4 numbering resources are approaching exhaustion, it is important to
ensure efficient utilization of IPv4 assignments, and to arrange for
reclamation of unused space. Therefore, this policy would require that
the organization wishing to receive IPv6 PI space demonstrate efficient
utilization of their IPv4 assignment. (Efficient utilization is already
defined elsewhere in policy, and the exact mechanism for achieving and
determining efficient use is a matter of procedure, not of policy, so
detailed procedures are not included in the policy statement above. The
intent is that any organization with an assignment of /23 or larger
which is less than 50% utilized would renumber and return whole unused
CIDR blocks as necessary to bring the remaining CIDR block to 50%
utilization or higher. A /24 should be considered efficiently utilized
as long as it is in use for multihoming, as /25's and smaller are not
routable for that purpose.)

It has been suggested that this policy would be useful only until the
growth of IPv6 exceeds the growth of IPv4. I would agree with this, and
would further posit that the existing "qualify ... under the IPv4 policy
currently in effect" language should also be modified at that time. I
have therefore proposed this policy with a policy term of "permanent",
with the expectation that this section of policy (6.5.8.1) will be
rewritten at the appropriate time to entirely remove all IPv4 dependencies.

Timetable for implementation: immediate




From info at arin.net  Fri Mar 21 14:47:38 2008
From: info at arin.net (Member Services)
Date: Fri, 21 Mar 2008 14:47:38 -0400
Subject: Policy Proposal 2007-23 - Staff Assessment
Message-ID: <47E402CA.6030308@arin.net>

Policy Proposal 2007-23 (Global)
Title:  End Policy for IANA IPv4 allocations to RIRs
Revision Submitted: Feb 8, 2008
Date of Assessment: Mar 21, 2008


ARIN Staff Assessment

The assessment of this proposal includes comments from ARIN staff and
the ARIN General Counsel. It contains analysis of procedural, legal, and
resource concerns regarding the implementation of this policy proposal
as it is currently stated. Any changes to the language of the proposal
may necessitate further analysis by staff and Counsel.

I.	Proposal

Policy Proposal is available as Annex A below and at:
http://www.arin.net/policy/proposals/2007_23.html

II.	Understanding of the proposal

ARIN staff understands that this policy would have IANA allocate a
single /8 to each of the 5 RIRs ?at the point when the IANA free pool is
more than 5 /8s, but too small to fulfill a request from an RIR without
using part of the final 5 /8s? or the point of imminent exhaustion.

III.	Comments

A.	ARIN Staff

1.	The policy conflicts with the spirit of RFC 2050 in which fairness
and efficiency of allocation by IANA to the RIRs is cited.
2.	Author did not indicate placement in the NRPM. It would go in to
Section 10.

B.	ARIN General Counsel

This policy presents no significant legal issues.

It seeks to substitute a different mechanism than actual utilization to
allocate the last 5 unallocated blocs of IPV4 resources, one each to
each RIR.

It might be arguably discriminatory against ARIN, or any other RIR which
has a high 'burn rate' for a slash 8, compared to those RIRs with a
slower burn rate; it also could be more discriminatory if the low burn
rate RIR's are provided a slash 8 just before the trigger event and
consequently end up with 2 slash 8's, with a lower burn rate. However,
Counsel sees these as political/policy considerations and not legal issues.


IV. Resource Impact ? Minimal

The resource impact of implementing this policy is viewed as minimum.
Barring any unforeseen resource requirements, this policy could be
implemented within 30 -90 days from the date of the ratification of the
policy by the ARIN Board of Trustees.  It will require the following:

? Updates to Guidelines will be required
? Staff training will be required

Respectfully submitted,

Member Services
American Registry for Internet Numbers (ARIN)


##*##


Annex A

Policy Proposal 2007-23 (Global)
End Policy for IANA IPv4 allocations to RIRs

Proposal Version: Version 2

Date: 8 February 2008

Author: Roque Gagliano, ANTEL; Francisco Obispo, CENIT; Haitham EL
Nakhal, MCIT; Didier Allain Kla, ISOC Cote d'Ivoire; JPNIC IPv4
countdown policy team: - Akinori Maemura - Akira Nakagawa - Izumi
Okutani - Kosuke Ito - Kuniaki Kondo - Shuji Nakamura - Susumu Sato -
Takashi Arano - Tomohiro Fujisaki - Tomoya Yoshida - Toshiyuki Hosaka

Proposal type: new

Policy term: temporary

Policy statement:

This is a revised version of;

prop-046: IPv4 countdown policy proposal

prop-051: Global policy for the allocation of the remaining IPv4 address
space

This policy describes the process for the allocation of the remaining
IPv4 space from IANA to the RIRs. When a minimum amount of available
space is reached, one /8 will be allocated from IANA to each RIR,
replacing the current IPv4 allocation policy.

In order to fulfill the requirements of this policy, at the time it is
adopted, one /8 will be reserved by IANA for each RIR. The reserved
allocation units will no longer be part of the available space at the
IANA pool. IANA will also reserve one /8 to any new RIR at the time it
is recognized.

The process for the allocation of the remaining IPv4 space is divided in
two consecutive phases:

4.1. Existing Policy Phase:

During this phase IANA will continue allocating IPv4 addresses to the
RIRs using the existing allocation policy. This phase will continue
until a request for IPv4 address space from any RIR to IANA either
cannot be fulfilled with the remaining IPv4 space available at the IANA
pool or can be fulfilled but leaving the IANA remaining IPv4 pool empty.

This will be the last IPv4 address space request that IANA will accept
from any RIR. At this point the next phase of the process will be initiated.

4.2. Exhaustion Phase:

IANA will automatically allocate the reserved IPv4 allocation units to
each RIR (one /8 to each one) and respond to the last request with the
remaining available allocation units at the IANA pool (M units).

4.2.1. Size of the final IPv4 allocations:

During this phase IANA will automatically allocate one /8 to each RIR
from the reserved space defined in this policy. IANA will also allocate
M allocation units to the RIR that submitted the last request for IPv4
addresses.

4.2.2. Allocation of the remaining IPv4 Address space:

After the completion of the evaluation of the final request for IPv4
addresses, IANA MUST:

A) Immediately notify the NRO about the activation of the second phase
of this policy.

B) Proceed to allocate M allocation units to the RIR that submitted the
last request for IPv4 address space.

C) Proceed to allocate one /8 to each RIR from the reserved space.

Rationale: The exhaustion of IPv4 address space is projected to take
place within the next few years. This proposal seeks to focus on
measures that should be taken globally in the address management area in
order to prepare for the situation in all RIR regions.

To continue applying a global coordinated policy for distribution of the
last piece(s) of each RIR's unallocated address block does not match the
reality of the situation in each RIR region.

Issues each RIR region will face during the exhaustion period vary by
region as the level of development of IPv4 and IPv6 are widely
different. As a result, applying a global co-ordinated policy may not
adequately address issues in a certain region while it could be work for
the others.

For example, in a region where late comers desperately need even small
blocks of IPv4 addresses to access to the IPv4 Internet, a policy that
defines the target of allocations/assignments of IPv4 address space to
be late comers would be appropriate in such region. This would allow
availablilty of IPv4 address space for such requirements for more years.

Another example comes from difference in IPv6 deployment rate. For a
region where IPv6 deployment rate is low, measures may be necessary to
prolong IPv4 address life for the existing business as well as for new
businesses until networks are IPv6 ready. Some regions may have strong
needs to secure IPv4 address space for translators.

A globally coordinated policy which addresses all the issues listed
above to meet the needs for all RIR regions may result in not solving
issues in any of the regions.

Timetable for implementation: after approval by ICANN board





From info at arin.net  Fri Mar 21 14:48:01 2008
From: info at arin.net (Member Services)
Date: Fri, 21 Mar 2008 14:48:01 -0400
Subject: Policy Proposal 2007-14	- Staff Assessment
Message-ID: <47E402E1.6080903@arin.net>

Policy Proposal 2007-14	
Title:   Resource Review Process
Proposal Submitted: Feb 21, 2008
Date of Assessment: Mar 21, 2008

ARIN Staff Assessment

The assessment of this proposal includes comments from ARIN staff and
the ARIN General Counsel. It contains analysis of procedural, legal, and
resource concerns regarding the implementation of this policy proposal
as it is currently stated. Any changes to the language of the proposal
may necessitate further analysis by staff and Counsel.

I.	Proposal

Policy Proposal is available as Annex A below and at:
http://www.arin.net/policy/proposals/2007_14.html

II.	Understanding of the proposal

This policy proposal provides clear policy authority to audit or reclaim
resources, guidelines for how it shall be done, and a guarantee of a
(minimum) six-month grace period so that the current user shall have
time to stop using any resources to be reclaimed.


III.	Comments

A.	ARIN Staff

1.  2c does not reconcile with the RSA, which grants ARIN authority to
request any data necessary and does not specify any sort of limitation
to frequency.

2.   Item 3 requires staff to share the results of an audit of an
organization?s resources.  Staff often reviews an organization?s
transaction history and resources during fraud or suspicious activity
investigations and feels that it is not always prudent to share those
results.

3.  Point 4b uses the term ?single aggregate block? Does this refer to a
single CIDR prefix, or to ?a contiguous range of addresses??


B.	ARIN General Counsel

This policy will be looked at very carefully in those instances where
ARIN demands data, or seeks to terminate and revoke resources previously
granted. It will guide ARIN, and any reviewing adjudication court who
may be required to evaluate a dispute, review it because it sets up
procedures for revocation, and requires production of data. Writing down
such policies may be important support for ARIN's application of such
policies. However, the same benefit can become a problem if the language
is not carefully constructed. Counsel supports a version of this policy
being enacted and believes adoption of this policy could reduce future
legal fees.

Some language tweaks may help. For this reason I am suggesting the
author and AC consider language that tightens the policy from a legal
perspective but is consistent with the perceived intent of the author.
Some language changes are more important than others.  Please note:
Outlook doesn't permit redlining to show; it automatically accepts the
redlined changes.  Therefore, the redlines have been accepted in 1-8 below.

1. ARIN may review the current usage of any resources issued by ARIN to
an organization. The organization shall furnish whatever records are
believed to be necessary by ARIN to perform this review.

2. ARIN may conduct such reviews:

a. when any new resource is requested, b. whenever ARIN has reason to
believe that the resources originally were obtained fraudulently, or in
contravention of existing policies, c. at any other time, without cause
having to be established, unless a prior review has been completed in
the preceding 24 months.

3. ARIN shall communicate the results of the review to the organization.

4. Organizations found by ARIN to be substantially out of compliance
with current ARIN policy shall be requested or required to return
resources to bring them into (or reasonably close to) compliance.

4a. The extent to which an organization may remain out of compliance
shall be based on the reasonable judgment of the ARIN staff and shall
balance all facts known, including the organizations utilization rate,
available address pool, and other factors as appropriate so as to avoid
forcing returns which will result in near-term additional requests or
unnecessary route de- aggregation.

4b. To the extent possible, entire blocks should be returned. Partial
address blocks shall be returned in such a way that the portion retained
will comprise a single aggregate block.

5. If the organization does not voluntarily return resources as
requested, ARIN may revoke any resources issued by ARIN as required to
bring the organization into overall compliance. ARIN shall follow the
same guidelines for revocation that are required for voluntary return in
the previous paragraph.

6. Except in cases of fraud, or intentional violations of policy, an
organization shall be provided a reasonable period of time to effect a
return. ARIN shall agree to a longer term with the organization if ARIN
believes the organization is working in good faith to restore compliance
and has a valid need for additional time to renumber out of the affected
blocks.

7. ARIN shall continue to maintain the resource(s) while their return or
revocation is pending, except no new maintenance fees shall be assessed
for the resource(s). (?)

8. Legacy resources in active use, regardless of utilization, are not
subject to revocation by ARIN, pursuant to this subsection. However, the
utilization of legacy resources shall be considered during a review to
assess overall compliance.

  Counsel continues not to agree with the first sentence of the
rationale which states ARIN "feels that current policy does not give
them the power to review or reclaim resources except in cases of
fraud...."  Counsel requests this be rewritten to reflect that such
powers need to be carefully delineated for application and ease of
understanding.

IV.	Resource Impact ?  Minimal

The resource impact of implementing this policy is viewed as minimal.
Barring any unforeseen resource requirements, this policy could be
implemented within 30 ? 90 days from the date of the ratification of the
policy by the ARIN Board of Trustees. Depending on the impact to RSD
this may require additional staff. It will require the following:

? Guidelines Changes
? Registration System Changes
? Staff training
? May increase RSD workload
? May increase turnaround times

Respectfully submitted,

Member Services
American Registry for Internet Numbers (ARIN)


##*##


Annex A

Policy Proposal 2007-14
Resource Review Process

Author: Owen DeLong, Stephen Sprunk

Date: 21 February 2008

Proposal type: modify

Policy term: permanent

Policy statement:

Add the following to the NRPM:

Resource Review

1. ARIN may review the current usage of any resources issued by ARIN to
an organization. The organization shall furnish whatever records are
necessary to perform this review.

2. ARIN may conduct such reviews:

a. when any new resource is requested,
b. whenever ARIN has cause to believe that the resources had originally
been obtained fraudulently, or c. at any other time without cause unless
a prior review has been completed in the preceding 24 months.

3. ARIN shall communicate the results of the review to the organization.

4. Organizations shown to be substantially out of compliance with
current ARIN policy shall return resources as needed to bring them into
(or reasonably close to) compliance.

4a. The extent to which an organization may remain out of compliance
shall be based on the best judgment of the ARIN staff and shall balance
the organizations utilization rate, available address pool, and other
factors as appropriate so as to avoid forcing returns which will result
in near-term additional requests or unnecessary route de- aggregation.

4b. To the extent possible, entire blocks should be returned. Partial
address blocks shall be returned in such a way that the portion retained
will comprise a single aggregate block.

5. If the organization does not voluntarily return resources as
required, ARIN may revoke any resources issued by ARIN as required to
bring the organization into overall compliance. ARIN shall follow the
same guidelines for revocation that are required for voluntary return in
the previous paragraph.

6. Except in cases of fraud, an organization shall be given a minimum of
six months to effect a return. ARIN shall negotiate a longer term with
the organization if ARIN believes the organization is working in good
faith to substantially restore compliance and has a valid need for
additional time to renumber out of the affected blocks.

7. ARIN shall continue to maintain the resource(s) while their return or
revocation is pending, except no new maintenance fees shall be assessed
for the resource(s).

8. Legacy resources in active use, regardless of utilization, are not
subject to revocation by ARIN. However, the utilization of legacy
resources shall be considered during a review to assess overall compliance.

9. In considering compliance with policies which allow a timeframe (such
as a requirement to assign some number of prefixes within 5 years)
failure to comply cannot be measured until after the timeframe specified
in the applicable policy has elapsed. Blocks subject to such a policy
shall be assumed in compliance with that policy until such time as the
specified time since issuance has elapsed.

Delete NRPM sections 4.1.2, 4.1.3, 4.1.4

Remove the sentence "In extreme cases, existing allocations may be
affected." from NRPM section 4.2.3.1.

Rationale:

ARIN feels that current policy does not give them the power to review or
reclaim resources except in cases of fraud, despite this being mentioned
in the Registration Services Agreement. This policy proposal provides
clear policy authority to do so, guidelines for how and under what
conditions it shall be done, and a guarantee of a (minimum) six- month
grace period so that the current user shall have time to renumber out of
any resources to be reclaimed.

The nature of the "review" is to be of the same form as is currently
done when an organization requests new resources, i.e. the documentation
required and standards should be the same.

The intent of paragraph 2c is to prevent ARIN from doing more than one
without-cause review in a 24 month period.

The renumbering period does not affect any "hold" period that ARIN may
apply after return or revocation of resources is complete.

The deleted sections/text would be redundant with the adoption of this
proposal.

Timetable for implementation: Immediate







From info at arin.net  Fri Mar 21 14:48:14 2008
From: info at arin.net (Member Services)
Date: Fri, 21 Mar 2008 14:48:14 -0400
Subject: Policy Proposal 2007-17	- Staff Assessment
Message-ID: <47E402EE.20104@arin.net>

Policy Proposal 2007-17	
Title:  Legacy Outreach and Partial Reclamation
Date Submitted: Feb. 21, 2008
Date of Assessment: Mar 21, 2008

ARIN Staff Assessment

The assessment of this proposal includes comments from ARIN staff and
the ARIN General Counsel. It contains analysis of procedural, legal, and
resource concerns regarding the implementation of this policy proposal
as it is currently stated. Any changes to the language of the proposal
may necessitate further analysis by staff and Counsel.

I.	Proposal

Policy Proposal is available as Annex A below and at:
http://www.arin.net/policy/proposals/2007_17.html

The proposal was revised, current version dated 21 February 2008.

II.	Understanding of the proposal

ARIN staff understands that this proposal would replace the existing
amnesty policy in NRPM Section 4.6.


III.	Comments

A.	ARIN Staff
1.	There is currently an amnesty policy (NRPM 4.6) and an aggregation
policy (NRPM 4.7).  Both policies contain clear and concise criteria and
have been used successfully by the ARIN community since implementation.
2.	This proposal seems to be combining both of these policies into one
policy.  If that is the case, it needs to explicitly state that.
3.	The proposed policy text implies that ARIN will issue new addresses
to organizations in exchange for returned addresses, but does not
explicitly state that.
4.	The proposed policy text removes the 12 month renumbering timeframe,
creating significant abuse potential.   Since there's no renumbering
timeframe, nothing prevents the requestor from keeping both the smaller
aggregates and the large aggregate indefinitely.
5.	The proposed policy text requires ARIN to accept all amnesty or
aggregation returns without prejudice, creating more avenues for abuse.
  For example, a spammer would be able to use this policy to repeatedly
exchange blacklisted space for clean space.
6.	If anyone is allowed to exchange their space without limitation, this
could affect the remaining supply of IPv4 address space.

B.	ARIN General Counsel

The policy creates no significant legal or litigation concerns.

Comment for author or AC to consider, but not in a binding way: if ARIN
label's some set of resources as in the control of someone 'unreachable'
in whois, do we inadvertently encourage hijacking and spamming during
the waiting period before revocation?

The prior expressed concerns about binding board or inappropriately
getting into fee setting of board have been addressed by changes.


IV. Resource Impact ? Minimal

The resource impact of implementing this policy is viewed as minimum.
Barring any unforeseen resource requirements, this policy could be
implemented within 30 - 90 days from the date of the ratification of the
policy by the ARIN Board of Trustees.  It will require the following:

? Updates to Registration Services Guidelines will be required
? Staff training will be required
? Tracking tools for the return of the space and for the yearly contact
requirement

Respectfully submitted,

Member Services
American Registry for Internet Numbers (ARIN)


##*##


Annex A

Policy Proposal 2007-17
Legacy Outreach and Partial Reclamation

Author: Owen DeLong

Date: 21 February 2008

Proposal type: modify

Policy term: permanent

Policy statement:

Replace section 4.6 as follows:

4.6 Amnesty and Aggregation requests

4.6.1 Intent of this policy

This policy is intended to allow the community and ARIN staff to work
together with holders of address resources in the best interests of the
community by facilitating the return of unused address space and the
aggregation of existing space in a manner which is in the best interests
of both parties.

4.6.2 No penalty for returning or aggregating

ARIN shall seek to make the return of address space as convenient and
risk-free to the returning organization as possible. An organization
with several non-contiguous blocks seeking to aggregate and return space
at the same time should be accommodated if possible. If it is possible
to expand one block, for example, to facilitate the return of other
blocks, ARIN should do that where possible.

4.6.3 Return should not force renumbering

An organization shall be allowed to return a partial block of any size
to ARIN. For any return greater than a /24, ARIN shall not require that
the non-returned portion of the block be renumbered unless the returning
organization wishes to do so.

4.6.4 Incentives

The Board of Trustees should consider creating incentives for
organizations to return addresses under this policy.

4.6.5 RSA Required if new addresses received

Any organization which receives any additional addresses under this
policy shall be required to sign an ARIN RSA which will apply to all new
addresses issued and to any retained blocks which are expanded under
this policy.

4.6.6 Annual contact required

Any organization which participates in this policy shall be required to
sign an agreement stipulating that ARIN will attempt contact at least
once per year via the contact mechanisms registered for the organization
in whois. Should ARIN fail to make contact, after reasonable effort the
organization shall be flagged as "unreachable" in whois. After six
months in "unreachable" status, the organization agrees that ARIN may
consider all resources held by the organization to be abandoned and
reclaim such resources. Should the organization make contact with ARIN
prior to the end of the aforementioned six month period and update their
contact information appropriately, ARIN shall remove the "unreachable"
status and the annual contact cycle shall continue as normal. If the
organization pays annual fees to ARIN, the payment of annual fees shall
be considered sufficient contact.

Rationale:

Existing policy supports aggregation (4.7) and provides some amnesty
(existing 4.6) for returning blocks. However, a number of resource
holders have expressed discomfort with the current section 4.6 believing
that they will be forced to return their entire address space and
renumber rather than being able to make partial returns and retain some
of their existing space.

This policy seeks to eliminate those concerns and make the return of
unused address space more desirable to the resource holders.

A very high percentage of underutilized space is in the hands of legacy
holders who currently have no benefit to joining the ARIN process and no
way to return any portion of their address space without incurring
significant disadvantage as a result.

A suggestion to the board would be to adopt benefits along the following
lines for people returning space. These benefits would provide
additional incentive for resource holders to make appropriate returns
and for legacy holders to join the ARIN process:

1. If the organization does not currently pay ARIN fees, they shall
remain fee exempt.

2. If the organization currently pays ARIN fees, their fees shall be
waived for two years for each /20 returned, with any fractional /20
resulting in a one-time single year waiver.

3. Any organization returning address space under this policy shall
continue under their existing RSA or they may choose to sign the current
RSA. For organizations which currently do not have an RSA, they may sign
the current RSA, or, they may choose to remain without an RSA.

4. All organizations returning space under this policy shall, if they
meet other eligibility requirements and so request, obtain an
appropriate IPv6 end-user assignment or ISP allocation as applicable,
with no fees for the first 5 years. Organizations electing to receive
IPv6 allocation/assignment under this provision must sign a current RSA
and must agree that their IPv4 resources are henceforth subject to the RSA.

Timetable for implementation: Immediate







From info at arin.net  Fri Mar 21 14:48:33 2008
From: info at arin.net (Member Services)
Date: Fri, 21 Mar 2008 14:48:33 -0400
Subject: Policy Proposal 2007-27 - Staff Assessment
Message-ID: <47E40301.9070405@arin.net>

Policy Proposal 2007-27
Title:  Cooperative distribution of the end of the IPv4 free pool
Proposal Submitted: Nov 20, 2007
Date of Assessment: Mar 21, 2008

ARIN Staff Assessment

The assessment of this proposal includes comments from ARIN staff and
the ARIN General Counsel. It contains analysis of procedural, legal, and
resource concerns regarding the implementation of this policy proposal
as it is currently stated. Any changes to the language of the proposal
may necessitate further analysis by staff and Counsel.

I.      Proposal

Policy Proposal is available as Annex A below and at:
http://www.arin.net/policy/proposals/2007_27.html

II.     Understanding of the proposal

Staff understands that this policy will establish a mechanism for the
allocation of IPv4 address blocks between RIR's once the IANA global
pool of addresses has been depleted.

III.    Issues and concerns

A.  ARIN Staff

1.	This policy would have to adopted as an Inter-RIR policy and would
have to remain the same in each region for it to work properly.

2.	There is no way of reliably predicting when an RIR is within 30 days
of depleting their remaining pool of IPv4 addresses since this is
dependent upon the number and size of the resource requests they receive.

3.	This policy would require constant monitoring of the available IPv4
inventory of all the RIRs. To be timely, a software tool would need to
be developed that  monitored all RIR available IPv4 inventory and
produced a daily report.  This same tool would need to be used by all 5
of the RIRs for consistency and accuracy.

4.	When the recipient RIR approaches the source RIR for a 3 month supply
of addresses, will fees be charged to the recipient RIR?

5.	It is likely that AfriNIC and LACNIC will be the two RIRs who
typically would have the largest inventory of IPv4 at any given time
since they currently allocate address space at a slow rate and in lessor
amounts than the other three RIRs.  If the three larger RIRs
consistently approach them for address space, it is likely that their
remaining supply will quickly dwindle.

6.	If one RIR will be required to review requests from another region,
all such requests must be made in an agreed upon common language.

7.	Process and procedures training may be required for those parties
making requests to an RIR in a region other than their own.

8.	If the source RIR reviews and approves requests from the recipient
RIR?s customers, there are likely to be business, legal, and other
administrative issues that arise.  For example:
   - Which RIR would the requestor pay?
   - In what currency would the fee paid?
   - Which RIR would have to report the registration fee as income?
   - Which RIR would the requestor sign a contract with?
   - Which RIR would maintain the record?
   - Will the requestor become a member of the source RIR and if so,
will they be required to pay an annual fee to the source RIR?


B.	 ARIN General Counsel

Counsel sees no significant legal or litigation issues related to this
policy.

IV. Resource Impact ? Major

The resource impact of implementing this policy is viewed as major.
Barring any unforeseen resource requirements, this policy could be
implemented within 180 days from the date of the ratification of the
policy by the ARIN Board of Trustees.  It would also be dependent upon
the policy being adopted in all other RIRs.

? Tracking tool with built in metrics needed to attempt to estimate the
30 day depletion mark
? Survey needs to be created to ask other RIR to estimate their
remaining available space
? Inter RIR coordination process needs to be established for this
process of surveying and follow up actions.
? New guidelines
? Staff training

Respectfully submitted,

Member Services
American Registry for Internet Numbers (ARIN)


##*##


Annex A

Policy Proposal 2007-27
Cooperative distribution of the end of the IPv4 free pool

Author: Tony Hain

Date: 20 November 2007

Proposal type: new

Policy term: permanent

Policy summary:
This policy will establish a process for RIR-to-RIR redistribution of
the tail-end of the IPv4 pool, taking effect after the IANA Reserve is
exhausted. Each redistribution Allocation will be triggered by the
recipient RIR depleting its reserve to a 30 day supply, and will result
in up to a 3 month supply being transferred from the RIR with the
longest remaining time before it exhausts its own pool.

Policy statement:
At the point when any given RIR is within 30 days of depleting its
remaining IPv4 pool, a survey will be taken of the other 4 to determine
the remaining time before each of them exhausts their pool (including
both member use and recent redistribution allocations to other RIRs).
The one with the longest window before exhausting its pool will be
designated as the source RIR. The recipient RIR will follow procedures
for an LIR in the source RIR region to request a block that is expected
to be sufficient for up to 3 months, but is no larger than 1/8th of the
source RIR's remaining pool. At the point where no RIR can supply a
block that is less than 1/8th of their remaining pool that will sustain
the recipient RIR for 30 days, the recipient RIR will collect its
requests each week, and forward those individual requests to the source
RIR designated that week.

Rationale:

This policy will establish a mechanism for the Allocation of IPv4
address blocks between RIR's, but will not go into effect until the IANA
pool has been depleted.

It is really bizarre to watch the maneuvering as the global RIR
community grapples with 'fairness' of distributing the last few IANA
Reserve /8 blocks. On one level this just appears to be petty sibling
rivalry, as people are bickering over who gets the last cookie and
whimpering about 'fairness'. At the same time, each RIR is chartered to
look after the interests of its membership so it is to be expected that
they will each want to get as much as possible to meet the needs of
their respective membership.

Existing practice requires RIR's to acquire blocks from IANA, which
leads to the current round of nonsense about optimal distribution of the
remaining pool based on elaborate mathematical models.

This globally submitted policy proposal attempts to resolve the issue by
shifting to an RIR-to-RIR Allocation model after the IANA pool is depleted.

This policy would effectively result in each RIR becoming a virtual LIR
member of all of the other RIR's for the sole purpose of managing the
tail-end of the IPv4 pool.

Timetable for implementation: Before 1/1/2009



From info at arin.net  Mon Mar 24 11:13:57 2008
From: info at arin.net (Member Services)
Date: Mon, 24 Mar 2008 11:13:57 -0400
Subject: [ppml] Revised 2007-14
In-Reply-To: <434C0D36-B948-4226-A5F4-37EFEE29B504@delong.com>
References: <434C0D36-B948-4226-A5F4-37EFEE29B504@delong.com>
Message-ID: <47E7C535.8070305@arin.net>

Policy Proposal 2007-14: Resource Review Process has been revised. This
proposal is open for discussion on this mailing list and will be on the
agenda at the upcoming ARIN Public Policy Meeting.

The current policy proposal text is provided below and is also available
at: http://www.arin.net/policy/proposals/2007_14.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)



Owen DeLong wrote:
> The following revisions to 2007-14 are being submitted in order
> to address some concerns expressed to the authors by ARIN
> counsel.  The authors do not believe that these changes alter
> the meaning or intent of the proposal.
> 
> This is the version that will be presented at the Denver meeting.
> 
> Version: 2.1
> Policy statement:
> 
> Add the following to the NRPM:
> 
> Resource Review
> 
> 1. ARIN may review the current usage of any resources issued by ARIN
> to an organization. The organization shall furnish whatever records
> are believed to be necessary by ARIN to perform this review.
> 
> 2. ARIN may conduct such reviews:
> 
> a. when any new resource is requested,
> b. whenever ARIN has reason to believe that the resources
> were originally obtained fraudulently, or
> c. at any other time without having to establish cause unless a
> prior review has been completed in the preceding 24 months.
> 
> 3. ARIN shall communicate the results of the review to the organization.
> 
> 4. Organizations found by ARIN to be substantially out of compliance
> with
> current ARIN policy shall be requested or required to return resources
> as
> needed to bring them into (or reasonably close to) compliance.
> 
> 4a. The extent to which an organization may remain out of compliance
> shall be based on the reasonable judgment of the ARIN staff and shall
> balance all facts known, including the organizations utilization rate,
> available address pool,  and other factors as appropriate so as to avoid
> forcing returns which  will result in near-term additional requests or
> unnecessary route de-aggregation.
> 
> 4b. To the extent possible, entire blocks should be returned. Partial
> address blocks shall be returned in such a way that the portion
> retained will comprise a single aggregate block.
> 
> 5. If the organization does not voluntarily return resources as
> requested, ARIN may revoke any resources issued by ARIN as required to
> bring the organization into overall compliance. ARIN shall follow the
> same guidelines for revocation that are required for voluntary return
> in the previous paragraph.
> 
> 6. Except in cases of fraud, or intentional violations of policy, an
> organization shall be given a minimum  of six months to effect a
> return. ARIN shall negotiate a longer term with the organization
> if ARIN believes the organization is working in good faith to
> substantially
> restore compliance and has a valid need for additional time to
> renumber out of the affected blocks.
> 
> 7. ARIN shall continue to maintain the resource(s) while their return
> or revocation is pending, except no any maintenance fees assessed
> during that period shall be calculated as if the return or revocation
> was complete.
> 
> 8. Legacy resources in active use, regardless of utilization, are not
> subject to revocation by ARIN. pursuant to this subsection. However,
> the utilization of legacy resources shall be considered during a
> review to assess overall compliance.
> 
> 9. In considering compliance with policies which allow a timeframe
> (such as a requirement to assign some number of prefixes within 5
> years) failure to comply cannot be measured until after the timeframe
> specified in the applicable policy has elapsed. Blocks subject to such
> a policy shall be assumed in compliance with that policy until such
> time as the specified time since issuance has elapsed.
> 
> 
> 
> Delete NRPM sections 4.1.2, 4.1.3, 4.1.4
> 
> Remove the sentence "In extreme cases, existing allocations may be
> affected." from NRPM section 4.2.3.1.
> 
> Rationale:
> 
> The authors have been told that current policy does not clearly give
> ARIN the power to review or reclaim resources except in cases of
> fraud, despite this being mentioned in the Registration Services
> Agreement. This policy proposal provides clear policy authority to
> do so, guidelines for how and under what conditions it shall be
> done, and a guarantee of a (minimum) six- month grace period
> so that the current user shall have time to renumber out of any
> resources to be reclaimed.
> 
> The nature of the "review" is to be of the same form as is currently
> done when an organization requests new resources, i.e. the
> documentation required and standards should be the same.
> 
> The intent of paragraph 2c is to prevent ARIN from doing more than one
> without-cause review in a 24 month period.
> 
> The renumbering period does not affect any "hold" period that ARIN may
> apply after return or revocation of resources is complete.
> 
> The deleted sections/text would be redundant with the adoption of this
> proposal.
> 
> Timetable for implementation: Immediate
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml
> Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues.
> 



From info at arin.net  Mon Mar 24 16:54:58 2008
From: info at arin.net (Member Services)
Date: Mon, 24 Mar 2008 16:54:58 -0400
Subject: ARIN XXI - Open Policy Hour
Message-ID: <47E81522.3080107@arin.net>

Questions about the Policy Process:
1. Do you want to know what policy proposals will be discussed at the
upcoming ARIN Public Policy Meeting?
2. Do you have an idea about how ARIN should manage Internet Number
Resources?
3. Do you think that a current policy should be enhanced or changed, or
even retired?
4. Are you hesitant about making a formal proposal on the Public Policy
Mail List (PPML)?
5. Are you new to the Policy Development Process?

If you answered ?yes? to any of these questions, then you should attend
the Open Policy Hour!

Come and get a better understanding of what will be discussed during the
upcoming Public Policy Meeting, or discuss and receive feedback on your
ideas in an open, informal forum. The Open Policy Hour consists of two
parts.

Part One is the Policy Proposal Background Briefing. ARIN staff will
provide an overview of the policy proposals on the meeting agenda.
Members of the ARIN Advisory Council will be present to answer general
questions about these proposals. The proposal content will not be
discussed. This session offers general information on the nature of the
proposals.

Part Two is the Policy Proposal BoF. This is where you can "test drive"
a policy idea. How can you participate? Bring your ideas and questions.
If you have a policy suggestion, but would like to receive feedback
prior to submitting it to the community on the PPML, here is your
opportunity. Preference will be given to individuals with prepared short
(3-minute) presentations. To sign up in advance please send an e-mail to
policy at arin.net by 2 April 2008 with your name, organization, and a
brief description of your policy subject. Walk-up presenters are also
welcome.

Join your colleagues for this informal session. The Open Policy Hour for
ARIN XXI will be held on Sunday, 6 April, from 4:30 - 5:30 PM. If you
are not familiar with the way policies are developed in the ARIN region,
join ARIN staff a half hour earlier, at 4:00 PM, for a review of the
Internet Resource Policy Evaluation Process.

Registration and hotel information for ARIN XXI is available at:
http://www.arin.net/ARIN-XXI/

Contact Member Services at info at arin.net if you have any questions.

Regards,

Member Services
American Registry for Internet Numbers (ARIN)



From info at arin.net  Tue Mar 25 10:11:03 2008
From: info at arin.net (Member Services)
Date: Tue, 25 Mar 2008 10:11:03 -0400
Subject: ARIN XXI: Check Out The Agenda!
Message-ID: <47E907F7.4000903@arin.net>

We look forward to your participation at the ARIN XXI Public Policy and 
Members Meeting, taking place 6-9 April 2008, in Denver, Colorado.

The meeting will take place at the Grand Hyatt Denver. Hotel and travel 
information, meeting registration, and agenda details, are available 
through http://www.arin.net/ARIN-XXI/.

In addition to ARIN policy proposal and member discussions, the meeting 
will also feature the following:

Sunday, 6 April
? First Timer Luncheon
? The IPv6 Pre-Game Show (no registration required)
? A session entitled ?Understanding ARIN?s Legacy Registration Services 
Agreement? presented by ARIN General Counsel Steven Ryan.
? Introduction to the Internet Resource Policy Evaluation Process and 
Open Policy Hour
? The 9th Annual Foosball Tournament
Monday, 7 April
? The ARIN XXI Social Event. More information is available at: 
http://www.arin.net/ARIN-XXI/social.html
Tuesday, 8 April
? The IPv6 Main Event (no registration required)

Select the events you plan to attend on your registration form. If you 
have already registered, but would like to modify your selections, click 
on the "Update Existing Registration" link available through 
http://www.arin.net/ARIN-XXI/.

You can always contact ARIN Member Services at info at arin.net with any 
questions. We look forward to seeing you in Denver!

Regards,

Member Services
American Registry for Internet Numbers (ARIN)




From info at arin.net  Thu Mar 27 09:55:22 2008
From: info at arin.net (Member Services)
Date: Thu, 27 Mar 2008 09:55:22 -0400
Subject: NRPM version 2008.2 - New Policy Implementation
Message-ID: <47EBA74A.1020505@arin.net>

On 10 March 2008, the ARIN Board of Trustees, acting on the
recommendation of the Advisory Council and noting that the Internet
Resource Policy Evaluation Process had been followed, adopted the
following policy proposal:

Policy Proposal 2007-22: Expand timeframe of Additional Requests

This policy proposal has been incorporated into version 2008.2 of the
ARIN Number Resource Policy Manual (NRPM).

The Board also voted to remove the Mailing Lists section from the NRPM
(Section 9). This section described the acceptable use policies of ARIN
mail lists. The section was an artifact of the creation of the NRPM and
was not number resource policy.

NRPM version 2008.2 is effective 27 March 2008 and supersedes previous
versions. See Appendix A of the NRPM for information regarding changes
to the manual.

The NRPM can be found at:
http://www.arin.net/policy/nrpm.html

Appendix A can be found at:
http://www.arin.net/policy/nrpm_changelog.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)



From info at arin.net  Thu Mar 27 10:31:26 2008
From: info at arin.net (Member Services)
Date: Thu, 27 Mar 2008 10:31:26 -0400
Subject: New ARIN Mailing List Acceptable Use Policy
Message-ID: <47EBAFBE.3000803@arin.net>

This message is being sent to all ARIN mailing lists.  If you are 
subscribed to more than one ARIN managed mailing list, you will receive 
multiple copies of this announcement.

At its 10 March meeting, the ARIN Board of Trustees adopted a new 
Mailing List Acceptable Use Policy (AUP) for all ARIN public mailing 
lists. The AUP sets forth general guidelines of acceptable list conduct 
and calls out a number of specifically prohibited activities. A section 
on reporting violations and enforcement is included, along with 
procedures on how both are to be accomplished.
 
The full text is available on the ARIN website as a link off the main 
mailing list page at: http://www.arin.net/mailing_lists/aup.html
 
Regards,
 
Member Services
American Registry for Internet Numbers (ARIN)




From info at arin.net  Thu Mar 27 14:45:07 2008
From: info at arin.net (Member Services)
Date: Thu, 27 Mar 2008 14:45:07 -0400
Subject: Policy Proposal 2008-3 - Staff Assessment
Message-ID: <47EBEB33.2060601@arin.net>

Policy Proposal 2008-3
Title: Community Networks IPv6 Allocation
Proposal Submitted: March 4, 2008
Date of Assessment: March 27, 2008


ARIN Staff Assessment

The assessment of this proposal includes comments from ARIN staff and
the ARIN General Counsel. It contains analysis of procedural, legal, and
resource concerns regarding the implementation of this policy proposal
as it is currently stated. Any changes to the language of the proposal
may necessitate further analysis by staff and Counsel.

I.      Proposal

Policy Proposal is available as Annex A below and at:
http://www.arin.net/policy/proposals/2008_3.html	

II.     Understanding of the proposal

ARIN staff understands this policy would provide IPv6 addresses to any
organization considered to be a community network.

III. Issues and concerns

A. ARIN Staff Comments

This proposal defines a ?community network? which is a new term in the
ARIN region.  The community should take a close look at this definition
to explore whether its rather broad definition might make it subject to
abuse or exploitation by people who may not otherwise qualify for IPv6
address space.

This proposal does not state a minimum number of actual or planned
customers for the community network.  Staff recommends that a minimum
number of customers be specified to help determine qualification.

There is no minimum allocation size specified in this policy.  Staff
recommends that a minimum allocation size be specified.

In addition, staff recommends that criteria for requests larger than the
minimum allocation size and for requests for additional allocations be
specified.

Staff believes that a community network does not fit either LIR or
end-user descriptions exactly and therefore recommends that this policy
be inserted into NRPM as section 6.5.9

B. ARIN General Counsel

Counsel sees no significant legal or litigation risk regarding this policy.

IV. Resource Impact - Moderate

The resource impact of implementing this policy is moderate.  Barring
any unforeseen resource requirements, this policy could be implemented
within 90 days from the date of the ratification of the policy by the
ARIN Board of Trustees.  It will require the following:

- New template
- Registration software changes
- New set of guidelines
- Staff training

Respectfully submitted,

Member Services
American Registry for Internet Numbers (ARIN)


##*##


Annex A

Policy Proposal 2008-3
Community Networks IPv6 Allocation

Author: Joshua King

Proposal Version: 1

Date: 4 March 2008

Proposal type: new

Policy term: permanent

Policy statement:

[Add Section 2.8 to the NRPM.]

2.8 Community Network

A community network is a generic reference to any network that is
operated by a group of people living in a particular local area
organized for the purposes of delivery or provision of network services
to the residents of an incorporated or unincorporated regional
municipality, city, town, village, rural municipality, township, county,
district or other municipality or other such geographic space, however
designated.

[Modify 6.5.8.1b as follows.]

b. qualify for an IPv4 assignment or allocation from ARIN under the IPv4
policy currently in effect or be a Community Network as defined in
Section 2.8.

Rationale:

There are currently a number of projects globally that aim to develop
community network infrastructure and related technologies. These are
usually coordinated by volunteer-run, grassroots organizations which
lack many of the resources of traditional internet service providers and
other network operators. They have diverse goals, including public
policy, software development, and implementation of community services
and resources. Many of them provide services free of charge, and thus
lack any paying user base. However, in order to create and maintain
community networks that are often composed of hundreds if not thousands
of inexpensive, commodity hosts and devices, a significant amount of
address space will be required. Current-generation workarounds to this
problem, such as NAT, not only make it difficult to develop
next-generation decentralized network technology by segmenting the
community's architecture from the Internet as a whole, but will cease to
be as viable a stopgap as the Internet moves towards IPv6 integration.

Even now, common community networking software solutions such as
CUWiNware (http://www.cuwin.net) and Freifunk (http://www.freifunk.at)
have nascent IPv6 addressing support, but participating organizations
lack the address space for widespread testing or adoption. As such, it
is necessary to implement an procedure as soon as possible for these
segregated networks to acquire address space. These organizations do not
meet the criteria traditionally defined for LIR's, and thus cannot
acquire address allocations through existing templates. By establishing
a procedure by which these organizations can seek to acquire the
resources they require for further development, ARIN can reach out to
this active community and establish a small but definite space for them
in the future of Internet.

Timetable for implementation: Immediate.




From info at arin.net  Fri Mar 28 11:16:50 2008
From: info at arin.net (Member Services)
Date: Fri, 28 Mar 2008 11:16:50 -0400
Subject: [ppml] Revision to 2007-17
In-Reply-To: <0A63064A-3AEA-4A0D-BD77-ED16D08E0E75@delong.com>
References: <0A63064A-3AEA-4A0D-BD77-ED16D08E0E75@delong.com>
Message-ID: <47ED0BE2.7070204@arin.net>

Policy Proposal 2007-17, Legacy Outreach and Partial Reclamation, has
been revised. This proposal is open for discussion on this mailing list
and will be on the agenda at the upcoming ARIN Public Policy Meeting.

The current policy proposal text is provided below and is also available
at: http://www.arin.net/policy/proposals/2007_17.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


Owen DeLong wrote:
> 
> The following revised version of 2007-17 is submitted for consideration.
> The amendments are being made to address concerns expressed by staff
> in the "staff assessment" of the policy proposal.
> 
> I ran these changes by staff prior to submitting them here.  The changes
> do address the concerns expressed by staff, but, staff may wish to revise
> their "impact" statement.  Beyond this statement, I'll leave it to staff
> to comment further if they wish.
> 
> Apologies for the late date on this amendment. Look forward to upcoming
> changes to the IRPEP to improve this situation.
> 
> Owen
> 
> 
> Modifications:
> 
>        Extended 4.6.1 to allow ARIN to reject transactions of no benefit
>        to the community. (Hopefully this closes most of the abuse loopholes)
> 
>        Renumbered 4.6.6 to 4.6.7 Annual contact required
> 
>        Renumbered 4.6.5 to 4.6.6 RSA Required if new addresses received
> 
>        Inserted new 4.6.5 to spell out requirement for ARIN to work with
>        resource holders to specify a return timeframe in contract.
> 
>        Added text to rationale to clarify overriding intent and
> 
> Policy Proposal 2007-17
> Legacy Outreach and Partial Reclamation
> 
> Author: Owen DeLong
> 
> Date: 21 February 2008
> 
> Proposal type: modify
> 
> Policy term: permanent
> 
> Policy statement:
> 
> Replace section 4.6 as follows:
> 
> 4.6 Amnesty and Aggregation requests
> 
> 4.6.1 Intent of this policy
> 
> This policy is intended to allow the community and ARIN staff to work
> together with holders of address resources in the best interests of
> the community by facilitating the return of unused address space and
> the aggregation of existing space in a manner which is in the best
> interests of both parties.
> 
> All transactions under this policy must either create greater
> aggregation (a reduction in the number of prefixes) or the return of
> address space. ARIN should reject any transaction which staff judges
> is not in the interests of the community.
> 
> 4.6.2 No penalty for returning or aggregating
> 
> ARIN shall seek to make the return of address space as convenient and
> risk-free to the returning organization as possible. An organization
> with several non-contiguous blocks seeking to aggregate and return
> space at the same time should be accommodated if possible. If it is
> possible to expand one block, for example, to facilitate the return of
> other blocks, ARIN should do th.6.3 Return should not force renumbering
> 
> An organization shall be allowed to return a partial block of any size
> to ARIN. For any return greater than a /24, ARIN shall not require
> that the non-returned portion of the block be renumbered unless the
> returning organization wishes to do so.
> 
> 4.6.4 Incentives
> 
> The Board of Trustees should consider creating incentives for
> organizations to return addresses under this policy.
> 
> 4.6.5 Timeframe for return
> 
> Any organization which is returning addresses under this policy shall
> negotiate with ARIN an appropriate timeframe in which to return the
> addresses after any new resources are received under this policy. In
> the case of a simple return, the timeframe shall be immediate.  In the
> case where renumbering into new addresses out of existing addresses to
> be returned is required, the returning organization shall sign a
> contract with ARIN which stipulates a final return date not less than
> 6 months nor more than 18 months after the receipt of new addresses.
> If an organization misses this return date, but, ARIN believes the
> organization is working in good faith to complete the renumbering,
> ARIN may grant a single extension of 6-12 months as staff deems
> appropriate to the situation. Such an extension must be requested in
> writing (email to hostmaster at arin.net <mailto:hostmaster at arin.net>) by 
> the organization at least 15
> days prior to the original expiration date.
> 
> 4.6.6 RSA Required if new addresses received
> 
> Any organization which receives any additional addresses under this
> policy shall be required to sign an ARIN RSA which will apply to all
> new addresses issued and to any retained blocks which are expanded
> under this policy.
> 
> 4.6.7 Annual contact required
> 
> Any organization which participates in this policy shall be required
> to sign an agreement stipulating that ARIN will attempt contact at
> least once per year via the contact mechanisms registered for the
> organization in whois. Should ARIN fail to make contact, after
> reasonable effort the organization shall be flagged as "unreachable"
> in whois. After six months in "unreachable" status, the organization
> agrees that ARIN may consider all resources held by the organization
> to be abandoned and reclaim such resources. Should the organization
> make contact with ARIN prior to the end of the aforementioned six
> month period and update their contact information appropriately, ARIN
> shall remove the "unreachable" status and the annual contact cycle
> shall continue as normal. If the organization pays annual fees to
> ARIN, the payment of annual fees shall be considered sufficient contact.
> 
> Rationale:
> 
> Existing policy supports aggregation (4.7) and provides some amnesty
> (existing 4.6) for returning blocks. However, a number of resource
> holders have expressed discomfort with the current section 4.6
> believing that they will be forced to return their entire address
> space and renumber rather than being able to make partial returns and
> retain some of their existing space.
> 
> This policy seeks to eliminate those concerns and make the return of
> unused address space more desirable to the resource holders.
> 
> A very high percentage of underutilized space is in the hands of
> legacy holders who currently have no benefit to joining the ARIN
> process and no way to return any portion of their address space
> without incurring significant disadvantage as a result.
> 
> A suggestion to the board would be to adopt benefits along the
> following lines for people returning space. These benefits would
> provide additional incentive for resource holders to make appropriate
> returns and for legacy holders to join the ARIN process:
> 
> 1. If the organization does not currently pay ARIN fees, they shall
> remain fee exempt.
> 
> 2. If the organization currently pays ARIN fees, their fees shall be
> waived for two years for each /20 returned, with any fractional /20
> resulting in a one-time single year waiver.
> 
> 3. Any organization returning address space under this policy shall
> continue under their existing RSA or they may choose to sign the
> current RSA. For organizations which currently do not have an RSA,
> they may sign the current RSA, or, they may choose to remain without
> an RSA.
> 
> 4. All organizations returning space under this policy shall, if they
> meet other eligibility requirements and so request, obtain an
> appropriate IPv6 end-user assignment or ISP allocation as applicable,
> with no fees for the first 5 years. Organizations electing to receive
> IPv6 allocation/assignment under this provision must sign a current
> RSA and must agree that their IPv4 resources are henceforth subject to
> the RSA.
> 
> The overriding intent of this policy proposal is to make it as easy as
> possible for both ARIN and resource holders to "do the right thing"
> with regard to excess resources or dis-aggregated (fragmented) address
> blocks.  It is the desire of the author that staff make any judgment
> calls necessary  under this policy with that ideal clearly in mind.
> While the author has made a concerted effort to make the policy as
> clear as possible and
> as concrete as can be, the reality is that these types of transactions
> must rely heavily on the judgment and expertise of the ARIN staff in
> determining what is in the best interests of the community.
> 
> 
> Timetable for implementation: Immediate
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml
> Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues.




From info at arin.net  Mon Mar 31 09:28:23 2008
From: info at arin.net (Member Services)
Date: Mon, 31 Mar 2008 09:28:23 -0400
Subject: Reminder: ARIN XXI Open Policy Hour and Remote Participation
Message-ID: <47F0E6F7.1060108@arin.net>

Sign up today to present your ideas at the ARIN XXI Open Policy Hour, 
Sunday, 6 April, from 4:30-5:30 PM (MDT).

The Open Policy Hour (OPH) is a showcase for your policy ideas. If you 
have a policy proposal you?d like to debut, prior to formally submitting 
it, here is your opportunity. Sign up by Wednesday, 2 April to ensure 
your chance to take the microphone. Send an e-mail to policy at arin.net 
with your name, organization, and a general description of the policy 
subject you wish to present. Everyone is invited to attend the session 
and raise ideas and suggestions. You do not need to have a formal 
presentation in order to participate. Signing up in advance allows us to 
confirm your turn to present your policy idea.

Information on this and other sessions is available at:
http://www.arin.net/ARIN-XXI/agenda.html

For the first time ever, the OPH will be available as part of our live 
meeting webcast and remote participants may submit comments and questions.

To register for remote participation, click the ?Meeting Registration? 
button available at http://www.arin.net/ARIN-XXI/ and choose "ARIN XXI 
Remote Participant" from the drop-down. Registration is not required to 
view the webcast.

Comments received from remote participants will be moderated and 
presented during normal question and answer periods. ARIN will use 
e-mail to provide the interactive portion of the remote participation 
effort. All remote participants are subject to the Remote Participation 
Acceptable Use Policy (AUP).

Additional information about remote participation, including the Remote 
Participation AUP, is available at:

http://www.arin.net/ARIN-XXI/webcast.html

We look forward to your participation in ARIN XXI. Meeting details are 
available at http://www.arin.net/ARIN-XXI/.

Please contact Member Services at info at arin.net if you have any questions.

Regards,

Member Services Department
American Registry for Internet Numbers (ARIN)






From info at arin.net  Mon Mar 31 11:59:01 2008
From: info at arin.net (Member Services)
Date: Mon, 31 Mar 2008 11:59:01 -0400
Subject: Poll - Transfer Policy
Message-ID: <47F10A45.70001@arin.net>

The ARIN Advisory Council is conducting a poll. The poll contains five
questions. You will receive five e-mails, one question per message.

Every e-mail address subscribed to the Public Policy Mailing List (PPML)
will be e-mailed individually with instructions on how to participate in
the poll. If an alias is subscribed to the PPML that is then distributed
to several individuals, only the first opinion registered will be
counted. Only those who are already subscribed when the poll starts may
participate.

The poll ends at noon EDT on Thursday, 3 April 2008. The results will be
sent to PPML.

Regards,

Member Services
American Registry for Internet Numbers (ARIN)