From kkargel at polartel.com  Mon Mar  2 11:30:43 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 2 Mar 2009 10:30:43 -0600
Subject: [arin-ppml] (curiosity) a policy which addresses which
	POCcontacts ARIN should spam?
In-Reply-To: <6eb799ab0902271741o731dd6f6lf71ff1fc2c930967@mail.gmail.com>
References: <62FDBBDA-55E0-4644-BFCD-E75DF9EB04FB@svcolo.com>
	<6eb799ab0902271741o731dd6f6lf71ff1fc2c930967@mail.gmail.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AE7C@mail>

I agree that notices from ARIN "may be" necessary and useful.  In our case
the addresses subscribed to ARIN-announce are real people.  The few emails
we get to that address are minor and do not construe any undue hardship.
IMHO the trivial nuisance is far outweighed by the occasional actually
important message.

If my memory serves me right when I signed up for the list it was strongly
suggested that the subscriber be a real person with no auto-replies.  

Personally I do not think that directing informational mailing lists to a
trouble ticket system falls within 'best practice', but that is me.

Kevin


________________________________________
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of James Hess
Sent: Friday, February 27, 2009 7:41 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] (curiosity) a policy which addresses which
POCcontacts ARIN should spam?

My suggestion would be actually, that if you automatically create tickets
upon receipt of a message,
adjust your systems so as to exclude "do-not-reply at arin.net",? to properly
direct them to a human like ARIN expects instead of creating some sort of
useless ticket in a database.

The annoyance of 'closing a ticket' is one manufactured by using unexpected
robots.
I believe POCs are meant to be the human beings responsible who can be
immediately reached, not necessarily automated systems,? for just filing a
ticket away for a while.


And I don't find it surprising in the least, that once in a blue moon, there
is an important issue that ARIN needs to notify every single contact of --?
even such that they don't get to opt out really; if they are a registrant,
they have a responsibility to receive certain communications....

However, I? dothink the notice may have been wasteful and unnecessary in
this case.?? The warning in January about the change to 4-byte AS numbers
was far more important.

The creation of a special announce list for POCs, for more general notices?
may be a suitable solution, but once every few years on average, I would
still expect there could be an emergency notice to all POCs, depending on
the severity of the issue they all need to be aprised of immediately.



For all I know, they had thousands of registrants complaining to ARIN about
the incorrect geography search engines were giving,? asking to get a block
from a different /8? instead, or something.

In that case, sending a notice to the small number of contacts who had
manually subscribed to a mailing list would be a highly-ineffective way of
getting the notice out to the sites having issues.

--
-J
On Thu, Feb 26, 2009 at 7:37 PM, Jo Rhett <jrhett at svcolo.com> wrote:
After having ARIN spam not only the Admin contacts and the POC contact
of record for our business, we watched the same ARIN message hit each
and every one of our different ticket/helpdesk systems -- including
Abuse!

I sincerely doubt that this is helpful or useful. ?Would it be
difficult to define exactly which POC contacts should receive non-
specific ARIN communications?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090302/f4fbf7be/attachment.bin>

From jrhett at svcolo.com  Mon Mar  2 18:07:09 2009
From: jrhett at svcolo.com (Jo Rhett)
Date: Mon, 2 Mar 2009 15:07:09 -0800
Subject: [arin-ppml] (curiosity) a policy which addresses which POC
	contacts ARIN should spam?
In-Reply-To: <6eb799ab0902271741o731dd6f6lf71ff1fc2c930967@mail.gmail.com>
References: <62FDBBDA-55E0-4644-BFCD-E75DF9EB04FB@svcolo.com>
	<6eb799ab0902271741o731dd6f6lf71ff1fc2c930967@mail.gmail.com>
Message-ID: <CD77413D-24BB-43E2-B29F-FDB8532EAACE@svcolo.com>

On Feb 27, 2009, at 5:41 PM, James Hess wrote:
> My suggestion would be actually, that if you automatically create  
> tickets
> upon receipt of a message,
> adjust your systems so as to exclude "do-not-reply at arin.net",  to  
> properly
> direct them to a human like ARIN expects instead of creating some  
> sort of
> useless ticket in a database.

No.  There are different POC contacts defined in the Policy manual for  
a reason.  They are not identical and equivalent.  There is one which  
specifically should be used, and it was not.  There are several which  
are clearly inappropriate, and they were used.

Upon re-reading and further discussion offline I (now) believe that  
the current policy correctly addresses this matter, and no policy  
change is required. It was an operational mistake on ARIN's part.   
Obviously this matter may return here later.

-- 
Jo Rhett
senior geek

Silicon Valley Colocation
Support Phone: 408-400-0550






From jrhett at svcolo.com  Mon Mar  2 18:10:41 2009
From: jrhett at svcolo.com (Jo Rhett)
Date: Mon, 2 Mar 2009 15:10:41 -0800
Subject: [arin-ppml] (curiosity) a policy which addresses which
	POCcontacts ARIN should spam?
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AE7C@mail>
References: <62FDBBDA-55E0-4644-BFCD-E75DF9EB04FB@svcolo.com>
	<6eb799ab0902271741o731dd6f6lf71ff1fc2c930967@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4AE7C@mail>
Message-ID: <619D51EF-E6DA-40AB-9993-F6A321EA52A7@svcolo.com>

On Mar 2, 2009, at 8:30 AM, Kevin Kargel wrote:
> I agree that notices from ARIN "may be" necessary and useful.  In  
> our case
> the addresses subscribed to ARIN-announce are real people.  The few  
> emails
> we get to that address are minor and do not construe any undue  
> hardship.
> IMHO the trivial nuisance is far outweighed by the occasional actually
> important message.
>
> If my memory serves me right when I signed up for the list it was  
> strongly
> suggested that the subscriber be a real person with no auto-replies.
>
> Personally I do not think that directing informational mailing lists  
> to a
> trouble ticket system falls within 'best practice', but that is me.

Kevin, I find myself in full agreement with you except that this isn't  
the matter under discussion.

ARIN sent mail not to a subscribed direct mailing list, but to every  
POC contact in the database.  In particular, the (A)buse contact goes  
to an abuse helpdesk which tracks down and deals with abuse reports.   
It is not an appropriate destination for ARIN information notices.

Direct mailing lists like this one are appropriate.  Mailing to the  
POC contacts assigned for ARIN communication, and for which role  
accounts are not appropriate, as likewise appropriate.  Neither of  
these were used.

-- 
Jo Rhett
senior geek

Silicon Valley Colocation
Support Phone: 408-400-0550






From info at arin.net  Thu Mar  5 16:01:15 2009
From: info at arin.net (Member Services)
Date: Thu, 05 Mar 2009 16:01:15 -0500
Subject: [arin-ppml] Policy Proposal: Protective Usage Transfer Policy for
 IPv4 Address - Revised
Message-ID: <49B03D9B.9070103@arin.net>

Policy Proposal
Protective Usage Transfer Policy for IPv4 Address

The proposal originator submitted a revised version of the proposal.

The AC will review this proposal at their next regularly scheduled
meeting and decide how to utilize the proposal. Their decision will be
announced to the PPML.

In the meantime, the AC invites everyone to comment on this proposal on
the PPML, particularly their support or non-support and the reasoning
behind their opinion. Such participation contributes to a thorough
vetting and provides important guidance to the AC in their deliberations.

The ARIN Policy Development Process can be found at:
http://www.arin.net/policy/pdp.html

Mailing list subscription information can be found at:
http://www.arin.net/mailing_lists/

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


#####


Policy Proposal Name: Protective Usage Transfer Policy for IPv4 Address

Proposal Originator : Christopher A. Quesada

Proposal Version: 2

Date: 5 March 2009

Policy statement:

Critical infrastructure providers may appeal to ARIN for final review
and approval of any full or partial transfer of IPv4 address space that
has been in use by the critical infrastructure serving the community for
five consecutive years or more.  Such appeal may result in a partial or
full approval of the requested transfer, or rejection of the transfer if
it lacks appropriate rationale, justification, or interferes with the
seamless operation of such critical infrastructure or hardship to the
provider.

Rationale:
Protection of critical infrastructure providers of the Internet,
including public exchange points, core DNS service providers (e.g.
ICANN-sanctioned root, gTLD, and ccTLD operators) as well as the RIRs
and IANA is necessary in order to ensure the continuous operation of the
Internet for its global service community.  It is possible for an
organization to transfer an aggregate IPv4 address resource containing
allocations/assignments downstream supporting critical infrastructure
(as defined in ARIN?s Number Resource Policy Manual).  This policy is
intended to protect that critical infrastructure by allowing for the
review and final approval of such transfer by ARIN, upon appeal by the
critical infrastructure provider to ARIN, within a sixty day period of
the transfer notification if such transfer would interfere with the
continuous and seamless operation of that critical infrastructure or
hardship to the provider.  Review of the transfer can consist of a
request by ARIN to the transferring organization for a rationale for
such transfer.  This may include but not be limited to, a requirement
for the receiving party to submit the appropriate network request form
identifying the need and justification for the aggregate IPv4 address
resource.









From info at arin.net  Mon Mar  9 11:18:01 2009
From: info at arin.net (Member Services)
Date: Mon, 09 Mar 2009 11:18:01 -0400
Subject: [arin-ppml] Policy Proposal (Global): Allocation of IPv4 Blocks to
 Regional Internet Registries - Revised
Message-ID: <49B53329.5010603@arin.net>

Policy Proposal (Global)
Allocation of IPv4 Blocks to Regional Internet Registries

The proposal originator submitted a revised version of the proposal. See
the rationale for an explanation of changes in this version. The
proposal will be forwarded to the ARIN Advisory Council for their
consideration. The proposal is on the AC's docket for development and
evaluation.

The ARIN Policy Development Process can be found at:
http://www.arin.net/policy/pdp.html

Mailing list subscription information can be found at:
http://www.arin.net/mailing_lists/

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Policy Proposal Name: Allocation of IPv4 Blocks to Regional Internet
Registries

Proposal Originator:

This proposal was developed by a team consisting of persons from each of
the 5 RIRs.

Adiel A. Akplogan AfriNIC

Raul Echeberria LACNIC

Geoff Huston APNIC

MAEMURA Akinori APNIC

Axel Pawlik RIPE NCC

Ray Plzak ARIN

Oscar A. Robles-Garay" LACNIC

Nigel Titley RIPE NCC

Paul Wilson APNIC

Proposal Version: 3.0

Date: 9 March 2009

Proposal type: New Global

Policy term: Permanent

Policy statement:

This document describes the policy governing the allocation of IPv4
address space from the IANA to the Regional Internet Registries (RIRs).
This document does not stipulate performance requirements in the
provision of services by IANA to an RIR in accordance with this policy.
Such requirements should be specified by appropriate agreements among
the RIRs and ICANN.

This policy is to be implemented in two phases.

A. Phase I: Recovery of IPv4 Address Space

Upon ratification of this policy by the ICANN Board of Directors the
IANA shall establish a mechanism to receive IPv4 address space which is
returned to it by the RIRs, and hold that address space in a 'recovered
IPv4 pool'.

Each RIR through their respective chosen policies and strategies may
recover IPv4 address space which is under their administration. Each RIR
shall at quarterly intervals return any such recovered address space to
the IANA in aggregated blocks of /24 or larger, for inclusion in the
recovered IPv4 pool.

During Phase I, no allocations will be made from the recovered IPv4 pool.

B. Phase II: Allocation of Recovered IPv4 address space by the IANA

Upon ratification of this policy by the ICANN Board of Directors and a
declaration by the IANA that its existing free pool of unallocated IPv4
address space is depleted; Global Addressing Policy ASO-001-2 (adopted
by ICANN Board 8 April 2005) is rescinded. IANA will then commence to
allocate the IPv4 address space from the recovered IPv4 pool.

1. The following definitions apply to this policy:

a. Recovered Address Space.  Recovered address space is that address
space that is returned to an RIR as a result of any activity that seeks
to reclaim unused address space or is voluntarily returned to the RIR or
is reclaimed by the RIR as a result of legal action or abuse
determination. Recovered address space does not include that address
space that is reclaimed because of non-payment of contractual fees whose
reclamation date is less than 1 year at the time of the report.

b. IPv4 Address Holdings. IPv4 address holdings are all unallocated IPv4
address space held by an RIR to include recovered address space not yet
returned less that address space that is committed in accordance with
the RIR's reservation policy and practices.

c. Aggregated address blocks. Aggregated address blocks are contiguous
prefixes that can be aggregated on natural bit boundaries. 10.0.0.0/24
and 10.0.1.0/24 are two contiguous prefixes that can be combined to form
an aggregated address block. 10.0.0.0/24 and 10.0.1.0/25 are two
contiguous prefixes that cannot be combined on a natural bit boundary to
form an aggregated block.

2. Allocation of IPv4 Address Space

a. For the purposes of this policy, an 'IPv4 allocation period' is
defined as a 6-month period following 1 March or 1 September in each year.

b. At the beginning of each IPv4 allocation period, the IANA will
determine the 'IPv4 allocation unit' for that period, as 1/10 of its
IPv4 address pool, rounded down to the next CIDR (power-of-2) boundary.
The minimum 'IPv4 allocation unit' size will be a /24.

c. In each allocation period, each RIR may issue one IPv4 request to the
IANA. Providing that the RIR satisfies the allocation criteria described
in paragraph B.2, the IANA will allocate a single allocation unit,
composed of the smallest possible number of blocks available in its IPv4
address pool.

3. IPv4 Address Space Allocation Criteria

A RIR is eligible to receive additional IPv4 address space from the IANA
when the total of its IPv4 address holdings is less than 50% of the
current IPv4 allocation unit, and providing that it has not already
received an IPv4 allocation from the IANA during the current IPv4
allocation period.

4. Initial Allocation of IPv4 Address Space

Each new RIR shall, at the moment of recognition, be allocated one (1)
allocation unit by the IANA. If an allocation unit is not available,
then the IANA will issue this block as soon as one is available. This
allocation will be made regardless of the newly formed RIR's projected
utilization figures and shall be independent of the IPv4 address space
that may have been transferred to the new RIR by the already existing
RIRs as part of the formal transition process.

5. Reporting

a. All returned space is to be recorded in an IANA-published log of IPv4
address space transactions, with each log entry detailing the returned
address block, the date of the return, and the returning RIR.

b. All allocated space is also to be recorded in this IANA-published log
of IPv4 address space transactions, with each log entry detailing the
address blocks, the date of the allocation and the recipient RIR.

c. The IANA will maintain a public registry of the current disposition
of all IPv4 address space, detailing all reservations and current
allocations and current IANA-held address space that is unallocated.

d) The IANA may make public announcements of IPv4 address block
transactions that occur under this policy. The IANA will make
appropriate modifications to the "Internet Protocol V4 Address Space"
page of the IANA website and may make announcements to its own
appropriate announcement lists. The IANA announcements will be limited
to which address ranges, the time of allocation and to which Registry
they have been allocated.



Rationale:

This is version 3 of the policy proposal. It is the form that reached
consensus following community discussion at the APNIC 27 Policy SIG on
Thursday 26 February 2008 and endorsement at the APNIC Member Meeting
(AMM) on Friday 27 February 2008. With the depletion of the IANA free
pool of IPv4 address space, the current policy regarding the allocation
of IPv4 address space to the RIRs will become obsolete. The RIRs may,
according to their individual policies and procedures, recover IPv4
address space. This policy provides a mechanism for the RIRs to retro
allocate the recovered IPv4 address space to the IANA and provides the
IANA the policy by which it can allocate it back to the RIRs on a needs
basis. This policy creates a new global pool of IPv4 address space that
can be allocated where it is needed on a global basis without a transfer
of address space between the RIRs.

Specifically this revision does the following:

a. Adds the definition of "aggregated block" as paragraph 1.3.

b. Adds to paragraph 2.b the minimum allocation size which can be
allocated by IANA.

XXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Below are 3 exemplar scenarios of the execution of this policy after
Phase II is in force. These are not part of the rationale but are
provided for illustrative purposes.

Example 1:


On 1 March 2020, IANA has the equivalent of a /17 (32,768 addresses)
worth of IPv4 addresses.

1. IANA calculates that 1/10 of this space is 3,276 addresses.

2. IANA rounds this down to the next bit boundary, which creates a
minimum allocation size of /21 (2,048 addresses).

3. Each RIR can request and receive a single allocation unit equivalent
to a /21 worth of addresses.

4. While IANA may not be able to allocate a contiguous /21 and can
allocate noncontiguous smaller blocks equivalent to a /21 worth of
addresses.

Example 2:

On 1 March 2020, IANA has the equivalent of a /20 (4,096 addresses)
worth of IPv4 addresses.

1. IANA calculates that 1/10 of this space is 409 addresses.

2. IANA rounds this down to the next bit boundary, which creates a
minimum allocation size of /24 (256 addresses).

3. Each RIR can request and receive a single allocation unit equivalent
to a /24 worth of addresses.

4. As the minimum size of address space returned to IANA is /24, IANA
can allocate a contiguous range of addresses that amount to a /24.

Example 3:

On 1 March 2020, IANA has the equivalent of a /21 (2,048 addresses)
worth of IPv4 addresses.

1. IANA calculates that 1/10 of this space is 204 addresses.

2. IANA rounds this down to the next bit boundary, which creates a
minimum allocation size of /25 (128 addresses).

3. A /25 is smaller than the minimum permissible allocation size under
this policy.  A /25 is smaller than the minimum permissible allocation
size under this policy. Therefore, IANA is unable to make an allocation
until more address space is received.

XXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Timetable for implementation:

This policy is to be implemented immediately upon ratification by the
ICANN Board of Directors according to the global policy process
described in the ASO MoU.






From info at arin.net  Mon Mar  9 14:42:01 2009
From: info at arin.net (Member Services)
Date: Mon, 09 Mar 2009 14:42:01 -0400
Subject: [arin-ppml] =?windows-1252?q?Petition_Deadline_=96_San_Antonio?=
Message-ID: <49B562F9.5070909@arin.net>

Next month ARIN will conduct it?s bi-annual meeting ARIN XXIII 26-29
April 2009 in San Antonio Texas.  During that time, the Public Policy
Meeting will occur 27-28 April 2009.  In accordance with the Policy
Development Process, ARIN is informing the community that the time to
petition due to dissatisfaction with the actions taken so far by the
ARIN Advisory Council (AC) regarding policy proposals is drawing to a close.

The AC is currently working on six proposals and draft texts.

The AC intends to bring forth the following as draft policies for
discussion on the ARIN Public Policy Mailing list and at the upcoming
Public Policy Meeting:

   2008-7: Whois Integrity Policy Proposal

   80. IPv4 Recovery Fund

   81. Depleted IPv4 reserves

   82. Allocation of IPv4 Blocks to Regional Internet Registries (Global)

The AC is continuing to work on these, but may not be publishing draft
policy text on the PPML in time for the upcoming Public Policy Meeting:

   2008-3: Community Networks IPv6 Allocation

   83. Protective Usage Transfer Policy for IPv4 Address

All draft policies must be published to the PPML at least 35 days prior
to a meeting in order to be placed on the agenda for that meeting. That
35-day deadline for ARIN XXIII is 23 March 2009. In addition, the entire
petition process to move proposals forward as draft policies must be
completed prior to the 35-day deadline. Per the ARIN Policy Development
Process, ?Any member of the community, including a proposal originator,
may initiate a Discussion Petition if they are dissatisfied with the
action taken by the Advisory Council regarding any specific policy
proposal. If successful, this petition will change the policy proposal
to a draft policy which will be published for discussion and review by
the community on the PPML and at an upcoming public policy meeting.?

The deadline to start a proposal petition is 13 March 2009. Petitions
must include the proposal and a petition statement. Once begun, a
petition lasts for 5 business days. Success is measured as support from
at least 10 different people from 10 different organizations. Should an
actual petition begin, ARIN staff will post more detailed information.

The text for Draft Policies and Proposals is available at:
https://www.arin.net/policy/proposals/

The ARIN Policy Development Process is available at:
https://www.arin.net/policy/pdp.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)



From martin.hannigan at batelnet.bs  Tue Mar 10 18:24:20 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Tue, 10 Mar 2009 18:24:20 -0400
Subject: [arin-ppml] Policy Proposal (Global): Allocation of IPv4 Blocks
	to Regional Internet Registries - Revised
In-Reply-To: <49B53329.5010603@arin.net>
References: <49B53329.5010603@arin.net>
Message-ID: <4607e1d50903101524p51e29b6cna0a5426af2ca722e@mail.gmail.com>

[ clip ]


>
> This policy is to be implemented in two phases.
>
> A. Phase I: Recovery of IPv4 Address Space
>
> Upon ratification of this policy by the ICANN Board of Directors the
> IANA shall establish a mechanism to receive IPv4 address space which is
> returned to it by the RIRs, and hold that address space in a 'recovered
> IPv4 pool'.
>
> Each RIR through their respective chosen policies and strategies may
> recover IPv4 address space which is under their administration. Each RIR
> shall at quarterly intervals return any such recovered address space to
> the IANA in aggregated blocks of /24 or larger, for inclusion in the
> recovered IPv4 pool.



Not in favor of this policy moving forward, again.

How does ARIN justify turning over ip address space to the IANA to address
needs if ARIN  has needs? For example, another region may go to the IANA
under this policy and get an allocation "unit", a ration, that address 100%
of their current need. The ARIN region may go to the well to have only
.0001% of their current need addressed.

Without restrictions on use of the IP address resources that may go back
"the funds", how can we be certain that we aren't fueling the proverbial
corporate jet through the transfer processes in other regions?

This is a disincentive for ARIN to recover address space and an incentive
for a stronger and continuing address space market, gray or not, since it
creates fear that entities with needs will not be able to get v4 address
space. The counter argument that everyone should be migrating to v6 anyhow
becomes a straw man based on this policy.


[ clip ]


> 4. Initial Allocation of IPv4 Address Space
>
> Each new RIR shall, at the moment of recognition, be allocated one (1)
> allocation unit by the IANA. If an allocation unit is not available,
> then the IANA will issue this block as soon as one is available. This
> allocation will be made regardless of the newly formed RIR's projected
> utilization figures and shall be independent of the IPv4 address space
> that may have been transferred to the new RIR by the already existing
> RIRs as part of the formal transition process.



This is to address the MOU and attachment with ICANN? Not being able to
allocate v4 address space to a new RIR does not seem to prevent it's
creation and the MoU does not seem to require a v4 allocation to a new RIR
[beyond exhaustion]. I don't see a reason why[if needed] a new RIR can't be
"pure" v6 and allow this policy to be in compliance with the MoU.

But -- since it is in last call and likely to be accepted in the APNIC
region, suggestions for change are moot. This policy not move forward.

Why not instead create an ARIN policy that sets aside [possibly] recovered
space and open the door to allow "others not normally eligible" to go ahead
and submit needs based requests against such a pool and on an even footing
with existing allocations "if" there is excess space available "and" ARIN's
needs are met and in line with ARIN policy?

Best Regards,

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090310/195219da/attachment.htm>

From JOHN at egh.com  Tue Mar 10 21:14:04 2009
From: JOHN at egh.com (John Santos)
Date: Tue, 10 Mar 2009 20:14:04 -0500
Subject: [arin-ppml] Policy Proposal (Global): Allocation of IPv4 Blocks
	to Regional Internet Registries - Revised
In-Reply-To: <4607e1d50903101524p51e29b6cna0a5426af2ca722e@mail.gmail.com>
Message-ID: <1090310195651.5520A-100000@Ives.egh.com>


Maybe I just didn't read this closely enough, but I don't see where it
actually *requires* an RIR to return returned address space to the IANA.

As far as I can tell, every 6 months, an RIR returns *surplus* address
space (presumably acquired from returned V4 blocks) to IANA which can
then be delegated to other RIRs.  There didn't seem to be any criteria
for determining what's "surplus".  Does the RIR just decide it now has
more than it will need in the forseeable future and elect to return it
so other RIRs can use it?  Is there no mechanism currently in place to
do that?  Is the idea here just that after widespread IPv6 adoption,
lots of v4 space will get returned, mostly to ARIN since ARIN has the
most space, and there may still be pent up demand for it in other
regions.  For example, a lot of poorer countries may be adopting
internets based on old, obsolete tech that they can acquire cheap on
the used market, but doesn't do IPv6.  This would give them a
mechanism to acquire abandoned v4 addresses (indirectly) from ARIN.

If this is *all* this policy is intended to accomplish, then fine.
If an RIR is *required* to return returned addresses to IANA despite
ongoing need within that RIR, then this is just busy work, since they'll
immediately have to turn around and get more, probably different
addresses back from IANA and causing bureaucratic delays and routing
churn, since the addresses will go right back to the RIRs with the
most demand.

-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539

From marla.azinger at frontiercorp.com  Tue Mar 10 19:57:31 2009
From: marla.azinger at frontiercorp.com (Azinger, Marla)
Date: Tue, 10 Mar 2009 19:57:31 -0400
Subject: [arin-ppml] Policy Proposal (Global): Allocation of IPv4
	Blocks	to Regional Internet Registries - Revised
In-Reply-To: <1090310195651.5520A-100000@Ives.egh.com>
References: <4607e1d50903101524p51e29b6cna0a5426af2ca722e@mail.gmail.com>
	<1090310195651.5520A-100000@Ives.egh.com>
Message-ID: <2E2FECEBAE57CC4BAACDE67638305F10484CC53766@ROCH-EXCH1.corp.pvt>

The current text can easily be interpreted to mean all RIR's must return the address space.  ARIN AC is working on a revision that makes it an option and not a requirement as the current text would undermine other current ARIN policy regarding reclamation.  We dont see anything wrong with permitting other RIR's to return the space if they choose to do so, but making it a requirement would not support ARIN policy and we dont want conflicting policies.

Cheers
Marla Azinger

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Santos
Sent: Tuesday, March 10, 2009 6:14 PM
To: Martin Hannigan
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Policy Proposal (Global): Allocation of IPv4 Blocks to Regional Internet Registries - Revised


Maybe I just didn't read this closely enough, but I don't see where it actually *requires* an RIR to return returned address space to the IANA.

As far as I can tell, every 6 months, an RIR returns *surplus* address space (presumably acquired from returned V4 blocks) to IANA which can then be delegated to other RIRs.  There didn't seem to be any criteria for determining what's "surplus".  Does the RIR just decide it now has more than it will need in the forseeable future and elect to return it so other RIRs can use it?  Is there no mechanism currently in place to do that?  Is the idea here just that after widespread IPv6 adoption, lots of v4 space will get returned, mostly to ARIN since ARIN has the most space, and there may still be pent up demand for it in other regions.  For example, a lot of poorer countries may be adopting internets based on old, obsolete tech that they can acquire cheap on the used market, but doesn't do IPv6.  This would give them a mechanism to acquire abandoned v4 addresses (indirectly) from ARIN.

If this is *all* this policy is intended to accomplish, then fine.
If an RIR is *required* to return returned addresses to IANA despite ongoing need within that RIR, then this is just busy work, since they'll immediately have to turn around and get more, probably different addresses back from IANA and causing bureaucratic delays and routing churn, since the addresses will go right back to the RIRs with the most demand.

--
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539


From owen at delong.com  Wed Mar 11 02:27:30 2009
From: owen at delong.com (Owen DeLong)
Date: Tue, 10 Mar 2009 23:27:30 -0700
Subject: [arin-ppml] Policy Proposal (Global): Allocation of IPv4 Blocks
	to Regional Internet Registries - Revised
In-Reply-To: <1090310195651.5520A-100000@Ives.egh.com>
References: <1090310195651.5520A-100000@Ives.egh.com>
Message-ID: <6D5AC3EA-8240-4EEB-9201-818B7AB7E6C3@delong.com>


On Mar 10, 2009, at 6:14 PM, John Santos wrote:

>
> Maybe I just didn't read this closely enough, but I don't see where it
> actually *requires* an RIR to return returned address space to the  
> IANA.
>
In the description of phase one, it's pretty clear that the intent is  
that RIRs
do not reissue returned blocks and instead shall pass them back to the
IANA.

> As far as I can tell, every 6 months, an RIR returns *surplus* address
> space (presumably acquired from returned V4 blocks) to IANA which can
> then be delegated to other RIRs.  There didn't seem to be any criteria
> for determining what's "surplus".  Does the RIR just decide it now has
> more than it will need in the forseeable future and elect to return it
> so other RIRs can use it?  Is there no mechanism currently in place to
> do that?  Is the idea here just that after widespread IPv6 adoption,
> lots of v4 space will get returned, mostly to ARIN since ARIN has the
> most space, and there may still be pent up demand for it in other
> regions.  For example, a lot of poorer countries may be adopting
> internets based on old, obsolete tech that they can acquire cheap on
> the used market, but doesn't do IPv6.  This would give them a
> mechanism to acquire abandoned v4 addresses (indirectly) from ARIN.
>
Nope... Every 6 months, an RIR returns all reclaimed address space
is how I read the policy.

> If this is *all* this policy is intended to accomplish, then fine.
> If an RIR is *required* to return returned addresses to IANA despite
> ongoing need within that RIR, then this is just busy work, since  
> they'll
> immediately have to turn around and get more, probably different
> addresses back from IANA and causing bureaucratic delays and routing
> churn, since the addresses will go right back to the RIRs with the
> most demand.
>
Except it limits what they can get back from IANA to one allocation unit
per 6 month cycle regardless of how much more they need.

Owen



From martin.hannigan at batelnet.bs  Wed Mar 11 10:41:21 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Wed, 11 Mar 2009 10:41:21 -0400
Subject: [arin-ppml] Policy Proposal (Global): Allocation of IPv4 Blocks
	to Regional Internet Registries - Revised
In-Reply-To: <2E2FECEBAE57CC4BAACDE67638305F10484CC53766@ROCH-EXCH1.corp.pvt>
References: <4607e1d50903101524p51e29b6cna0a5426af2ca722e@mail.gmail.com>
	<1090310195651.5520A-100000@Ives.egh.com>
	<2E2FECEBAE57CC4BAACDE67638305F10484CC53766@ROCH-EXCH1.corp.pvt>
Message-ID: <4607e1d50903110741u2b17f97al9b930781990654b4@mail.gmail.com>

On Tue, Mar 10, 2009 at 7:57 PM, Azinger, Marla <
marla.azinger at frontiercorp.com> wrote:

> The current text can easily be interpreted to mean all RIR's must return
> the address space.  ARIN AC is working on a revision that makes it an option
> and not a requirement as the current text would undermine other current ARIN
> policy regarding reclamation.  We dont see anything wrong with permitting
> other RIR's to return the space if they choose to do so, but making it a
> requirement would not support ARIN policy and we dont want conflicting
> policies.
>
>

Changes that are ok under the global pdp are very minor non-contextual
changes. Changes that would be subject to scrutiny by the ASO AC are changes
that cause a policy to significantly differ from one region to another. If
the AC, for example, fixed some fuzzy language, that could be enough to
significantly change the policy since it could be interepreted differently
vs. a version in another region.

My suggestion would be that the AC either forward this policy or send it
back to the authors so that they can decide how they want to proceed, either
withdrawing it and starting from scratch or trying to fix it without a major
contextual change.

Best,
Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090311/ff910a02/attachment.htm>

From martin.hannigan at batelnet.bs  Wed Mar 11 15:16:32 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Wed, 11 Mar 2009 15:16:32 -0400
Subject: [arin-ppml] Policy Proposal (Global): Allocation of IPv4 Blocks
	to Regional Internet Registries - Revised
In-Reply-To: <6D5AC3EA-8240-4EEB-9201-818B7AB7E6C3@delong.com>
References: <1090310195651.5520A-100000@Ives.egh.com>
	<6D5AC3EA-8240-4EEB-9201-818B7AB7E6C3@delong.com>
Message-ID: <4607e1d50903111216k1adee456j929efda221a1961b@mail.gmail.com>

On Wed, Mar 11, 2009 at 2:27 AM, Owen DeLong <owen at delong.com> wrote:

>
> On Mar 10, 2009, at 6:14 PM, John Santos wrote:
>
>
>> Maybe I just didn't read this closely enough, but I don't see where it
>> actually *requires* an RIR to return returned address space to the IANA.
>>
>>  In the description of phase one, it's pretty clear that the intent is
> that RIRs
> do not reissue returned blocks and instead shall pass them back to the


In Section A, there is no ambiguity. It clearly states the RIR's _shall_
return v4 space based on the defintion in b.1.b "Holdings". It makes no
distinction between legacy v4 or non-legacy v4 address space. The only
differentiated v4 address space is v4 address space that has administrative
issues(legal, financial). A grace and/or sunset period is created for its
eventual resolution and "clear" return.


> IANA.
>
>  As far as I can tell, every 6 months, an RIR returns *surplus* address
>> space (presumably acquired from returned V4 blocks) to IANA which can
>> then be delegated to other RIRs.  There didn't seem to be any criteria
>> for determining what's "surplus".  Does the RIR just decide it now has
>> more than it will need in the forseeable future and elect to return it
>> so other RIRs can use it?  Is there no mechanism currently in place to
>> do that?  Is the idea here just that after widespread IPv6 adoption,
>> lots of v4 space will get returned, mostly to ARIN since ARIN has the
>> most space, and there may still be pent up demand for it in other
>> regions.  For example, a lot of poorer countries may be adopting
>> internets based on old, obsolete tech that they can acquire cheap on
>> the used market, but doesn't do IPv6.  This would give them a
>> mechanism to acquire abandoned v4 addresses (indirectly) from ARIN.
>>
>>  Nope... Every 6 months, an RIR returns all reclaimed address space
> is how I read the policy.


The relevant definition is B.1.b "Holdings".

Best,

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090311/620e8afb/attachment.htm>

From farmer at umn.edu  Wed Mar 11 17:08:42 2009
From: farmer at umn.edu (David Farmer)
Date: Wed, 11 Mar 2009 16:08:42 -0500
Subject: [arin-ppml] Policy Proposal (Global): Allocation of IPv4 Blocks
	to Regional Internet Registries - Revised
In-Reply-To: <4607e1d50903110741u2b17f97al9b930781990654b4@mail.gmail.com>
References: <4607e1d50903101524p51e29b6cna0a5426af2ca722e@mail.gmail.com>,
	<2E2FECEBAE57CC4BAACDE67638305F10484CC53766@ROCH-EXCH1.corp.pvt>,
	<4607e1d50903110741u2b17f97al9b930781990654b4@mail.gmail.com>
Message-ID: <49B7E20A.31690.9C90AE4@farmer.umn.edu>

On 11 Mar 2009 Martin Hannigan wrote:

> Changes that are ok under the global pdp are very minor non-contextual
> changes. Changes that would be subject to scrutiny by the ASO AC are
> changes that cause a policy to significantly differ from one region to
> another. If the AC, for example, fixed some fuzzy language, that could
> be enough to significantly change the policy since it could be
> interepreted differently vs. a version in another region.
>
> My suggestion would be that the AC either forward this policy or send
> it back to the authors so that they can decide how they want to
> proceed, either withdrawing it and starting from scratch or trying to
> fix it without a major contextual change.

Based on your previous post I assume you are not in favor of moving it 
forward, and would favor sending it back to the authors.

I believe we should send it back to the authors too, but if we do that and we 
want them to make changes, rather than just scrap it, I believe it would be a 
good idea to give them feedback on how we would like to see it changed to 
as be more suitable to the ARIN community

There are several issues I think we should give them feedback on:

1.  RIR assigned vs. Legacy Blocks -  It might be be helpful to differentiate 
between Legacy assignments and RIR assigned /8s.  Like making return of 
RIR assigned block optional, and Legacy assigned block mandatory.

2. General Fragmentation - There are several reasons, geolocation, regional 
route aggregation, etc... that it is useful to be able to make assumptions 
about addresses in big blocks.  While some amount of this kind of 
fragmentation is inevitable, to the extent possible it would be helpful to 
minimize this fragmentation.  At the very least, IANA should be charged to 
minimize fragmentation when reallocating blocks to the RIRs

3. DNS Reverse Zone Fragmentation - Fragmentation will also affect the 
DNS reverse zones, while probably a manageable issue, it wouldn't hut to 
minimize this as much as possible too.  From a reverse zone point of view, 
/16 is the next logical break point down from /8 where IANA manages things 
now.  How do we plan to deal with this, does it become a inter-RIR issue to 
redelegate the appropriate reverse zones, or does IANA take over the /8 
level and delegate out the /16 reverse zones appropriately to the RIRs? 

4. Big blocks vs. small block - This is kind of related to #2 and #3.  
Personally, I could agree that big blocks are resources of the whole Internet 
and should go back to IANA.  I would consider /8 - /16 as big blocks for sure, 
and there is definatly value in retruning those to IANA.   But the value of 
returning smaller blocks, /20 or longer for sure, to IANA in my opinion is 
minimal.  Especially compared to the fragmentation effects and just general 
confusion that it would create. So maybe small blocks should remain with or 
be returned to the RIR associated managing the /8 the block is part of.  I'm 
willing to be flexible if /17 - /19 are considered big or small. But, from a DNS 
reverse zone point of view there is an advantage of picking /16 as the 
divider.

5. Need criteria -  an RIR should still have to justify need to get additional 
address blocks, it is not clear to me that as currently drafted that an RIR 
would still have to justify its need for any blocks it receives.

6. Incentives -  What if an RIR has to provide incentives to motivate the 
return address space?  Should the RIR be able to keep blocks returned for 
which incentives were paid?  Should the other RIRs have to reimburse the 
RIR providing the incentive pro-rata shares?  Maybe if an RIR pays 
incentives worth more than some amount (say $5,000 for discussion) then 
they keep 50% of the block and must return 50% of the block to IANA.  


=======================================================
David Farmer				     Email:	farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota			     Phone:	612-626-0815
2218 University Ave SE			     Cell:		612-812-9952
Minneapolis, MN 55414-3029		     FAX:	612-626-1818
=======================================================



From martin.hannigan at batelnet.bs  Wed Mar 11 19:09:19 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Wed, 11 Mar 2009 19:09:19 -0400
Subject: [arin-ppml] Policy Proposal (Global): Allocation of IPv4 Blocks
	to Regional Internet Registries - Revised
In-Reply-To: <49B7E20A.31690.9C90AE4@farmer.umn.edu>
References: <4607e1d50903101524p51e29b6cna0a5426af2ca722e@mail.gmail.com>
	<2E2FECEBAE57CC4BAACDE67638305F10484CC53766@ROCH-EXCH1.corp.pvt>
	<4607e1d50903110741u2b17f97al9b930781990654b4@mail.gmail.com>
	<49B7E20A.31690.9C90AE4@farmer.umn.edu>
Message-ID: <4607e1d50903111609j5626014w7cc171c42a850676@mail.gmail.com>

On Wed, Mar 11, 2009 at 5:08 PM, David Farmer <farmer at umn.edu> wrote:

> On 11 Mar 2009 Martin Hannigan wrote:
>
> > Changes that are ok under the global pdp are very minor non-contextual
> > changes. Changes that would be subject to scrutiny by the ASO AC are
> > changes that cause a policy to significantly differ from one region to
> > another. If the AC, for example, fixed some fuzzy language, that could
> > be enough to significantly change the policy since it could be
> > interepreted differently vs. a version in another region.
> >
> > My suggestion would be that the AC either forward this policy or send
> > it back to the authors so that they can decide how they want to
> > proceed, either withdrawing it and starting from scratch or trying to
> > fix it without a major contextual change.
>
> Based on your previous post I assume you are not in favor of moving it
> forward, and would favor sending it back to the authors.



Agreed.


>
> I believe we should send it back to the authors too, but if we do that and
> we
> want them to make changes, rather than just scrap it, I believe it would be
> a
> good idea to give them feedback on how we would like to see it changed to
> as be more suitable to the ARIN community


I'm in favor of the discussion. A few points to help explain the global
policy pdp. The problem with the AC changing the policy at this juncture is
that it's already in last call in the APNIC region. The authors would have
some decisions to make if the AC made a significant modification to the
document. A global policy must be passed in a contextually similiar form in
each RIR region in order for it to be processed and certified by the ASO AC
and ICANN BoD as a global policy. I'm not sure how you get a proposal to the
floor without the AC moving it forward.

They could instead send their feedback [ours] to the authors and let them
decide what to do since the onus of the work should be on the authors
considering the complexity of the global pdp and the difficulties in
manuevering the policy around the glob?


> There are several issues I think we should give them feedback on:
>
> 1.  RIR assigned vs. Legacy Blocks -  It might be be helpful to
> differentiate
> between Legacy assignments and RIR assigned /8s.  Like making return of
> RIR assigned block optional, and Legacy assigned block mandatory.


Differentiating creates classes. We see that differientation and the
resulting difficulties with creating reasonable, modernized, transfer
policy. When you create a class, you almost always end up with an inequity
that is uneven and painful. Citizenship vs. non-citizenship, for example.

[ clip ]


> 5. Need criteria -  an RIR should still have to justify need to get
> additional
> address blocks, it is not clear to me that as currently drafted that an RIR
> would still have to justify its need for any blocks it receives.


I believe that there is a typo[1] in the policy. In B.2.c it refers to B.2
as the allocation criteria. The authors may mean to refer to B.3 as the
allocation criteria reference.

When compared to the B.1.B, holdings eligible for return to the IANA, we
seem to have a gap between the allocation criteria and the return of
eligible holdings in the form of "inventory". I don't see how inventory is
allowed.



> 6. Incentives -  What if an RIR has to provide incentives to motivate the
> return address space?  Should the RIR be able to keep blocks returned for
> which incentives were paid?  Should the other RIRs have to reimburse the
> RIR providing the incentive pro-rata shares?  Maybe if an RIR pays
> incentives worth more than some amount (say $5,000 for discussion) then
> they keep 50% of the block and must return 50% of the block to IANA.
>

An RIR would not provide incentives under this policy. The space would
return to the IANA which becomes the disincentive, along with the allocation
unit, and the liklihood of a regional requests being stalled en-masse when
we "do" have space. Or did.

The best way to demonstrate the disparity may be to simply look at the
current utilization statistics[2] provided by the NRO. Fast forward this to
the 2010 prediction and imagine that as the size of the "backed up"
requests. This demonstrates to me that this policy would not be favorable
for any RIR region, IMHO, which is why it may have been proposed.

The one other issue that I have is the performance metric reference in
opening section where it states that service performance SLA's are between
the IANA and the collective RIR's. Should we take this to mean the NRO? If
that is the case, I'd like to see an additional insertion of a clause that
requires public reporting of those metrics as related to this policy for
transparency purposes. It may already be required of the IANA and NRO
elsewhere, but I'd like to see it be a requirement of the NRO as well.


1. This would qualify as a "minor" change under the global PDP and not
materially affect the meaning of the policy, IMHO, and the AC "should"
consider making that change if they forward for consensus, even if just for
discussion.

2. NRO aggregated RIR statistics
http://www.nro.net/documents/presentations/nro-jointstats_12-31-08.pdf

I'm surprised that this policy made it to last call in APNIC. It seems that
it's bad for them considering that they are currently utilizing IP address
space the fastest[2].
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090311/67e5a040/attachment.htm>

From scottleibrand at gmail.com  Wed Mar 11 20:24:40 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Wed, 11 Mar 2009 17:24:40 -0700
Subject: [arin-ppml] Policy Proposal (Global): Allocation of IPv4 Blocks
 to Regional Internet Registries - Revised
In-Reply-To: <4607e1d50903111609j5626014w7cc171c42a850676@mail.gmail.com>
References: <4607e1d50903101524p51e29b6cna0a5426af2ca722e@mail.gmail.com>	<2E2FECEBAE57CC4BAACDE67638305F10484CC53766@ROCH-EXCH1.corp.pvt>	<4607e1d50903110741u2b17f97al9b930781990654b4@mail.gmail.com>	<49B7E20A.31690.9C90AE4@farmer.umn.edu>
	<4607e1d50903111609j5626014w7cc171c42a850676@mail.gmail.com>
Message-ID: <49B85648.1060107@gmail.com>

Marty,

Thanks for your excellent input here.

I seem to recall that the last time we went through the global PDP (with 
the "last /8" policy), that we had several RIRs who liked the general 
idea, but required substantial changes (namely N=1 instead of 2 or more) 
to support it.  IIRC, some RIRs passed it first with a higher value for 
N, then had to go back and pass the N=1 consensus version after that was 
what passed in the other RIRs.

I'm wondering if we couldn't do something similar here.  While I think 
some sort of policy along these lines might be beneficial (and we need 
*something* to tell the IANA what to do after IANA free pool 
exhaustion), I think that the policy as written is unworkable, for all 
the reasons outlined by others.

So, what if the ARIN AC were to go ahead and revise the policy along the 
lines of what Marla outlined earlier?  Assuming that a less restrictive 
policy is all we'll have consensus for, wouldn't that just mean that 
APNIC would have to pass the less restrictive version as well before it 
could advance to the ASO?

Thanks again,
Scott

Martin Hannigan wrote:
>
>
> On Wed, Mar 11, 2009 at 5:08 PM, David Farmer <farmer at umn.edu 
> <mailto:farmer at umn.edu>> wrote:
>
>     On 11 Mar 2009 Martin Hannigan wrote:
>
>     > Changes that are ok under the global pdp are very minor
>     non-contextual
>     > changes. Changes that would be subject to scrutiny by the ASO AC are
>     > changes that cause a policy to significantly differ from one
>     region to
>     > another. If the AC, for example, fixed some fuzzy language, that
>     could
>     > be enough to significantly change the policy since it could be
>     > interepreted differently vs. a version in another region.
>     >
>     > My suggestion would be that the AC either forward this policy or
>     send
>     > it back to the authors so that they can decide how they want to
>     > proceed, either withdrawing it and starting from scratch or
>     trying to
>     > fix it without a major contextual change.
>
>     Based on your previous post I assume you are not in favor of moving it
>     forward, and would favor sending it back to the authors.
>
>
>
> Agreed.
>  
>
>
>     I believe we should send it back to the authors too, but if we do
>     that and we
>     want them to make changes, rather than just scrap it, I believe it
>     would be a
>     good idea to give them feedback on how we would like to see it
>     changed to
>     as be more suitable to the ARIN community
>
>
> I'm in favor of the discussion. A few points to help explain the 
> global policy pdp. The problem with the AC changing the policy at this 
> juncture is that it's already in last call in the APNIC region. The 
> authors would have some decisions to make if the AC made a significant 
> modification to the document. A global policy must be passed in a 
> contextually similiar form in each RIR region in order for it to be 
> processed and certified by the ASO AC and ICANN BoD as a global 
> policy. I'm not sure how you get a proposal to the floor without the 
> AC moving it forward.
>
> They could instead send their feedback [ours] to the authors and let 
> them decide what to do since the onus of the work should be on the 
> authors considering the complexity of the global pdp and the 
> difficulties in manuevering the policy around the glob?
>
>
>     There are several issues I think we should give them feedback on:
>
>     1.  RIR assigned vs. Legacy Blocks -  It might be be helpful to
>     differentiate
>     between Legacy assignments and RIR assigned /8s.  Like making
>     return of
>     RIR assigned block optional, and Legacy assigned block mandatory.
>
>
> Differentiating creates classes. We see that differientation and the 
> resulting difficulties with creating reasonable, modernized, transfer 
> policy. When you create a class, you almost always end up with an 
> inequity that is uneven and painful. Citizenship vs. non-citizenship, 
> for example.
>
> [ clip ]
>
>
>     5. Need criteria -  an RIR should still have to justify need to
>     get additional
>     address blocks, it is not clear to me that as currently drafted
>     that an RIR
>     would still have to justify its need for any blocks it receives.
>
>
> I believe that there is a typo[1] in the policy. In B.2.c it refers to 
> B.2 as the allocation criteria. The authors may mean to refer to B.3 
> as the allocation criteria reference.
>
> When compared to the B.1.B, holdings eligible for return to the IANA, 
> we seem to have a gap between the allocation criteria and the return 
> of eligible holdings in the form of "inventory". I don't see how 
> inventory is allowed.
>
>
>
>     6. Incentives -  What if an RIR has to provide incentives to
>     motivate the
>     return address space?  Should the RIR be able to keep blocks
>     returned for
>     which incentives were paid?  Should the other RIRs have to
>     reimburse the
>     RIR providing the incentive pro-rata shares?  Maybe if an RIR pays
>     incentives worth more than some amount (say $5,000 for discussion)
>     then
>     they keep 50% of the block and must return 50% of the block to IANA.
>
>
> An RIR would not provide incentives under this policy. The space would 
> return to the IANA which becomes the disincentive, along with the 
> allocation unit, and the liklihood of a regional requests being 
> stalled en-masse when we "do" have space. Or did.
>
> The best way to demonstrate the disparity may be to simply look at the 
> current utilization statistics[2] provided by the NRO. Fast forward 
> this to the 2010 prediction and imagine that as the size of the 
> "backed up" requests. This demonstrates to me that this policy would 
> not be favorable for any RIR region, IMHO, which is why it may have 
> been proposed.
>
> The one other issue that I have is the performance metric reference in 
> opening section where it states that service performance SLA's are 
> between the IANA and the collective RIR's. Should we take this to mean 
> the NRO? If that is the case, I'd like to see an additional insertion 
> of a clause that requires public reporting of those metrics as related 
> to this policy for transparency purposes. It may already be required 
> of the IANA and NRO elsewhere, but I'd like to see it be a requirement 
> of the NRO as well.
>
>
> 1. This would qualify as a "minor" change under the global PDP and not 
> materially affect the meaning of the policy, IMHO, and the AC "should" 
> consider making that change if they forward for consensus, even if 
> just for discussion.
>
> 2. NRO aggregated RIR statistics 
> http://www.nro.net/documents/presentations/nro-jointstats_12-31-08.pdf
>
> I'm surprised that this policy made it to last call in APNIC. It seems 
> that it's bad for them considering that they are currently utilizing 
> IP address space the fastest[2].
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From owen at delong.com  Wed Mar 11 21:33:33 2009
From: owen at delong.com (Owen DeLong)
Date: Wed, 11 Mar 2009 18:33:33 -0700
Subject: [arin-ppml] Policy Proposal (Global): Allocation of IPv4 Blocks
	to Regional Internet Registries - Revised
In-Reply-To: <49B85648.1060107@gmail.com>
References: <4607e1d50903101524p51e29b6cna0a5426af2ca722e@mail.gmail.com>	<2E2FECEBAE57CC4BAACDE67638305F10484CC53766@ROCH-EXCH1.corp.pvt>	<4607e1d50903110741u2b17f97al9b930781990654b4@mail.gmail.com>	<49B7E20A.31690.9C90AE4@farmer.umn.edu>
	<4607e1d50903111609j5626014w7cc171c42a850676@mail.gmail.com>
	<49B85648.1060107@gmail.com>
Message-ID: <EF36BFCF-B3D2-4F87-8E78-523C0DACABCB@delong.com>

That's correct.  IMHO, that's what we should do as well.

Owen

On Mar 11, 2009, at 5:24 PM, Scott Leibrand wrote:

> Marty,
>
> Thanks for your excellent input here.
>
> I seem to recall that the last time we went through the global PDP  
> (with
> the "last /8" policy), that we had several RIRs who liked the general
> idea, but required substantial changes (namely N=1 instead of 2 or  
> more)
> to support it.  IIRC, some RIRs passed it first with a higher value  
> for
> N, then had to go back and pass the N=1 consensus version after that  
> was
> what passed in the other RIRs.
>
> I'm wondering if we couldn't do something similar here.  While I think
> some sort of policy along these lines might be beneficial (and we need
> *something* to tell the IANA what to do after IANA free pool
> exhaustion), I think that the policy as written is unworkable, for all
> the reasons outlined by others.
>
> So, what if the ARIN AC were to go ahead and revise the policy along  
> the
> lines of what Marla outlined earlier?  Assuming that a less  
> restrictive
> policy is all we'll have consensus for, wouldn't that just mean that
> APNIC would have to pass the less restrictive version as well before  
> it
> could advance to the ASO?
>
> Thanks again,
> Scott
>
> Martin Hannigan wrote:
>>
>>
>> On Wed, Mar 11, 2009 at 5:08 PM, David Farmer <farmer at umn.edu
>> <mailto:farmer at umn.edu>> wrote:
>>
>>    On 11 Mar 2009 Martin Hannigan wrote:
>>
>>> Changes that are ok under the global pdp are very minor
>>    non-contextual
>>> changes. Changes that would be subject to scrutiny by the ASO AC are
>>> changes that cause a policy to significantly differ from one
>>    region to
>>> another. If the AC, for example, fixed some fuzzy language, that
>>    could
>>> be enough to significantly change the policy since it could be
>>> interepreted differently vs. a version in another region.
>>>
>>> My suggestion would be that the AC either forward this policy or
>>    send
>>> it back to the authors so that they can decide how they want to
>>> proceed, either withdrawing it and starting from scratch or
>>    trying to
>>> fix it without a major contextual change.
>>
>>    Based on your previous post I assume you are not in favor of  
>> moving it
>>    forward, and would favor sending it back to the authors.
>>
>>
>>
>> Agreed.
>>
>>
>>
>>    I believe we should send it back to the authors too, but if we do
>>    that and we
>>    want them to make changes, rather than just scrap it, I believe it
>>    would be a
>>    good idea to give them feedback on how we would like to see it
>>    changed to
>>    as be more suitable to the ARIN community
>>
>>
>> I'm in favor of the discussion. A few points to help explain the
>> global policy pdp. The problem with the AC changing the policy at  
>> this
>> juncture is that it's already in last call in the APNIC region. The
>> authors would have some decisions to make if the AC made a  
>> significant
>> modification to the document. A global policy must be passed in a
>> contextually similiar form in each RIR region in order for it to be
>> processed and certified by the ASO AC and ICANN BoD as a global
>> policy. I'm not sure how you get a proposal to the floor without the
>> AC moving it forward.
>>
>> They could instead send their feedback [ours] to the authors and let
>> them decide what to do since the onus of the work should be on the
>> authors considering the complexity of the global pdp and the
>> difficulties in manuevering the policy around the glob?
>>
>>
>>    There are several issues I think we should give them feedback on:
>>
>>    1.  RIR assigned vs. Legacy Blocks -  It might be be helpful to
>>    differentiate
>>    between Legacy assignments and RIR assigned /8s.  Like making
>>    return of
>>    RIR assigned block optional, and Legacy assigned block mandatory.
>>
>>
>> Differentiating creates classes. We see that differientation and the
>> resulting difficulties with creating reasonable, modernized, transfer
>> policy. When you create a class, you almost always end up with an
>> inequity that is uneven and painful. Citizenship vs. non-citizenship,
>> for example.
>>
>> [ clip ]
>>
>>
>>    5. Need criteria -  an RIR should still have to justify need to
>>    get additional
>>    address blocks, it is not clear to me that as currently drafted
>>    that an RIR
>>    would still have to justify its need for any blocks it receives.
>>
>>
>> I believe that there is a typo[1] in the policy. In B.2.c it refers  
>> to
>> B.2 as the allocation criteria. The authors may mean to refer to B.3
>> as the allocation criteria reference.
>>
>> When compared to the B.1.B, holdings eligible for return to the IANA,
>> we seem to have a gap between the allocation criteria and the return
>> of eligible holdings in the form of "inventory". I don't see how
>> inventory is allowed.
>>
>>
>>
>>    6. Incentives -  What if an RIR has to provide incentives to
>>    motivate the
>>    return address space?  Should the RIR be able to keep blocks
>>    returned for
>>    which incentives were paid?  Should the other RIRs have to
>>    reimburse the
>>    RIR providing the incentive pro-rata shares?  Maybe if an RIR pays
>>    incentives worth more than some amount (say $5,000 for discussion)
>>    then
>>    they keep 50% of the block and must return 50% of the block to  
>> IANA.
>>
>>
>> An RIR would not provide incentives under this policy. The space  
>> would
>> return to the IANA which becomes the disincentive, along with the
>> allocation unit, and the liklihood of a regional requests being
>> stalled en-masse when we "do" have space. Or did.
>>
>> The best way to demonstrate the disparity may be to simply look at  
>> the
>> current utilization statistics[2] provided by the NRO. Fast forward
>> this to the 2010 prediction and imagine that as the size of the
>> "backed up" requests. This demonstrates to me that this policy would
>> not be favorable for any RIR region, IMHO, which is why it may have
>> been proposed.
>>
>> The one other issue that I have is the performance metric reference  
>> in
>> opening section where it states that service performance SLA's are
>> between the IANA and the collective RIR's. Should we take this to  
>> mean
>> the NRO? If that is the case, I'd like to see an additional insertion
>> of a clause that requires public reporting of those metrics as  
>> related
>> to this policy for transparency purposes. It may already be required
>> of the IANA and NRO elsewhere, but I'd like to see it be a  
>> requirement
>> of the NRO as well.
>>
>>
>> 1. This would qualify as a "minor" change under the global PDP and  
>> not
>> materially affect the meaning of the policy, IMHO, and the AC  
>> "should"
>> consider making that change if they forward for consensus, even if
>> just for discussion.
>>
>> 2. NRO aggregated RIR statistics
>> http://www.nro.net/documents/presentations/nro- 
>> jointstats_12-31-08.pdf
>>
>> I'm surprised that this policy made it to last call in APNIC. It  
>> seems
>> that it's bad for them considering that they are currently utilizing
>> IP address space the fastest[2].
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From martin.hannigan at batelnet.bs  Thu Mar 12 00:25:43 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Thu, 12 Mar 2009 00:25:43 -0400
Subject: [arin-ppml] Policy Proposal (Global): Allocation of IPv4 Blocks
	to Regional Internet Registries - Revised
In-Reply-To: <49B85648.1060107@gmail.com>
References: <4607e1d50903101524p51e29b6cna0a5426af2ca722e@mail.gmail.com>
	<2E2FECEBAE57CC4BAACDE67638305F10484CC53766@ROCH-EXCH1.corp.pvt>
	<4607e1d50903110741u2b17f97al9b930781990654b4@mail.gmail.com>
	<49B7E20A.31690.9C90AE4@farmer.umn.edu>
	<4607e1d50903111609j5626014w7cc171c42a850676@mail.gmail.com>
	<49B85648.1060107@gmail.com>
Message-ID: <4607e1d50903112125x32b0c436v85e4e263710d0127@mail.gmail.com>

On Wed, Mar 11, 2009 at 8:24 PM, Scott Leibrand <scottleibrand at gmail.com>wrote:

> Marty,
>
> Thanks for your excellent input here.
>
> I seem to recall that the last time we went through the global PDP (with
> the "last /8" policy), that we had several RIRs who liked the general idea,
> but required substantial changes (namely N=1 instead of 2 or more) to
> support it.  IIRC, some RIRs passed it first with a higher value for N, then
> had to go back and pass the N=1 consensus version after that was what passed
> in the other RIRs.


Correct. That was in fact a result of the differences between the regions. A
contextually similar version was required to be passed and the initial
version was not able to meet that requirement based on regional changes.


>
> I'm wondering if we couldn't do something similar here.  While I think some
> sort of policy along these lines might be beneficial (and we need
> *something* to tell the IANA what to do after IANA free pool exhaustion), I
> think that the policy as written is unworkable, for all the reasons outlined
> by others.


It's perfectly fine if the IANA v4 responsibilities are deprecated at
exhaustion. They will not be going away as a result and not all of their
functions related to v4 would be deprecated. As far as doing something
similiar to the /8 policy you referenced, yes, the AC absolutely could. I
don't know that this is the most efficient way to proceed, all considered.
It looks like the APNIC last call will have concluded before the ARIN region
is able to return feedback/decision to the authors based on a meeting
consesus requirement. If that happens post ARIN meeting, significant changes
require them to start over[1]. If there is a compromise to be made, it's
likely better to make it sooner than later. If the AC has the ability to not
accept the policy now and allow them to resubmit a revision, that may
actually be beneficial to all.


>
>
> So, what if the ARIN AC were to go ahead and revise the policy along the
> lines of what Marla outlined earlier?  Assuming that a less restrictive
> policy is all we'll have consensus for, wouldn't that just mean that APNIC
> would have to pass the less restrictive version as well before it could
> advance to the ASO?


Marla indicated that she thought that the language was fuzzy. I assert that
that the language is not ambigous. You could insert language to make it
voluntary, for example. That would require APNIC to revisit the policy per
their PDP[1].

Best,

Martin


1. That took two years to pass its multiple iterations due to the
differences in the N=X equation. This demonstrates that if the current
policy being discused is passed and then deemed harmful or perhaps illegal,
it will take that long to fix it, or, that long to learn that one RIR
community will hold out and refuse to grant consensus and there will be no
fix.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090312/fed84b08/attachment.htm>

From plzak at arin.net  Thu Mar 12 10:39:35 2009
From: plzak at arin.net (Ray Plzak)
Date: Thu, 12 Mar 2009 10:39:35 -0400
Subject: [arin-ppml] Policy Proposal (Global): Allocation of IPv4 Blocks
 to Regional Internet Registries - Revised
In-Reply-To: <49B85648.1060107@gmail.com>
References: <4607e1d50903101524p51e29b6cna0a5426af2ca722e@mail.gmail.com>
	<2E2FECEBAE57CC4BAACDE67638305F10484CC53766@ROCH-EXCH1.corp.pvt>
	<4607e1d50903110741u2b17f97al9b930781990654b4@mail.gmail.com>
	<49B7E20A.31690.9C90AE4@farmer.umn.edu>
	<4607e1d50903111609j5626014w7cc171c42a850676@mail.gmail.com>
	<49B85648.1060107@gmail.com>
Message-ID: <FEA070315E40A3489D38398C35FE7BB2363FDEB3B3@EDAMAME.arin.net>

Two comments for consideration

1. Version 3 of this policy proposal represents the form that the policy is in after consensus was reached at APNIC. The APNIC community considered version 2 and then modified it resulting in version 3. So it is not unreasonable to expect other RIR communities to do the same thing.

2. According to the current ARIN PDP, the Advisory Council "owns" the proposal in the ARIN region. If the AC decides to present a version at a public policy meeting that is different from that submitted by the authors, the authors may either:

	a. Do nothing
	b. Start a petition to have the version submitted by them considered at the same public policy meeting.

Ray 



-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand
Sent: Wednesday, March 11, 2009 8:25 PM
To: Martin Hannigan
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Policy Proposal (Global): Allocation of IPv4 Blocks to Regional Internet Registries - Revised

Marty,

Thanks for your excellent input here.

I seem to recall that the last time we went through the global PDP (with 
the "last /8" policy), that we had several RIRs who liked the general 
idea, but required substantial changes (namely N=1 instead of 2 or more) 
to support it.  IIRC, some RIRs passed it first with a higher value for 
N, then had to go back and pass the N=1 consensus version after that was 
what passed in the other RIRs.

I'm wondering if we couldn't do something similar here.  While I think 
some sort of policy along these lines might be beneficial (and we need 
*something* to tell the IANA what to do after IANA free pool 
exhaustion), I think that the policy as written is unworkable, for all 
the reasons outlined by others.

So, what if the ARIN AC were to go ahead and revise the policy along the 
lines of what Marla outlined earlier?  Assuming that a less restrictive 
policy is all we'll have consensus for, wouldn't that just mean that 
APNIC would have to pass the less restrictive version as well before it 
could advance to the ASO?

Thanks again,
Scott

Martin Hannigan wrote:
>
>
> On Wed, Mar 11, 2009 at 5:08 PM, David Farmer <farmer at umn.edu 
> <mailto:farmer at umn.edu>> wrote:
>
>     On 11 Mar 2009 Martin Hannigan wrote:
>
>     > Changes that are ok under the global pdp are very minor
>     non-contextual
>     > changes. Changes that would be subject to scrutiny by the ASO AC are
>     > changes that cause a policy to significantly differ from one
>     region to
>     > another. If the AC, for example, fixed some fuzzy language, that
>     could
>     > be enough to significantly change the policy since it could be
>     > interepreted differently vs. a version in another region.
>     >
>     > My suggestion would be that the AC either forward this policy or
>     send
>     > it back to the authors so that they can decide how they want to
>     > proceed, either withdrawing it and starting from scratch or
>     trying to
>     > fix it without a major contextual change.
>
>     Based on your previous post I assume you are not in favor of moving it
>     forward, and would favor sending it back to the authors.
>
>
>
> Agreed.
>  
>
>
>     I believe we should send it back to the authors too, but if we do
>     that and we
>     want them to make changes, rather than just scrap it, I believe it
>     would be a
>     good idea to give them feedback on how we would like to see it
>     changed to
>     as be more suitable to the ARIN community
>
>
> I'm in favor of the discussion. A few points to help explain the 
> global policy pdp. The problem with the AC changing the policy at this 
> juncture is that it's already in last call in the APNIC region. The 
> authors would have some decisions to make if the AC made a significant 
> modification to the document. A global policy must be passed in a 
> contextually similiar form in each RIR region in order for it to be 
> processed and certified by the ASO AC and ICANN BoD as a global 
> policy. I'm not sure how you get a proposal to the floor without the 
> AC moving it forward.
>
> They could instead send their feedback [ours] to the authors and let 
> them decide what to do since the onus of the work should be on the 
> authors considering the complexity of the global pdp and the 
> difficulties in manuevering the policy around the glob?
>
>
>     There are several issues I think we should give them feedback on:
>
>     1.  RIR assigned vs. Legacy Blocks -  It might be be helpful to
>     differentiate
>     between Legacy assignments and RIR assigned /8s.  Like making
>     return of
>     RIR assigned block optional, and Legacy assigned block mandatory.
>
>
> Differentiating creates classes. We see that differientation and the 
> resulting difficulties with creating reasonable, modernized, transfer 
> policy. When you create a class, you almost always end up with an 
> inequity that is uneven and painful. Citizenship vs. non-citizenship, 
> for example.
>
> [ clip ]
>
>
>     5. Need criteria -  an RIR should still have to justify need to
>     get additional
>     address blocks, it is not clear to me that as currently drafted
>     that an RIR
>     would still have to justify its need for any blocks it receives.
>
>
> I believe that there is a typo[1] in the policy. In B.2.c it refers to 
> B.2 as the allocation criteria. The authors may mean to refer to B.3 
> as the allocation criteria reference.
>
> When compared to the B.1.B, holdings eligible for return to the IANA, 
> we seem to have a gap between the allocation criteria and the return 
> of eligible holdings in the form of "inventory". I don't see how 
> inventory is allowed.
>
>
>
>     6. Incentives -  What if an RIR has to provide incentives to
>     motivate the
>     return address space?  Should the RIR be able to keep blocks
>     returned for
>     which incentives were paid?  Should the other RIRs have to
>     reimburse the
>     RIR providing the incentive pro-rata shares?  Maybe if an RIR pays
>     incentives worth more than some amount (say $5,000 for discussion)
>     then
>     they keep 50% of the block and must return 50% of the block to IANA.
>
>
> An RIR would not provide incentives under this policy. The space would 
> return to the IANA which becomes the disincentive, along with the 
> allocation unit, and the liklihood of a regional requests being 
> stalled en-masse when we "do" have space. Or did.
>
> The best way to demonstrate the disparity may be to simply look at the 
> current utilization statistics[2] provided by the NRO. Fast forward 
> this to the 2010 prediction and imagine that as the size of the 
> "backed up" requests. This demonstrates to me that this policy would 
> not be favorable for any RIR region, IMHO, which is why it may have 
> been proposed.
>
> The one other issue that I have is the performance metric reference in 
> opening section where it states that service performance SLA's are 
> between the IANA and the collective RIR's. Should we take this to mean 
> the NRO? If that is the case, I'd like to see an additional insertion 
> of a clause that requires public reporting of those metrics as related 
> to this policy for transparency purposes. It may already be required 
> of the IANA and NRO elsewhere, but I'd like to see it be a requirement 
> of the NRO as well.
>
>
> 1. This would qualify as a "minor" change under the global PDP and not 
> materially affect the meaning of the policy, IMHO, and the AC "should" 
> consider making that change if they forward for consensus, even if 
> just for discussion.
>
> 2. NRO aggregated RIR statistics 
> http://www.nro.net/documents/presentations/nro-jointstats_12-31-08.pdf
>
> I'm surprised that this policy made it to last call in APNIC. It seems 
> that it's bad for them considering that they are currently utilizing 
> IP address space the fastest[2].
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.



From heather.schiller at verizonbusiness.com  Thu Mar 12 13:06:13 2009
From: heather.schiller at verizonbusiness.com (Heather Schiller)
Date: Thu, 12 Mar 2009 13:06:13 -0400
Subject: [arin-ppml] Current policy/process on transfers between RIR's
Message-ID: <49B94105.3020102@verizonbusiness.com>


 From the SIDR working group mailing list:


"Think about corporate acquisitions for a moment.  EngulfAndDevour,
headquartered in region A, buys MomAndPopISP, in region B.
MomAndPopISP is a going concern whose founders want to retire, grow
tomatoes, and deal with no unit of time shorter than a season.
EngulfAndDevour has paid heavily for good will of MomAndPopISP's
customer base and wants MomAndPopISP's routing to continue to work
during transfer of MomAndPopISP's resources from region B to region A.
Any downtime at all is unacceptable.  Hence make-before-break."


Can someone confirm if resources are being transferred between RIR's 
today as part of corporate acquisition/divestitures?  If so, under what 
policy?  Can someone site examples of this being done?  I'm curious as 
to how the records are managed.

Thanks,
--Heather

-- 
====================================================
  Heather Schiller	Verizon Business
  Customer Security	1.800.900.0241
  IP Address Management	help4u at verizonbusiness.com
=====================================================



From info at arin.net  Thu Mar 12 14:04:05 2009
From: info at arin.net (Member Services)
Date: Thu, 12 Mar 2009 14:04:05 -0400
Subject: [arin-ppml] ICANN Ratifies Global Policy: End Policy for IANA IPv4
 allocations to RIRs
Message-ID: <49B94E95.6090607@arin.net>

On 6 March 2009 the ICANN Board of Directors ratified the global policy, 
End Policy for IANA IPv4 allocations to RIRs.

http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm

In the ARIN region, this corresponds to policy 2007-23: End Policy for 
IANA IPv4 allocations to RIRs  (adopted by the ARIN Board of Trustees 20 
June 2008).
 
https://www.arin.net/policy/proposals/2007_23.html


Regards,

Member Services
American Registry for Internet Numbers (ARIN)



From randy at psg.com  Thu Mar 12 14:09:06 2009
From: randy at psg.com (Randy Bush)
Date: Thu, 12 Mar 2009 11:09:06 -0700
Subject: [arin-ppml] Current policy/process on transfers between RIR's
In-Reply-To: <49B94105.3020102@verizonbusiness.com>
References: <49B94105.3020102@verizonbusiness.com>
Message-ID: <m2r612ehq5.wl%randy@psg.com>

>  From the SIDR working group mailing list:
> 
> "Think about corporate acquisitions for a moment.  EngulfAndDevour,
> headquartered in region A, buys MomAndPopISP, in region B.
> MomAndPopISP is a going concern whose founders want to retire, grow
> tomatoes, and deal with no unit of time shorter than a season.
> EngulfAndDevour has paid heavily for good will of MomAndPopISP's
> customer base and wants MomAndPopISP's routing to continue to work
> during transfer of MomAndPopISP's resources from region B to region A.
> Any downtime at all is unacceptable.  Hence make-before-break."
> 
> 
> Can someone confirm if resources are being transferred between RIR's 
> today as part of corporate acquisition/divestitures?  If so, under what 
> policy?  Can someone site examples of this being done?  I'm curious as 
> to how the records are managed.

perhaps technology should not be designed to only fit this week's rir
policies?  

randy, who remembers classful allocation


From michael.dillon at bt.com  Thu Mar 12 14:31:50 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Thu, 12 Mar 2009 18:31:50 -0000
Subject: [arin-ppml] Current policy/process on transfers between RIR's
In-Reply-To: <49B94105.3020102@verizonbusiness.com>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC0BD1A8CE@E03MVZ2-UKDY.domain1.systemhost.net>

> Can someone confirm if resources are being transferred 
> between RIR's today as part of corporate 
> acquisition/divestitures?  If so, under what policy?  Can 
> someone site examples of this being done?  I'm curious as to 
> how the records are managed.

My employer has a global network with all of its addresses sourced from
ARIN. There is a 5 to 7 year transition plan to move all the customers
onto another global network with all of its addresses sourced from RIPE.
The two networks both touch roughly the same cities and until this
quarter, both were growing including adding new PoPs. Now one network is
removing PoPs in fringe areas where the other strategic network has
recently added PoPs. 

We will eventually accomplish the transfer of all customers without
involving the RIRs at all. It's enough work to deal with all the
technical differences between networks, add features to the strategic
network, install various gateways to support transition, and then slowly
start moving customers sometime next year once the new features are
well-tested.

We all must put up with a small amount of RIR bureaucracy in order to
get addresses registered, but it would be wrong to require anyone to
include the RIR bureaucracy in the delicate brain surgery of network
transitions.

I pray that there are no masochists out there who have actually
transferred resources between RIRs, outside of the legacy stuff which
halfway made sense.

--Michael Dillon

P.S. My employer has some other global networks as well with addresses
sourced from ARIN, RIPE, LACNIC and APNIC. I hope we never have to sort
out that situation, just let the IPv6 transition ease us slowly away
from the legacy of acquisitions. Word on the grapevine has it that all
of our major competitors have IPv6 pilot projects underway, some with
customers connected, so there is a good chance that the IPv6 transition
will happen and give everyone the opportunity to sweep aside lots of
legacy cruft from the Internet frontier days.



From martin.hannigan at batelnet.bs  Thu Mar 12 22:01:13 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Thu, 12 Mar 2009 22:01:13 -0400
Subject: [arin-ppml] Policy Proposal (Global): Allocation of IPv4 Blocks
	to Regional Internet Registries - Revised
In-Reply-To: <FEA070315E40A3489D38398C35FE7BB2363FDEB3B3@EDAMAME.arin.net>
References: <4607e1d50903101524p51e29b6cna0a5426af2ca722e@mail.gmail.com>
	<2E2FECEBAE57CC4BAACDE67638305F10484CC53766@ROCH-EXCH1.corp.pvt>
	<4607e1d50903110741u2b17f97al9b930781990654b4@mail.gmail.com>
	<49B7E20A.31690.9C90AE4@farmer.umn.edu>
	<4607e1d50903111609j5626014w7cc171c42a850676@mail.gmail.com>
	<49B85648.1060107@gmail.com>
	<FEA070315E40A3489D38398C35FE7BB2363FDEB3B3@EDAMAME.arin.net>
Message-ID: <4607e1d50903121901j7798a243i1f13fd283a2ff81c@mail.gmail.com>

The ARIN AC also has the option to do nothing. There is no requirement to
forward a global policy to the meeting for consensus, unedited or otherwise,
in any portion of the global pdp or ICANN bylaws. In the spirit of
cooperation, it would be fair to provide feedback to the authors, but that
need not be through the far end of the process. In all fairness, the authors
do have the petition process to fallback on if they disagree with the
outcome.

Best,

Martin



On Thu, Mar 12, 2009 at 10:39 AM, Ray Plzak <plzak at arin.net> wrote:

> Two comments for consideration
>
> 1. Version 3 of this policy proposal represents the form that the policy is
> in after consensus was reached at APNIC. The APNIC community considered
> version 2 and then modified it resulting in version 3. So it is not
> unreasonable to expect other RIR communities to do the same thing.
>
> 2. According to the current ARIN PDP, the Advisory Council "owns" the
> proposal in the ARIN region. If the AC decides to present a version at a
> public policy meeting that is different from that submitted by the authors,
> the authors may either:
>
>        a. Do nothing
>        b. Start a petition to have the version submitted by them considered
> at the same public policy meeting.
>
> Ray
>
>
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Scott Leibrand
> Sent: Wednesday, March 11, 2009 8:25 PM
> To: Martin Hannigan
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal (Global): Allocation of IPv4
> Blocks to Regional Internet Registries - Revised
>
> Marty,
>
> Thanks for your excellent input here.
>
> I seem to recall that the last time we went through the global PDP (with
> the "last /8" policy), that we had several RIRs who liked the general
> idea, but required substantial changes (namely N=1 instead of 2 or more)
> to support it.  IIRC, some RIRs passed it first with a higher value for
> N, then had to go back and pass the N=1 consensus version after that was
> what passed in the other RIRs.
>
> I'm wondering if we couldn't do something similar here.  While I think
> some sort of policy along these lines might be beneficial (and we need
> *something* to tell the IANA what to do after IANA free pool
> exhaustion), I think that the policy as written is unworkable, for all
> the reasons outlined by others.
>
> So, what if the ARIN AC were to go ahead and revise the policy along the
> lines of what Marla outlined earlier?  Assuming that a less restrictive
> policy is all we'll have consensus for, wouldn't that just mean that
> APNIC would have to pass the less restrictive version as well before it
> could advance to the ASO?
>
> Thanks again,
> Scott
>
> Martin Hannigan wrote:
> >
> >
> > On Wed, Mar 11, 2009 at 5:08 PM, David Farmer <farmer at umn.edu
> > <mailto:farmer at umn.edu>> wrote:
> >
> >     On 11 Mar 2009 Martin Hannigan wrote:
> >
> >     > Changes that are ok under the global pdp are very minor
> >     non-contextual
> >     > changes. Changes that would be subject to scrutiny by the ASO AC
> are
> >     > changes that cause a policy to significantly differ from one
> >     region to
> >     > another. If the AC, for example, fixed some fuzzy language, that
> >     could
> >     > be enough to significantly change the policy since it could be
> >     > interepreted differently vs. a version in another region.
> >     >
> >     > My suggestion would be that the AC either forward this policy or
> >     send
> >     > it back to the authors so that they can decide how they want to
> >     > proceed, either withdrawing it and starting from scratch or
> >     trying to
> >     > fix it without a major contextual change.
> >
> >     Based on your previous post I assume you are not in favor of moving
> it
> >     forward, and would favor sending it back to the authors.
> >
> >
> >
> > Agreed.
> >
> >
> >
> >     I believe we should send it back to the authors too, but if we do
> >     that and we
> >     want them to make changes, rather than just scrap it, I believe it
> >     would be a
> >     good idea to give them feedback on how we would like to see it
> >     changed to
> >     as be more suitable to the ARIN community
> >
> >
> > I'm in favor of the discussion. A few points to help explain the
> > global policy pdp. The problem with the AC changing the policy at this
> > juncture is that it's already in last call in the APNIC region. The
> > authors would have some decisions to make if the AC made a significant
> > modification to the document. A global policy must be passed in a
> > contextually similiar form in each RIR region in order for it to be
> > processed and certified by the ASO AC and ICANN BoD as a global
> > policy. I'm not sure how you get a proposal to the floor without the
> > AC moving it forward.
> >
> > They could instead send their feedback [ours] to the authors and let
> > them decide what to do since the onus of the work should be on the
> > authors considering the complexity of the global pdp and the
> > difficulties in manuevering the policy around the glob?
> >
> >
> >     There are several issues I think we should give them feedback on:
> >
> >     1.  RIR assigned vs. Legacy Blocks -  It might be be helpful to
> >     differentiate
> >     between Legacy assignments and RIR assigned /8s.  Like making
> >     return of
> >     RIR assigned block optional, and Legacy assigned block mandatory.
> >
> >
> > Differentiating creates classes. We see that differientation and the
> > resulting difficulties with creating reasonable, modernized, transfer
> > policy. When you create a class, you almost always end up with an
> > inequity that is uneven and painful. Citizenship vs. non-citizenship,
> > for example.
> >
> > [ clip ]
> >
> >
> >     5. Need criteria -  an RIR should still have to justify need to
> >     get additional
> >     address blocks, it is not clear to me that as currently drafted
> >     that an RIR
> >     would still have to justify its need for any blocks it receives.
> >
> >
> > I believe that there is a typo[1] in the policy. In B.2.c it refers to
> > B.2 as the allocation criteria. The authors may mean to refer to B.3
> > as the allocation criteria reference.
> >
> > When compared to the B.1.B, holdings eligible for return to the IANA,
> > we seem to have a gap between the allocation criteria and the return
> > of eligible holdings in the form of "inventory". I don't see how
> > inventory is allowed.
> >
> >
> >
> >     6. Incentives -  What if an RIR has to provide incentives to
> >     motivate the
> >     return address space?  Should the RIR be able to keep blocks
> >     returned for
> >     which incentives were paid?  Should the other RIRs have to
> >     reimburse the
> >     RIR providing the incentive pro-rata shares?  Maybe if an RIR pays
> >     incentives worth more than some amount (say $5,000 for discussion)
> >     then
> >     they keep 50% of the block and must return 50% of the block to IANA.
> >
> >
> > An RIR would not provide incentives under this policy. The space would
> > return to the IANA which becomes the disincentive, along with the
> > allocation unit, and the liklihood of a regional requests being
> > stalled en-masse when we "do" have space. Or did.
> >
> > The best way to demonstrate the disparity may be to simply look at the
> > current utilization statistics[2] provided by the NRO. Fast forward
> > this to the 2010 prediction and imagine that as the size of the
> > "backed up" requests. This demonstrates to me that this policy would
> > not be favorable for any RIR region, IMHO, which is why it may have
> > been proposed.
> >
> > The one other issue that I have is the performance metric reference in
> > opening section where it states that service performance SLA's are
> > between the IANA and the collective RIR's. Should we take this to mean
> > the NRO? If that is the case, I'd like to see an additional insertion
> > of a clause that requires public reporting of those metrics as related
> > to this policy for transparency purposes. It may already be required
> > of the IANA and NRO elsewhere, but I'd like to see it be a requirement
> > of the NRO as well.
> >
> >
> > 1. This would qualify as a "minor" change under the global PDP and not
> > materially affect the meaning of the policy, IMHO, and the AC "should"
> > consider making that change if they forward for consensus, even if
> > just for discussion.
> >
> > 2. NRO aggregated RIR statistics
> > http://www.nro.net/documents/presentations/nro-jointstats_12-31-08.pdf
> >
> > I'm surprised that this policy made it to last call in APNIC. It seems
> > that it's bad for them considering that they are currently utilizing
> > IP address space the fastest[2].
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090312/d261cde0/attachment.htm>

From farmer at umn.edu  Mon Mar 16 10:51:03 2009
From: farmer at umn.edu (David Farmer)
Date: Mon, 16 Mar 2009 09:51:03 -0500
Subject: [arin-ppml] Policy Proposal: Protective Usage Transfer Policy
	for IPv4 Address - Revised
In-Reply-To: <49B03D9B.9070103@arin.net>
References: <49B03D9B.9070103@arin.net>
Message-ID: <49BE2107.556.17A4E002@farmer.umn.edu>

I'd be interested if this revision has changed anyone's mind or answered any 
questions for anyone.

Personally, I believe this only really answered one of my questions included 
below.  I've included a few additional comments in line;

On 11 Feb 2009 David Farmer wrote:

> I would like to bring us back to the text of the proposal for a 
> moment.
> 
> Could the Author or one on the supporters of this please clearify 
> or comment on a few issues for me;
> 
> 1.  What is the remedy you would seek from ARIN in this 
> Appeal of the Transfer?
> 
>       A. An extended delay in execution of the transfer.  If so
>       how long?
> 
>       B. ARIN to assign the block in question directly to the
>       Critical Infrastructure Provider?

It is still unclear to me what remedy you are seeking from ARIN.  I believe 
that this has to be clarified.  I think some kind of delay is about the most I 
could personally support, a reassignment would create a very bad precedent, 
more below;
 
> 2.  What do you mean by "for consecutive periods of time".  I 
> think you intend that the CI Provider should have been using 
> the address block for an extended time period.  So, how long 
> should the addresses have been in use to qualify?

Thank you, this has been clarified, five years.  But please realize that there 
are many end-users that have been using address space for five years or 
more.

> 3.  Who within ARIN should be responsible to hear the appeal?  
> Staff, the Board, a 3rd party arbiter (how would you pick the 
> arbiter), a vote at a member meeting?

I think you intend this to be ARIN Staff, but I think this still needs to be 
clarified.

> 4. Do the CI Providers need to have a relationship with ARIN 
> already?

I'm still concerned about this.

> 5. Have you thought about legal issues like indemnification, will the
> CI Providers have to defend ARIN from law suits and pay any settlement
> to the parties to the transfer?

I'm still concerned about this, too

> 6. How could ARIN possibly defend itself against all the end-
> users in this very same situation if we did this for the CI 
> Providers.  This is a very slippery slope.

I am concerned that this sends the message that renumbering is "TO  
HARD" even for companies in the business of providing network 
infrastructure, with staffs of network professionals, especially if we were to 
allow reassignment.  If we allow CI Providers an exception from 
renumbering, how do we as an industry justify requiring most end-users to 
renumber?  

Below in the rational it says "interfere with the continuous and seamless 
operation of that critical infrastructure or hardship to the provider."  
Unfortunately I believe this is double speak for renumbering, unless you can 
explain how else a transfer would "interfere".

I could maybe support this if renumbering were explicitly defined and not 
interfering or creating a hardship.

I'll add another issue;

7. I believe the text also seems to put the presumption in favor of the CI 
provider, why shouldn't the CI provider have to prove harm first, rather than 
the transferee prove that the transfer is justified.  

> All of these things would have to be dealt with for this proposal to
> make all the way into becoming a policy.  Is it worth it?  Are there
> ways around these issues? 

I would like to see those that support this policy address these issues.

On 5 Mar 2009 Member Services wrote:

> Policy Proposal
> Protective Usage Transfer Policy for IPv4 Address
> 
> The proposal originator submitted a revised version of the proposal.
> 
> The AC will review this proposal at their next regularly scheduled
> meeting and decide how to utilize the proposal. Their decision will be
> announced to the PPML.
> 
> In the meantime, the AC invites everyone to comment on this proposal
> on the PPML, particularly their support or non-support and the
> reasoning behind their opinion. Such participation contributes to a
> thorough vetting and provides important guidance to the AC in their
> deliberations.
> 
> The ARIN Policy Development Process can be found at:
> http://www.arin.net/policy/pdp.html
> 
> Mailing list subscription information can be found at:
> http://www.arin.net/mailing_lists/
> 
> Regards,
> 
> Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> #####
> 
> 
> Policy Proposal Name: Protective Usage Transfer Policy for IPv4
> Address
> 
> Proposal Originator : Christopher A. Quesada
> 
> Proposal Version: 2
> 
> Date: 5 March 2009
> 
> Policy statement:
> 
> Critical infrastructure providers may appeal to ARIN for final review
> and approval of any full or partial transfer of IPv4 address space
> that has been in use by the critical infrastructure serving the
> community for five consecutive years or more.  Such appeal may result
> in a partial or full approval of the requested transfer, or rejection
> of the transfer if it lacks appropriate rationale, justification, or
> interferes with the seamless operation of such critical infrastructure
> or hardship to the provider.
> 
> Rationale:
> Protection of critical infrastructure providers of the Internet,
> including public exchange points, core DNS service providers (e.g.
> ICANN-sanctioned root, gTLD, and ccTLD operators) as well as the RIRs
> and IANA is necessary in order to ensure the continuous operation of
> the Internet for its global service community.  It is possible for an
> organization to transfer an aggregate IPv4 address resource containing
> allocations/assignments downstream supporting critical infrastructure
> (as defined in ARIN?s Number Resource Policy Manual).  This policy is
> intended to protect that critical infrastructure by allowing for the
> review and final approval of such transfer by ARIN, upon appeal by the
> critical infrastructure provider to ARIN, within a sixty day period of
> the transfer notification if such transfer would interfere with the
> continuous and seamless operation of that critical infrastructure or
> hardship to the provider.  Review of the transfer can consist of a
> request by ARIN to the transferring organization for a rationale for
> such transfer.  This may include but not be limited to, a requirement
> for the receiving party to submit the appropriate network request form
> identifying the need and justification for the aggregate IPv4 address
> resource.
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



=======================================================
David Farmer				     Email:	farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota			     Phone:	612-626-0815
2218 University Ave SE			     Cell:		612-812-9952
Minneapolis, MN 55414-3029		     FAX:	612-626-1818
=======================================================



From kkargel at polartel.com  Mon Mar 16 11:29:46 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 16 Mar 2009 10:29:46 -0500
Subject: [arin-ppml] Policy Proposal: Protective Usage Transfer
	Policyfor IPv4 Address - Revised
In-Reply-To: <49BE2107.556.17A4E002@farmer.umn.edu>
References: <49B03D9B.9070103@arin.net> <49BE2107.556.17A4E002@farmer.umn.edu>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AEC5@mail>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of David Farmer
> Sent: Monday, March 16, 2009 9:51 AM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal: Protective Usage Transfer
> Policyfor IPv4 Address - Revised
> 
> I'd be interested if this revision has changed anyone's mind or answered
> any
> questions for anyone.
> 
It has not changed my mind.  I am still opposed.  There are adequate
remedies in place and adequate time to take advantage of them.  I see no
need for this policy.

Kevin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090316/ba389784/attachment.bin>

From martin.hannigan at batelnet.bs  Mon Mar 16 12:10:10 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Mon, 16 Mar 2009 12:10:10 -0400
Subject: [arin-ppml] Policy Proposal: Protective Usage Transfer Policy
	for IPv4 Address - Revised
In-Reply-To: <49BE2107.556.17A4E002@farmer.umn.edu>
References: <49B03D9B.9070103@arin.net> <49BE2107.556.17A4E002@farmer.umn.edu>
Message-ID: <4607e1d50903160910x6d6f2673x7923cbdbc55557ac@mail.gmail.com>

This is one of many canary in a coal mine scenarios that will arise as
we march towards exhaustion and v4 resources monetary value continues
to increase.

If we were able to disconnect resource recovery from the transfer
discussion we might be able to make some progress.

Still, I support the concept, but neutral on this specific policy proposal.


Best,

Martin

On 3/16/09, David Farmer <farmer at umn.edu> wrote:
> I'd be interested if this revision has changed anyone's mind or answered any
> questions for anyone.
>
> Personally, I believe this only really answered one of my questions included
> below.  I've included a few additional comments in line;
>
> On 11 Feb 2009 David Farmer wrote:
>
>> I would like to bring us back to the text of the proposal for a
>> moment.
>>
>> Could the Author or one on the supporters of this please clearify
>> or comment on a few issues for me;
>>
>> 1.  What is the remedy you would seek from ARIN in this
>> Appeal of the Transfer?
>>
>>       A. An extended delay in execution of the transfer.  If so
>>       how long?
>>
>>       B. ARIN to assign the block in question directly to the
>>       Critical Infrastructure Provider?
>
> It is still unclear to me what remedy you are seeking from ARIN.  I believe
> that this has to be clarified.  I think some kind of delay is about the most
> I
> could personally support, a reassignment would create a very bad precedent,
> more below;
>
>> 2.  What do you mean by "for consecutive periods of time".  I
>> think you intend that the CI Provider should have been using
>> the address block for an extended time period.  So, how long
>> should the addresses have been in use to qualify?
>
> Thank you, this has been clarified, five years.  But please realize that
> there
> are many end-users that have been using address space for five years or
> more.
>
>> 3.  Who within ARIN should be responsible to hear the appeal?
>> Staff, the Board, a 3rd party arbiter (how would you pick the
>> arbiter), a vote at a member meeting?
>
> I think you intend this to be ARIN Staff, but I think this still needs to be
> clarified.
>
>> 4. Do the CI Providers need to have a relationship with ARIN
>> already?
>
> I'm still concerned about this.
>
>> 5. Have you thought about legal issues like indemnification, will the
>> CI Providers have to defend ARIN from law suits and pay any settlement
>> to the parties to the transfer?
>
> I'm still concerned about this, too
>
>> 6. How could ARIN possibly defend itself against all the end-
>> users in this very same situation if we did this for the CI
>> Providers.  This is a very slippery slope.
>
> I am concerned that this sends the message that renumbering is "TO
> HARD" even for companies in the business of providing network
> infrastructure, with staffs of network professionals, especially if we were
> to
> allow reassignment.  If we allow CI Providers an exception from
> renumbering, how do we as an industry justify requiring most end-users to
> renumber?
>
> Below in the rational it says "interfere with the continuous and seamless
> operation of that critical infrastructure or hardship to the provider."
> Unfortunately I believe this is double speak for renumbering, unless you can
> explain how else a transfer would "interfere".
>
> I could maybe support this if renumbering were explicitly defined and not
> interfering or creating a hardship.
>
> I'll add another issue;
>
> 7. I believe the text also seems to put the presumption in favor of the CI
> provider, why shouldn't the CI provider have to prove harm first, rather
> than
> the transferee prove that the transfer is justified.
>
>> All of these things would have to be dealt with for this proposal to
>> make all the way into becoming a policy.  Is it worth it?  Are there
>> ways around these issues?
>
> I would like to see those that support this policy address these issues.
>
> On 5 Mar 2009 Member Services wrote:
>
>> Policy Proposal
>> Protective Usage Transfer Policy for IPv4 Address
>>
>> The proposal originator submitted a revised version of the proposal.
>>
>> The AC will review this proposal at their next regularly scheduled
>> meeting and decide how to utilize the proposal. Their decision will be
>> announced to the PPML.
>>
>> In the meantime, the AC invites everyone to comment on this proposal
>> on the PPML, particularly their support or non-support and the
>> reasoning behind their opinion. Such participation contributes to a
>> thorough vetting and provides important guidance to the AC in their
>> deliberations.
>>
>> The ARIN Policy Development Process can be found at:
>> http://www.arin.net/policy/pdp.html
>>
>> Mailing list subscription information can be found at:
>> http://www.arin.net/mailing_lists/
>>
>> Regards,
>>
>> Member Services
>> American Registry for Internet Numbers (ARIN)
>>
>>
>> #####
>>
>>
>> Policy Proposal Name: Protective Usage Transfer Policy for IPv4
>> Address
>>
>> Proposal Originator : Christopher A. Quesada
>>
>> Proposal Version: 2
>>
>> Date: 5 March 2009
>>
>> Policy statement:
>>
>> Critical infrastructure providers may appeal to ARIN for final review
>> and approval of any full or partial transfer of IPv4 address space
>> that has been in use by the critical infrastructure serving the
>> community for five consecutive years or more.  Such appeal may result
>> in a partial or full approval of the requested transfer, or rejection
>> of the transfer if it lacks appropriate rationale, justification, or
>> interferes with the seamless operation of such critical infrastructure
>> or hardship to the provider.
>>
>> Rationale:
>> Protection of critical infrastructure providers of the Internet,
>> including public exchange points, core DNS service providers (e.g.
>> ICANN-sanctioned root, gTLD, and ccTLD operators) as well as the RIRs
>> and IANA is necessary in order to ensure the continuous operation of
>> the Internet for its global service community.  It is possible for an
>> organization to transfer an aggregate IPv4 address resource containing
>> allocations/assignments downstream supporting critical infrastructure
>> (as defined in ARIN?s Number Resource Policy Manual).  This policy is
>> intended to protect that critical infrastructure by allowing for the
>> review and final approval of such transfer by ARIN, upon appeal by the
>> critical infrastructure provider to ARIN, within a sixty day period of
>> the transfer notification if such transfer would interfere with the
>> continuous and seamless operation of that critical infrastructure or
>> hardship to the provider.  Review of the transfer can consist of a
>> request by ARIN to the transferring organization for a rationale for
>> such transfer.  This may include but not be limited to, a requirement
>> for the receiving party to submit the appropriate network request form
>> identifying the need and justification for the aggregate IPv4 address
>> resource.
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>
>
>
> =======================================================
> David Farmer				     Email:	farmer at umn.edu
> Office of Information Technology
> Networking & Telecomunication Services
> University of Minnesota			     Phone:	612-626-0815
> 2218 University Ave SE			     Cell:		612-812-9952
> Minneapolis, MN 55414-3029		     FAX:	612-626-1818
> =======================================================
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>


From heather.schiller at verizonbusiness.com  Tue Mar 17 19:16:13 2009
From: heather.schiller at verizonbusiness.com (Heather Schiller)
Date: Tue, 17 Mar 2009 19:16:13 -0400
Subject: [arin-ppml] Policy Proposal: Protective Usage Transfer Policy
 for IPv4 Address - Revised
In-Reply-To: <49B03D9B.9070103@arin.net>
References: <49B03D9B.9070103@arin.net>
Message-ID: <49C02F3D.6030801@verizonbusiness.com>


I think that this text could use some clarification.. Here are my 
questions/concerns:

1) This policy allows a reassignment holder to appeal to ARIN if/when 
the direct allocation holder applies for a transfer?   or does it allow 
someone to appeal to ARIN to convert/transfer the assignment anytime 
after it's been in use for 5 years?


2) who is the 'provider' in the text?  The direct allocation holder? the 
reassignment holder?


3) Also, it seem the text isn't clear that this refers only to CI space 
- the micro-allocations for exchange points or for critical 
infrastructure.   ARIN maintains a list of these netblocks:

https://www.arin.net/knowledge/micro_allocations.html

The text appears to refer to anything that might be CI regardless of 
*where* it is assigned from, which in theory, could include a PA or PI 
block.  Is that the intent?

4) Who is authorized to make an appeal?  Presumably an organization that 
has an assignment in the resource that is up for transfer?  But how do 
you verify that?  I'm spot checking the list of micro-allocations - Most 
appear to be allocations, which allow for reassignments, but so far, 
none have reassignment information.  One way to verify how long a 
reassignment has been in use for that 5 year figure would be to check 
the date on the reassignment.

5) Is the goal to delay the transfer to allow the subdelegation holders 
more time to renumber?  or to put a kabash on the whole transfer or..? 
how do you make someone hold onto space when they don't want to?

  Here were the outcome scenarios outlined in the text:

  partial approval of transfer: what happens to the space that isn't 
approved for transfer?  does it get returned to ARIN? reallocated? or?

  full approval of transfer: gets fully transferred to new org

  rejection of transfer: ?? seems the most bizarre.. what happens here? 
  who is responsible for the space?  If a company or organization 
dissolves or merges with another.. someone has to be responsible for the 
space?

6) What are the valid arguments for an appeal?  What rights does the 
direct allocation holder have in this appeals process?  If they can 
demonstrate that they have provided ample warning and time to renumber 
as recommended in the NRPM, does the organization making an appeal still 
have grounds to appeal?  What role do contracts between the direct 
allocation holder and the reassignment holder play in the appeals 
process?  Should ARIN consider those contracts as part of the appeal? 
Are you asking ARIN to intercede in something that maybe should be 
played out in court?

--Heather

====================================================
  Heather Schiller	Verizon Business
  Customer Security	1.800.900.0241
  IP Address Management	help4u at verizonbusiness.com
=====================================================


Member Services wrote:
> Policy Proposal
> Protective Usage Transfer Policy for IPv4 Address
> 
> The proposal originator submitted a revised version of the proposal.
> 
> The AC will review this proposal at their next regularly scheduled
> meeting and decide how to utilize the proposal. Their decision will be
> announced to the PPML.
> 
> In the meantime, the AC invites everyone to comment on this proposal on
> the PPML, particularly their support or non-support and the reasoning
> behind their opinion. Such participation contributes to a thorough
> vetting and provides important guidance to the AC in their deliberations.
> 
> The ARIN Policy Development Process can be found at:
> http://www.arin.net/policy/pdp.html
> 
> Mailing list subscription information can be found at:
> http://www.arin.net/mailing_lists/
> 
> Regards,
> 
> Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> #####
> 
> 
> Policy Proposal Name: Protective Usage Transfer Policy for IPv4 Address
> 
> Proposal Originator : Christopher A. Quesada
> 
> Proposal Version: 2
> 
> Date: 5 March 2009
> 
> Policy statement:
> 
> Critical infrastructure providers may appeal to ARIN for final review
> and approval of any full or partial transfer of IPv4 address space that
> has been in use by the critical infrastructure serving the community for
> five consecutive years or more.  Such appeal may result in a partial or
> full approval of the requested transfer, or rejection of the transfer if
> it lacks appropriate rationale, justification, or interferes with the
> seamless operation of such critical infrastructure or hardship to the
> provider.
> 
> Rationale:
> Protection of critical infrastructure providers of the Internet,
> including public exchange points, core DNS service providers (e.g.
> ICANN-sanctioned root, gTLD, and ccTLD operators) as well as the RIRs
> and IANA is necessary in order to ensure the continuous operation of the
> Internet for its global service community.  It is possible for an
> organization to transfer an aggregate IPv4 address resource containing
> allocations/assignments downstream supporting critical infrastructure
> (as defined in ARIN?s Number Resource Policy Manual).  This policy is
> intended to protect that critical infrastructure by allowing for the
> review and final approval of such transfer by ARIN, upon appeal by the
> critical infrastructure provider to ARIN, within a sixty day period of
> the transfer notification if such transfer would interfere with the
> continuous and seamless operation of that critical infrastructure or
> hardship to the provider.  Review of the transfer can consist of a
> request by ARIN to the transferring organization for a rationale for
> such transfer.  This may include but not be limited to, a requirement
> for the receiving party to submit the appropriate network request form
> identifying the need and justification for the aggregate IPv4 address
> resource.
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 




From farmer at umn.edu  Wed Mar 18 10:06:53 2009
From: farmer at umn.edu (David Farmer)
Date: Wed, 18 Mar 2009 09:06:53 -0500
Subject: [arin-ppml] Policy Proposal (Global): Allocation of IPv4 Blocks
	to Regional Internet Registries - Revised
In-Reply-To: <4607e1d50903111609j5626014w7cc171c42a850676@mail.gmail.com>
References: <4607e1d50903101524p51e29b6cna0a5426af2ca722e@mail.gmail.com>,
	<49B7E20A.31690.9C90AE4@farmer.umn.edu>,
	<4607e1d50903111609j5626014w7cc171c42a850676@mail.gmail.com>
Message-ID: <49C0B9AD.19704.84A951A@farmer.umn.edu>

On 11 Mar 2009 Martin Hannigan wrote:

> On Wed, Mar 11, 2009 at 5:08 PM, David Farmer <farmer at umn.edu> wrote:

[ clip ]

> > There are several issues I think we should give them feedback on:
> >
> > 1.  RIR assigned vs. Legacy Blocks -  It might be be helpful to
> > differentiate between Legacy assignments and RIR assigned /8s.  Like
> > making return of RIR assigned block optional, and Legacy assigned
> > block mandatory.
> 
> Differentiating creates classes. We see that differientation and the
> resulting difficulties with creating reasonable, modernized, transfer
> policy. When you create a class, you almost always end up with an
> inequity that is uneven and painful. Citizenship vs. non-citizenship,
> for example.

I think I agree with you on this one, but this is one change that has been 
talked about.

> [ clip ]
> 
> 
> > 5. Need criteria -  an RIR should still have to justify need to get
> > additional address blocks, it is not clear to me that as currently
> > drafted that an RIR would still have to justify its need for any
> > blocks it receives.
> 
> 
> I believe that there is a typo[1] in the policy. In B.2.c it refers to
> B.2 as the allocation criteria. The authors may mean to refer to B.3
> as the allocation criteria reference.
> 
> When compared to the B.1.B, holdings eligible for return to the IANA,
> we seem to have a gap between the allocation criteria and the return
> of eligible holdings in the form of "inventory". I don't see how
> inventory is allowed.

I think you are correct about the typo.  But, beyond that I believe that 
something along the lines of the current global policies 3.2 (10.1.3.2 in ARIN 
NPRM) "Calculation of NECESSARY SPACE" in needed in addition to what 
is in B.3 of the proposed policy.  An RIR should have to demonstrate that it 
needs what it is eligible to receive too.  

If you assume that we will never recover much address space then there will 
probably never be enough address space to meet the needs of even one of 
the RIRs.  But it could still be possible for the criteria in the proposed B.3 to 
be meet, but that the RIR in questions has more address space than it 
needs.  In no situation should an RIR be able receive address that it can't 
justify need, especially if other RIRs can justify need.    
 
> > 6. Incentives -  What if an RIR has to provide incentives to
> > motivate the return address space?  Should the RIR be able to keep
> > blocks returned for which incentives were paid?  Should the other
> > RIRs have to reimburse the RIR providing the incentive pro-rata
> > shares?  Maybe if an RIR pays incentives worth more than some amount
> > (say $5,000 for discussion) then they keep 50% of the block and must
> > return 50% of the block to IANA.
> >
> 
> An RIR would not provide incentives under this policy. The space would
> return to the IANA which becomes the disincentive, along with the
> allocation unit, and the liklihood of a regional requests being
> stalled en-masse when we "do" have space. Or did.

Actually, this is a bigger problem than I was originally thinking, the recovery 
of address space, by what even means has associated expenses.  Even, if 
the recovery is for non-payment, non-use, or abandonment, there can still be 
considerable administrative expenses associated with the recovery of 
address space.  And, that is without even talking about incentives.

If an RIR has to take on expenses to recover address space locally, but then 
likely only retain 20% of the benefit of those expenses locally, and have 80% 
of the benefit go globally elsewhere;  How is an RIR to justify those expenses 
locally to it membership?  

With 100% of the expenses kept locally, but only 20% of the benefit kept 
locally, this creates a serious imbalance between an RIRs local and global 
responsibilities.

I propose that an RIR be able to keep up to 50% of the address space it 
recovers each quarter, and return a minimum of 50% to IANA.  In this 
proposal, an RIR is likely to see 60% of the benefit of the recovery expenses 
retained locally with only 40% of the benefit going globally elsewhere.  

With 100% of the expenses kept locally, but 60% of the benefit kept locally 
too, this would bring an RIRs local and global responsibilities into a much 
better balance.  

I propose the following change in language in section A of this proposal, "At 
quarterly intervals, each RIR shall return a minimum of 50% of any such 
recovered address space to the IANA in aggregate blocks of /24 or larger, for 
inclusion in the recovered IPv4 pool."

By requiring a minimum of 50% be returned, but allowing an RIR to return 
more, each RIR is able to tune the balance of its local and global 
responsibilities as conditions dictate. 

Further, with a needs requirement included in B.3s Allocation Criteria, like I 
talk about above, if an RIR is recovering more address space than it needs 
then the global benefit would go up to at least 50%.  In other words if an RIR 
is recovering more space than it needs it cannot get address space from 
IANA too.   

Otherwise, there would need to be some kind of mechanism for the RIRs to 
share these recovery expenses globally.  And I believe having the RIRs 
exchange money will create all kinds of nasty issues, that I don't even want 
to think about.

What do you think?

> The best way to demonstrate the disparity may be to simply look at the
> current utilization statistics[2] provided by the NRO. Fast forward
> this to the 2010 prediction and imagine that as the size of the
> "backed up" requests. This demonstrates to me that this policy would
> not be favorable for any RIR region, IMHO, which is why it may have
> been proposed.

I agree there are global inequities, but creating an inequity between each 
RIRs local and global responsibilities will not fix that.  If fact it could make it 
worse.

> The one other issue that I have is the performance metric reference in
> opening section where it states that service performance SLA's are
> between the IANA and the collective RIR's. Should we take this to mean
> the NRO? If that is the case, I'd like to see an additional insertion
> of a clause that requires public reporting of those metrics as related
> to this policy for transparency purposes. It may already be required
> of the IANA and NRO elsewhere, but I'd like to see it be a requirement
> of the NRO as well.
> 
> 
> 1. This would qualify as a "minor" change under the global PDP and not
> materially affect the meaning of the policy, IMHO, and the AC "should"
> consider making that change if they forward for consensus, even if
> just for discussion.
> 
> 2. NRO aggregated RIR statistics
> http://www.nro.net/documents/presentations/nro-jointstats_12-31-08.pdf
> 
> I'm surprised that this policy made it to last call in APNIC. It seems
> that it's bad for them considering that they are currently utilizing
> IP address space the fastest[2].

Yes, this is more than a minor change, but without something like this I can't 
see ARIN getting consensus for the policy

What do you think?

=======================================================
David Farmer				     Email:	farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota			     Phone:	612-626-0815
2218 University Ave SE			     Cell:		612-812-9952
Minneapolis, MN 55414-3029		     FAX:	612-626-1818
=======================================================



From info at arin.net  Wed Mar 18 14:46:04 2009
From: info at arin.net (Member Services)
Date: Wed, 18 Mar 2009 14:46:04 -0400
Subject: [arin-ppml] Policy Proposal: IPv6 Multiple Discrete Networks
Message-ID: <49C1416C.9070203@arin.net>

ARIN received the following policy proposal and is posting it to the 
Public Policy Mailing List (PPML) in accordance with Policy Development 
Process.

This proposal is in the first stage of the Policy Development Process. 
ARIN staff will perform the Clarity and Understanding step. Staff does 
not evaluate the proposal at this time, their goal is to make sure that 
they understand the proposal and believe the community will as well. 
Staff will report their results to the ARIN Advisory Council (AC) within 
10 days.

The AC will review the proposal at their next regularly scheduled
meeting (if the period before the next regularly scheduled meeting is
less than 10 days, then the period may be extended to the subsequent
regularly scheduled meeting). The AC will decide how to utilize the
proposal and announce the decision to the PPML.

In the meantime, the AC invites everyone to comment on the proposal on
the PPML, particularly their support or non-support and the reasoning
behind their opinion. Such participation contributes to a thorough
vetting and provides important guidance to the AC in their deliberations.

The ARIN Policy Development Process can be found at:
http://www.arin.net/policy/pdp.html

Mailing list subscription information can be found at:
http://www.arin.net/mailing_lists/

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##

Policy Proposal Name: IPv6 Multiple Discrete Networks

Proposal Originator: David Divins

Proposal Version: 1

Date: 3/17/2009

Proposal type: Add

Policy term: Permanent

Policy statement:

Organizations with multiple discrete IPv6 networks desiring to request
new or additional address space under a single Organization ID must meet
the following criteria:

      1. The organization shall be a single entity and not a consortium
of smaller independent entities.

      2. The organization must have compelling criteria for creating
discrete networks. Examples of a discrete network might include:

            1. Regulatory restrictions for data transmission,

            2. Geographic distance and diversity between networks,

            3. Autonomous multihomed discrete networks.

      3. The organization must keep detailed records on how it has
allocated space to each location, including the date of each allocation.

      4. The organization should notify ARIN at the time of the request
their desire to apply this policy to their account.

Rationale:

This proposed policy is suggested as NRPM 6.11.  The policy is intended
to provide parity between current IPv4 policy and allow discrete network
operators to obtain IPv6 space.

Timetable for implementation: Immediately







From martin.hannigan at batelnet.bs  Wed Mar 18 15:33:03 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Wed, 18 Mar 2009 15:33:03 -0400
Subject: [arin-ppml] Policy Proposal (Global): Allocation of IPv4 Blocks
	to Regional Internet Registries - Revised
In-Reply-To: <49C0B9AD.19704.84A951A@farmer.umn.edu>
References: <4607e1d50903101524p51e29b6cna0a5426af2ca722e@mail.gmail.com>
	<49B7E20A.31690.9C90AE4@farmer.umn.edu>
	<4607e1d50903111609j5626014w7cc171c42a850676@mail.gmail.com>
	<49C0B9AD.19704.84A951A@farmer.umn.edu>
Message-ID: <4607e1d50903181233j34579c85ta27fe865827e588b@mail.gmail.com>

Hi Dave,

On Wed, Mar 18, 2009 at 10:06 AM, David Farmer <farmer at umn.edu> wrote:

> On 11 Mar 2009 Martin Hannigan wrote:
>
> > On Wed, Mar 11, 2009 at 5:08 PM, David Farmer <farmer at umn.edu> wrote:
>
> [ clip ]
>
> > > There are several issues I think we should give them feedback on:
> > >
> > > 1.  RIR assigned vs. Legacy Blocks -  It might be be helpful to
> > > differentiate between Legacy assignments and RIR assigned /8s.  Like
> > > making return of RIR assigned block optional, and Legacy assigned
> > > block mandatory.
> >
> > Differentiating creates classes. We see that differientation and the
> > resulting difficulties with creating reasonable, modernized, transfer
> > policy. When you create a class, you almost always end up with an
> > inequity that is uneven and painful. Citizenship vs. non-citizenship,
> > for example.
>
> I think I agree with you on this one, but this is one change that has been
> talked about.



Technically, this is a transfer policy since it allows the transfer of
resources that are currently legitimately registered within the region to be
taken out of the region. The regional transfer policies are very different.
There lies a large inequity of this policy.

[ clip ]


>
>
> If you assume that we will never recover much address space then there will
> probably never be enough address space to meet the needs of even one of
> the RIRs.  But it could still be possible for the criteria in the proposed
> B.3 to
> be meet, but that the RIR in questions has more address space than it
> needs.  In no situation should an RIR be able receive address that it can't
> justify need, especially if other RIRs can justify need.



I don't disagree that space that is classified as excess, through a regional
policy that is modifiable both rapidly and in response to real experience
and regional requirements, should be allocated where there is need. This is
not the mechanism that would accomplish that, fairly and/or evenly.

There is also no fix, that I am currently aware of, that would accomodate a
fair redistribution of returned or recovered IPv4 adddress space that is
based on the needs of all regions.  There also isn't a policy fix that would
address all of the pitfalls that would prove unfair to our community. Such
as monetizing. The only way that I can think of to insure that unfair
conditions are not created is to have a global transfer policy that mutually
assures that the system will not be monetized or unfair. That will prove
impossible to do on a global, or globally coordinated, basis since the needs
are so varied.

[ clip ]



>
>
> Otherwise, there would need to be some kind of mechanism for the RIRs to
> share these recovery expenses globally.  And I believe having the RIRs
> exchange money will create all kinds of nasty issues, that I don't even
> want
> to think about.
>
> What do you think?


I think that this would create a potential gaming scenario. An entity could
determine which region was up next in the queue and provide an incentive in
the another region that gets space returned and subsequently passed to the
IANA, fulfilled as stated in the policy, and then allocated to a party that
could then turn around and transfer that resource in the same region. The
potential for abuse seems huge.

This policy indirectly, but effectively, creates a global transfer policy
based on the most lax policy in the system, IMHO.



>
> > The best way to demonstrate the disparity may be to simply look at the
> > current utilization statistics[2] provided by the NRO. Fast forward
> > this to the 2010 prediction and imagine that as the size of the
> > "backed up" requests. This demonstrates to me that this policy would
> > not be favorable for any RIR region, IMHO, which is why it may have
> > been proposed.
>
> I agree there are global inequities, but creating an inequity between each
> RIRs local and global responsibilities will not fix that.  If fact it could
> make it
> worse.


This policy creates a rather severe imbalance in fairness based on the
points I made related to that statistical compilation from the NRO and the
differing volume of needs amongst the RIR operations. One region would have
a majority of it's needs met while our region would have small fractions of
our needs met under this policy. It's really that simple. Even if small
amounts of space were to be recovered and transferred to the IANA, some
regions would be able to continue in an almost business as usual fashion.


Best Regards,

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090318/8face0af/attachment.htm>

From heather.schiller at verizonbusiness.com  Wed Mar 18 17:32:46 2009
From: heather.schiller at verizonbusiness.com (Heather Schiller)
Date: Wed, 18 Mar 2009 17:32:46 -0400
Subject: [arin-ppml] Question for ARIN staff..
Message-ID: <49C1687E.9090505@verizonbusiness.com>


Is Ben Edelman still on the ARIN payroll or still consulting for ARIN? 
Is Ben Edelman speaking on behalf of ARIN or representing ARIN's point 
of view in this article?


http://hbswk.hbs.edu/item/5968.html

A: A market-based approach offers a real benefit to those who still need 
more IPv4 addresses after ordinary supplies run out. Rather than being 
told that no more IPv4 space is available, on any terms or at any price, 
these networks could offer payments to get v4 space from others. It's 
unlikely that other networks would return their space for free?why would 
they? But if the price is right, they may be willing to transfer the 
space to someone who needs it more.

So the core benefit is allocative efficiency, moving scarce resources to 
those who need them most.

But there are other benefits, too. By putting a positive price on IPv4 
space, a market mechanism would remind current v4 users that their v4 
space is valuable, and that they might want to try to vacate it, to the 
extent they can, perhaps by moving to IPv6. A market basically tells 
networks: "We will pay you to use v6 instead." That's a transition 
incentive quite different from anything we've seen to date. That's a 
transition incentive that just might work.


Q: Who will make this decision? Will governments play a role?

A: IP addresses are given out by five Regional Internet Registries 
(RIRs). In North America, our RIR is the American Registry for Internet 
Numbers (ARIN). RIRs are private nonprofits, not a government agency, 
and their powers are appropriately limited. But RIRs are in a position 
to allow paid transfers, if they conclude that such transfers are in the 
Internet's best interests.

-- 
====================================================
  Heather Schiller	Verizon Business
  Customer Security	1.800.900.0241
  IP Address Management	help4u at verizonbusiness.com
=====================================================



From schnizlein at isoc.org  Wed Mar 18 18:09:44 2009
From: schnizlein at isoc.org (John Schnizlein)
Date: Wed, 18 Mar 2009 18:09:44 -0400
Subject: [arin-ppml] Question for ARIN staff..
In-Reply-To: <49C1687E.9090505@verizonbusiness.com>
References: <49C1687E.9090505@verizonbusiness.com>
Message-ID: <6E6664D8-90FB-4D3E-9C91-0DD5DF86AF51@isoc.org>

The longer (better) article at http://www.benedelman.org/publications/runningout-draft.pdf 
  has an explicit answer for the second question at the bottom of page  
one:

"Disclosure: I provide advice to ARIN?s counsel on matters pertaining  
to v6 transition, v4
exhaustion, and possible revisions to ARIN?s v4 transfer policy.

This paper expresses only my own views ? not the views of ARIN or of  
those who kindly
discussed these matters with me. "

John

On 2009Mar18, at 5:32 PM, Heather Schiller wrote:

>
> Is Ben Edelman still on the ARIN payroll or still consulting for ARIN?
> Is Ben Edelman speaking on behalf of ARIN or representing ARIN's point
> of view in this article?
>
>
> http://hbswk.hbs.edu/item/5968.html
>
> A: A market-based approach offers a real benefit to those who still  
> need
> more IPv4 addresses after ordinary supplies run out. Rather than being
> told that no more IPv4 space is available, on any terms or at any  
> price,
> these networks could offer payments to get v4 space from others. It's
> unlikely that other networks would return their space for free?why  
> would
> they? But if the price is right, they may be willing to transfer the
> space to someone who needs it more.
>
> So the core benefit is allocative efficiency, moving scarce  
> resources to
> those who need them most.
>
> But there are other benefits, too. By putting a positive price on IPv4
> space, a market mechanism would remind current v4 users that their v4
> space is valuable, and that they might want to try to vacate it, to  
> the
> extent they can, perhaps by moving to IPv6. A market basically tells
> networks: "We will pay you to use v6 instead." That's a transition
> incentive quite different from anything we've seen to date. That's a
> transition incentive that just might work.
>
>
> Q: Who will make this decision? Will governments play a role?
>
> A: IP addresses are given out by five Regional Internet Registries
> (RIRs). In North America, our RIR is the American Registry for  
> Internet
> Numbers (ARIN). RIRs are private nonprofits, not a government agency,
> and their powers are appropriately limited. But RIRs are in a position
> to allow paid transfers, if they conclude that such transfers are in  
> the
> Internet's best interests.
>
> -- 
> ====================================================
>  Heather Schiller	Verizon Business
>  Customer Security	1.800.900.0241
>  IP Address Management	help4u at verizonbusiness.com
> =====================================================
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From mueller at syr.edu  Wed Mar 18 17:53:48 2009
From: mueller at syr.edu (Milton L Mueller)
Date: Wed, 18 Mar 2009 17:53:48 -0400
Subject: [arin-ppml] Question for ARIN staff..
In-Reply-To: <49C1687E.9090505@verizonbusiness.com>
References: <49C1687E.9090505@verizonbusiness.com>
Message-ID: <75822E125BCB994F8446858C4B19F0D7149619E1@SUEX07-MBX-04.ad.syr.edu>



In this article, Ben Edelman is nowhere identified as associated with ARIN. Neither he nor the interviewer even mentions ARIN. What exactly is the point of your question? 

Milton Mueller
Professor, Syracuse University School of Information Studies
XS4All Professor, Delft University of Technology
------------------------------
Internet Governance Project:
http://internetgovernance.org
 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Heather Schiller
> Sent: Wednesday, March 18, 2009 5:33 PM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Question for ARIN staff..
> 
> 
> Is Ben Edelman still on the ARIN payroll or still consulting 
> for ARIN? 
> Is Ben Edelman speaking on behalf of ARIN or representing 
> ARIN's point 
> of view in this article?
> 
> 
> http://hbswk.hbs.edu/item/5968.html
> 
> A: A market-based approach offers a real benefit to those who 
> still need 
> more IPv4 addresses after ordinary supplies run out. Rather 
> than being 
> told that no more IPv4 space is available, on any terms or at 
> any price, 
> these networks could offer payments to get v4 space from others. It's 
> unlikely that other networks would return their space for 
> free-why would 
> they? But if the price is right, they may be willing to transfer the 
> space to someone who needs it more.
> 
> So the core benefit is allocative efficiency, moving scarce 
> resources to 
> those who need them most.
> 
> But there are other benefits, too. By putting a positive 
> price on IPv4 
> space, a market mechanism would remind current v4 users that their v4 
> space is valuable, and that they might want to try to vacate 
> it, to the 
> extent they can, perhaps by moving to IPv6. A market basically tells 
> networks: "We will pay you to use v6 instead." That's a transition 
> incentive quite different from anything we've seen to date. That's a 
> transition incentive that just might work.
> 
> 
> Q: Who will make this decision? Will governments play a role?
> 
> A: IP addresses are given out by five Regional Internet Registries 
> (RIRs). In North America, our RIR is the American Registry 
> for Internet 
> Numbers (ARIN). RIRs are private nonprofits, not a government agency, 
> and their powers are appropriately limited. But RIRs are in a 
> position 
> to allow paid transfers, if they conclude that such transfers 
> are in the 
> Internet's best interests.
> 
> -- 
> ====================================================
>   Heather Schiller	Verizon Business
>   Customer Security	1.800.900.0241
>   IP Address Management	help4u at verizonbusiness.com
> =====================================================
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 

From info at arin.net  Fri Mar 20 13:29:47 2009
From: info at arin.net (Member Services)
Date: Fri, 20 Mar 2009 13:29:47 -0400
Subject: [arin-ppml] Policy Proposal: Sunset 2008-6 on schedule
Message-ID: <49C3D28B.4060103@arin.net>

ARIN received the following policy proposal and is posting it to the
Public Policy Mailing List (PPML) in accordance with Policy Development
Process.

This proposal is in the first stage of the Policy Development Process.
ARIN staff will perform the Clarity and Understanding step. Staff does
not evaluate the proposal at this time, their goal is to make sure that
they understand the proposal and believe the community will as well.
Staff will report their results to the ARIN Advisory Council (AC) within
10 days.

The AC will review the proposal at their next regularly scheduled
meeting (if the period before the next regularly scheduled meeting is
less than 10 days, then the period may be extended to the subsequent
regularly scheduled meeting). The AC will decide how to utilize the
proposal and announce the decision to the PPML.

In the meantime, the AC invites everyone to comment on the proposal on
the PPML, particularly their support or non-support and the reasoning
behind their opinion. Such participation contributes to a thorough
vetting and provides important guidance to the AC in their deliberations.

The ARIN Policy Development Process can be found at:
http://www.arin.net/policy/pdp.html

Mailing list subscription information can be found at:
http://www.arin.net/mailing_lists/

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Policy Proposal Name: Sunset 2008-6 on schedule

Proposal Originator: Owen DeLong

Proposal Version: 1.0

Date: 19 March 2009

Proposal type: delete

Policy term: permanent

Policy statement:

Effective March 31, 2012, the changes made to the NRPM by policy 2008-6
are to be deleted.

Rationale:

Part of the policy that the community developed consensus for in 2008-6
included a sunset clause.  The ARIN Board in an unprecedented action
chose to discard this clause while approving the remainder of the policy.

This proposal is intended to restore the will of the community and
ensure that this policy remains temporary as intended.

Timetable for implementation: March 31, 2012







From tedm at ipinc.net  Fri Mar 20 13:56:36 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 20 Mar 2009 10:56:36 -0700
Subject: [arin-ppml] Policy Proposal: Sunset 2008-6 on schedule
In-Reply-To: <49C3D28B.4060103@arin.net>
References: <49C3D28B.4060103@arin.net>
Message-ID: <FF1B008A38AF4B169F2C6231EC04AA26@tedsdesk>

I fully support this.

The disregarding of the "For a period of 3 years from policy implementation"
statement in the policy proposal was NOT mentioned AT ALL in the actual
records of the policy proposal itself:

https://www.arin.net/policy/proposals/2008_6.html

For THIS REASON ALONE setting aside ALL OTHER discussion I would be
in favor of Owen's proposal.

The COMPLETE implementation of ANY policy is a sacred trust, and while
I might condone the ARIN board's actions of removing the sunset clause
IF AN EXPLANATION WAS SUPPLIED IN THE POLICY RECORD the fact that one
WAS NOT and NO mention of this appears in the record is, in my opinion,
far, far worse than the thwarting the will of the community.

It is one thing for ARIN to thwart the will of the community for reasons
they feel are good and have a logical basis (changed premises, etc.) It is
ENTIRELY DIFFERENT for them to do so and SWEEP IT UNDER THE RUG by NOT
documenting it in the proposal.

So, are we going to have to now, check and verify every accepted proposal
against the actual NRPM itself to make sure the board didn't just
"forget" to include something it didn't like?

Fagh!

Ted

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services
> Sent: Friday, March 20, 2009 10:30 AM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Policy Proposal: Sunset 2008-6 on schedule
> 
> ARIN received the following policy proposal and is posting it 
> to the Public Policy Mailing List (PPML) in accordance with 
> Policy Development Process.
> 
> This proposal is in the first stage of the Policy Development Process.
> ARIN staff will perform the Clarity and Understanding step. 
> Staff does not evaluate the proposal at this time, their goal 
> is to make sure that they understand the proposal and believe 
> the community will as well.
> Staff will report their results to the ARIN Advisory Council 
> (AC) within 10 days.
> 
> The AC will review the proposal at their next regularly 
> scheduled meeting (if the period before the next regularly 
> scheduled meeting is less than 10 days, then the period may 
> be extended to the subsequent regularly scheduled meeting). 
> The AC will decide how to utilize the proposal and announce 
> the decision to the PPML.
> 
> In the meantime, the AC invites everyone to comment on the 
> proposal on the PPML, particularly their support or 
> non-support and the reasoning behind their opinion. Such 
> participation contributes to a thorough vetting and provides 
> important guidance to the AC in their deliberations.
> 
> The ARIN Policy Development Process can be found at:
> http://www.arin.net/policy/pdp.html
> 
> Mailing list subscription information can be found at:
> http://www.arin.net/mailing_lists/
> 
> Regards,
> 
> Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> ## * ##
> 
> 
> Policy Proposal Name: Sunset 2008-6 on schedule
> 
> Proposal Originator: Owen DeLong
> 
> Proposal Version: 1.0
> 
> Date: 19 March 2009
> 
> Proposal type: delete
> 
> Policy term: permanent
> 
> Policy statement:
> 
> Effective March 31, 2012, the changes made to the NRPM by 
> policy 2008-6 are to be deleted.
> 
> Rationale:
> 
> Part of the policy that the community developed consensus for 
> in 2008-6 included a sunset clause.  The ARIN Board in an 
> unprecedented action chose to discard this clause while 
> approving the remainder of the policy.
> 
> This proposal is intended to restore the will of the 
> community and ensure that this policy remains temporary as intended.
> 
> Timetable for implementation: March 31, 2012
> 
> 
> 
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 



From scottleibrand at gmail.com  Fri Mar 20 14:07:09 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Fri, 20 Mar 2009 11:07:09 -0700
Subject: [arin-ppml] Policy Proposal: Sunset 2008-6 on schedule
In-Reply-To: <FF1B008A38AF4B169F2C6231EC04AA26@tedsdesk>
References: <49C3D28B.4060103@arin.net>
	<FF1B008A38AF4B169F2C6231EC04AA26@tedsdesk>
Message-ID: <49C3DB4D.8030605@gmail.com>

Ted,

I don't believe that the Board has yet released the record of their 
(very recent) emergency policy action subsequent to adopting 2008-6.  We 
should see something released on that in the near future, and per the 
PDP, will be discussing the action on PPML and at the San Antonio Public 
Policy Meeting.

-Scott (speaking solely for myself, and not yet expressing any opinion 
on any action taken or policy proposed on this subject)

Ted Mittelstaedt wrote:
> I fully support this.
>
> The disregarding of the "For a period of 3 years from policy implementation"
> statement in the policy proposal was NOT mentioned AT ALL in the actual
> records of the policy proposal itself:
>
> https://www.arin.net/policy/proposals/2008_6.html
>
> For THIS REASON ALONE setting aside ALL OTHER discussion I would be
> in favor of Owen's proposal.
>
> The COMPLETE implementation of ANY policy is a sacred trust, and while
> I might condone the ARIN board's actions of removing the sunset clause
> IF AN EXPLANATION WAS SUPPLIED IN THE POLICY RECORD the fact that one
> WAS NOT and NO mention of this appears in the record is, in my opinion,
> far, far worse than the thwarting the will of the community.
>
> It is one thing for ARIN to thwart the will of the community for reasons
> they feel are good and have a logical basis (changed premises, etc.) It is
> ENTIRELY DIFFERENT for them to do so and SWEEP IT UNDER THE RUG by NOT
> documenting it in the proposal.
>
> So, are we going to have to now, check and verify every accepted proposal
> against the actual NRPM itself to make sure the board didn't just
> "forget" to include something it didn't like?
>
> Fagh!
>
> Ted
>
>   
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net 
>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services
>> Sent: Friday, March 20, 2009 10:30 AM
>> To: arin-ppml at arin.net
>> Subject: [arin-ppml] Policy Proposal: Sunset 2008-6 on schedule
>>
>> ARIN received the following policy proposal and is posting it 
>> to the Public Policy Mailing List (PPML) in accordance with 
>> Policy Development Process.
>>
>> This proposal is in the first stage of the Policy Development Process.
>> ARIN staff will perform the Clarity and Understanding step. 
>> Staff does not evaluate the proposal at this time, their goal 
>> is to make sure that they understand the proposal and believe 
>> the community will as well.
>> Staff will report their results to the ARIN Advisory Council 
>> (AC) within 10 days.
>>
>> The AC will review the proposal at their next regularly 
>> scheduled meeting (if the period before the next regularly 
>> scheduled meeting is less than 10 days, then the period may 
>> be extended to the subsequent regularly scheduled meeting). 
>> The AC will decide how to utilize the proposal and announce 
>> the decision to the PPML.
>>
>> In the meantime, the AC invites everyone to comment on the 
>> proposal on the PPML, particularly their support or 
>> non-support and the reasoning behind their opinion. Such 
>> participation contributes to a thorough vetting and provides 
>> important guidance to the AC in their deliberations.
>>
>> The ARIN Policy Development Process can be found at:
>> http://www.arin.net/policy/pdp.html
>>
>> Mailing list subscription information can be found at:
>> http://www.arin.net/mailing_lists/
>>
>> Regards,
>>
>> Member Services
>> American Registry for Internet Numbers (ARIN)
>>
>>
>> ## * ##
>>
>>
>> Policy Proposal Name: Sunset 2008-6 on schedule
>>
>> Proposal Originator: Owen DeLong
>>
>> Proposal Version: 1.0
>>
>> Date: 19 March 2009
>>
>> Proposal type: delete
>>
>> Policy term: permanent
>>
>> Policy statement:
>>
>> Effective March 31, 2012, the changes made to the NRPM by 
>> policy 2008-6 are to be deleted.
>>
>> Rationale:
>>
>> Part of the policy that the community developed consensus for 
>> in 2008-6 included a sunset clause.  The ARIN Board in an 
>> unprecedented action chose to discard this clause while 
>> approving the remainder of the policy.
>>
>> This proposal is intended to restore the will of the 
>> community and ensure that this policy remains temporary as intended.
>>
>> Timetable for implementation: March 31, 2012
>>
>>
>>
>>
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to 
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
>>     
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>   


From owen at delong.com  Fri Mar 20 14:27:43 2009
From: owen at delong.com (Owen DeLong)
Date: Fri, 20 Mar 2009 11:27:43 -0700
Subject: [arin-ppml] Policy Proposal: Sunset 2008-6 on schedule
In-Reply-To: <FF1B008A38AF4B169F2C6231EC04AA26@tedsdesk>
References: <49C3D28B.4060103@arin.net>
	<FF1B008A38AF4B169F2C6231EC04AA26@tedsdesk>
Message-ID: <92124DB7-3213-49B0-BC7D-D2FA42939F14@delong.com>

Ted,
	I don't think anyone was sweeping anything under the rug.  I believe
the board plans to document this decision fully in the policy along with
their public announcement of the decision.

	The fact that my proposal hit the public before the board's  
announcement
is an error on my part, for which I sincerely apologize to the Board  
and to the
community for the confusion it has and will cause.

	I am upset by the board's actions, and, I stand by my proposal, but,  
the
timing error is my fault and not an effort by the board to cover  
anything up.
I have the utmost respect for our board and believe that they are people
of integrity doing what they believe is best for ARIN and the community.

Owen

On Mar 20, 2009, at 10:56 AM, Ted Mittelstaedt wrote:

> I fully support this.
>
> The disregarding of the "For a period of 3 years from policy  
> implementation"
> statement in the policy proposal was NOT mentioned AT ALL in the  
> actual
> records of the policy proposal itself:
>
> https://www.arin.net/policy/proposals/2008_6.html
>
> For THIS REASON ALONE setting aside ALL OTHER discussion I would be
> in favor of Owen's proposal.
>
> The COMPLETE implementation of ANY policy is a sacred trust, and while
> I might condone the ARIN board's actions of removing the sunset clause
> IF AN EXPLANATION WAS SUPPLIED IN THE POLICY RECORD the fact that one
> WAS NOT and NO mention of this appears in the record is, in my  
> opinion,
> far, far worse than the thwarting the will of the community.
>
> It is one thing for ARIN to thwart the will of the community for  
> reasons
> they feel are good and have a logical basis (changed premises, etc.)  
> It is
> ENTIRELY DIFFERENT for them to do so and SWEEP IT UNDER THE RUG by NOT
> documenting it in the proposal.
>
> So, are we going to have to now, check and verify every accepted  
> proposal
> against the actual NRPM itself to make sure the board didn't just
> "forget" to include something it didn't like?
>
> Fagh!
>
> Ted
>
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net
>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services
>> Sent: Friday, March 20, 2009 10:30 AM
>> To: arin-ppml at arin.net
>> Subject: [arin-ppml] Policy Proposal: Sunset 2008-6 on schedule
>>
>> ARIN received the following policy proposal and is posting it
>> to the Public Policy Mailing List (PPML) in accordance with
>> Policy Development Process.
>>
>> This proposal is in the first stage of the Policy Development  
>> Process.
>> ARIN staff will perform the Clarity and Understanding step.
>> Staff does not evaluate the proposal at this time, their goal
>> is to make sure that they understand the proposal and believe
>> the community will as well.
>> Staff will report their results to the ARIN Advisory Council
>> (AC) within 10 days.
>>
>> The AC will review the proposal at their next regularly
>> scheduled meeting (if the period before the next regularly
>> scheduled meeting is less than 10 days, then the period may
>> be extended to the subsequent regularly scheduled meeting).
>> The AC will decide how to utilize the proposal and announce
>> the decision to the PPML.
>>
>> In the meantime, the AC invites everyone to comment on the
>> proposal on the PPML, particularly their support or
>> non-support and the reasoning behind their opinion. Such
>> participation contributes to a thorough vetting and provides
>> important guidance to the AC in their deliberations.
>>
>> The ARIN Policy Development Process can be found at:
>> http://www.arin.net/policy/pdp.html
>>
>> Mailing list subscription information can be found at:
>> http://www.arin.net/mailing_lists/
>>
>> Regards,
>>
>> Member Services
>> American Registry for Internet Numbers (ARIN)
>>
>>
>> ## * ##
>>
>>
>> Policy Proposal Name: Sunset 2008-6 on schedule
>>
>> Proposal Originator: Owen DeLong
>>
>> Proposal Version: 1.0
>>
>> Date: 19 March 2009
>>
>> Proposal type: delete
>>
>> Policy term: permanent
>>
>> Policy statement:
>>
>> Effective March 31, 2012, the changes made to the NRPM by
>> policy 2008-6 are to be deleted.
>>
>> Rationale:
>>
>> Part of the policy that the community developed consensus for
>> in 2008-6 included a sunset clause.  The ARIN Board in an
>> unprecedented action chose to discard this clause while
>> approving the remainder of the policy.
>>
>> This proposal is intended to restore the will of the
>> community and ensure that this policy remains temporary as intended.
>>
>> Timetable for implementation: March 31, 2012
>>
>>
>>
>>
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From tedm at ipinc.net  Fri Mar 20 15:00:27 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 20 Mar 2009 12:00:27 -0700
Subject: [arin-ppml] Policy Proposal: Sunset 2008-6 on schedule
In-Reply-To: <92124DB7-3213-49B0-BC7D-D2FA42939F14@delong.com>
References: <49C3D28B.4060103@arin.net>
	<FF1B008A38AF4B169F2C6231EC04AA26@tedsdesk>
	<92124DB7-3213-49B0-BC7D-D2FA42939F14@delong.com>
Message-ID: <E32C7567B8E9410E90AFA9E5874B3227@tedsdesk>


OK, but I still am opposed to removal of a sunsetting
clause on this change - thus I still fully support
your proposal.

I also can't see how this proposal hitting the public before
the board's action is an error on your part.  YOU didn't post
your proposal to the mailing list, ARIN AKA  Member Services
did.  You merely sent a proposal to them.

If they HAD IMMEDIATELY documented this, it would not have
mattered if the proposal had gone out "early"

Ted


> -----Original Message-----
> From: Owen DeLong [mailto:owen at delong.com] 
> Sent: Friday, March 20, 2009 11:28 AM
> To: Ted Mittelstaedt
> Cc: 'Member Services'; arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal: Sunset 2008-6 on schedule
> 
> Ted,
> 	I don't think anyone was sweeping anything under the 
> rug.  I believe the board plans to document this decision 
> fully in the policy along with their public announcement of 
> the decision.
> 
> 	The fact that my proposal hit the public before the 
> board's announcement is an error on my part, for which I 
> sincerely apologize to the Board and to the community for the 
> confusion it has and will cause.
> 
> 	I am upset by the board's actions, and, I stand by my 
> proposal, but, the timing error is my fault and not an effort 
> by the board to cover anything up.
> I have the utmost respect for our board and believe that they 
> are people of integrity doing what they believe is best for 
> ARIN and the community.
> 
> Owen
> 
> On Mar 20, 2009, at 10:56 AM, Ted Mittelstaedt wrote:
> 
> > I fully support this.
> >
> > The disregarding of the "For a period of 3 years from policy 
> > implementation"
> > statement in the policy proposal was NOT mentioned AT ALL in the 
> > actual records of the policy proposal itself:
> >
> > https://www.arin.net/policy/proposals/2008_6.html
> >
> > For THIS REASON ALONE setting aside ALL OTHER discussion I 
> would be in 
> > favor of Owen's proposal.
> >
> > The COMPLETE implementation of ANY policy is a sacred 
> trust, and while 
> > I might condone the ARIN board's actions of removing the 
> sunset clause 
> > IF AN EXPLANATION WAS SUPPLIED IN THE POLICY RECORD the 
> fact that one 
> > WAS NOT and NO mention of this appears in the record is, in my 
> > opinion, far, far worse than the thwarting the will of the 
> community.
> >
> > It is one thing for ARIN to thwart the will of the community for 
> > reasons they feel are good and have a logical basis 
> (changed premises, 
> > etc.) It is ENTIRELY DIFFERENT for them to do so and SWEEP IT UNDER 
> > THE RUG by NOT documenting it in the proposal.
> >
> > So, are we going to have to now, check and verify every accepted 
> > proposal against the actual NRPM itself to make sure the 
> board didn't 
> > just "forget" to include something it didn't like?
> >
> > Fagh!
> >
> > Ted
> >
> >> -----Original Message-----
> >> From: arin-ppml-bounces at arin.net
> >> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services
> >> Sent: Friday, March 20, 2009 10:30 AM
> >> To: arin-ppml at arin.net
> >> Subject: [arin-ppml] Policy Proposal: Sunset 2008-6 on schedule
> >>
> >> ARIN received the following policy proposal and is posting 
> it to the 
> >> Public Policy Mailing List (PPML) in accordance with Policy 
> >> Development Process.
> >>
> >> This proposal is in the first stage of the Policy Development 
> >> Process.
> >> ARIN staff will perform the Clarity and Understanding step.
> >> Staff does not evaluate the proposal at this time, their 
> goal is to 
> >> make sure that they understand the proposal and believe 
> the community 
> >> will as well.
> >> Staff will report their results to the ARIN Advisory Council
> >> (AC) within 10 days.
> >>
> >> The AC will review the proposal at their next regularly scheduled 
> >> meeting (if the period before the next regularly scheduled 
> meeting is 
> >> less than 10 days, then the period may be extended to the 
> subsequent 
> >> regularly scheduled meeting).
> >> The AC will decide how to utilize the proposal and announce the 
> >> decision to the PPML.
> >>
> >> In the meantime, the AC invites everyone to comment on the 
> proposal 
> >> on the PPML, particularly their support or non-support and the 
> >> reasoning behind their opinion. Such participation 
> contributes to a 
> >> thorough vetting and provides important guidance to the AC 
> in their 
> >> deliberations.
> >>
> >> The ARIN Policy Development Process can be found at:
> >> http://www.arin.net/policy/pdp.html
> >>
> >> Mailing list subscription information can be found at:
> >> http://www.arin.net/mailing_lists/
> >>
> >> Regards,
> >>
> >> Member Services
> >> American Registry for Internet Numbers (ARIN)
> >>
> >>
> >> ## * ##
> >>
> >>
> >> Policy Proposal Name: Sunset 2008-6 on schedule
> >>
> >> Proposal Originator: Owen DeLong
> >>
> >> Proposal Version: 1.0
> >>
> >> Date: 19 March 2009
> >>
> >> Proposal type: delete
> >>
> >> Policy term: permanent
> >>
> >> Policy statement:
> >>
> >> Effective March 31, 2012, the changes made to the NRPM by policy 
> >> 2008-6 are to be deleted.
> >>
> >> Rationale:
> >>
> >> Part of the policy that the community developed consensus for in 
> >> 2008-6 included a sunset clause.  The ARIN Board in an 
> unprecedented 
> >> action chose to discard this clause while approving the 
> remainder of 
> >> the policy.
> >>
> >> This proposal is intended to restore the will of the community and 
> >> ensure that this policy remains temporary as intended.
> >>
> >> Timetable for implementation: March 31, 2012
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> PPML
> >> You are receiving this message because you are subscribed 
> to the ARIN 
> >> Public Policy Mailing List (ARIN-PPML at arin.net).
> >> Unsubscribe or manage your mailing list subscription at:
> >> http://lists.arin.net/mailman/listinfo/arin-ppml
> >> Please contact info at arin.net if you experience any issues.
> >>
> >
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed 
> to the ARIN 
> > Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> 
> 



From owen at delong.com  Fri Mar 20 15:14:57 2009
From: owen at delong.com (Owen DeLong)
Date: Fri, 20 Mar 2009 12:14:57 -0700
Subject: [arin-ppml] Policy Proposal: Sunset 2008-6 on schedule
In-Reply-To: <E32C7567B8E9410E90AFA9E5874B3227@tedsdesk>
References: <49C3D28B.4060103@arin.net>
	<FF1B008A38AF4B169F2C6231EC04AA26@tedsdesk>
	<92124DB7-3213-49B0-BC7D-D2FA42939F14@delong.com>
	<E32C7567B8E9410E90AFA9E5874B3227@tedsdesk>
Message-ID: <29AEF1F5-E5C2-43E5-B147-69C17D9D561D@delong.com>


On Mar 20, 2009, at 12:00 PM, Ted Mittelstaedt wrote:

>
> OK, but I still am opposed to removal of a sunsetting
> clause on this change - thus I still fully support
> your proposal.
>
On this, we agree.  Thanks for your support.

> I also can't see how this proposal hitting the public before
> the board's action is an error on your part.  YOU didn't post
> your proposal to the mailing list, ARIN AKA  Member Services
> did.  You merely sent a proposal to them.
>
My proposal was based on privileged advanced communication
of the boards decision to the AC.  Once a proposal is submitted,
staff has a rigid and limited timeframe by which they MUST send
it to PPML.  I should have been aware of this timeline and should
have held my submission accordingly.  Staff did what they are
required to do.

> If they HAD IMMEDIATELY documented this, it would not have
> mattered if the proposal had gone out "early"
>
This is a very recent decision by the board, and, it is not
unreasonable for them to take a few days to develop the
announcement.  It is not staff's prerogative to communicate
the boards decisions to the public.

Again, I want to make it very clear to everyone that the only
inappropriate action here was that I submitted my proposal
earlier than I should have.

While I do not agree with the board's decision, they have
acted within their authority in a manner they believe to be
best for the community.  I believe they have taken this action
with integrity and all appropriate deliberation. I expect they
will announce the decision shortly. I expect that would
happen with or without my proposal.

The timing error here is mine and mine alone and I really
want to avoid any unnecessary and invalid accusations
being hurled at staff or the board for my error.

So, everyone, please have a little patience and wait for the
Board announcement.  I apologize for letting the cat out of
the bag early and causing all of this confusion. If you really
must send flaming accusations to someone for the timing
on this, please send them just to me.

Owen



From tedm at ipinc.net  Fri Mar 20 15:53:59 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 20 Mar 2009 12:53:59 -0700
Subject: [arin-ppml] Policy Proposal: Sunset 2008-6 on schedule
In-Reply-To: <29AEF1F5-E5C2-43E5-B147-69C17D9D561D@delong.com>
References: <49C3D28B.4060103@arin.net>
	<FF1B008A38AF4B169F2C6231EC04AA26@tedsdesk>
	<92124DB7-3213-49B0-BC7D-D2FA42939F14@delong.com>
	<E32C7567B8E9410E90AFA9E5874B3227@tedsdesk>
	<29AEF1F5-E5C2-43E5-B147-69C17D9D561D@delong.com>
Message-ID: <DAFE2E72CC7145BD8A25B257F635506E@tedsdesk>


Owen,

staff could have contacted you right after you submitted your proposal and
reminded you that the boards' decision hadn't been posted yet.  Or more
obviously, asked you "what decision" so you could have sent out a
followup to the ppl yourself before the post was made.

Owen, when your running an organization, you take the blame for the
orgs screwups.  You aren't running ARIN, ARIN staff is running ARIN.
They take the blame for the timing mistake on the proposal release, NOT you.

Hasn't anyone learned from the US's newest President Obama?  How many times
has
he stated that the current economic crisis was NOT something he created,
BUT he is in charge now, so HE is responsible.  Owen, YOU aren't in charge,
you are blameless on the timing - and you deserve kudos on objecting
to this board decision in any case.  If there was some legal problem
with the proposal the board discovered at the last minute they should have
halted proceedings on it and gone back to the submitter and worked with
him on it.

I highly doubt that anything the board says to justify their decision
will pass muster on the ppml.  Even if the proposal author comes out
in support of what the board did, I still would oppose this action - I
would rather have seen the entire proposal scratched and a new one
submitted to go through the usual discussion without the sunset clause.

Sunset clauses are VERY COMMONLY used to get controversal and somewhat
objectionable public policy past the voters.  There's almost certainly
people who would have changed their position on the original proposal
if it lacked a sunset clause - otherwise a sunset clause would never
have been put in it in the first place.  To pass such "legislation" with
a clause and then remove the clause immediately after passage is unheard of.

Ted


> -----Original Message-----
> From: Owen DeLong [mailto:owen at delong.com] 
> Sent: Friday, March 20, 2009 12:15 PM
> To: Ted Mittelstaedt
> Cc: 'Member Services'; arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal: Sunset 2008-6 on schedule
> 
> 
> On Mar 20, 2009, at 12:00 PM, Ted Mittelstaedt wrote:
> 
> >
> > OK, but I still am opposed to removal of a sunsetting 
> clause on this 
> > change - thus I still fully support your proposal.
> >
> On this, we agree.  Thanks for your support.
> 
> > I also can't see how this proposal hitting the public before the 
> > board's action is an error on your part.  YOU didn't post your 
> > proposal to the mailing list, ARIN AKA  Member Services did.  You 
> > merely sent a proposal to them.
> >
> My proposal was based on privileged advanced communication of 
> the boards decision to the AC.  Once a proposal is submitted, 
> staff has a rigid and limited timeframe by which they MUST 
> send it to PPML.  I should have been aware of this timeline 
> and should have held my submission accordingly.  Staff did 
> what they are required to do.
> 
> > If they HAD IMMEDIATELY documented this, it would not have 
> mattered if 
> > the proposal had gone out "early"
> >
> This is a very recent decision by the board, and, it is not 
> unreasonable for them to take a few days to develop the 
> announcement.  It is not staff's prerogative to communicate 
> the boards decisions to the public.
> 
> Again, I want to make it very clear to everyone that the only 
> inappropriate action here was that I submitted my proposal 
> earlier than I should have.
> 
> While I do not agree with the board's decision, they have 
> acted within their authority in a manner they believe to be 
> best for the community.  I believe they have taken this 
> action with integrity and all appropriate deliberation. I 
> expect they will announce the decision shortly. I expect that 
> would happen with or without my proposal.
> 
> The timing error here is mine and mine alone and I really 
> want to avoid any unnecessary and invalid accusations being 
> hurled at staff or the board for my error.
> 
> So, everyone, please have a little patience and wait for the 
> Board announcement.  I apologize for letting the cat out of 
> the bag early and causing all of this confusion. If you 
> really must send flaming accusations to someone for the 
> timing on this, please send them just to me.
> 
> Owen
> 
> 



From schnizlein at isoc.org  Fri Mar 20 16:08:57 2009
From: schnizlein at isoc.org (John Schnizlein)
Date: Fri, 20 Mar 2009 16:08:57 -0400
Subject: [arin-ppml] Policy Proposal: Sunset 2008-6 on schedule
In-Reply-To: <DAFE2E72CC7145BD8A25B257F635506E@tedsdesk>
References: <49C3D28B.4060103@arin.net>
	<FF1B008A38AF4B169F2C6231EC04AA26@tedsdesk>
	<92124DB7-3213-49B0-BC7D-D2FA42939F14@delong.com>
	<E32C7567B8E9410E90AFA9E5874B3227@tedsdesk>
	<29AEF1F5-E5C2-43E5-B147-69C17D9D561D@delong.com>
	<DAFE2E72CC7145BD8A25B257F635506E@tedsdesk>
Message-ID: <36669051-45FE-4DC6-91BE-CEFDE0AEF62B@isoc.org>

Really touching the line of off-topic -

Referring to ARIN's policy development process as "legislation" is a  
slippery slope I do not recommend walking.  However, the frequent huge  
difference between what goes into a Conference Committee and what  
comes out does not support the description: "unheard of".

Here is the part that gets back in the vicinity of the topic: the  
discussions of transfer proposals have been dynamic to say the least,  
not just in  ARIN but in other RIRs also.  It seems premature to  
discuss changes that have not been published yet, regardless of Owen's  
view of private conversations with staff.

John

On 2009Mar20, at 3:53 PM, Ted Mittelstaedt wrote:

> Sunset clauses are VERY COMMONLY used to get controversal and somewhat
> objectionable public policy past the voters.  There's almost certainly
> people who would have changed their position on the original proposal
> if it lacked a sunset clause - otherwise a sunset clause would never
> have been put in it in the first place.  To pass such "legislation"  
> with
> a clause and then remove the clause immediately after passage is  
> unheard of.



From tedm at ipinc.net  Fri Mar 20 17:50:36 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 20 Mar 2009 14:50:36 -0700
Subject: [arin-ppml] Policy Proposal: Sunset 2008-6 on schedule
In-Reply-To: <36669051-45FE-4DC6-91BE-CEFDE0AEF62B@isoc.org>
References: <49C3D28B.4060103@arin.net>
	<FF1B008A38AF4B169F2C6231EC04AA26@tedsdesk>
	<92124DB7-3213-49B0-BC7D-D2FA42939F14@delong.com>
	<E32C7567B8E9410E90AFA9E5874B3227@tedsdesk>
	<29AEF1F5-E5C2-43E5-B147-69C17D9D561D@delong.com>
	<DAFE2E72CC7145BD8A25B257F635506E@tedsdesk>
	<36669051-45FE-4DC6-91BE-CEFDE0AEF62B@isoc.org>
Message-ID: <46CC5224FA49462490588585630C3ABF@tedsdesk>


The conference committees are equivalent to the ARIN PPML.

Changing a policy proposal that the PPML has given consensus
on is basically equivalent to a line-item veto.  That's
the real slippery slope IMHO.

Ted 

> -----Original Message-----
> From: John Schnizlein [mailto:schnizlein at isoc.org] 
> Sent: Friday, March 20, 2009 1:09 PM
> To: Ted Mittelstaedt
> Cc: 'Owen DeLong'; arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal: Sunset 2008-6 on schedule
> 
> Really touching the line of off-topic -
> 
> Referring to ARIN's policy development process as 
> "legislation" is a slippery slope I do not recommend walking. 
>  However, the frequent huge difference between what goes into 
> a Conference Committee and what comes out does not support 
> the description: "unheard of".
> 
> Here is the part that gets back in the vicinity of the topic: 
> the discussions of transfer proposals have been dynamic to 
> say the least, not just in  ARIN but in other RIRs also.  It 
> seems premature to discuss changes that have not been 
> published yet, regardless of Owen's view of private 
> conversations with staff.
> 
> John
> 
> On 2009Mar20, at 3:53 PM, Ted Mittelstaedt wrote:
> 
> > Sunset clauses are VERY COMMONLY used to get controversal 
> and somewhat 
> > objectionable public policy past the voters.  There's 
> almost certainly 
> > people who would have changed their position on the 
> original proposal 
> > if it lacked a sunset clause - otherwise a sunset clause 
> would never 
> > have been put in it in the first place.  To pass such "legislation"
> > with
> > a clause and then remove the clause immediately after passage is 
> > unheard of.
> 
> 



From info at arin.net  Mon Mar 23 15:05:03 2009
From: info at arin.net (Member Services)
Date: Mon, 23 Mar 2009 15:05:03 -0400
Subject: [arin-ppml] Draft Policy 2008-3: Community Networks IPv6 Assignment
Message-ID: <49C7DD5F.7070306@arin.net>

SUBJECT: Draft Policy 2008-3: Community Networks IPv6 Assignment

Draft Policy 2008-3
Community Networks IPv6 Assignment

The following draft policy text is being posted for feedback and
discussion on the Public Policy Mailing List (PPML).

After the October 2008 Public Policy Meeting the ARIN Advisory Council
(AC) decided that 2008-3 required more work. The text below was
developed by the AC. The AC was required to submit text to ARIN for
staff and legal assessment prior to selecting it as a draft policy. The
assessment, along with the text that was assessed, is located below the
draft policy.

On 20 March 2009 the ARIN Advisory Council (AC) selected Draft Policy
2008-3: Community Networks IPv6 Assignment for adoption discussion on
the PPML and at the upcoming Public Policy Meeting.

Draft Policy 2008-3 is below and can be found at:
https://www.arin.net/policy/proposals/2008_3.html

We encourage you to discuss Draft Policy 2008-3 on PPML prior to the
ARIN XXIII Public Policy Meeting. Both the discussion on the PPML and at
the Public Policy Meeting will be used by the ARIN Advisory Council to
determine the community consensus regarding adopting this as policy.

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

All of the Draft Policies under discussion can be found at:
https://www.arin.net/policy/proposals/index.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy 2008-3
Community Networks IPv6 Assignment

Date: 23 March 2009

Policy statement:

[Add Section 2.8 to the NRPM.]

2.8 Community Network

A community network is any network organized and operated by a mostly
volunteer group operating as or under the fiscal support of a non-profit
organization or university for the purpose of providing free or low-cost
connectivity to the residents of their local service area. To be treated
as a community network under ARIN policy, the applicant must further
certify to ARIN that the community network staff is at least 50%
volunteer and that the annual budget for community network activities is
less than $250,000.

[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 qualifying Community Network as
defined in Section 2.8, with assignment criteria defined in section 6.5.9.

[Add Section 6.5.9 to the NRPM.]

6.5.9 Community Network Assignments

6.5.9.1 Qualification Criteria

To qualify for a direct assignment, a community network must demonstrate
it will immediately provide sustained service to at least 100
simultaneous users and must demonstrate a plan to provide sustained
service to at least 200 simultaneous users within one year. For
community networks located in rural regions or in the Caribbean and
North Atlantic Islands Sector, the numbers in these qualification
criteria may be relaxed at ARIN's discretion.

6.5.9.2. Initial assignment size

The minimum size of the assignment is /48. Organizations requesting a
larger assignment must provide documentation of the characteristics of
the Community Network's size and architecture that require the use of
additional subnets. An HD-Ratio of .94 with respect to subnet
utilization within the network must be met for all assignments larger
than a /48. These assignments shall be made from a distinctly identified
prefix and shall be made with a reservation for growth of at least a
/44. This reservation may be assigned to other organizations later, at
ARIN's discretion.

6.5.9.3. Subsequent assignment size

Additional assignments may be made when the need for additional subnets
is justified. Justification will be determined based on a detailed plan
of the network's architecture and the .94 HD-Ratio metric. When
possible, assignments will be made from an aggregatable adjacent address
block.


Rationale:

this policy was originally proposed by community network operators to
provide them with the ability to receive a direct assignment of IPv6
address resources from ARIN. the operators of such networks have
expressed their need to have a stable and globally unique address
assignment with which to number their network infrastructure. many such
networks are not able to meet the current criteria for a PI IPv6
assignment from ARIN. in an environment where connections to outside
networks may come and go, a stable internal address structure would be
very valuable. additionally, the ability to exchange routes with others,
whether locally or tunneled, and thereby have native IPv6 connectivity,
would be quite beneficial. these operators were also hopeful that, once
this new class of address assignments was created, they could pursue
lower annual fees for community networks through the ARIN Consultation
and Suggestion Process (ACSP).

there could also be a number of potential benefits to allowing community
network participants to begin using IPv6 addressing. some of these
networks have many technically capable and adventurous members who would
be motivated to begin developing and/or experimenting with the software
extensions which will be needed to support IPv6 prefix selection among
multiple IPv6 prefixes when establishing remote connections. also,
participants in networks receiving such assignments will have the
necessary global-ID to experiment with the various proposals currently
being developed for separating network locater from network ID.

also, during the more than one year timeframe that this policy has been
under consideration, other people have suggested other scenarios where
community networks would provide a valuable resource. one such proposal
was discussed at one of the Caribbean Sector meetings where some
participants pointed out the efforts were being made in remote or
sparsely populated areas to establish community networks which would
serve as connections back to educational resources for distant learning
capabilities. there are also many still wild areas of North America
where such community networks could provide improved connectivity over
telephone modems.

Timetable for implementation: Immediate.


#####


ARIN Staff Assessment

*2008-3*

*Title: Community Networks IPv6 Allocation*

*Proposal Submitted: 04 March 2008*

*Latest Revision Submitted: 06 March 2009 (includes AC revisions)*

*Date of Assessment: 15 March 2009*

I. Understanding of the Policy:

*Staff Understanding of the Proposal:*

ARIN staff understands this policy would provide an IPv6 assignment of a
/48 or larger to any community network that can demonstrate it will
provide service to at least 100 users immediately, and have a plan to
demonstrate that it will provide service to at least 200 users within
one year.

II. Comments

A. ARIN Staff Comments:

? The title of the policy says ?allocation? while this policy is clearly
an ?assignment? policy. Therefore, the title should be changed. In
addition, the title of section 6.5.9 should be changed to say
?assignment? and not ?allocation?.

B. ARIN General Counsel Comments:

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

III. Resource Impact

The resource impact of implementing this policy is viewed as minimal. It
is estimated that this policy could require up to 1 person month of
effort to implement following ratification by the ARIN Board of
Trustees. It may require the following:

    * Guidelines Changes
    * Staff training
    * Development of new internal procedures

Text assessed:

2008-3: Community Networks IPv6 Allocation**

*Policy statement:*

[Add Section 2.8 to the NRPM.]

2.8 Community Network

A community network is any network organized and operated by a mostly
volunteer group operating as or under the fiscal support of a non-profit
organization or university for the purpose of providing free or low-cost
connectivity to the residents of their local service area. To be treated
as a community network under ARIN policy, the applicant must further
certify to ARIN that the community network staff is at least 50%
volunteer and that the annual budget for community network activities is
less than $250,000.

[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 qualifying Community Network as
defined in Section 2.8, with allocation criteria defined in section 6.5.9.

[Add Section 6.5.9 to the NRPM.]

6.5.9 Community Network Allocations

6.5.9.1 Qualification Criteria

To qualify for a direct assignment, a community network must demonstrate
it will immediately provide sustained service to at least 100
simultaneous users and must demonstrate a plan to provide sustained
service to at least 200 simultaneous users within one year. For
community networks located in rural regions or in the Caribbean and
North Atlantic Islands Sector, the numbers in these qualification
criteria may be relaxed at ARIN's discretion.

6.5.9.2. Initial assignment size

The minimum size of the assignment is /48. Organizations requesting a
larger assignment must provide documentation of the characteristics of
the Community Network's size and architecture that require the use of
additional subnets. An HD-Ratio of .94 with respect to subnet
utilization within the network must be met for all assignments larger
than a /48. These assignments shall be made from a distinctly identified
prefix and shall be made with a reservation for growth of at least a
/44. This reservation may be assigned to other organizations later, at
ARIN's discretion.

6.5.9.3. Subsequent assignment size

Additional assignments may be made when the need for additional subnets
is justified. Justification will be determined based on a detailed plan
of the network's architecture and the .94 HD-Ratio metric. When
possible, assignments will be made from an aggregatable adjacent address
block.






From info at arin.net  Mon Mar 23 15:05:18 2009
From: info at arin.net (Member Services)
Date: Mon, 23 Mar 2009 15:05:18 -0400
Subject: [arin-ppml] =?windows-1252?q?Draft_Policy_2008-7=3A_Identify_Inva?=
 =?windows-1252?q?lid_WHOIS_POC=92s?=
Message-ID: <49C7DD6E.3010106@arin.net>

SUBJECT: Draft Policy 2008-7: Identify Invalid WHOIS POC?s

Draft Policy 2008-7
Identify Invalid WHOIS POC?s

The following draft policy text is being posted for feedback and
discussion on the Public Policy Mailing List (PPML).

After the October 2008 Public Policy Meeting the ARIN Advisory Council
(AC) decided that 2008-7 required more work. The text below was
developed by the AC with help from the proposal originators. The AC was
required to submit text to ARIN for staff and legal assessment prior to
selecting it as a draft policy. The assessment, along with the text that
was assessed, is located below the draft policy.

On 20 March 2009 the ARIN Advisory Council (AC) selected Draft Policy
2008-7: Identify Invalid WHOIS POC?s (formally known as WHOIS Integrity
Policy Proposal) for adoption discussion on the PPML and at the upcoming
Public Policy Meeting.

Draft Policy 2008-7 is below and can be found at:
https://www.arin.net/policy/proposals/2008_7.html

We encourage you to discuss Draft Policy 2008-7 on PPML prior to the
ARIN XXIII Public Policy Meeting. Both the discussion on the PPML and at
the Public Policy Meeting will be used by the ARIN Advisory Council to
determine the community consensus regarding adopting this as policy.

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

All of the Draft Policies under discussion can be found at:
https://www.arin.net/policy/proposals/index.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy 2008-7
Identify Invalid WHOIS POC?s

Date: 23 March 2009

Policy Statement:

During ARINs annual WHOIS POC validation, an e-mail will be sent to
every POC in the WHOIS database. Each POC will have a maximum of 60 days
to respond with an affirmative that their WHOIS contact information is
correct and complete. Unresponsive POC email addresses shall be marked
as such in the database. If ARIN staff deems a POC to be completely and
permanently abandoned or otherwise illegitimate, the record shall be
deleted. ARIN will maintain, and make readily available to the
community, a current list of address-blocks with no valid POC; this data
will be subject to the current bulk WHOIS policy.

Timetable for implementation: Immediate


#####

ARIN Staff Assessment

2008-7

Title:  Identify Invalid WHOIS POC's (formerly known as WHOIS Integrity
Policy Proposal)

Revision Submitted: 07 March 2008

2nd Revision Submitted: 12 Feb 2009

Date of Assessment:  24 Feb 2009

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

I.  Understanding

ARIN staff understands that this will institute an annual
re-registration of all POCs registered in WHOIS.  POCs who do not
respond within 60 days will be marked in the database as "un-responsive"
and if staff deems them to be invalid for any reason, may remove them
from WHOIS.  In addition, staff will maintain a list of all address
blocks with no valid POCs and will make this data available to any
organization using the bulk whois policy criteria.

II.  Issues and Concerns

  A.  ARIN Staff Comments:

    * Resource records marked as ?unresponsive? or those with no POCs at
      all could become the targets of hijackers who, in the past have
      tended to look for address blocks that contain obsolete or stale data.
    *  An annual re-registration of all POCs (~223,000 currently) will
      likely result in a vast increase in workload, particularly with
      the follow up work and research involved when a POC does not reply
      within 60 days.  This could result in a slow down in registration
      response and processing times.



    * This policy refers to the Bulk Whois policy rather than stating
      the actual criteria under which an organization will be allowed to
      request the list of all address blocks with no valid POCs.  It
      would be better policy text to state the specific criteria,
      including the requirement to sign an AUP, within this policy itself.



  B.  ARIN General Counsel

    * It is possible those delisted will threaten or file litigation to
      be relisted. However, a properly promulgated policy does not pose
      antirust or other legal concerns.



III. Resource Impact

The resource impact of implementing this policy is viewed as
significant. Barring any unforeseen resource requirements, it is
estimated that this policy could take up to 18 person months to fully
implement from the date of ratification of the policy by the ARIN Board
of Trustees.  It may require the following:

    * Staff training
    * Development of new internal process and procedures and
      modification to existing ones
    * Creation of an automated system to track notifications, updates,
      and current status of the POC notification. Provide allowances for
      manual intervention and follow-up by staff.  Engineering estimates
      that it could take up to 18 person months for the creation and
      implementation of this system. In addition, this could impact
      ARIN?s current project deployment schedule.
    * Increased workload could result in the need for additional staff



Text assessed:

2008-7: Identify Invalid WHOIS POC's (formally known as WHOIS Integrity
Policy Proposal)

Revised text is as follows:

During ARINs annual WHOIS POC validation, an e-mail will be sent to
every POC in the WHOIS database. Each POC will have a maximum of 60 days
to respond with an affirmative that their WHOIS contact information is
correct and complete. Unresponsive POC email addresses shall be marked
as such in the database. If ARIN staff deems a POC to be completely and
permanently abandoned or otherwise illegitimate, the record shall be
deleted. ARIN will maintain, and make readily available to the
community, a current list of address-blocks with no valid POC; this data
will be subject to the current bulk WHOIS policy.







From info at arin.net  Mon Mar 23 15:05:31 2009
From: info at arin.net (Member Services)
Date: Mon, 23 Mar 2009 15:05:31 -0400
Subject: [arin-ppml] Draft Policy 2009-2: Depleted IPv4 reserves
Message-ID: <49C7DD7B.5000901@arin.net>

Draft Policy 2009-2
Depleted IPv4 reserves

The following draft policy text is being posted for feedback and
discussion on the Public Policy Mailing List (PPML).

This draft policy was developed by the ARIN Advisory Council (AC) from
Policy Proposal 81: Depleted IPv4 reserves. The AC has taken the
proposal and developed it into a draft policy. The AC was required to
submit text to ARIN for staff and legal assessment prior to selecting it
as a draft policy. The assessment, along with the text that was
assessed, is located below the draft policy.

On 20 March 2009 the ARIN Advisory Council (AC) selected Draft Policy
2009-2: Depleted IPv4 reserves for adoption discussion on the PPML and
at the upcoming Public Policy Meeting.

Draft Policy 2009-2 is below and can be found at:
https://www.arin.net/policy/proposals/2009_2.html

We encourage you to discuss Draft Policy 2009-2 on the PPML prior to the
ARIN XXIII Public Policy Meeting. Both the discussion on the PPML and at
the Public Policy Meeting will be used by the AC to determine the
community consensus regarding adopting this as policy.

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

All of the Draft Policies under discussion can be found at:
https://www.arin.net/policy/proposals/index.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy 2009-2
Depleted IPv4 reserves

Date: 23 March 2009

Policy statement:

(add the following section to the NRPM)

4.1.8 Depleted IPv4 reserves

A limit will be applied to all IPv4 address requests when ARIN's reserve
of unallocated IPv4 address space drops below an equivalent /9. When
this happens, an ISP or End User may receive up to a single /20 within a
six month period. This restriction will be lifted in the event the
reserve of unallocated IPv4 address space increases to an equivalent /7.

Rationale:

As the reserve of IPv4 address space becomes smaller, there is a risk
that many organizations will be denied resources by a large, last minute
request. By implementing a throttle on the last of the IPv4 address
space, a more limited group of organizations will be impacted, allowing
many organizations to receive ongoing resources during the transition to
IPv6.

According to the ARIN statistics page
http://www.arin.net/statistics/index.html, 1,993 organizations were
issued IP space in 2006 and 2007. Of these allocations 41% of the
applicants received less than a /20. On the opposite end, 82
organizations received large blocks. Given that the last reserve of IPv4
space cannot possibly meet the needs of the 82 organizations, the space
could be managed in a way to provide for the needs of a wider base of
consumers while the largest ISPs build momentum behind IPv6.

The goal is to find a balance between the needs of organizations
requiring space, and avoiding the restrictions on end user growth. For
this reason, any caps on allocations should be implemented when the
reserves are essentially depleted, rather than trying to restrict end
user growth when IP space is still readily available.

By putting a six month window on the maximum allocation, the remaining
IP space could provide at least one year for everyone to implement other
solutions while still being able to obtain an IPv4 address allocation.
The time period was also added to provide a consistent rate of
depletion, avoiding a scenario where a large organization could queue
multiple, justifiable requests, resulting in the scenario the proposal
is intended to avoid.

Additional language may need to be added in the event a paid transfer
policy is approved. The thinking is to have two pools of available IP.
One being the current, IANA allocated, reserve of IP space. The second
being IP blocks recovered through monetary incentive. This proposal
would apply to the IANA allocated reserves and would not apply to blocks
made available by monetary means.

An additional thought was to avoid tying this policy shift specifically
to the last /8 allocated by IANA. This allows the policy to come in and
out of play in the event that IPv4 address space is abandoned or
returned to ARIN.

Timetable for implementation: Immediate



#####


ARIN Staff Assessment

*Title: Depleted IPv4 Reserves*

*Proposal Submitted: 02 Dec 2008*

*Revision Submitted: 16 Feb 2009*

*Date of Assessment: 10 March 2009*

I. Understanding of the Policy:

*Staff Understanding of the Proposal:*

ARIN understands this policy goes into effect when ARIN has less than a
/9 worth of IPv4 address space available to be issued to customers. At
that time, an ISP or End user can only receive a /20 from ARIN within a
six month period. This restriction will be removed if ARIN?s available
pool of addresses increases to a /7 equivalent.

II. Comments:

A. ARIN Staff Comments:

          o One question to consider is whether staff should be setting
            aside a /9 in anticipation of this policy. If that is not
            done, there is the potential that one large request could
            take away a very large block of ARIN?s remaining inventory
            and leave us with far less than the /9 equivalent needed to
            implement this policy. For example, if there is one /8 left,
            and ISP A qualifies for a /8, and it gets issued, then there
            will be no address space left to issue under this policy.
                + If the intent is to make sure there is at least a /9
                  available to give out in /20 blocks, then the trigger
                  point may need to be reconsidered. Here are two
                  potential options:
                      # Trigger the policy when filling a request would
                        drop the supply below a /9
                      # Give the org whose request would drop the supply
                        below a /9 as many addresses as would take us to
                        a /9, then trigger the policy.

B. ARIN General Counsel Comments:

The policy does not pose any significant legal risk to ARIN. A community
decision to segment the remaining unissued IPV4 numbers to serve a
larger number of users on its face does not discriminate against or for
any user, large or small. Therefore it is legally unobjectionable. It is
a rational scheme for distribution reasonably related to meeting the
needs of as many end users as possible. Counsel respectfully suggests
that the policy as drafted may contain potential seeds of confusion by
providing for switching back to current distribution policies, and then
back to this policy.

III. Resource Impact

The resource impact of implementing this policy is viewed as minimal. It
is estimated that this policy could require up to 3 person months of
effort to implement following ratification by the ARIN Board of
Trustees. Because this implementation is not planned, it may preempt
ARIN?s current project deployment schedule. It may require the following:

    * Guidelines Changes
    * Modifications to existing registration software tools ? they need
      to be able to report to staff existing inventory levels and to
      notify us when the /9 threshold is reached or is imminent.

Text assessed:

Depleted IPv4 reserves

*Policy statement:*

4.1.8 Depleted IPv4 reserves

A limit will be applied to all IPv4 address requests when ARIN's reserve
of unallocated IPv4 address space drops below an equivalent /9. When
this happens, an ISP or End User may receive up to a single /20 within a
six month period. This restriction will be lifted in the event the
reserve of unallocated IPv4 address space increases to an equivalent /7.







From info at arin.net  Mon Mar 23 15:05:43 2009
From: info at arin.net (Member Services)
Date: Mon, 23 Mar 2009 15:05:43 -0400
Subject: [arin-ppml] Draft Policy 2009-3 (Global): Allocation of IPv4 Blocks
 to Regional Internet Registries
Message-ID: <49C7DD87.4010508@arin.net>

Draft Policy 2009-3 (Global)
Allocation of IPv4 Blocks to Regional Internet Registries

The following draft policy text is being posted for feedback and
discussion on the Public Policy Mailing List (PPML).

This draft policy was developed by the ARIN Advisory Council (AC) from
Policy Proposal 82: Allocation of IPv4 Blocks to Regional Internet
Registries. The AC has taken the proposal and developed it into a draft
policy. The AC was required to submit text to ARIN for staff and legal
assessment prior to selecting it as a draft policy. The assessment,
along with the text that was assessed, is located below the draft policy.

On 20 March 2009 the ARIN Advisory Council (AC) selected Draft Policy
2009-3: Allocation of IPv4 Blocks to Regional Internet Registries for
adoption discussion on the PPML and at the upcoming Public Policy Meeting.

Draft Policy 2009-3 is below and can be found at:
https://www.arin.net/policy/proposals/2009_3.html

We encourage you to discuss Draft Policy 2009-3 on the PPML prior to the
ARIN XXIII Public Policy Meeting. Both the discussion on the PPML and at
the Public Policy Meeting will be used by the AC to determine the
community consensus regarding adopting this as policy.

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

All of the Draft Policies under discussion can be found at:
https://www.arin.net/policy/proposals/index.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy 2009-3 (Global)
Allocation of IPv4 Blocks to Regional Internet Registries

Date: 23 March 2009

Policy statement:

This document describes the policy governing the allocation of IPv4
address space from the IANA to the Regional Internet Registries (RIRs).
This document does not stipulate performance requirements in the
provision of services by IANA to an RIR in accordance with this policy.
Such requirements should be specified by appropriate agreements among
the RIRs and ICANN.

This policy is to be implemented in two phases.

A. Phase I: Recovery of IPv4 Address Space

Upon ratification of this policy by the ICANN Board of Directors the
IANA shall establish a mechanism to receive IPv4 address space which is
returned to it by the RIRs, and hold that address space in a 'recovered
IPv4 pool'.

Each RIR through their respective chosen policies and strategies may
recover IPv4 address space which is under their administration. At
quarterly intervals, each RIR shall return to the IANA any legacy
address space recovered, and may return to the IANA any non-legacy
address space recovered, in aggregated blocks of /24 or larger, for
inclusion in the recovered IPv4 pool.

During Phase I, no allocations will be made from the recovered IPv4
pool. Return of recovered address space (as described above) will
continue throughout Phase II.

B. Phase II: Allocation of Recovered IPv4 address space by the IANA

Upon ratification of this policy by the ICANN Board of Directors and a
declaration by the IANA that its existing free pool of unallocated IPv4
address space is depleted; Global Addressing Policy ASO-001-2 (adopted
by ICANN Board 8 April 2005) is rescinded. IANA will then commence to
allocate the IPv4 address space from the recovered IPv4 pool.

1. The following definitions apply to this policy:

a. Recovered Address Space. Recovered address space is that address
space that is returned to an RIR as a result of any activity that seeks
to reclaim unused address space or is voluntarily returned to the RIR or
is reclaimed by the RIR as a result of legal action or abuse
determination. Recovered address space does not include that address
space that is reclaimed because of non-payment of contractual fees whose
reclamation date is less than 1 year at the time of the report.

b. IPv4 Address Holdings. IPv4 address holdings are all unallocated IPv4
address space held by an RIR to include recovered address space not yet
returned less that address space that is committed in accordance with
the RIR's reservation policy and practices.

c. Aggregated address blocks. Aggregated address blocks are contiguous
prefixes that can be aggregated on natural bit boundaries. 10.0.0.0/24
and 10.0.1.0/24 are two contiguous prefixes that can be combined to form
an aggregated address block. 10.0.0.0/24 and 10.0.1.0/25 are two
contiguous prefixes that cannot be combined on a natural bit boundary to
form an aggregated block.

d. Legacy address space. IPv4 address space allocated or assigned prior
to the creation of the RIR.

2. Allocation of IPv4 Address Space

a. For the purposes of this policy, an 'IPv4 allocation period' is
defined as a 6-month period following 1 March or 1 September in each year.

b. At the beginning of each IPv4 allocation period, the IANA will
determine the 'IPv4 allocation unit' for that period, as 1/10 of its
IPv4 address pool, rounded down to the next CIDR (power-of-2) boundary.
The minimum 'IPv4 allocation unit' size will be a /24.

c. In each allocation period, each RIR may issue one IPv4 request to the
IANA. Providing that the RIR satisfies the allocation criteria described
in paragraph B.2, the IANA will allocate a single allocation unit,
composed of the smallest possible number of blocks available in its IPv4
address pool.

3. IPv4 Address Space Allocation Criteria

A RIR is eligible to receive additional IPv4 address space from the IANA
when the total of its IPv4 address holdings is less than 50% of the
current IPv4 allocation unit, and providing that it has not already
received an IPv4 allocation from the IANA during the current IPv4
allocation period.

4. Initial Allocation of IPv4 Address Space

Each new RIR shall, at the moment of recognition, be allocated one (1)
allocation unit by the IANA. If an allocation unit is not available,
then the IANA will issue this block as soon as one is available. This
allocation will be made regardless of the newly formed RIR's projected
utilization figures and shall be independent of the IPv4 address space
that may have been transferred to the new RIR by the already existing
RIRs as part of the formal transition process.

5. Reporting

a. All returned space is to be recorded in an IANA-published log of IPv4
address space transactions, with each log entry detailing the returned
address block, the date of the return, and the returning RIR.

b. All allocated space is also to be recorded in this IANA-published log
of IPv4 address space transactions, with each log entry detailing the
address blocks, the date of the allocation and the recipient RIR.

c. The IANA will maintain a public registry of the current disposition
of all IPv4 address space, detailing all reservations and current
allocations and current IANA-held address space that is unallocated.

d) The IANA may make public announcements of IPv4 address block
transactions that occur under this policy. The IANA will make
appropriate modifications to the "Internet Protocol V4 Address Space"
page of the IANA website and may make announcements to its own
appropriate announcement lists. The IANA announcements will be limited
to which address ranges, the time of allocation and to which Registry
they have been allocated.



#####

ARIN Staff Assessment

*Title: Allocation of IPv4 Blocks to the Regional Internet Registries*

*Proposal Submitted: 30 Jan 2009*

*Revision Submitted: 05 March 2009*

*Date of Assessment: 10 March 2009*

* *

I. Understanding of the Policy:

*Staff Understanding of the Proposal:*

Staff understands that this proposal would be implemented in 2 phases.
Phase 1 would require the RIRs to return recovered IPv4 legacy address
space (via policy or procedure) to the IANA and have the option of
returning recovered non-legacy address space to the IANA. Phase 2 would
start after the depletion of the IANA free pool and would nullify the
existing IANA to RIR policy (Global Addressing Policy ASO-001-2). The
new IANA to RIR policy would allow each RIR to receive approximately
1/10th of the recovered IPv4 pool from IANA once every 6 months as long
as it meets the qualification criteria written in paragraph B2. IANA
will be required to keep a log of all returned IPv4 address space and
all issued IPv4 address space from the recovered pool, as well as
maintain a public registry of the current disposition of all IPv4
address space.

II. Comments

A. ARIN Staff Comments

    * The one policy that this impacts is NRPM 4.6 Amnesty and
      Aggregation, which says ?Transactions should only be accepted
      under this policy if they are in the interests of the community
      (e.g. they improve aggregation or result in a net reclamation of
      space).? Because the ARIN region holds the majority of the legacy
      address space, and most of the address space returned under this
      policy is legacy space, it would mean that there would be no ?net
      return? of address space to ARIN. ARIN would essentially be
      exchanging legacy address space for non-legacy address space, and
      returning the legacy address space it received in the exchange to
      IANA, resulting in a net loss of address space in ARIN?s available
      pool.

B. ARIN General Counsel Comments:

The current basis of allocation of numbers was established in RFC's 2008
and 2050 and is need based. If one region has greater needs than
another, the current policy of IANA does not require equal distribution
to all RIR's s. This proposed policy would establish a different
political and not needs based method for allocating returned space. It
would make each RIR an equal recipient of such space. But the level of
need and economic activity between each RI R is not equal. This policy
will tend to reallocate returned space away from where it is recovered,
in the ARIN region , and move more of it to AFRINIC and LACNIC than
current distribution principles. By equating the smaller economies and
related needs of certain regions to the needs of other regions, like
ARIN, that have greater day to day need, it in effect creates a new
political order of distribution thru equal shares. It is possible
sovereign governments in the regions with greater activity will not
agree to such a revised distribution model. The proposed policy
undermines the legal rationale for distribution.

The policy also creates a powerful disincentive for any RIR, including
ARIN, to undertake any financial expenditure of RIR dollars for programs
intended to obtain returned space for reallocation. Currently ARIN is
working towards policies such as the LRSA and 2008-6, intended to
encourage returns and use of under utilized resources, but which cost
ARIN expenditures other RIRs are not duplicating. Any policy which
creates such a disincentive by leaving expenditures with a single RIR,
who cannot benefit except to receive 20% of the returned space should be
carefully considered.

Finally, it is likely entities with number resources in the ARIN region
may be willing to return those resources for uses in the region but
unwilling to do so if 4/5 of such resources will be sent to other regions.

III. Resource Impact

The resource impact of implementing this policy is viewed as minimal. It
is estimated that this policy could require up to 3 person months of
effort to implement following ratification by the ARIN Board of
Trustees. Because this implementation is not planned, it may preempt
ARIN?s current project deployment schedule. It may require the following:

    * Modifications to existing registration procedures to include the
      handling of returned/reclaimed address space and the process of
      requesting additional address space from the IANA.
    * Staff training

Text assessed:

*Allocation of IPv4 Blocks to Regional Internet Registries (Global)*

*Policy statement:*

This document describes the policy governing the allocation of IPv4
address space from the IANA to the Regional Internet Registries (RIRs).
This document does not stipulate performance requirements in the
provision of services by IANA to an RIR in accordance with this policy.
Such requirements should be specified by appropriate agreements among
the RIRs and ICANN.

This policy is to be implemented in two phases.

A. Phase I: Recovery of IPv4 Address Space

Upon ratification of this policy by the ICANN Board of Directors the
IANA shall establish a mechanism to receive IPv4 address space which is
returned to it by the RIRs, and hold that address space in a 'recovered
IPv4 pool'.

Each RIR through their respective chosen policies and strategies may
recover IPv4 address space which is under their administration. At
quarterly intervals, each RIR shall return any legacy address space
recovered, and may return any non-legacy address space recovered, to the
IANA in aggregated blocks of /24 or larger, for inclusion in the
recovered IPv4 pool.

During Phase I, no allocations will be made from the recovered IPv4
pool. Return of recovered address space (as described above) will
continue throughout Phase II.

B. Phase II: Allocation of Recovered IPv4 address space by the IANA

Upon ratification of this policy by the ICANN Board of Directors and a
declaration by the IANA that its existing free pool of unallocated IPv4
address space is depleted; Global Addressing Policy ASO-001-2 (adopted
by ICANN Board 8 April 2005) is rescinded. IANA will then commence to
allocate the IPv4 address space from the recovered IPv4 pool.

1. The following definitions apply to this policy:

a. Recovered Address Space. Recovered address space is that address
space that is returned to an RIR as a result of any activity that seeks
to reclaim unused address space or is voluntarily returned to the RIR or
is reclaimed by the RIR as a result of legal action or abuse
determination. Recovered address space does not include that address
space that is reclaimed because of non-payment of contractual fees whose
reclamation date is less than 1 year at the time of the report.

b. IPv4 Address Holdings. IPv4 address holdings are all unallocated IPv4
address space held by an RIR to include recovered address space not yet
returned less that address space that is committed in accordance with
the RIR's reservation policy and practices.

c. Legacy address space. IPv4 address space allocated or assigned prior
to the creation of the RIR.

2. Allocation of IPv4 Address Space

a. For the purposes of this policy, an 'IPv4 allocation period' is
defined as a 6-month period following 1 March or 1 September in each year.

b. At the beginning of each IPv4 allocation period, the IANA will
determine the 'IPv4 allocation unit' for that period, as 1/10 of its
IPv4 address pool, rounded down to the next CIDR (power-of-2) boundary.

c. In each allocation period, each RIR may issue one IPv4 request to the
IANA. Providing that the RIR satisfies the allocation criteria described
in paragraph B.2, the IANA will allocate a single allocation unit,
composed of the smallest possible number of blocks available in its IPv4
address pool.

3. IPv4 Address Space Allocation Criteria

A RIR is eligible to receive additional IPv4 address space from the IANA
when the total of its IPv4 address holdings is less than 50% of the
current IPv4 allocation unit, and providing that it has not already
received an IPv4 allocation from the IANA during the current IPv4
allocation period.

4. Initial Allocation of IPv4 Address Space

Each new RIR shall, at the moment of recognition, be allocated one (1)
allocation unit by the IANA. If an allocation unit is not available,
then the IANA will issue this block as soon as one is available. This
allocation will be made regardless of the newly formed RIR's projected
utilization figures and shall be independent of the IPv4 address space
that may have been transferred to the new RIR by the already existing
RIRs as part of the formal transition process.

5. Reporting

a. All returned space is to be recorded in an IANA-published log of IPv4
address space transactions, with each log entry detailing the returned
address block, the date of the return, and the returning RIR.

b. All allocated space is also to be recorded in this IANA-published log
of IPv4 address space transactions, with each log entry detailing the
address blocks, the date of the allocation and the recipient RIR.

c. The IANA will maintain a public registry of the current disposition
of all IPv4 address space, detailing all reservations and current
allocations and current IANA-held address space that is unallocated.

d) The IANA may make public announcements of IPv4 address block
transactions that occur under this policy. The IANA will make
appropriate modifications to the "Internet Protocol V4 Address Space"
page of the IANA website and may make announcements to its own
appropriate announcement lists. The IANA announcements will be limited
to which address ranges, the time of allocation and to which Registry
they have been allocated.







From info at arin.net  Mon Mar 23 15:06:02 2009
From: info at arin.net (Member Services)
Date: Mon, 23 Mar 2009 15:06:02 -0400
Subject: [arin-ppml] Draft Policy 2009-4: IPv4 Recovery Fund
Message-ID: <49C7DD9A.6030907@arin.net>

Draft Policy 2009-4
IPv4 Recovery Fund

The following draft policy text is being posted for feedback and
discussion on the Public Policy Mailing List (PPML).

This draft policy was developed by the ARIN Advisory Council (AC) from
Policy Proposal 80: IPv4 Recovery Fund. The AC has taken the proposal
and developed it into a draft policy. The AC was required to submit text
to ARIN for staff and legal assessment prior to selecting it as a draft
policy. The assessment, along with the text that was assessed, is
located below the draft policy.

On 20 March 2009 the ARIN Advisory Council (AC) selected Draft Policy
2009-4: IPv4 Recovery Fund for adoption discussion on the PPML and at
the upcoming Public Policy Meeting.

Draft Policy 2009-4 is below and can be found at:
https://www.arin.net/policy/proposals/2009_4.html

We encourage you to discuss Draft Policy 2009-4 on the PPML prior to the
ARIN XXIII Public Policy Meeting. Both the discussion on the PPML and at
the Public Policy Meeting will be used by the AC to determine the
community consensus regarding adopting this as policy.

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

All of the Draft Policies under discussion can be found at:
https://www.arin.net/policy/proposals/index.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy 2009-4
IPv4 Recovery Fund

Date: 23 March 2009

Policy statement:

(Create new section in section 4, represented by "4.X".)

4.X IPv4 Recovery Fund

4.X.1 Implementation Timing

Upon receiving a valid request for a block larger than ARIN
can satisfy from its existing free pool, or, by obtaining
additional space from IANA, ARIN shall begin offering financial
incentives for returned IP blocks according to this policy.

4.X.2 Recovery of IPv4 Space

ARIN believes that organizations should voluntarily return
unused and/or unneeded IP resources to the community. However,
upon implementation of this policy, ARIN will offer financial
incentives for the return of IPv4 resources to ARIN
relinquishment of any future claims to those resources. ARIN
will continue to accept voluntary returns.

4.X.3 Allocation of Recovered Space

Once approved for IPv4 space ARIN will ask the requester to
specify a bid of how much they are willing to pay for
reclamation of address space. ARIN will use this bid in
determining what incentives to offer for return of space.
The requester may make a higher bid at any time, which is
treated as a brand new bid replacing their old bid.

If ARIN recovers space and offers it to requester at or below
the specified bid within 60 days of the time the bid was
made then the bid shall be binding on requester at the price
ARIN offers the space.

4.X.4 Address Block Management

ARIN may not offer a partial fill, that is provide a block
smaller than the one for which the requester was approved.

ARIN may split recovered blocks into multiple smaller blocks
at the staff's discretion using the following principals:
- It is unlikely a request will be made for the address
block size involved in the next 60 days.
- The block is divided into as few parts as practical.
- There are enough bids to allow the entire block to be
allocated.

4.X.5 Transparency

ARIN staff shall make public the current and historical
prices of asks, bids, and executed transactions in a manor
that facilitates the bidding process. ARIN staff must
regularly report on the amount of address space obtained and
distributed via this mechanism, number of blocks subdivided,
as well as aggregate financial numbers.

4.X.6 Cost Recovery

ARIN shall manage the address space recovery program with a
goal of cost recovery.

ARIN may:
- Use ARIN funds to reclaim blocks when there is no specific
demand; if such reclamation is deemed in the best interest
of the community and there is a significant likelyhood of
future demand.
- Use a portion of the funds collected under this program
to pay for the implementation of this program.

Rationale:

Many have recognized that in order for unused or poorly used IPv4
resources to be returned to the free pool that financial compensation
will be required. This is particularly the case in poorly used assets
where the current holder may have to expend time and money to renumber
in order to free the blocks.

This proposal sets up a fund administered by ARIN to encourage the
return of space. Effectively ARIN will offer financial incentives to
return unused or poorly used IPv4 resources and place them back into the
IPv4 free pool.

The intention is for this activity to be revenue neutral to ARIN. To
achieve that goal those requesting IPv4 resources will be requested to
bid on a one-time payment to the recovery fund to cover the cost of the
resources they have received.

The proposal is intentionally vague on the exact implementation details
to staff because:

- Transactions with those returning space and obtaining space may
occur in any order.
- The bidding process may need to evolve over time, and may not
be as simple as highest bidder wins. It may include aspects such
as a dutch auction style format (all winners pay the lowest winning
price), or may include other factors such as which size blocks
ARIN has free in an effort to limit deaggregation.
- ARIN will have to develop contracts and procedures around this
activity that are better suited for staff and legal than the
policy process.

Compared to other "transfer proposals", this proposal has the following
benefits:

- Maintains that IP addresses are not property.
- Maintains the concept that unused addresses should be returned to
the free pool.
- Maintains need based addressing.
- Removes the need for those with excess resources to find those
without resources. There is no need for any sort of listing
service, eBay, etc.
- All transactions are two party transactions with ARIN as one of
the parties. The potential for multi-party legal disputes is
reduced.
- ARIN can absorb spikes in supply or demand, creating more level
prices over time.
- ARIN can provide transparency across all transactions in this
system.
- Reduces confusion to new entrants over where they should go to
receive address space.

Change Log:

- Changed "monetary" to "financial" to allow for the possibility
of ARIN offering things other than direct payment (like fee
credits). Credit: Robert Bonomi.
- Updated numbering so there were not two 4.10.2's. Also changed
to using a place holder for section. Credit: Robert Bonomi
- Changed the cost recovery language to be more clear and provide
some additional flexibility.
- Clarified 4.10.2 about future claims. Credit: Ted Mittelstaedt
- Split 10.X.3 into 10.X.3 and 10.X.3 with better titles.
- Left the exact algorithm to staff. Removed examples as a result.

Timetable for implementation:

Staff should begin developing procedures and updated templates
immediately. Policy would not go into effect until the criteria listed
occurs.



#####


ARIN Staff Assessment

* Title: IPv4 Recovery Fund*

*Proposal Submitted: 08 Jan 2009 *

*Date of Assessment: 10 March 2009*

I. Understanding of the Policy:

*Staff Understanding of the Proposal:*

ARIN understands this policy allows approved requestors of IPv4 address
space to place binding "bids" for the addresses they have been approved.

In turn, ARIN can use the monies from those bids to offer financial
incentives to registrants of address space to return unused or unneeded
addresses to the free pool for reissue to the approved requestors.

II. Comments

A. ARIN Staff Comments:

    * It is unclear to staff exactly when this policy would be
      triggered. For example, if someone is approved for a /9, and ARIN
      has only bits of fragmented space left (/10, /12, /13, etc.) which
      together could fill a /9 request, would this trigger this policy?
      In other words, can ARIN use dis-contiguous smaller blocks or
      would the requester be denied and asked to bid on a /9 that may be
      returned in the future?
    * The policy appears to say that once a request cannot be filled, a
      requester must make a bid. There does not seem to be an option of
      waiting for a block that is voluntarily returned. It would be
      helpful if the policy specified that once the policy is triggered,
      there is no opting out, if this is indeed the case.
    * Once the policy is triggered, it is difficult to tell whether
      every request must then be filled via the bid process or if
      requesters can choose not to use it. Again, it would be helpful if
      this were specifically spelled out in the policy text.
    * Under section 4.X.3 what would happen if a requester doesn't pay
      the bid amount they committed to? If ARIN is paying the money up
      front for that address space but is unable to collect that amount
      back, it could put ARIN at some financial risk.
    * The bidding process as laid out in section 4.X.3 is somewhat
      confusing. There is no mention made of a situation where there are
      two bidders competing for the same address space. Would ARIN
      automatically award the space to the highest bidder? If so, could
      that be viewed as an unfair process that rewards those with the
      most monetary resources?
    * If someone return's space without monetary compensation in the
      midst of this, it is not clear whether ARIN would then offer that
      address space under the current fee structure or under this bid
      structure.
    * The term "cost recovery? in section 4x6 should be clearly defined.
      Specifically, this states that we can use "a portion" of the funds
      collected to recover space even when there is no demand.
    * Is there anything to prohibit out of region bidders? ARIN?s
      current practice is to issue address space only to organizations
      that will be using that space within ARIN?s region. If anyone can
      bid on this space from any region, it will represent a fundamental
      change in the way we operate today.
    * This policy would change ARIN?s current financial and business
      models and would significantly impact the way we do business today.
    * This policy could be a disincentive for people to voluntarily
      return IP address space, which is something that people do on a
      somewhat regular basis today.

B. ARIN General Counsel Comments:

Nothing in ARIN's Articles of Incorporation or Bylaws prevents ARIN from
implementing this policy.  However, this policy would represent a major
shift in ARIN's activities by requiring ARIN to build business
capabilities and undertake legal risks quite different from ARIN's
existing business and expertise.

In particular, this proposal would require that ARIN staff exercise
skills as traders -- e.g. buying IPv4 resource when they think they
should buy, selling when they think they should sell.  The required
skills are not unlike those involved in running a hedge fund or,
perhaps, the US government role in buying Strategic Petroleum Reserve
assets. The required skills are quite different from ARIN's core competency.

This proposal would also introduce potentially capital requirements --
causing ARIN to invest its funds in purchases of v4 resource in
anticipation of future sales.  As a nonprofit with a limited financial
reserve, ARIN faces an important financial risk from such transactions,
in that ARIN could lose significant funds if IPv4 prices do not evolve
as ARIN staff anticipate.

The proposal is relatively silent on the specifics of ARIN's
decision-making process for allocating the IPv4 resources ARIN obtains
through this process.  While it may be appropriate to delegate those
decisions to staff, it is difficult to legally assess the proposal
without a vision of the decision rules ARIN would use in allocating
scarce space among multiple prospective recipients.  Moreover, because
many potential recipients will urgently want additional v4 space, such
decisions are likely to be closely scrutinized, and ARIN would need a
clear and compelling reason to choose to grant space purchased to one
recipient rather than another.

This proposal also exposes ARIN to significant and unameliorated legal
risk. For example, in each potential transfer, ARIN participates at
least twice on "good" transactions that go well -- one to receive space
from an original provider, then a second time to transfer that space to
an ultimate recipient.  But each transaction performed presents legal
risk.  For example, if a putative provider promises to transfer, but
reneges, ARIN might find itself having to sue to compel such sale.

Conversely, if a putative provider wants to sell ARIN addresses at a
given price, but ARIN is unwilling to pay that price, the provider might
sue ARIN, alleging that ARIN's decision to reject that price was
wrongful.  (The provider might ground its case in a purchase it sees as
similar, in which some other provider received that price.)  As to
recipients, ARIN might face liability from those who wanted v4 resource
but did not receive it (at the prices they sought to offer), and ARIN
might feel compelled to enter litigation if a recipient ultimately
refuses to pay for resources it received.  In short, ARIN would face
important legal risks both due to the multiple sequential transactions
and due to disputes potentially resulting from ARIN's significant
decision-making discretion as to the purchase and allocation of v4 resource.

These risks may be worth accepting in order to get the benefits of
address transfers.  However, ARIN faces significantly less legal risk
from a other proposed decentralized markets where ARIN's role is not
central (e.g. , see the market portion of an abandoned policy, 2008-6)
in which address providers and recipients were left to their own
resources to reach agreements directly between one another, without ARIN
serving to receive and transfer all resources and all associated funds.


III. Resource Impact

The resource impact of implementing this policy is viewed as
significant. It is estimated that this policy could require up to 18
person months of effort to implement following ratification by the ARIN
Board of Trustees. Because this implementation is not planned, it may
preempt ARIN?s current project deployment schedule. It may require the
following:

    * The development of a tracking system to monitor the transaction,
      both the purchase and the sale, as well as the inventory.
    * The development of a reporting system.
    * Modifications to ARIN?s existing business model would be needed,
      particularly if ARIN gets into the business of buying back address
      space which then becomes designated as an asset and inventory.
    * Increased fees due to potential litigation, legal costs, and
      collection costs
    * Modifications to existing registration procedures
    * Staff training
    * Guidelines updates

Text assessed:

Policy Proposal Name: IPv4 Recovery Fund

*Policy statement:*

* (Create new section in section 4, represented by "4.X".)*

*4.X IPv4 Recovery Fund*

4.X.1 Implementation Timing

Upon receiving a valid request for a block larger than ARIN

can satisfy from its existing free pool, or, by obtaining

additional space from IANA, ARIN shall begin offering financial

incentives for returned IP blocks according to this policy.

4.X.2 Recovery of IPv4 Space

ARIN believes that organizations should voluntarily return

unused and/or unneeded IP resources to the community. However,

upon implementation of this policy, ARIN will offer financial

incentives for the return of IPv4 resources to ARIN

relinquishment of any future claims to those resources. ARIN

will continue to accept voluntary returns.

4.X.3 Allocation of Recovered Space

Once approved for IPv4 space ARIN will ask the requester to

specify a bid of how much they are willing to pay for

reclamation of address space. ARIN will use this bid in

determining what incentives to offer for return of space.

The requester may make a higher bid at any time, which is

treated as a brand new bid replacing their old bid.

If ARIN recovers space and offers it to requester at or below

the specified bid within 60 days of the time the bid was

made then the bid shall be binding on requester at the price

ARIN offers the space.

4.X.4 Address Block Management

ARIN may not offer a partial fill, that is provide a block

smaller than the one for which the requester was approved.

ARIN may split recovered blocks into multiple smaller blocks

at the staff's discretion using the following principals:

- It is unlikely a request will be made for the address

block size involved in the next 60 days.

- The block is divided into as few parts as practical.

- There are enough bids to allow the entire block to be

allocated.

4.X.5 Transparency

ARIN staff shall make public the current and historical

prices of asks, bids, and executed transactions in a manor

that facilitates the bidding process. ARIN staff must

regularly report on the amount of address space obtained and

distributed via this mechanism, number of blocks subdivided,

as well as aggregate financial numbers.

4.X.6 Cost Recovery

ARIN shall manage the address space recovery program with a

goal of cost recovery.

ARIN may:

- Use ARIN funds to reclaim blocks when there is no specific

demand; if such reclamation is deemed in the best interest

of the community and there is a significant likelyhood of

future demand.

- Use a portion of the funds collected under this program

to pay for the implementation of this program.







From scottleibrand at gmail.com  Mon Mar 23 16:03:27 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Mon, 23 Mar 2009 13:03:27 -0700
Subject: [arin-ppml] Draft Policy 2009-3 (Global): Allocation of IPv4
 Blocks to Regional Internet Registries
In-Reply-To: <49C7DD87.4010508@arin.net>
References: <49C7DD87.4010508@arin.net>
Message-ID: <49C7EB0F.3030800@gmail.com>

As the primary AC shepherd for this proposal, I'd like to give a little 
more background on the changes we made to the originators' original 
proposed text.

The main concern expressed with this proposal to date is that it 
requires ARIN to return recovered address space to IANA, thereby 
removing most of the incentive for ARIN to recover that space in the 
first place.  In addition, there were a number of concerns expressed 
about unnecessarily splitting up the blocks allocated to ARIN, when ARIN 
could simply reassign any returned space out to new recipients.

To address these concerns, I see a couple of options.  One would be to 
make the return of recovered space completely optional.  This might be 
best for ARIN, but might also make the policy all but useless.  It would 
also raise global issues of fairness, since ARIN holds most of the 
legacy address space allocated before ARIN existed.  So another option 
would be to require return of recovered legacy address space, while 
making return of non-legacy space optional.  The latter is the option 
reflected in the text below:

    d. Legacy address space. IPv4 address space allocated or assigned 
prior to the creation of the RIR.

    Each RIR through their respective chosen policies and strategies may 
recover IPv4 address space which is under their administration. At 
quarterly intervals, each RIR shall return to the IANA any legacy 
address space recovered, and may return to the IANA any non-legacy 
address space recovered, in aggregated blocks of /24 or larger, for 
inclusion in the recovered IPv4 pool.

In addition, we added the following, which is intended to be a 
clarification, but may reflect a different understanding of the phases:

    Return of recovered address space (as described above) will continue 
throughout Phase II. 

I would love to get feedback from PPML on the following questions:

 - What do you think of the general idea behind this proposal?
 - Do you think returns should be mandatory or optional?  Would you 
distinguish between legacy and non-legacy space?
 - Do you have any other detailed feedback on specific aspects of this 
draft policy?

Thanks,
Scott

Member Services wrote:
> Draft Policy 2009-3 (Global)
> Allocation of IPv4 Blocks to Regional Internet Registries
>
> The following draft policy text is being posted for feedback and
> discussion on the Public Policy Mailing List (PPML).
>
> This draft policy was developed by the ARIN Advisory Council (AC) from
> Policy Proposal 82: Allocation of IPv4 Blocks to Regional Internet
> Registries. The AC has taken the proposal and developed it into a draft
> policy. The AC was required to submit text to ARIN for staff and legal
> assessment prior to selecting it as a draft policy. The assessment,
> along with the text that was assessed, is located below the draft policy.
>
> On 20 March 2009 the ARIN Advisory Council (AC) selected Draft Policy
> 2009-3: Allocation of IPv4 Blocks to Regional Internet Registries for
> adoption discussion on the PPML and at the upcoming Public Policy Meeting.
>
> Draft Policy 2009-3 is below and can be found at:
> https://www.arin.net/policy/proposals/2009_3.html
>
> We encourage you to discuss Draft Policy 2009-3 on the PPML prior to the
> ARIN XXIII Public Policy Meeting. Both the discussion on the PPML and at
> the Public Policy Meeting will be used by the AC to determine the
> community consensus regarding adopting this as policy.
>
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
>
> All of the Draft Policies under discussion can be found at:
> https://www.arin.net/policy/proposals/index.html
>
> Regards,
>
> Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Draft Policy 2009-3 (Global)
> Allocation of IPv4 Blocks to Regional Internet Registries
>
> Date: 23 March 2009
>
> Policy statement:
>
> This document describes the policy governing the allocation of IPv4
> address space from the IANA to the Regional Internet Registries (RIRs).
> This document does not stipulate performance requirements in the
> provision of services by IANA to an RIR in accordance with this policy.
> Such requirements should be specified by appropriate agreements among
> the RIRs and ICANN.
>
> This policy is to be implemented in two phases.
>
> A. Phase I: Recovery of IPv4 Address Space
>
> Upon ratification of this policy by the ICANN Board of Directors the
> IANA shall establish a mechanism to receive IPv4 address space which is
> returned to it by the RIRs, and hold that address space in a 'recovered
> IPv4 pool'.
>
> Each RIR through their respective chosen policies and strategies may
> recover IPv4 address space which is under their administration. At
> quarterly intervals, each RIR shall return to the IANA any legacy
> address space recovered, and may return to the IANA any non-legacy
> address space recovered, in aggregated blocks of /24 or larger, for
> inclusion in the recovered IPv4 pool.
>
> During Phase I, no allocations will be made from the recovered IPv4
> pool. Return of recovered address space (as described above) will
> continue throughout Phase II.
>
> B. Phase II: Allocation of Recovered IPv4 address space by the IANA
>
> Upon ratification of this policy by the ICANN Board of Directors and a
> declaration by the IANA that its existing free pool of unallocated IPv4
> address space is depleted; Global Addressing Policy ASO-001-2 (adopted
> by ICANN Board 8 April 2005) is rescinded. IANA will then commence to
> allocate the IPv4 address space from the recovered IPv4 pool.
>
> 1. The following definitions apply to this policy:
>
> a. Recovered Address Space. Recovered address space is that address
> space that is returned to an RIR as a result of any activity that seeks
> to reclaim unused address space or is voluntarily returned to the RIR or
> is reclaimed by the RIR as a result of legal action or abuse
> determination. Recovered address space does not include that address
> space that is reclaimed because of non-payment of contractual fees whose
> reclamation date is less than 1 year at the time of the report.
>
> b. IPv4 Address Holdings. IPv4 address holdings are all unallocated IPv4
> address space held by an RIR to include recovered address space not yet
> returned less that address space that is committed in accordance with
> the RIR's reservation policy and practices.
>
> c. Aggregated address blocks. Aggregated address blocks are contiguous
> prefixes that can be aggregated on natural bit boundaries. 10.0.0.0/24
> and 10.0.1.0/24 are two contiguous prefixes that can be combined to form
> an aggregated address block. 10.0.0.0/24 and 10.0.1.0/25 are two
> contiguous prefixes that cannot be combined on a natural bit boundary to
> form an aggregated block.
>
> d. Legacy address space. IPv4 address space allocated or assigned prior
> to the creation of the RIR.
>
> 2. Allocation of IPv4 Address Space
>
> a. For the purposes of this policy, an 'IPv4 allocation period' is
> defined as a 6-month period following 1 March or 1 September in each year.
>
> b. At the beginning of each IPv4 allocation period, the IANA will
> determine the 'IPv4 allocation unit' for that period, as 1/10 of its
> IPv4 address pool, rounded down to the next CIDR (power-of-2) boundary.
> The minimum 'IPv4 allocation unit' size will be a /24.
>
> c. In each allocation period, each RIR may issue one IPv4 request to the
> IANA. Providing that the RIR satisfies the allocation criteria described
> in paragraph B.2, the IANA will allocate a single allocation unit,
> composed of the smallest possible number of blocks available in its IPv4
> address pool.
>
> 3. IPv4 Address Space Allocation Criteria
>
> A RIR is eligible to receive additional IPv4 address space from the IANA
> when the total of its IPv4 address holdings is less than 50% of the
> current IPv4 allocation unit, and providing that it has not already
> received an IPv4 allocation from the IANA during the current IPv4
> allocation period.
>
> 4. Initial Allocation of IPv4 Address Space
>
> Each new RIR shall, at the moment of recognition, be allocated one (1)
> allocation unit by the IANA. If an allocation unit is not available,
> then the IANA will issue this block as soon as one is available. This
> allocation will be made regardless of the newly formed RIR's projected
> utilization figures and shall be independent of the IPv4 address space
> that may have been transferred to the new RIR by the already existing
> RIRs as part of the formal transition process.
>
> 5. Reporting
>
> a. All returned space is to be recorded in an IANA-published log of IPv4
> address space transactions, with each log entry detailing the returned
> address block, the date of the return, and the returning RIR.
>
> b. All allocated space is also to be recorded in this IANA-published log
> of IPv4 address space transactions, with each log entry detailing the
> address blocks, the date of the allocation and the recipient RIR.
>
> c. The IANA will maintain a public registry of the current disposition
> of all IPv4 address space, detailing all reservations and current
> allocations and current IANA-held address space that is unallocated.
>
> d) The IANA may make public announcements of IPv4 address block
> transactions that occur under this policy. The IANA will make
> appropriate modifications to the "Internet Protocol V4 Address Space"
> page of the IANA website and may make announcements to its own
> appropriate announcement lists. The IANA announcements will be limited
> to which address ranges, the time of allocation and to which Registry
> they have been allocated.
>
>
>
> #####
>
> ARIN Staff Assessment
>
> *Title: Allocation of IPv4 Blocks to the Regional Internet Registries*
>
> *Proposal Submitted: 30 Jan 2009*
>
> *Revision Submitted: 05 March 2009*
>
> *Date of Assessment: 10 March 2009*
>
> * *
>
> I. Understanding of the Policy:
>
> *Staff Understanding of the Proposal:*
>
> Staff understands that this proposal would be implemented in 2 phases.
> Phase 1 would require the RIRs to return recovered IPv4 legacy address
> space (via policy or procedure) to the IANA and have the option of
> returning recovered non-legacy address space to the IANA. Phase 2 would
> start after the depletion of the IANA free pool and would nullify the
> existing IANA to RIR policy (Global Addressing Policy ASO-001-2). The
> new IANA to RIR policy would allow each RIR to receive approximately
> 1/10th of the recovered IPv4 pool from IANA once every 6 months as long
> as it meets the qualification criteria written in paragraph B2. IANA
> will be required to keep a log of all returned IPv4 address space and
> all issued IPv4 address space from the recovered pool, as well as
> maintain a public registry of the current disposition of all IPv4
> address space.
>
> II. Comments
>
> A. ARIN Staff Comments
>
>     * The one policy that this impacts is NRPM 4.6 Amnesty and
>       Aggregation, which says ?Transactions should only be accepted
>       under this policy if they are in the interests of the community
>       (e.g. they improve aggregation or result in a net reclamation of
>       space).? Because the ARIN region holds the majority of the legacy
>       address space, and most of the address space returned under this
>       policy is legacy space, it would mean that there would be no ?net
>       return? of address space to ARIN. ARIN would essentially be
>       exchanging legacy address space for non-legacy address space, and
>       returning the legacy address space it received in the exchange to
>       IANA, resulting in a net loss of address space in ARIN?s available
>       pool.
>
> B. ARIN General Counsel Comments:
>
> The current basis of allocation of numbers was established in RFC's 2008
> and 2050 and is need based. If one region has greater needs than
> another, the current policy of IANA does not require equal distribution
> to all RIR's s. This proposed policy would establish a different
> political and not needs based method for allocating returned space. It
> would make each RIR an equal recipient of such space. But the level of
> need and economic activity between each RI R is not equal. This policy
> will tend to reallocate returned space away from where it is recovered,
> in the ARIN region , and move more of it to AFRINIC and LACNIC than
> current distribution principles. By equating the smaller economies and
> related needs of certain regions to the needs of other regions, like
> ARIN, that have greater day to day need, it in effect creates a new
> political order of distribution thru equal shares. It is possible
> sovereign governments in the regions with greater activity will not
> agree to such a revised distribution model. The proposed policy
> undermines the legal rationale for distribution.
>
> The policy also creates a powerful disincentive for any RIR, including
> ARIN, to undertake any financial expenditure of RIR dollars for programs
> intended to obtain returned space for reallocation. Currently ARIN is
> working towards policies such as the LRSA and 2008-6, intended to
> encourage returns and use of under utilized resources, but which cost
> ARIN expenditures other RIRs are not duplicating. Any policy which
> creates such a disincentive by leaving expenditures with a single RIR,
> who cannot benefit except to receive 20% of the returned space should be
> carefully considered.
>
> Finally, it is likely entities with number resources in the ARIN region
> may be willing to return those resources for uses in the region but
> unwilling to do so if 4/5 of such resources will be sent to other regions.
>
> III. Resource Impact
>
> The resource impact of implementing this policy is viewed as minimal. It
> is estimated that this policy could require up to 3 person months of
> effort to implement following ratification by the ARIN Board of
> Trustees. Because this implementation is not planned, it may preempt
> ARIN?s current project deployment schedule. It may require the following:
>
>     * Modifications to existing registration procedures to include the
>       handling of returned/reclaimed address space and the process of
>       requesting additional address space from the IANA.
>     * Staff training
>
> Text assessed:
>
> *Allocation of IPv4 Blocks to Regional Internet Registries (Global)*
>
> *Policy statement:*
>
> This document describes the policy governing the allocation of IPv4
> address space from the IANA to the Regional Internet Registries (RIRs).
> This document does not stipulate performance requirements in the
> provision of services by IANA to an RIR in accordance with this policy.
> Such requirements should be specified by appropriate agreements among
> the RIRs and ICANN.
>
> This policy is to be implemented in two phases.
>
> A. Phase I: Recovery of IPv4 Address Space
>
> Upon ratification of this policy by the ICANN Board of Directors the
> IANA shall establish a mechanism to receive IPv4 address space which is
> returned to it by the RIRs, and hold that address space in a 'recovered
> IPv4 pool'.
>
> Each RIR through their respective chosen policies and strategies may
> recover IPv4 address space which is under their administration. At
> quarterly intervals, each RIR shall return any legacy address space
> recovered, and may return any non-legacy address space recovered, to the
> IANA in aggregated blocks of /24 or larger, for inclusion in the
> recovered IPv4 pool.
>
> During Phase I, no allocations will be made from the recovered IPv4
> pool. Return of recovered address space (as described above) will
> continue throughout Phase II.
>
> B. Phase II: Allocation of Recovered IPv4 address space by the IANA
>
> Upon ratification of this policy by the ICANN Board of Directors and a
> declaration by the IANA that its existing free pool of unallocated IPv4
> address space is depleted; Global Addressing Policy ASO-001-2 (adopted
> by ICANN Board 8 April 2005) is rescinded. IANA will then commence to
> allocate the IPv4 address space from the recovered IPv4 pool.
>
> 1. The following definitions apply to this policy:
>
> a. Recovered Address Space. Recovered address space is that address
> space that is returned to an RIR as a result of any activity that seeks
> to reclaim unused address space or is voluntarily returned to the RIR or
> is reclaimed by the RIR as a result of legal action or abuse
> determination. Recovered address space does not include that address
> space that is reclaimed because of non-payment of contractual fees whose
> reclamation date is less than 1 year at the time of the report.
>
> b. IPv4 Address Holdings. IPv4 address holdings are all unallocated IPv4
> address space held by an RIR to include recovered address space not yet
> returned less that address space that is committed in accordance with
> the RIR's reservation policy and practices.
>
> c. Legacy address space. IPv4 address space allocated or assigned prior
> to the creation of the RIR.
>
> 2. Allocation of IPv4 Address Space
>
> a. For the purposes of this policy, an 'IPv4 allocation period' is
> defined as a 6-month period following 1 March or 1 September in each year.
>
> b. At the beginning of each IPv4 allocation period, the IANA will
> determine the 'IPv4 allocation unit' for that period, as 1/10 of its
> IPv4 address pool, rounded down to the next CIDR (power-of-2) boundary.
>
> c. In each allocation period, each RIR may issue one IPv4 request to the
> IANA. Providing that the RIR satisfies the allocation criteria described
> in paragraph B.2, the IANA will allocate a single allocation unit,
> composed of the smallest possible number of blocks available in its IPv4
> address pool.
>
> 3. IPv4 Address Space Allocation Criteria
>
> A RIR is eligible to receive additional IPv4 address space from the IANA
> when the total of its IPv4 address holdings is less than 50% of the
> current IPv4 allocation unit, and providing that it has not already
> received an IPv4 allocation from the IANA during the current IPv4
> allocation period.
>
> 4. Initial Allocation of IPv4 Address Space
>
> Each new RIR shall, at the moment of recognition, be allocated one (1)
> allocation unit by the IANA. If an allocation unit is not available,
> then the IANA will issue this block as soon as one is available. This
> allocation will be made regardless of the newly formed RIR's projected
> utilization figures and shall be independent of the IPv4 address space
> that may have been transferred to the new RIR by the already existing
> RIRs as part of the formal transition process.
>
> 5. Reporting
>
> a. All returned space is to be recorded in an IANA-published log of IPv4
> address space transactions, with each log entry detailing the returned
> address block, the date of the return, and the returning RIR.
>
> b. All allocated space is also to be recorded in this IANA-published log
> of IPv4 address space transactions, with each log entry detailing the
> address blocks, the date of the allocation and the recipient RIR.
>
> c. The IANA will maintain a public registry of the current disposition
> of all IPv4 address space, detailing all reservations and current
> allocations and current IANA-held address space that is unallocated.
>
> d) The IANA may make public announcements of IPv4 address block
> transactions that occur under this policy. The IANA will make
> appropriate modifications to the "Internet Protocol V4 Address Space"
> page of the IANA website and may make announcements to its own
> appropriate announcement lists. The IANA announcements will be limited
> to which address ranges, the time of allocation and to which Registry
> they have been allocated.
>
>
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>   


From Matthew.Wilder at telus.com  Mon Mar 23 17:30:27 2009
From: Matthew.Wilder at telus.com (Matthew Wilder)
Date: Mon, 23 Mar 2009 15:30:27 -0600
Subject: [arin-ppml] Draft Policy 2009-2: Depleted IPv4 reserves
References: <49C7DD7B.5000901@arin.net> 
Message-ID: <DE229826F48ABD4CBF754E5AA6CFC14B1DDA22280E@WP40044.corp.ads>

I think there is definitely a place for a policy somehow limiting the size of allocations when there is less than 6 months to go in projected ARIN IP Address reserves.  I think a maximum allocation size of /20 is going to be too limiting for large ISPs (full disclosure, I work for TELUS, a large Canadian ISP).  This policy is unusually biased against the largest consumers of IP addresses.  I may have read the policy proposal wrong, but it also looked like a /20 is the most an organization will get in a 6 month period.  That would be even more limiting.

(NOTE: if you get tired of reading this long-winded feedback, skip to my suggestion)

*******My feedback:*******
Using the statistics page, it can be seen that the vast majority of IP Address space in 2006 and 2007 went to 24 organizations.  Among other factors, I would suggest that the reason this is actually good is that large ISPs can efficiently utilize IP Addresses in the way IP address space is given to end users (including DHCP).

Last year, someone used a gas station analogy to depict the system that ARIN and ISPs and EUs constitute.  ARIN (the gas station) controls the IP Addresses (the fuel) which are distributed to those (ISPs and EUs) in need of IP addresses (fuel).  Using this analogy, I recall someone making a statement that all the people with civics will be totally left out when the bug SUVs (large ISPs) are sucking up the last of the fuel.  That analogy is off the mark first of all because large ISPs probably utilize IP Address space more efficiently than the average ISP or EU, where SUVs, well, they aren't the model of efficiency.  The second way this analogy is a bit misleading is that it represents SUVs as coming in at the last minute to take all of what is left, when the SUVs are only one of many consumers of IP Address space.

Again considering the statistics page, over 80% of address allocations in 2006 and 2007 went to 24 organizations, roughly 1% of the organizations.  So these would not be the organizations coming out of nowhere to take what is left of the unallocated IPv4 space.  I imagine that the other thousands of organization covered by ARIN would be the ones who might come up to ARIN in 2011 or 2012 and load up on their last block of IPv4 space, which may last them 6 years, let alone 6 months.

On the other hand, large ISPs who are the most consistent consumers of IP Addresses would be told to accept a block of IP Addresses that will last them 6 weeks, maybe even 6 days.

*******My suggestion:*******
I think this policy has its place.  I think the limit should focus not on a particular subnet size, but on the historical allocations to an organization and the projected utilization of the block being requested.  The allocation should target satisfaction of 3 months of the ISP's requirement.  For example, an organization that usually consumes space totalling a /15 every year should be granted a /17 which will probably last for 3 months of projected requirements.  This is certainly a little harder to put into writing, but I think it offers greater fairness.

Thanks for reading!

Cheers,
Matthew Wilder


-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services
Sent: Monday, March 23, 2009 12:06 PM
To: arin-ppml at arin.net
Subject: [arin-ppml] Draft Policy 2009-2: Depleted IPv4 reserves

Draft Policy 2009-2
Depleted IPv4 reserves

The following draft policy text is being posted for feedback and discussion on the Public Policy Mailing List (PPML).

This draft policy was developed by the ARIN Advisory Council (AC) from Policy Proposal 81: Depleted IPv4 reserves. The AC has taken the proposal and developed it into a draft policy. The AC was required to submit text to ARIN for staff and legal assessment prior to selecting it as a draft policy. The assessment, along with the text that was assessed, is located below the draft policy.

On 20 March 2009 the ARIN Advisory Council (AC) selected Draft Policy
2009-2: Depleted IPv4 reserves for adoption discussion on the PPML and at the upcoming Public Policy Meeting.

Draft Policy 2009-2 is below and can be found at:
https://www.arin.net/policy/proposals/2009_2.html

We encourage you to discuss Draft Policy 2009-2 on the PPML prior to the ARIN XXIII Public Policy Meeting. Both the discussion on the PPML and at the Public Policy Meeting will be used by the AC to determine the community consensus regarding adopting this as policy.

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

All of the Draft Policies under discussion can be found at:
https://www.arin.net/policy/proposals/index.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy 2009-2
Depleted IPv4 reserves

Date: 23 March 2009

Policy statement:

(add the following section to the NRPM)

4.1.8 Depleted IPv4 reserves

A limit will be applied to all IPv4 address requests when ARIN's reserve of unallocated IPv4 address space drops below an equivalent /9. When this happens, an ISP or End User may receive up to a single /20 within a six month period. This restriction will be lifted in the event the reserve of unallocated IPv4 address space increases to an equivalent /7.

Rationale:

As the reserve of IPv4 address space becomes smaller, there is a risk that many organizations will be denied resources by a large, last minute request. By implementing a throttle on the last of the IPv4 address space, a more limited group of organizations will be impacted, allowing many organizations to receive ongoing resources during the transition to IPv6.

According to the ARIN statistics page
http://www.arin.net/statistics/index.html, 1,993 organizations were issued IP space in 2006 and 2007. Of these allocations 41% of the applicants received less than a /20. On the opposite end, 82 organizations received large blocks. Given that the last reserve of IPv4 space cannot possibly meet the needs of the 82 organizations, the space could be managed in a way to provide for the needs of a wider base of consumers while the largest ISPs build momentum behind IPv6.

The goal is to find a balance between the needs of organizations requiring space, and avoiding the restrictions on end user growth. For this reason, any caps on allocations should be implemented when the reserves are essentially depleted, rather than trying to restrict end user growth when IP space is still readily available.

By putting a six month window on the maximum allocation, the remaining IP space could provide at least one year for everyone to implement other solutions while still being able to obtain an IPv4 address allocation.
The time period was also added to provide a consistent rate of depletion, avoiding a scenario where a large organization could queue multiple, justifiable requests, resulting in the scenario the proposal is intended to avoid.

Additional language may need to be added in the event a paid transfer policy is approved. The thinking is to have two pools of available IP.
One being the current, IANA allocated, reserve of IP space. The second being IP blocks recovered through monetary incentive. This proposal would apply to the IANA allocated reserves and would not apply to blocks made available by monetary means.

An additional thought was to avoid tying this policy shift specifically to the last /8 allocated by IANA. This allows the policy to come in and out of play in the event that IPv4 address space is abandoned or returned to ARIN.

Timetable for implementation: Immediate



#####


ARIN Staff Assessment

*Title: Depleted IPv4 Reserves*

*Proposal Submitted: 02 Dec 2008*

*Revision Submitted: 16 Feb 2009*

*Date of Assessment: 10 March 2009*

I. Understanding of the Policy:

*Staff Understanding of the Proposal:*

ARIN understands this policy goes into effect when ARIN has less than a
/9 worth of IPv4 address space available to be issued to customers. At that time, an ISP or End user can only receive a /20 from ARIN within a six month period. This restriction will be removed if ARIN's available pool of addresses increases to a /7 equivalent.

II. Comments:

A. ARIN Staff Comments:

          o One question to consider is whether staff should be setting
            aside a /9 in anticipation of this policy. If that is not
            done, there is the potential that one large request could
            take away a very large block of ARIN's remaining inventory
            and leave us with far less than the /9 equivalent needed to
            implement this policy. For example, if there is one /8 left,
            and ISP A qualifies for a /8, and it gets issued, then there
            will be no address space left to issue under this policy.
                + If the intent is to make sure there is at least a /9
                  available to give out in /20 blocks, then the trigger
                  point may need to be reconsidered. Here are two
                  potential options:
                      # Trigger the policy when filling a request would
                        drop the supply below a /9
                      # Give the org whose request would drop the supply
                        below a /9 as many addresses as would take us to
                        a /9, then trigger the policy.

B. ARIN General Counsel Comments:

The policy does not pose any significant legal risk to ARIN. A community decision to segment the remaining unissued IPV4 numbers to serve a larger number of users on its face does not discriminate against or for any user, large or small. Therefore it is legally unobjectionable. It is a rational scheme for distribution reasonably related to meeting the needs of as many end users as possible. Counsel respectfully suggests that the policy as drafted may contain potential seeds of confusion by providing for switching back to current distribution policies, and then back to this policy.

III. Resource Impact

The resource impact of implementing this policy is viewed as minimal. It is estimated that this policy could require up to 3 person months of effort to implement following ratification by the ARIN Board of Trustees. Because this implementation is not planned, it may preempt ARIN's current project deployment schedule. It may require the following:

    * Guidelines Changes
    * Modifications to existing registration software tools - they need
      to be able to report to staff existing inventory levels and to
      notify us when the /9 threshold is reached or is imminent.

Text assessed:

Depleted IPv4 reserves

*Policy statement:*

4.1.8 Depleted IPv4 reserves

A limit will be applied to all IPv4 address requests when ARIN's reserve of unallocated IPv4 address space drops below an equivalent /9. When this happens, an ISP or End User may receive up to a single /20 within a six month period. This restriction will be lifted in the event the reserve of unallocated IPv4 address space increases to an equivalent /7.





_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.


From owen at delong.com  Mon Mar 23 18:18:19 2009
From: owen at delong.com (Owen DeLong)
Date: Mon, 23 Mar 2009 15:18:19 -0700
Subject: [arin-ppml] Draft Policy 2009-2: Depleted IPv4 reserves
In-Reply-To: <DE229826F48ABD4CBF754E5AA6CFC14B1DDA22280E@WP40044.corp.ads>
References: <49C7DD7B.5000901@arin.net>
	<DE229826F48ABD4CBF754E5AA6CFC14B1DDA22280E@WP40044.corp.ads>
Message-ID: <4D639F66-9B64-4FF0-BC3A-B8B64430402A@delong.com>

Matthew,
	Thanks for your input.  Some counterpoints to what you have said that  
I would
like to see some feedback on:

	1.	Once ARIN reserves drop below, say, a /9, that means that ARIN would
		only be able to satisfy a maximum of 32 x-large (/14) requests.  Given
		that you state there are 24 organizations that suck down 80% of
		ARIN resources, I think those organizations are going to have to
		face some rather severe limitations soon after we reach that point
		either through this policy, or, as the result of ARIN being completely
		out of addresses.

	2.	If those extra large organizations are restricted, along with  
everyone
		else, to getting only a /20 per 6 month period thereafter, yes, they
		will be suffering an address shortage, along with everyone else, but,
		they will at least be able to get some addresses for some period of
		time, and, a much larger number of organizations will be able to get
		SOME of their needs met. The assumption that smaller organizations
		will qualify for enough address space for 6 years is, in most cases
		specious and misleading. This policy would not give a /20 to someone
		who would normally qualify only for a /22 based on a 1 year  
projection.

	3.	I  believe the central question raised by this policy is how does  
the
		community want to prioritize the IPv4 end game.  Do we want to
		provide as much as needed on a first-come-first-serve basis until
		we run head-long into the brick wall where nobody can get anything,
		or, do we want to reach a threshold where we face an address
		shortage for some time before we hit absolute runout.

Owen





From martin.hannigan at batelnet.bs  Mon Mar 23 18:34:04 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Mon, 23 Mar 2009 18:34:04 -0400
Subject: [arin-ppml] Draft Policy 2009-3 (Global): Allocation of IPv4
	Blocks to Regional Internet Registries
In-Reply-To: <49C7EB0F.3030800@gmail.com>
References: <49C7DD87.4010508@arin.net> <49C7EB0F.3030800@gmail.com>
Message-ID: <4607e1d50903231534i676bd704r86368962108253dc@mail.gmail.com>

On Mon, Mar 23, 2009 at 4:03 PM, Scott Leibrand <scottleibrand at gmail.com>wrote:

[ clip ]


>
>
> I would love to get feedback from PPML on the following questions:
>
>  - What do you think of the general idea behind this proposal?


Based on the summaries, I think that creating token policies should be
discouraged.  It clouds the message of transitioning to v6.

Best,

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090323/038f0120/attachment.htm>

From kmedcalf at dessus.com  Mon Mar 23 20:18:36 2009
From: kmedcalf at dessus.com (Keith Medcalf)
Date: Mon, 23 Mar 2009 20:18:36 -0400
Subject: [arin-ppml] Draft Policy 2008-7: Identify Invalid WHOIS POC's
In-Reply-To: <49C7DD6E.3010106@arin.net>
Message-ID: <1f08e8ae3c9c4f4bb0e002f1a1a40c20@mail.dessus.com>


> During ARINs annual WHOIS POC validation, an e-mail will be sent to
> every POC in the WHOIS database. Each POC will have a maximum 
> of 60 days to respond with an affirmative that their WHOIS contact 
> information is correct and complete. Unresponsive POC email addresses 
> shall be marked as such in the database. If ARIN staff deems a POC 
> to be completely and permanently abandoned or otherwise illegitimate, 
> the record shall be deleted.

Policy should clearly require that the email message:
 - MUST be in text/plain format (MUST NOT be HTML)
 - MUST be sent from a system which has valid meshed forward and reverse DNS
 - MUST originate from the ARIN.NET domain

That is, in order to qualify as an "e-mail" then absolutely strict RFC compliance shall be required for the SMTP mailer, and the message itself must be text/plain.

Otherwise, "spam discard" may be confused with "un-responsive"

-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org 
 






From owen at delong.com  Mon Mar 23 21:37:00 2009
From: owen at delong.com (Owen DeLong)
Date: Mon, 23 Mar 2009 18:37:00 -0700
Subject: [arin-ppml] Draft Policy 2008-7: Identify Invalid WHOIS POC's
In-Reply-To: <1f08e8ae3c9c4f4bb0e002f1a1a40c20@mail.dessus.com>
References: <1f08e8ae3c9c4f4bb0e002f1a1a40c20@mail.dessus.com>
Message-ID: <62630D01-343C-4E9D-AA83-E6A9ED8478F4@delong.com>


On Mar 23, 2009, at 5:18 PM, Keith Medcalf wrote:

>
>> During ARINs annual WHOIS POC validation, an e-mail will be sent to
>> every POC in the WHOIS database. Each POC will have a maximum
>> of 60 days to respond with an affirmative that their WHOIS contact
>> information is correct and complete. Unresponsive POC email addresses
>> shall be marked as such in the database. If ARIN staff deems a POC
>> to be completely and permanently abandoned or otherwise illegitimate,
>> the record shall be deleted.
>
> Policy should clearly require that the email message:
> - MUST be in text/plain format (MUST NOT be HTML)
> - MUST be sent from a system which has valid meshed forward and  
> reverse DNS
> - MUST originate from the ARIN.NET domain
>
> That is, in order to qualify as an "e-mail" then absolutely strict  
> RFC compliance shall be required for the SMTP mailer, and the  
> message itself must be text/plain.
>
While these are valid requirements for the email, they are operational
in nature and do not need to be spelled out in the policy.  I am  
confident
staff will comply with these and other BCP-oriented practices in this
process without codifying each and every one of them into policy.

Note that the policy does not automatically consider a contact that
does not respond abandoned.  It specifically leaves that determination
to staff judgment which would probably include additional attempts
to contact by alternate methods.

Owen



From Lee at dilkie.com  Tue Mar 24 07:51:30 2009
From: Lee at dilkie.com (Lee Dilkie)
Date: Tue, 24 Mar 2009 07:51:30 -0400
Subject: [arin-ppml] Draft Policy 2008-7: Identify Invalid WHOIS POC's
In-Reply-To: <62630D01-343C-4E9D-AA83-E6A9ED8478F4@delong.com>
References: <1f08e8ae3c9c4f4bb0e002f1a1a40c20@mail.dessus.com>
	<62630D01-343C-4E9D-AA83-E6A9ED8478F4@delong.com>
Message-ID: <49C8C942.80601@dilkie.com>



Owen DeLong wrote:
> On Mar 23, 2009, at 5:18 PM, Keith Medcalf wrote:
>
>   
> While these are valid requirements for the email, they are operational
> in nature and do not need to be spelled out in the policy.  I am  
> confident
> staff will comply with these and other BCP-oriented practices in this
> process without codifying each and every one of them into policy.
>
> Note that the policy does not automatically consider a contact that
> does not respond abandoned.  It specifically leaves that determination
> to staff judgment which would probably include additional attempts
> to contact by alternate methods.
>
>
>   
Since the policy specified "email" and that is only one of many contact
methods, perhaps the policy shouldn't be so specific either and simply
leave the details of "contacting the record holder" to staff.


From info at arin.net  Tue Mar 24 11:48:41 2009
From: info at arin.net (Member Services)
Date: Tue, 24 Mar 2009 11:48:41 -0400
Subject: [arin-ppml] Policy Proposal: Protective Usage Transfer Policy for
 IPv4 Address - Abandoned
In-Reply-To: <49B03D9B.9070103@arin.net>
References: <49B03D9B.9070103@arin.net>
Message-ID: <49C900D9.6040003@arin.net>

Policy Proposal 83
Protective Usage Transfer Policy for IPv4 Address

On 19 March 2009 the ARIN Advisory Council (AC) abandoned Policy
Proposal 83: Protective Usage Transfer Policy for IPv4 Address. The AC
provided the following explanation of their decision:

#####
?The Advisory Council, seeing little support and a large amount of
opposition on PPML for the Policy Proposal 83 - Protective Usage
Transfer Policy for IPv4 Address has decided to abandon it. Further, the
Advisory Council believes that the specific issues raised in this
proposal are adequately addressed by existing policy allowing critical
infrastructure providers to obtain assignments directly from ARIN.

Therefore, if critical infrastructure providers believe they need
protected resources to guarantee the availability of Internet critical
infrastructure they provide, they should obtain resources directly from
ARIN, see NRPM 4.4 and 6.10.

However, beyond the specific issues raised in this proposal, several
more general issues and questions were raised in the discussion of this
proposal. The Advisory Council intends to investigate some of these
general issues and questions at a workshop in April. Additionally, the
Advisory Council encourages feedback on PPML regarding these general
issues and questions.?
#####

The AC abandoned the proposal. Per the ARIN Policy Development Process,
?Any member of the community, including a proposal originator, may
initiate a Discussion Petition if they are dissatisfied with the action
taken by the Advisory Council regarding any specific policy proposal. If
successful, this petition will change the policy proposal to a draft
policy which will be published for discussion and review by the
community on the PPML and at an upcoming public policy meeting.? Note
that we have passed the deadline for petitions for the upcoming meeting
in San Antonio (as posted to PPML on 9 March 2009); a successful
petition at this time would be for the Fall ARIN meeting.

The deadline to start a proposal petition is 30 March 2009. Petitions
must include the proposal and a petition statement. Once begun, a
petition lasts for 5 business days. Success is measured as support from
at least 10 different people from 10 different organizations. Should an
actual petition begin, ARIN staff will post additional information.

The text for Draft Policies and Proposals is available at:
https://www.arin.net/policy/proposals/

The ARIN Policy Development Process is available at:
https://www.arin.net/policy/pdp.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)

## * ##


Member Services wrote:
> Policy Proposal
> Protective Usage Transfer Policy for IPv4 Address
>
> The proposal originator submitted a revised version of the proposal.
>
> The AC will review this proposal at their next regularly scheduled
> meeting and decide how to utilize the proposal. Their decision will be
> announced to the PPML.
>
> In the meantime, the AC invites everyone to comment on this proposal on
> the PPML, particularly their support or non-support and the reasoning
> behind their opinion. Such participation contributes to a thorough
> vetting and provides important guidance to the AC in their deliberations.
>
> The ARIN Policy Development Process can be found at:
> http://www.arin.net/policy/pdp.html
>
> Mailing list subscription information can be found at:
> http://www.arin.net/mailing_lists/
>
> Regards,
>
> Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> #####
>
>
> Policy Proposal Name: Protective Usage Transfer Policy for IPv4 Address
>
> Proposal Originator : Christopher A. Quesada
>
> Proposal Version: 2
>
> Date: 5 March 2009
>
> Policy statement:
>
> Critical infrastructure providers may appeal to ARIN for final review
> and approval of any full or partial transfer of IPv4 address space that
> has been in use by the critical infrastructure serving the community for
> five consecutive years or more.  Such appeal may result in a partial or
> full approval of the requested transfer, or rejection of the transfer if
> it lacks appropriate rationale, justification, or interferes with the
> seamless operation of such critical infrastructure or hardship to the
> provider.
>
> Rationale:
> Protection of critical infrastructure providers of the Internet,
> including public exchange points, core DNS service providers (e.g.
> ICANN-sanctioned root, gTLD, and ccTLD operators) as well as the RIRs
> and IANA is necessary in order to ensure the continuous operation of the
> Internet for its global service community.  It is possible for an
> organization to transfer an aggregate IPv4 address resource containing
> allocations/assignments downstream supporting critical infrastructure
> (as defined in ARIN?s Number Resource Policy Manual).  This policy is
> intended to protect that critical infrastructure by allowing for the
> review and final approval of such transfer by ARIN, upon appeal by the
> critical infrastructure provider to ARIN, within a sixty day period of
> the transfer notification if such transfer would interfere with the
> continuous and seamless operation of that critical infrastructure or
> hardship to the provider.  Review of the transfer can consist of a
> request by ARIN to the transferring organization for a rationale for
> such transfer.  This may include but not be limited to, a requirement
> for the receiving party to submit the appropriate network request form
> identifying the need and justification for the aggregate IPv4 address
> resource.
>
>
>
>
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
>   






From Matthew.Wilder at telus.com  Tue Mar 24 11:48:36 2009
From: Matthew.Wilder at telus.com (Matthew Wilder)
Date: Tue, 24 Mar 2009 09:48:36 -0600
Subject: [arin-ppml] Draft Policy 2009-2: Depleted IPv4 reserves
In-Reply-To: <4D639F66-9B64-4FF0-BC3A-B8B64430402A@delong.com>
References: <49C7DD7B.5000901@arin.net>
	<DE229826F48ABD4CBF754E5AA6CFC14B1DDA22280E@WP40044.corp.ads>
	<4D639F66-9B64-4FF0-BC3A-B8B64430402A@delong.com>
Message-ID: <DE229826F48ABD4CBF754E5AA6CFC14B1DDA2229A5@WP40044.corp.ads>

Hi Owen,

I agree that there should be some amount of rationing of IP Addresses in the IPv4 endgame.  I simply question the fairness of a policy that says everyone can have what they need in IPv4 addresses except those who need more than a /20 every 6 months.

Fairness itself is a loaded word in these discussions.  To me, fairness in this case fundamentally implies equal access to IPv4 addresses.  The question then becomes the definition of equal access.  Is that access to an equal amount of space per organization?  Though that sounds good, that answer ignores the philosophy of needs-based allocations.  And what about equal amount of space per EU organization represented by an ISP?  That would imply that the large ISPs should still have access to the majority of IP Addresses, since they represent the vast majority of internet users in North America.

The starting point for this policy has to be some kind of target objective.  If the objective of the policy is to make the last /9 of space last around one year before depletion, without consideration of consistent limitation to vastly different organizations, I think this policy fits the bill.

I think there is a way of making the last /9 last for a year without unequally affecting different organizations.  I think the way to implement such a policy more fairly is to limit allocations to a certain percentage of space an organization already has allocated to it.  Thus, each organization can have equal geometric growth to their IPv4 address space, and thus everyone has the same limitations placed on them.  I don't know the numbers that would accomplish a goal of 1 year spreadout of the last /9, but I would bet it is in the 5-10% ballpark.  Note that this kind of policy would prevent a run on ARIN by smaller ISPs and EUs that can request a /20 which might double their IPv4 address space.

I look forward to hearing your thoughts on these ideas!

Cheers,
Matthew

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong
Sent: Monday, March 23, 2009 3:18 PM
To: Matthew Wilder
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft Policy 2009-2: Depleted IPv4 reserves

Matthew,
	Thanks for your input.  Some counterpoints to what you have said that I would like to see some feedback on:

	1.	Once ARIN reserves drop below, say, a /9, that means that ARIN would
		only be able to satisfy a maximum of 32 x-large (/14) requests.  Given
		that you state there are 24 organizations that suck down 80% of
		ARIN resources, I think those organizations are going to have to
		face some rather severe limitations soon after we reach that point
		either through this policy, or, as the result of ARIN being completely
		out of addresses.

	2.	If those extra large organizations are restricted, along with  
everyone
		else, to getting only a /20 per 6 month period thereafter, yes, they
		will be suffering an address shortage, along with everyone else, but,
		they will at least be able to get some addresses for some period of
		time, and, a much larger number of organizations will be able to get
		SOME of their needs met. The assumption that smaller organizations
		will qualify for enough address space for 6 years is, in most cases
		specious and misleading. This policy would not give a /20 to someone
		who would normally qualify only for a /22 based on a 1 year projection.

	3.	I  believe the central question raised by this policy is how does  
the
		community want to prioritize the IPv4 end game.  Do we want to
		provide as much as needed on a first-come-first-serve basis until
		we run head-long into the brick wall where nobody can get anything,
		or, do we want to reach a threshold where we face an address
		shortage for some time before we hit absolute runout.

Owen



_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.


From info at arin.net  Tue Mar 24 13:00:24 2009
From: info at arin.net (Member Services)
Date: Tue, 24 Mar 2009 13:00:24 -0400
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using the
	Emergency PDP)
Message-ID: <49C911A8.5020009@arin.net>

Draft Policy 2009-1
Transfer Policy

The ARIN Board of Trustees has declared a policy emergency and is making
use of the Emergency PDP provision in the ARIN Policy Development
Process to revise policy.

At their meeting on 6 February 2009 the ARIN Board of Trustees, based on
the recommendation of the ARIN Advisory Council and noting that the
Policy Development Process had been followed, adopted Draft Policy
2008-6: Emergency Transfer Policy for IPv4 Addresses.

Then at their meeting on 8 March 2009, the Board noted there is a gap in
the transfer policy that limits the availability of IPv4 address space
at a time when otherwise available IPv4 address space will become
scarce, and declared this gap an emergency. The Board initiated the
Emergency PDP of the Policy Development Process in order to revise the
transfer policy (both the existing transfer policy and the policy just
adopted).

Per the Emergency PDP, the draft policy below is being posted to the
Public Policy Mailing List for 10 business days of discussion and review
by the community. The emergency discussion period ends 7 April 2009.
Within 5 business days of the end of discussion the Advisory Council
will, having reviewed the comments on the list, review the draft policy
and make a recommendation to the Board of Trustees. The Board may adopt
or reject the draft policy. If the Board adopts the policy, it will be
presented at the next public policy meeting for reconsideration.

We encourage you to discuss Draft Policy 2009-1 on the PPML. The
discussion on the list will be used by the AC to determine the community
consensus regarding adopting this as policy.

Draft Policy 2009-1: Transfer Policy is available below and at:
https://www.arin.net/policy/proposals/2009_1.html

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

Policy 2008-6: Emergency Transfer Policy for IPv4 Addresses can be found at:
https://www.arin.net/policy/proposals/2008_6.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy 2009-1
Transfer Policy

Originator: ARIN Board of Trustees (using the Emergency PDP provision in
the ARIN Policy Development Process)

Date: 24 March 2009

Policy statement:

Insert into the ARIN Number Resource Policy Manual as follows:

Add Section 2.8:

?Organization. An Organization is one or more legal entities under
common control or ownership.?

Replace Section 8 as follows:

8. Transfers

8.1. Principles
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. Mergers and Acquisitions
ARIN will consider requests for the transfer of number resources in the
case of mergers and acquisitions 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.

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) affecting 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 Transfers to Specified Recipients
Number resources may be released, in whole or in part, to ARIN for
transfer to another specified organizational recipient, by any
authorized resource holder within the ARIN region. Such transferred
number resources may only be received by organizations that are within
the ARIN region and can demonstrate the need for such resources in the
exact amount which they can justify under current ARIN policies.

#####

Notes:

Most of the existing Section 8 is left unchanged. List of changes:

2.8 New.
8.1 Changes from ?Transfers? to ?Principles.?
8.2 Changes from ?Transfer Requirements? to ?Mergers and Acquisitions.?
8.2 The word ?only? is removed.
8.3 Merged up into 8.2.
8.3 Edited version of the adopted 2008-6.



From stephen at sprunk.org  Tue Mar 24 12:54:38 2009
From: stephen at sprunk.org (Stephen Sprunk)
Date: Tue, 24 Mar 2009 11:54:38 -0500
Subject: [arin-ppml] Draft Policy 2009-2: Depleted IPv4 reserves
In-Reply-To: <DE229826F48ABD4CBF754E5AA6CFC14B1DDA22280E@WP40044.corp.ads>
References: <49C7DD7B.5000901@arin.net>
	<DE229826F48ABD4CBF754E5AA6CFC14B1DDA22280E@WP40044.corp.ads>
Message-ID: <49C9104E.3040105@sprunk.org>

Matthew Wilder wrote:
> I think there is definitely a place for a policy somehow limiting the size of allocations when there is less than 6 months to go in projected ARIN IP Address reserves.  I think a maximum allocation size of /20 is going to be too limiting for large ISPs (full disclosure, I work for TELUS, a large Canadian ISP).  This policy is unusually biased against the largest consumers of IP addresses.

I agree that it is unusually biased, but the reality is that we're 
running out of addresses, and when a handful of mega-ISPs (who are the 
only ones with the power to make the IPv6 transition a reality) are 
consuming 80%+ of the addresses, I can see the justification for 
protecting the thousands of other orgs that have much more modest needs 
and do _not_ have the power to transition to IPv6 until well after the 
mega-ISPs have done so.

I'm not sure this policy is the best we can do (it's all stick and no 
carrot), but I do agree with the general principles behind it and, 
lacking any better options so far, must support it.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3241 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090324/03501d84/attachment.bin>

From owen at delong.com  Tue Mar 24 13:19:47 2009
From: owen at delong.com (Owen DeLong)
Date: Tue, 24 Mar 2009 10:19:47 -0700
Subject: [arin-ppml] Draft Policy 2009-2: Depleted IPv4 reserves
In-Reply-To: <DE229826F48ABD4CBF754E5AA6CFC14B1DDA2229A5@WP40044.corp.ads>
References: <49C7DD7B.5000901@arin.net>
	<DE229826F48ABD4CBF754E5AA6CFC14B1DDA22280E@WP40044.corp.ads>
	<4D639F66-9B64-4FF0-BC3A-B8B64430402A@delong.com>
	<DE229826F48ABD4CBF754E5AA6CFC14B1DDA2229A5@WP40044.corp.ads>
Message-ID: <EB0F027E-B7AB-4E76-A3E6-516811A227F4@delong.com>


On Mar 24, 2009, at 8:48 AM, Matthew Wilder wrote:

> Hi Owen,
>
> I agree that there should be some amount of rationing of IP  
> Addresses in the IPv4 endgame.  I simply question the fairness of a  
> policy that says everyone can have what they need in IPv4 addresses  
> except those who need more than a /20 every 6 months.
>
> Fairness itself is a loaded word in these discussions.  To me,  
> fairness in this case fundamentally implies equal access to IPv4  
> addresses.  The question then becomes the definition of equal  
> access.  Is that access to an equal amount of space per  
> organization?  Though that sounds good, that answer ignores the  
> philosophy of needs-based allocations.  And what about equal amount  
> of space per EU organization represented by an ISP?  That would  
> imply that the large ISPs should still have access to the majority  
> of IP Addresses, since they represent the vast majority of internet  
> users in North America.
>
> The starting point for this policy has to be some kind of target  
> objective.  If the objective of the policy is to make the last /9 of  
> space last around one year before depletion, without consideration  
> of consistent limitation to vastly different organizations, I think  
> this policy fits the bill.
>
> I think there is a way of making the last /9 last for a year without  
> unequally affecting different organizations.  I think the way to  
> implement such a policy more fairly is to limit allocations to a  
> certain percentage of space an organization already has allocated to  
> it.  Thus, each organization can have equal geometric growth to  
> their IPv4 address space, and thus everyone has the same limitations  
> placed on them.  I don't know the numbers that would accomplish a  
> goal of 1 year spreadout of the last /9, but I would bet it is in  
> the 5-10% ballpark.  Note that this kind of policy would prevent a  
> run on ARIN by smaller ISPs and EUs that can request a /20 which  
> might double their IPv4 address space.
>
I think it would be closer to 1%.  Let's look at that in real terms,  
however.

For an organization that has an effective /10 worth of space, 1% is more
than 40,000 addresses.  On the other hand, for an organization that
has a /22, 1% is 10 addresses.  I really don't think the argument that  
this
is an equal impact on the small provider and the large one holds in such
a comparison. True, as a growth percentage, the effect is roughly the  
same,
but, in real terms, 1% of a /10 allows the large ISP to add a number of
large customers, lots of medium customers and/or a whole lot of small
customers. On the other hand, for the small provider, those 10  
addresses,
even if we're generous and bump them up to a /28 (16 addresses) to make
things line up are probably nearly useless.  First, they can only add  
one
small customer or a handful of home users.  Second, it's unlikely they  
can
even get the prefix routed, so, maybe they can't even do that.

Even if we use 10%, the numbers are still pretty skewed.  True, the  
small
provider now gets, essentially, a /25 to use for growth.  They might  
even
be able to put 8-16 small customers into that space.  There's even a  
small
chance they could get it routed.  But, the large ISP with a /10 under  
this
system gets a nice juicy /13 or so (more than 400,000 addresses).

However, with 24 x-large organizations (many of whom have more than
a /8, not just a /10 under their control) vying for this remaining /9,  
at
10%, I don't think you'll get anywhere close to a year.

You do raise some interesting questions.  It would be good to get a
sense from the community of:

1.	How long would the community like rationed IPv4 to last?
	A.	Brick Wall -- allocate as we have until it's gone.
	B.	Ration by some mechanism to last 1 year
	C.	Ration for 2 years
	D.	Ration for 5 years

2.	How would the community prefer to ration?
	A.	Percentage of existing space
	B.	Nobody gets more than a /x every 6 months
	C.	A graduated table based on your org. type:
			(example only:
					x-large		<=/18 every 6 months
					large		<=/19 every 6 months
					medium		<=/20 every 6 months
					smaller		<=/22 every 6 months
			)

3.	How does the community feel we should balance the conflicting needs
	of large quantities of addresses for large ISPs vs. large numbers of
	smaller organizations needing fewer addresses each?

I don't really have a strong opinion on how this should go.  But, I  
think it is
important we have the discussion and come to a deliberate decision as
a community in the near future.

Owen



From martin.hannigan at batelnet.bs  Tue Mar 24 13:37:24 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Tue, 24 Mar 2009 13:37:24 -0400
Subject: [arin-ppml] Draft Policy 2009-2: Depleted IPv4 reserves
In-Reply-To: <49C7DD7B.5000901@arin.net>
References: <49C7DD7B.5000901@arin.net>
Message-ID: <4607e1d50903241037w18f2ec15qe182565ee4730ef2@mail.gmail.com>

> *Policy statement:*
>
> 4.1.8 Depleted IPv4 reserves
>
> A limit will be applied to all IPv4 address requests when ARIN's reserve
> of unallocated IPv4 address space drops below an equivalent /9. When
> this happens, an ISP or End User may receive up to a single /20 within a
> six month period. This restriction will be lifted in the event the
> reserve of unallocated IPv4 address space increases to an equivalent /7.
>

This policy seems to impose exactly the same unfair application that Counsel
described in the summary for  global policy for returning v4 space to the
IANA[3]. Creating equal shares only means that equal allocations occur. It
still creates a severe need imbalance and potentially creates an unfair
advantage for smaller players that a /20 does fulfill their needs.

What's the projection of the impact of this policy on our final exhaustion,
total meltdown of IPv4 allocations utilizing in-region maximum[1] available
inventory[2]?

Perhaps we should instead make it less desireable to get PI and have anyone
who needs a /20 or less accept PA from their upstream?

A this time, I am not in favor of this policy.

-M<

[1] http://aso.icann.org/docs/aso-001-2.pdf
[2]
http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml
[3]
http://mail.google.com/a/batelnet.bs/?AuthEventSource=SSO#label/PPML/12034bd1264e04bf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090324/ed83adf9/attachment.htm>

From martin.hannigan at batelnet.bs  Tue Mar 24 13:39:12 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Tue, 24 Mar 2009 13:39:12 -0400
Subject: [arin-ppml] Draft Policy 2009-2: Depleted IPv4 reserves
In-Reply-To: <4607e1d50903241037w18f2ec15qe182565ee4730ef2@mail.gmail.com>
References: <49C7DD7B.5000901@arin.net>
	<4607e1d50903241037w18f2ec15qe182565ee4730ef2@mail.gmail.com>
Message-ID: <4607e1d50903241039r50991adfn831a1b52bf1527b0@mail.gmail.com>

> [3]
> http://mail.google.com/a/batelnet.bs/?AuthEventSource=SSO#label/PPML/12034bd1264e04bf
>
>
Sorry folks, I cut and pasted the internal URL. The proper link for [3] is

https://www.arin.net/policy/proposals/2009_3.html

Best,

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090324/6a3056c4/attachment.htm>

From bicknell at ufp.org  Tue Mar 24 14:13:13 2009
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 24 Mar 2009 13:13:13 -0500
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using the
	Emergency PDP)
In-Reply-To: <49C911A8.5020009@arin.net>
References: <49C911A8.5020009@arin.net>
Message-ID: <20090324181313.GA51839@ussenterprise.ufp.org>

In a message written on Tue, Mar 24, 2009 at 01:00:24PM -0400, Member Services wrote:
> At their meeting on 6 February 2009 the ARIN Board of Trustees, based on
> the recommendation of the ARIN Advisory Council and noting that the
> Policy Development Process had been followed, adopted Draft Policy
> 2008-6: Emergency Transfer Policy for IPv4 Addresses.

I find there is a great lack of clarity in what the Board has done.

The paragraph above matches the Board minutes from the Feb 6, 2009
Board meeting (https://www.arin.net/about_us/bot/bot2009_0206.html).
Both state that 2008-6 have been adopted, although the latter
suggests "with edits" although those edits are not specified.

The Board had a March meeting, but those minutes are not yet available
online.  Rather, we have the following from the announcement of 2009-1:

> Then at their meeting on 8 March 2009, the Board noted there is a gap in
> the transfer policy that limits the availability of IPv4 address space
> at a time when otherwise available IPv4 address space will become
> scarce, and declared this gap an emergency. The Board initiated the
> Emergency PDP of the Policy Development Process in order to revise the
> transfer policy (both the existing transfer policy and the policy just
> adopted).
> 
> Per the Emergency PDP, the draft policy below is being posted to the
> Public Policy Mailing List for 10 business days of discussion and review
> by the community. The emergency discussion period ends 7 April 2009.
> Within 5 business days of the end of discussion the Advisory Council
> will, having reviewed the comments on the list, review the draft policy
> and make a recommendation to the Board of Trustees. The Board may adopt
> or reject the draft policy. If the Board adopts the policy, it will be
> presented at the next public policy meeting for reconsideration.

Unfortunately this leaves a series of progressively more imporant
questions.  Did the Board adopt 2008-6 as-is, or with changes?  If
changes were made, where are those changes documented so that the
public can review them?  Since the Board has now put forth 2009-1,
is it in addition to 2008-6, or to replace entirely 2008-6?  If it
is in addition to 2008-6, how are inconsistencies between the two
policies resolved?

More importantly, the way in which these actions have been taken
leave me with a bad taste in my mouth.  It appears 2009-1, which
is the emergency policy the board wants, has little or nothing to
do with 2008-6.  If the Board did not like 2008-6 and felt 2009-1
was more appropriate then the Board should have rejected 2008-6 and
used their emergency powers to directly create 2009-1.

It feels to me like the Board is keeping 2008-6 in name only to
provide the pretense that the community and AC has supported this
action.   The reality is 2009-1, from my perspective, has /nothing/
in common with the letter or intent of 2008-6, and thus keeping the
name is a rather sleezy tactic to try and sell the emergency policy.

In any event, the Board needs to get the March minutes posted and
clarify its intentions regarding both 2008-6 and 2009-1 before PPML
will have any solid idea of what the Board is trying to do.


Now, separately onto 2009-1 itself:

> Draft Policy 2009-1
> Transfer Policy
[snip]
> Replace Section 8 as follows:
> 
> 8. Transfers
> 
> 8.1. Principles

Fairly close if not exactly word for word from the current NRPM
8.1, no real issues here.

> 8.2. Mergers and Acquisitions

Fairly close to existing sections 8.2 and 8.3 combined into one
section.  No major issues here as well.

> 8.3 Transfers to Specified Recipients
> Number resources may be released, in whole or in part, to ARIN for
> transfer to another specified organizational recipient, by any
> authorized resource holder within the ARIN region. Such transferred
> number resources may only be received by organizations that are within
> the ARIN region and can demonstrate the need for such resources in the
> exact amount which they can justify under current ARIN policies.

Here we are at the meat of the policy.  This is a wide open transfer
policy with the only restriction being justified need.

I see no need for sections 8, 8.1, and 8.2 to have been rewritten.
It seems to me the 2009-1 8.3 section could have been added as 8.4.
What was the purpose of rewriting the previous sections?

The 2009-1 addresses virtually none of the many concerns that came up
while discussing 2008-2 and 2008-6, concerns the community was quite
interested in addressing.  To name a few:

  - This policy doesn't seem to require the receiver to be under an
    RSA to receive resources.  Is that the Board's intent, or is that
    an "operational detail" left out?

  - The policy as worded seems to make ARIN an escrow agent for IP's,
    specifically that they may be released "to ARIN" to be subsequently
    given to a third party.  Is this language just to show the flow of
    IP's, or is it that ARIN may be a deeper part of the transaction
    (releaser provides them to ARIN, receiver provides money to
    releaser, releaser tells ARIN they have received the money, ARIN
    releases to the receiver)?

  - This policy provides no restrictions on deaggregation.  A releaser
    with a /8 could turn it into /22's overnight.

I find myself unable to support this emergency policy.  The primary
reason is I feel the Board has failed to listen to the community
input on a wide range of issues here, ignoring well voiced concerns
about a wide open transfer policy and specific details (like the
sunset clause) in 2008-6.  

Worse, this policy includes no justification what so ever for the
Board's decision.  There is nothing here to indicate why the Board
felt Emergency action was necessary.  This is particularly damning
in light of the timing, we are 30 days away from a full face to
face meeting, and the Board feels it is necessary to have an emergency
policy in place merely a couple of weeks before that.  I see
absolutely no reason there should be any action on this policy until
after the San Antonio meeting.

At the same time we have the exact form of 2008-6 up in the air as it
appears to be documented no where that PPML can see it, and we have a
pending policy proposal, 2009-4 (full disclosure, I was the original
author of 2009-4) that would be rendered moot by this action a few weeks
before the community was able to discuss it.

In short, the Board took the wrong action at the wrong time, and
has utterly failed to explain these actions to the community.  I
am shocked and saddened by what I feel is a total breakdown in our
normal processes.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090324/25dfc881/attachment.sig>

From tedm at ipinc.net  Tue Mar 24 14:18:13 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 24 Mar 2009 11:18:13 -0700
Subject: [arin-ppml] Draft Policy 2008-7: Identify Invalid WHOIS POC's
In-Reply-To: <1f08e8ae3c9c4f4bb0e002f1a1a40c20@mail.dessus.com>
References: <49C7DD6E.3010106@arin.net>
	<1f08e8ae3c9c4f4bb0e002f1a1a40c20@mail.dessus.com>
Message-ID: <7161025FDDD246B7BAE4B996DB4CFF90@tedsdesk>

Hi Keith,

  My original proposal that 2008-7 is based on
incorporated some of these so I know exactly where your
coming from.  However we decided not to be this specific
because it gives ARIN staff flexibility in how to design
these notifications to make it through spam filters.

  For people running spam filtering on their POC addresses
you would think they would have the wherewithall to 
whitelist ARIN's sending e-mail address in their spam filter.

  ARIN staff is being given the power to make a determination
if a POC is "completely and permanently abandonded or otherwise
illegitimate" by this policy, we would assume that they would
make a telephone call if the e-mail to the POC is not responded
to.

  You want to be careful here because some of this is operations
and some policy - ARIN staff cannot design an operations procedure
until policy authorizes it.

Ted

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Keith Medcalf
> Sent: Monday, March 23, 2009 5:19 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy 2008-7: Identify 
> Invalid WHOIS POC's
> 
> 
> > During ARINs annual WHOIS POC validation, an e-mail will be sent to 
> > every POC in the WHOIS database. Each POC will have a maximum of 60 
> > days to respond with an affirmative that their WHOIS contact 
> > information is correct and complete. Unresponsive POC email 
> addresses 
> > shall be marked as such in the database. If ARIN staff 
> deems a POC to 
> > be completely and permanently abandoned or otherwise 
> illegitimate, the 
> > record shall be deleted.
> 
> Policy should clearly require that the email message:
>  - MUST be in text/plain format (MUST NOT be HTML)
>  - MUST be sent from a system which has valid meshed forward 
> and reverse DNS
>  - MUST originate from the ARIN.NET domain
> 
> That is, in order to qualify as an "e-mail" then absolutely 
> strict RFC compliance shall be required for the SMTP mailer, 
> and the message itself must be text/plain.
> 
> Otherwise, "spam discard" may be confused with "un-responsive"
> 
> --
> ()  ascii ribbon campaign - against html e-mail /\  
> www.asciiribbon.org 
>  
> 
> 
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 



From tedm at ipinc.net  Tue Mar 24 14:19:05 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 24 Mar 2009 11:19:05 -0700
Subject: [arin-ppml] Draft Policy 2008-7: Identify Invalid WHOIS POC's
In-Reply-To: <62630D01-343C-4E9D-AA83-E6A9ED8478F4@delong.com>
References: <1f08e8ae3c9c4f4bb0e002f1a1a40c20@mail.dessus.com>
	<62630D01-343C-4E9D-AA83-E6A9ED8478F4@delong.com>
Message-ID: <F7799CF47DA043468FA4BCEB1ABB9A85@tedsdesk>

 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong
> Sent: Monday, March 23, 2009 6:37 PM
> To: Keith Medcalf
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy 2008-7: Identify 
> Invalid WHOIS POC's
> 


> Note that the policy does not automatically consider a 
> contact that does not respond abandoned.  It specifically 
> leaves that determination to staff judgment which would 
> probably include additional attempts to contact by alternate methods.
> 

That was intentional in the policy for exactly this reason.

Ted



From rlc at usfamily.net  Tue Mar 24 14:19:15 2009
From: rlc at usfamily.net (Ron Cleven)
Date: Tue, 24 Mar 2009 13:19:15 -0500 (CDT)
Subject: [arin-ppml] Draft Policy 2009-2: Depleted IPv4 reserves
In-Reply-To: <49C9104E.3040105@sprunk.org>
References: <49C7DD7B.5000901@arin.net>	<DE229826F48ABD4CBF754E5AA6CFC14B1DDA22280E@WP40044.corp.ads>
	<49C9104E.3040105@sprunk.org>
Message-ID: <49C9241D.6050601@usfamily.net>

Stephen's comments are spot on.  The large ISP's are the very ones who 
have both the resources and clout to make the IPv6 transition happen. If 
they are unwilling or unable to do so, what does that say about the 
viability of ever making that transition?  Mr. Wilder doth protest too 
much.


Stephen Sprunk wrote:
> Matthew Wilder wrote:
> 
>> I think there is definitely a place for a policy somehow limiting the 
>> size of allocations when there is less than 6 months to go in 
>> projected ARIN IP Address reserves.  I think a maximum allocation size 
>> of /20 is going to be too limiting for large ISPs (full disclosure, I 
>> work for TELUS, a large Canadian ISP).  This policy is unusually 
>> biased against the largest consumers of IP addresses.
> 
> 
> I agree that it is unusually biased, but the reality is that we're 
> running out of addresses, and when a handful of mega-ISPs (who are the 
> only ones with the power to make the IPv6 transition a reality) are 
> consuming 80%+ of the addresses, I can see the justification for 
> protecting the thousands of other orgs that have much more modest needs 
> and do _not_ have the power to transition to IPv6 until well after the 
> mega-ISPs have done so.
> 
> I'm not sure this policy is the best we can do (it's all stick and no 
> carrot), but I do agree with the general principles behind it and, 
> lacking any better options so far, must support it.
> 
> S
> 


From Matthew.Wilder at telus.com  Tue Mar 24 14:35:15 2009
From: Matthew.Wilder at telus.com (Matthew Wilder)
Date: Tue, 24 Mar 2009 12:35:15 -0600
Subject: [arin-ppml] Draft Policy 2009-2: Depleted IPv4 reserves
In-Reply-To: <EB0F027E-B7AB-4E76-A3E6-516811A227F4@delong.com>
References: <49C7DD7B.5000901@arin.net>
	<DE229826F48ABD4CBF754E5AA6CFC14B1DDA22280E@WP40044.corp.ads>
	<4D639F66-9B64-4FF0-BC3A-B8B64430402A@delong.com>
	<DE229826F48ABD4CBF754E5AA6CFC14B1DDA2229A5@WP40044.corp.ads>
	<EB0F027E-B7AB-4E76-A3E6-516811A227F4@delong.com>
Message-ID: <DE229826F48ABD4CBF754E5AA6CFC14B1DDA222AF4@WP40044.corp.ads>

On Mar 24, 2009, at 10:46 AM, Owen DeLong wrote:

> I think it would be closer to 1%.  Let's look at that in real terms, 
> however.
> 
> For an organization that has an effective /10 worth of space, 1% is more 
> than 40,000 addresses.  On the other hand, for an organization that has 
> a /22, 1% is 10 addresses.  I really don't think the argument that this 
> is an equal impact on the small provider and the large one holds in such 
> a comparison. True, as a growth percentage, the effect is roughly the 
> same, but, in real terms, 1% of a /10 allows the large ISP to add a 
> number of large customers, lots of medium customers and/or a whole lot 
> of small customers. On the other hand, for the small provider, those 10 
> addresses, even if we're generous and bump them up to a /28 
> 16 addresses) to make things line up are probably nearly useless.  
> First, they can only add one small customer or a handful of home users.  
> Second, it's unlikely they can even get the prefix routed, so, maybe 
> they can't even do that.
> 
> Even if we use 10%, the numbers are still pretty skewed.  True, the 
> small provider now gets, essentially, a /25 to use for growth.  They 
> might even be able to put 8-16 small customers into that space.  There's 
> even a small chance they could get it routed.  But, the large ISP with 
> a /10 under this system gets a nice juicy /13 or so (more than 400,000 
> addresses).
> 
> However, with 24 x-large organizations (many of whom have more than a 
> /8, not just a /10 under their control) vying for this remaining /9, 
> at 10%, I don't think you'll get anywhere close to a year.
> 
> You do raise some interesting questions.  It would be good to get a 
> sense from the community of:
> 
> 1.	How long would the community like rationed IPv4 to last?
> 	A.	Brick Wall -- allocate as we have until it's gone.
> 	B.	Ration by some mechanism to last 1 year
> 	C.	Ration for 2 years
> 	D.	Ration for 5 years
> 
> 2.	How would the community prefer to ration?
> 	A.	Percentage of existing space
> 	B.	Nobody gets more than a /x every 6 months
> 	C.	A graduated table based on your org. type:
> 			(example only:
> 					x-large		<=/18 every 6 months
> 					large		<=/19 every 6 months
> 					medium		<=/20 every 6 months
> 					smaller		<=/22 every 6 months
> 			)
> 
> 3.	How does the community feel we should balance the conflicting needs
> 	of large quantities of addresses for large ISPs vs. large numbers of
> 	smaller organizations needing fewer addresses each?
> 
> I don't really have a strong opinion on how this should go.  But, I think 
> it is important we have the discussion and come to a deliberate decision 
> as a community in the near future.
> 
> Owen

Owen,

Great points.  I should have done a few calculations before throwing out a percentage, but I agree we are looking at low single digit percentage.  I like the questions and options you lay out for the community, and I will provide my preferences and opinions:

1. B/C - I think a reasonable extension of IPv4 availability would be 1 to 2 years.  More than that and you may introduce a reason for organizations not to move toward IPv6 (especially when paired with generous transfer policies that would likely be surfacing at the time of IPv4 rationing).

2. C - A Graduated limit on allocations offers exactly the balanced limitation that I would hope for in this kind of policy.  ARIN's mandate is unbiased with respect to large versus small organization, and so any policies should continue to support relative needs-based allocations.

3. Another way of balancing the conflicting needs is to partition the last of the IP address space so that a portion is reserved for organizations with different address requirements.  For example, roughly 50% could be reserved for the extra-large allocations, and the other 50% reserved for all other allocations, or something along those lines.

Cheers,
Matthew

_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.


From bicknell at ufp.org  Tue Mar 24 14:35:31 2009
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 24 Mar 2009 13:35:31 -0500
Subject: [arin-ppml] Draft Policy 2008-7: Identify Invalid WHOIS POC's
In-Reply-To: <1f08e8ae3c9c4f4bb0e002f1a1a40c20@mail.dessus.com>
References: <49C7DD6E.3010106@arin.net>
	<1f08e8ae3c9c4f4bb0e002f1a1a40c20@mail.dessus.com>
Message-ID: <20090324183530.GA54611@ussenterprise.ufp.org>

In a message written on Mon, Mar 23, 2009 at 08:18:36PM -0400, Keith Medcalf wrote:
> Policy should clearly require that the email message:
>  - MUST be in text/plain format (MUST NOT be HTML)
>  - MUST be sent from a system which has valid meshed forward and reverse DNS
>  - MUST originate from the ARIN.NET domain

I think we need to think really hard about what should go into
policy and what should be an operational detail.  For instance while
I think the first e-mail should be from ARIN.NET, I would not want
to preclude the option of staff sending a subsequent e-mail from
another ARIN controlled domain in case ARIN.NET is blacklisted for
some reason.

At various times we've wanted to include operational suggestions
along with policy, and our current process provides no good way to
do that.  This however seems like a prime case of suggestions that
should be made via the ASCP around the time the policy is moved
forward, so ARIN staff can have full community input day one.  I
think the community as a whole could be making much better use of
the ASCP, particularly in the case of new policy proposals.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090324/274ce9ed/attachment.sig>

From tedm at ipinc.net  Tue Mar 24 14:45:01 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 24 Mar 2009 11:45:01 -0700
Subject: [arin-ppml] Draft Policy 2008-7: Identify Invalid WHOIS POC's
In-Reply-To: <49C8C942.80601@dilkie.com>
References: <1f08e8ae3c9c4f4bb0e002f1a1a40c20@mail.dessus.com><62630D01-343C-4E9D-AA83-E6A9ED8478F4@delong.com>
	<49C8C942.80601@dilkie.com>
Message-ID: <3E32C91B19244A0D977F953C8BD36871@tedsdesk>

 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Lee Dilkie
> Sent: Tuesday, March 24, 2009 4:52 AM
> To: Owen DeLong
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy 2008-7: Identify 
> Invalid WHOIS POC's
> 
> 
> 
> Owen DeLong wrote:
> > On Mar 23, 2009, at 5:18 PM, Keith Medcalf wrote:
> >
> >   
> > While these are valid requirements for the email, they are 
> operational 
> > in nature and do not need to be spelled out in the policy.  I am 
> > confident staff will comply with these and other BCP-oriented 
> > practices in this process without codifying each and every 
> one of them 
> > into policy.
> >
> > Note that the policy does not automatically consider a contact that 
> > does not respond abandoned.  It specifically leaves that 
> determination 
> > to staff judgment which would probably include additional 
> attempts to 
> > contact by alternate methods.
> >
> >
> >   
> Since the policy specified "email" and that is only one of 
> many contact methods, perhaps the policy shouldn't be so 
> specific either and simply leave the details of "contacting 
> the record holder" to staff.

We (the policy originators) all felt this was a bad idea for 2
major reasons:

1) With the number of POCs in the whois database, e-mail
is the only practical method of contacting and getting a response
from them on an annual basis.  To do otherwise (perhaps a phone
call) would mean hiring a large number of people to sit there
dialing telephone numbers.  You also have language problems in
doing it this way and the inevitable transcription errors that
would result.  Postage is expensive as well, as is handling by
hand, paper responses.

ARIN will have enough to do attempting to validate by phone
and paper unresponsive POCs.  The goal here should be that ALL e-mail
addresses in WHOIS are responsive, so that it's a minimal cost to
verify the address registrations.

2) WHOIS mandates valid POC info INCLUDING THE E-MAIL ADDRESS.  It
is a contractual violation to supply a bogus or false e-mail
address - you agreed to supplying a correct one when you signed
the agreement to get your addresses.  The legacy holders also
STRONGLY IMPLIED they would supply legitimate e-mail addresses
in their WHOIS entries when they supplied their WHOIS records.

There has never been a time that ANY IMPLICATION EXISTED that
TCP/IP address assignors WOULD NOT BE REACHABLE BY E-MAIL or that
it would be OK to supply a "fake" e-mail address.  Indeed, one of
the primary reasons for getting TCP/IP numbering is e-mail.

Don't you think it's a bit odd that your proposing ON
AN E-MAIL MAILING LIST that we countenence removal of the requirement
for valid E-MAIL addresses in POC entries?  Using your own,
publically reachable, personal e-mail address to do so?  You
obviously have no problem with making your own e-mail address
public - so why would you think that any reasons put forth by
a POC for not having a valid e-mail address published in WHOIS
are anything other than bogus nonsense?

Thus, we (the proposers) simply did not consider a POC that has an
unreachable e-mail address to be a valid WHOIS entry.

Ted



From tedm at ipinc.net  Tue Mar 24 14:50:05 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 24 Mar 2009 11:50:05 -0700
Subject: [arin-ppml] Draft Policy 2008-7: Identify Invalid WHOIS POC's
In-Reply-To: <20090324183530.GA54611@ussenterprise.ufp.org>
References: <49C7DD6E.3010106@arin.net><1f08e8ae3c9c4f4bb0e002f1a1a40c20@mail.dessus.com>
	<20090324183530.GA54611@ussenterprise.ufp.org>
Message-ID: <D3990F459B554128801EFFFA2BBA3CA5@tedsdesk>

 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Leo Bicknell
> Sent: Tuesday, March 24, 2009 11:36 AM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy 2008-7: Identify 
> Invalid WHOIS POC's
> 
> In a message written on Mon, Mar 23, 2009 at 08:18:36PM 
> -0400, Keith Medcalf wrote:
> > Policy should clearly require that the email message:
> >  - MUST be in text/plain format (MUST NOT be HTML)
> >  - MUST be sent from a system which has valid meshed forward and 
> > reverse DNS
> >  - MUST originate from the ARIN.NET domain
> 
> I think we need to think really hard about what should go 
> into policy and what should be an operational detail.  For 
> instance while I think the first e-mail should be from 
> ARIN.NET, I would not want to preclude the option of staff 
> sending a subsequent e-mail from another ARIN controlled 
> domain in case ARIN.NET is blacklisted for some reason.
> 


I would assume that any POC contact would be asked by an ARIN
staff who had to go through such hoops to please whitelist
ARIN.NET in the filter on their POC contact.

Ted



From Matthew.Wilder at telus.com  Tue Mar 24 14:46:05 2009
From: Matthew.Wilder at telus.com (Matthew Wilder)
Date: Tue, 24 Mar 2009 12:46:05 -0600
Subject: [arin-ppml] Draft Policy 2009-2: Depleted IPv4 reserves
In-Reply-To: <49C9241D.6050601@usfamily.net>
References: <49C7DD7B.5000901@arin.net>
	<DE229826F48ABD4CBF754E5AA6CFC14B1DDA22280E@WP40044.corp.ads>
	<49C9104E.3040105@sprunk.org> <49C9241D.6050601@usfamily.net>
Message-ID: <DE229826F48ABD4CBF754E5AA6CFC14B1DDA222B10@WP40044.corp.ads>


Ron wrote:
> Stephen's comments are spot on.  The large ISP's are the very ones who 
> have both the resources and clout to make the IPv6 transition happen. 
> If they are unwilling or unable to do so, what does that say about the 
> viability of ever making that transition?  Mr. Wilder doth protest too 
> much.

My explicit role in my organization is to ensure adequate IP Addressing to support service growth and new service introduction.  I believe without a doubt that the only way I will be successful in that mandate is to position IPv6 as the vehicle so that the IP Addresses are there.  

My organization is taking the steps necessary to get that transition happening, so we are not unwilling.  I can tell you that with certain services, we might well be unable to transition before IPv4 exhaust hits, but my focus is to transition the high growth services.  I want to make sure that the other services which may take longer to transition have the IP Addresses available, as I am sure every other admin POC out there is trying to ensure.

I don't protest for the sake of demanding unfair privileges on the behalf of large ISPs.  I protest a policy that says everyone can have their needs completely met except for one group, which can't even have a reasonable fraction of their need met.

Respectfully,
Matthew Wilder

From tedm at ipinc.net  Tue Mar 24 14:55:30 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 24 Mar 2009 11:55:30 -0700
Subject: [arin-ppml] Policy Proposal: Sunset 2008-6 on schedule
In-Reply-To: <86d4cbm3wq.fsf@seastrom.com>
References: <49C3D28B.4060103@arin.net><FF1B008A38AF4B169F2C6231EC04AA26@tedsdesk><92124DB7-3213-49B0-BC7D-D2FA42939F14@delong.com><E32C7567B8E9410E90AFA9E5874B3227@tedsdesk><29AEF1F5-E5C2-43E5-B147-69C17D9D561D@delong.com><DAFE2E72CC7145BD8A25B257F635506E@tedsdesk><36669051-45FE-4DC6-91BE-CEFDE0AEF62B@isoc.org><46CC5224FA49462490588585630C3ABF@tedsdesk>
	<86d4cbm3wq.fsf@seastrom.com>
Message-ID: <E7CFF8DCE811419CBAC3DD3DE6901DAE@tedsdesk>

 

> -----Original Message-----
> From: Robert E. Seastrom [mailto:rs at seastrom.com] 
> Sent: Saturday, March 21, 2009 5:55 AM
> To: Ted Mittelstaedt
> Cc: 'John Schnizlein'; arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal: Sunset 2008-6 on schedule
> 
> 
> Speaking for myself, and not for the AC...
> 
> Can we all please show some forbearance and wait for the 
> Board's explanation before engaging in debate on Owen's 
> proposal?  Not only would it be good for the signal to noise 
> ratio on PPML, but it would keep us from having to rehash the 
> same discussion twice.
> 

It has been 2 business days since this happened, surely that is
enough time for the Board to post it's explanation by now.


Ted



From rlc at usfamily.net  Tue Mar 24 14:58:09 2009
From: rlc at usfamily.net (Ron Cleven)
Date: Tue, 24 Mar 2009 13:58:09 -0500 (CDT)
Subject: [arin-ppml] Draft Policy 2009-2: Depleted IPv4 reserves
In-Reply-To: <DE229826F48ABD4CBF754E5AA6CFC14B1DDA222B10@WP40044.corp.ads>
References: <49C7DD7B.5000901@arin.net>	<DE229826F48ABD4CBF754E5AA6CFC14B1DDA22280E@WP40044.corp.ads>	<49C9104E.3040105@sprunk.org>
	<49C9241D.6050601@usfamily.net>
	<DE229826F48ABD4CBF754E5AA6CFC14B1DDA222B10@WP40044.corp.ads>
Message-ID: <49C92D3C.2010509@usfamily.net>

I have read over and over and over in this list that IPv6 is "the 
solution" to all the IPv4 depletion problems.  I have also seen tons of 
posts that explicitly or implicitly assert that only irresponsible ISP's 
will not be ready to go with IPv6 by the time IPv4 runs out.  After all, 
we have all known this day has been coming for the last decade.  Yet, 
you seem to saying that your large ISP who should be a leader in this 
movement will be unable to make the transition in time.  I'm shocked!

Are there any other large ISP's monitoring this list who are the least 
bit concerned about the transition, or is Telus the only one who can't 
seem to figure this out?  Perhaps one of the large ISP's who has 
everything all figured out could share all their technical information 
to put Telus' mind to rest?

Matthew Wilder wrote:

> Ron wrote:
> 
>>Stephen's comments are spot on.  The large ISP's are the very ones who 
>>have both the resources and clout to make the IPv6 transition happen. 
>>If they are unwilling or unable to do so, what does that say about the 
>>viability of ever making that transition?  Mr. Wilder doth protest too 
>>much.
> 
> 
> My explicit role in my organization is to ensure adequate IP Addressing to support service growth and new service introduction.  I believe without a doubt that the only way I will be successful in that mandate is to position IPv6 as the vehicle so that the IP Addresses are there.  
> 
> My organization is taking the steps necessary to get that transition happening, so we are not unwilling.  I can tell you that with certain services, we might well be unable to transition before IPv4 exhaust hits, but my focus is to transition the high growth services.  I want to make sure that the other services which may take longer to transition have the IP Addresses available, as I am sure every other admin POC out there is trying to ensure.
> 
> I don't protest for the sake of demanding unfair privileges on the behalf of large ISPs.  I protest a policy that says everyone can have their needs completely met except for one group, which can't even have a reasonable fraction of their need met.
> 
> Respectfully,
> Matthew Wilder



From stephen at sprunk.org  Tue Mar 24 15:09:04 2009
From: stephen at sprunk.org (Stephen Sprunk)
Date: Tue, 24 Mar 2009 14:09:04 -0500
Subject: [arin-ppml] Draft Policy 2009-2: Depleted IPv4 reserves
In-Reply-To: <DE229826F48ABD4CBF754E5AA6CFC14B1DDA222B10@WP40044.corp.ads>
References: <49C7DD7B.5000901@arin.net>	<DE229826F48ABD4CBF754E5AA6CFC14B1DDA22280E@WP40044.corp.ads>	<49C9104E.3040105@sprunk.org>
	<49C9241D.6050601@usfamily.net>
	<DE229826F48ABD4CBF754E5AA6CFC14B1DDA222B10@WP40044.corp.ads>
Message-ID: <49C92FD0.1080602@sprunk.org>

Matthew Wilder wrote:
> I don't protest for the sake of demanding unfair privileges on the behalf of large ISPs.  I protest a policy that says everyone can have their needs completely met except for one group, which can't even have a reasonable fraction of their need met.
>   

By the time this proposal would become active, there would not be enough 
IP addresses left for the mega-ISPs to all have a "reasonable fraction 
of their need met" anyways, given the rate of consumption and allocation 
window.  The difference in a few percentage points (getting 10% of their 
request instead of 15%) for those mega-ISPs, though, would be the 
difference between the thousands of other members getting most of what 
they need for a year or two and getting absolutely nothing (because the 
mega-ISPs had grabbed up the entire remaining free pool in one request).

There is simply no way to be "fair" when 1% of members account for 80%+ 
of the IPv4 burn rate; someone's going to get screwed when we hit the 
wall, and the options are screwing only the biggest 1% or screwing 
everyone (including that 1%).  You might not see a difference from where 
you sit, but the other 99% of us do.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3241 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090324/4f323073/attachment.bin>

From tedm at ipinc.net  Tue Mar 24 15:08:14 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 24 Mar 2009 12:08:14 -0700
Subject: [arin-ppml] Draft Policy 2008-3: Community Networks IPv6
	Assignment
In-Reply-To: <49C7DD5F.7070306@arin.net>
References: <49C7DD5F.7070306@arin.net>
Message-ID: <142C7C752A94407CB818216C1495E666@tedsdesk>


I had thought that one of the big advantages of IPv6 is that it was
designed to be simple to renumber.  

Thus I am not sure why having "a stable and globally unique address
assignment" has anything to do with having "a stable internal address
structure" under IPv6.  I can understand why a community network would
need the second thing, but I don't see why they can't have this under
a globally unique address assignment that's made by a LIR instead of
by ARIN.

The community network's internal address structure would NOT change
when their connections to outside networks come and go - under IPv6.

Could the proposers explain what they need, here?  We all what to
support non-profit community networks that help poor people get
online, but at first blush this looks like the proposal authors are
assuming IPv6 == IPv4.


Ted


> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services
> Sent: Monday, March 23, 2009 12:05 PM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Draft Policy 2008-3: Community Networks 
> IPv6 Assignment
> 
> SUBJECT: Draft Policy 2008-3: Community Networks IPv6 Assignment
> 
> Draft Policy 2008-3
> Community Networks IPv6 Assignment
> 
> The following draft policy text is being posted for feedback 
> and discussion on the Public Policy Mailing List (PPML).
> 
> After the October 2008 Public Policy Meeting the ARIN Advisory Council
> (AC) decided that 2008-3 required more work. The text below 
> was developed by the AC. The AC was required to submit text 
> to ARIN for staff and legal assessment prior to selecting it 
> as a draft policy. The assessment, along with the text that 
> was assessed, is located below the draft policy.
> 
> On 20 March 2009 the ARIN Advisory Council (AC) selected Draft Policy
> 2008-3: Community Networks IPv6 Assignment for adoption 
> discussion on the PPML and at the upcoming Public Policy Meeting.
> 
> Draft Policy 2008-3 is below and can be found at:
> https://www.arin.net/policy/proposals/2008_3.html
> 
> We encourage you to discuss Draft Policy 2008-3 on PPML prior 
> to the ARIN XXIII Public Policy Meeting. Both the discussion 
> on the PPML and at the Public Policy Meeting will be used by 
> the ARIN Advisory Council to determine the community 
> consensus regarding adopting this as policy.
> 
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
> 
> All of the Draft Policies under discussion can be found at:
> https://www.arin.net/policy/proposals/index.html
> 
> Regards,
> 
> Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> ## * ##
> 
> 
> Draft Policy 2008-3
> Community Networks IPv6 Assignment
> 
> Date: 23 March 2009
> 
> Policy statement:
> 
> [Add Section 2.8 to the NRPM.]
> 
> 2.8 Community Network
> 
> A community network is any network organized and operated by 
> a mostly volunteer group operating as or under the fiscal 
> support of a non-profit organization or university for the 
> purpose of providing free or low-cost connectivity to the 
> residents of their local service area. To be treated as a 
> community network under ARIN policy, the applicant must 
> further certify to ARIN that the community network staff is 
> at least 50% volunteer and that the annual budget for 
> community network activities is less than $250,000.
> 
> [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 qualifying 
> Community Network as defined in Section 2.8, with assignment 
> criteria defined in section 6.5.9.
> 
> [Add Section 6.5.9 to the NRPM.]
> 
> 6.5.9 Community Network Assignments
> 
> 6.5.9.1 Qualification Criteria
> 
> To qualify for a direct assignment, a community network must 
> demonstrate it will immediately provide sustained service to 
> at least 100 simultaneous users and must demonstrate a plan 
> to provide sustained service to at least 200 simultaneous 
> users within one year. For community networks located in 
> rural regions or in the Caribbean and North Atlantic Islands 
> Sector, the numbers in these qualification criteria may be 
> relaxed at ARIN's discretion.
> 
> 6.5.9.2. Initial assignment size
> 
> The minimum size of the assignment is /48. Organizations 
> requesting a larger assignment must provide documentation of 
> the characteristics of the Community Network's size and 
> architecture that require the use of additional subnets. An 
> HD-Ratio of .94 with respect to subnet utilization within the 
> network must be met for all assignments larger than a /48. 
> These assignments shall be made from a distinctly identified 
> prefix and shall be made with a reservation for growth of at 
> least a /44. This reservation may be assigned to other 
> organizations later, at ARIN's discretion.
> 
> 6.5.9.3. Subsequent assignment size
> 
> Additional assignments may be made when the need for 
> additional subnets is justified. Justification will be 
> determined based on a detailed plan of the network's 
> architecture and the .94 HD-Ratio metric. When possible, 
> assignments will be made from an aggregatable adjacent address block.
> 
> 
> Rationale:
> 
> this policy was originally proposed by community network 
> operators to provide them with the ability to receive a 
> direct assignment of IPv6 address resources from ARIN. the 
> operators of such networks have expressed their need to have 
> a stable and globally unique address assignment with which to 
> number their network infrastructure. many such networks are 
> not able to meet the current criteria for a PI IPv6 
> assignment from ARIN. in an environment where connections to 
> outside networks may come and go, a stable internal address 
> structure would be very valuable. additionally, the ability 
> to exchange routes with others, whether locally or tunneled, 
> and thereby have native IPv6 connectivity, would be quite 
> beneficial. these operators were also hopeful that, once this 
> new class of address assignments was created, they could 
> pursue lower annual fees for community networks through the 
> ARIN Consultation and Suggestion Process (ACSP).
> 
> there could also be a number of potential benefits to 
> allowing community network participants to begin using IPv6 
> addressing. some of these networks have many technically 
> capable and adventurous members who would be motivated to 
> begin developing and/or experimenting with the software 
> extensions which will be needed to support IPv6 prefix 
> selection among multiple IPv6 prefixes when establishing 
> remote connections. also, participants in networks receiving 
> such assignments will have the necessary global-ID to 
> experiment with the various proposals currently being 
> developed for separating network locater from network ID.
> 
> also, during the more than one year timeframe that this 
> policy has been under consideration, other people have 
> suggested other scenarios where community networks would 
> provide a valuable resource. one such proposal was discussed 
> at one of the Caribbean Sector meetings where some 
> participants pointed out the efforts were being made in 
> remote or sparsely populated areas to establish community 
> networks which would serve as connections back to educational 
> resources for distant learning capabilities. there are also 
> many still wild areas of North America where such community 
> networks could provide improved connectivity over telephone modems.
> 
> Timetable for implementation: Immediate.
> 
> 
> #####
> 
> 
> ARIN Staff Assessment
> 
> *2008-3*
> 
> *Title: Community Networks IPv6 Allocation*
> 
> *Proposal Submitted: 04 March 2008*
> 
> *Latest Revision Submitted: 06 March 2009 (includes AC revisions)*
> 
> *Date of Assessment: 15 March 2009*
> 
> I. Understanding of the Policy:
> 
> *Staff Understanding of the Proposal:*
> 
> ARIN staff understands this policy would provide an IPv6 
> assignment of a
> /48 or larger to any community network that can demonstrate 
> it will provide service to at least 100 users immediately, 
> and have a plan to demonstrate that it will provide service 
> to at least 200 users within one year.
> 
> II. Comments
> 
> A. ARIN Staff Comments:
> 
> . The title of the policy says "allocation" while this policy 
> is clearly an "assignment" policy. Therefore, the title 
> should be changed. In addition, the title of section 6.5.9 
> should be changed to say "assignment" and not "allocation".
> 
> B. ARIN General Counsel Comments:
> 
> Counsel sees no significant legal or litigation risk 
> regarding this policy.
> 
> III. Resource Impact
> 
> The resource impact of implementing this policy is viewed as 
> minimal. It is estimated that this policy could require up to 
> 1 person month of effort to implement following ratification 
> by the ARIN Board of Trustees. It may require the following:
> 
>     * Guidelines Changes
>     * Staff training
>     * Development of new internal procedures
> 
> Text assessed:
> 
> 2008-3: Community Networks IPv6 Allocation**
> 
> *Policy statement:*
> 
> [Add Section 2.8 to the NRPM.]
> 
> 2.8 Community Network
> 
> A community network is any network organized and operated by 
> a mostly volunteer group operating as or under the fiscal 
> support of a non-profit organization or university for the 
> purpose of providing free or low-cost connectivity to the 
> residents of their local service area. To be treated as a 
> community network under ARIN policy, the applicant must 
> further certify to ARIN that the community network staff is 
> at least 50% volunteer and that the annual budget for 
> community network activities is less than $250,000.
> 
> [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 qualifying 
> Community Network as defined in Section 2.8, with allocation 
> criteria defined in section 6.5.9.
> 
> [Add Section 6.5.9 to the NRPM.]
> 
> 6.5.9 Community Network Allocations
> 
> 6.5.9.1 Qualification Criteria
> 
> To qualify for a direct assignment, a community network must 
> demonstrate it will immediately provide sustained service to 
> at least 100 simultaneous users and must demonstrate a plan 
> to provide sustained service to at least 200 simultaneous 
> users within one year. For community networks located in 
> rural regions or in the Caribbean and North Atlantic Islands 
> Sector, the numbers in these qualification criteria may be 
> relaxed at ARIN's discretion.
> 
> 6.5.9.2. Initial assignment size
> 
> The minimum size of the assignment is /48. Organizations 
> requesting a larger assignment must provide documentation of 
> the characteristics of the Community Network's size and 
> architecture that require the use of additional subnets. An 
> HD-Ratio of .94 with respect to subnet utilization within the 
> network must be met for all assignments larger than a /48. 
> These assignments shall be made from a distinctly identified 
> prefix and shall be made with a reservation for growth of at 
> least a /44. This reservation may be assigned to other 
> organizations later, at ARIN's discretion.
> 
> 6.5.9.3. Subsequent assignment size
> 
> Additional assignments may be made when the need for 
> additional subnets is justified. Justification will be 
> determined based on a detailed plan of the network's 
> architecture and the .94 HD-Ratio metric. When possible, 
> assignments will be made from an aggregatable adjacent address block.
> 
> 
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 
> 



From tedm at ipinc.net  Tue Mar 24 15:13:37 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 24 Mar 2009 12:13:37 -0700
Subject: [arin-ppml] Draft Policy 2009-4: IPv4 Recovery Fund
In-Reply-To: <49C7DD9A.6030907@arin.net>
References: <49C7DD9A.6030907@arin.net>
Message-ID: <4E2F5C1D7DE44750A55F396303A96846@tedsdesk>


I do not agree with implementing such a policy at the
current time.  Once the IPv4 free pool is exhausted that
would be an appropriate time to do a study to see if
something like this would increase the rate of IPv4
return.  But if this is implemented now it will encourage
hoarding and speculation.

I also strongly oppose a policy like this that does not
contain a sunset clause.  Once a tipping point is reached
in IPv6 penetration, IPv4 will be in surplus and I don't
want to see ARIN paying for addresses that 6 months later
will be worthless.

Ted

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services
> Sent: Monday, March 23, 2009 12:06 PM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Draft Policy 2009-4: IPv4 Recovery Fund
> 
> Draft Policy 2009-4
> IPv4 Recovery Fund
> 
> The following draft policy text is being posted for feedback 
> and discussion on the Public Policy Mailing List (PPML).
> 
> This draft policy was developed by the ARIN Advisory Council 
> (AC) from Policy Proposal 80: IPv4 Recovery Fund. The AC has 
> taken the proposal and developed it into a draft policy. The 
> AC was required to submit text to ARIN for staff and legal 
> assessment prior to selecting it as a draft policy. The 
> assessment, along with the text that was assessed, is located 
> below the draft policy.
> 
> On 20 March 2009 the ARIN Advisory Council (AC) selected Draft Policy
> 2009-4: IPv4 Recovery Fund for adoption discussion on the 
> PPML and at the upcoming Public Policy Meeting.
> 
> Draft Policy 2009-4 is below and can be found at:
> https://www.arin.net/policy/proposals/2009_4.html
> 
> We encourage you to discuss Draft Policy 2009-4 on the PPML 
> prior to the ARIN XXIII Public Policy Meeting. Both the 
> discussion on the PPML and at the Public Policy Meeting will 
> be used by the AC to determine the community consensus 
> regarding adopting this as policy.
> 
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
> 
> All of the Draft Policies under discussion can be found at:
> https://www.arin.net/policy/proposals/index.html
> 
> Regards,
> 
> Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> ## * ##
> 
> 
> Draft Policy 2009-4
> IPv4 Recovery Fund
> 
> Date: 23 March 2009
> 
> Policy statement:
> 
> (Create new section in section 4, represented by "4.X".)
> 
> 4.X IPv4 Recovery Fund
> 
> 4.X.1 Implementation Timing
> 
> Upon receiving a valid request for a block larger than ARIN 
> can satisfy from its existing free pool, or, by obtaining 
> additional space from IANA, ARIN shall begin offering 
> financial incentives for returned IP blocks according to this policy.
> 
> 4.X.2 Recovery of IPv4 Space
> 
> ARIN believes that organizations should voluntarily return 
> unused and/or unneeded IP resources to the community. 
> However, upon implementation of this policy, ARIN will offer 
> financial incentives for the return of IPv4 resources to ARIN 
> relinquishment of any future claims to those resources. ARIN 
> will continue to accept voluntary returns.
> 
> 4.X.3 Allocation of Recovered Space
> 
> Once approved for IPv4 space ARIN will ask the requester to 
> specify a bid of how much they are willing to pay for 
> reclamation of address space. ARIN will use this bid in 
> determining what incentives to offer for return of space.
> The requester may make a higher bid at any time, which is 
> treated as a brand new bid replacing their old bid.
> 
> If ARIN recovers space and offers it to requester at or below 
> the specified bid within 60 days of the time the bid was made 
> then the bid shall be binding on requester at the price ARIN 
> offers the space.
> 
> 4.X.4 Address Block Management
> 
> ARIN may not offer a partial fill, that is provide a block 
> smaller than the one for which the requester was approved.
> 
> ARIN may split recovered blocks into multiple smaller blocks 
> at the staff's discretion using the following principals:
> - It is unlikely a request will be made for the address block 
> size involved in the next 60 days.
> - The block is divided into as few parts as practical.
> - There are enough bids to allow the entire block to be allocated.
> 
> 4.X.5 Transparency
> 
> ARIN staff shall make public the current and historical 
> prices of asks, bids, and executed transactions in a manor 
> that facilitates the bidding process. ARIN staff must 
> regularly report on the amount of address space obtained and 
> distributed via this mechanism, number of blocks subdivided, 
> as well as aggregate financial numbers.
> 
> 4.X.6 Cost Recovery
> 
> ARIN shall manage the address space recovery program with a 
> goal of cost recovery.
> 
> ARIN may:
> - Use ARIN funds to reclaim blocks when there is no specific 
> demand; if such reclamation is deemed in the best interest of 
> the community and there is a significant likelyhood of future demand.
> - Use a portion of the funds collected under this program to 
> pay for the implementation of this program.
> 
> Rationale:
> 
> Many have recognized that in order for unused or poorly used 
> IPv4 resources to be returned to the free pool that financial 
> compensation will be required. This is particularly the case 
> in poorly used assets where the current holder may have to 
> expend time and money to renumber in order to free the blocks.
> 
> This proposal sets up a fund administered by ARIN to 
> encourage the return of space. Effectively ARIN will offer 
> financial incentives to return unused or poorly used IPv4 
> resources and place them back into the
> IPv4 free pool.
> 
> The intention is for this activity to be revenue neutral to 
> ARIN. To achieve that goal those requesting IPv4 resources 
> will be requested to bid on a one-time payment to the 
> recovery fund to cover the cost of the resources they have received.
> 
> The proposal is intentionally vague on the exact 
> implementation details to staff because:
> 
> - Transactions with those returning space and obtaining space 
> may occur in any order.
> - The bidding process may need to evolve over time, and may 
> not be as simple as highest bidder wins. It may include 
> aspects such as a dutch auction style format (all winners pay 
> the lowest winning price), or may include other factors such 
> as which size blocks ARIN has free in an effort to limit 
> deaggregation.
> - ARIN will have to develop contracts and procedures around 
> this activity that are better suited for staff and legal than 
> the policy process.
> 
> Compared to other "transfer proposals", this proposal has the 
> following
> benefits:
> 
> - Maintains that IP addresses are not property.
> - Maintains the concept that unused addresses should be 
> returned to the free pool.
> - Maintains need based addressing.
> - Removes the need for those with excess resources to find 
> those without resources. There is no need for any sort of 
> listing service, eBay, etc.
> - All transactions are two party transactions with ARIN as 
> one of the parties. The potential for multi-party legal 
> disputes is reduced.
> - ARIN can absorb spikes in supply or demand, creating more 
> level prices over time.
> - ARIN can provide transparency across all transactions in 
> this system.
> - Reduces confusion to new entrants over where they should go 
> to receive address space.
> 
> Change Log:
> 
> - Changed "monetary" to "financial" to allow for the 
> possibility of ARIN offering things other than direct payment 
> (like fee credits). Credit: Robert Bonomi.
> - Updated numbering so there were not two 4.10.2's. Also 
> changed to using a place holder for section. Credit: Robert Bonomi
> - Changed the cost recovery language to be more clear and 
> provide some additional flexibility.
> - Clarified 4.10.2 about future claims. Credit: Ted Mittelstaedt
> - Split 10.X.3 into 10.X.3 and 10.X.3 with better titles.
> - Left the exact algorithm to staff. Removed examples as a result.
> 
> Timetable for implementation:
> 
> Staff should begin developing procedures and updated 
> templates immediately. Policy would not go into effect until 
> the criteria listed occurs.
> 
> 
> 
> #####
> 
> 
> ARIN Staff Assessment
> 
> * Title: IPv4 Recovery Fund*
> 
> *Proposal Submitted: 08 Jan 2009 *
> 
> *Date of Assessment: 10 March 2009*
> 
> I. Understanding of the Policy:
> 
> *Staff Understanding of the Proposal:*
> 
> ARIN understands this policy allows approved requestors of 
> IPv4 address space to place binding "bids" for the addresses 
> they have been approved.
> 
> In turn, ARIN can use the monies from those bids to offer 
> financial incentives to registrants of address space to 
> return unused or unneeded addresses to the free pool for 
> reissue to the approved requestors.
> 
> II. Comments
> 
> A. ARIN Staff Comments:
> 
>     * It is unclear to staff exactly when this policy would be
>       triggered. For example, if someone is approved for a 
> /9, and ARIN
>       has only bits of fragmented space left (/10, /12, /13, 
> etc.) which
>       together could fill a /9 request, would this trigger 
> this policy?
>       In other words, can ARIN use dis-contiguous smaller blocks or
>       would the requester be denied and asked to bid on a /9 
> that may be
>       returned in the future?
>     * The policy appears to say that once a request cannot be 
> filled, a
>       requester must make a bid. There does not seem to be an 
> option of
>       waiting for a block that is voluntarily returned. It would be
>       helpful if the policy specified that once the policy is 
> triggered,
>       there is no opting out, if this is indeed the case.
>     * Once the policy is triggered, it is difficult to tell whether
>       every request must then be filled via the bid process or if
>       requesters can choose not to use it. Again, it would be 
> helpful if
>       this were specifically spelled out in the policy text.
>     * Under section 4.X.3 what would happen if a requester doesn't pay
>       the bid amount they committed to? If ARIN is paying the money up
>       front for that address space but is unable to collect 
> that amount
>       back, it could put ARIN at some financial risk.
>     * The bidding process as laid out in section 4.X.3 is somewhat
>       confusing. There is no mention made of a situation 
> where there are
>       two bidders competing for the same address space. Would ARIN
>       automatically award the space to the highest bidder? If 
> so, could
>       that be viewed as an unfair process that rewards those with the
>       most monetary resources?
>     * If someone return's space without monetary compensation in the
>       midst of this, it is not clear whether ARIN would then 
> offer that
>       address space under the current fee structure or under this bid
>       structure.
>     * The term "cost recovery" in section 4x6 should be 
> clearly defined.
>       Specifically, this states that we can use "a portion" 
> of the funds
>       collected to recover space even when there is no demand.
>     * Is there anything to prohibit out of region bidders? ARIN's
>       current practice is to issue address space only to organizations
>       that will be using that space within ARIN's region. If 
> anyone can
>       bid on this space from any region, it will represent a 
> fundamental
>       change in the way we operate today.
>     * This policy would change ARIN's current financial and business
>       models and would significantly impact the way we do 
> business today.
>     * This policy could be a disincentive for people to voluntarily
>       return IP address space, which is something that people do on a
>       somewhat regular basis today.
> 
> B. ARIN General Counsel Comments:
> 
> Nothing in ARIN's Articles of Incorporation or Bylaws 
> prevents ARIN from implementing this policy.  However, this 
> policy would represent a major shift in ARIN's activities by 
> requiring ARIN to build business capabilities and undertake 
> legal risks quite different from ARIN's existing business and 
> expertise.
> 
> In particular, this proposal would require that ARIN staff 
> exercise skills as traders -- e.g. buying IPv4 resource when 
> they think they should buy, selling when they think they 
> should sell.  The required skills are not unlike those 
> involved in running a hedge fund or, perhaps, the US 
> government role in buying Strategic Petroleum Reserve assets. 
> The required skills are quite different from ARIN's core competency.
> 
> This proposal would also introduce potentially capital 
> requirements -- causing ARIN to invest its funds in purchases 
> of v4 resource in anticipation of future sales.  As a 
> nonprofit with a limited financial reserve, ARIN faces an 
> important financial risk from such transactions, in that ARIN 
> could lose significant funds if IPv4 prices do not evolve as 
> ARIN staff anticipate.
> 
> The proposal is relatively silent on the specifics of ARIN's 
> decision-making process for allocating the IPv4 resources 
> ARIN obtains through this process.  While it may be 
> appropriate to delegate those decisions to staff, it is 
> difficult to legally assess the proposal without a vision of 
> the decision rules ARIN would use in allocating scarce space 
> among multiple prospective recipients.  Moreover, because 
> many potential recipients will urgently want additional v4 
> space, such decisions are likely to be closely scrutinized, 
> and ARIN would need a clear and compelling reason to choose 
> to grant space purchased to one recipient rather than another.
> 
> This proposal also exposes ARIN to significant and 
> unameliorated legal risk. For example, in each potential 
> transfer, ARIN participates at least twice on "good" 
> transactions that go well -- one to receive space from an 
> original provider, then a second time to transfer that space 
> to an ultimate recipient.  But each transaction performed 
> presents legal risk.  For example, if a putative provider 
> promises to transfer, but reneges, ARIN might find itself 
> having to sue to compel such sale.
> 
> Conversely, if a putative provider wants to sell ARIN 
> addresses at a given price, but ARIN is unwilling to pay that 
> price, the provider might sue ARIN, alleging that ARIN's 
> decision to reject that price was wrongful.  (The provider 
> might ground its case in a purchase it sees as similar, in 
> which some other provider received that price.)  As to 
> recipients, ARIN might face liability from those who wanted 
> v4 resource but did not receive it (at the prices they sought 
> to offer), and ARIN might feel compelled to enter litigation 
> if a recipient ultimately refuses to pay for resources it 
> received.  In short, ARIN would face important legal risks 
> both due to the multiple sequential transactions and due to 
> disputes potentially resulting from ARIN's significant 
> decision-making discretion as to the purchase and allocation 
> of v4 resource.
> 
> These risks may be worth accepting in order to get the 
> benefits of address transfers.  However, ARIN faces 
> significantly less legal risk from a other proposed 
> decentralized markets where ARIN's role is not central (e.g. 
> , see the market portion of an abandoned policy, 2008-6) in 
> which address providers and recipients were left to their own 
> resources to reach agreements directly between one another, 
> without ARIN serving to receive and transfer all resources 
> and all associated funds.
> 
> 
> III. Resource Impact
> 
> The resource impact of implementing this policy is viewed as 
> significant. It is estimated that this policy could require 
> up to 18 person months of effort to implement following 
> ratification by the ARIN Board of Trustees. Because this 
> implementation is not planned, it may preempt ARIN's current 
> project deployment schedule. It may require the
> following:
> 
>     * The development of a tracking system to monitor the transaction,
>       both the purchase and the sale, as well as the inventory.
>     * The development of a reporting system.
>     * Modifications to ARIN's existing business model would be needed,
>       particularly if ARIN gets into the business of buying 
> back address
>       space which then becomes designated as an asset and inventory.
>     * Increased fees due to potential litigation, legal costs, and
>       collection costs
>     * Modifications to existing registration procedures
>     * Staff training
>     * Guidelines updates
> 
> Text assessed:
> 
> Policy Proposal Name: IPv4 Recovery Fund
> 
> *Policy statement:*
> 
> * (Create new section in section 4, represented by "4.X".)*
> 
> *4.X IPv4 Recovery Fund*
> 
> 4.X.1 Implementation Timing
> 
> Upon receiving a valid request for a block larger than ARIN
> 
> can satisfy from its existing free pool, or, by obtaining
> 
> additional space from IANA, ARIN shall begin offering financial
> 
> incentives for returned IP blocks according to this policy.
> 
> 4.X.2 Recovery of IPv4 Space
> 
> ARIN believes that organizations should voluntarily return
> 
> unused and/or unneeded IP resources to the community. However,
> 
> upon implementation of this policy, ARIN will offer financial
> 
> incentives for the return of IPv4 resources to ARIN
> 
> relinquishment of any future claims to those resources. ARIN
> 
> will continue to accept voluntary returns.
> 
> 4.X.3 Allocation of Recovered Space
> 
> Once approved for IPv4 space ARIN will ask the requester to
> 
> specify a bid of how much they are willing to pay for
> 
> reclamation of address space. ARIN will use this bid in
> 
> determining what incentives to offer for return of space.
> 
> The requester may make a higher bid at any time, which is
> 
> treated as a brand new bid replacing their old bid.
> 
> If ARIN recovers space and offers it to requester at or below
> 
> the specified bid within 60 days of the time the bid was
> 
> made then the bid shall be binding on requester at the price
> 
> ARIN offers the space.
> 
> 4.X.4 Address Block Management
> 
> ARIN may not offer a partial fill, that is provide a block
> 
> smaller than the one for which the requester was approved.
> 
> ARIN may split recovered blocks into multiple smaller blocks
> 
> at the staff's discretion using the following principals:
> 
> - It is unlikely a request will be made for the address
> 
> block size involved in the next 60 days.
> 
> - The block is divided into as few parts as practical.
> 
> - There are enough bids to allow the entire block to be
> 
> allocated.
> 
> 4.X.5 Transparency
> 
> ARIN staff shall make public the current and historical
> 
> prices of asks, bids, and executed transactions in a manor
> 
> that facilitates the bidding process. ARIN staff must
> 
> regularly report on the amount of address space obtained and
> 
> distributed via this mechanism, number of blocks subdivided,
> 
> as well as aggregate financial numbers.
> 
> 4.X.6 Cost Recovery
> 
> ARIN shall manage the address space recovery program with a
> 
> goal of cost recovery.
> 
> ARIN may:
> 
> - Use ARIN funds to reclaim blocks when there is no specific
> 
> demand; if such reclamation is deemed in the best interest
> 
> of the community and there is a significant likelyhood of
> 
> future demand.
> 
> - Use a portion of the funds collected under this program
> 
> to pay for the implementation of this program.
> 
> 
> 
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 
> 



From stephen at sprunk.org  Tue Mar 24 15:14:42 2009
From: stephen at sprunk.org (Stephen Sprunk)
Date: Tue, 24 Mar 2009 14:14:42 -0500
Subject: [arin-ppml] Draft Policy 2009-2: Depleted IPv4 reserves
In-Reply-To: <4607e1d50903241037w18f2ec15qe182565ee4730ef2@mail.gmail.com>
References: <49C7DD7B.5000901@arin.net>
	<4607e1d50903241037w18f2ec15qe182565ee4730ef2@mail.gmail.com>
Message-ID: <49C93122.8070909@sprunk.org>

Martin Hannigan wrote:
>
>     *Policy statement:*
>
>     4.1.8 Depleted IPv4 reserves
>
>     A limit will be applied to all IPv4 address requests when ARIN's
>     reserve of unallocated IPv4 address space drops below an
>     equivalent /9. When this happens, an ISP or End User may receive
>     up to a single /20 within a six month period. This restriction
>     will be lifted in the event the reserve of unallocated IPv4
>     address space increases to an equivalent /7.
>
>
> This policy seems to impose exactly the same unfair application that 
> Counsel described in the summary for global policy for returning v4 
> space to the IANA[3]. Creating equal shares only means that equal 
> allocations occur. It still creates a severe need imbalance and 
> potentially creates an unfair advantage for smaller players that a /20 
> does fulfill their needs.

I can see why you'd think that, but I'll take an actual lawyer's opinion 
on that topic.  Per the email from Member Services that started this thread:

"B. ARIN General Counsel Comments:

The policy does not pose any significant legal risk to ARIN. A community 
decision to segment the remaining unissued IPV4 numbers to serve a 
larger number of users on its face does not discriminate against or for 
any user, large or small. Therefore it is legally unobjectionable. It is 
a rational scheme for distribution reasonably related to meeting the 
needs of as many end users as possible. Counsel respectfully suggests 
that the policy as drafted may contain potential seeds of confusion by 
providing for switching back to current distribution policies, and then 
back to this policy."

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3241 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090324/364c73ac/attachment.bin>

From stephen at sprunk.org  Tue Mar 24 15:20:21 2009
From: stephen at sprunk.org (Stephen Sprunk)
Date: Tue, 24 Mar 2009 14:20:21 -0500
Subject: [arin-ppml] Draft Policy 2008-3: Community Networks
	IPv6	Assignment
In-Reply-To: <142C7C752A94407CB818216C1495E666@tedsdesk>
References: <49C7DD5F.7070306@arin.net>
	<142C7C752A94407CB818216C1495E666@tedsdesk>
Message-ID: <49C93275.6080601@sprunk.org>

Ted Mittelstaedt wrote:
> I had thought that one of the big advantages of IPv6 is that it was designed to be simple to renumber.  
>
> Thus I am not sure why having "a stable and globally unique address assignment" has anything to do with having "a stable internal address structure" under IPv6.  I can understand why a community network would need the second thing, but I don't see why they can't have this under a globally unique address assignment that's made by a LIR instead of by ARIN.
>
> The community network's internal address structure would NOT change when their connections to outside networks come and go - under IPv6.
>   

This reasoning was officially rejected with the adoption of 2005-1.  
Please re-read the archives on that debate so that we don't have to 
rehash all those same tired, flawed arguments again.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3241 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090324/4bb13b08/attachment.bin>

From bicknell at ufp.org  Tue Mar 24 15:21:22 2009
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 24 Mar 2009 14:21:22 -0500
Subject: [arin-ppml] Draft Policy 2009-4: IPv4 Recovery Fund
In-Reply-To: <4E2F5C1D7DE44750A55F396303A96846@tedsdesk>
References: <49C7DD9A.6030907@arin.net>
	<4E2F5C1D7DE44750A55F396303A96846@tedsdesk>
Message-ID: <20090324192122.GA57501@ussenterprise.ufp.org>

In a message written on Tue, Mar 24, 2009 at 12:13:37PM -0700, Ted Mittelstaedt wrote:
> I also strongly oppose a policy like this that does not
> contain a sunset clause.  Once a tipping point is reached
> in IPv6 penetration, IPv4 will be in surplus and I don't
> want to see ARIN paying for addresses that 6 months later
> will be worthless.

While this proposal does not have a "sunset clause" it was designed
to automatically sunset.

Under this policy it is perfectly acceptable for folks to bid $0 (they
only want IPv4 resources if they are voluntarily returned to ARIN), or
not to bid at all (they don't want resources until we can return to
normal allocations).

ARIN staff will only be paying for the return of address space while
there are non-zero bids.

So if there is no more demand for IPv4, there are no more bids, and thus
ARIN ceases to purchase.  The policy automatically comes to an end.
Folks can bid $0, which will only be matched if space is voluntarily
returned to ARIN.

While the policy does not provide a specific timeframe (and indeed,
I think it is inappropriate to do so) it directs ARIN to offer
payments to recover space in proportion to the number of binding
bids received.  I see no way under this policy for ARIN to buy space
six months in advance, or to end up with a significant amount of
recovered but unwanted space.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090324/8f47dd81/attachment.sig>

From tedm at ipinc.net  Tue Mar 24 15:38:27 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 24 Mar 2009 12:38:27 -0700
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using
	theEmergency PDP)
In-Reply-To: <49C911A8.5020009@arin.net>
References: <49C911A8.5020009@arin.net>
Message-ID: <17D6E429B7DC4261B86619FC6F6EE3D2@tedsdesk>



As for the policy itself, my question to the board is this,
we have been having mergers and acquisitions of ISP's for years.
What were you doing previously when ISP A with numbering bought
ISP B with numbering, and came to you wanting to use the
numbers of ISP B?  Why can't you just keep doing that?  What
is it during a period of IPv4 scarcity that you think you can't do
with these mergers that you have been doing now, during a period
of non-scarcity?

Ted

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services
> Sent: Tuesday, March 24, 2009 10:00 AM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy 
> (Using theEmergency PDP)
> 
> Draft Policy 2009-1
> Transfer Policy
> 
> The ARIN Board of Trustees has declared a policy emergency 
> and is making use of the Emergency PDP provision in the ARIN 
> Policy Development Process to revise policy.
> 
> At their meeting on 6 February 2009 the ARIN Board of 
> Trustees, based on the recommendation of the ARIN Advisory 
> Council and noting that the Policy Development Process had 
> been followed, adopted Draft Policy
> 2008-6: Emergency Transfer Policy for IPv4 Addresses.
> 
> Then at their meeting on 8 March 2009, the Board noted there 
> is a gap in the transfer policy that limits the availability 
> of IPv4 address space at a time when otherwise available IPv4 
> address space will become scarce, and declared this gap an 
> emergency. The Board initiated the Emergency PDP of the 
> Policy Development Process in order to revise the transfer 
> policy (both the existing transfer policy and the policy just 
> adopted).
> 
> Per the Emergency PDP, the draft policy below is being posted 
> to the Public Policy Mailing List for 10 business days of 
> discussion and review by the community. The emergency 
> discussion period ends 7 April 2009.
> Within 5 business days of the end of discussion the Advisory 
> Council will, having reviewed the comments on the list, 
> review the draft policy and make a recommendation to the 
> Board of Trustees. The Board may adopt or reject the draft 
> policy. If the Board adopts the policy, it will be presented 
> at the next public policy meeting for reconsideration.
> 
> We encourage you to discuss Draft Policy 2009-1 on the PPML. 
> The discussion on the list will be used by the AC to 
> determine the community consensus regarding adopting this as policy.
> 
> Draft Policy 2009-1: Transfer Policy is available below and at:
> https://www.arin.net/policy/proposals/2009_1.html
> 
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
> 
> Policy 2008-6: Emergency Transfer Policy for IPv4 Addresses 
> can be found at:
> https://www.arin.net/policy/proposals/2008_6.html
> 
> Regards,
> 
> Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> ## * ##
> 
> 
> Draft Policy 2009-1
> Transfer Policy
> 
> Originator: ARIN Board of Trustees (using the Emergency PDP 
> provision in the ARIN Policy Development Process)
> 
> Date: 24 March 2009
> 
> Policy statement:
> 
> Insert into the ARIN Number Resource Policy Manual as follows:
> 
> Add Section 2.8:
> 
> "Organization. An Organization is one or more legal entities 
> under common control or ownership."
> 
> Replace Section 8 as follows:
> 
> 8. Transfers
> 
> 8.1. Principles
> 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. Mergers and Acquisitions
> ARIN will consider requests for the transfer of number 
> resources in the case of mergers and acquisitions 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.
> 
> 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) affecting 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 Transfers to Specified Recipients
> Number resources may be released, in whole or in part, to 
> ARIN for transfer to another specified organizational 
> recipient, by any authorized resource holder within the ARIN 
> region. Such transferred number resources may only be 
> received by organizations that are within the ARIN region and 
> can demonstrate the need for such resources in the exact 
> amount which they can justify under current ARIN policies.
> 
> #####
> 
> Notes:
> 
> Most of the existing Section 8 is left unchanged. List of changes:
> 
> 2.8 New.
> 8.1 Changes from "Transfers" to "Principles."
> 8.2 Changes from "Transfer Requirements" to "Mergers and 
> Acquisitions."
> 8.2 The word "only" is removed.
> 8.3 Merged up into 8.2.
> 8.3 Edited version of the adopted 2008-6.
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 
> 



From Matthew.Wilder at telus.com  Tue Mar 24 15:41:55 2009
From: Matthew.Wilder at telus.com (Matthew Wilder)
Date: Tue, 24 Mar 2009 13:41:55 -0600
Subject: [arin-ppml] Draft Policy 2009-2: Depleted IPv4 reserves
In-Reply-To: <49C92D3C.2010509@usfamily.net>
References: <49C7DD7B.5000901@arin.net>
	<DE229826F48ABD4CBF754E5AA6CFC14B1DDA22280E@WP40044.corp.ads>
	<49C9104E.3040105@sprunk.org>	<49C9241D.6050601@usfamily.net>
	<DE229826F48ABD4CBF754E5AA6CFC14B1DDA222B10@WP40044.corp.ads>
	<49C92D3C.2010509@usfamily.net>
Message-ID: <DE229826F48ABD4CBF754E5AA6CFC14B1DDA222B77@WP40044.corp.ads>

Hi Ron,

I will give you the benefit of the doubt here.  In case there was the slightest ambiguity with my comments, I will clarify my statements.

I did not at any point say that TELUS would be unable to transition to IPv6, so hold back your shock for a moment.  I suggested that TELUS might be unable to transition certain services to IPv6 before IPv4 exhaust.  At large organizations, there are too many inter-dependencies to make everything happen at once.  And I doubt there is an organization out there with more than 100 network elements who plans to switch off IPv4 before IPv4 address exhaust.  I hope that doesn't trouble you too much.

Cheers,
Matthew



Ron Cleven wrote:

> I have read over and over and over in this list that IPv6 is "the solution" to all the IPv4 depletion problems.  I have also seen tons of posts that explicitly or implicitly assert that only irresponsible ISP's will not be ready to go with IPv6 by the time IPv4 runs out.  After all, we have all known this day has been coming for the last decade.  Yet, you seem to saying that your large ISP who should be a leader in this movement will be unable to make the transition in time.  I'm shocked!

> Are there any other large ISP's monitoring this list who are the least bit concerned about the transition, or is Telus the only one who can't seem to figure this out?  Perhaps one of the large ISP's who has everything all figured out could share all their technical information to put Telus' mind to rest?

Matthew Wilder wrote:

> Ron wrote:
> 
>>Stephen's comments are spot on.  The large ISP's are the very ones who 
>>have both the resources and clout to make the IPv6 transition happen.
>>If they are unwilling or unable to do so, what does that say about the 
>>viability of ever making that transition?  Mr. Wilder doth protest too 
>>much.
> 
> 
> My explicit role in my organization is to ensure adequate IP Addressing to support service growth and new service introduction.  I believe without a doubt that the only way I will be successful in that mandate is to position IPv6 as the vehicle so that the IP Addresses are there.  
> 
> My organization is taking the steps necessary to get that transition happening, so we are not unwilling.  I can tell you that with certain services, we might well be unable to transition before IPv4 exhaust hits, but my focus is to transition the high growth services.  I want to make sure that the other services which may take longer to transition have the IP Addresses available, as I am sure every other admin POC out there is trying to ensure.
> 
> I don't protest for the sake of demanding unfair privileges on the behalf of large ISPs.  I protest a policy that says everyone can have their needs completely met except for one group, which can't even have a reasonable fraction of their need met.
> 
> Respectfully,
> Matthew Wilder


From tedm at ipinc.net  Tue Mar 24 15:47:09 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 24 Mar 2009 12:47:09 -0700
Subject: [arin-ppml] Draft Policy 2008-3: Community Networks
	IPv6	Assignment
In-Reply-To: <49C93275.6080601@sprunk.org>
References: <49C7DD5F.7070306@arin.net>
	<142C7C752A94407CB818216C1495E666@tedsdesk>
	<49C93275.6080601@sprunk.org>
Message-ID: <79EF89C62125463C8F77A13317D36816@tedsdesk>

 

> -----Original Message-----
> From: Stephen Sprunk [mailto:stephen at sprunk.org] 
> Sent: Tuesday, March 24, 2009 12:20 PM
> To: Ted Mittelstaedt
> Cc: ARIN PPML
> Subject: Re: [arin-ppml] Draft Policy 2008-3: Community 
> Networks IPv6 Assignment
> 
> Ted Mittelstaedt wrote:
> > I had thought that one of the big advantages of IPv6 is 
> that it was designed to be simple to renumber.  
> >
> > Thus I am not sure why having "a stable and globally unique 
> address assignment" has anything to do with having "a stable 
> internal address structure" under IPv6.  I can understand why 
> a community network would need the second thing, but I don't 
> see why they can't have this under a globally unique address 
> assignment that's made by a LIR instead of by ARIN.
> >
> > The community network's internal address structure would 
> NOT change when their connections to outside networks come 
> and go - under IPv6.
> >   
> 
> This reasoning was officially rejected with the adoption of 2005-1.  
> Please re-read the archives on that debate so that we don't 
> have to rehash all those same tired, flawed arguments again.
> 

No, that reasoning was rejected for networks LARGER than a /48

That is why the minimum size exists.

Or are you arguing that community networks of 100 users would
have such a complex internal network that they couldn't renumber?

Just how small a network do you have to have for you to keep
making this argument?  Or would you make the same arguments
about how it's impossible to renumbering for a single host
(that wasn't already covered under the micro allocations policy
such as used for a root nameserver, etc.)

Ted




From owen at delong.com  Tue Mar 24 15:45:48 2009
From: owen at delong.com (Owen DeLong)
Date: Tue, 24 Mar 2009 12:45:48 -0700
Subject: [arin-ppml] Draft Policy 2008-3: Community Networks IPv6
	Assignment
In-Reply-To: <142C7C752A94407CB818216C1495E666@tedsdesk>
References: <49C7DD5F.7070306@arin.net>
	<142C7C752A94407CB818216C1495E666@tedsdesk>
Message-ID: <91D8824B-745E-4430-AF80-697EF4849BC7@delong.com>

There is a disconnect between original IPv6 marketing hype
and reality here.

The "simple renumbering" and independent internal addressing
structure capabilities are not fully baked and have not as yet
materialized in IPv6.

Owen

On Mar 24, 2009, at 12:08 PM, Ted Mittelstaedt wrote:

>
> I had thought that one of the big advantages of IPv6 is that it was
> designed to be simple to renumber.
>
> Thus I am not sure why having "a stable and globally unique address
> assignment" has anything to do with having "a stable internal address
> structure" under IPv6.  I can understand why a community network would
> need the second thing, but I don't see why they can't have this under
> a globally unique address assignment that's made by a LIR instead of
> by ARIN.
>
> The community network's internal address structure would NOT change
> when their connections to outside networks come and go - under IPv6.
>
> Could the proposers explain what they need, here?  We all what to
> support non-profit community networks that help poor people get
> online, but at first blush this looks like the proposal authors are
> assuming IPv6 == IPv4.
>
>
> Ted
>
>
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net
>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services
>> Sent: Monday, March 23, 2009 12:05 PM
>> To: arin-ppml at arin.net
>> Subject: [arin-ppml] Draft Policy 2008-3: Community Networks
>> IPv6 Assignment
>>
>> SUBJECT: Draft Policy 2008-3: Community Networks IPv6 Assignment
>>
>> Draft Policy 2008-3
>> Community Networks IPv6 Assignment
>>
>> The following draft policy text is being posted for feedback
>> and discussion on the Public Policy Mailing List (PPML).
>>
>> After the October 2008 Public Policy Meeting the ARIN Advisory  
>> Council
>> (AC) decided that 2008-3 required more work. The text below
>> was developed by the AC. The AC was required to submit text
>> to ARIN for staff and legal assessment prior to selecting it
>> as a draft policy. The assessment, along with the text that
>> was assessed, is located below the draft policy.
>>
>> On 20 March 2009 the ARIN Advisory Council (AC) selected Draft Policy
>> 2008-3: Community Networks IPv6 Assignment for adoption
>> discussion on the PPML and at the upcoming Public Policy Meeting.
>>
>> Draft Policy 2008-3 is below and can be found at:
>> https://www.arin.net/policy/proposals/2008_3.html
>>
>> We encourage you to discuss Draft Policy 2008-3 on PPML prior
>> to the ARIN XXIII Public Policy Meeting. Both the discussion
>> on the PPML and at the Public Policy Meeting will be used by
>> the ARIN Advisory Council to determine the community
>> consensus regarding adopting this as policy.
>>
>> The ARIN Policy Development Process can be found at:
>> https://www.arin.net/policy/pdp.html
>>
>> All of the Draft Policies under discussion can be found at:
>> https://www.arin.net/policy/proposals/index.html
>>
>> Regards,
>>
>> Member Services
>> American Registry for Internet Numbers (ARIN)
>>
>>
>> ## * ##
>>
>>
>> Draft Policy 2008-3
>> Community Networks IPv6 Assignment
>>
>> Date: 23 March 2009
>>
>> Policy statement:
>>
>> [Add Section 2.8 to the NRPM.]
>>
>> 2.8 Community Network
>>
>> A community network is any network organized and operated by
>> a mostly volunteer group operating as or under the fiscal
>> support of a non-profit organization or university for the
>> purpose of providing free or low-cost connectivity to the
>> residents of their local service area. To be treated as a
>> community network under ARIN policy, the applicant must
>> further certify to ARIN that the community network staff is
>> at least 50% volunteer and that the annual budget for
>> community network activities is less than $250,000.
>>
>> [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 qualifying
>> Community Network as defined in Section 2.8, with assignment
>> criteria defined in section 6.5.9.
>>
>> [Add Section 6.5.9 to the NRPM.]
>>
>> 6.5.9 Community Network Assignments
>>
>> 6.5.9.1 Qualification Criteria
>>
>> To qualify for a direct assignment, a community network must
>> demonstrate it will immediately provide sustained service to
>> at least 100 simultaneous users and must demonstrate a plan
>> to provide sustained service to at least 200 simultaneous
>> users within one year. For community networks located in
>> rural regions or in the Caribbean and North Atlantic Islands
>> Sector, the numbers in these qualification criteria may be
>> relaxed at ARIN's discretion.
>>
>> 6.5.9.2. Initial assignment size
>>
>> The minimum size of the assignment is /48. Organizations
>> requesting a larger assignment must provide documentation of
>> the characteristics of the Community Network's size and
>> architecture that require the use of additional subnets. An
>> HD-Ratio of .94 with respect to subnet utilization within the
>> network must be met for all assignments larger than a /48.
>> These assignments shall be made from a distinctly identified
>> prefix and shall be made with a reservation for growth of at
>> least a /44. This reservation may be assigned to other
>> organizations later, at ARIN's discretion.
>>
>> 6.5.9.3. Subsequent assignment size
>>
>> Additional assignments may be made when the need for
>> additional subnets is justified. Justification will be
>> determined based on a detailed plan of the network's
>> architecture and the .94 HD-Ratio metric. When possible,
>> assignments will be made from an aggregatable adjacent address block.
>>
>>
>> Rationale:
>>
>> this policy was originally proposed by community network
>> operators to provide them with the ability to receive a
>> direct assignment of IPv6 address resources from ARIN. the
>> operators of such networks have expressed their need to have
>> a stable and globally unique address assignment with which to
>> number their network infrastructure. many such networks are
>> not able to meet the current criteria for a PI IPv6
>> assignment from ARIN. in an environment where connections to
>> outside networks may come and go, a stable internal address
>> structure would be very valuable. additionally, the ability
>> to exchange routes with others, whether locally or tunneled,
>> and thereby have native IPv6 connectivity, would be quite
>> beneficial. these operators were also hopeful that, once this
>> new class of address assignments was created, they could
>> pursue lower annual fees for community networks through the
>> ARIN Consultation and Suggestion Process (ACSP).
>>
>> there could also be a number of potential benefits to
>> allowing community network participants to begin using IPv6
>> addressing. some of these networks have many technically
>> capable and adventurous members who would be motivated to
>> begin developing and/or experimenting with the software
>> extensions which will be needed to support IPv6 prefix
>> selection among multiple IPv6 prefixes when establishing
>> remote connections. also, participants in networks receiving
>> such assignments will have the necessary global-ID to
>> experiment with the various proposals currently being
>> developed for separating network locater from network ID.
>>
>> also, during the more than one year timeframe that this
>> policy has been under consideration, other people have
>> suggested other scenarios where community networks would
>> provide a valuable resource. one such proposal was discussed
>> at one of the Caribbean Sector meetings where some
>> participants pointed out the efforts were being made in
>> remote or sparsely populated areas to establish community
>> networks which would serve as connections back to educational
>> resources for distant learning capabilities. there are also
>> many still wild areas of North America where such community
>> networks could provide improved connectivity over telephone modems.
>>
>> Timetable for implementation: Immediate.
>>
>>
>> #####
>>
>>
>> ARIN Staff Assessment
>>
>> *2008-3*
>>
>> *Title: Community Networks IPv6 Allocation*
>>
>> *Proposal Submitted: 04 March 2008*
>>
>> *Latest Revision Submitted: 06 March 2009 (includes AC revisions)*
>>
>> *Date of Assessment: 15 March 2009*
>>
>> I. Understanding of the Policy:
>>
>> *Staff Understanding of the Proposal:*
>>
>> ARIN staff understands this policy would provide an IPv6
>> assignment of a
>> /48 or larger to any community network that can demonstrate
>> it will provide service to at least 100 users immediately,
>> and have a plan to demonstrate that it will provide service
>> to at least 200 users within one year.
>>
>> II. Comments
>>
>> A. ARIN Staff Comments:
>>
>> . The title of the policy says "allocation" while this policy
>> is clearly an "assignment" policy. Therefore, the title
>> should be changed. In addition, the title of section 6.5.9
>> should be changed to say "assignment" and not "allocation".
>>
>> B. ARIN General Counsel Comments:
>>
>> Counsel sees no significant legal or litigation risk
>> regarding this policy.
>>
>> III. Resource Impact
>>
>> The resource impact of implementing this policy is viewed as
>> minimal. It is estimated that this policy could require up to
>> 1 person month of effort to implement following ratification
>> by the ARIN Board of Trustees. It may require the following:
>>
>>    * Guidelines Changes
>>    * Staff training
>>    * Development of new internal procedures
>>
>> Text assessed:
>>
>> 2008-3: Community Networks IPv6 Allocation**
>>
>> *Policy statement:*
>>
>> [Add Section 2.8 to the NRPM.]
>>
>> 2.8 Community Network
>>
>> A community network is any network organized and operated by
>> a mostly volunteer group operating as or under the fiscal
>> support of a non-profit organization or university for the
>> purpose of providing free or low-cost connectivity to the
>> residents of their local service area. To be treated as a
>> community network under ARIN policy, the applicant must
>> further certify to ARIN that the community network staff is
>> at least 50% volunteer and that the annual budget for
>> community network activities is less than $250,000.
>>
>> [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 qualifying
>> Community Network as defined in Section 2.8, with allocation
>> criteria defined in section 6.5.9.
>>
>> [Add Section 6.5.9 to the NRPM.]
>>
>> 6.5.9 Community Network Allocations
>>
>> 6.5.9.1 Qualification Criteria
>>
>> To qualify for a direct assignment, a community network must
>> demonstrate it will immediately provide sustained service to
>> at least 100 simultaneous users and must demonstrate a plan
>> to provide sustained service to at least 200 simultaneous
>> users within one year. For community networks located in
>> rural regions or in the Caribbean and North Atlantic Islands
>> Sector, the numbers in these qualification criteria may be
>> relaxed at ARIN's discretion.
>>
>> 6.5.9.2. Initial assignment size
>>
>> The minimum size of the assignment is /48. Organizations
>> requesting a larger assignment must provide documentation of
>> the characteristics of the Community Network's size and
>> architecture that require the use of additional subnets. An
>> HD-Ratio of .94 with respect to subnet utilization within the
>> network must be met for all assignments larger than a /48.
>> These assignments shall be made from a distinctly identified
>> prefix and shall be made with a reservation for growth of at
>> least a /44. This reservation may be assigned to other
>> organizations later, at ARIN's discretion.
>>
>> 6.5.9.3. Subsequent assignment size
>>
>> Additional assignments may be made when the need for
>> additional subnets is justified. Justification will be
>> determined based on a detailed plan of the network's
>> architecture and the .94 HD-Ratio metric. When possible,
>> assignments will be made from an aggregatable adjacent address block.
>>
>>
>>
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
>>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From tedm at ipinc.net  Tue Mar 24 15:52:55 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 24 Mar 2009 12:52:55 -0700
Subject: [arin-ppml] Draft Policy 2008-3: Community Networks IPv6
	Assignment
In-Reply-To: <91D8824B-745E-4430-AF80-697EF4849BC7@delong.com>
References: <49C7DD5F.7070306@arin.net>
	<142C7C752A94407CB818216C1495E666@tedsdesk>
	<91D8824B-745E-4430-AF80-697EF4849BC7@delong.com>
Message-ID: <CA0DC7B5B1614D33BCC6C300C7654C02@tedsdesk>


And your position on 2008-3 is....? 

Ted

> -----Original Message-----
> From: Owen DeLong [mailto:owen at delong.com] 
> Sent: Tuesday, March 24, 2009 12:46 PM
> To: Ted Mittelstaedt
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy 2008-3: Community 
> Networks IPv6 Assignment
> 
> There is a disconnect between original IPv6 marketing hype 
> and reality here.
> 
> The "simple renumbering" and independent internal addressing 
> structure capabilities are not fully baked and have not as 
> yet materialized in IPv6.
> 
> Owen
> 
> On Mar 24, 2009, at 12:08 PM, Ted Mittelstaedt wrote:
> 
> >
> > I had thought that one of the big advantages of IPv6 is that it was 
> > designed to be simple to renumber.
> >
> > Thus I am not sure why having "a stable and globally unique address 
> > assignment" has anything to do with having "a stable 
> internal address 
> > structure" under IPv6.  I can understand why a community 
> network would 
> > need the second thing, but I don't see why they can't have 
> this under 
> > a globally unique address assignment that's made by a LIR 
> instead of 
> > by ARIN.
> >
> > The community network's internal address structure would NOT change 
> > when their connections to outside networks come and go - under IPv6.
> >
> > Could the proposers explain what they need, here?  We all what to 
> > support non-profit community networks that help poor people get 
> > online, but at first blush this looks like the proposal authors are 
> > assuming IPv6 == IPv4.
> >
> >
> > Ted
> >
> >
> >> -----Original Message-----
> >> From: arin-ppml-bounces at arin.net
> >> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services
> >> Sent: Monday, March 23, 2009 12:05 PM
> >> To: arin-ppml at arin.net
> >> Subject: [arin-ppml] Draft Policy 2008-3: Community Networks
> >> IPv6 Assignment
> >>
> >> SUBJECT: Draft Policy 2008-3: Community Networks IPv6 Assignment
> >>
> >> Draft Policy 2008-3
> >> Community Networks IPv6 Assignment
> >>
> >> The following draft policy text is being posted for feedback and 
> >> discussion on the Public Policy Mailing List (PPML).
> >>
> >> After the October 2008 Public Policy Meeting the ARIN Advisory 
> >> Council
> >> (AC) decided that 2008-3 required more work. The text below was 
> >> developed by the AC. The AC was required to submit text to 
> ARIN for 
> >> staff and legal assessment prior to selecting it as a 
> draft policy. 
> >> The assessment, along with the text that was assessed, is located 
> >> below the draft policy.
> >>
> >> On 20 March 2009 the ARIN Advisory Council (AC) selected 
> Draft Policy
> >> 2008-3: Community Networks IPv6 Assignment for adoption 
> discussion on 
> >> the PPML and at the upcoming Public Policy Meeting.
> >>
> >> Draft Policy 2008-3 is below and can be found at:
> >> https://www.arin.net/policy/proposals/2008_3.html
> >>
> >> We encourage you to discuss Draft Policy 2008-3 on PPML 
> prior to the 
> >> ARIN XXIII Public Policy Meeting. Both the discussion on 
> the PPML and 
> >> at the Public Policy Meeting will be used by the ARIN Advisory 
> >> Council to determine the community consensus regarding 
> adopting this 
> >> as policy.
> >>
> >> The ARIN Policy Development Process can be found at:
> >> https://www.arin.net/policy/pdp.html
> >>
> >> All of the Draft Policies under discussion can be found at:
> >> https://www.arin.net/policy/proposals/index.html
> >>
> >> Regards,
> >>
> >> Member Services
> >> American Registry for Internet Numbers (ARIN)
> >>
> >>
> >> ## * ##
> >>
> >>
> >> Draft Policy 2008-3
> >> Community Networks IPv6 Assignment
> >>
> >> Date: 23 March 2009
> >>
> >> Policy statement:
> >>
> >> [Add Section 2.8 to the NRPM.]
> >>
> >> 2.8 Community Network
> >>
> >> A community network is any network organized and operated 
> by a mostly 
> >> volunteer group operating as or under the fiscal support of a 
> >> non-profit organization or university for the purpose of providing 
> >> free or low-cost connectivity to the residents of their 
> local service 
> >> area. To be treated as a community network under ARIN policy, the 
> >> applicant must further certify to ARIN that the community network 
> >> staff is at least 50% volunteer and that the annual budget for 
> >> community network activities is less than $250,000.
> >>
> >> [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 qualifying 
> Community Network 
> >> as defined in Section 2.8, with assignment criteria defined in 
> >> section 6.5.9.
> >>
> >> [Add Section 6.5.9 to the NRPM.]
> >>
> >> 6.5.9 Community Network Assignments
> >>
> >> 6.5.9.1 Qualification Criteria
> >>
> >> To qualify for a direct assignment, a community network must 
> >> demonstrate it will immediately provide sustained service 
> to at least 
> >> 100 simultaneous users and must demonstrate a plan to provide 
> >> sustained service to at least 200 simultaneous users 
> within one year. 
> >> For community networks located in rural regions or in the 
> Caribbean 
> >> and North Atlantic Islands Sector, the numbers in these 
> qualification 
> >> criteria may be relaxed at ARIN's discretion.
> >>
> >> 6.5.9.2. Initial assignment size
> >>
> >> The minimum size of the assignment is /48. Organizations 
> requesting a 
> >> larger assignment must provide documentation of the 
> characteristics 
> >> of the Community Network's size and architecture that 
> require the use 
> >> of additional subnets. An HD-Ratio of .94 with respect to subnet 
> >> utilization within the network must be met for all 
> assignments larger 
> >> than a /48.
> >> These assignments shall be made from a distinctly 
> identified prefix 
> >> and shall be made with a reservation for growth of at least a /44. 
> >> This reservation may be assigned to other organizations later, at 
> >> ARIN's discretion.
> >>
> >> 6.5.9.3. Subsequent assignment size
> >>
> >> Additional assignments may be made when the need for additional 
> >> subnets is justified. Justification will be determined based on a 
> >> detailed plan of the network's architecture and the .94 HD-Ratio 
> >> metric. When possible, assignments will be made from an 
> aggregatable 
> >> adjacent address block.
> >>
> >>
> >> Rationale:
> >>
> >> this policy was originally proposed by community network 
> operators to 
> >> provide them with the ability to receive a direct 
> assignment of IPv6 
> >> address resources from ARIN. the operators of such networks have 
> >> expressed their need to have a stable and globally unique address 
> >> assignment with which to number their network infrastructure. many 
> >> such networks are not able to meet the current criteria 
> for a PI IPv6 
> >> assignment from ARIN. in an environment where connections 
> to outside 
> >> networks may come and go, a stable internal address 
> structure would 
> >> be very valuable. additionally, the ability to exchange 
> routes with 
> >> others, whether locally or tunneled, and thereby have native IPv6 
> >> connectivity, would be quite beneficial. these operators were also 
> >> hopeful that, once this new class of address assignments 
> was created, 
> >> they could pursue lower annual fees for community networks through 
> >> the ARIN Consultation and Suggestion Process (ACSP).
> >>
> >> there could also be a number of potential benefits to allowing 
> >> community network participants to begin using IPv6 
> addressing. some 
> >> of these networks have many technically capable and adventurous 
> >> members who would be motivated to begin developing and/or 
> >> experimenting with the software extensions which will be needed to 
> >> support IPv6 prefix selection among multiple IPv6 prefixes when 
> >> establishing remote connections. also, participants in networks 
> >> receiving such assignments will have the necessary global-ID to 
> >> experiment with the various proposals currently being 
> developed for 
> >> separating network locater from network ID.
> >>
> >> also, during the more than one year timeframe that this policy has 
> >> been under consideration, other people have suggested 
> other scenarios 
> >> where community networks would provide a valuable 
> resource. one such 
> >> proposal was discussed at one of the Caribbean Sector 
> meetings where 
> >> some participants pointed out the efforts were being made 
> in remote 
> >> or sparsely populated areas to establish community networks which 
> >> would serve as connections back to educational resources 
> for distant 
> >> learning capabilities. there are also many still wild 
> areas of North 
> >> America where such community networks could provide improved 
> >> connectivity over telephone modems.
> >>
> >> Timetable for implementation: Immediate.
> >>
> >>
> >> #####
> >>
> >>
> >> ARIN Staff Assessment
> >>
> >> *2008-3*
> >>
> >> *Title: Community Networks IPv6 Allocation*
> >>
> >> *Proposal Submitted: 04 March 2008*
> >>
> >> *Latest Revision Submitted: 06 March 2009 (includes AC revisions)*
> >>
> >> *Date of Assessment: 15 March 2009*
> >>
> >> I. Understanding of the Policy:
> >>
> >> *Staff Understanding of the Proposal:*
> >>
> >> ARIN staff understands this policy would provide an IPv6 
> assignment 
> >> of a
> >> /48 or larger to any community network that can 
> demonstrate it will 
> >> provide service to at least 100 users immediately, and 
> have a plan to 
> >> demonstrate that it will provide service to at least 200 
> users within 
> >> one year.
> >>
> >> II. Comments
> >>
> >> A. ARIN Staff Comments:
> >>
> >> . The title of the policy says "allocation" while this policy is 
> >> clearly an "assignment" policy. Therefore, the title should be 
> >> changed. In addition, the title of section 6.5.9 should be 
> changed to 
> >> say "assignment" and not "allocation".
> >>
> >> B. ARIN General Counsel Comments:
> >>
> >> Counsel sees no significant legal or litigation risk 
> regarding this 
> >> policy.
> >>
> >> III. Resource Impact
> >>
> >> The resource impact of implementing this policy is viewed 
> as minimal. 
> >> It is estimated that this policy could require up to
> >> 1 person month of effort to implement following 
> ratification by the 
> >> ARIN Board of Trustees. It may require the following:
> >>
> >>    * Guidelines Changes
> >>    * Staff training
> >>    * Development of new internal procedures
> >>
> >> Text assessed:
> >>
> >> 2008-3: Community Networks IPv6 Allocation**
> >>
> >> *Policy statement:*
> >>
> >> [Add Section 2.8 to the NRPM.]
> >>
> >> 2.8 Community Network
> >>
> >> A community network is any network organized and operated 
> by a mostly 
> >> volunteer group operating as or under the fiscal support of a 
> >> non-profit organization or university for the purpose of providing 
> >> free or low-cost connectivity to the residents of their 
> local service 
> >> area. To be treated as a community network under ARIN policy, the 
> >> applicant must further certify to ARIN that the community network 
> >> staff is at least 50% volunteer and that the annual budget for 
> >> community network activities is less than $250,000.
> >>
> >> [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 qualifying 
> Community Network 
> >> as defined in Section 2.8, with allocation criteria defined in 
> >> section 6.5.9.
> >>
> >> [Add Section 6.5.9 to the NRPM.]
> >>
> >> 6.5.9 Community Network Allocations
> >>
> >> 6.5.9.1 Qualification Criteria
> >>
> >> To qualify for a direct assignment, a community network must 
> >> demonstrate it will immediately provide sustained service 
> to at least 
> >> 100 simultaneous users and must demonstrate a plan to provide 
> >> sustained service to at least 200 simultaneous users 
> within one year. 
> >> For community networks located in rural regions or in the 
> Caribbean 
> >> and North Atlantic Islands Sector, the numbers in these 
> qualification 
> >> criteria may be relaxed at ARIN's discretion.
> >>
> >> 6.5.9.2. Initial assignment size
> >>
> >> The minimum size of the assignment is /48. Organizations 
> requesting a 
> >> larger assignment must provide documentation of the 
> characteristics 
> >> of the Community Network's size and architecture that 
> require the use 
> >> of additional subnets. An HD-Ratio of .94 with respect to subnet 
> >> utilization within the network must be met for all 
> assignments larger 
> >> than a /48.
> >> These assignments shall be made from a distinctly 
> identified prefix 
> >> and shall be made with a reservation for growth of at least a /44. 
> >> This reservation may be assigned to other organizations later, at 
> >> ARIN's discretion.
> >>
> >> 6.5.9.3. Subsequent assignment size
> >>
> >> Additional assignments may be made when the need for additional 
> >> subnets is justified. Justification will be determined based on a 
> >> detailed plan of the network's architecture and the .94 HD-Ratio 
> >> metric. When possible, assignments will be made from an 
> aggregatable 
> >> adjacent address block.
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> PPML
> >> You are receiving this message because you are subscribed 
> to the ARIN 
> >> Public Policy Mailing List (ARIN-PPML at arin.net).
> >> Unsubscribe or manage your mailing list subscription at:
> >> http://lists.arin.net/mailman/listinfo/arin-ppml
> >> Please contact info at arin.net if you experience any issues.
> >>
> >>
> >
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed 
> to the ARIN 
> > Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> 
> 



From pstewart at nexicomgroup.net  Tue Mar 24 15:49:19 2009
From: pstewart at nexicomgroup.net (Paul Stewart)
Date: Tue, 24 Mar 2009 15:49:19 -0400
Subject: [arin-ppml] Draft Policy 2009-2: Depleted IPv4 reserves
In-Reply-To: <DE229826F48ABD4CBF754E5AA6CFC14B1DDA222B77@WP40044.corp.ads>
References: <49C7DD7B.5000901@arin.net><DE229826F48ABD4CBF754E5AA6CFC14B1DDA22280E@WP40044.corp.ads><49C9104E.3040105@sprunk.org>	<49C9241D.6050601@usfamily.net><DE229826F48ABD4CBF754E5AA6CFC14B1DDA222B10@WP40044.corp.ads><49C92D3C.2010509@usfamily.net>
	<DE229826F48ABD4CBF754E5AA6CFC14B1DDA222B77@WP40044.corp.ads>
Message-ID: <89D27DE3375BB6428DDCC2927489826A02223F9E@nexus.nexicomgroup.net>

While we are not large by any stretch, we do have *well* over 100
network elements - our core and distribution are all dual stack today.
Our plan is that any new customer deployments (starting middle of this
year) would involve dual stack to the customer premise.  Then we would
work our way back within a year of starting to run dual-stack at all
existing locations.

By putting it into our workflow of a standard deployment and then
focusing efforts on converting existing elements to dual stack, we feel
we can easily do this within a year.

With dual stack everywhere, then the "pressure is off" from our
perspective to avoid any sudden panic situations...

Just my two cents worth...

Paul


-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Matthew Wilder
Sent: Tuesday, March 24, 2009 3:42 PM
To: Ron Cleven; ARIN PPML
Subject: Re: [arin-ppml] Draft Policy 2009-2: Depleted IPv4 reserves

Hi Ron,

I will give you the benefit of the doubt here.  In case there was the
slightest ambiguity with my comments, I will clarify my statements.

I did not at any point say that TELUS would be unable to transition to
IPv6, so hold back your shock for a moment.  I suggested that TELUS
might be unable to transition certain services to IPv6 before IPv4
exhaust.  At large organizations, there are too many inter-dependencies
to make everything happen at once.  And I doubt there is an organization
out there with more than 100 network elements who plans to switch off
IPv4 before IPv4 address exhaust.  I hope that doesn't trouble you too
much.

Cheers,
Matthew



Ron Cleven wrote:

> I have read over and over and over in this list that IPv6 is "the
solution" to all the IPv4 depletion problems.  I have also seen tons of
posts that explicitly or implicitly assert that only irresponsible ISP's
will not be ready to go with IPv6 by the time IPv4 runs out.  After all,
we have all known this day has been coming for the last decade.  Yet,
you seem to saying that your large ISP who should be a leader in this
movement will be unable to make the transition in time.  I'm shocked!

> Are there any other large ISP's monitoring this list who are the least
bit concerned about the transition, or is Telus the only one who can't
seem to figure this out?  Perhaps one of the large ISP's who has
everything all figured out could share all their technical information
to put Telus' mind to rest?

Matthew Wilder wrote:

> Ron wrote:
> 
>>Stephen's comments are spot on.  The large ISP's are the very ones who

>>have both the resources and clout to make the IPv6 transition happen.
>>If they are unwilling or unable to do so, what does that say about the

>>viability of ever making that transition?  Mr. Wilder doth protest too

>>much.
> 
> 
> My explicit role in my organization is to ensure adequate IP
Addressing to support service growth and new service introduction.  I
believe without a doubt that the only way I will be successful in that
mandate is to position IPv6 as the vehicle so that the IP Addresses are
there.  
> 
> My organization is taking the steps necessary to get that transition
happening, so we are not unwilling.  I can tell you that with certain
services, we might well be unable to transition before IPv4 exhaust
hits, but my focus is to transition the high growth services.  I want to
make sure that the other services which may take longer to transition
have the IP Addresses available, as I am sure every other admin POC out
there is trying to ensure.
> 
> I don't protest for the sake of demanding unfair privileges on the
behalf of large ISPs.  I protest a policy that says everyone can have
their needs completely met except for one group, which can't even have a
reasonable fraction of their need met.
> 
> Respectfully,
> Matthew Wilder
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.


From kkargel at polartel.com  Tue Mar 24 16:09:06 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 24 Mar 2009 15:09:06 -0500
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using
	theEmergency PDP)
In-Reply-To: <49C911A8.5020009@arin.net>
References: <49C911A8.5020009@arin.net>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AF06@mail>



2008-6 met with great resistance when it was presented in the past.  While
the text of 2008-6 says it's intent is not to create a market that is
exactly what it does.  

I continue to stand firm against p2p transfer policies and I find the boards
use of emergency powers to implement such a policy against or in spite of
the wishes of the community abusive.

I do not think there is much I can do other than whine, and this does show
to me the futility of trying to be active and part of the process.  I guess
that money wins out and people will do whatever it takes to create the
artificial IP address market.  

This leaves me quite disheartened and with a much less confidence in ARIN
administration.  

Kevin Kargel


> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Member Services
> Sent: Tuesday, March 24, 2009 12:00 PM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using
> theEmergency PDP)
> 
> Draft Policy 2009-1
> Transfer Policy
> 
> The ARIN Board of Trustees has declared a policy emergency and is making
> use of the Emergency PDP provision in the ARIN Policy Development
> Process to revise policy.
> 
> At their meeting on 6 February 2009 the ARIN Board of Trustees, based on
> the recommendation of the ARIN Advisory Council and noting that the
> Policy Development Process had been followed, adopted Draft Policy
> 2008-6: Emergency Transfer Policy for IPv4 Addresses.
> 
> Then at their meeting on 8 March 2009, the Board noted there is a gap in
> the transfer policy that limits the availability of IPv4 address space
> at a time when otherwise available IPv4 address space will become
> scarce, and declared this gap an emergency. The Board initiated the
> Emergency PDP of the Policy Development Process in order to revise the
> transfer policy (both the existing transfer policy and the policy just
> adopted).
> 
> Per the Emergency PDP, the draft policy below is being posted to the
> Public Policy Mailing List for 10 business days of discussion and review
> by the community. The emergency discussion period ends 7 April 2009.
> Within 5 business days of the end of discussion the Advisory Council
> will, having reviewed the comments on the list, review the draft policy
> and make a recommendation to the Board of Trustees. The Board may adopt
> or reject the draft policy. If the Board adopts the policy, it will be
> presented at the next public policy meeting for reconsideration.
> 
> We encourage you to discuss Draft Policy 2009-1 on the PPML. The
> discussion on the list will be used by the AC to determine the community
> consensus regarding adopting this as policy.
> 
> Draft Policy 2009-1: Transfer Policy is available below and at:
> https://www.arin.net/policy/proposals/2009_1.html
> 
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
> 
> Policy 2008-6: Emergency Transfer Policy for IPv4 Addresses can be found
> at:
> https://www.arin.net/policy/proposals/2008_6.html
> 
> Regards,
> 
> Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> ## * ##
> 
> 
> Draft Policy 2009-1
> Transfer Policy
> 
> Originator: ARIN Board of Trustees (using the Emergency PDP provision in
> the ARIN Policy Development Process)
> 
> Date: 24 March 2009
> 
> Policy statement:
> 
> Insert into the ARIN Number Resource Policy Manual as follows:
> 
> Add Section 2.8:
> 
> "Organization. An Organization is one or more legal entities under
> common control or ownership."
> 
> Replace Section 8 as follows:
> 
> 8. Transfers
> 
> 8.1. Principles
> 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. Mergers and Acquisitions
> ARIN will consider requests for the transfer of number resources in the
> case of mergers and acquisitions 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.
> 
> 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) affecting 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 Transfers to Specified Recipients
> Number resources may be released, in whole or in part, to ARIN for
> transfer to another specified organizational recipient, by any
> authorized resource holder within the ARIN region. Such transferred
> number resources may only be received by organizations that are within
> the ARIN region and can demonstrate the need for such resources in the
> exact amount which they can justify under current ARIN policies.
> 
> #####
> 
> Notes:
> 
> Most of the existing Section 8 is left unchanged. List of changes:
> 
> 2.8 New.
> 8.1 Changes from "Transfers" to "Principles."
> 8.2 Changes from "Transfer Requirements" to "Mergers and Acquisitions."
> 8.2 The word "only" is removed.
> 8.3 Merged up into 8.2.
> 8.3 Edited version of the adopted 2008-6.
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090324/168d8b6d/attachment.bin>

From tedm at ipinc.net  Tue Mar 24 16:11:08 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 24 Mar 2009 13:11:08 -0700
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using
	theEmergency PDP)
In-Reply-To: <49C911A8.5020009@arin.net>
References: <49C911A8.5020009@arin.net>
Message-ID: <2D7A012DEE8A4B049DEC8488867A089A@tedsdesk>


We are opposed to this.

Ted 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services
> Sent: Tuesday, March 24, 2009 10:00 AM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy 
> (Using theEmergency PDP)
> 
> Draft Policy 2009-1
> Transfer Policy
> 
> The ARIN Board of Trustees has declared a policy emergency 
> and is making use of the Emergency PDP provision in the ARIN 
> Policy Development Process to revise policy.
> 
> At their meeting on 6 February 2009 the ARIN Board of 
> Trustees, based on the recommendation of the ARIN Advisory 
> Council and noting that the Policy Development Process had 
> been followed, adopted Draft Policy
> 2008-6: Emergency Transfer Policy for IPv4 Addresses.
> 
> Then at their meeting on 8 March 2009, the Board noted there 
> is a gap in the transfer policy that limits the availability 
> of IPv4 address space at a time when otherwise available IPv4 
> address space will become scarce, and declared this gap an 
> emergency. The Board initiated the Emergency PDP of the 
> Policy Development Process in order to revise the transfer 
> policy (both the existing transfer policy and the policy just 
> adopted).
> 
> Per the Emergency PDP, the draft policy below is being posted 
> to the Public Policy Mailing List for 10 business days of 
> discussion and review by the community. The emergency 
> discussion period ends 7 April 2009.
> Within 5 business days of the end of discussion the Advisory 
> Council will, having reviewed the comments on the list, 
> review the draft policy and make a recommendation to the 
> Board of Trustees. The Board may adopt or reject the draft 
> policy. If the Board adopts the policy, it will be presented 
> at the next public policy meeting for reconsideration.
> 
> We encourage you to discuss Draft Policy 2009-1 on the PPML. 
> The discussion on the list will be used by the AC to 
> determine the community consensus regarding adopting this as policy.
> 
> Draft Policy 2009-1: Transfer Policy is available below and at:
> https://www.arin.net/policy/proposals/2009_1.html
> 
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
> 
> Policy 2008-6: Emergency Transfer Policy for IPv4 Addresses 
> can be found at:
> https://www.arin.net/policy/proposals/2008_6.html
> 
> Regards,
> 
> Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> ## * ##
> 
> 
> Draft Policy 2009-1
> Transfer Policy
> 
> Originator: ARIN Board of Trustees (using the Emergency PDP 
> provision in the ARIN Policy Development Process)
> 
> Date: 24 March 2009
> 
> Policy statement:
> 
> Insert into the ARIN Number Resource Policy Manual as follows:
> 
> Add Section 2.8:
> 
> "Organization. An Organization is one or more legal entities 
> under common control or ownership."
> 
> Replace Section 8 as follows:
> 
> 8. Transfers
> 
> 8.1. Principles
> 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. Mergers and Acquisitions
> ARIN will consider requests for the transfer of number 
> resources in the case of mergers and acquisitions 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.
> 
> 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) affecting 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 Transfers to Specified Recipients
> Number resources may be released, in whole or in part, to 
> ARIN for transfer to another specified organizational 
> recipient, by any authorized resource holder within the ARIN 
> region. Such transferred number resources may only be 
> received by organizations that are within the ARIN region and 
> can demonstrate the need for such resources in the exact 
> amount which they can justify under current ARIN policies.
> 
> #####
> 
> Notes:
> 
> Most of the existing Section 8 is left unchanged. List of changes:
> 
> 2.8 New.
> 8.1 Changes from "Transfers" to "Principles."
> 8.2 Changes from "Transfer Requirements" to "Mergers and 
> Acquisitions."
> 8.2 The word "only" is removed.
> 8.3 Merged up into 8.2.
> 8.3 Edited version of the adopted 2008-6.
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 
> 



From stephen at sprunk.org  Tue Mar 24 16:18:46 2009
From: stephen at sprunk.org (Stephen Sprunk)
Date: Tue, 24 Mar 2009 15:18:46 -0500
Subject: [arin-ppml] Draft Policy 2008-7: Identify Invalid WHOIS POC's
In-Reply-To: <3E32C91B19244A0D977F953C8BD36871@tedsdesk>
References: <1f08e8ae3c9c4f4bb0e002f1a1a40c20@mail.dessus.com><62630D01-343C-4E9D-AA83-E6A9ED8478F4@delong.com>	<49C8C942.80601@dilkie.com>
	<3E32C91B19244A0D977F953C8BD36871@tedsdesk>
Message-ID: <49C94026.3090203@sprunk.org>

Ted Mittelstaedt wrote:
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net 
>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Lee Dilkie
>> Sent: Tuesday, March 24, 2009 4:52 AM
>> To: Owen DeLong
>> Cc: arin-ppml at arin.net
>> Subject: Re: [arin-ppml] Draft Policy 2008-7: Identify 
>> Invalid WHOIS POC's
>>
>>     
>> ...
>> Since the policy specified "email" and that is only one of 
>> many contact methods, perhaps the policy shouldn't be so 
>> specific either and simply leave the details of "contacting 
>> the record holder" to staff.
>>     
> ...
> Don't you think it's a bit odd that your proposing ON AN E-MAIL MAILING LIST that we countenence removal of the requirement for valid E-MAIL addresses in POC entries?  Using your own, publically reachable, personal e-mail address to do so?  You obviously have no problem with making your own e-mail address public - so why would you think that any reasons put forth by a POC for not having a valid e-mail address published in WHOIS are anything other than bogus nonsense?
>   

IMHO, that is a gross misrepresentation of what Lee said.  I agree, as I 
believe Lee does, that all POC records should have valid email 
addresses.  I simply don't agree that policy should specify operational 
details that ARIN staff are in a better position to decide based on 
their experience (which may vary over time).  If they need more 
clarification on what we want or how we want it done, they will ask us; 
absent that, we should give them pure policy and let them figure out how 
best to implement it.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3241 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090324/1a1026f4/attachment.bin>

From matthew at matthew.at  Tue Mar 24 15:54:59 2009
From: matthew at matthew.at (Matthew Kaufman)
Date: Tue, 24 Mar 2009 12:54:59 -0700
Subject: [arin-ppml] Draft Policy 2009-4: IPv4 Recovery Fund
In-Reply-To: <20090324192122.GA57501@ussenterprise.ufp.org>
References: <49C7DD9A.6030907@arin.net>	<4E2F5C1D7DE44750A55F396303A96846@tedsdesk>
	<20090324192122.GA57501@ussenterprise.ufp.org>
Message-ID: <49C93A93.6010708@matthew.at>

Leo Bicknell wrote:
>
> While this proposal does not have a "sunset clause" it was designed
> to automatically sunset.
>
> Under this policy it is perfectly acceptable for folks to bid $0 (they
> only want IPv4 resources if they are voluntarily returned to ARIN), or
> not to bid at all (they don't want resources until we can return to
> normal allocations).
>
> ARIN staff will only be paying for the return of address space while
> there are non-zero bids.
>
>   
Why don't we combine 2009-4 and 2009-2? ARIN could just use its 
remaining stock of address space and sell it to the highest bidder via 
the policy in 2009-4.

Clearly as the numbers run out, the prices will get higher and higher 
and since "the highest bidder" is going to be who gets IPv4 space 
*after* the runout, we could all get experience now with who does and 
doesn't end up with space with that as the allocation policy.

I'm sure ARIN could find something creative to do with the excess funds 
that might be generated.

Matthew Kaufman




From tedm at ipinc.net  Tue Mar 24 16:23:25 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 24 Mar 2009 13:23:25 -0700
Subject: [arin-ppml] Draft Policy 2008-7: Identify Invalid WHOIS POC's
In-Reply-To: <49C94026.3090203@sprunk.org>
References: <1f08e8ae3c9c4f4bb0e002f1a1a40c20@mail.dessus.com><62630D01-343C-4E9D-AA83-E6A9ED8478F4@delong.com>	<49C8C942.80601@dilkie.com>
	<3E32C91B19244A0D977F953C8BD36871@tedsdesk>
	<49C94026.3090203@sprunk.org>
Message-ID: <51DF79F575B84402A4F04FA1A527E354@tedsdesk>

 

> -----Original Message-----
> From: Stephen Sprunk [mailto:stephen at sprunk.org] 
> Sent: Tuesday, March 24, 2009 1:19 PM
> To: Ted Mittelstaedt
> Cc: 'Lee Dilkie'; ARIN PPML
> Subject: Re: [arin-ppml] Draft Policy 2008-7: Identify 
> Invalid WHOIS POC's
> 
> Ted Mittelstaedt wrote:
> >> -----Original Message-----
> >> From: arin-ppml-bounces at arin.net
> >> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Lee Dilkie
> >> Sent: Tuesday, March 24, 2009 4:52 AM
> >> To: Owen DeLong
> >> Cc: arin-ppml at arin.net
> >> Subject: Re: [arin-ppml] Draft Policy 2008-7: Identify 
> Invalid WHOIS 
> >> POC's
> >>
> >>     
> >> ...
> >> Since the policy specified "email" and that is only one of many 
> >> contact methods, perhaps the policy shouldn't be so 
> specific either 
> >> and simply leave the details of "contacting the record holder" to 
> >> staff.
> >>     
> > ...
> > Don't you think it's a bit odd that your proposing ON AN 
> E-MAIL MAILING LIST that we countenence removal of the 
> requirement for valid E-MAIL addresses in POC entries?  Using 
> your own, publically reachable, personal e-mail address to do 
> so?  You obviously have no problem with making your own 
> e-mail address public - so why would you think that any 
> reasons put forth by a POC for not having a valid e-mail 
> address published in WHOIS are anything other than bogus nonsense?
> >   
> 
> IMHO, that is a gross misrepresentation of what Lee said.  I 
> agree, as I believe Lee does, that all POC records should 
> have valid email addresses.

OK then, would you be willing to support a policy proposal that
ONLY stated all POC's must have valid e-mail addresses?  Nothing else
about validation or any of that?  Just a simple statement that
all POCs in the whois database must have valid e-mail addresses?

Ted



From tedm at ipinc.net  Tue Mar 24 16:26:05 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 24 Mar 2009 13:26:05 -0700
Subject: [arin-ppml] Draft Policy 2009-4: IPv4 Recovery Fund
In-Reply-To: <49C93A93.6010708@matthew.at>
References: <49C7DD9A.6030907@arin.net>	<4E2F5C1D7DE44750A55F396303A96846@tedsdesk><20090324192122.GA57501@ussenterprise.ufp.org>
	<49C93A93.6010708@matthew.at>
Message-ID: <2C5C3A6164454F8DA03034C3DB95D515@tedsdesk>

 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Matthew Kaufman
> Sent: Tuesday, March 24, 2009 12:55 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy 2009-4: IPv4 Recovery Fund
> 
> Leo Bicknell wrote:
> >
> > While this proposal does not have a "sunset clause" it was 
> designed to 
> > automatically sunset.
> >
> > Under this policy it is perfectly acceptable for folks to 
> bid $0 (they 
> > only want IPv4 resources if they are voluntarily returned 
> to ARIN), or 
> > not to bid at all (they don't want resources until we can return to 
> > normal allocations).
> >
> > ARIN staff will only be paying for the return of address 
> space while 
> > there are non-zero bids.
> >
> >   
> Why don't we combine 2009-4 and 2009-2? ARIN could just use 
> its remaining stock of address space and sell it to the 
> highest bidder via the policy in 2009-4.
> 
> Clearly as the numbers run out, the prices will get higher 
> and higher and since "the highest bidder" is going to be who 
> gets IPv4 space
> *after* the runout, we could all get experience now with who 
> does and doesn't end up with space with that as the allocation policy.
> 

Why don't we simply declare open season all remining unassigned IPv4 space.
Anyone who wants to use it, can do so.  No entries will be made in whois
for it, it will just be wide open.  Whoever had the most money and can
force the most networks on the Internet to accept their advertisements
for it, over anyone else's advertisements for it, wins.

Ted



From rlc at usfamily.net  Tue Mar 24 16:30:06 2009
From: rlc at usfamily.net (Ron Cleven)
Date: Tue, 24 Mar 2009 15:30:06 -0500 (CDT)
Subject: [arin-ppml] Draft Policy 2009-2: Depleted IPv4 reserves
In-Reply-To: <89D27DE3375BB6428DDCC2927489826A02223F9E@nexus.nexicomgroup.net>
References: <49C7DD7B.5000901@arin.net><DE229826F48ABD4CBF754E5AA6CFC14B1DDA22280E@WP40044.corp.ads><49C9104E.3040105@sprunk.org>	<49C9241D.6050601@usfamily.net><DE229826F48ABD4CBF754E5AA6CFC14B1DDA222B10@WP40044.corp.ads><49C92D3C.2010509@usfamily.net>	<DE229826F48ABD4CBF754E5AA6CFC14B1DDA222B77@WP40044.corp.ads>
	<89D27DE3375BB6428DDCC2927489826A02223F9E@nexus.nexicomgroup.net>
Message-ID: <49C942CC.9010009@usfamily.net>

Paul,

Thank you.  Your response seems entirely reasonable.  Any large ISP 
would, of course, focus on the logistics of transitioning their 
residential customers first (cuz that is where nearly all of their IP 
addresses are), to reach a point where new customers would be IPv6, then 
gradually migrate older customers to IPv6, using whatever scheme works 
best for them.  Once this is done, as you say, the pressure is off, 
because there would be no need for new IPv4 allocations.

Hence, I can only conclude that TELUS has yet to figure out how to 
accommodate their residential customers in the context of IPv6 yet. 
Otherwise, they would have no need for any new IPv4 allocations, and 
Matthew would have no reason to protest.

I am sorry to pick on Matthew, because I probably agree with him on his 
ultimate point.  However, what this all leads to, of course, is whether 
or not ANY large ISP's have begun large-scale roll-out of new broadband 
(cable/DSL) residential customers in such a fashion that those new 
customers are forced to use IPv6?

If that has started happening, have the technical details of the "model" 
been widely published or are they a closely guarded secret?  If it HAS 
started happening, then the depletion of IPv4 should be a moot point.

If it has not started happening, is it because the large ISP's have not 
figured out how to make it work "cleanly" yet, because that is the only 
reason I can imagine?

I understand my comments might sound naive, but if no such "clean" 
transitional model exists, then we's in a world of hurt.

Ron



Paul Stewart wrote:

> While we are not large by any stretch, we do have *well* over 100
> network elements - our core and distribution are all dual stack today.
> Our plan is that any new customer deployments (starting middle of this
> year) would involve dual stack to the customer premise.  Then we would
> work our way back within a year of starting to run dual-stack at all
> existing locations.
> 
> By putting it into our workflow of a standard deployment and then
> focusing efforts on converting existing elements to dual stack, we feel
> we can easily do this within a year.
> 
> With dual stack everywhere, then the "pressure is off" from our
> perspective to avoid any sudden panic situations...
> 
> Just my two cents worth...
> 
> Paul
> 
> 
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Matthew Wilder
> Sent: Tuesday, March 24, 2009 3:42 PM
> To: Ron Cleven; ARIN PPML
> Subject: Re: [arin-ppml] Draft Policy 2009-2: Depleted IPv4 reserves
> 
> Hi Ron,
> 
> I will give you the benefit of the doubt here.  In case there was the
> slightest ambiguity with my comments, I will clarify my statements.
> 
> I did not at any point say that TELUS would be unable to transition to
> IPv6, so hold back your shock for a moment.  I suggested that TELUS
> might be unable to transition certain services to IPv6 before IPv4
> exhaust.  At large organizations, there are too many inter-dependencies
> to make everything happen at once.  And I doubt there is an organization
> out there with more than 100 network elements who plans to switch off
> IPv4 before IPv4 address exhaust.  I hope that doesn't trouble you too
> much.
> 
> Cheers,
> Matthew
> 
> 
> 
> Ron Cleven wrote:
> 
> 
>>I have read over and over and over in this list that IPv6 is "the
> 
> solution" to all the IPv4 depletion problems.  I have also seen tons of
> posts that explicitly or implicitly assert that only irresponsible ISP's
> will not be ready to go with IPv6 by the time IPv4 runs out.  After all,
> we have all known this day has been coming for the last decade.  Yet,
> you seem to saying that your large ISP who should be a leader in this
> movement will be unable to make the transition in time.  I'm shocked!
> 
> 
>>Are there any other large ISP's monitoring this list who are the least
> 
> bit concerned about the transition, or is Telus the only one who can't
> seem to figure this out?  Perhaps one of the large ISP's who has
> everything all figured out could share all their technical information
> to put Telus' mind to rest?
> 
> Matthew Wilder wrote:
> 
> 
>>Ron wrote:
>>
>>
>>>Stephen's comments are spot on.  The large ISP's are the very ones who
> 
> 
>>>have both the resources and clout to make the IPv6 transition happen.
>>>If they are unwilling or unable to do so, what does that say about the
> 
> 
>>>viability of ever making that transition?  Mr. Wilder doth protest too
> 
> 
>>>much.
>>
>>
>>My explicit role in my organization is to ensure adequate IP
> 
> Addressing to support service growth and new service introduction.  I
> believe without a doubt that the only way I will be successful in that
> mandate is to position IPv6 as the vehicle so that the IP Addresses are
> there.  
> 
>>My organization is taking the steps necessary to get that transition
> 
> happening, so we are not unwilling.  I can tell you that with certain
> services, we might well be unable to transition before IPv4 exhaust
> hits, but my focus is to transition the high growth services.  I want to
> make sure that the other services which may take longer to transition
> have the IP Addresses available, as I am sure every other admin POC out
> there is trying to ensure.
> 
>>I don't protest for the sake of demanding unfair privileges on the
> 
> behalf of large ISPs.  I protest a policy that says everyone can have
> their needs completely met except for one group, which can't even have a
> reasonable fraction of their need met.
> 
>>Respectfully,
>>Matthew Wilder
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 



From stephen at sprunk.org  Tue Mar 24 16:32:43 2009
From: stephen at sprunk.org (Stephen Sprunk)
Date: Tue, 24 Mar 2009 15:32:43 -0500
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy
 (Using	theEmergency PDP)
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AF06@mail>
References: <49C911A8.5020009@arin.net>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4AF06@mail>
Message-ID: <49C9436B.2010907@sprunk.org>

Kevin Kargel wrote:
> 2008-6 met with great resistance when it was presented in the past.  While
> the text of 2008-6 says it's intent is not to create a market that is
> exactly what it does.  
>
> I continue to stand firm against p2p transfer policies and I find the boards use of emergency powers to implement such a policy against or in spite of the wishes of the community abusive.
>   

I understand you're against paid transfers, but I think that the AC 
properly concluded that there was community consensus to do _something_, 
and 2008-6 was the best (or least-bad, if you prefer) option available.

Consensus does not mean that you (or anyone else) is going to get what 
you want every time.

> I do not think there is much I can do other than whine, and this does show to me the futility of trying to be active and part of the process.  I guess that money wins out and people will do whatever it takes to create the artificial IP address market.
>   

Participation is not futile, even when you lose.  I also disagree with 
your baseless (and easily refuted) accusation that the proponents of an 
address market are motivated by personal financial gain, but we've been 
through that before...

> This leaves me quite disheartened and with a much less confidence in ARIN
> administration.  
>   

I'm not thrilled with the (lack of) transparency demonstrated to date 
with this action, either.  I still haven't puzzled out exactly what the 
BoT _did_, much less why or whether I (dis)agree with it -- and that's a 
serious problem.

This situation is not, IMHO, what the emergency policy powers were 
intended for; if there were some fatal flaw in 2008-6 that prevented the 
BoT from adopting it, they _should_ have sent it back to the AC and made 
it an agenda item for the upcoming public policy meeting.  It'd be a 
different matter if the policy were adopted and some fatal flaw were 
discovered after implementation, and the ideal action there would be to 
suspend the policy until the flaw could be corrected via the normal PDP...

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3241 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090324/49412aad/attachment.bin>

From kkargel at polartel.com  Tue Mar 24 16:33:18 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 24 Mar 2009 15:33:18 -0500
Subject: [arin-ppml] Draft Policy 2009-4: IPv4 Recovery Fund
In-Reply-To: <2C5C3A6164454F8DA03034C3DB95D515@tedsdesk>
References: <49C7DD9A.6030907@arin.net>	<4E2F5C1D7DE44750A55F396303A96846@tedsdesk><20090324192122.GA57501@ussenterprise.ufp.org><49C93A93.6010708@matthew.at>
	<2C5C3A6164454F8DA03034C3DB95D515@tedsdesk>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AF08@mail>


> Why don't we simply declare open season all remining unassigned IPv4
> space.
> Anyone who wants to use it, can do so.  No entries will be made in whois
> for it, it will just be wide open.  Whoever had the most money and can
> force the most networks on the Internet to accept their advertisements
> for it, over anyone else's advertisements for it, wins.
> 
> Ted
> 
> _______________________________________________

Yes, or we could just all meet at a common arena with our biggest geeks, and
they could rush in with their favorite weapons and fight for the stack of IP
certificates in the center of the arena.  

This is exactly what a p2p transfer policy does except that it uses dollars
and lawyers as the weapons.  Whoever can offer the biggest bribes gets the
goods.  Anyone who is not comfortable going to-to-toe with the big ISP's
budgets should be afraid, they should be very afraid.

Kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090324/d916b95d/attachment.bin>

From stephen at sprunk.org  Tue Mar 24 16:36:37 2009
From: stephen at sprunk.org (Stephen Sprunk)
Date: Tue, 24 Mar 2009 15:36:37 -0500
Subject: [arin-ppml] Draft Policy 2008-7: Identify Invalid WHOIS POC's
In-Reply-To: <51DF79F575B84402A4F04FA1A527E354@tedsdesk>
References: <1f08e8ae3c9c4f4bb0e002f1a1a40c20@mail.dessus.com><62630D01-343C-4E9D-AA83-E6A9ED8478F4@delong.com>	<49C8C942.80601@dilkie.com>
	<3E32C91B19244A0D977F953C8BD36871@tedsdesk>
	<49C94026.3090203@sprunk.org>
	<51DF79F575B84402A4F04FA1A527E354@tedsdesk>
Message-ID: <49C94455.8070802@sprunk.org>

Ted Mittelstaedt wrote:
>> -----Original Message-----
>> From: Stephen Sprunk [mailto:stephen at sprunk.org] 
>> Sent: Tuesday, March 24, 2009 1:19 PM
>> To: Ted Mittelstaedt
>> Cc: 'Lee Dilkie'; ARIN PPML
>> Subject: Re: [arin-ppml] Draft Policy 2008-7: Identify 
>> Invalid WHOIS POC's
>>     
>> ... I agree, as I believe Lee does, that all POC records should 
>> have valid email addresses.
>>     
>
> OK then, would you be willing to support a policy proposal that ONLY stated all POC's must have valid e-mail addresses?  Nothing else about validation or any of that?  Just a simple statement that all POCs in the whois database must have valid e-mail addresses?
>   

No.  Without validation and enforcement, the policy would be useless and 
just clutter the NRPM.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3241 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090324/779aa455/attachment.bin>

From matthew at matthew.at  Tue Mar 24 16:37:02 2009
From: matthew at matthew.at (Matthew Kaufman)
Date: Tue, 24 Mar 2009 13:37:02 -0700
Subject: [arin-ppml] Draft Policy 2009-4: IPv4 Recovery Fund
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AF08@mail>
References: <49C7DD9A.6030907@arin.net>	<4E2F5C1D7DE44750A55F396303A96846@tedsdesk><20090324192122.GA57501@ussenterprise.ufp.org><49C93A93.6010708@matthew.at>	<2C5C3A6164454F8DA03034C3DB95D515@tedsdesk>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4AF08@mail>
Message-ID: <49C9446E.3080700@matthew.at>

Kevin Kargel wrote:
> This is exactly what a p2p transfer policy does except that it uses dollars
> and lawyers as the weapons.  
This is also true *without* a p2p transfer policy. Large ISPs will 
acquire small ISPs and other corporate entities or their spun-off 
subsidiaries in order to use the exsting transfer policies to achieve 
exactly the same, only the lawyers get slightly more rich due to the 
added complexity.

Matthew Kaufman


From tedm at ipinc.net  Tue Mar 24 16:38:26 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 24 Mar 2009 13:38:26 -0700
Subject: [arin-ppml] Draft Policy 2009-4: IPv4 Recovery Fund
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AF08@mail>
References: <49C7DD9A.6030907@arin.net>	<4E2F5C1D7DE44750A55F396303A96846@tedsdesk><20090324192122.GA57501@ussenterprise.ufp.org><49C93A93.6010708@matthew.at><2C5C3A6164454F8DA03034C3DB95D515@tedsdesk>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4AF08@mail>
Message-ID: <2D9ADAB95E12433BADC6ED9AE7A8E043@tedsdesk>

 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel
> Sent: Tuesday, March 24, 2009 1:33 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy 2009-4: IPv4 Recovery Fund
> 
> 
> > Why don't we simply declare open season all remining 
> unassigned IPv4 
> > space.
> > Anyone who wants to use it, can do so.  No entries will be made in 
> > whois for it, it will just be wide open.  Whoever had the 
> most money 
> > and can force the most networks on the Internet to accept their 
> > advertisements for it, over anyone else's advertisements 
> for it, wins.
> > 
> > Ted
> > 
> > _______________________________________________
> 
> Yes, or we could just all meet at a common arena with our 
> biggest geeks, and they could rush in with their favorite 
> weapons and fight for the stack of IP certificates in the 
> center of the arena.  
> 

I'm game as long as Brooke Richards was holding the certs. ;-)

Ted



From Matthew.Wilder at telus.com  Tue Mar 24 16:42:00 2009
From: Matthew.Wilder at telus.com (Matthew Wilder)
Date: Tue, 24 Mar 2009 14:42:00 -0600
Subject: [arin-ppml] Draft Policy 2009-2: Depleted IPv4 reserves
In-Reply-To: <49C942CC.9010009@usfamily.net>
References: <49C7DD7B.5000901@arin.net><DE229826F48ABD4CBF754E5AA6CFC14B1DDA22280E@WP40044.corp.ads><49C9104E.3040105@sprunk.org>
	<49C9241D.6050601@usfamily.net><DE229826F48ABD4CBF754E5AA6CFC14B1DDA222B10@WP40044.corp.ads><49C92D3C.2010509@usfamily.net>
	<DE229826F48ABD4CBF754E5AA6CFC14B1DDA222B77@WP40044.corp.ads>
	<89D27DE3375BB6428DDCC2927489826A02223F9E@nexus.nexicomgroup.net>
	<49C942CC.9010009@usfamily.net>
Message-ID: <DE229826F48ABD4CBF754E5AA6CFC14B1DDA222BD9@WP40044.corp.ads>

So to summarize, the large ISPs should take one for the team and force their customers onto a network standard that would cut them off from the majority of content they are interested in, incurring massive cost while doing so, and then every other ISP out there doesn't have to worry about IPv4 exhaust because it won't even happen.  When you put it that way, I will bring the business case to my superiors and get approval right away!

MW

Ron Cleven wrote:
> Paul,

> Thank you.  Your response seems entirely reasonable.  Any large ISP would, of course, focus on the logistics of transitioning their residential customers first (cuz that is where nearly all of their IP addresses are), to reach a point where new customers would be IPv6, then gradually migrate older customers to IPv6, using whatever scheme works best for them.  Once this is done, as you say, the pressure is off, because there would be no need for new IPv4 allocations.

> Hence, I can only conclude that TELUS has yet to figure out how to accommodate their residential customers in the context of IPv6 yet. 
Otherwise, they would have no need for any new IPv4 allocations, and Matthew would have no reason to protest.

> I am sorry to pick on Matthew, because I probably agree with him on his ultimate point.  However, what this all leads to, of course, is whether or not ANY large ISP's have begun large-scale roll-out of new broadband
(cable/DSL) residential customers in such a fashion that those new customers are forced to use IPv6?

> If that has started happening, have the technical details of the "model" 
been widely published or are they a closely guarded secret?  If it HAS started happening, then the depletion of IPv4 should be a moot point.

> If it has not started happening, is it because the large ISP's have not figured out how to make it work "cleanly" yet, because that is the only reason I can imagine?

> I understand my comments might sound naive, but if no such "clean" 
transitional model exists, then we's in a world of hurt.

> Ron

From farmer at umn.edu  Tue Mar 24 16:46:55 2009
From: farmer at umn.edu (David Farmer)
Date: Tue, 24 Mar 2009 15:46:55 -0500
Subject: [arin-ppml] Draft Policy 2009-2: Depleted IPv4 reserves
In-Reply-To: <DE229826F48ABD4CBF754E5AA6CFC14B1DDA2229A5@WP40044.corp.ads>
References: <49C7DD7B.5000901@arin.net>,
	<4D639F66-9B64-4FF0-BC3A-B8B64430402A@delong.com>,
	<DE229826F48ABD4CBF754E5AA6CFC14B1DDA2229A5@WP40044.corp.ads>
Message-ID: <49C9006F.22095.14235745@farmer.umn.edu>

On 24 Mar 2009 Matthew Wilder wrote:

> Hi Owen,
> 
> I agree that there should be some amount of rationing of IP Addresses
> in the IPv4 endgame.  I simply question the fairness of a policy that
> says everyone can have what they need in IPv4 addresses except those
> who need more than a /20 every 6 months.
> 
> Fairness itself is a loaded word in these discussions.  To me,
> fairness in this case fundamentally implies equal access to IPv4
> addresses.  The question then becomes the definition of equal access. 
> Is that access to an equal amount of space per organization?  Though
> that sounds good, that answer ignores the philosophy of needs-based
> allocations.  And what about equal amount of space per EU organization
> represented by an ISP?  

You are right, much like art, fairness is in the eyes of the beholder.  But like 
another famous quote about art, I think we know fairness when we see it.  
There is another measurement of fairness, when everyone is unhappy 
maybe you are there (at fairness).

> That would imply that the large ISPs should
> still have access to the majority of IP Addresses, since they
> represent the vast majority of internet users in North America.

I'm with Mr. Sprunk on this one the bigger you are the more effect you can 
have on IPv6 adoption. But, there isn't only an fairness issue between big 
and small, if we don't do something one big ISP could get the last bit of IP 
space and leave none for the other big ISPs too. 

> The starting point for this policy has to be some kind of target
> objective.  If the objective of the policy is to make the last /9 of
> space last around one year before depletion, without consideration of
> consistent limitation to vastly different organizations, I think this
> policy fits the bill.

I don't think we have an exact target, but that is the general idea, make what 
is left last some amount of time, a year plus or minus a few months seems 
about right, but I don't have a specific.  We would also like to avoid a run on 
the bank so to speak.    Another way to describe this is make sure everyone 
can get some of the crumbs at the bottom of the bag of the potato chips.  
The only truly fair way is to get the next bag of potato chips off the shelf (you 
could think of that as IPv6), but short of doing that how should we dole-out 
the crumbs.

> I think there is a way of making the last /9 last for a year without
> unequally affecting different organizations.  I think the way to
> implement such a policy more fairly is to limit allocations to a
> certain percentage of space an organization already has allocated to
> it.  Thus, each organization can have equal geometric growth to their
> IPv4 address space, and thus everyone has the same limitations placed
> on them.  I don't know the numbers that would accomplish a goal of 1
> year spreadout of the last /9, but I would bet it is in the 5-10%
> ballpark.  Note that this kind of policy would prevent a run on ARIN
> by smaller ISPs and EUs that can request a /20 which might double
> their IPv4 address space.

Personally I'd like to do something like what you are talking about, but I think 
it is to hard.  Maybe the important thing is to make sure everyone to feels 
some of pain.  But, given the realities of base 2 mathematics and the other 
constraints we have to work with it is impossible to have everyone feel the 
pain equally.  The big guys will always have more pain, they have further to 
fall.  Remember, "the bigger they are, the harder they fall."

I propose the following tiered methodology, based on your justified need 
under current process and procedures, you would get the following;

Justified Need, what you get
/11 or greater, you get a /20
/12 to /14, you get a /21
/15 to /17, you get a /22
/18 to /20, you get a /23
/21 or smaller, you get a /24

While not as concise and elegant as the current policy, it is reasonably 
understandable and shares the pain down to the smaller guys too.

Note: Currently, the minimum allocation for all End Users and ISP in the US 
and Canada is /20, Caribbean and North Atlantic Islands sector ISPs only is 
/22, and Micro-allocations are /24.  So, only Micro-allocations at /24 actually 
get 100% of their need meet and that is probably OK, they are suppose to be 
"critical" after all.

See the following Google Doc Spread Sheet and charts, I had to generate 
the charts with Excel, and provide them as JPEGs because I couldn't  figure 
out how to get Google Docs to do log graphs.

Spread Sheet
http://spreadsheets.google.com/pub?key=pMNgPs6H0qPUlVFsG30_Zfw

Chart1
http://docs.google.com/Doc?id=dg794v8b_2gs5v3hcg

Chart2
http://docs.google.com/Doc?id=dg794v8b_0dc7k2xgc

The draw backs are;
1. More complicated than the proposed policy
2. Allocating blocks smaller than /20 or /22, but that can probably be 
contained to the last /9 or so.
3. More small blocks causing route table growth, but this is probably self 
limiting anyway.
4. The other RIR are basically doing much the same as the current policy 
proposal, so in some ways this tiered approach maybe more fair, but maybe 
not if you compare the ARIN region to other regions.

> I look forward to hearing your thoughts on these ideas!

What do you think?

> Cheers,
> Matthew

Personally, I'm ok with this either way, if people can get over the slight 
unfairness of /20 it is way simpler and is way all the other RIR seem to be 
going too.  That doesn't make it right, but it does cut down on the regional 
differences.  Which is why I backed down in the AC discussions on this 
issue.

And, either way we are going to be out of IPv4 addresses long before most 
people are ready for IPv6, I hope I'm wrong on this one, but!


=======================================================
David Farmer				     Email:	farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota			     Phone:	612-626-0815
2218 University Ave SE			     Cell:		612-812-9952
Minneapolis, MN 55414-3029		     FAX:	612-626-1818
=======================================================



From bicknell at ufp.org  Tue Mar 24 16:49:13 2009
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 24 Mar 2009 15:49:13 -0500
Subject: [arin-ppml] Draft Policy 2009-4: IPv4 Recovery Fund
In-Reply-To: <49C93A93.6010708@matthew.at>
References: <49C7DD9A.6030907@arin.net>
	<4E2F5C1D7DE44750A55F396303A96846@tedsdesk>
	<20090324192122.GA57501@ussenterprise.ufp.org>
	<49C93A93.6010708@matthew.at>
Message-ID: <20090324204913.GA61768@ussenterprise.ufp.org>

In a message written on Tue, Mar 24, 2009 at 12:54:59PM -0700, Matthew Kaufman wrote:
> Why don't we combine 2009-4 and 2009-2? ARIN could just use its 
> remaining stock of address space and sell it to the highest bidder via 
> the policy in 2009-4.

I'm not sure I'm going to come at this from the same direction you
were thinking, but you raise an interesting point.

Dan (original author of 2009-2) and I share one concern.  We don't
want someone large to make a request right at the end and have it
filled by ARIN with all of the drips and dregs left around.  It's
not hard to imagine someone asking for a /12 at the right (wrong?)
time and having ARIN try to fill it with 2 /16's, 14 /17's, 9 /20's,
241 /21's, ....

The obvious bad effect, deaggregation, isn't the real problem.
That's going to happen if many smaller companies get the space.
The real problem is that it causes everyone to hit the wall at the
same instant.  With that one large request ARIN is out, period game
over.  While we can't make the landing really soft, it seems like
having some small amount of spread biased towards the smallest
players with the least buffer makes sense.  "Please save the
children", if you will.

Dan attempted to take this problem on directly in 2009-2 by limiting
requests once we fell below some minimum.  I attempted to take it
on indirectly by implementing the recovery of space as specific
size prefixes run out.  If you ask for a /12 and ARIN has no more
you must start to bid, even if ARIN still has a lot of smaller
blocks out there (which would be given out normally until they are
gone).

In any event, they aren't really compatable (doing both as-is doesn't
make a ton of sense), but they aren't really incompatable (as they share
many of the same motivations, I think).  If the community likes both
concepts I think we would have to hammer out a compromise that made
sense but I stand ready to do that and I think Dan does too if it is
what people want.

> Clearly as the numbers run out, the prices will get higher and higher 
> and since "the highest bidder" is going to be who gets IPv4 space 
> *after* the runout, we could all get experience now with who does and 
> doesn't end up with space with that as the allocation policy.
> 
> I'm sure ARIN could find something creative to do with the excess funds 
> that might be generated.

My reading of the room is there is a relatively strong sentiment against
ARIN generating "windfall profits" off the exhaustion, and thus I'm
tempted to say your idea is a non-starter.  That said, there have been
several folks express concern over the amount of cash ARIN may have to
tie up in the 2009-4 program.  I think it's a fairly small amount of
money and risk, but perhaps there would be support to start 2009-4 with
a /small/ amount of reserve left such that a buffer can be created.
It's not something I had considered before and I wouldn't add it unless
there was strong support, but it is an idea.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090324/fe5eda04/attachment.sig>

From rlc at usfamily.net  Tue Mar 24 16:51:46 2009
From: rlc at usfamily.net (Ron Cleven)
Date: Tue, 24 Mar 2009 15:51:46 -0500 (CDT)
Subject: [arin-ppml] Draft Policy 2009-2: Depleted IPv4 reserves
In-Reply-To: <DE229826F48ABD4CBF754E5AA6CFC14B1DDA222BD9@WP40044.corp.ads>
References: <49C7DD7B.5000901@arin.net><DE229826F48ABD4CBF754E5AA6CFC14B1DDA22280E@WP40044.corp.ads><49C9104E.3040105@sprunk.org>	<49C9241D.6050601@usfamily.net><DE229826F48ABD4CBF754E5AA6CFC14B1DDA222B10@WP40044.corp.ads><49C92D3C.2010509@usfamily.net>	<DE229826F48ABD4CBF754E5AA6CFC14B1DDA222B77@WP40044.corp.ads>	<89D27DE3375BB6428DDCC2927489826A02223F9E@nexus.nexicomgroup.net>	<49C942CC.9010009@usfamily.net>
	<DE229826F48ABD4CBF754E5AA6CFC14B1DDA222BD9@WP40044.corp.ads>
Message-ID: <49C947E0.90708@usfamily.net>

So, there is no way for a PC operating over IPv6 to access an IPv4 web 
site or mail server or ...

Hmmmmm, sounds like a problem.  Maybe some really bright people out 
there can figure out a way to make that happen?



Matthew Wilder wrote:
> So to summarize, the large ISPs should take one for the team and force their customers onto a network standard that would cut them off from the majority of content they are interested in, incurring massive cost while doing so, and then every other ISP out there doesn't have to worry about IPv4 exhaust because it won't even happen.  When you put it that way, I will bring the business case to my superiors and get approval right away!
> 
> MW
> 
> Ron Cleven wrote:
> 
>>Paul,
> 
> 
>>Thank you.  Your response seems entirely reasonable.  Any large ISP would, of course, focus on the logistics of transitioning their residential customers first (cuz that is where nearly all of their IP addresses are), to reach a point where new customers would be IPv6, then gradually migrate older customers to IPv6, using whatever scheme works best for them.  Once this is done, as you say, the pressure is off, because there would be no need for new IPv4 allocations.
> 
> 
>>Hence, I can only conclude that TELUS has yet to figure out how to accommodate their residential customers in the context of IPv6 yet. 
> 
> Otherwise, they would have no need for any new IPv4 allocations, and Matthew would have no reason to protest.
> 
> 
>>I am sorry to pick on Matthew, because I probably agree with him on his ultimate point.  However, what this all leads to, of course, is whether or not ANY large ISP's have begun large-scale roll-out of new broadband
> 
> (cable/DSL) residential customers in such a fashion that those new customers are forced to use IPv6?
> 
> 
>>If that has started happening, have the technical details of the "model" 
> 
> been widely published or are they a closely guarded secret?  If it HAS started happening, then the depletion of IPv4 should be a moot point.
> 
> 
>>If it has not started happening, is it because the large ISP's have not figured out how to make it work "cleanly" yet, because that is the only reason I can imagine?
> 
> 
>>I understand my comments might sound naive, but if no such "clean" 
> 
> transitional model exists, then we's in a world of hurt.
> 
> 
>>Ron
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 



From Matthew.Wilder at telus.com  Tue Mar 24 17:21:48 2009
From: Matthew.Wilder at telus.com (Matthew Wilder)
Date: Tue, 24 Mar 2009 15:21:48 -0600
Subject: [arin-ppml] Draft Policy 2009-2: Depleted IPv4 reserves
In-Reply-To: <49C9006F.22095.14235745@farmer.umn.edu>
References: <49C7DD7B.5000901@arin.net>,
	<4D639F66-9B64-4FF0-BC3A-B8B64430402A@delong.com>,
	<DE229826F48ABD4CBF754E5AA6CFC14B1DDA2229A5@WP40044.corp.ads>
	<49C9006F.22095.14235745@farmer.umn.edu>
Message-ID: <DE229826F48ABD4CBF754E5AA6CFC14B1DDA222C12@WP40044.corp.ads>

Hi David,

Thank you for the comments.  I like them (since you asked).

I definitely appreciate the comments around the complexity of the policy.  It is much cleaner and easier to say that all allocations will be /20 or smaller.  It would also make it easier for staff to continue processing requests for the most part.  The other drivers make equal sense; routing table growth is contained, and we would remain consistent with other RIRs.

I know I am in the minority with my view (as someone pointed out the 1% minority).  I don't want to force the introduction of super-complex rules.  To frame my comments, I have calculated the time it would take for a /9 to be assigned without this policy.  At a rate of 20,000 /24 subnets per month (what we are seeing now) that is 80 /16's per month, or one /10 per month.  When I see this, I have to realize that a /9 will last at most 2 months under regular conditions, so the impact is a fairly narrow window with the proposal.

Based on this finding, I will support the policy as it reads, knowing that the fairness issue I see is simultaneously a significant benefit to the majority of other organizations.

Cheers,
Matthew
 

-----Original Message-----
From: David Farmer [mailto:farmer at umn.edu] 
Sent: Tuesday, March 24, 2009 1:47 PM
To: Matthew Wilder
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft Policy 2009-2: Depleted IPv4 reserves

On 24 Mar 2009 Matthew Wilder wrote:

> Hi Owen,
> 
> I agree that there should be some amount of rationing of IP Addresses 
> in the IPv4 endgame.  I simply question the fairness of a policy that 
> says everyone can have what they need in IPv4 addresses except those 
> who need more than a /20 every 6 months.
> 
> Fairness itself is a loaded word in these discussions.  To me, 
> fairness in this case fundamentally implies equal access to IPv4 
> addresses.  The question then becomes the definition of equal access.
> Is that access to an equal amount of space per organization?  Though 
> that sounds good, that answer ignores the philosophy of needs-based 
> allocations.  And what about equal amount of space per EU organization 
> represented by an ISP?

You are right, much like art, fairness is in the eyes of the beholder.  But like another famous quote about art, I think we know fairness when we see it.  
There is another measurement of fairness, when everyone is unhappy maybe you are there (at fairness).

> That would imply that the large ISPs should still have access to the 
> majority of IP Addresses, since they represent the vast majority of 
> internet users in North America.

I'm with Mr. Sprunk on this one the bigger you are the more effect you can have on IPv6 adoption. But, there isn't only an fairness issue between big and small, if we don't do something one big ISP could get the last bit of IP space and leave none for the other big ISPs too. 

> The starting point for this policy has to be some kind of target 
> objective.  If the objective of the policy is to make the last /9 of 
> space last around one year before depletion, without consideration of 
> consistent limitation to vastly different organizations, I think this 
> policy fits the bill.

I don't think we have an exact target, but that is the general idea, make what is left last some amount of time, a year plus or minus a few months seems about right, but I don't have a specific.  We would also like to avoid a run on 
the bank so to speak.    Another way to describe this is make sure everyone 
can get some of the crumbs at the bottom of the bag of the potato chips.  
The only truly fair way is to get the next bag of potato chips off the shelf (you could think of that as IPv6), but short of doing that how should we dole-out the crumbs.

> I think there is a way of making the last /9 last for a year without 
> unequally affecting different organizations.  I think the way to 
> implement such a policy more fairly is to limit allocations to a 
> certain percentage of space an organization already has allocated to 
> it.  Thus, each organization can have equal geometric growth to their
> IPv4 address space, and thus everyone has the same limitations placed 
> on them.  I don't know the numbers that would accomplish a goal of 1 
> year spreadout of the last /9, but I would bet it is in the 5-10% 
> ballpark.  Note that this kind of policy would prevent a run on ARIN 
> by smaller ISPs and EUs that can request a /20 which might double 
> their IPv4 address space.

Personally I'd like to do something like what you are talking about, but I think it is to hard.  Maybe the important thing is to make sure everyone to feels some of pain.  But, given the realities of base 2 mathematics and the other constraints we have to work with it is impossible to have everyone feel the pain equally.  The big guys will always have more pain, they have further to fall.  Remember, "the bigger they are, the harder they fall."

I propose the following tiered methodology, based on your justified need under current process and procedures, you would get the following;

Justified Need, what you get
/11 or greater, you get a /20
/12 to /14, you get a /21
/15 to /17, you get a /22
/18 to /20, you get a /23
/21 or smaller, you get a /24

While not as concise and elegant as the current policy, it is reasonably understandable and shares the pain down to the smaller guys too.

Note: Currently, the minimum allocation for all End Users and ISP in the US and Canada is /20, Caribbean and North Atlantic Islands sector ISPs only is /22, and Micro-allocations are /24.  So, only Micro-allocations at /24 actually get 100% of their need meet and that is probably OK, they are suppose to be "critical" after all.

See the following Google Doc Spread Sheet and charts, I had to generate the charts with Excel, and provide them as JPEGs because I couldn't  figure out how to get Google Docs to do log graphs.

Spread Sheet
http://spreadsheets.google.com/pub?key=pMNgPs6H0qPUlVFsG30_Zfw

Chart1
http://docs.google.com/Doc?id=dg794v8b_2gs5v3hcg

Chart2
http://docs.google.com/Doc?id=dg794v8b_0dc7k2xgc

The draw backs are;
1. More complicated than the proposed policy 2. Allocating blocks smaller than /20 or /22, but that can probably be contained to the last /9 or so.
3. More small blocks causing route table growth, but this is probably self limiting anyway.
4. The other RIR are basically doing much the same as the current policy proposal, so in some ways this tiered approach maybe more fair, but maybe not if you compare the ARIN region to other regions.

> I look forward to hearing your thoughts on these ideas!

What do you think?

> Cheers,
> Matthew

Personally, I'm ok with this either way, if people can get over the slight unfairness of /20 it is way simpler and is way all the other RIR seem to be going too.  That doesn't make it right, but it does cut down on the regional differences.  Which is why I backed down in the AC discussions on this issue.

And, either way we are going to be out of IPv4 addresses long before most people are ready for IPv6, I hope I'm wrong on this one, but!


=======================================================
David Farmer				     Email:	farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota			     Phone:	612-626-0815
2218 University Ave SE			     Cell:		612-812-9952
Minneapolis, MN 55414-3029		     FAX:	612-626-1818
=======================================================



From tedm at ipinc.net  Tue Mar 24 17:26:08 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 24 Mar 2009 14:26:08 -0700
Subject: [arin-ppml] Draft Policy 2008-7: Identify Invalid WHOIS POC's
In-Reply-To: <49C94455.8070802@sprunk.org>
References: <1f08e8ae3c9c4f4bb0e002f1a1a40c20@mail.dessus.com><62630D01-343C-4E9D-AA83-E6A9ED8478F4@delong.com>	<49C8C942.80601@dilkie.com>
	<3E32C91B19244A0D977F953C8BD36871@tedsdesk>
	<49C94026.3090203@sprunk.org>
	<51DF79F575B84402A4F04FA1A527E354@tedsdesk>
	<49C94455.8070802@sprunk.org>
Message-ID: <D83F25EF748E4025B26388C6BE56B0BD@tedsdesk>

 

> -----Original Message-----
> From: Stephen Sprunk [mailto:stephen at sprunk.org] 
> Sent: Tuesday, March 24, 2009 1:37 PM
> To: Ted Mittelstaedt
> Cc: 'ARIN PPML'
> Subject: Re: [arin-ppml] Draft Policy 2008-7: Identify 
> Invalid WHOIS POC's
> 
> Ted Mittelstaedt wrote:
> >> -----Original Message-----
> >> From: Stephen Sprunk [mailto:stephen at sprunk.org]
> >> Sent: Tuesday, March 24, 2009 1:19 PM
> >> To: Ted Mittelstaedt
> >> Cc: 'Lee Dilkie'; ARIN PPML
> >> Subject: Re: [arin-ppml] Draft Policy 2008-7: Identify 
> Invalid WHOIS 
> >> POC's
> >>     
> >> ... I agree, as I believe Lee does, that all POC records 
> should have 
> >> valid email addresses.
> >>     
> >
> > OK then, would you be willing to support a policy proposal 
> that ONLY stated all POC's must have valid e-mail addresses?  
> Nothing else about validation or any of that?  Just a simple 
> statement that all POCs in the whois database must have valid 
> e-mail addresses?
> >   
> 
> No.  Without validation and enforcement, the policy would be 
> useless and just clutter the NRPM.
> 

Heh.  OK I see your not going to make it easy for me.

I'm going to assume that no matter what I say your not going to
be convinced.  But I am not too concerned about that because it's
clear that ARIN uses an elastic definition of consensus - not
every last person must agree for a policy to go into effect.  So
I really only need to meet the bar of convincing everyone else,
and your response here allows me the opportunity to do it.


You believe that policy proposals must have validation and
enforcement.  That's your first premise.

You also stated that you believe all POC records should have
valid e-mail addresses.  Now, MOST people
would assume that the definition of a valid e-mail address is
one that the POC gets the e-mails sent to it - even if the POC
chooses to not respond.  BUT, here is where things get a bit tricky.

If an e-mail address in WHOIS is accepting mail but the POC is not
responding, EVEN THOUGH it might be ORDINAIRLY considered
"valid" in the context of what an e-mail address IS, in the
context of the ARIN WHOIS database IT IS NOT VALID.  It isn't
valid because there is no way to PROVE it is valid unless
they respond to a message to it.  Proof requires them to respond.
Just looking in your /var/log/maillog
and seeing the remote machine accepting the message isn't enough.

You could query whois, get the e-mail address, call the POC, say
"is this your e-mail address" and have them say yes, then send
an e-mail to it, and even see your machine contacting their
mailserver and the message going - but unless they say "OK I
got the message" you have NO PROOF that the POC actually got
the message.  Their mailserver could have simply discarded the
message before delivering it to their e-mail box.

The actual human that the POC is, MUST RESPOND for the
address to be considered VALID in the context of the WHOIS database.

So, thus is the second premise.  You state that you believe
all POC records should have valid e-mail addresses.  That means,
e-mail addresses where then the POC is contacted by e-mail,
the POC responds.  (spam messages mailed to the poc are not
attempts by a human to contact the poc, thus the POC does not
need to respond to the spammer to be considered valid)

To throw your position a bone, the policy specifies contact by ARIN must
be responded to, not contact by anyone else in the world.

OK so now we have our 2 premises that YOU claim to believe in.

Now, for these premises to be valid in this proposal, the
first step is that the only possible way here for ARIN to
know if the POC e-mail is valid is to e-mail it and get responses
(e-mail or otherwise)  I mean, if they simply called the POC on the
phone or sent them a paper letter, asking if the e-mail address in
the POC was correct, that's still no guarentee that the address isn't
bogus - the POC could lie to them.  It takes an actual e-mail
and response, to know.

But, we aren't complete.  What is ARIN?  ARIN is us.  Meaning, 
the ARIN membership, us, essentially govern ARIN.  Effectively WE are the
ones asking if such-and-such an e-mail address on a POC is valid.
And ARIN staff has to have some way of communicating the response back
to us.  That way is the whois database.

In short, if I ask how do you, Stephen, know if a specific e-mail
address on a POCis valid, your answer would be that you know it's
valid because WHOIS says it is.

But, today, right now, you, me, nobody has any way of knowing if
this is true.  Because, the WHOIS database currently is not validated,
not checked, and has NEVER been.

In short, today we CANNOT conform to your premise #2 - that all
POC's must have valid e-mail addresses in WHOIS.  Thus, we MUST
validate to conform to that - premise #1.

And, because contact of the POC by any other means than e-mail
introduces the ability that the POC can lie, ONLY contact via
e-mail followed by a response by the POC meets the bar set by
your premise #2 - that POC's must have valid E-mail addresses.

Thus, the policy proposal specifies contact by e-mail.




Ted



From cra at WPI.EDU  Tue Mar 24 16:58:01 2009
From: cra at WPI.EDU (Chuck Anderson)
Date: Tue, 24 Mar 2009 16:58:01 -0400
Subject: [arin-ppml] Draft Policy 2009-2: Depleted IPv4 reserves
In-Reply-To: <49C947E0.90708@usfamily.net>
References: <DE229826F48ABD4CBF754E5AA6CFC14B1DDA222B77@WP40044.corp.ads>
	<89D27DE3375BB6428DDCC2927489826A02223F9E@nexus.nexicomgroup.net>
	<49C942CC.9010009@usfamily.net>
	<DE229826F48ABD4CBF754E5AA6CFC14B1DDA222BD9@WP40044.corp.ads>
	<49C947E0.90708@usfamily.net>
Message-ID: <20090324205801.GC3330@angus.ind.WPI.EDU>

On Tue, Mar 24, 2009 at 03:51:46PM -0500, Ron Cleven wrote:
> So, there is no way for a PC operating over IPv6 to access an IPv4 web 
> site or mail server or ...
> 
> Hmmmmm, sounds like a problem.  Maybe some really bright people out 
> there can figure out a way to make that happen?

There are people working on it.  See IVI:

http://tools.ietf.org/html/draft-xli-behave-ivi-01


From tedm at ipinc.net  Tue Mar 24 17:33:15 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 24 Mar 2009 14:33:15 -0700
Subject: [arin-ppml] Draft Policy 2009-2: Depleted IPv4 reserves
In-Reply-To: <49C947E0.90708@usfamily.net>
References: <49C7DD7B.5000901@arin.net><DE229826F48ABD4CBF754E5AA6CFC14B1DDA22280E@WP40044.corp.ads><49C9104E.3040105@sprunk.org>	<49C9241D.6050601@usfamily.net><DE229826F48ABD4CBF754E5AA6CFC14B1DDA222B10@WP40044.corp.ads><49C92D3C.2010509@usfamily.net>	<DE229826F48ABD4CBF754E5AA6CFC14B1DDA222B77@WP40044.corp.ads>	<89D27DE3375BB6428DDCC2927489826A02223F9E@nexus.nexicomgroup.net>	<49C942CC.9010009@usfamily.net><DE229826F48ABD4CBF754E5AA6CFC14B1DDA222BD9@WP40044.corp.ads>
	<49C947E0.90708@usfamily.net>
Message-ID: <0DFD0A7AD0814EC790323AA97CCC1874@tedsdesk>

 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ron Cleven
> Sent: Tuesday, March 24, 2009 1:52 PM
> To: ARIN PPML
> Subject: Re: [arin-ppml] Draft Policy 2009-2: Depleted IPv4 reserves
> 
> So, there is no way for a PC operating over IPv6 to access an 
> IPv4 web site or mail server or ...
> 
> Hmmmmm, sounds like a problem.  Maybe some really bright 
> people out there can figure out a way to make that happen?
> 

look and see:

http://linux.yyz.us/ipv6/proxy.html

Ted



From martin.hannigan at batelnet.bs  Tue Mar 24 17:34:08 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Tue, 24 Mar 2009 17:34:08 -0400
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using the
	Emergency PDP)
In-Reply-To: <49C911A8.5020009@arin.net>
References: <49C911A8.5020009@arin.net>
Message-ID: <4607e1d50903241434x2f79d44qc685726f5348e167@mail.gmail.com>

My contribution is related to the policy. I reserve my right to provide an
act for the circus at a later date.

On Tue, Mar 24, 2009 at 1:00 PM, Member Services <info at arin.net> wrote:

[ clip ]



> 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.
>


Stating that the POC has no rights and then requiring them to take action on
our behalf seems questionable. I don't think we can require a POC to do
anything.

I'd be in favor of this if the work was ARIN's and it was effective. "Upon
notification of a major negative change in a Corporations status" might work
and leaving  the door open for methods of surveillance to implement this
section of the policy would be useful, IMHO.

The rewrite may read:

"Number resources are issued based on justified need to organizations and
not to individuals that represent those organizations. Upon notification
that a major negative event related to the Corporations solvency [define
these in defintions] has occurred, ARIN will freeze all assigned  provider
independent "PI" address space, ASN's, and affiliated resources deemed
necessary to protect ARIN assigned number resources and their disposition.
Changes to these resources during the negative event will be processed in a
manner consistent with ARIN policy and agreements in effect at the time of
the negative event".


[ clip ]

Not in love with the M&A requirements. Too broad in depth and breadth. We've
been here before so I don't need to repeat.

Best Regards,


Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090324/0a0c7f81/attachment.htm>

From scottleibrand at gmail.com  Tue Mar 24 17:49:20 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Tue, 24 Mar 2009 14:49:20 -0700
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using the
	Emergency PDP)
In-Reply-To: <4607e1d50903241434x2f79d44qc685726f5348e167@mail.gmail.com>
References: <49C911A8.5020009@arin.net>
	<4607e1d50903241434x2f79d44qc685726f5348e167@mail.gmail.com>
Message-ID: <3A14052C-A43F-4849-AF62-1702EC7A5CE3@gmail.com>

Martin,

Those sections are already in the NRPM. If you think they need  
changed, I think it would be best to make a new proposal to do so.

Do you have any (more) feedback on the changes proposed here?

Thanks,
Scott

On Mar 24, 2009, at 2:34 PM, Martin Hannigan <martin.hannigan at batelnet.bs 
 > wrote:

>
>
> My contribution is related to the policy. I reserve my right to  
> provide an act for the circus at a later date.
>
> On Tue, Mar 24, 2009 at 1:00 PM, Member Services <info at arin.net>  
> wrote:
>
> [ clip ]
>
>
>
> 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.
>
>
> Stating that the POC has no rights and then requiring them to take  
> action on our behalf seems questionable. I don't think we can  
> require a POC to do anything.
>
> I'd be in favor of this if the work was ARIN's and it was effective.  
> "Upon notification of a major negative change in a Corporations  
> status" might work and leaving  the door open for methods of  
> surveillance to implement this section of the policy would be  
> useful, IMHO.
>
> The rewrite may read:
>
> "Number resources are issued based on justified need to  
> organizations and not to individuals that represent those  
> organizations. Upon notification that a major negative event related  
> to the Corporations solvency [define these in defintions] has  
> occurred, ARIN will freeze all assigned  provider independent "PI"  
> address space, ASN's, and affiliated resources deemed necessary to  
> protect ARIN assigned number resources and their disposition.  
> Changes to these resources during the negative event will be  
> processed in a manner consistent with ARIN policy and agreements in  
> effect at the time of the negative event".
>
>
> [ clip ]
>
> Not in love with the M&A requirements. Too broad in depth and  
> breadth. We've been here before so I don't need to repeat.
>
> Best Regards,
>
>
> Martin
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090324/e6b2ade9/attachment.htm>

From martin.hannigan at batelnet.bs  Tue Mar 24 17:54:10 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Tue, 24 Mar 2009 17:54:10 -0400
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using the
	Emergency PDP)
In-Reply-To: <3A14052C-A43F-4849-AF62-1702EC7A5CE3@gmail.com>
References: <49C911A8.5020009@arin.net>
	<4607e1d50903241434x2f79d44qc685726f5348e167@mail.gmail.com>
	<3A14052C-A43F-4849-AF62-1702EC7A5CE3@gmail.com>
Message-ID: <4607e1d50903241454i175cec35ob670684147e34d0f@mail.gmail.com>

Scott,

This posting says "replace section 8". I think that opens the policy up to
feedback on all sections.

-M<



On Tue, Mar 24, 2009 at 5:49 PM, Scott Leibrand <scottleibrand at gmail.com>wrote:

> Martin,
>
> Those sections are already in the NRPM. If you think they need changed, I
> think it would be best to make a new proposal to do so.
>
> Do you have any (more) feedback on the changes proposed here?
>
> Thanks,
> Scott
>
> On Mar 24, 2009, at 2:34 PM, Martin Hannigan <martin.hannigan at batelnet.bs>
> wrote:
>
>
>
> My contribution is related to the policy. I reserve my right to provide an
> act for the circus at a later date.
>
> On Tue, Mar 24, 2009 at 1:00 PM, Member Services < <info at arin.net>
> info at arin.net> wrote:
>
> [ clip ]
>
>
>
>> 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.
>>
>
>
> Stating that the POC has no rights and then requiring them to take action
> on our behalf seems questionable. I don't think we can require a POC to do
> anything.
>
> I'd be in favor of this if the work was ARIN's and it was effective. "Upon
> notification of a major negative change in a Corporations status" might work
> and leaving  the door open for methods of surveillance to implement this
> section of the policy would be useful, IMHO.
>
> The rewrite may read:
>
> "Number resources are issued based on justified need to organizations and
> not to individuals that represent those organizations. Upon notification
> that a major negative event related to the Corporations solvency [define
> these in defintions] has occurred, ARIN will freeze all assigned  provider
> independent "PI" address space, ASN's, and affiliated resources deemed
> necessary to protect ARIN assigned number resources and their disposition.
> Changes to these resources during the negative event will be processed in a
> manner consistent with ARIN policy and agreements in effect at the time of
> the negative event".
>
>
> [ clip ]
>
> Not in love with the M&A requirements. Too broad in depth and breadth.
> We've been here before so I don't need to repeat.
>
> Best Regards,
>
>
> Martin
>
>
>  _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090324/ecb8936e/attachment.htm>

From scottleibrand at gmail.com  Tue Mar 24 18:12:49 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Tue, 24 Mar 2009 15:12:49 -0700
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using the
 Emergency PDP)
In-Reply-To: <4607e1d50903241454i175cec35ob670684147e34d0f@mail.gmail.com>
References: <49C911A8.5020009@arin.net>	
	<4607e1d50903241434x2f79d44qc685726f5348e167@mail.gmail.com>	
	<3A14052C-A43F-4849-AF62-1702EC7A5CE3@gmail.com>
	<4607e1d50903241454i175cec35ob670684147e34d0f@mail.gmail.com>
Message-ID: <49C95AE1.6030209@gmail.com>

True, but I don't think we should make such changes using the emergency 
PDP unless they're critical.  Since we're essentially in a highly 
abbreviated (almost last-call like) review period for this emergency 
draft policy, I think we're best off focusing on the changes the Board 
made in the emergency policy.

I do think it would be worthwhile to clean up the old M&A transfer 
policy (and others have said so as well, including staff in some of 
their assessments of 2008-2), so I would welcome a policy proposal to do 
so (using the normal PDP).

Do you have any specific opinion on the changes between 2008-6 and 
2009-1, such as the removal of the 3-year sunset clause?

Thanks for your well-thought out non-circus-act contributions thus far, 
on this and all the other draft policy proposals.

-Scott

Martin Hannigan wrote:
>
>
> Scott,
>
> This posting says "replace section 8". I think that opens the policy 
> up to feedback on all sections.
>
> -M<
>
>
>
> On Tue, Mar 24, 2009 at 5:49 PM, Scott Leibrand 
> <scottleibrand at gmail.com <mailto:scottleibrand at gmail.com>> wrote:
>
>     Martin,
>
>     Those sections are already in the NRPM. If you think they need
>     changed, I think it would be best to make a new proposal to do so. 
>
>     Do you have any (more) feedback on the changes proposed here?
>
>     Thanks,
>     Scott
>
>     On Mar 24, 2009, at 2:34 PM, Martin Hannigan
>     <martin.hannigan at batelnet.bs <mailto:martin.hannigan at batelnet.bs>>
>     wrote:
>
>>
>>
>>     My contribution is related to the policy. I reserve my right to
>>     provide an act for the circus at a later date.
>>
>>     On Tue, Mar 24, 2009 at 1:00 PM, Member Services <info at arin.net
>>     <mailto:info at arin.net>> wrote:
>>
>>     [ clip ]
>>      
>>
>>
>>         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.
>>
>>
>>
>>     Stating that the POC has no rights and then requiring them to
>>     take action on our behalf seems questionable. I don't think we
>>     can require a POC to do anything.
>>
>>     I'd be in favor of this if the work was ARIN's and it was
>>     effective. "Upon notification of a major negative change in a
>>     Corporations status" might work and leaving  the door open for
>>     methods of surveillance to implement this section of the policy
>>     would be useful, IMHO.
>>      
>>     The rewrite may read:
>>
>>     "Number resources are issued based on justified need to
>>     organizations and not to individuals that represent those
>>     organizations. Upon notification that a major negative event
>>     related to the Corporations solvency [define these in defintions]
>>     has occurred, ARIN will freeze all assigned  provider independent
>>     "PI" address space, ASN's, and affiliated resources deemed
>>     necessary to protect ARIN assigned number resources and their
>>     disposition. Changes to these resources during the negative event
>>     will be processed in a manner consistent with ARIN policy and
>>     agreements in effect at the time of the negative event".
>>
>>
>>     [ clip ]
>>
>>     Not in love with the M&A requirements. Too broad in depth and
>>     breadth. We've been here before so I don't need to repeat.
>>
>>     Best Regards,
>>
>>
>>     Martin
>>
>>
>>     _______________________________________________
>>     PPML
>>     You are receiving this message because you are subscribed to
>>     the ARIN Public Policy Mailing List (ARIN-PPML at arin.net
>>     <mailto:ARIN-PPML at arin.net>).
>>     Unsubscribe or manage your mailing list subscription at:
>>     http://lists.arin.net/mailman/listinfo/arin-ppml
>>     Please contact info at arin.net <mailto:info at arin.net> if you
>>     experience any issues.
>
>


From martin.hannigan at batelnet.bs  Tue Mar 24 18:40:47 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Tue, 24 Mar 2009 18:40:47 -0400
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using the
	Emergency PDP)
In-Reply-To: <49C95AE1.6030209@gmail.com>
References: <49C911A8.5020009@arin.net>
	<4607e1d50903241434x2f79d44qc685726f5348e167@mail.gmail.com>
	<3A14052C-A43F-4849-AF62-1702EC7A5CE3@gmail.com>
	<4607e1d50903241454i175cec35ob670684147e34d0f@mail.gmail.com>
	<49C95AE1.6030209@gmail.com>
Message-ID: <4607e1d50903241540i785f943fsfc0b3d3669ff11f2@mail.gmail.com>

On Tue, Mar 24, 2009 at 6:12 PM, Scott Leibrand <scottleibrand at gmail.com>wrote:


>
> I do think it would be worthwhile to clean up the old M&A transfer policy
> (and others have said so as well, including staff in some of their
> assessments of 2008-2), so I would welcome a policy proposal to do so (using
> the normal PDP).


Perhaps we should all limit our hopes? :-)


>
> Do you have any specific opinion on the changes between 2008-6 and 2009-1,
> such as the removal of the 3-year sunset clause?


I wasn't in favor of 2008-6. Additional comments that I have are related to
open markets and not germane to the discussion.


>
>
> Thanks for your well-thought out non-circus-act contributions thus far, on
> this and all the other draft policy proposals.


I meant "circus act" tongue in cheek and I hope that it came across
properly. Apologies offered if otherwise.

I would like to add that  I agree with Leo Bicknell. I'd like to see _all_
committees with minutes related to the policies currently under discussion
have at least draft minutes posted for reference no later than seven days
before the meeting. It's nice to have the staff and legal summaries prior to
meeting time so that we can consider everything relevant in the discussion.


Best,

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090324/9fc35392/attachment.htm>

From spiffnolee at yahoo.com  Tue Mar 24 18:35:03 2009
From: spiffnolee at yahoo.com (Lee Howard)
Date: Tue, 24 Mar 2009 15:35:03 -0700 (PDT)
Subject: [arin-ppml] Draft Policy 2009-2: Depleted IPv4 reserves
In-Reply-To: <49C92D3C.2010509@usfamily.net>
References: <49C7DD7B.5000901@arin.net>
	<DE229826F48ABD4CBF754E5AA6CFC14B1DDA22280E@WP40044.corp.ads>
	<49C9104E.3040105@sprunk.org> <49C9241D.6050601@usfamily.net>
	<DE229826F48ABD4CBF754E5AA6CFC14B1DDA222B10@WP40044.corp.ads>
	<49C92D3C.2010509@usfamily.net>
Message-ID: <134995.68761.qm@web63301.mail.re1.yahoo.com>


----- Original Message ----
> From: Ron Cleven <rlc at usfamily.net>
> 
> Are there any other large ISP's monitoring this list who are the least 
> bit concerned about the transition, 

Yes.  

There will be issues.  We're working through various venues to minimize them.  

Lee  (Time Warner Cable)



      



From martin.hannigan at batelnet.bs  Tue Mar 24 18:56:35 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Tue, 24 Mar 2009 18:56:35 -0400
Subject: [arin-ppml] Draft Policy 2009-2: Depleted IPv4 reserves
In-Reply-To: <49C93122.8070909@sprunk.org>
References: <49C7DD7B.5000901@arin.net>
	<4607e1d50903241037w18f2ec15qe182565ee4730ef2@mail.gmail.com>
	<49C93122.8070909@sprunk.org>
Message-ID: <4607e1d50903241556w235f49fdi96ad0cf24872437d@mail.gmail.com>

On Tue, Mar 24, 2009 at 3:14 PM, Stephen Sprunk <stephen at sprunk.org> wrote:

> Martin Hannigan wrote:
>
>>
>>    *Policy statement:*
>>
>>    4.1.8 Depleted IPv4 reserves
>>
>>    A limit will be applied to all IPv4 address requests when ARIN's
>>    reserve of unallocated IPv4 address space drops below an
>>    equivalent /9. When this happens, an ISP or End User may receive
>>    up to a single /20 within a six month period. This restriction
>>    will be lifted in the event the reserve of unallocated IPv4
>>    address space increases to an equivalent /7.
>>
>>
>> This policy seems to impose exactly the same unfair application that
>> Counsel described in the summary for global policy for returning v4 space to
>> the IANA[3]. Creating equal shares only means that equal allocations occur.
>> It still creates a severe need imbalance and potentially creates an unfair
>> advantage for smaller players that a /20 does fulfill their needs.
>>
>
> I can see why you'd think that, but I'll take an actual lawyer's opinion on
> that topic.  Per the email from Member Services that started this thread:
>
> "B. ARIN General Counsel Comments:
>
> The policy does not pose any significant legal risk to ARIN. A community
> decision to segment the remaining unissued IPV4 numbers to serve a larger
> number of users on its face does not discriminate against or for any user,
> large or small. Therefore it is legally unobjectionable. It is a rational
> scheme for distribution reasonably related to meeting the needs of as many
> end users as possible. Counsel respectfully suggests that the policy as
> drafted may contain potential seeds of confusion by providing for switching
> back to current distribution policies, and then back to this policy."
>
>
With respect to my colleagues and Steve Ryan, our Counsel, if I followed
every lawyer that told me something different than I believed with regards
to issues affecting a business that I am involved with I would not be here
today.

In this case, I'm pointing out what appears to be a contradiction. How can
we say that an allocation system that provides for different fractions of
needs is _not_ ok for one party; ARIN as part of the the RIR system via the
global policy I referenced, but is ok for another; in-region networks that
are impacted in the exact same way?

I think that we've got the right idea, maximize end user access, but the
wrong method. The statement was also fairly weak in that it used phrases
like "on it's face" and "significant" and "legally unobjectionable". In
reading between the lines I think that it's to be understood that this issue
isn't completely thought out.


Best,

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090324/d103d919/attachment.htm>

From lea.roberts at stanford.edu  Tue Mar 24 19:35:54 2009
From: lea.roberts at stanford.edu (Lea Roberts)
Date: Tue, 24 Mar 2009 16:35:54 -0700 (PDT)
Subject: [arin-ppml] Draft Policy 2008-3: Community Networks IPv6
	Assignment
In-Reply-To: <91D8824B-745E-4430-AF80-697EF4849BC7@delong.com>
Message-ID: <Pine.LNX.4.44.0903241251500.22026-100000@networking.stanford.edu>

On Tue, 24 Mar 2009, Owen DeLong wrote:

> There is a disconnect between original IPv6 marketing hype
> and reality here.

regardless of marketing hype, there are many things that were said at even
the IETF level which have not been delivered in the protocol that exists
today...

> The "simple renumbering" and independent internal addressing
> structure capabilities are not fully baked and have not as yet
> materialized in IPv6.

FWIW, the simple changing of prefixes on host interfaces, by adding a new
router advertisement and deprecating the old, has been demonstrated to
work (mostly).  unfortunately, however, there exists no tie-in from that
mechanism to access-lists and firewall rules and such that still remain
administrator intensive.

> On Mar 24, 2009, at 12:08 PM, Ted Mittelstaedt wrote:
>
> >
> > I had thought that one of the big advantages of IPv6 is that it was
> > designed to be simple to renumber.

certain parts of the renumbering process are simple but still require
several steps even if the exceptions noted above are not involved.  one of
the cool things that works but has yet to have practical uses is that an
interface can have multiple prefixes assigned.  the hard problem there is
how you decide, among multiple prefixes with global scope, which one to
choose as best to initiate a connection off-site...  this is the kind of
thing that the "experimenter" type of community network might be able to
help develop and test.

> > Thus I am not sure why having "a stable and globally unique address
> > assignment" has anything to do with having "a stable internal address
> > structure" under IPv6.  I can understand why a community network would
> > need the second thing, but I don't see why they can't have this under
> > a globally unique address assignment that's made by a LIR instead of
> > by ARIN.

you seem to assume that they would have a stable provider (i.e. LIR)
connection, which the proposers indicated was not the case for many
community networks.  a better argument would be for them to use ULA but
that's not guaranteed to be globally unique.

> > The community network's internal address structure would NOT change
> > when their connections to outside networks come and go - under IPv6.

once they have an assignment, that is true.  but if not from an LIR???

> > Could the proposers explain what they need, here?  We all what to
> > support non-profit community networks that help poor people get
> > online, but at first blush this looks like the proposal authors are
> > assuming IPv6 == IPv4.

I assure you they (and we on the AC) are quite aware of the difference...

since you ask for disclosure:  I am one the AC shepherds for this policy
and I am in favor of this policy.  My co-shepherd is very much against it.
under the new PDP, I've edited the suggestions from other AC members into
the text as posted and rewrote the rationale (obviously not well enough...
:-)  so while I'm not one of the original proposers, I guess it's on me as
more like an author of what you now see.  I'm sorry to have failed to
explain clearly enough why allowing these IPv6 assignments is worthwhile.

frankly, I believe that current policy limiting IPv6 assignments is much
closer to "assuming IPv6 == IPv4" than this proposal.  I already gotten
all the arguments about how "routing slots" are precious, as did the
original proposers.  they understood that getting into the global DFZ was
unlikely but did have hopes of doing some IPv6 experiments with local
peers and perhaps over tunnels.  personally, I don't think the LIR model
maps very well into the community network environment.  they can probably
get by with ULA but it's sad how the Internet's routing problems bleed
over into creating this false address scarcity.  but, hey, that's the
reality of networking in the early 21st century!    regards,  /Lea



From lea.roberts at stanford.edu  Tue Mar 24 19:44:18 2009
From: lea.roberts at stanford.edu (Lea Roberts)
Date: Tue, 24 Mar 2009 16:44:18 -0700 (PDT)
Subject: [arin-ppml] Draft Policy 2008-3: Community Networks IPv6
	Assignment
In-Reply-To: <Pine.LNX.4.44.0903241251500.22026-100000@networking.stanford.edu>
Message-ID: <Pine.LNX.4.44.0903241636210.25696-100000@networking.stanford.edu>

BTW, the sharp-eyed among you may notice that this policy, as posted,
doesn't match up exactly to the one in the staff comments...  that's
because it was edited in response to their comments!

three occasions of "allocation" were changed to "assignment".   /Lea




From tedm at ipinc.net  Tue Mar 24 20:29:58 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 24 Mar 2009 17:29:58 -0700
Subject: [arin-ppml] Draft Policy 2008-3: Community Networks IPv6
	Assignment
In-Reply-To: <Pine.LNX.4.44.0903241251500.22026-100000@networking.stanford.edu>
References: <91D8824B-745E-4430-AF80-697EF4849BC7@delong.com>
	<Pine.LNX.4.44.0903241251500.22026-100000@networking.stanford.edu>
Message-ID: <DE1C546F32934B869D54CB1CF8EC52B5@tedsdesk>

 

> -----Original Message-----
> From: Lea Roberts [mailto:lea.roberts at stanford.edu] 
> Sent: Tuesday, March 24, 2009 4:36 PM
> To: Ted Mittelstaedt
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy 2008-3: Community 
> Networks IPv6 Assignment
> 
> On Tue, 24 Mar 2009, Owen DeLong wrote:
> 
> > There is a disconnect between original IPv6 marketing hype 
> and reality 
> > here.
> 
> regardless of marketing hype, there are many things that were 
> said at even the IETF level which have not been delivered in 
> the protocol that exists today...
> 
> > The "simple renumbering" and independent internal 
> addressing structure 
> > capabilities are not fully baked and have not as yet 
> materialized in 
> > IPv6.
> 
> FWIW, the simple changing of prefixes on host interfaces, by 
> adding a new router advertisement and deprecating the old, 
> has been demonstrated to work (mostly).  unfortunately, 
> however, there exists no tie-in from that mechanism to 
> access-lists and firewall rules and such that still remain 
> administrator intensive.
> 

Even a devils advocate would agree that firewall ruleset mods are
a bigger problem than interface renumbering under IPv6.  Granted
they will likely occur during a renumber - but not exclusively
because of renumbering, of course.  I am also assuming that a
network that's purely for the purpose of providing access would not
be much interested in deploying extensive firewalling.  After
all, it's charter is to provide access, not be responsible for
whether some user who turns off Windows Firewall gets hit by
an attack.

> > On Mar 24, 2009, at 12:08 PM, Ted Mittelstaedt wrote:
> >
> > >
> > > I had thought that one of the big advantages of IPv6 is 
> that it was 
> > > designed to be simple to renumber.
> 
> certain parts of the renumbering process are simple but still 
> require several steps even if the exceptions noted above are 
> not involved.  one of the cool things that works but has yet 
> to have practical uses is that an interface can have multiple 
> prefixes assigned.  the hard problem there is how you decide, 
> among multiple prefixes with global scope, which one to 
> choose as best to initiate a connection off-site...  this is 
> the kind of thing that the "experimenter" type of community 
> network might be able to help develop and test.
> 
> > > Thus I am not sure why having "a stable and globally 
> unique address 
> > > assignment" has anything to do with having "a stable internal 
> > > address structure" under IPv6.  I can understand why a community 
> > > network would need the second thing, but I don't see why 
> they can't 
> > > have this under a globally unique address assignment 
> that's made by 
> > > a LIR instead of by ARIN.
> 
> you seem to assume that they would have a stable provider 
> (i.e. LIR) connection, which the proposers indicated was not 
> the case for many community networks.  a better argument 
> would be for them to use ULA but that's not guaranteed to be 
> globally unique.
> 
> > > The community network's internal address structure would 
> NOT change 
> > > when their connections to outside networks come and go - 
> under IPv6.
> 
> once they have an assignment, that is true.  but if not from an LIR???
> 
> > > Could the proposers explain what they need, here?  We all what to 
> > > support non-profit community networks that help poor people get 
> > > online, but at first blush this looks like the proposal 
> authors are 
> > > assuming IPv6 == IPv4.
> 
> I assure you they (and we on the AC) are quite aware of the 
> difference...
> 
> since you ask for disclosure:  I am one the AC shepherds for 
> this policy and I am in favor of this policy.  My co-shepherd 
> is very much against it.
> under the new PDP, I've edited the suggestions from other AC 
> members into the text as posted and rewrote the rationale 
> (obviously not well enough...
> :-)  so while I'm not one of the original proposers, I guess 
> it's on me as more like an author of what you now see.  I'm 
> sorry to have failed to explain clearly enough why allowing 
> these IPv6 assignments is worthwhile.
> 

The way I look at it is in terms of how do we design policy
to most easily allow everyone access on the Internet.  That is
why I've been apalled at the lack of maintainence on WHOIS.
Having a large number of POC's that have no usable contact
info encourages the creation of lots of dark matter on the
Internet which harbor all kinds of parasites like spammers who
make life miserable for the rest of us, and raise the cost of
connecting and staying connected.  With portable numbering, if
we are too tight on allowing it, then networks that need it
will do end-runs around what they are supposed to be doing - they
will be spurred into tunneling and doing all kinds of stuff
that make it more difficult for the rest of us to deal with
them - which also creates more dark matter on the Internet
as well.  But, on the other side of the teeter-totter, if
you make addressing policy too liberal and just hand them out
to anyone (including individuals) once more you create other
problems which increase the cost of access to the Internet
for the rest of us.

It is a balancing act.  The proposal rationale just didn't
go into enough depth to weight the teeter-totter in favor
of it, for me.  But that doesn't mean that more weight
couldn't have been put on there.  Your explanation helps
some - but it's still lacking in specifics.  Could we have
an example, at least just one, of a community net that is
active right now, that really -needs- this, and why specifically,
rather than why generally?  I think a specific example of a
network would be more illustrative (you don't have to
say the actual name of the network, just describe it's
specifics, is all) and more effective than just hand-waving.

Ted



From Lee at dilkie.com  Tue Mar 24 21:42:32 2009
From: Lee at dilkie.com (Lee Dilkie)
Date: Tue, 24 Mar 2009 21:42:32 -0400
Subject: [arin-ppml] Draft Policy 2008-7: Identify Invalid WHOIS POC's
In-Reply-To: <51DF79F575B84402A4F04FA1A527E354@tedsdesk>
References: <1f08e8ae3c9c4f4bb0e002f1a1a40c20@mail.dessus.com><62630D01-343C-4E9D-AA83-E6A9ED8478F4@delong.com>	<49C8C942.80601@dilkie.com>	<3E32C91B19244A0D977F953C8BD36871@tedsdesk>	<49C94026.3090203@sprunk.org>
	<51DF79F575B84402A4F04FA1A527E354@tedsdesk>
Message-ID: <49C98C08.2030500@dilkie.com>



Ted Mittelstaedt wrote:
>  
>   
>>>   
>>>       
>> IMHO, that is a gross misrepresentation of what Lee said.  I 
>> agree, as I believe Lee does, that all POC records should 
>> have valid email addresses.
>>     
>
> OK then, would you be willing to support a policy proposal that
> ONLY stated all POC's must have valid e-mail addresses?  Nothing else
> about validation or any of that?  Just a simple statement that
> all POCs in the whois database must have valid e-mail addresses?
>
> Ted
>
>   
I don't have a problem with a policy that POC's have a valid email
address (and I presume you really mean valid/reachable/respondable).
However, I do have a problem with using the current POC email addresses,
as they currently stand, to make the determination of reachability or
not. To determine if a POC (a human being) is reachable, one must use
all the addressing modes (specifically, postal, as that carries legal
weight) to attempt to establish contact *and inform the POC of this
newly enforced requirement to have a valid and reachable/respondable
email address in whois*. I think that only then you can have a fair policy.

-lee

*respondable is not really a word but in this context it means "an
address to which, if an email request is send, a response from the POC
human will be received"



From lear at cisco.com  Wed Mar 25 02:45:10 2009
From: lear at cisco.com (Eliot Lear)
Date: Wed, 25 Mar 2009 07:45:10 +0100
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using
 the	Emergency PDP)
In-Reply-To: <49C911A8.5020009@arin.net>
References: <49C911A8.5020009@arin.net>
Message-ID: <49C9D2F6.9030002@cisco.com>

Dear Member Services,

On 3/24/09 6:00 PM, Member Services wrote:
> Draft Policy 2009-1
> Transfer Policy
>
> The ARIN Board of Trustees has declared a policy emergency and is making
> use of the Emergency PDP provision in the ARIN Policy Development
> Process to revise policy.
>
> At their meeting on 6 February 2009 the ARIN Board of Trustees, based on
> the recommendation of the ARIN Advisory Council and noting that the
> Policy Development Process had been followed, adopted Draft Policy
> 2008-6: Emergency Transfer Policy for IPv4 Addresses.
>
> Then at their meeting on 8 March 2009, the Board noted there is a gap in
> the transfer policy that limits the availability of IPv4 address space
> at a time when otherwise available IPv4 address space will become
> scarce, and declared this gap an emergency. The Board initiated the
> Emergency PDP of the Policy Development Process in order to revise the
> transfer policy (both the existing transfer policy and the policy just
> adopted).
>
> Per the Emergency PDP, the draft policy below is being posted to the
> Public Policy Mailing List for 10 business days of discussion and review
> by the community. The emergency discussion period ends 7 April 2009.
> Within 5 business days of the end of discussion the Advisory Council
> will, having reviewed the comments on the list, review the draft policy
> and make a recommendation to the Board of Trustees. The Board may adopt
> or reject the draft policy. If the Board adopts the policy, it will be
> presented at the next public policy meeting for reconsideration.
>    

Could the Board or a representative please explain what any specific 
action created the emergency under which they have declared a policy 
emergency?  The above is extraordinarily vague and I cannot understand 
how the proposed policy changes support the emergency since I do not 
understand what the emergency is.

Eliot


From michael.dillon at bt.com  Wed Mar 25 02:56:26 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 25 Mar 2009 06:56:26 -0000
Subject: [arin-ppml] Draft Policy 2009-2: Depleted IPv4 reserves
In-Reply-To: <49C9241D.6050601@usfamily.net>
Message-ID: <28E139F46D45AF49A31950F88C49745845D549@E03MVZ2-UKDY.domain1.systemhost.net>

> Stephen's comments are spot on.  The large ISP's are the very 
> ones who have both the resources and clout to make the IPv6 
> transition happen. If they are unwilling or unable to do so, 
> what does that say about the viability of ever making that 
> transition?  Mr. Wilder doth protest too much.

Fact is that we can either give all the remaining IPv4 addresses to a
few large ISPs or send the large ISPs to the brick wall much earlier
than everybody else. Which is the politically more palatable choice?

Cut small business out of the picture? Or tell the large ISPs to start
mining internal resources and transition to IPv6?

The fact is that the large ISPs, because they have large numbers of
IPv4 addresses, have the possibility to recover addresses internally
by cancelling less profitable customer contracts, by moving certain
classes of customer to their choice of NAT/PAT or IPv6, and so on. They
have juggling room. My company is such a large ISP and we fully expect
that all of the LIRs we deal with will cut us off before they cut off
the smaller ISPs. As long as our competitors, other large ISPs, are on
the same level playing ground, this seems fair.

And it is true that we have resources that others do not, for instance
we can influence box vendors on improving their support for IPv6, we
have input into things like the Broadband Forum who are including IPv6
in their next standard for DSL gateways, and so on. In fact, I expect
that many large ISPs, like us, have already got IPv6 customers on the
net. It's just not yet considered a standard product that any account
manager can sell.

--Michael Dillon


From michael.dillon at bt.com  Wed Mar 25 04:28:51 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 25 Mar 2009 08:28:51 -0000
Subject: [arin-ppml] Draft Policy 2009-2: Depleted IPv4 reserves
In-Reply-To: <49C942CC.9010009@usfamily.net>
Message-ID: <28E139F46D45AF49A31950F88C49745845D5AC@E03MVZ2-UKDY.domain1.systemhost.net>


> However, what this all leads to, 
> of course, is whether or not ANY large ISP's have begun 
> large-scale roll-out of new broadband
> (cable/DSL) residential customers in such a fashion that 
> those new customers are forced to use IPv6?
> 
> If that has started happening, have the technical details of 
> the "model" 
> been widely published or are they a closely guarded secret?  

Google for DOCSIS 3.0 for cable ISPs, and for DSL have a look here
<http://www.broadband-forum.org/technical/technicalwip.php> at WT 177. I
believe that IPv6 will be included in the next release of BroadbandSuite
3.1.

As for what people are doing on their core networks, it depends on
whether or not they use MPLS, and how big the jop is. Some non-MPLS
networks are going to dual-stack, others are building an overlay pure
IPv6 network using tunnels to key PoPs where they will have early IPv6
customer. And MPLS networks are probably deploying 6VPE although some
may also be building overlays using pseudowire. But the very biggest
companies actually have several networks internally due to acquisition
history so they will be doing all of the above and more.

> If it HAS started happening, then the depletion of IPv4 
> should be a moot point.

It has started happening but most large companies are careful
not to say too much about future services because they don't 
want their competitors to learn the specifics too soon.

> I understand my comments might sound naive, but if no such "clean" 
> transitional model exists, then we's in a world of hurt.

We still have at least one and a half years for large ISPs to get new
allocations, and then they will be able to mine IPv4 addresses
internally
for quite some time by forcing certain types of customers onto IPv6 or
by simply shutting down less profitable IPv4 dependent
services/customers.
Every companies internal timeline looks different, but it is fair to say
that the ones who take too long will likely suffer decreased valuations
and be acquired by the ones who took the lead and made IPv6 work
profitably.

--Michael Dillon



From michael.dillon at bt.com  Wed Mar 25 07:27:44 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 25 Mar 2009 11:27:44 -0000
Subject: [arin-ppml] Draft Policy 2009-2: Depleted IPv4 reserves
In-Reply-To: <49C947E0.90708@usfamily.net>
Message-ID: <28E139F46D45AF49A31950F88C49745845DA36@E03MVZ2-UKDY.domain1.systemhost.net>

> So, there is no way for a PC operating over IPv6 to access an 
> IPv4 web site or mail server or ...
> 
> Hmmmmm, sounds like a problem.  Maybe some really bright 
> people out there can figure out a way to make that happen?

Please don't make inaccurate statements. If you don't know the answer
then either don't comment, or ask where you can find out how to allow a
PC on IPv6 to access IPv4 servers.

There are several ways that this can be achieved, and many of them are
documented from the ISP perspective at ARIN's IPv6 site
<http://www.getipv6.info>

For solutions which work independent of the ISP supporting it, try
Google. 
These solutions also exist and have for many years now.

--Michael Dillon


From jcurran at istaff.org  Wed Mar 25 08:21:58 2009
From: jcurran at istaff.org (John Curran)
Date: Wed, 25 Mar 2009 08:21:58 -0400
Subject: [arin-ppml] 134.17.0.0/16
Message-ID: <DE200153-C291-4AFB-95DD-B2E3BA068169@istaff.org>

As a follow up to my post on Monday November 16, 2008, Media Breakaway  
has
completed their renumbering effort and has returned the legacy address  
block
134.17.0.0/16, originally issued to "San Francisco (SF) Bay Packet  
Radio"
to ARIN.

Regards,
/John

John Curran
Chairman, ARIN Board of Trustees

===
Begin forwarded message:
> From: John Curran <jcurran at mail.com>
> Date: November 17, 2008 2:26:42 PM EST
> To: arin-ppml at arin.net
> Cc: nanog at nanog.org
> Subject: 134.17.0.0/16
>
> Media Breakaway and ARIN have cooperatively reached an agreement
> whereby Media Breakaway will be returning to ARIN the legacy
> address space 134.17.0.0/16 originally issued to San Francisco
> (SF) Bay Packet Radio.
>
> Media Breakaway will be returning this space upon completion
> of renumbering to a new IPv4 allocation made based on their
> qualification under existing policy.  ARIN is grateful for
> Media Breakaway's cooperation in this matter.
>
> Regards,
> /John
>
> John Curran
> Chairman, ARIN Board of Trustees
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090325/60259aa0/attachment.htm>

From rlc at usfamily.net  Wed Mar 25 08:50:59 2009
From: rlc at usfamily.net (Ron Cleven)
Date: Wed, 25 Mar 2009 07:50:59 -0500 (CDT)
Subject: [arin-ppml] Draft Policy 2009-2: Depleted IPv4 reserves
In-Reply-To: <28E139F46D45AF49A31950F88C49745845DA36@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C49745845DA36@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <49CA28B2.90209@usfamily.net>

Michael,

I think maybe you missed the sarcasm in my email.  I was reacting to the 
following statement by someone from TELUS, who did not appear to have a 
very optimistic view of IPv6:

    So to summarize, the large ISPs should take one for the team
    and force their customers onto a network standard that would
    cut them off from the majority of content they are interested
    in, incurring massive cost while doing so, and then every
    other ISP out there doesn't have to worry about IPv4 exhaust
    because it won't even happen.  When you put it that way, I
    will bring the business case to my superiors and get approval
    right away!

As is pretty obvious, his assertion was that the transition to IPv6 for 
broadband customers would involve "massive costs" and such a transition 
would "cut [the adopting customers] off from the majority of content".

I don't have any opinion on the cost issue, though I have certainly read 
plenty of posts here that dismiss that assertion as silly.  However, I 
obviously know that a properly-designed IPv6 transition for broadband 
customers should/would not cut those customers off from a majority of 
content, as there appear to be a few thousand different ways of 
implementing such a transition (ok, I might be exaggerating a bit), most 
of which would not have that effect.

However, the sarcasm was not really directed at the TELUS person.  If a 
marketing person had been in charge of the design of IPv6, there would 
only be ONE way of implementing the transition, because the top 5 goals 
for such a design would have been:

1) Clean interoperability of IPv6 and IPv4 to expedite adoption
2) Clean interoperability of IPv6 and IPv4 to expedite adoption
3) Clean interoperability of IPv6 and IPv4 to expedite adoption
4) Clean interoperability of IPv6 and IPv4 to expedite adoption
5) Clean interoperability of IPv6 and IPv4 to expedite adoption

Products need to be defined in a fashion that allows them to eventually 
get to market, and, in this market, you have to play nice with the 
billions of IPv4-only devices out there, at least for some non-trivial 
transitional period of time.

All those bits could have been put to good use.  If I "owned" the IPv4 
address 1.2.3.4, I should implicitly own the IPv6 address x:1:2:3:4:y. 
In short, at worst I should have to buy a fleet of shiny new Cisco 
routers that understand that and have enough capacity to deal with it.

Instead, after a decade, there still seems to be as many network designs 
to deal with IPv6/IPv4 interoperability as there are ISP's who have 
dabbled with it.  But, there I go exaggerating again.  Sorry.  It is 
amazing that with all the smart people involved, we still find ourselves 
playing chicken with binary arithmetic.

Ron



michael.dillon at bt.com wrote:

>>So, there is no way for a PC operating over IPv6 to access an 
>>IPv4 web site or mail server or ...
>>
>>Hmmmmm, sounds like a problem.  Maybe some really bright 
>>people out there can figure out a way to make that happen?
> 
> 
> Please don't make inaccurate statements. If you don't know the answer
> then either don't comment, or ask where you can find out how to allow a
> PC on IPv6 to access IPv4 servers.
> 
> There are several ways that this can be achieved, and many of them are
> documented from the ISP perspective at ARIN's IPv6 site
> <http://www.getipv6.info>
> 
> For solutions which work independent of the ISP supporting it, try
> Google. 
> These solutions also exist and have for many years now.
> 
> --Michael Dillon
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 



From tedm at ipinc.net  Wed Mar 25 13:17:34 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 25 Mar 2009 10:17:34 -0700
Subject: [arin-ppml] Draft Policy 2008-7: Identify Invalid WHOIS POC's
In-Reply-To: <49C98C08.2030500@dilkie.com>
References: <1f08e8ae3c9c4f4bb0e002f1a1a40c20@mail.dessus.com><62630D01-343C-4E9D-AA83-E6A9ED8478F4@delong.com>	<49C8C942.80601@dilkie.com>	<3E32C91B19244A0D977F953C8BD36871@tedsdesk>	<49C94026.3090203@sprunk.org>
	<51DF79F575B84402A4F04FA1A527E354@tedsdesk>
	<49C98C08.2030500@dilkie.com>
Message-ID: <9E0414D1A1BC4E87933E65A41BF92751@tedsdesk>

 

> -----Original Message-----
> From: Lee Dilkie [mailto:Lee at dilkie.com] 
> Sent: Tuesday, March 24, 2009 6:43 PM
> To: Ted Mittelstaedt
> Cc: 'Stephen Sprunk'; 'ARIN PPML'
> Subject: Re: [arin-ppml] Draft Policy 2008-7: Identify 
> Invalid WHOIS POC's
> 
> 
> 
> Ted Mittelstaedt wrote:
> >  
> >   
> >>>   
> >>>       
> >> IMHO, that is a gross misrepresentation of what Lee said.  
> I agree, 
> >> as I believe Lee does, that all POC records should have 
> valid email 
> >> addresses.
> >>     
> >
> > OK then, would you be willing to support a policy proposal 
> that ONLY 
> > stated all POC's must have valid e-mail addresses?  Nothing 
> else about 
> > validation or any of that?  Just a simple statement that 
> all POCs in 
> > the whois database must have valid e-mail addresses?
> >
> > Ted
> >
> >   
> I don't have a problem with a policy that POC's have a valid 
> email address (and I presume you really mean 
> valid/reachable/respondable).
> However, I do have a problem with using the current POC email 
> addresses, as they currently stand, to make the determination 
> of reachability or not. 

That is NOT what the policy proposal states.  Please re-read it.

Nowhere in the policy proposal is ARIN staff directed
to make a determination if a POC is completely and permanently
abandoned or otherwise illegitimate AS A RESULT of a failure
of the POC to respond to e-mail.

Instead, the directive to ARIN staff to determine if a POC is
completely and permanently abandoned or otherwise illegitimate
is open-ended.  The policy directs ARIN staff to make this
determination on an annual basis, period.  The policy also
directs ARIN staff to mark unresponsive POC e-mail addresses
in the WHOIS database on an annual basis.

The proposal was CAREFULLY crafted to SPECIFICALY NOT REQUIRE
ARIN staff to make a validity determination based on the
results of e-mail. 

Obviously, since both of these are annual validations (ie:
POC validation and e-mail validation) there's synergy in
doing them together at the same time - which is why the
policy covers them both.  But you will see that the tie-in
is not mandated if you re-read the policy.  (it may be
strongly implied depending on your interpretation of the
policy proposal, of course.  My interpretation is that it
IS strongly implied.  But, a lawyer would almost certainly
tell you that implied policy has no legal validity.)

> To determine if a POC (a human being) 
> is reachable, one must use all the addressing modes 
> (specifically, postal, as that carries legal
> weight) to attempt to establish contact *and inform the POC 
> of this newly enforced requirement to have a valid and 
> reachable/respondable email address in whois*. I think that 
> only then you can have a fair policy.
> 

Specifying contact methods in the policy proposal was tried the last
time this was introduced and it was widely objected by the
list membership as unnecessary interference between policy and
operations.

Lee, it seems one group on the list objects to the policy as
being too narrow, and another group objects to it as being not
narrow enough.  (the group your in)  However, the group objecting to
it being too narrow was making objections to things that were
actually present in that proposal.  Your group that's objecting to
it as being not narrow enough, are objecting to things that
your reading into the policy, that technically aren't actually there.

Ted



From martin.hannigan at batelnet.bs  Wed Mar 25 13:36:40 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Wed, 25 Mar 2009 13:36:40 -0400
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using the
	Emergency PDP)
In-Reply-To: <49C95AE1.6030209@gmail.com>
References: <49C911A8.5020009@arin.net>
	<4607e1d50903241434x2f79d44qc685726f5348e167@mail.gmail.com>
	<3A14052C-A43F-4849-AF62-1702EC7A5CE3@gmail.com>
	<4607e1d50903241454i175cec35ob670684147e34d0f@mail.gmail.com>
	<49C95AE1.6030209@gmail.com>
Message-ID: <4607e1d50903251036k3c441b5kd27ddbe73c6606d6@mail.gmail.com>

Scott,

Thinking out of the box a bit, let me ask you another question. Why
shouldn't we address the entire section in this single review since
the new PDP allows for this and the modification addresses the same
section?

Best,

Martin



On 3/24/09, Scott Leibrand <scottleibrand at gmail.com> wrote:
> True, but I don't think we should make such changes using the emergency
> PDP unless they're critical.  Since we're essentially in a highly
> abbreviated (almost last-call like) review period for this emergency
> draft policy, I think we're best off focusing on the changes the Board
> made in the emergency policy.
>
> I do think it would be worthwhile to clean up the old M&A transfer
> policy (and others have said so as well, including staff in some of
> their assessments of 2008-2), so I would welcome a policy proposal to do
> so (using the normal PDP).
>
> Do you have any specific opinion on the changes between 2008-6 and
> 2009-1, such as the removal of the 3-year sunset clause?
>
> Thanks for your well-thought out non-circus-act contributions thus far,
> on this and all the other draft policy proposals.
>
> -Scott
>
> Martin Hannigan wrote:
>>
>>
>> Scott,
>>
>> This posting says "replace section 8". I think that opens the policy
>> up to feedback on all sections.
>>
>> -M<
>>
>>
>>
>> On Tue, Mar 24, 2009 at 5:49 PM, Scott Leibrand
>> <scottleibrand at gmail.com <mailto:scottleibrand at gmail.com>> wrote:
>>
>>     Martin,
>>
>>     Those sections are already in the NRPM. If you think they need
>>     changed, I think it would be best to make a new proposal to do so.
>>
>>     Do you have any (more) feedback on the changes proposed here?
>>
>>     Thanks,
>>     Scott
>>
>>     On Mar 24, 2009, at 2:34 PM, Martin Hannigan
>>     <martin.hannigan at batelnet.bs <mailto:martin.hannigan at batelnet.bs>>
>>     wrote:
>>
>>>
>>>
>>>     My contribution is related to the policy. I reserve my right to
>>>     provide an act for the circus at a later date.
>>>
>>>     On Tue, Mar 24, 2009 at 1:00 PM, Member Services <info at arin.net
>>>     <mailto:info at arin.net>> wrote:
>>>
>>>     [ clip ]
>>>
>>>
>>>
>>>         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.
>>>
>>>
>>>
>>>     Stating that the POC has no rights and then requiring them to
>>>     take action on our behalf seems questionable. I don't think we
>>>     can require a POC to do anything.
>>>
>>>     I'd be in favor of this if the work was ARIN's and it was
>>>     effective. "Upon notification of a major negative change in a
>>>     Corporations status" might work and leaving  the door open for
>>>     methods of surveillance to implement this section of the policy
>>>     would be useful, IMHO.
>>>
>>>     The rewrite may read:
>>>
>>>     "Number resources are issued based on justified need to
>>>     organizations and not to individuals that represent those
>>>     organizations. Upon notification that a major negative event
>>>     related to the Corporations solvency [define these in defintions]
>>>     has occurred, ARIN will freeze all assigned  provider independent
>>>     "PI" address space, ASN's, and affiliated resources deemed
>>>     necessary to protect ARIN assigned number resources and their
>>>     disposition. Changes to these resources during the negative event
>>>     will be processed in a manner consistent with ARIN policy and
>>>     agreements in effect at the time of the negative event".
>>>
>>>
>>>     [ clip ]
>>>
>>>     Not in love with the M&A requirements. Too broad in depth and
>>>     breadth. We've been here before so I don't need to repeat.
>>>
>>>     Best Regards,
>>>
>>>
>>>     Martin
>>>
>>>
>>>     _______________________________________________
>>>     PPML
>>>     You are receiving this message because you are subscribed to
>>>     the ARIN Public Policy Mailing List (ARIN-PPML at arin.net
>>>     <mailto:ARIN-PPML at arin.net>).
>>>     Unsubscribe or manage your mailing list subscription at:
>>>     http://lists.arin.net/mailman/listinfo/arin-ppml
>>>     Please contact info at arin.net <mailto:info at arin.net> if you
>>>     experience any issues.
>>
>>
>

-- 
Sent from my mobile device


From scottleibrand at gmail.com  Wed Mar 25 13:45:16 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Wed, 25 Mar 2009 10:45:16 -0700
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using the
 Emergency PDP)
In-Reply-To: <4607e1d50903251036k3c441b5kd27ddbe73c6606d6@mail.gmail.com>
References: <49C911A8.5020009@arin.net>	
	<4607e1d50903241434x2f79d44qc685726f5348e167@mail.gmail.com>	
	<3A14052C-A43F-4849-AF62-1702EC7A5CE3@gmail.com>	
	<4607e1d50903241454i175cec35ob670684147e34d0f@mail.gmail.com>	
	<49C95AE1.6030209@gmail.com>
	<4607e1d50903251036k3c441b5kd27ddbe73c6606d6@mail.gmail.com>
Message-ID: <49CA6DAC.20005@gmail.com>

If this were still 2008-6, we could indeed do that.  2009-1, however, 
since it was created by the Board using the emergency PDP, is not yet 
"owned" by the AC the same way a normal policy would be, so I don't 
think we have the authority to modify it like we could a normal policy.

> Per the Emergency PDP, the draft policy below is being posted to the
> Public Policy Mailing List for 10 business days of discussion and review
> by the community. The emergency discussion period ends 7 April 2009.
> Within 5 business days of the end of discussion the Advisory Council
> will, having reviewed the comments on the list, review the draft policy
> and make a recommendation to the Board of Trustees. The Board may adopt
> or reject the draft policy. If the Board adopts the policy, it will be
> presented at the next public policy meeting for reconsideration.

If the Board adopts the policy after  we get done with the emergency 
discussion period and make our recommendation, it looks like the policy 
will come back to the public policy meeting and the AC, which I presume 
will then follow the normal process.  So perhaps we could make such 
revisions then...

As you may have gathered, we're all trying to figure out this new PDP as 
we go along.  Thanks for raising the questions: it forces me to think 
through what's possible, and how best to do what we want to do.

-Scott

Martin Hannigan wrote:
> Scott,
>
> Thinking out of the box a bit, let me ask you another question. Why
> shouldn't we address the entire section in this single review since
> the new PDP allows for this and the modification addresses the same
> section?
>
> Best,
>
> Martin
>
>
>
> On 3/24/09, Scott Leibrand <scottleibrand at gmail.com> wrote:
>   
>> True, but I don't think we should make such changes using the emergency
>> PDP unless they're critical.  Since we're essentially in a highly
>> abbreviated (almost last-call like) review period for this emergency
>> draft policy, I think we're best off focusing on the changes the Board
>> made in the emergency policy.
>>
>> I do think it would be worthwhile to clean up the old M&A transfer
>> policy (and others have said so as well, including staff in some of
>> their assessments of 2008-2), so I would welcome a policy proposal to do
>> so (using the normal PDP).
>>
>> Do you have any specific opinion on the changes between 2008-6 and
>> 2009-1, such as the removal of the 3-year sunset clause?
>>
>> Thanks for your well-thought out non-circus-act contributions thus far,
>> on this and all the other draft policy proposals.
>>
>> -Scott
>>
>> Martin Hannigan wrote:
>>     
>>> Scott,
>>>
>>> This posting says "replace section 8". I think that opens the policy
>>> up to feedback on all sections.
>>>
>>> -M<
>>>
>>>
>>>
>>> On Tue, Mar 24, 2009 at 5:49 PM, Scott Leibrand
>>> <scottleibrand at gmail.com <mailto:scottleibrand at gmail.com>> wrote:
>>>
>>>     Martin,
>>>
>>>     Those sections are already in the NRPM. If you think they need
>>>     changed, I think it would be best to make a new proposal to do so.
>>>
>>>     Do you have any (more) feedback on the changes proposed here?
>>>
>>>     Thanks,
>>>     Scott
>>>
>>>     On Mar 24, 2009, at 2:34 PM, Martin Hannigan
>>>     <martin.hannigan at batelnet.bs <mailto:martin.hannigan at batelnet.bs>>
>>>     wrote:
>>>
>>>       
>>>>     My contribution is related to the policy. I reserve my right to
>>>>     provide an act for the circus at a later date.
>>>>
>>>>     On Tue, Mar 24, 2009 at 1:00 PM, Member Services <info at arin.net
>>>>     <mailto:info at arin.net>> wrote:
>>>>
>>>>     [ clip ]
>>>>
>>>>
>>>>
>>>>         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.
>>>>
>>>>
>>>>
>>>>     Stating that the POC has no rights and then requiring them to
>>>>     take action on our behalf seems questionable. I don't think we
>>>>     can require a POC to do anything.
>>>>
>>>>     I'd be in favor of this if the work was ARIN's and it was
>>>>     effective. "Upon notification of a major negative change in a
>>>>     Corporations status" might work and leaving  the door open for
>>>>     methods of surveillance to implement this section of the policy
>>>>     would be useful, IMHO.
>>>>
>>>>     The rewrite may read:
>>>>
>>>>     "Number resources are issued based on justified need to
>>>>     organizations and not to individuals that represent those
>>>>     organizations. Upon notification that a major negative event
>>>>     related to the Corporations solvency [define these in defintions]
>>>>     has occurred, ARIN will freeze all assigned  provider independent
>>>>     "PI" address space, ASN's, and affiliated resources deemed
>>>>     necessary to protect ARIN assigned number resources and their
>>>>     disposition. Changes to these resources during the negative event
>>>>     will be processed in a manner consistent with ARIN policy and
>>>>     agreements in effect at the time of the negative event".
>>>>
>>>>
>>>>     [ clip ]
>>>>
>>>>     Not in love with the M&A requirements. Too broad in depth and
>>>>     breadth. We've been here before so I don't need to repeat.
>>>>
>>>>     Best Regards,
>>>>
>>>>
>>>>     Martin
>>>>
>>>>
>>>>     _______________________________________________
>>>>     PPML
>>>>     You are receiving this message because you are subscribed to
>>>>     the ARIN Public Policy Mailing List (ARIN-PPML at arin.net
>>>>     <mailto:ARIN-PPML at arin.net>).
>>>>     Unsubscribe or manage your mailing list subscription at:
>>>>     http://lists.arin.net/mailman/listinfo/arin-ppml
>>>>     Please contact info at arin.net <mailto:info at arin.net> if you
>>>>     experience any issues.
>>>>         
>>>       
>
>   


From leo.vegoda at icann.org  Wed Mar 25 15:17:51 2009
From: leo.vegoda at icann.org (Leo Vegoda)
Date: Wed, 25 Mar 2009 12:17:51 -0700
Subject: [arin-ppml] Draft Policy 2008-3: Community Networks IPv6
 Assignment
In-Reply-To: <91D8824B-745E-4430-AF80-697EF4849BC7@delong.com>
Message-ID: <C5EFD16F.26C2B%leo.vegoda@icann.org>

On 24/03/2009 12:45, "Owen DeLong" <owen at delong.com> wrote:

> There is a disconnect between original IPv6 marketing hype
> and reality here.
> 
> The "simple renumbering" and independent internal addressing
> structure capabilities are not fully baked and have not as yet
> materialized in IPv6.

There's a current draft on the issue, for anyone interested in renumbering
issues:

http://tools.ietf.org/html/draft-carpenter-renum-needs-work-02

Regards,

Leo Vegoda



From Daniel_Alexander at Cable.Comcast.com  Wed Mar 25 15:52:40 2009
From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel)
Date: Wed, 25 Mar 2009 15:52:40 -0400
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using
	theEmergency PDP)
In-Reply-To: <49C911A8.5020009@arin.net>
References: <49C911A8.5020009@arin.net>
Message-ID: <997BC128AE961E4A8B880CD7442D94800A6977DC@NJCHLEXCMB01.cable.comcast.com>


Well this one has created quite a fuss. As the AC Shepherd for 2009-1,
let me throw in my own thoughts, and then I'll wait for further
clarification from the authors.

2008-6 was sent to the BoT by the AC and was adopted according to the
minutes. https://www.arin.net/about_us/bot/bot2009_0206.html

The AC left the door open for the BoT, in their reasoning for accepting
2008-6. The policy, once ratified by the ARIN BoT, would be
"implemented" when the BoT deemed necessary. This appears to be exactly
what is going on. 2008-6 is ratified, and will be implemented by the
Board when they see fit. It even points out in the text of the proposal
that the expectation wasn't until IANA exhaustion.

It appears that the BoT has reservations about the language of 2008-6,
and rather than waiting another couple years for us to hash this out on
the mailing list, created 2009-1 to provide a proposal that would
clarify their concerns. In the interest of expediency, they would like
to use their emergency powers to offer 2009-1 as an alternative, and are
looking for feedback.

This proposal doesn't appear to uproot the work done by the community,
or the AC. As I put the existing language in the NRPM next to the text
of 2009-1, it simply clarifies some wording that is listed in the
"notes" and adds the text of 2008-6. 

The one item that was removed was the sunset clause. This always seemed
redundant to me anyways, since all policies are only valid until changed
by a subsequent policy. Every policy really has a sunset clause
implicitly built into them. 

It would be helpful if people could reply and point out how the text of
2009-1 would fundamentally change the current policy and what was
accepted in 2008-6.

Disclaimer- These are only my interpretations and I cannot speak for the
BoT.

Thanks,
Dan Alexander
ARIN AC hat on


-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Member Services
Sent: Tuesday, March 24, 2009 1:00 PM
To: arin-ppml at arin.net
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using
theEmergency PDP)

Draft Policy 2009-1
Transfer Policy

The ARIN Board of Trustees has declared a policy emergency and is making
use of the Emergency PDP provision in the ARIN Policy Development
Process to revise policy.

At their meeting on 6 February 2009 the ARIN Board of Trustees, based on
the recommendation of the ARIN Advisory Council and noting that the
Policy Development Process had been followed, adopted Draft Policy
2008-6: Emergency Transfer Policy for IPv4 Addresses.

Then at their meeting on 8 March 2009, the Board noted there is a gap in
the transfer policy that limits the availability of IPv4 address space
at a time when otherwise available IPv4 address space will become
scarce, and declared this gap an emergency. The Board initiated the
Emergency PDP of the Policy Development Process in order to revise the
transfer policy (both the existing transfer policy and the policy just
adopted).

Per the Emergency PDP, the draft policy below is being posted to the
Public Policy Mailing List for 10 business days of discussion and review
by the community. The emergency discussion period ends 7 April 2009.
Within 5 business days of the end of discussion the Advisory Council
will, having reviewed the comments on the list, review the draft policy
and make a recommendation to the Board of Trustees. The Board may adopt
or reject the draft policy. If the Board adopts the policy, it will be
presented at the next public policy meeting for reconsideration.

We encourage you to discuss Draft Policy 2009-1 on the PPML. The
discussion on the list will be used by the AC to determine the community
consensus regarding adopting this as policy.

Draft Policy 2009-1: Transfer Policy is available below and at:
https://www.arin.net/policy/proposals/2009_1.html

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

Policy 2008-6: Emergency Transfer Policy for IPv4 Addresses can be found
at:
https://www.arin.net/policy/proposals/2008_6.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy 2009-1
Transfer Policy

Originator: ARIN Board of Trustees (using the Emergency PDP provision in
the ARIN Policy Development Process)

Date: 24 March 2009

Policy statement:

Insert into the ARIN Number Resource Policy Manual as follows:

Add Section 2.8:

"Organization. An Organization is one or more legal entities under
common control or ownership."

Replace Section 8 as follows:

8. Transfers

8.1. Principles
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. Mergers and Acquisitions
ARIN will consider requests for the transfer of number resources in the
case of mergers and acquisitions 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.

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) affecting 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 Transfers to Specified Recipients
Number resources may be released, in whole or in part, to ARIN for
transfer to another specified organizational recipient, by any
authorized resource holder within the ARIN region. Such transferred
number resources may only be received by organizations that are within
the ARIN region and can demonstrate the need for such resources in the
exact amount which they can justify under current ARIN policies.

#####

Notes:

Most of the existing Section 8 is left unchanged. List of changes:

2.8 New.
8.1 Changes from "Transfers" to "Principles."
8.2 Changes from "Transfer Requirements" to "Mergers and Acquisitions."
8.2 The word "only" is removed.
8.3 Merged up into 8.2.
8.3 Edited version of the adopted 2008-6.

_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN
Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.


From bicknell at ufp.org  Wed Mar 25 16:25:24 2009
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 25 Mar 2009 15:25:24 -0500
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using
	theEmergency PDP)
In-Reply-To: <997BC128AE961E4A8B880CD7442D94800A6977DC@NJCHLEXCMB01.cable.comcast.com>
References: <49C911A8.5020009@arin.net>
	<997BC128AE961E4A8B880CD7442D94800A6977DC@NJCHLEXCMB01.cable.comcast.com>
Message-ID: <20090325202524.GA18907@ussenterprise.ufp.org>


While I value your opinion, the Board has provided no official
evidence that it matches their thinking.  That in and of itself is
a huge problem.  When the Board uses their emergency powers to pass a
policy the community should not have to speculate as to why it happened.

In a message written on Wed, Mar 25, 2009 at 03:52:40PM -0400, Alexander, Daniel wrote:
> It appears that the BoT has reservations about the language of 2008-6,
> and rather than waiting another couple years for us to hash this out on
> the mailing list, created 2009-1 to provide a proposal that would
> clarify their concerns. In the interest of expediency, they would like
> to use their emergency powers to offer 2009-1 as an alternative, and are
> looking for feedback.

I'm going to speak here specifically as an AC member, but of course
only for myself and not as the entire AC.

The AC goes around begging for people to provide input on policy
decisions.  We do from time to time get input from the Board, either
in the form of briefings during our meetings or in the form of policies
being returned to us by the Board.

Nowhere in the passage of 2008-6 did I get any input from any Board
members that the sunset provision would sink this policy.  That concern
could have been raised at the last face to face meeting, privately to
the AC in any of our monthly meetings since then, or by returning the
policy to the AC.  It makes no sense for the Board to wait until the
11th hour and turn the policy back with something that should have been
out in the open from the start if it was such a major problem.

Also, if the problem is as you describe, and it wouldn't occur for
"another couple years" then why do we have an emergency policy on
the docket?  This should have been returned to the AC, and/or the
Board should have submitted a normal policy proposal.

> The one item that was removed was the sunset clause. This always seemed
> redundant to me anyways, since all policies are only valid until changed
> by a subsequent policy. Every policy really has a sunset clause
> implicitly built into them. 
> 
> It would be helpful if people could reply and point out how the text of
> 2009-1 would fundamentally change the current policy and what was
> accepted in 2008-6.

This policy was sold as a backstop.  The Board had repeatedly told
the AC they did not want to use their emergency powers if at all
possible and would prefer a policy to be passed via the policy
process.  The marketing on this policy was that it was the community
providing approval to the board /if nothing else happened/ between
now and exhaustion and that it had a sunset clause to continue to
motivate work on additional policies.

The message was quite clear to me in the last meeting, the community
wanted to continue work hammering out a better policy, but if for some
reason we couldn't wanted to provide the authorization for a last ditch
effort.

What the board has done here though is to turn "last ditch effort"
into "right now" with 2009-1.  Note it has no implementation
time frame, but since the Board saw fit to use their emergency powers
and it couldn't even wait for the meeting next month I can only
assume the Board hopes to have this up and running prior to the
meeting.  Further, by removing the sunset they have removed a
significant further motivator to continue discussing this policy.

As to the effect, I can point to 2009-4.  Based on the community
input at the last meeting I and others continued to work on
alternatives trying to provide options and to keep the discussion
going on the best way to do this.  If the Board unilaterally decides
to implement a transfer policy of its liking prior to the meeting
then what is the motivation to discuss an alternative?

Even if you wanted to argue there is still room to pass some
alternative, because we board has not disclosed why it took the
action it did one has to wonder if they would even accept it.  The Board
had the opportunity here to craft what they felt was the "right" policy,
and it included no elements of other things on the table.  Without
knowing the justification it is impossible to know if it would be
possible to change their minds.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090325/4a857043/attachment.sig>

From BillD at cait.wustl.edu  Wed Mar 25 17:21:00 2009
From: BillD at cait.wustl.edu (Bill Darte)
Date: Wed, 25 Mar 2009 16:21:00 -0500
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (UsingtheEmergency
	PDP)
In-Reply-To: <997BC128AE961E4A8B880CD7442D94800A6977DC@NJCHLEXCMB01.cable.comcast.com>
References: <49C911A8.5020009@arin.net>
	<997BC128AE961E4A8B880CD7442D94800A6977DC@NJCHLEXCMB01.cable.comcast.com>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D030878AB1B6@ex1.cait.wustl.edu>

2008-6 had marginal consensus support.  That support was largely due to
three things, I believe.
1. The policy statement was distilled to the most fundamental and
essential language.
2. The rationale made it quite clear what the intent was and as
specifically, what its intend was not.
3. The implementation timetable deferred the implementation until such a
time as there was indeed real scarity.

The 3 year sunset was obviously included to mute the contention that the
transfer policy was intended to be permanent, create a continuing
market, and bolster the legacy IPv4 over emergence of IPv6.  And, the
sunset period would not begin, now, but when an emergency scarcity was
obvious, so the sunset's removal now seems to serve no purpose.  The
term of the sunset was always questionable, but was short expecting that
such and emergency would not endure and if it did, it could be extended.
Removal of the sunset, again, seems to suggest and expectation of the
Board that the policy would now become business as usual rather than an
antidote to a real emergency.

If the intent is to declared that an emergency scarcity of IPv4
addresses exists now and that transfers between individuals can commense
upon ratification and implementation, and that those transfers will
continue ad infinitum until the ARIN community wills the policy to be
recinded, then I believe there needs to be some specific evidence
presented which illustrates that ARIN can no longer "fulfill its mission
and [to] facilitate a continuing supply of IPv4 address resources to its
service community" as the rationale states.

And if that is so, then I suggest that the ARIN BoT and the ARIN
community as a whole needs to ramp up its efforts to effect a movement
to IPv6 in real and substantive ways.

Bill Darte
ARIN Advisory Council
Original Author of 2008-6


<<<<<<<< what it said, for clarity >>>>>>>>>

8.4 Emergency Transfer Policy for IPv4 Addresses

For a period of 3 years from policy implementation, authorized resource
holders served by ARIN may designate a recipient for number resources
they
release to ARIN.

Number resources may only be received under RSA in the exact amount
which can be justified under ARIN resource-allocation policies.

Rationale:

In order for ARIN to fulfill its mission and to facilitate a continuing
supply of IPv4 address resources to its service community when ARIN
resources are no longer adequate, and to preserve the integrity of
documentation and ARIN services for those resources, this policy may be
implemented. Its intent is to preserve the current tradition of
need-based allocation/assignments for those still needing IPv4 resources
during a transition period as the industry adopts IPv6. This policy is
not intended to create a 'market' for such transfers and does not
introduce or condone the monetization of address resources or a view of
addresses as property. It does recognize that organizations making
available unused or no longer needed address resources may incur certain
costs that might be compensated by those acquiring the resources. This
policy is intended to be transient and light-weight and does not
encourage a sustained or continuing role for IPv4, but rather helps to
mitigate a transitional crisis that may emerge while the industry adopts
IPv6 in accordance with the recommendation of ARIN's Board of Trustees.

Timetable for implementation:

This policy, once ratified by the ARIN Board of Trustees, would be
implemented when either the free-pool of IANA addresses is exhausted or
IPv4 address resources in the ARIN Region reach a threshold of scarcity
recognized by the ARIN Board of Trustees as requiring this policy
implementation. 



From kkargel at polartel.com  Wed Mar 25 18:14:27 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Wed, 25 Mar 2009 17:14:27 -0500
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy
	(UsingtheEmergencyPDP)
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D030878AB1B6@ex1.cait.wustl.edu>
References: <49C911A8.5020009@arin.net><997BC128AE961E4A8B880CD7442D94800A6977DC@NJCHLEXCMB01.cable.comcast.com>
	<EACF8B735E9CBA4B8BAF9E4165D030878AB1B6@ex1.cait.wustl.edu>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AF1B@mail>


> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Bill Darte
> Sent: Wednesday, March 25, 2009 4:21 PM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy
> (UsingtheEmergencyPDP)
> 
> 2008-6 had marginal consensus support.  That support was largely due to
> three things, I believe.
> 1. The policy statement was distilled to the most fundamental and
> essential language.
> 2. The rationale made it quite clear what the intent was and as
> specifically, what its intend was not.
> 3. The implementation timetable deferred the implementation until such a
> time as there was indeed real scarity.
> 

I think even "marginal" support is an overstatement.  In my possibly tainted
view the majority opposed the proposal.  This is why I am upset that it was
forced in by the same tactics used by politicians to force pork barrel
projects in that have been voted down by the citizens.  

I have and will continue to express my opposition to any policy that permits
a privatized IP market by allowing peer to peer transfers without submitting
the IP blocks for fair distribution to the community.  Turning IP addresses
in to a marketable commodity will severely harm the community.  

Whether or not 2008-6 states it does not intend to create a market that is
exactly what it does.  It will allow any of the big players who can justify
an IP block to negotiate for and purchase IP's, and it then allows them to
market and sell those same IP's.  2008-6 very readily creates the vehicle
that will allow corporations to become IP brokers.  

2009-1 has the same effect by it's inclusion of 2008-6.  

If this resolution becomes active policy I propose we declare ARIN obsolete
and replace it with a web based database where each record holder has the
privilege to reassign ownership and administration of all or part of his
records arbitrarily.

Kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090325/3c8185f8/attachment.bin>

From martin.hannigan at batelnet.bs  Wed Mar 25 18:21:47 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Wed, 25 Mar 2009 18:21:47 -0400
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy
	(UsingtheEmergencyPDP)
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AF1B@mail>
References: <49C911A8.5020009@arin.net>
	<997BC128AE961E4A8B880CD7442D94800A6977DC@NJCHLEXCMB01.cable.comcast.com>
	<EACF8B735E9CBA4B8BAF9E4165D030878AB1B6@ex1.cait.wustl.edu>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4AF1B@mail>
Message-ID: <4607e1d50903251521s2c5e8474r1df930282e9518b8@mail.gmail.com>

On Wed, Mar 25, 2009 at 6:14 PM, Kevin Kargel <kkargel at polartel.com> wrote:

[ clip ]


>
>
> I have and will continue to express my opposition to any policy that
> permits
> a privatized IP market by allowing peer to peer transfers without
> submitting
> the IP blocks for fair distribution to the community.  Turning IP addresses
> in to a marketable commodity will severely harm the community.
>
>

And why would that be? Could you please provide some evidence of this harm
along with your claim so that we can appropriately analyze and respond?

Best Regards,

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090325/ad6d039d/attachment.htm>

From kkargel at polartel.com  Wed Mar 25 18:52:14 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Wed, 25 Mar 2009 17:52:14 -0500
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy
	(UsingtheEmergencyPDP)
In-Reply-To: <4607e1d50903251521s2c5e8474r1df930282e9518b8@mail.gmail.com>
References: <49C911A8.5020009@arin.net>
	<997BC128AE961E4A8B880CD7442D94800A6977DC@NJCHLEXCMB01.cable.comcast.com>
	<EACF8B735E9CBA4B8BAF9E4165D030878AB1B6@ex1.cait.wustl.edu>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4AF1B@mail>
	<4607e1d50903251521s2c5e8474r1df930282e9518b8@mail.gmail.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AF1F@mail>

________________________________________
From: Martin Hannigan [mailto:martin.hannigan at batelnet.bs] 
Sent: Wednesday, March 25, 2009 5:22 PM
To: Kevin Kargel
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy
(UsingtheEmergencyPDP)


On Wed, Mar 25, 2009 at 6:14 PM, Kevin Kargel <kkargel at polartel.com> wrote:

[ clip ]
?


I have and will continue to express my opposition to any policy that permits
a privatized IP market by allowing peer to peer transfers without submitting
the IP blocks for fair distribution to the community. ?Turning IP addresses
in to a marketable commodity will severely harm the community.


And why would that be? Could you please provide some evidence of this harm
along with your claim so that we can appropriately analyze and respond?

Best Regards,

Martin

[/clip]

I have repeatedly provided evidence and didn?t think this needed to be an
extended tome.  Some key points in brief here, longer winded diatribes are
in the archives.

If IP addresses become property they will end up going to the highest
bidder.  This will drive the cost of IP addresses to the maximum that the
market will bear.  That cost will be passed to the consumer.  This hurts the
community.

If IP addresses become monetized property they become regulable
(regulateable?).  IP addresses will be governed under different rules by
every government on earth.  This will hurt the community.

If IP addresses become monetized property they will be taxed. Someone needs
to pay for all the government regulation. This will hurt the community.

If IP addresses move to a privatized market then only the big players will
be able to afford them.  The large players will use dollars and lawyers to
make sure they have a competitive advantage.  This will destroy the small
companies involved in the internet and prevent community based internet
services from being feasible.  This will hurt the community.  
Evidence of this can be seen in what happened to the radio spectrum when the
FCC moved to an auction format to dispense them.  Small company owned
commercial radio stations are far and few between now.  Small companies are
forced to move in to unregulated and unprotected frequencies for
communication because they cannot afford to license their own spectrum.
Amateur radio operaters have been squeezed in to smaller and smaller
spectrums until they are virtually unusable.  Amateur radio is much less
popular.


There are dozens if not hundreds of further points that show how the
community will be hurt by privatizing IP addresses.  The end effect will be
that the Internet will be too expensive for the middle class person to use.
Only large corps and wealthy individuals will have direct access.  The rich
will get richer and the poor will get poorer.  Middle class students will
have fewer resources for education than upper class students.  This will
stratify the classes in society even more strongly than they exist today.  

I believe we have a good system the way it is.  I see no reason to fix
something that isn?t broken, especially for the reason of creating an
artificial commodity market as a growth opportunity.  Don't let your greed
overcome your social responsibility.

Kevin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090325/e7355a90/attachment.bin>

From Lee at dilkie.com  Wed Mar 25 19:02:39 2009
From: Lee at dilkie.com (Lee Dilkie)
Date: Wed, 25 Mar 2009 19:02:39 -0400
Subject: [arin-ppml] Draft Policy 2008-7: Identify Invalid WHOIS POC's
In-Reply-To: <9E0414D1A1BC4E87933E65A41BF92751@tedsdesk>
References: <1f08e8ae3c9c4f4bb0e002f1a1a40c20@mail.dessus.com><62630D01-343C-4E9D-AA83-E6A9ED8478F4@delong.com>	<49C8C942.80601@dilkie.com>	<3E32C91B19244A0D977F953C8BD36871@tedsdesk>	<49C94026.3090203@sprunk.org>
	<51DF79F575B84402A4F04FA1A527E354@tedsdesk>
	<49C98C08.2030500@dilkie.com>
	<9E0414D1A1BC4E87933E65A41BF92751@tedsdesk>
Message-ID: <49CAB80F.1020106@dilkie.com>

Hi Ted,


Ted Mittelstaedt wrote:
> That is NOT what the policy proposal states.  Please re-read it.
>
> Nowhere in the policy proposal is ARIN staff directed
> to make a determination if a POC is completely and permanently
> abandoned or otherwise illegitimate AS A RESULT of a failure
> of the POC to respond to e-mail.
>
> Instead, the directive to ARIN staff to determine if a POC is
> completely and permanently abandoned or otherwise illegitimate
> is open-ended.  The policy directs ARIN staff to make this
> determination on an annual basis, period.  The policy also
> directs ARIN staff to mark unresponsive POC e-mail addresses
> in the WHOIS database on an annual basis.
>
> The proposal was CAREFULLY crafted to SPECIFICALY NOT REQUIRE
> ARIN staff to make a validity determination based on the
> results of e-mail. 
>
> Obviously, since both of these are annual validations (ie:
> POC validation and e-mail validation) there's synergy in
> doing them together at the same time - which is why the
> policy covers them both.  But you will see that the tie-in
> is not mandated if you re-read the policy.  (it may be
> strongly implied depending on your interpretation of the
> policy proposal, of course.  My interpretation is that it
> IS strongly implied.  But, a lawyer would almost certainly
> tell you that implied policy has no legal validity.)
>
>   
>> ..
>
> Specifying contact methods in the policy proposal was tried the last
> time this was introduced and it was widely objected by the
> list membership as unnecessary interference between policy and
> operations.
>
> Lee, it seems one group on the list objects to the policy as
> being too narrow, and another group objects to it as being not
> narrow enough.  (the group your in)  However, the group objecting to
> it being too narrow was making objections to things that were
> actually present in that proposal.  Your group that's objecting to
> it as being not narrow enough, are objecting to things that
> your reading into the policy, that technically aren't actually there.
>
> Ted
>   

If you read my original email on the subject you'll see that I proposed
to simply directly staff to establish the validity of a POC. period.
Drop the email thing. Staff will obviously use email as a first resort
and escalate beyond that but why specify email in the policy? (in other
words, I'm in the other group, the "too narrow")

But I still don't get the "why" of this. This seems to be a lot of
work(and money) and somewhat risky if a false positive (false invalid)
occurs. What's the purpose?

-lee
.



From kkargel at polartel.com  Wed Mar 25 19:11:02 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Wed, 25 Mar 2009 18:11:02 -0500
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy
	(UsingtheEmergencyPDP)
In-Reply-To: <4607e1d50903251521s2c5e8474r1df930282e9518b8@mail.gmail.com>
References: <49C911A8.5020009@arin.net>
	<997BC128AE961E4A8B880CD7442D94800A6977DC@NJCHLEXCMB01.cable.comcast.com>
	<EACF8B735E9CBA4B8BAF9E4165D030878AB1B6@ex1.cait.wustl.edu>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4AF1B@mail>
	<4607e1d50903251521s2c5e8474r1df930282e9518b8@mail.gmail.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AF21@mail>

________________________________________
From: Martin Hannigan [mailto:martin.hannigan at batelnet.bs] 
Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy
(UsingtheEmergencyPDP)


On Wed, Mar 25, 2009 at 6:14 PM, Kevin Kargel <kkargel at polartel.com> wrote:

[ clip ]
?


I have and will continue to express my opposition to any policy that permits
a privatized IP market by allowing peer to peer transfers without submitting
the IP blocks for fair distribution to the community. ?Turning IP addresses
in to a marketable commodity will severely harm the community.


And why would that be? Could you please provide some evidence of this harm
along with your claim so that we can appropriately analyze and respond?

Best Regards,

Martin

____________________________________________________________

One other statement I want to make.  The internet has thrived thus far in an
environment of cooperative anarchy.  This is the only example on earth of
huge numbers of people working effectively together toward a common goal for
the common good.

The far sighted pioneers of the Internet (hey, could these guys be those
vilified legacy holders?) were amazingly wise in designing a medium that was
virtually impossible for governments to tax, control or regulate.  This I
believe is the sole reason why the Internet is as functional as it is.  Once
governments start poking their fingers in to the pie all bets are off.  We
owe a big debt of gratitude to those pioneers.

The Internet we have today is available almost universally across all but
the extremes of social boundaries.  The world is even providing free laptop
computers to third world children with a built in mesh network to pass
Internet along where monetary economies and communication lines are unheard
of.  What a wonderful thing! (OLTPC)

We need to continue this far sightedness and not create cracks where
governments can gain a foothold.  

OK, I'll climb down off my soap box again.

Kevin


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090325/431cffba/attachment.bin>

From jcurran at istaff.org  Wed Mar 25 19:15:32 2009
From: jcurran at istaff.org (John Curran)
Date: Wed, 25 Mar 2009 19:15:32 -0400
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using the
	Emergency PDP)
In-Reply-To: <997BC128AE961E4A8B880CD7442D94800A6977DC@NJCHLEXCMB01.cable.comcast.com>
References: <49C911A8.5020009@arin.net>
	<997BC128AE961E4A8B880CD7442D94800A6977DC@NJCHLEXCMB01.cable.comcast.com>
Message-ID: <6DBC350E-C58F-49B5-950E-266F668BDA5D@istaff.org>

All -

    As noted in Daniel's message, the material change made to the
    transfer policy by the ARIN Board is removal of the 3 year
    sunset clause.  It was the consensus of the Board that this did
    not materially improve the usefulness of the 2008-6, created
    uncertainty for the community, and most importantly represented
    a dangerous precedent of time-based expirations of policy clauses.

    At present, the Board has one tool at its disposal for timely
    modification of policy language, and that is use of the emergency
    policy process.  The Board has already indicated the urgent need
    for a transfer policy and due to the timeliness of the situation,
    it was determined that the best course of action was proceed and
    use to emergency policy process to promptly remove the sunset
    clause rather than risk continued delay of the transfer policy
    via referral back to the AC.

Thanks!
/John

John Curran
Chair, ARIN Board of Trustees
Interim CEO


On Mar 25, 2009, at 3:52 PM, Alexander, Daniel wrote:

>
> Well this one has created quite a fuss. As the AC Shepherd for 2009-1,
> let me throw in my own thoughts, and then I'll wait for further
> clarification from the authors.
>
> 2008-6 was sent to the BoT by the AC and was adopted according to the
> minutes. https://www.arin.net/about_us/bot/bot2009_0206.html
>
> The AC left the door open for the BoT, in their reasoning for  
> accepting
> 2008-6. The policy, once ratified by the ARIN BoT, would be
> "implemented" when the BoT deemed necessary. This appears to be  
> exactly
> what is going on. 2008-6 is ratified, and will be implemented by the
> Board when they see fit. It even points out in the text of the  
> proposal
> that the expectation wasn't until IANA exhaustion.
>
> It appears that the BoT has reservations about the language of 2008-6,
> and rather than waiting another couple years for us to hash this out  
> on
> the mailing list, created 2009-1 to provide a proposal that would
> clarify their concerns. In the interest of expediency, they would like
> to use their emergency powers to offer 2009-1 as an alternative, and  
> are
> looking for feedback.
>
> This proposal doesn't appear to uproot the work done by the community,
> or the AC. As I put the existing language in the NRPM next to the text
> of 2009-1, it simply clarifies some wording that is listed in the
> "notes" and adds the text of 2008-6.
>
> The one item that was removed was the sunset clause. This always  
> seemed
> redundant to me anyways, since all policies are only valid until  
> changed
> by a subsequent policy. Every policy really has a sunset clause
> implicitly built into them.
>
> It would be helpful if people could reply and point out how the text  
> of
> 2009-1 would fundamentally change the current policy and what was
> accepted in 2008-6.
>
> Disclaimer- These are only my interpretations and I cannot speak for  
> the
> BoT.
>
> Thanks,
> Dan Alexander
> ARIN AC hat on
>
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]  
> On
> Behalf Of Member Services
> Sent: Tuesday, March 24, 2009 1:00 PM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using
> theEmergency PDP)
>
> Draft Policy 2009-1
> Transfer Policy
>
> The ARIN Board of Trustees has declared a policy emergency and is  
> making
> use of the Emergency PDP provision in the ARIN Policy Development
> Process to revise policy.
>
> At their meeting on 6 February 2009 the ARIN Board of Trustees,  
> based on
> the recommendation of the ARIN Advisory Council and noting that the
> Policy Development Process had been followed, adopted Draft Policy
> 2008-6: Emergency Transfer Policy for IPv4 Addresses.
>
> Then at their meeting on 8 March 2009, the Board noted there is a  
> gap in
> the transfer policy that limits the availability of IPv4 address space
> at a time when otherwise available IPv4 address space will become
> scarce, and declared this gap an emergency. The Board initiated the
> Emergency PDP of the Policy Development Process in order to revise the
> transfer policy (both the existing transfer policy and the policy just
> adopted).
>
> Per the Emergency PDP, the draft policy below is being posted to the
> Public Policy Mailing List for 10 business days of discussion and  
> review
> by the community. The emergency discussion period ends 7 April 2009.
> Within 5 business days of the end of discussion the Advisory Council
> will, having reviewed the comments on the list, review the draft  
> policy
> and make a recommendation to the Board of Trustees. The Board may  
> adopt
> or reject the draft policy. If the Board adopts the policy, it will be
> presented at the next public policy meeting for reconsideration.
>
> We encourage you to discuss Draft Policy 2009-1 on the PPML. The
> discussion on the list will be used by the AC to determine the  
> community
> consensus regarding adopting this as policy.
>
> Draft Policy 2009-1: Transfer Policy is available below and at:
> https://www.arin.net/policy/proposals/2009_1.html
>
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
>
> Policy 2008-6: Emergency Transfer Policy for IPv4 Addresses can be  
> found
> at:
> https://www.arin.net/policy/proposals/2008_6.html
>
> Regards,
>
> Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Draft Policy 2009-1
> Transfer Policy
>
> Originator: ARIN Board of Trustees (using the Emergency PDP  
> provision in
> the ARIN Policy Development Process)
>
> Date: 24 March 2009
>
> Policy statement:
>
> Insert into the ARIN Number Resource Policy Manual as follows:
>
> Add Section 2.8:
>
> "Organization. An Organization is one or more legal entities under
> common control or ownership."
>
> Replace Section 8 as follows:
>
> 8. Transfers
>
> 8.1. Principles
> 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. Mergers and Acquisitions
> ARIN will consider requests for the transfer of number resources in  
> the
> case of mergers and acquisitions 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.
>
> 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) affecting 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 Transfers to Specified Recipients
> Number resources may be released, in whole or in part, to ARIN for
> transfer to another specified organizational recipient, by any
> authorized resource holder within the ARIN region. Such transferred
> number resources may only be received by organizations that are within
> the ARIN region and can demonstrate the need for such resources in the
> exact amount which they can justify under current ARIN policies.
>
> #####
>
> Notes:
>
> Most of the existing Section 8 is left unchanged. List of changes:
>
> 2.8 New.
> 8.1 Changes from "Transfers" to "Principles."
> 8.2 Changes from "Transfer Requirements" to "Mergers and  
> Acquisitions."
> 8.2 The word "only" is removed.
> 8.3 Merged up into 8.2.
> 8.3 Edited version of the adopted 2008-6.
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN
> Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>



From bicknell at ufp.org  Wed Mar 25 19:54:33 2009
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 25 Mar 2009 18:54:33 -0500
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using the
	Emergency PDP)
In-Reply-To: <6DBC350E-C58F-49B5-950E-266F668BDA5D@istaff.org>
References: <49C911A8.5020009@arin.net>
	<997BC128AE961E4A8B880CD7442D94800A6977DC@NJCHLEXCMB01.cable.comcast.com>
	<6DBC350E-C58F-49B5-950E-266F668BDA5D@istaff.org>
Message-ID: <20090325235433.GB26660@ussenterprise.ufp.org>

In a message written on Wed, Mar 25, 2009 at 07:15:32PM -0400, John Curran wrote:
>     As noted in Daniel's message, the material change made to the
>     transfer policy by the ARIN Board is removal of the 3 year
>     sunset clause.  It was the consensus of the Board that this did
>     not materially improve the usefulness of the 2008-6, created
>     uncertainty for the community, and most importantly represented
>     a dangerous precedent of time-based expirations of policy clauses.

I find it difficult to understand how a well defined date creates
uncertainty, and we in fact already have accepted policies with
time based expirations:

https://www.arin.net/policy/proposals/2005_9.html

Indeed, in that policy as in 2008-6 the dates provide for easy to
understand limits for the community and it's easy to argue that
those limits in 2005-9 have worked amazingly well.  In that case
vendors delivered the features around the time the policy required
them.

However, you've managed to avoid addressing the largest issue.  If
this was such a problem that the Board could not pass a policy with
a time-based expiration and there was an "emergency need" to get
this right why was the Board in whole or as individuals unable to
articulate this problem at the last meeting, on PPML, or in a private
briefing to the AC?  Why does the community find out about this
major, emergency concern at the 11th hour, and as a result only has
14 days on PPML to discuss it and come up with a solution.

If the sunset provision was a fatal flaw that should have been
interjected into the process weeks or months ago.

>     At present, the Board has one tool at its disposal for timely
>     modification of policy language, and that is use of the emergency
>     policy process.  The Board has already indicated the urgent need
>     for a transfer policy and due to the timeliness of the situation,
>     it was determined that the best course of action was proceed and
>     use to emergency policy process to promptly remove the sunset
>     clause rather than risk continued delay of the transfer policy
>     via referral back to the AC.

Given the proximity of the ARIN XXIII meeting I think it would be
irresponsible for the Board to take any action on this policy prior
to it being discussed in a public forum.  To implement a policy a
few weeks prior to a face to face meeting would be a slap in the
face to the community.  Unfortunately as far as I can tell the
process at this point requires the AC and the Board to move on the
policy prior to the face to face meeting.

The Board should not be surprising the community.  Ever.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090325/4e8788b3/attachment.sig>

From BillD at cait.wustl.edu  Wed Mar 25 19:53:45 2009
From: BillD at cait.wustl.edu (Bill Darte)
Date: Wed, 25 Mar 2009 18:53:45 -0500
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using
	theEmergency PDP)
References: <49C911A8.5020009@arin.net><997BC128AE961E4A8B880CD7442D94800A6977DC@NJCHLEXCMB01.cable.comcast.com>
	<6DBC350E-C58F-49B5-950E-266F668BDA5D@istaff.org>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087531F2E@ex1.cait.wustl.edu>

Thanks John,

But what exactly is the basis upon which you adjudged the "urgent need for a transfer policy"...was it the current inability to satisfy addressing requests?  Was it something other?

Under what circumstances would you determine the emergency to be over and would determine no further need for the extended reach of the transfer policy for IPv4?

bd


-----Original Message-----
From: arin-ppml-bounces at arin.net on behalf of John Curran
Sent: Wed 3/25/2009 6:15 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using theEmergency PDP)
 
All -

    As noted in Daniel's message, the material change made to the
    transfer policy by the ARIN Board is removal of the 3 year
    sunset clause.  It was the consensus of the Board that this did
    not materially improve the usefulness of the 2008-6, created
    uncertainty for the community, and most importantly represented
    a dangerous precedent of time-based expirations of policy clauses.

    At present, the Board has one tool at its disposal for timely
    modification of policy language, and that is use of the emergency
    policy process.  The Board has already indicated the urgent need
    for a transfer policy and due to the timeliness of the situation,
    it was determined that the best course of action was proceed and
    use to emergency policy process to promptly remove the sunset
    clause rather than risk continued delay of the transfer policy
    via referral back to the AC.

Thanks!
/John

John Curran
Chair, ARIN Board of Trustees
Interim CEO


On Mar 25, 2009, at 3:52 PM, Alexander, Daniel wrote:

>
> Well this one has created quite a fuss. As the AC Shepherd for 2009-1,
> let me throw in my own thoughts, and then I'll wait for further
> clarification from the authors.
>
> 2008-6 was sent to the BoT by the AC and was adopted according to the
> minutes. https://www.arin.net/about_us/bot/bot2009_0206.html
>
> The AC left the door open for the BoT, in their reasoning for  
> accepting
> 2008-6. The policy, once ratified by the ARIN BoT, would be
> "implemented" when the BoT deemed necessary. This appears to be  
> exactly
> what is going on. 2008-6 is ratified, and will be implemented by the
> Board when they see fit. It even points out in the text of the  
> proposal
> that the expectation wasn't until IANA exhaustion.
>
> It appears that the BoT has reservations about the language of 2008-6,
> and rather than waiting another couple years for us to hash this out  
> on
> the mailing list, created 2009-1 to provide a proposal that would
> clarify their concerns. In the interest of expediency, they would like
> to use their emergency powers to offer 2009-1 as an alternative, and  
> are
> looking for feedback.
>
> This proposal doesn't appear to uproot the work done by the community,
> or the AC. As I put the existing language in the NRPM next to the text
> of 2009-1, it simply clarifies some wording that is listed in the
> "notes" and adds the text of 2008-6.
>
> The one item that was removed was the sunset clause. This always  
> seemed
> redundant to me anyways, since all policies are only valid until  
> changed
> by a subsequent policy. Every policy really has a sunset clause
> implicitly built into them.
>
> It would be helpful if people could reply and point out how the text  
> of
> 2009-1 would fundamentally change the current policy and what was
> accepted in 2008-6.
>
> Disclaimer- These are only my interpretations and I cannot speak for  
> the
> BoT.
>
> Thanks,
> Dan Alexander
> ARIN AC hat on
>
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]  
> On
> Behalf Of Member Services
> Sent: Tuesday, March 24, 2009 1:00 PM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using
> theEmergency PDP)
>
> Draft Policy 2009-1
> Transfer Policy
>
> The ARIN Board of Trustees has declared a policy emergency and is  
> making
> use of the Emergency PDP provision in the ARIN Policy Development
> Process to revise policy.
>
> At their meeting on 6 February 2009 the ARIN Board of Trustees,  
> based on
> the recommendation of the ARIN Advisory Council and noting that the
> Policy Development Process had been followed, adopted Draft Policy
> 2008-6: Emergency Transfer Policy for IPv4 Addresses.
>
> Then at their meeting on 8 March 2009, the Board noted there is a  
> gap in
> the transfer policy that limits the availability of IPv4 address space
> at a time when otherwise available IPv4 address space will become
> scarce, and declared this gap an emergency. The Board initiated the
> Emergency PDP of the Policy Development Process in order to revise the
> transfer policy (both the existing transfer policy and the policy just
> adopted).
>
> Per the Emergency PDP, the draft policy below is being posted to the
> Public Policy Mailing List for 10 business days of discussion and  
> review
> by the community. The emergency discussion period ends 7 April 2009.
> Within 5 business days of the end of discussion the Advisory Council
> will, having reviewed the comments on the list, review the draft  
> policy
> and make a recommendation to the Board of Trustees. The Board may  
> adopt
> or reject the draft policy. If the Board adopts the policy, it will be
> presented at the next public policy meeting for reconsideration.
>
> We encourage you to discuss Draft Policy 2009-1 on the PPML. The
> discussion on the list will be used by the AC to determine the  
> community
> consensus regarding adopting this as policy.
>
> Draft Policy 2009-1: Transfer Policy is available below and at:
> https://www.arin.net/policy/proposals/2009_1.html
>
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
>
> Policy 2008-6: Emergency Transfer Policy for IPv4 Addresses can be  
> found
> at:
> https://www.arin.net/policy/proposals/2008_6.html
>
> Regards,
>
> Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Draft Policy 2009-1
> Transfer Policy
>
> Originator: ARIN Board of Trustees (using the Emergency PDP  
> provision in
> the ARIN Policy Development Process)
>
> Date: 24 March 2009
>
> Policy statement:
>
> Insert into the ARIN Number Resource Policy Manual as follows:
>
> Add Section 2.8:
>
> "Organization. An Organization is one or more legal entities under
> common control or ownership."
>
> Replace Section 8 as follows:
>
> 8. Transfers
>
> 8.1. Principles
> 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. Mergers and Acquisitions
> ARIN will consider requests for the transfer of number resources in  
> the
> case of mergers and acquisitions 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.
>
> 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) affecting 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 Transfers to Specified Recipients
> Number resources may be released, in whole or in part, to ARIN for
> transfer to another specified organizational recipient, by any
> authorized resource holder within the ARIN region. Such transferred
> number resources may only be received by organizations that are within
> the ARIN region and can demonstrate the need for such resources in the
> exact amount which they can justify under current ARIN policies.
>
> #####
>
> Notes:
>
> Most of the existing Section 8 is left unchanged. List of changes:
>
> 2.8 New.
> 8.1 Changes from "Transfers" to "Principles."
> 8.2 Changes from "Transfer Requirements" to "Mergers and  
> Acquisitions."
> 8.2 The word "only" is removed.
> 8.3 Merged up into 8.2.
> 8.3 Edited version of the adopted 2008-6.
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN
> Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>

_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090325/08182ce2/attachment.htm>

From spiffnolee at yahoo.com  Wed Mar 25 20:10:46 2009
From: spiffnolee at yahoo.com (Lee Howard)
Date: Wed, 25 Mar 2009 17:10:46 -0700 (PDT)
Subject: [arin-ppml] Approval of board meeting minutes (was re: 2009-1)
Message-ID: <794096.99465.qm@web63308.mail.re1.yahoo.com>


Ted said: 
> It has been 2 business days since this happened, surely that is
> enough time for the Board to post it's explanation by now.

As Secretary, I will point out that our Bylaws 
https://www.arin.net/about_us/corp_docs/bylaws.html  require us 
to post meeting minutes, following an approval procedure that is 
publicly available: https://www.arin.net/about_us/boardguidelines.html#approval  
That procedure says we give Board members 10 days to review 
minutes before publishing them.  This helps to make sure we have 
accurate minutes.  The minutes of the March 18 meeting have 
been  sent to the Board for approval.  

We also require notice be given to Board members before a meeting
[Bylaws], which makes it very difficult for the body to respond 
quickly to an email thread.

Lee


      



From jcurran at istaff.org  Wed Mar 25 20:34:03 2009
From: jcurran at istaff.org (John Curran)
Date: Wed, 25 Mar 2009 20:34:03 -0400
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using
	theEmergency PDP)
In-Reply-To: <20090325202524.GA18907@ussenterprise.ufp.org>
References: <49C911A8.5020009@arin.net>
	<997BC128AE961E4A8B880CD7442D94800A6977DC@NJCHLEXCMB01.cable.comcast.com>
	<20090325202524.GA18907@ussenterprise.ufp.org>
Message-ID: <27921168-6E53-46BF-B0EA-EDEED4259AE9@istaff.org>

On Mar 25, 2009, at 4:25 PM, Leo Bicknell wrote:
> If the Board unilaterally decide to implement a transfer
> policy of its liking prior to the meeting then what is the
> motivation to discuss an alternative?

To be clear, the Board adopted the transfer policy of the *AC*'s
liking.

Your objection appears to be that we left it to the AC of three
year's hence to decide if it should be retired at that point in
time.

/John

John Curran
Chair, ARIN Board of Trustees



From bicknell at ufp.org  Wed Mar 25 20:48:58 2009
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 25 Mar 2009 19:48:58 -0500
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using
	theEmergency PDP)
In-Reply-To: <27921168-6E53-46BF-B0EA-EDEED4259AE9@istaff.org>
References: <49C911A8.5020009@arin.net>
	<997BC128AE961E4A8B880CD7442D94800A6977DC@NJCHLEXCMB01.cable.comcast.com>
	<20090325202524.GA18907@ussenterprise.ufp.org>
	<27921168-6E53-46BF-B0EA-EDEED4259AE9@istaff.org>
Message-ID: <20090326004858.GA29870@ussenterprise.ufp.org>

In a message written on Wed, Mar 25, 2009 at 08:34:03PM -0400, John Curran wrote:
> To be clear, the Board adopted the transfer policy of the *AC*'s
> liking.

You can't have it both ways John.

If you adopted the policy of the AC's liking there would be no 2009-1.
You "adopted it" for all of 60 seconds, long enough to completely alter
it into 2009-1 under your emergency authority.

It is bait-and-switch for the Board to say it is adopting the policy the
community supported while dramatically altering it via emergency powers.

> Your objection appears to be that we left it to the AC of three
> year's hence to decide if it should be retired at that point in
> time.

That's not what the community wanted, and so yes, I object on the face
of it.

However, the Board neither posted with the policy, nor with any of
the queries since why emergency action was required a mere 30 days
prior to a face to face meeting.  The Board has also not provided any
explanation why this objection couldn't have been raised prior to this
point.  Was the emergency the Board's own making because they failed to
raise this issue in a timely fashion?

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090325/74d2e597/attachment.sig>

From tedm at ipinc.net  Wed Mar 25 20:51:11 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 25 Mar 2009 17:51:11 -0700
Subject: [arin-ppml] Draft Policy 2008-7: Identify Invalid WHOIS POC's
In-Reply-To: <49CAB80F.1020106@dilkie.com>
References: <1f08e8ae3c9c4f4bb0e002f1a1a40c20@mail.dessus.com><62630D01-343C-4E9D-AA83-E6A9ED8478F4@delong.com>	<49C8C942.80601@dilkie.com>	<3E32C91B19244A0D977F953C8BD36871@tedsdesk>	<49C94026.3090203@sprunk.org>
	<51DF79F575B84402A4F04FA1A527E354@tedsdesk>
	<49C98C08.2030500@dilkie.com>
	<9E0414D1A1BC4E87933E65A41BF92751@tedsdesk>
	<49CAB80F.1020106@dilkie.com>
Message-ID: <B115B9DE963A47349839D9C54E839D49@tedsdesk>

 

> -----Original Message-----
> From: Lee Dilkie [mailto:Lee at dilkie.com] 
> Sent: Wednesday, March 25, 2009 4:03 PM
> To: Ted Mittelstaedt
> Cc: 'ARIN PPML'
> Subject: Re: [arin-ppml] Draft Policy 2008-7: Identify 
> Invalid WHOIS POC's
> 
> Hi Ted,
> 
> 
> Ted Mittelstaedt wrote:
> > That is NOT what the policy proposal states.  Please re-read it.
> >
> > Nowhere in the policy proposal is ARIN staff directed to make a 
> > determination if a POC is completely and permanently abandoned or 
> > otherwise illegitimate AS A RESULT of a failure of the POC 
> to respond 
> > to e-mail.
> >
> > Instead, the directive to ARIN staff to determine if a POC is 
> > completely and permanently abandoned or otherwise illegitimate is 
> > open-ended.  The policy directs ARIN staff to make this 
> determination 
> > on an annual basis, period.  The policy also directs ARIN staff to 
> > mark unresponsive POC e-mail addresses in the WHOIS database on an 
> > annual basis.
> >
> > The proposal was CAREFULLY crafted to SPECIFICALY NOT REQUIRE ARIN 
> > staff to make a validity determination based on the results 
> of e-mail.
> >
> > Obviously, since both of these are annual validations (ie:
> > POC validation and e-mail validation) there's synergy in doing them 
> > together at the same time - which is why the policy covers 
> them both.  
> > But you will see that the tie-in is not mandated if you re-read the 
> > policy.  (it may be strongly implied depending on your 
> interpretation 
> > of the policy proposal, of course.  My interpretation is that it IS 
> > strongly implied.  But, a lawyer would almost certainly 
> tell you that 
> > implied policy has no legal validity.)
> >
> >   
> >> ..
> >
> > Specifying contact methods in the policy proposal was tried 
> the last 
> > time this was introduced and it was widely objected by the list 
> > membership as unnecessary interference between policy and 
> operations.
> >
> > Lee, it seems one group on the list objects to the policy 
> as being too 
> > narrow, and another group objects to it as being not narrow 
> enough.  
> > (the group your in)  However, the group objecting to it being too 
> > narrow was making objections to things that were actually 
> present in 
> > that proposal.  Your group that's objecting to it as being 
> not narrow 
> > enough, are objecting to things that your reading into the policy, 
> > that technically aren't actually there.
> >
> > Ted
> >   
> 
> If you read my original email on the subject you'll see that 
> I proposed to simply directly staff to establish the validity 
> of a POC. period.
> Drop the email thing. Staff will obviously use email as a 
> first resort and escalate beyond that but why specify email 
> in the policy?

Because part of the policy is to update WHOIS with more
accurate data as to the validity of a POC e-mail address.

> (in other words, I'm in the other group, the 
> "too narrow")
> 
> But I still don't get the "why" of this. This seems to be a 
> lot of work(and money) and somewhat risky if a false positive 
> (false invalid) occurs. What's the purpose?
> 


Many IPv4 resources are tied up
not because they are advertised in dfz, but simply because there
are POC's that are tied to those resources.

You do understand that legacy resource holders
have NO onus on them to maintain accurate POC entries in WHOIS,
right?  If they haven't signed a legacy RSA - but there's
still a POC handle in WHOIS - that IPv4 resource is tied up
and unavailable for reassignment.

And it's probably VERY likely that some resources under RSA are
containing bogus WHOIS entries as well.  Large companies frequently
will have accounting departments who will pay bills year after year
and never bother to check if the service they are paying for is
still in use.

Currently we simply do NOT know if the amount of unused, stale-POC
legacy resources plus abandonded, stale-POC-but-still-paid-for
RSA numbering resources constitutes a significant pool of IPv4.

When IPv4 runout happens, there's going to be a number of governments
who will want to know if ARIN has IPv4 hidden away - it's just not
going to be acceptable to say "well, we might have some but we
don't know because we have been too lazy to bother pruning our
database"

This is why the proposal directs ARIN to report on this after grooming,
and to update WHOIS with email validity data.

Keep in mind that if you have a bogus entry in WHOIS that NON-email
verification is going to take several months.  They will have to make
a phone call and if the phone # is wrong they will have to send a
certified letter and if that is not responded to they probably will
have to send a second certified letter, if that is ignored they will
have to check dfz and see if any prefixes tied to the POC are being
advertised, then check with the advertiser to have them tell them
who is doing the advertising, then check with that group and ask
why they are advertising a prefix that doesn't belong to them per
the POC data.  If that entity starts arguing with ARIN that they
own the prefix, ARIN will demand supporting docs that will take time
to produce, etc. etc.

It might easily take upwards of a year before some of the legacy
prefixes that are currently being advertised, that have bogus POC
data on them, are verified by ARIN staff and POC data is then updated.
And, this is just the stuff that is NOT criminal.

In cases where it IS criminal, ie: where a spammer is hijacking an
abandoned IPv4 prefix they just found, then you can imagine that entity will
fight a war of delaying and stalling tactics with ARIN which will
push it out even longer.

SO what we will end up with this policy is the following:

a report from ARIN that lists the reclaimed prefixes, and the ones
"in dispute" ie: the ones where verification is pending.  Those will
be visible in WHOIS by the existence of a "bogus e-mail" mark on
the e-mail data in the POC.  We will know that a certain percentage
of the "verification pending" ones will turn out to be reclaimed,
and so based on that we will be able to make a pretty accurate estimate
of how much stale IPv4 is tied up in WHOIS.

And, once we know the amount of stale assignments in WHOIS, it is then
possible to judge the viability of all of the various "IPv4 reclamation"
schemes and see if it's worth spending money on them.

Why have ARIN spend a huge amount of time and effort and money trying
to reclaim IPv4 if it turns out that after we groom WHOIS that only
a small fraction of IPv4 allocations are bogus?  Conversely, if we find
that, say 50% of assigned IPv4 is abandonded or unverifable, then
we know that Ipv4 runout will be many years away.


Ted



From jcurran at istaff.org  Wed Mar 25 21:23:34 2009
From: jcurran at istaff.org (John Curran)
Date: Wed, 25 Mar 2009 21:23:34 -0400
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using
	theEmergency PDP)
In-Reply-To: <20090326004858.GA29870@ussenterprise.ufp.org>
References: <49C911A8.5020009@arin.net>
	<997BC128AE961E4A8B880CD7442D94800A6977DC@NJCHLEXCMB01.cable.comcast.com>
	<20090325202524.GA18907@ussenterprise.ufp.org>
	<27921168-6E53-46BF-B0EA-EDEED4259AE9@istaff.org>
	<20090326004858.GA29870@ussenterprise.ufp.org>
Message-ID: <FDDD3C6C-9A4C-4F45-A612-60C20074C04C@istaff.org>

On Mar 25, 2009, at 8:48 PM, Leo Bicknell wrote:
> Was the emergency the Board's own making because they failed to
> raise this issue in a timely fashion?

More than a year ago, once it was apparent that reclamation lacked
material support in the community, the ARIN Board asked the AC to
consider transfer policies that would encourage the reuse of address
space that would otherwise lay fallow.  This is because of ARIN's
mission to encourage efficient utilization of these scarce resources.
Providing some form of direction on how this would occur based on the
community's input and doing so well before we approach depletion has
been a top priority for the organization, as clarity is necessary in
order for any approach to be effective in encouraging reutilization.

The AC deliberations on this matter went on for some time, and while
they finally resulted in a transfer policy, it was not clear that
reutilization would occur as a result nor that it was reasonable for
the ARIN Board to send it back to the AC for further deliberations
on the sunset provision given the lengthy history that the transfer
policy experienced therein.

Did the Board act in a timely manner?  In my personal opinion,
the Board has been quite timely and also patient with the AC's
deliberations.  It is true that 2009-1 effectively calls the
Sunset provision into question, and one hopes that will result
in dialogue about why such a provision so important so that the
Board, per the emergency policy process, can weigh that and the
AC recommendations in its decision.

/John

[personal views only, as the Board has not reviewed nor
  approved this message]




From matthew at matthew.at  Wed Mar 25 22:16:55 2009
From: matthew at matthew.at (Matthew Kaufman)
Date: Wed, 25 Mar 2009 19:16:55 -0700
Subject: [arin-ppml] Draft Policy 2009-1: Transfer
	Policy	(UsingtheEmergencyPDP)
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AF1F@mail>
References: <49C911A8.5020009@arin.net>	<997BC128AE961E4A8B880CD7442D94800A6977DC@NJCHLEXCMB01.cable.comcast.com>	<EACF8B735E9CBA4B8BAF9E4165D030878AB1B6@ex1.cait.wustl.edu>	<70DE64CEFD6E9A4EB7FAF3A06314106601B4AF1B@mail>	<4607e1d50903251521s2c5e8474r1df930282e9518b8@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4AF1F@mail>
Message-ID: <49CAE597.6040802@matthew.at>

Kevin Kargel wrote:
> If IP addresses become property they will end up going to the highest
> bidder.  This will drive the cost of IP addresses to the maximum that the
> market will bear.  That cost will be passed to the consumer.  This hurts the
> community.
>   
And the post-runout alternative you propose is...?

No matter how bad the future where IP addresses can be traded for money 
(which is already the case without the policy... big ISPs in need of 
address space will acquire other whole or spun-off entities that hold 
address space in order to reuse it), the future where IP addresses are 
unavailable and *not even the highest bidder* can get them is worse.

Unless you have a solution I'm not thinking of where the nice friendly 
Internet community can still get all the IPv4 space it needs to last 
through a transition that is starting too late to be done before runout.

Matthew Kaufman


From michael.dillon at bt.com  Thu Mar 26 05:11:34 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Thu, 26 Mar 2009 09:11:34 -0000
Subject: [arin-ppml] Draft Policy 2009-1:
	TransferPolicy	(UsingtheEmergencyPDP)
In-Reply-To: <49CAE597.6040802@matthew.at>
Message-ID: <28E139F46D45AF49A31950F88C4974584C7CED@E03MVZ2-UKDY.domain1.systemhost.net>

> the future where IP addresses are unavailable and *not 
> even the highest bidder* can get them is worse.

The science fiction list is over that way.

Here, in the real world, we have plentiful cheap IPv6 addresses
for anyone who wants them. Leading organizations such as Google
have already tried these IPv6 addresses and discovered that they
taste great, like a good address should.

What would you rather have, an intractable policy problem in how
to allocate a fixed pool of scarce addresses, or a technical problem
in how to make IPv6 and IPv4 networks intercommunicate?

--Michael Dillon


From Lee at dilkie.com  Thu Mar 26 07:18:29 2009
From: Lee at dilkie.com (Lee Dilkie)
Date: Thu, 26 Mar 2009 07:18:29 -0400
Subject: [arin-ppml] Draft Policy 2008-7: Identify Invalid WHOIS POC's
In-Reply-To: <B115B9DE963A47349839D9C54E839D49@tedsdesk>
References: <1f08e8ae3c9c4f4bb0e002f1a1a40c20@mail.dessus.com><62630D01-343C-4E9D-AA83-E6A9ED8478F4@delong.com>	<49C8C942.80601@dilkie.com>	<3E32C91B19244A0D977F953C8BD36871@tedsdesk>	<49C94026.3090203@sprunk.org>
	<51DF79F575B84402A4F04FA1A527E354@tedsdesk>
	<49C98C08.2030500@dilkie.com>
	<9E0414D1A1BC4E87933E65A41BF92751@tedsdesk>
	<49CAB80F.1020106@dilkie.com>
	<B115B9DE963A47349839D9C54E839D49@tedsdesk>
Message-ID: <49CB6485.2010100@dilkie.com>


Ted Mittelstaedt wrote:
> And, once we know the amount of stale assignments in WHOIS, it is then
> possible to judge the viability of all of the various "IPv4 reclamation"
> schemes and see if it's worth spending money on them.
>
> Why have ARIN spend a huge amount of time and effort and money trying
> to reclaim IPv4 if it turns out that after we groom WHOIS that only
> a small fraction of IPv4 allocations are bogus?  Conversely, if we find
> that, say 50% of assigned IPv4 is abandonded or unverifable, then
> we know that Ipv4 runout will be many years away.
>
>
> Ted
>   
got it. Makes good sense.


From rmoore at fnsky.com  Thu Mar 26 11:02:55 2009
From: rmoore at fnsky.com (Rodgers Moore)
Date: Thu, 26 Mar 2009 11:02:55 -0400
Subject: [arin-ppml] Draft Policy 2008-7: Identify Invalid WHOIS POC's
In-Reply-To: <49CB6485.2010100@dilkie.com>
References: <1f08e8ae3c9c4f4bb0e002f1a1a40c20@mail.dessus.com><62630D01-343C-4E9D-AA83-E6A9ED8478F4@delong.com>	<49C8C942.80601@dilkie.com>	<3E32C91B19244A0D977F953C8BD36871@tedsdesk>	<49C94026.3090203@sprunk.org><51DF79F575B84402A4F04FA1A527E354@tedsdesk><49C98C08.2030500@dilkie.com><9E0414D1A1BC4E87933E65A41BF92751@tedsdesk><49CAB80F.1020106@dilkie.com><B115B9DE963A47349839D9C54E839D49@tedsdesk>
	<49CB6485.2010100@dilkie.com>
Message-ID: <8B7449CB7F52FB4B82A01890152D00980100F37D@ex2003isc.interspacecomputers.com>

I'm a newbie here, so I've missed a lot of discussion.  This has
probably already been covered.

We have a built in keep alive in the system.  The renewal fee.  Change
it from annual to quarterly for IPv4.  Or are the new policies to weed
out stale delegations?

Rodgers Moore, CCIE# 8153

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Lee Dilkie
Sent: Thursday, March 26, 2009 7:18 AM
To: Ted Mittelstaedt
Cc: 'ARIN PPML'
Subject: Re: [arin-ppml] Draft Policy 2008-7: Identify Invalid WHOIS
POC's


Ted Mittelstaedt wrote:
> And, once we know the amount of stale assignments in WHOIS, it is then
> possible to judge the viability of all of the various "IPv4
reclamation"
> schemes and see if it's worth spending money on them.
>
> Why have ARIN spend a huge amount of time and effort and money trying
> to reclaim IPv4 if it turns out that after we groom WHOIS that only
> a small fraction of IPv4 allocations are bogus?  Conversely, if we
find
> that, say 50% of assigned IPv4 is abandonded or unverifable, then
> we know that Ipv4 runout will be many years away.
>
>
> Ted
>   
got it. Makes good sense.
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Rodgers Moore.vcf
Type: text/x-vcard
Size: 465 bytes
Desc: Rodgers Moore.vcf
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090326/7f337358/attachment.vcf>

From kkargel at polartel.com  Thu Mar 26 11:13:18 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Thu, 26 Mar 2009 10:13:18 -0500
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using
	theEmergency PDP)
In-Reply-To: <6DBC350E-C58F-49B5-950E-266F668BDA5D@istaff.org>
References: <49C911A8.5020009@arin.net><997BC128AE961E4A8B880CD7442D94800A6977DC@NJCHLEXCMB01.cable.comcast.com>
	<6DBC350E-C58F-49B5-950E-266F668BDA5D@istaff.org>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AF23@mail>


> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of John Curran
> Sent: Wednesday, March 25, 2009 6:16 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using
> theEmergency PDP)
> 
> All -
> 
>     As noted in Daniel's message, the material change made to the
>     transfer policy by the ARIN Board is removal of the 3 year
>     sunset clause.  It was the consensus of the Board that this did
>     not materially improve the usefulness of the 2008-6, created
>     uncertainty for the community, and most importantly represented
>     a dangerous precedent of time-based expirations of policy clauses.
> 
>     At present, the Board has one tool at its disposal for timely
>     modification of policy language, and that is use of the emergency
>     policy process.  The Board has already indicated the urgent need
>     for a transfer policy and due to the timeliness of the situation,

What urgent need for a transfer policy?  Why does this keep getting restated
as though it is established fact.  I have not seen a community consensus
that there is a need for a transfer policy.  There are a few vocal
individuals that voice the need for a transfer policy until some accept it
as fact.  

There is no need for a transfer policy.  We have a policy for reassignment
of IP blocks.  We do not need a new policy unless the goal is to make profit
from the transfer.

Kevin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090326/45637037/attachment.bin>

From farmer at umn.edu  Thu Mar 26 11:49:35 2009
From: farmer at umn.edu (David Farmer)
Date: Thu, 26 Mar 2009 10:49:35 -0500
Subject: [arin-ppml] Draft Policy 2008-7: Identify Invalid WHOIS POC's
In-Reply-To: <8B7449CB7F52FB4B82A01890152D00980100F37D@ex2003isc.interspacecomputers.com>
References: <1f08e8ae3c9c4f4bb0e002f1a1a40c20@mail.dessus.com>,
	<49CB6485.2010100@dilkie.com>,
	<8B7449CB7F52FB4B82A01890152D00980100F37D@ex2003isc.interspacecomputers.com>
Message-ID: <49CB5DBF.11109.8859E81@farmer.umn.edu>

On 26 Mar 2009 Rodgers Moore wrote:

> I'm a newbie here, so I've missed a lot of discussion.  This has
> probably already been covered.
> 
> We have a built in keep alive in the system.  The renewal fee.  Change
> it from annual to quarterly for IPv4.  Or are the new policies to weed
> out stale delegations?

That is exactly the issue, to get at stale delegations, and stale 
POCs are a good first sign of a stale delegation.  A stale POC 
doesn't necessarily directly imply a stale delegation, but 
looking for stale POCs is about the only practical method to 
find stale delegations.  And, the potential side effects of 
updating stale POCs on valid delegations is probablly a good 
side effect anyway.

Currently most Legacy holders don't have an annual renewal 
fee or process, this will change with more adoption of the 
LRSA.  However, in realiaty all of ARIN's renual fees are 
relatively small and may be automatically paid by an 
accountant, who knows nothing about the actuall needs and 
use of IP addresses.  Even $18,000 for a XL allocation isn't 
that much money for an organization that would justify it.

The fact the bill gets paid, may only really mean there is a vaild 
billing contact, and nothing else.  But, if the accountant, gets 
an email, phone call, or letter, asking about other invalid 
contact informaiton, I expect that will usually be shifted off to 
someone who actaully knows something about the IP 
addresses.

 > Rodgers Moore, CCIE# 8153
> 
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
> On Behalf Of Lee Dilkie Sent: Thursday, March 26, 2009 7:18 AM To: Ted
> Mittelstaedt Cc: 'ARIN PPML' Subject: Re: [arin-ppml] Draft Policy
> 2008-7: Identify Invalid WHOIS POC's
> 
> 
> Ted Mittelstaedt wrote:
> > And, once we know the amount of stale assignments in WHOIS, it is
> > then possible to judge the viability of all of the various "IPv4
> reclamation"
> > schemes and see if it's worth spending money on them.
> >
> > Why have ARIN spend a huge amount of time and effort and money
> > trying to reclaim IPv4 if it turns out that after we groom WHOIS
> > that only a small fraction of IPv4 allocations are bogus? 
> > Conversely, if we
> find
> > that, say 50% of assigned IPv4 is abandonded or unverifable, then we
> > know that Ipv4 runout will be many years away.
> >
> >
> > Ted
> >   
> got it. Makes good sense.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 



================================================
=======
David Farmer				     Email:	
farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota			     Phone:	612-626-
0815
2218 University Ave SE			     Cell:		
612-812-9952
Minneapolis, MN 55414-3029		     FAX:	612-626-
1818
================================================
=======



From sweeny at indiana.edu  Thu Mar 26 12:48:20 2009
From: sweeny at indiana.edu (Brent Sweeny)
Date: Thu, 26 Mar 2009 12:48:20 -0400
Subject: [arin-ppml] ARIN-PPML Digest, Vol 45, Issue 36
In-Reply-To: <mailman.1492.1238080095.11304.arin-ppml@arin.net>
References: <mailman.1492.1238080095.11304.arin-ppml@arin.net>
Message-ID: <49CBB1D4.2000709@indiana.edu>

it occurred to me, on reading Ted's note excerpted below, that so identifying
IPv4 blocks that ARIN believes but can't yet prove are abandoned is a
wonderful invitation to hijackers--increasing the likelihood of one thing
you're trying to prevent, while working on another goal of disputable value
which is coattailed to a goal of undisputed value.  I believe it's fine to
clean up WHOIS data, and even trying to scrape up every last dreg of
available v4 space is useful, but it's not going to stem the tide of runout,
nor will the small relief it offers arrive in time.
  Brent Sweeny, Indiana University

Ted Mittelstaedt <tedm at ipinc.net> wrote on 25 Mar 2009 17:51:11
| SO what we will end up with this policy is the following:
|
| a report from ARIN that lists the reclaimed prefixes, and the ones
| "in dispute" ie: the ones where verification is pending.  Those will
| be visible in WHOIS by the existence of a "bogus e-mail" mark on
| the e-mail data in the POC.  We will know that a certain percentage
| of the "verification pending" ones will turn out to be reclaimed,
| and so based on that we will be able to make a pretty accurate estimate
| of how much stale IPv4 is tied up in WHOIS.


From Lee at Dilkie.com  Thu Mar 26 13:15:50 2009
From: Lee at Dilkie.com (Lee Dilkie)
Date: Thu, 26 Mar 2009 13:15:50 -0400
Subject: [arin-ppml] Draft Policy 2008-7: Identify Invalid WHOIS POC's
In-Reply-To: <8B7449CB7F52FB4B82A01890152D00980100F37D@ex2003isc.interspacecomputers.com>
References: <1f08e8ae3c9c4f4bb0e002f1a1a40c20@mail.dessus.com><62630D01-343C-4E9D-AA83-E6A9ED8478F4@delong.com>	<49C8C942.80601@dilkie.com>	<3E32C91B19244A0D977F953C8BD36871@tedsdesk>	<49C94026.3090203@sprunk.org><51DF79F575B84402A4F04FA1A527E354@tedsdesk><49C98C08.2030500@dilkie.com><9E0414D1A1BC4E87933E65A41BF92751@tedsdesk><49CAB80F.1020106@dilkie.com><B115B9DE963A47349839D9C54E839D49@tedsdesk>	<49CB6485.2010100@dilkie.com>
	<8B7449CB7F52FB4B82A01890152D00980100F37D@ex2003isc.interspacecomputers.com>
Message-ID: <49CBB846.7010601@Dilkie.com>

Hi Rodgers,

This sort of indirectly aimed at the legacy holders (myself included).
They don't have any fees.

But regardless, you don't renew your POC, which is what this policy is
all about. You renew your numbered resource (which points at various POCs).

What Ted's trying to do here is find out which legacy numbered resources
(networks) have no valid POCs so it can be determined how many legacy
networks are abandoned.

-lee

Rodgers Moore wrote:
> I'm a newbie here, so I've missed a lot of discussion.  This has
> probably already been covered.
>
> We have a built in keep alive in the system.  The renewal fee.  Change
> it from annual to quarterly for IPv4.  Or are the new policies to weed
> out stale delegations?
>
> Rodgers Moore, CCIE# 8153
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Lee Dilkie
> Sent: Thursday, March 26, 2009 7:18 AM
> To: Ted Mittelstaedt
> Cc: 'ARIN PPML'
> Subject: Re: [arin-ppml] Draft Policy 2008-7: Identify Invalid WHOIS
> POC's
>
>
> Ted Mittelstaedt wrote:
>   
>> And, once we know the amount of stale assignments in WHOIS, it is then
>> possible to judge the viability of all of the various "IPv4
>>     
> reclamation"
>   
>> schemes and see if it's worth spending money on them.
>>
>> Why have ARIN spend a huge amount of time and effort and money trying
>> to reclaim IPv4 if it turns out that after we groom WHOIS that only
>> a small fraction of IPv4 allocations are bogus?  Conversely, if we
>>     
> find
>   
>> that, say 50% of assigned IPv4 is abandonded or unverifable, then
>> we know that Ipv4 runout will be many years away.
>>
>>
>> Ted
>>   
>>     
> got it. Makes good sense.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>   
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From spiffnolee at yahoo.com  Thu Mar 26 13:21:38 2009
From: spiffnolee at yahoo.com (Lee Howard)
Date: Thu, 26 Mar 2009 10:21:38 -0700 (PDT)
Subject: [arin-ppml] Approval of board meeting minutes (was re: 2009-1)
Message-ID: <487746.67766.qm@web63305.mail.re1.yahoo.com>


----- Original Message ----

> From: Leo Bicknell <bicknell at ufp.org>
> To: Lee Howard <spiffnolee at yahoo.com>
> Sent: Wednesday, March 25, 2009 5:26:25 PM
> Subject: Re: [arin-ppml] Approval of board meeting minutes (was re: 2009-1)
> 
> 
> So.....will we get a copy of the minutes before the April 7th
> deadline to comment on 2009-1 or not?

Sorry.
March 18 (+2 day turnaround for Secretary review) + 10 < April 7
Yes.

But the entire text of the draft proposal is already available for comment.

Lee




> In a message written on Wed, Mar 25, 2009 at 05:10:46PM -0700, Lee Howard wrote:
> > 
> > Ted said: 
> > > It has been 2 business days since this happened, surely that is
> > > enough time for the Board to post it's explanation by now.
> > 
> > As Secretary, I will point out that our Bylaws 
> > https://www.arin.net/about_us/corp_docs/bylaws.html  require us 
> > to post meeting minutes, following an approval procedure that is 
> > publicly available: 
> https://www.arin.net/about_us/boardguidelines.html#approval  
> > That procedure says we give Board members 10 days to review 
> > minutes before publishing them.  This helps to make sure we have 
> > accurate minutes.  The minutes of the March 18 meeting have 
> > been  sent to the Board for approval.  
> > 
> > We also require notice be given to Board members before a meeting
> > [Bylaws], which makes it very difficult for the body to respond 
> > quickly to an email thread.
> > 
> > Lee
> > 
> > 
> >      
> > 
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> 
> -- 
>        Leo Bicknell - bicknell at ufp.org - CCIE 3440
>         PGP keys at http://www.ufp.org/~bicknell/


      



From matthew at matthew.at  Thu Mar 26 13:23:16 2009
From: matthew at matthew.at (Matthew Kaufman)
Date: Thu, 26 Mar 2009 10:23:16 -0700
Subject: [arin-ppml] Draft Policy
	2009-1:	TransferPolicy	(UsingtheEmergencyPDP)
In-Reply-To: <28E139F46D45AF49A31950F88C4974584C7CED@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C4974584C7CED@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <49CBBA04.1000002@matthew.at>

michael.dillon at bt.com wrote:
>> the future where IP addresses are unavailable and *not 
>> even the highest bidder* can get them is worse.
>>     
>
> The science fiction list is over that way.
>
> Here, in the real world, we have plentiful cheap IPv6 addresses
> for anyone who wants them. Leading organizations such as Google
> have already tried these IPv6 addresses and discovered that they
> taste great, like a good address should.
>
>   
You conveniently left out my "the IPv4 space it needs to last through a 
transition that is starting too late to be done before runout".

IPv6 is the future. Between now and that future, there will be 
organization that need IPv4 addresses in order to operate. Some of that 
demand will occur after the runout.
> What would you rather have, an intractable policy problem in how
> to allocate a fixed pool of scarce addresses, or a technical problem
> in how to make IPv6 and IPv4 networks intercommunicate?
>   
I have yet to see a technical solution to IPv4-IPv6 interworking that 
doesn't require any IPv4 addresses during the transition. And I refuse 
to believe that when IPv4 addresses are no longer available from RIRs 
that entrepreneurs will grind to a halt and no longer fund, build, and 
grow businesses that have a need to talk to the existing IPv4 Internet.

Where does a hosted service that needs to deploy more servers to serve 
increased demand from existing IPv4 clients get IPv4 addresses from 
after the runout?

Where does an innovative new service that needs to deploy servers to 
serve customers who are only on the existing IPv4 Internet get IPv4 
addresses from after the runout?

Where does a new ISP that wants to deploy IPv6 to customers with an 
IPv6-IPv4 translation gateway to reach the legacy IPv4 Internet get IPv4 
addresses for the IPv4 side of that translation gateway after the runout?

The answer is that if there is money to be made in having those 
addresses then acquiring those addresses will be part of the capital 
expenditure required to start or grow one of those businesses. Yes, it 
will cost more than it does now, and so yes there will be business 
models for which that no longer makes sense... but there may very well 
be business models where the cost of getting a few more IPv4 addresses 
to continue growing, high as it might be, is lower than the cost of 
*not* having the addresses.

I have two significant issues with people who are completely opposed to 
a transfer policy:

1) The idea that things have worked well so far with the friendly 
cooperative addresses-are-nearly-free model we have now and so we should 
keep things as-is.

The problem is that the world we must plan for is not the world we 
inhabit today. *There is no "as-is" after the runout.* The world we must 
plan for is one where IPv6 addresses are as available as IPv4 addresses 
are today, but IPv4 addresses are *no longer easy to come by*. And I 
believe that because the transition is starting as late as it is and 
going as slow as it is with an new protocol that is as poorly suited to 
a smooth migration as IPv6 is there *will undoubtedly be a continuing 
need for both existing and new organizations to get a limited number of 
IPv4 addresses*.

2) The idea that if we don't have a transfer policy then transfers won't 
happen.

Existing entities which need more IPv4 space in order to continue 
operating and/or growing, or new entities which need even small amounts 
of IPv4 space in order to exist at all (imagine, for instance, a new ISP 
serving a previously unserved region which needs IPv4 addresses for that 
side of their IPv6-IPv4 gateway) *will* find a way to get these 
addresses if there is economic value in doing so. They will purchase 
existing entities which have underutilized space, they will ask entities 
with space to spin off subsidiaries or lease address space to them, etc. 
All of this is more legally complicated, and thus more costly in lawyer 
time, than just being able to transfer the address space. That adds an 
unnecessary transaction cost to solving the needs of the entities which 
need IPv4 addresses after the runout, and so that is *even worse* than a 
clean transfer policy would be, as far as increasing the cost to the 
acquiring entity goes.


Of course there are folks for whom the lack of a clean and simple 
transfer policy is a win: the lawyers who will orchestrate the 
more-complex transfers that will happen anyway, and the people with 
existing IPv4 services who want as big a barrier to new entrants as 
possible.

Matthew Kaufman




From owen at delong.com  Thu Mar 26 13:20:08 2009
From: owen at delong.com (Owen DeLong)
Date: Thu, 26 Mar 2009 10:20:08 -0700
Subject: [arin-ppml] ARIN-PPML Digest, Vol 45, Issue 36
In-Reply-To: <49CBB1D4.2000709@indiana.edu>
References: <mailman.1492.1238080095.11304.arin-ppml@arin.net>
	<49CBB1D4.2000709@indiana.edu>
Message-ID: <DF066668-B765-4947-B046-B1633446370B@delong.com>

I believe that clearly identifying these blocks in whois so that
organizations that choose to can consider that information in
filtering policy will do more to prevent abuse than to encourage
it.

Owen

On Mar 26, 2009, at 9:48 AM, Brent Sweeny wrote:

> it occurred to me, on reading Ted's note excerpted below, that so  
> identifying
> IPv4 blocks that ARIN believes but can't yet prove are abandoned is a
> wonderful invitation to hijackers--increasing the likelihood of one  
> thing
> you're trying to prevent, while working on another goal of  
> disputable value
> which is coattailed to a goal of undisputed value.  I believe it's  
> fine to
> clean up WHOIS data, and even trying to scrape up every last dreg of
> available v4 space is useful, but it's not going to stem the tide of  
> runout,
> nor will the small relief it offers arrive in time.
>  Brent Sweeny, Indiana University
>
> Ted Mittelstaedt <tedm at ipinc.net> wrote on 25 Mar 2009 17:51:11
> | SO what we will end up with this policy is the following:
> |
> | a report from ARIN that lists the reclaimed prefixes, and the ones
> | "in dispute" ie: the ones where verification is pending.  Those will
> | be visible in WHOIS by the existence of a "bogus e-mail" mark on
> | the e-mail data in the POC.  We will know that a certain percentage
> | of the "verification pending" ones will turn out to be reclaimed,
> | and so based on that we will be able to make a pretty accurate  
> estimate
> | of how much stale IPv4 is tied up in WHOIS.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From kkargel at polartel.com  Thu Mar 26 13:35:51 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Thu, 26 Mar 2009 12:35:51 -0500
Subject: [arin-ppml] Draft
	Policy2009-1:	TransferPolicy	(UsingtheEmergencyPDP)
In-Reply-To: <49CBBA04.1000002@matthew.at>
References: <28E139F46D45AF49A31950F88C4974584C7CED@E03MVZ2-UKDY.domain1.systemhost.net>
	<49CBBA04.1000002@matthew.at>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AF29@mail>


> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Matthew Kaufman
> Sent: Thursday, March 26, 2009 12:23 PM
> To: michael.dillon at bt.com
> Cc: ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy2009-1: TransferPolicy
> (UsingtheEmergencyPDP)
> 
> You conveniently left out my "the IPv4 space it needs to last through a
> transition that is starting too late to be done before runout".

Then complete the transition *before* IPv4 runout.

> Where does a hosted service that needs to deploy more servers to serve
> increased demand from existing IPv4 clients get IPv4 addresses from
> after the runout?

Umm , did you just ask where to get more stuff when there is no more stuff?
The answer is you don't.

> 
> Where does an innovative new service that needs to deploy servers to
> serve customers who are only on the existing IPv4 Internet get IPv4
> addresses from after the runout?

See above.  Shouldn't innovative new services be using ipv6?

> 
> Where does a new ISP that wants to deploy IPv6 to customers with an
> IPv6-IPv4 translation gateway to reach the legacy IPv4 Internet get IPv4
> addresses for the IPv4 side of that translation gateway after the runout?
> 
> The answer is that if there is money to be made in having those
> addresses then acquiring those addresses will be part of the capital
> expenditure required to start or grow one of those businesses. Yes, it
> will cost more than it does now, and so yes there will be business
> models for which that no longer makes sense... but there may very well
> be business models where the cost of getting a few more IPv4 addresses
> to continue growing, high as it might be, is lower than the cost of
> *not* having the addresses.

I see lots of questions describing problems of how to continue to use a
technology that is unavailable.  Face it, IPv4 is a finite resource, when it
runs out it runs out.  

> 
> I have two significant issues with people who are completely opposed to
> a transfer policy:
> 
> 1) The idea that things have worked well so far with the friendly
> cooperative addresses-are-nearly-free model we have now and so we should
> keep things as-is.
> 
> The problem is that the world we must plan for is not the world we
> inhabit today. *There is no "as-is" after the runout.* The world we must
> plan for is one where IPv6 addresses are as available as IPv4 addresses
> are today, but IPv4 addresses are *no longer easy to come by*. And I
> believe that because the transition is starting as late as it is and
> going as slow as it is with an new protocol that is as poorly suited to
> a smooth migration as IPv6 is there *will undoubtedly be a continuing
> need for both existing and new organizations to get a limited number of
> IPv4 addresses*.

So why can't people go back to ARIN and get more IP addresses?  If they are
available for transfer they are available for recycling.  If they cannot be
returned then they can't be transferred either.  

> 
> 2) The idea that if we don't have a transfer policy then transfers won't
> happen.
> 
> Existing entities which need more IPv4 space in order to continue
> operating and/or growing, or new entities which need even small amounts
> of IPv4 space in order to exist at all (imagine, for instance, a new ISP
> serving a previously unserved region which needs IPv4 addresses for that
> side of their IPv6-IPv4 gateway) *will* find a way to get these
> addresses if there is economic value in doing so. They will purchase
> existing entities which have underutilized space, they will ask entities
> with space to spin off subsidiaries or lease address space to them, etc.
> All of this is more legally complicated, and thus more costly in lawyer
> time, than just being able to transfer the address space. That adds an
> unnecessary transaction cost to solving the needs of the entities which
> need IPv4 addresses after the runout, and so that is *even worse* than a
> clean transfer policy would be, as far as increasing the cost to the
> acquiring entity goes.

So we are back to "if it's going to happen anyway we might as well legalize
it" option.  Pshaw, come up with a better argument.

I still maintain that creating an IP market will increase the cost of
internet to the point that it will be unaffordable by many if not most.  You
may be willing to sacrifice that section of society but I am not.  

Go ahead and screw the little guys, the heck with the end users, keep
supporting big business.  It will come back to haunt you.

> 
> 
> Of course there are folks for whom the lack of a clean and simple
> transfer policy is a win: the lawyers who will orchestrate the
> more-complex transfers that will happen anyway, and the people with
> existing IPv4 services who want as big a barrier to new entrants as
> possible.
> 
> Matthew Kaufman
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090326/add7d1b1/attachment.bin>

From kkargel at polartel.com  Thu Mar 26 13:36:57 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Thu, 26 Mar 2009 12:36:57 -0500
Subject: [arin-ppml] ARIN-PPML Digest, Vol 45, Issue 36
In-Reply-To: <DF066668-B765-4947-B046-B1633446370B@delong.com>
References: <mailman.1492.1238080095.11304.arin-ppml@arin.net><49CBB1D4.2000709@indiana.edu>
	<DF066668-B765-4947-B046-B1633446370B@delong.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AF2A@mail>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Owen DeLong
> Sent: Thursday, March 26, 2009 12:20 PM
> To: Brent Sweeny
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 45, Issue 36
> 
> I believe that clearly identifying these blocks in whois so that
> organizations that choose to can consider that information in
> filtering policy will do more to prevent abuse than to encourage
> it.
> 
> Owen
> 

I completely support Owen's statement.  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090326/3f0fc97b/attachment.bin>

From kkargel at polartel.com  Thu Mar 26 13:47:37 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Thu, 26 Mar 2009 12:47:37 -0500
Subject: [arin-ppml] Draft
	Policy2009-1:	TransferPolicy	(UsingtheEmergencyPDP)
In-Reply-To: <49CBBA04.1000002@matthew.at>
References: <28E139F46D45AF49A31950F88C4974584C7CED@E03MVZ2-UKDY.domain1.systemhost.net>
	<49CBBA04.1000002@matthew.at>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AF2B@mail>




> michael.dillon at bt.com wrote:
> I have two significant issues with people who are completely opposed to
> a transfer policy:
> 
Those of us who are diametrically opposed to a transfer policy have that
position because it is just a bad idea.  I have gone on at length as to why
it is a bad idea, and see no need to do so again.

When an idea is flawed at it's core it doesn't matter how you sugar coat it,
what angle you look at it from, what rationalization you come up with for
it, at the core it is still a bad idea.

If someone is going to poke you in the eye with a big stick it would be a
bad idea.  It doesn't change if they wash the stick first so you don't get
an infection, it doesn't change if they smear k-y jelly all over the stick
first, it doesn't matter if someone else is going to do it if they don't, it
doesn't matter if someone else is also going to get a stick poked in their
eye too, it is still a bad idea.  


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090326/7458a0ce/attachment.bin>

From tedm at ipinc.net  Thu Mar 26 14:00:04 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Thu, 26 Mar 2009 11:00:04 -0700
Subject: [arin-ppml] ARIN-PPML Digest, Vol 45, Issue 36
In-Reply-To: <49CBB1D4.2000709@indiana.edu>
References: <mailman.1492.1238080095.11304.arin-ppml@arin.net>
	<49CBB1D4.2000709@indiana.edu>
Message-ID: <3A0057657F964986A159F1C5968C12F7@tedsdesk>


I had considered this as well and there's a catch
that will prevent this.

  I mentioned ARIN makes a report - but the policy proposal
actually states that it ONLY makes a report on ABANDONDED blocks.

  I am presuming that ARIN staff will setup some kind of internal
procedure where they take abandonded blocks and dump them back
into the free pool, then reassign them, since that is their charter.
Thus, the "list" of published abandonded blocks is no different than
the current list of "virgin" unassigned IPv4 (and IPv6)

  The blocks that ARIN believes but can't yet prove are abandonded
are only shown to the public via the WHOIS e-mail mark.  In other
words, ARIN need not provide a list of these.  They only just make a mod in
WHOIS to the e-mail address of suspect blocks then give us a summary
count of "in-process potentially abandonded" blocks.

  Thus, would-be hijackers would still have to iterate through
the -entire- IP range, and for each block they think is possibly
abandonded (ie: not currently being advertised, but still with a POC)
they would still have to query WHOIS.  And I think that WHOIS is already
setup to disallow high volume iterative queries to make it more difficult
for hijackers.

  Thus it's not really any additional help than what a hijacker
already has access to.

  As for the goal of disputable value, no offense but the real
problem isn't people like you who believe that the amount of available
IPv4 will only offer small relief.  The problem is the people out
there unconvinceable by IP mathematics - who simply won't believe
a logical proof that IPv4 reclamation is pointless because there's
not enough spare IPv4 out there.  They will only be convinced by
an actual census.

Just take a look for a moment at the controversy surrounding the
US Government's plans on using statistical estimation for certain
areas in the upcoming 2010 census.  You can argue until your blue
in the face that the census figures will vary by an insignificant
amount whether statistical estimation is used or not, with all
the mathmatical proofs available - but that isn't stopping the
Republicans from insisting on an actual person going and tapping
heads for the count.

   Unless a census/grooming/verification is done, we will have
this IPv4 reclamation pink elephant constantly dragging energy away
from us in every discussion of TCP/IP policy going forward.  Just
look at all the energy expended on IPv4 "transfer" and so on schemes.
Most focus on this list and on policy has been on IPv4, NOT on IPv6,
and we are heading to IPv6 lickety-split.  Let's get WHOIS cleaned up,
then we won't have this monkey sitting there on our back anymore.

Ted


> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Brent Sweeny
> Sent: Thursday, March 26, 2009 9:48 AM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 45, Issue 36
> 
> it occurred to me, on reading Ted's note excerpted below, 
> that so identifying
> IPv4 blocks that ARIN believes but can't yet prove are 
> abandoned is a wonderful invitation to hijackers--increasing 
> the likelihood of one thing you're trying to prevent, while 
> working on another goal of disputable value which is 
> coattailed to a goal of undisputed value.  I believe it's 
> fine to clean up WHOIS data, and even trying to scrape up 
> every last dreg of available v4 space is useful, but it's not 
> going to stem the tide of runout, nor will the small relief 
> it offers arrive in time.
>   Brent Sweeny, Indiana University
> 
> Ted Mittelstaedt <tedm at ipinc.net> wrote on 25 Mar 2009 17:51:11
> | SO what we will end up with this policy is the following:
> |
> | a report from ARIN that lists the reclaimed prefixes, and 
> the ones "in 
> | dispute" ie: the ones where verification is pending.  Those will be 
> | visible in WHOIS by the existence of a "bogus e-mail" mark on the 
> | e-mail data in the POC.  We will know that a certain 
> percentage of the 
> | "verification pending" ones will turn out to be reclaimed, and so 
> | based on that we will be able to make a pretty accurate estimate of 
> | how much stale IPv4 is tied up in WHOIS.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 



From matthew at matthew.at  Thu Mar 26 14:01:10 2009
From: matthew at matthew.at (Matthew Kaufman)
Date: Thu, 26 Mar 2009 11:01:10 -0700
Subject: [arin-ppml]
	Draft	Policy2009-1:	TransferPolicy	(UsingtheEmergencyPDP)
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AF29@mail>
References: <28E139F46D45AF49A31950F88C4974584C7CED@E03MVZ2-UKDY.domain1.systemhost.net>	<49CBBA04.1000002@matthew.at>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4AF29@mail>
Message-ID: <49CBC2E6.4030309@matthew.at>

Kevin Kargel wrote:
>> You conveniently left out my "the IPv4 space it needs to last through a
>> transition that is starting too late to be done before runout".
>>     
>
> Then complete the transition *before* IPv4 runout.
>
>   
Demonstrably not possible. Slowing IPv4 allocation sufficiently to not 
run out before transition completion would at this point have the same 
effect as immediate runout. Wishing the transition could happen faster 
won't help, either.
>> Where does a hosted service that needs to deploy more servers to serve
>> increased demand from existing IPv4 clients get IPv4 addresses from
>> after the runout?
>>     
>
> Umm , did you just ask where to get more stuff when there is no more stuff?
> The answer is you don't.
>
>   
No. You get it from people who have it but for whom it has much lower 
value than the value to you. They give it to you in exchange for enough 
money that the money is worth more to them than the addresses are.

Google isn't going to stop growing just because ARIN won't give them 
more addresses. They will go back and scavenge all the ones they have, 
they will get them from other RIRs until those RIRs are also out, they 
will assign additional value to potential acquisitions that have 
existing PI IPv4 space, especially if that space is underutilized, and 
they will acquire or lease address space as necessary from other 
entities that, with money applied, can find spare addresses to release.

This is a lot like how Sprint and Clearwire leased ITFS (now EBS) 
spectrum on 30-year leases from universities that didn't need all the 
instructional television channels they were licensed for. It gets the 
cash-strapped university a bunch of money to do other interesting new 
things, and it gets Sprint and Clearwire a bunch of spectrum that 
otherwise wasn't available. Good for everyone except little guys who 
didn't think to lease the spectrum first, or didn't have the cash to 
outbid Sprint or Clearwire... but then that's business, at least in this 
country, these days.
>> Where does an innovative new service that needs to deploy servers to
>> serve customers who are only on the existing IPv4 Internet get IPv4
>> addresses from after the runout?
>>     
>
> See above.  Shouldn't innovative new services be using ipv6?
>
>   
Innovative new services probably will be using IPv6. But they'll also 
want to serve the large pool of existing potential customers who are on 
IPv4 and who don't have access to an IPv4 to IPv6 proxy yet. So, at 
least for a while, there'll be a lot of value in having IPv4 addresses 
to reach these new services. Perhaps enough value to make it worthwhile 
to spend cash to convince someone else to part with, or at least lease, 
address space to the new entity.
>> Where does a new ISP that wants to deploy IPv6 to customers with an
>> IPv6-IPv4 translation gateway to reach the legacy IPv4 Internet get IPv4
>> addresses for the IPv4 side of that translation gateway after the runout?
>>
>> The answer is that if there is money to be made in having those
>> addresses then acquiring those addresses will be part of the capital
>> expenditure required to start or grow one of those businesses. Yes, it
>> will cost more than it does now, and so yes there will be business
>> models for which that no longer makes sense... but there may very well
>> be business models where the cost of getting a few more IPv4 addresses
>> to continue growing, high as it might be, is lower than the cost of
>> *not* having the addresses.
>>     
>
> I see lots of questions describing problems of how to continue to use a
> technology that is unavailable.  Face it, IPv4 is a finite resource, when it
> runs out it runs out.  
>
>   
There is a big difference between "new IPv4 address space is not 
available from RIR" and "the IPv4 Internet is shut down".

In between those two times, there is value to new entrants and growing 
entities in acquiring more IPv4 space. There is also value to failing 
entities and entities with more IPv4 space than they need for their own 
growth to NOT having IPv4 addresses... at least there would be, if for a 
reasonable transaction cost the addresses could be moved to the entities 
with need. As I point out, that can already happen with existing 
policy... this policy would just reduce the transaction cost.

So you're against reducing the transaction cost to those entities which 
might need additional IPv4 address space? I don't understand that 
position given your belief that "when they run out, they run out". If 
they've actually "run out" then new or growing entities won't have any 
reason to acquire addresses from existing entities with excess and so 
there won't be any transactions covered by this policy anyway!
>
>
> So why can't people go back to ARIN and get more IP addresses?  If they are
> available for transfer they are available for recycling.  If they cannot be
> returned then they can't be transferred either.  
>   
In our society, people often are more willing to part with things they 
are using if they are offered something else of value in exchange.

I could have put the motorcycle I've had in my garage out on the curb 
with a "free" sign on it. But I didn't. Instead I sold it on eBay for 
$3000. When you understand why, you'll understand why address space that 
isn't available for recycling might be available in trade for other 
things of value, like money.

(Among other things, as I've pointed out months ago, an IT department 
may find it much easier to justify the equipment needed for an IPv6 
transition if they can tell their management and/or shareholders that by 
reducing their need for IPv4 space they can recoup some of the 
transition cost by transferring those IPv4 addresses for entities which 
have figured out that the monetary value of getting more IPv4 space is 
non-zero.)
>
>
> So we are back to "if it's going to happen anyway we might as well legalize
> it" option.  Pshaw, come up with a better argument.
>
> I still maintain that creating an IP market will increase the cost of
> internet to the point that it will be unaffordable by many if not most.  You
> may be willing to sacrifice that section of society but I am not.  
>   
I believe that a clean and simple transfer policy *decreases* the cost 
when the alternative is complex legal arrangements to make transfers fit 
into existing policy. That is why I am in favor of a transfer policy.

As you have pointed out, when we run out, we run out, and so it isn't 
like you can just go back to ARIN and get more IPv4 for free.

And as I have pointed out, there is a reason why people are willing to 
sell things on eBay that they aren't willing to take to the local recycler.

> Go ahead and screw the little guys, the heck with the end users, keep
> supporting big business.  It will come back to haunt you.
>
>   
Again, big business can afford the lawyers to do the transfer "the hard 
way". Passing a cleaner and simpler policy helps the smaller guys by 
reducing the transaction cost.

I'm not going to be the one who floats a proposal wherein ARIN forcibly 
takes back all the IPv4 space from everyone, including legacy holders, 
and then redistributes it based on need as determined by committee. But 
that's really the alternative to capitalism's solution to the problem 
that *will come*, wishful thinking or not.

Matthew Kaufman





From spiffnolee at yahoo.com  Thu Mar 26 14:12:08 2009
From: spiffnolee at yahoo.com (Lee Howard)
Date: Thu, 26 Mar 2009 11:12:08 -0700 (PDT)
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using the
	Emergency PDP)
Message-ID: <829182.10675.qm@web63307.mail.re1.yahoo.com>



As a Board member, I have some insight into the process by which the 
emergency draft policy was submitted to the community.  However, I am
not willing to discuss the Board's deliberations without checking with my
fellow Board members; I'm afraid of mischaracterizing their positions.  I
do have my own opinions, which I will share, but I have an open mind, 
and it can be changed by well-reasoned argument or correction of my
faulty memory.

The Board tries to stay out of policy matters, having created the Advisory
Council for that purpose.  Generally I am reluctant to advocate for or 
against potential policies.  In this case, there's a policy gap, where 
numbers could be better allocated as needed, per ARIN's mission.


----- Original Message ----
> From: Leo Bicknell <bicknell at ufp.org>
> To: arin-ppml at arin.net
> Sent: Wednesday, March 25, 2009 4:54:33 PM
> Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using the Emergency PDP)
> 
> In a message written on Wed, Mar 25, 2009 at 07:15:32PM -0400, John Curran 
> wrote:
> >     As noted in Daniel's message, the material change made to the
> >     transfer policy by the ARIN Board is removal of the 3 year
> >     sunset clause.  It was the consensus of the Board that this did
> >     not materially improve the usefulness of the 2008-6, created
> >     uncertainty for the community, and most importantly represented
> >     a dangerous precedent of time-based expirations of policy clauses.
> 
> I find it difficult to understand how a well defined date creates
> uncertainty, 

Policy changes are changes.  
The economic ramifications of this particular policy are such that changes
could be material.  

> However, you've managed to avoid addressing the largest issue.  If
> this was such a problem that the Board could not pass a policy with
> a time-based expiration and there was an "emergency need" to get
> this right why was the Board in whole or as individuals unable to
> articulate this problem at the last meeting, on PPML, or in a private
> briefing to the AC?  

I wasn't at the last meeting, for really good personal reasons.  

I don't like to advocate for or against potential policies; I want to 
know what the community thinks without prejudicing the process.
I don't know what information was provided to the AC, because
I want to believe you guys can make sausage without my bit of tripe.


> Given the proximity of the ARIN XXIII meeting I think it would be
> irresponsible for the Board to take any action on this policy prior
> to it being discussed in a public forum.  To implement a policy a
> few weeks prior to a face to face meeting would be a slap in the
> face to the community.  Unfortunately as far as I can tell the
> process at this point requires the AC and the Board to move on the
> policy prior to the face to face meeting.

I acknowledge your concerns about the process followed.  

The process now is for ten days of review on PPML.  I would like
for the AC to hear more comments on the substance of the proposal, 
noting that the sunset clause is not the only difference from 2008-6.

Following that review, the AC will review and make a 
recommendation to  the Board of Trustees.  I look forward to that
recommendation.  

If the Board ultimately adopts, the policy is automatically up for 
review at the next meeting.  If the Board were to defer 
consideration until after the meeting, it could be in a position to
adopt the policy I will oppose implementing the policy
prior to the meeting, because the possibility of having a transfer 
policy in place for only two weeks is fraught.  However, I do
believe the Board should not wait until after the meeting to
adopt, because that would put the policy in place until the Fall
meeting, which would be unfair.


I disagree that the Board has lacked transparency.
We sent text to the Public Policy Mailing List for public consideration.
The AC should facilitate that thoughtful deliberation.


Lee


      



From tedm at ipinc.net  Thu Mar 26 14:36:22 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Thu, 26 Mar 2009 11:36:22 -0700
Subject: [arin-ppml] Draft
	Policy2009-1:	TransferPolicy	(UsingtheEmergencyPDP)
In-Reply-To: <49CBBA04.1000002@matthew.at>
References: <28E139F46D45AF49A31950F88C4974584C7CED@E03MVZ2-UKDY.domain1.systemhost.net>
	<49CBBA04.1000002@matthew.at>
Message-ID: <89941169CAF946E0ADB40BAD181B4A41@tedsdesk>

 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Matthew Kaufman
> Sent: Thursday, March 26, 2009 10:23 AM
> To: michael.dillon at bt.com
> Cc: ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy2009-1: TransferPolicy 
> (UsingtheEmergencyPDP)
> 
> michael.dillon at bt.com wrote:
> >> the future where IP addresses are unavailable and *not even the 
> >> highest bidder* can get them is worse.
> >>     
> >
> > The science fiction list is over that way.
> >
> > Here, in the real world, we have plentiful cheap IPv6 addresses for 
> > anyone who wants them. Leading organizations such as Google have 
> > already tried these IPv6 addresses and discovered that they taste 
> > great, like a good address should.
> >
> >   
> You conveniently left out my "the IPv4 space it needs to last 
> through a transition that is starting too late to be done 
> before runout".
> 
> IPv6 is the future. Between now and that future, there will 
> be organization that need IPv4 addresses in order to operate. 
> Some of that demand will occur after the runout.
> > What would you rather have, an intractable policy problem in how to 
> > allocate a fixed pool of scarce addresses, or a technical 
> problem in 
> > how to make IPv6 and IPv4 networks intercommunicate?
> >   
> I have yet to see a technical solution to IPv4-IPv6 
> interworking that doesn't require any IPv4 addresses during 
> the transition. And I refuse to believe that when IPv4 
> addresses are no longer available from RIRs that 
> entrepreneurs will grind to a halt and no longer fund, build, 
> and grow businesses that have a need to talk to the existing 
> IPv4 Internet.
> 

Plenty of ISP's (like the one I work for) will have IPv4
available to be able to allow us to offer IPv6<->IPv4 gateway
products.  We will self-generate that IPv4 from our own stock
when we move our customers off IPv4 and on to IPv6.  So those
entrepreneurs who are growing businesses that need to talk
to the legacy IPv4 Internet will be able to contract with companies
like ours to be able to do it.

In any case, your assuming the entrepreneurs will shoulder the
burden of connecting their IPv6 offerings to the IPv4 Internet.
While some may, I think your going to see very rapidly the onus
will be on the IPv4 users to shoulder the burden to connect to the
IPv6 Internet.  It's those users who will become the primary
purchasers of IPv4<->IPv6 gateway services, and likely, most
of those gateway services will be offered by their own ISP
and perhaps included in their access cost.

> 
> I have two significant issues with people who are completely 
> opposed to a transfer policy:
> 
> 1) The idea that things have worked well so far with the 
> friendly cooperative addresses-are-nearly-free model we have 
> now and so we should keep things as-is.
> 
> The problem is that the world we must plan for is not the 
> world we inhabit today. *There is no "as-is" after the 
> runout.* The world we must plan for is one where IPv6 
> addresses are as available as IPv4 addresses are today, but 
> IPv4 addresses are *no longer easy to come by*. And I believe 
> that because the transition is starting as late as it is and 
> going as slow as it is with an new protocol that is as poorly 
> suited to a smooth migration as IPv6 is there *will 
> undoubtedly be a continuing need for both existing and new 
> organizations to get a limited number of
> IPv4 addresses*.
> 

Then I would suggest that those organizations with such a need
go out now and get connected and get their IPv4 while it's still
available.

When IPv4 runs out, new orgs will not be able to go -anywhere- and
get it.  They will have to use IPv6 since they will have no choice.
So they will revamp their network to require as few IPv4 as possible
then go to a gateway provider and buy access to the IPv4 Internet.

I didn't say they would like it.  The people being told they have to
junk their TV's or get HDTV converter boxes don't like it either.  But,
in technology, the stick-in-the-mud people don't have the power to
stop change, at least, not at the current time.  They did a millennium
ago, and so we got people like Galileo being beaten into the mud.

> 2) The idea that if we don't have a transfer policy then 
> transfers won't happen.
> 
> Existing entities which need more IPv4 space in order to 
> continue operating and/or growing, or new entities which need 
> even small amounts of IPv4 space in order to exist at all 
> (imagine, for instance, a new ISP serving a previously 
> unserved region which needs IPv4 addresses for that side of 
> their IPv6-IPv4 gateway) *will* find a way to get these 
> addresses if there is economic value in doing so. They will 
> purchase existing entities which have underutilized space, 
> they will ask entities with space to spin off subsidiaries or 
> lease address space to them, etc. 
> All of this is more legally complicated, and thus more costly 
> in lawyer time, than just being able to transfer the address 
> space. That adds an unnecessary transaction cost to solving 
> the needs of the entities which need IPv4 addresses after the 
> runout, and so that is *even worse* than a clean transfer 
> policy would be, as far as increasing the cost to the 
> acquiring entity goes.
> 

And the downside of this is?  We WANT it to be difficult to
get IPv4 in a post-IPv4-runout world.  If it was still easy,
people would never switch until the very last drop of oil I
mean IPv4 was sucked up - then -everyone- would hit the brick
wall.

> 
> Of course there are folks for whom the lack of a clean and 
> simple transfer policy is a win: the lawyers who will 
> orchestrate the more-complex transfers that will happen 
> anyway, and the people with existing IPv4 services who want 
> as big a barrier to new entrants as possible.
> 

You put your biggest concern last.

Sure, the orgs involved now who have IPv4 will be at an advantage
over the newcomers.  This is EXACTLY LIKE the ISP's out there
who are legacy holders who AREN'T PAYING A CENT for their IP
numbering, while the newer ISPs who got their assignments after
ARIN are paying a lot of money.

What about all the brand-new ISP's who since they are building
networks from scratch, get to go out and buy cheap hardware
for a 10th of the cost of the expensive gear that
the older ISP's are still amortizing?  Or the newer ISP's who
started after DSL who don't support dialup AT ALL and only offer
DSL, and have much smaller support costs?

Ted



From farmer at umn.edu  Thu Mar 26 14:43:40 2009
From: farmer at umn.edu (David Farmer)
Date: Thu, 26 Mar 2009 13:43:40 -0500
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using the
	Emergency PDP)
In-Reply-To: <49C911A8.5020009@arin.net>
References: <49C911A8.5020009@arin.net>
Message-ID: <49CB868C.17074.9250208@farmer.umn.edu>

I'm one of the AC shepards too, and I would like to try to start some 
discussion of the policy text itself.  Others have and are handling the 
questions around the process issues.  I'm not trying to diminish those 
process issues, I really do think there are serious questions and issues there.  
But, personally I have little to add to that discussion.

However, given the limited time frame on Emergency PDP actions, I want to 
make sure we don't forget to discuss the actual policy text.

So far the only comments about the text itself have been;
 
1. Martin Hannigan made some good comments about the language in 8.1, 
requiring a POC to notify ARIN

For details, see his message dated: 
Tue, 24 Mar 2009 17:34:08 -0400 

2. Other comments about the removal of the 3 year sunset clause, however 
this may be inextricably linked with the process issues I spoke about above, 
so I'm going to leave that alone and let others continue that part of the 
thread.

So what else is there related to the text itself;

1. 2008-6 included the following language, "Number resources may only be 
received under RSA", and I don't see that anywhere in the 2009-1 language. 

John Curran side in the another email "the material change made to the 
transfer policy by the ARIN Board is removal of the 3 year sunset clause."  

If you assume that all resources assigned through the NPRM are covered by 
the RSA then I might agree this is not a "material change" but I would like to 
confirm that interpretation or better understand why this is not included in the 
text of 2009-1.

2. Within 2008-6 the title of section 8.4 was "Emergency Transfer Policy for 
IPv4 Addresses".  In my opinion this title explicitly limited the transfers, other 
than by Mergers and Acquisitions to IPv4 resources only.  In 2009-1 the title 
of 8.3 is "Transfers to Specified Recipients" and doesn't otherwise include 
any specific language to limit this to IPv4 resources only.  Therefore, I must 
conclude this would include IPv6 and ASN resource too.  If this is actually 
the Board's intent, in my opinion this far exceeds the community's intent in 
2008-6 and is definitely another "material change".

Furthermore, if the Board intended this to include IPv6 and ANS resources, 
then why keep the Mergers and Acquisitions section?  I would think the 
Transfers to Specified Recipients section would easily cover that situation, if 
it was intended to cover more that IPv4 resources.

Personally, I like the new title, but either the title needs to include a limitation 
to IPv4 resources or the limitation needs to be in the text of the section.  
Without limitation to IPv4 resource, I think this is a show stopper.

3. Are there parts of 2008-2 the community would want back in without the 
original 3 year sunset clause of 2008-6? 

Personally, I have to think about this one a little more.

Are there any other comments on the text itself?

On 24 Mar 2009 Member Services wrote:

> Draft Policy 2009-1
> Transfer Policy
> 
> The ARIN Board of Trustees has declared a policy emergency and is
> making use of the Emergency PDP provision in the ARIN Policy
> Development Process to revise policy.
> 
> At their meeting on 6 February 2009 the ARIN Board of Trustees, based
> on the recommendation of the ARIN Advisory Council and noting that the
> Policy Development Process had been followed, adopted Draft Policy
> 2008-6: Emergency Transfer Policy for IPv4 Addresses.
> 
> Then at their meeting on 8 March 2009, the Board noted there is a gap
> in the transfer policy that limits the availability of IPv4 address
> space at a time when otherwise available IPv4 address space will
> become scarce, and declared this gap an emergency. The Board initiated
> the Emergency PDP of the Policy Development Process in order to revise
> the transfer policy (both the existing transfer policy and the policy
> just adopted).
> 
> Per the Emergency PDP, the draft policy below is being posted to the
> Public Policy Mailing List for 10 business days of discussion and
> review by the community. The emergency discussion period ends 7 April
> 2009. Within 5 business days of the end of discussion the Advisory
> Council will, having reviewed the comments on the list, review the
> draft policy and make a recommendation to the Board of Trustees. The
> Board may adopt or reject the draft policy. If the Board adopts the
> policy, it will be presented at the next public policy meeting for
> reconsideration.
> 
> We encourage you to discuss Draft Policy 2009-1 on the PPML. The
> discussion on the list will be used by the AC to determine the
> community consensus regarding adopting this as policy.
> 
> Draft Policy 2009-1: Transfer Policy is available below and at:
> https://www.arin.net/policy/proposals/2009_1.html
> 
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
> 
> Policy 2008-6: Emergency Transfer Policy for IPv4 Addresses can be
> found at: https://www.arin.net/policy/proposals/2008_6.html
> 
> Regards,
> 
> Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> ## * ##
> 
> 
> Draft Policy 2009-1
> Transfer Policy
> 
> Originator: ARIN Board of Trustees (using the Emergency PDP provision
> in the ARIN Policy Development Process)
> 
> Date: 24 March 2009
> 
> Policy statement:
> 
> Insert into the ARIN Number Resource Policy Manual as follows:
> 
> Add Section 2.8:
> 
> "Organization. An Organization is one or more legal entities under
> common control or ownership."
> 
> Replace Section 8 as follows:
> 
> 8. Transfers
> 
> 8.1. Principles
> 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. Mergers and Acquisitions
> ARIN will consider requests for the transfer of number resources in
> the case of mergers and acquisitions 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:
> 
> o Existing customer base
> o Qualified hardware inventory
> o Specific software requirements.
> 
> 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:
> 
> o An authenticated copy of the instrument(s) affecting the transfer of
> assets, e.g., bill of sale, certificate of merger, contract, deed, or
> court decree. o A detailed inventory of all assets utilized by the
> requesting party in maintaining and using the number resource. o 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:
> 
> o A general listing of the assets or components acquired
> o A specific description of acquisitions, including:
> 
> o Type and quantity of equipment
> o Customer base
> 
> o A description of how number resources are being utilized
> o Network engineering plans, including:
> 
> o Host counts
> o Subnet masking
> o Network diagrams
> o Reassignments to customers
> 
> 8.3 Transfers to Specified Recipients
> Number resources may be released, in whole or in part, to ARIN for
> transfer to another specified organizational recipient, by any
> authorized resource holder within the ARIN region. Such transferred
> number resources may only be received by organizations that are within
> the ARIN region and can demonstrate the need for such resources in the
> exact amount which they can justify under current ARIN policies.
> 
> #####
> 
> Notes:
> 
> Most of the existing Section 8 is left unchanged. List of changes:
> 
> 2.8 New.
> 8.1 Changes from "Transfers" to "Principles."
> 8.2 Changes from "Transfer Requirements" to "Mergers and
> Acquisitions." 8.2 The word "only" is removed. 8.3 Merged up into 8.2.
> 8.3 Edited version of the adopted 2008-6.
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



=======================================================
David Farmer				     Email:	farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota			     Phone:	612-626-0815
2218 University Ave SE			     Cell:		612-812-9952
Minneapolis, MN 55414-3029		     FAX:	612-626-1818
=======================================================



From tedm at ipinc.net  Thu Mar 26 15:31:53 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Thu, 26 Mar 2009 12:31:53 -0700
Subject: [arin-ppml]
	Draft	Policy2009-1:	TransferPolicy	(UsingtheEmergencyPDP)
In-Reply-To: <49CBC2E6.4030309@matthew.at>
References: <28E139F46D45AF49A31950F88C4974584C7CED@E03MVZ2-UKDY.domain1.systemhost.net>	<49CBBA04.1000002@matthew.at><70DE64CEFD6E9A4EB7FAF3A06314106601B4AF29@mail>
	<49CBC2E6.4030309@matthew.at>
Message-ID: <63F11843739A41D088F5933BF9934B74@tedsdesk>

 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Matthew Kaufman
> Sent: Thursday, March 26, 2009 11:01 AM
> To: Kevin Kargel
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml]Draft Policy2009-1: TransferPolicy 
> (UsingtheEmergencyPDP)
> 
> Kevin Kargel wrote:
> >> You conveniently left out my "the IPv4 space it needs to 
> last through 
> >> a transition that is starting too late to be done before runout".
> >>     
> >
> > Then complete the transition *before* IPv4 runout.
> >
> >   
> Demonstrably not possible. Slowing IPv4 allocation 
> sufficiently to not run out before transition completion 
> would at this point have the same effect as immediate runout. 
> Wishing the transition could happen faster won't help, either.
> >> Where does a hosted service that needs to deploy more servers to 
> >> serve increased demand from existing IPv4 clients get IPv4 
> addresses 
> >> from after the runout?
> >>     
> >
> > Umm , did you just ask where to get more stuff when there 
> is no more stuff?
> > The answer is you don't.
> >
> >   
> No. You get it from people who have it but for whom it has 
> much lower value than the value to you. They give it to you 
> in exchange for enough money that the money is worth more to 
> them than the addresses are.
> 
> Google isn't going to stop growing just because ARIN won't 
> give them more addresses. They will go back and scavenge all 
> the ones they have, they will get them from other RIRs until 
> those RIRs are also out, they will assign additional value to 
> potential acquisitions that have existing PI IPv4 space, 
> especially if that space is underutilized, and they will 
> acquire or lease address space as necessary from other 
> entities that, with money applied, can find spare addresses 
> to release.

www.google.com resolves to a grand total of 4 IP addresses in
a round robin.  FOUR that serve the -entire internet-

gmail.com has an MX that resolves to a total of 5 addresses that
are -different- than the ones www.google.com goes to.

Doncha think that if Google needed IP's they might consider that
SMTP and WWW run on DIFFERENT ports and simply use the SAME IP numbers
for their MX records and webservers?  YA THINK!!!

Granted this is simplistic to the point of rediculous - but it illustrates
the point that IPv4 utilization by Google is already inefficient from the
point
of conservation of IPv4.  Frankly I doubt you know anymore than
I do how Google's internal network is structured, but I'm sure
they are well aware of this upcoming problem and have a plan already
worked out and being followed.

> 
> This is a lot like how Sprint and Clearwire leased ITFS (now 
> EBS) spectrum on 30-year leases from universities that didn't 
> need all the instructional television channels they were 
> licensed for. It gets the cash-strapped university a bunch of 
> money to do other interesting new things, and it gets Sprint 
> and Clearwire a bunch of spectrum that otherwise wasn't 
> available. Good for everyone except little guys who didn't 
> think to lease the spectrum first, or didn't have the cash to 
> outbid Sprint or Clearwire... but then that's business, at 
> least in this country, these days.

That is not an apples-to-apples comparison.  RF spectrum and
land are analogous.  IPv4 is NOT analogous to either spectrum
or land.  If it was possible to completely replace the RF spectrum
with something different, Sprint and Clearwire wouldn't have
paid a cent to those universities.

> >> Where does an innovative new service that needs to deploy 
> servers to 
> >> serve customers who are only on the existing IPv4 Internet 
> get IPv4 
> >> addresses from after the runout?
> >>     
> >
> > See above.  Shouldn't innovative new services be using ipv6?
> >
> >   
> Innovative new services probably will be using IPv6. But 
> they'll also want to serve the large pool of existing 
> potential customers who are on
> IPv4 and who don't have access to an IPv4 to IPv6 proxy yet. 
> So, at least for a while, there'll be a lot of value in 
> having IPv4 addresses to reach these new services. Perhaps 
> enough value to make it worthwhile to spend cash to convince 
> someone else to part with, or at least lease, address space 
> to the new entity.
> >> Where does a new ISP that wants to deploy IPv6 to customers with an
> >> IPv6-IPv4 translation gateway to reach the legacy IPv4 
> Internet get 
> >> IPv4 addresses for the IPv4 side of that translation 
> gateway after the runout?
> >>
> >> The answer is that if there is money to be made in having those 
> >> addresses then acquiring those addresses will be part of 
> the capital 
> >> expenditure required to start or grow one of those 
> businesses. Yes, 
> >> it will cost more than it does now, and so yes there will 
> be business 
> >> models for which that no longer makes sense... but there may very 
> >> well be business models where the cost of getting a few more IPv4 
> >> addresses to continue growing, high as it might be, is 
> lower than the 
> >> cost of
> >> *not* having the addresses.
> >>     
> >
> > I see lots of questions describing problems of how to 
> continue to use 
> > a technology that is unavailable.  Face it, IPv4 is a 
> finite resource, 
> > when it runs out it runs out.
> >
> >   
> There is a big difference between "new IPv4 address space is 
> not available from RIR" and "the IPv4 Internet is shut down".
> 
> In between those two times, there is value to new entrants 
> and growing entities in acquiring more IPv4 space. There is 
> also value to failing entities and entities with more IPv4 
> space than they need for their own growth to NOT having IPv4 
> addresses... at least there would be, if for a reasonable 
> transaction cost the addresses could be moved to the entities 
> with need. As I point out, that can already happen with 
> existing policy... this policy would just reduce the transaction cost.
> 
> So you're against reducing the transaction cost to those 
> entities which might need additional IPv4 address space? I 
> don't understand that position given your belief that "when 
> they run out, they run out". If they've actually "run out" 
> then new or growing entities won't have any reason to acquire 
> addresses from existing entities with excess and so there 
> won't be any transactions covered by this policy anyway!

Nothing is preventing all these "new businesses" that supposedly
will need IPv4 from forming their own Internet and using IPv4 on it.
They can do that and number how they want.  Just don't expect to
connect that to us.

In the case of IPv4->Ipv6 transition, it's better for the majority
to get the IPv4->IPv6 transition executed as quickly as possible.
The faster that we switch everyone over, and the shorter that this
transition period takes, the less money that everyone
will have to spend supporting legacy stuff.

I don't have a problem with schemes that generate more assignable
IPv4 BEFORE arin runs out - I would prefer this be run through ARIN
of course - but the fact that it exists "for free" from ARIN pre-IPv4 runout
means that nobody "selling" IPv4 is going to make any money at all,
and thus there's no incentive to do it, and every incentive to
return it to ARIN and continue the existing assignment mechanism.

But once IPv4 runout is hit, the IPv4->IPv6 transition really will
commence for most people.  That is when it's going to hit the
general newspapers and such.  If people are told that well, IPv4
MIGHT be available if you get in a line at ARIN and wait long
enough, or it MIGHT be available if you go buy a company that
has an assignment, to them that means IPv4 is unavailable and they
will have incentive to switch themselves to IPv6.

By contrast, if people are told that IPv4 is still available it
is just going to cost more, to most people that is going to translate
to "I can forget about this IPv4 crisis and just go back to
watching Lost on TV" in short, to most people, it will mean IPv4
runout has not happened.

> >
> >
> > So why can't people go back to ARIN and get more IP addresses?  If 
> > they are available for transfer they are available for 
> recycling.  If 
> > they cannot be returned then they can't be transferred either.
> >   
> In our society, people often are more willing to part with 
> things they are using if they are offered something else of 
> value in exchange.
> 
> I could have put the motorcycle I've had in my garage out on 
> the curb with a "free" sign on it. But I didn't. Instead I 
> sold it on eBay for $3000. When you understand why, you'll 
> understand why address space that isn't available for 
> recycling might be available in trade for other things of 
> value, like money.
> 
> (Among other things, as I've pointed out months ago, an IT 
> department may find it much easier to justify the equipment 
> needed for an IPv6 transition if they can tell their 
> management and/or shareholders that by reducing their need 
> for IPv4 space they can recoup some of the transition cost by 
> transferring those IPv4 addresses for entities which have 
> figured out that the monetary value of getting more IPv4 space is
> non-zero.)

This presupposes that having your motorcycle once more back in
the hands of someone who will ride it, instead of rotting away
in your garage never being ridden, is beneficial to society.  I
think you would find a lot of people that would disagree with
anything that puts one more bike back on the street.

Keep in mind also that when you sold your bike, that someone out
there who wanted a bike DIDN'T go down to the Harley stealership
and buy a new one (I'm assuming your bike was a hog as nobody would
buy any other kind of used bike than a hog for that much money)

That means HD sold one less bike this year, thus made less money,
thus someone on an assembly line at HD didn't have any work, and
was laid off as a result.

Your sale was an action beneficial to you, NOT beneficial to the
majority.  It was tolerated by the majority because there's not
enough bike riders out there to go to the trouble of banning them.
But make no mistake about it, when the minority of bike riders
gets to be a problem, the majority reacts with stuff like helmet
laws, superbike limiting legislation, etc.

The fact is that post-IPv4 runout, it's more beneficial to the
majority for those IT departments to simply sit on their IPv4
holdings and NOT sell them - since this forces IPv6 adoption faster.
Obviously it's most beneficial if they convert to IPv6 and
walk away from those holdings.

But even if they don't get money for selling those holdings,
they pay less money to ARIN for IP holdings if they return them,
so they still financially benefit.

Ted



From michael.dillon at bt.com  Thu Mar 26 16:26:01 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Thu, 26 Mar 2009 20:26:01 -0000
Subject: [arin-ppml] Draft Policy
	2009-1:	TransferPolicy	(UsingtheEmergencyPDP)
In-Reply-To: <49CBBA04.1000002@matthew.at>
Message-ID: <28E139F46D45AF49A31950F88C497458523F17@E03MVZ2-UKDY.domain1.systemhost.net>

> I have yet to see a technical solution to IPv4-IPv6 
> interworking that doesn't require any IPv4 addresses during 
> the transition. And I refuse to believe that when IPv4 
> addresses are no longer available from RIRs that 
> entrepreneurs will grind to a halt and no longer fund, build, 
> and grow businesses that have a need to talk to the existing 
> IPv4 Internet.

Then you are not looking very far, or more likely, you are not a network
technical person and therefore feel no need to keep up to date on the
details of the technology. For at least ten years now we have had
interworking mechanisms that allow IPv6 networks to access the IPv4
Internet and vice versa. New ones are coming along all the time such as
6VPE. There are no magic bullets, but there are many ways of making
interworking function well enough to keep a network operator growing and
profitable.

> Where does a hosted service that needs to deploy more servers 
> to serve increased demand from existing IPv4 clients get IPv4 
> addresses from after the runout?

>From a 6to4 gateway or from some type of NAT box such as NAT-PT.

Why don't you do some of your own research. This information is not that
hard to find and pointers to much of it are on ARIN's IPv6 wiki at
http://getipv6.info

If you don't even know the fundamentals, then why are you in this
discussion?

--Michael Dillon


From michael.dillon at bt.com  Thu Mar 26 16:37:05 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Thu, 26 Mar 2009 20:37:05 -0000
Subject: [arin-ppml] Draft
	Policy2009-1:	TransferPolicy	(UsingtheEmergencyPDP)
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AF2B@mail>
Message-ID: <28E139F46D45AF49A31950F88C497458523F1D@E03MVZ2-UKDY.domain1.systemhost.net>

If you are going to quote Matthew Kaufman [matthew at matthew.at]
then please put his name at the top, not mine.

> > michael.dillon at bt.com wrote:
> > I have two significant issues with people who are 
> completely opposed 
> > to a transfer policy:
> > 
> Those of us who are diametrically opposed to a transfer 
> policy have that position because it is just a bad idea.  I 
> have gone on at length as to why it is a bad idea, and see no 
> need to do so again.

I happen to agree that all transfer policies are just plain
bad ideas, unneccesary, a waste of time, and so on. Part of 
my reasoning is that transfer policies will hurt small businesses
and only benefit large businesses or at most, a select few wealthy small
businesses. This rather conflicts with ARIN's recent policies for
various soft-landing tactics which all benefit small businesses as a
category at the expense of large businesses like my employer.

Of course, my employer benefits from a scenario in which those small
businesses can buy our services, and in various other ways due to the
network effect. So in reality, I'm just taking the longer view that
if someone has to take the hit, we can take it and survive because we,
and other large network operators, have already got enough IPv6 testing
and deployment done to know that we can make a business of it when the
day comes. We'd rather see this IPv4 shortage be as short as possible
and are taking action to make it so by gearing up for IPv6. Early trials
are very promising.

--Michael Dillon


From matthew at matthew.at  Thu Mar 26 16:55:53 2009
From: matthew at matthew.at (Matthew Kaufman)
Date: Thu, 26 Mar 2009 13:55:53 -0700
Subject: [arin-ppml] Draft
	Policy	2009-1:	TransferPolicy	(UsingtheEmergencyPDP)
In-Reply-To: <28E139F46D45AF49A31950F88C497458523F17@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C497458523F17@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <49CBEBD9.3030808@matthew.at>

michael.dillon at bt.com wrote:
>
> Then you are not looking very far, or more likely, you are not a network
> technical person and therefore feel no need to keep up to date on the
> details of the technology. For at least ten years now we have had
> interworking mechanisms that allow IPv6 networks to access the IPv4
> Internet and vice versa. New ones are coming along all the time such as
> 6VPE. There are no magic bullets, but there are many ways of making
> interworking function well enough to keep a network operator growing and
> profitable.
>
>   
I am very much a "network technical person", but that is hardly relevant 
to the discussion.

There are interworking mechanisms under development, a few deployed, 
which allow IPv6-only hosts to access services that are exclusively on 
the IPv4 Internet. Because dual-stack was originally the primary 
solution to this problem, the early approaches are few and far between, 
though development has sped up significantly across several (probably 
too many) IETF WGs. But as previous posters have pointed out, IPv6 was 
very clearly not designed for interoperation with IPv4... instead it was 
designed as an all new Internet protocol, and sold on many features 
(automatic configuration, IPSEC, etc.) that were interesting enough that 
IPv4 got them anyway (and a few that still aren't going to happen, like 
ubiquitous worldwide IPv6 multicast), thus reducing the perceived value 
of IPv6. Now, of course, we have an emergency... IPv4 addresses will run 
out, and dual-stack doesn't solve that problem at all.

All methods that allow an IPv6 host to access the IPv4 address require 
somewhere between one IPv4 address at the gateway (e.g., NAT64) and one 
IPv4 address per host (dual stack). None work in the case of zero IPv4 
addresses available for the deployer of the gateway or host.

I do agree that an existing network operator with IPv4 space at their 
disposal will be able to use various techniques to continuing growing. 
Some operators (providers to consumer end-users) will have it easier 
than others (hosting of services that require unique IP addresses).

New entrants will be at a significant disadvantage in that there will be 
no PI space available from any RIR, so they will be limited to either 
getting IPv4 space (possibly overloaded via things like port-range 
sharing a la SHARA) from their ISP or acquiring IPv4 space either via 
the proposed transfer policy or via existing transfer mechanisms (buying 
existing holder entities).
>> Where does a hosted service that needs to deploy more servers 
>> to serve increased demand from existing IPv4 clients get IPv4 
>> addresses from after the runout?
>>     
>
> From a 6to4 gateway or from some type of NAT box such as NAT-PT.
>   
I don't think that's a viable solution. A service that needs to deploy a 
new unique IPv4 address to a host that is expected to be reachable from 
the legacy IPv4 Internet isn't going to be able to use a NAT device to 
synthesize that new address. Perhaps a NAT device would make it possible 
for that host to share an address with an existing host, but only if the 
port usage is compatible. (For example, deploying two entirely separate 
servers that respond on a well-known port isn't going to work)

> If you don't even know the fundamentals, then why are you in this
> discussion?
>   
I know the fundamentals, but even if I did not my opinion for or against 
a transfer policy is relevant as a holder of both legacy and ARIN RSA 
IPv4 space. Personal attacks are irrelevant, though if you knew my 
background regarding network protocol design and deployment and/or my 
background in ISP operations you might have just skipped them altogether.

Matthew Kaufman


From schnizlein at isoc.org  Thu Mar 26 16:42:54 2009
From: schnizlein at isoc.org (John Schnizlein)
Date: Thu, 26 Mar 2009 13:42:54 -0700
Subject: [arin-ppml] Draft Policy
	2009-1:	TransferPolicy	(UsingtheEmergencyPDP)
In-Reply-To: <28E139F46D45AF49A31950F88C497458523F17@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C497458523F17@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <6ACC5B6F-D8EE-4EB0-9001-F801525BC48F@isoc.org>

A minimal (but greater than this) level of comity would improve the  
quality of discussion of this contentious subject.  Please assume  
(even if it requires effort to suspend disbelief) that those with a  
different opinion are still competent.

John

On 2009Mar26, at 1:26 PM, <michael.dillon at bt.com> wrote:
>
> If you don't even know the fundamentals, then why are you in this
> discussion?



From owen at delong.com  Thu Mar 26 17:22:54 2009
From: owen at delong.com (Owen DeLong)
Date: Thu, 26 Mar 2009 14:22:54 -0700
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using the
	Emergency PDP)
In-Reply-To: <49CB868C.17074.9250208@farmer.umn.edu>
References: <49C911A8.5020009@arin.net> <49CB868C.17074.9250208@farmer.umn.edu>
Message-ID: <9B56A1A2-B1F5-4209-9B79-71B05DCC6053@delong.com>

>
> So what else is there related to the text itself;
>
> 1. 2008-6 included the following language, "Number resources may  
> only be
> received under RSA", and I don't see that anywhere in the 2009-1  
> language.
>
> John Curran side in the another email "the material change made to the
> transfer policy by the ARIN Board is removal of the 3 year sunset  
> clause."
>
The 2009-1 text requires the addresses to be returned by ARIN then  
issued
to the third party.  As such, I believe it is implicit that ARIN would  
require an
RSA from the third party prior to issuing the addresses to them.

> If you assume that all resources assigned through the NPRM are  
> covered by

> the RSA then I might agree this is not a "material change" but I  
> would like to
> confirm that interpretation or better understand why this is not  
> included in the
> text of 2009-1.
>
I don't think that the RSA facts change, but, I do think that direct  
transfers
recorded by ARIN vs. transfers through ARIN is a material change.  I am
not sure what the implications of such a change are, but, I am  
inclined to
believe that there is wisdom in having the transfers go through ARIN
instead of merely having ARIN record them.

> 2. Within 2008-6 the title of section 8.4 was "Emergency Transfer  
> Policy for
> IPv4 Addresses".  In my opinion this title explicitly limited the  
> transfers, other
> than by Mergers and Acquisitions to IPv4 resources only.  In 2009-1  
> the title
> of 8.3 is "Transfers to Specified Recipients" and doesn't otherwise  
> include
> any specific language to limit this to IPv4 resources only.   
> Therefore, I must
> conclude this would include IPv6 and ASN resource too.  If this is  
> actually
> the Board's intent, in my opinion this far exceeds the community's  
> intent in
> 2008-6 and is definitely another "material change".
>
This is a very material change and not for the better.
>
>
> 3. Are there parts of 2008-2 the community would want back in  
> without the
> original 3 year sunset clause of 2008-6?
>
Yes, but, I think there is a distinct lack of consensus around which  
parts.
I believe that is how we arrived at 2008-6 instead of 2008-2.

Owen



From tedm at ipinc.net  Thu Mar 26 17:51:39 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Thu, 26 Mar 2009 14:51:39 -0700
Subject: [arin-ppml]
	DraftPolicy	2009-1:	TransferPolicy	(UsingtheEmergencyPDP)
In-Reply-To: <49CBEBD9.3030808@matthew.at>
References: <28E139F46D45AF49A31950F88C497458523F17@E03MVZ2-UKDY.domain1.systemhost.net>
	<49CBEBD9.3030808@matthew.at>
Message-ID: <F5AD98B6764B4504AD86143DF8449FE8@tedsdesk>

 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Matthew Kaufman
> Sent: Thursday, March 26, 2009 1:56 PM
> To: michael.dillon at bt.com
> Cc: ppml at arin.net
> Subject: Re: [arin-ppml] DraftPolicy 2009-1: TransferPolicy 
> (UsingtheEmergencyPDP)
> 
> michael.dillon at bt.com wrote:
> >
> > Then you are not looking very far, or more likely, you are not a 
> > network technical person and therefore feel no need to keep 
> up to date 
> > on the details of the technology. For at least ten years 
> now we have 
> > had interworking mechanisms that allow IPv6 networks to access the 
> > IPv4 Internet and vice versa. New ones are coming along all 
> the time 
> > such as 6VPE. There are no magic bullets, but there are 
> many ways of 
> > making interworking function well enough to keep a network operator 
> > growing and profitable.
> >
> >   
> I am very much a "network technical person", but that is 
> hardly relevant to the discussion.
> 
> There are interworking mechanisms under development, a few 
> deployed, which allow IPv6-only hosts to access services that 
> are exclusively on the IPv4 Internet. Because dual-stack was 
> originally the primary solution to this problem, the early 
> approaches are few and far between, though development has 
> sped up significantly across several (probably too many) IETF 
> WGs. But as previous posters have pointed out, IPv6 was very 
> clearly not designed for interoperation with IPv4... instead 
> it was designed as an all new Internet protocol, and sold on 
> many features (automatic configuration, IPSEC, etc.) that 
> were interesting enough that
> IPv4 got them anyway (and a few that still aren't going to 
> happen, like ubiquitous worldwide IPv6 multicast), thus 
> reducing the perceived value of IPv6. Now, of course, we have 
> an emergency... IPv4 addresses will run out, and dual-stack 
> doesn't solve that problem at all.
> 
> All methods that allow an IPv6 host to access the IPv4 
> address require somewhere between one IPv4 address at the 
> gateway (e.g., NAT64) and one
> IPv4 address per host (dual stack). None work in the case of 
> zero IPv4 addresses available for the deployer of the gateway or host.
> 

There's lots and lots of service providers today with IPv4.  If
someone without IPv4 wants to get to an IPv4 network, they merely
pay a monthly access fee to the service provider that owns a 
gateway that goes between IPv6 and IPv4, and use IPv6 to get
to the service provider.

> I do agree that an existing network operator with IPv4 space 
> at their disposal will be able to use various techniques to 
> continuing growing. 
> Some operators (providers to consumer end-users) will have it 
> easier than others (hosting of services that require unique 
> IP addresses).
> 
> New entrants will be at a significant disadvantage in that 
> there will be no PI space available from any RIR, so they 
> will be limited to either getting IPv4 space (possibly 
> overloaded via things like port-range sharing a la SHARA) 
> from their ISP or acquiring IPv4 space either via the 
> proposed transfer policy or via existing transfer mechanisms 
> (buying existing holder entities).
> >> Where does a hosted service that needs to deploy more servers to 
> >> serve increased demand from existing IPv4 clients get IPv4 
> addresses 
> >> from after the runout?
> >>     
> >
> > From a 6to4 gateway or from some type of NAT box such as NAT-PT.
> >   
> I don't think that's a viable solution. A service that needs 
> to deploy a new unique IPv4 address to a host that is 
> expected to be reachable from the legacy IPv4 Internet isn't 
> going to be able to use a NAT device to synthesize that new 
> address. 

Customer wants to field a server with an IPv4 address on it FINE.
Nothing is stopping them from going to an IPv4 gateway provider
and getting a static IPv4 address, and tunneling from their
server to that provider over the IPv6 Internet.

They can use portable IPv6 space on their server and have 
as much redundancy to the gateway provider as they want.
The gateway provider can have as much redundancy as it wants
to the remains of the IPv4 Internet, whatever that will end
up being.

Ted



From schnizlein at isoc.org  Thu Mar 26 18:09:01 2009
From: schnizlein at isoc.org (John Schnizlein)
Date: Thu, 26 Mar 2009 15:09:01 -0700
Subject: [arin-ppml]
	DraftPolicy	2009-1:	TransferPolicy	(UsingtheEmergencyPDP)
In-Reply-To: <F5AD98B6764B4504AD86143DF8449FE8@tedsdesk>
References: <28E139F46D45AF49A31950F88C497458523F17@E03MVZ2-UKDY.domain1.systemhost.net>
	<49CBEBD9.3030808@matthew.at>
	<F5AD98B6764B4504AD86143DF8449FE8@tedsdesk>
Message-ID: <1CDB1C86-F2B6-44F4-AF0C-D497EE10EF48@isoc.org>

Are you actually saying you think that creating these tunnels, with  
the side effect of reliance on a third party for security and  
stability, not to mention the profit of the party providing service,  
is better for the Internet than transferring an address to the party  
that wants to reach the (legacy) IPv4-only hosts that will remain on  
the Internet for some time?

Really?

On 2009Mar26, at 2:51 PM, Ted Mittelstaedt wrote:

> Customer wants to field a server with an IPv4 address on it FINE.
> Nothing is stopping them from going to an IPv4 gateway provider
> and getting a static IPv4 address, and tunneling from their
> server to that provider over the IPv6 Internet.



From dwcarder at wisc.edu  Thu Mar 26 17:09:54 2009
From: dwcarder at wisc.edu (Dale W. Carder)
Date: Thu, 26 Mar 2009 16:09:54 -0500
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using the
 Emergency PDP)
In-Reply-To: <49CB868C.17074.9250208@farmer.umn.edu>
References: <49C911A8.5020009@arin.net> <49CB868C.17074.9250208@farmer.umn.edu>
Message-ID: <A5EF384C-8F90-48A7-8F20-B306BCF0D6F1@wisc.edu>


On Mar 26, 2009, at 1:43 PM, David Farmer wrote:
>
> 2. Within 2008-6 the title of section 8.4 was "Emergency Transfer  
> Policy for
> IPv4 Addresses".  In my opinion this title explicitly limited the  
> transfers, other
> than by Mergers and Acquisitions to IPv4 resources only.
[snip]
> Personally, I like the new title, but either the title needs to  
> include a limitation
> to IPv4 resources or the limitation needs to be in the text of the  
> section.
> Without limitation to IPv4 resource, I think this is a show stopper.

I believe the consensus was that it should exclusively apply
for IPv4 resources only.

I also can't find the emergency.

Dale




From farmer at umn.edu  Thu Mar 26 18:10:08 2009
From: farmer at umn.edu (David Farmer)
Date: Thu, 26 Mar 2009 17:10:08 -0500
Subject: [arin-ppml] Draft Policy 2009-1: TransferPolicy
	(UsingtheEmergencyPDP)
In-Reply-To: <49CBEBD9.3030808@matthew.at>
References: <28E139F46D45AF49A31950F88C497458523F17@E03MVZ2-UKDY.domain1.systemhost.net>,
	<49CBEBD9.3030808@matthew.at>
Message-ID: <49CBB6F0.12814.9E206E3@farmer.umn.edu>

On 26 Mar 2009 Matthew Kaufman wrote:
> 
> All methods that allow an IPv6 host to access the IPv4 address require
> somewhere between one IPv4 address at the gateway (e.g., NAT64) and
> one IPv4 address per host (dual stack). None work in the case of zero
> IPv4 addresses available for the deployer of the gateway or host.
> 
> I do agree that an existing network operator with IPv4 space at their
> disposal will be able to use various techniques to continuing growing.
> Some operators (providers to consumer end-users) will have it easier
> than others (hosting of services that require unique IP addresses).
> 
> New entrants will be at a significant disadvantage in that there will
> be no PI space available from any RIR, so they will be limited to
> either getting IPv4 space (possibly overloaded via things like
> port-range sharing a la SHARA) from their ISP or acquiring IPv4 space
> either via the proposed transfer policy or via existing transfer
> mechanisms (buying existing holder entities). 

I believe that 2008-5 should guarantee at least some PI IPv4 address space 
will be available within the ARIN region for IPv4 to IPv6 transition 
mechanisms.  I don't see why a new entrant with mostly only IPv6 address 
shouldn't be able to get at least some IPv4 space for transition mechanisms. 
On the face of it, that is the intent of 2008-5.  If you disagree, please explain 
why, and lets try to fix that.

https://www.arin.net/policy/proposals/2008_5.html

If in the long run IPv6 adoption fails, well then there really can't be any new 
entrants can there.  


=======================================================
David Farmer				     Email:	farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota			     Phone:	612-626-0815
2218 University Ave SE			     Cell:		612-812-9952
Minneapolis, MN 55414-3029		     FAX:	612-626-1818
=======================================================



From farmer at umn.edu  Thu Mar 26 18:27:00 2009
From: farmer at umn.edu (David Farmer)
Date: Thu, 26 Mar 2009 17:27:00 -0500
Subject: [arin-ppml] DraftPolicy 2009-1: TransferPolicy
	(UsingtheEmergencyPDP)
In-Reply-To: <1CDB1C86-F2B6-44F4-AF0C-D497EE10EF48@isoc.org>
References: <28E139F46D45AF49A31950F88C497458523F17@E03MVZ2-UKDY.domain1.systemhost.net>,
	<F5AD98B6764B4504AD86143DF8449FE8@tedsdesk>,
	<1CDB1C86-F2B6-44F4-AF0C-D497EE10EF48@isoc.org>
Message-ID: <49CBBAE4.25147.9F177B5@farmer.umn.edu>

On 26 Mar 2009 John Schnizlein wrote:

> Are you actually saying you think that creating these tunnels, with 
> the side effect of reliance on a third party for security and 
> stability, not to mention the profit of the party providing service, 
> is better for the Internet than transferring an address to the party 
> that wants to reach the (legacy) IPv4-only hosts that will remain on 
> the Internet for some time?
> 
> Really?

Yea, really, people do it everyday, it is call VPN.  It is not 
exactly the same thing, but not that different.  Today, 
especially with cheap high speed broadband, how many 
companies are connecting their remote offices with Internet 
VPN.  At the University of Minnesota we are, and we are even 
using globally accessible IPv4 addresses inside the encrypted 
tunnels.  

Today many people are implementing IPv6 inside of tunnels of 
one kind or another, 6to4, 6over4, 6PE, 6VPE, they are all 
tunnels over their dominant network technology, IPv4 or MPLS.  
People tunnel SNA and other legacy protocols inside IPv4 
today too.  

Why is it so hard to believe that some day we will tunnel the 
legacy protocol call IPv4 a dominate protocol called IPv6?

> On 2009Mar26, at 2:51 PM, Ted Mittelstaedt wrote:
> 
> > Customer wants to field a server with an IPv4 address on it FINE.
> > Nothing is stopping them from going to an IPv4 gateway provider and
> > getting a static IPv4 address, and tunneling from their server to
> > that provider over the IPv6 Internet.


================================================
=======
David Farmer				     Email:	
farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota			     Phone:	612-626-
0815
2218 University Ave SE			     Cell:		
612-812-9952
Minneapolis, MN 55414-3029		     FAX:	612-626-
1818
================================================
=======



From schnizlein at isoc.org  Thu Mar 26 18:04:06 2009
From: schnizlein at isoc.org (John Schnizlein)
Date: Thu, 26 Mar 2009 15:04:06 -0700
Subject: [arin-ppml] Draft
	Policy2009-1:	TransferPolicy	(UsingtheEmergencyPDP)
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AF29@mail>
References: <28E139F46D45AF49A31950F88C4974584C7CED@E03MVZ2-UKDY.domain1.systemhost.net>
	<49CBBA04.1000002@matthew.at>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4AF29@mail>
Message-ID: <B7CDCD59-372A-4CAB-87D7-7361217C6A6F@isoc.org>

Setting aside the distinction between creating a market for IPv4  
addresses, and accommodating the transfers that happen,  it seems that  
a little clarity of who bears what cost, and what the alternative to  
that cost is might be worthwhile.

Those who have IPv4 addresses when the free pools go empty would bear  
no cost created by a market.  If they convert some subset of their  
hosts from IPv4 to IPv6, they might be able to receive some  
compensation for the effort to release addresses.

Those who do not have IPv4 when the pools run dry would bear both the  
cost of addresses on the unauthorized market plus the cost of the risk  
that those addresses will be unreachable from parts of the Internet -  
or do without.

Who is harmed by this market?

John

On 2009Mar26, at 10:35 AM, Kevin Kargel wrote:

> I still maintain that creating an IP market will increase the cost of
> internet to the point that it will be unaffordable by many if not  
> most.  You
> may be willing to sacrifice that section of society but I am not.



From tedm at ipinc.net  Thu Mar 26 18:48:20 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Thu, 26 Mar 2009 15:48:20 -0700
Subject: [arin-ppml]
	DraftPolicy	2009-1:	TransferPolicy	(UsingtheEmergencyPDP)
In-Reply-To: <1CDB1C86-F2B6-44F4-AF0C-D497EE10EF48@isoc.org>
References: <28E139F46D45AF49A31950F88C497458523F17@E03MVZ2-UKDY.domain1.systemhost.net>
	<49CBEBD9.3030808@matthew.at>
	<F5AD98B6764B4504AD86143DF8449FE8@tedsdesk>
	<1CDB1C86-F2B6-44F4-AF0C-D497EE10EF48@isoc.org>
Message-ID: <42296E9423DD4DD2B4C5843159A29419@tedsdesk>


Yes.  Tunneling is and has always been a least-cost solution.

If they care that much about reliability they won't tunnel - they
will just get a T1 or other circuit to an ISP that will assign
them an IPv4 subnet.

Even the old "employee working from home on a VPN" scenario is
a least-cost solution.  For example, one of our customers has
a T1 to us where we have that circuit going to a private DSL
bridge, and from that bridge, DSL lines to all their key employees
locations.  Another customer runs a DSL line to their private DSL
bridge here.

When those employees sitting in their homes surf the web,
their traffic goes via DSL to the bridge in our NOC, then
to their company then out their company's
firewall then onward to their employers upstream Internet
feed - which as a matter of fact, isn't us.

You and I are both relying on a 3rd party to even have
this discussion at all - the 3rd party is the ppml list
itself.  And the ppml is relying on other parties to carry
traffic between us.  And those networks are probably
relying on cableline providers, not their own fiber.  And
so on and so on.

Welcome to the Internet!  This is the very ESSENSE of it.


Ted


> -----Original Message-----
> From: John Schnizlein [mailto:schnizlein at isoc.org] 
> Sent: Thursday, March 26, 2009 3:09 PM
> To: Ted Mittelstaedt
> Cc: matthew at matthew.at; ppml at arin.net
> Subject: Re: [arin-ppml] DraftPolicy 2009-1: TransferPolicy 
> (UsingtheEmergencyPDP)
> 
> Are you actually saying you think that creating these 
> tunnels, with the side effect of reliance on a third party 
> for security and stability, not to mention the profit of the 
> party providing service, is better for the Internet than 
> transferring an address to the party that wants to reach the 
> (legacy) IPv4-only hosts that will remain on the Internet for 
> some time?
> 
> Really?
> 
> On 2009Mar26, at 2:51 PM, Ted Mittelstaedt wrote:
> 
> > Customer wants to field a server with an IPv4 address on it FINE.
> > Nothing is stopping them from going to an IPv4 gateway provider and 
> > getting a static IPv4 address, and tunneling from their 
> server to that 
> > provider over the IPv6 Internet.
> 
> 



From bill at herrin.us  Thu Mar 26 19:03:53 2009
From: bill at herrin.us (William Herrin)
Date: Thu, 26 Mar 2009 19:03:53 -0400
Subject: [arin-ppml] ARIN-PPML Digest, Vol 45, Issue 36
In-Reply-To: <49CBB1D4.2000709@indiana.edu>
References: <mailman.1492.1238080095.11304.arin-ppml@arin.net>
	<49CBB1D4.2000709@indiana.edu>
Message-ID: <3c3e3fca0903261603s5c5c5709v7915aaa29f3ef203@mail.gmail.com>

On Thu, Mar 26, 2009 at 12:48 PM, Brent Sweeny <sweeny at indiana.edu> wrote:
> it occurred to me, on reading Ted's note excerpted below, that so identifying
> IPv4 blocks that ARIN believes but can't yet prove are abandoned is a
> wonderful invitation to hijackers

Brent,

You raise a reasonable point, but I would observe that hijackers don't
seem to have a great deal of trouble identifying abandoned blocks
without ARIN's investigation. If the block isn't in the global BGP
table and a test-spam to the POC bounces, it's a safe bet that block
is ripe for hijacking.

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From farmer at umn.edu  Thu Mar 26 19:30:39 2009
From: farmer at umn.edu (David Farmer)
Date: Thu, 26 Mar 2009 18:30:39 -0500
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using the
	Emergency PDP)
In-Reply-To: <9B56A1A2-B1F5-4209-9B79-71B05DCC6053@delong.com>
References: <49C911A8.5020009@arin.net>,
	<49CB868C.17074.9250208@farmer.umn.edu>,
	<9B56A1A2-B1F5-4209-9B79-71B05DCC6053@delong.com>
Message-ID: <49CBC9CF.9689.A2BBD9E@farmer.umn.edu>

On 26 Mar 2009 Owen DeLong wrote:

> On Mar 26, 2009, at 11:43 AM, David Farmer wrote:
> >
> > 3. Are there parts of 2008-2 the community would want back in 
> > without the original 3 year sunset clause of 2008-6?
> >
> Yes, but, I think there is a distinct lack of consensus around which 
> parts. I believe that is how we arrived at 2008-6 instead of 2008-2.

I agree, but I was hoping that maybe the actions of the Board 
and the limited time for comment might help focus the 
community on a consensus for one of or two of them. 

Like maybe;

- A releasing organization, can't recive IPv4 addresses in the 
subsequent 12 months

and;

- The receiving organization, can't have released IPv4 address 
in the preceeding 12 months





================================================
=======
David Farmer				     Email:	
farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota			     Phone:	612-626-
0815
2218 University Ave SE			     Cell:		
612-812-9952
Minneapolis, MN 55414-3029		     FAX:	612-626-
1818
================================================
=======



From heather.schiller at verizonbusiness.com  Thu Mar 26 19:19:20 2009
From: heather.schiller at verizonbusiness.com (Heather Schiller)
Date: Thu, 26 Mar 2009 19:19:20 -0400
Subject: [arin-ppml] Draft Policy 2008-7: Identify Invalid WHOIS POC's
In-Reply-To: <49CBB846.7010601@Dilkie.com>
References: <1f08e8ae3c9c4f4bb0e002f1a1a40c20@mail.dessus.com>
	<62630D01-343C-4E9D-AA83-E6A9ED8478F4@delong.com>
	<49C8C942.80601@dilkie.com>
	<3E32C91B19244A0D977F953C8BD36871@tedsdesk>
	<49C94026.3090203@sprunk.org>
	<51DF79F575B84402A4F04FA1A527E354@tedsdesk>
	<49C98C08.2030500@dilkie.com>
	<9E0414D1A1BC4E87933E65A41BF92751@tedsdesk>
	<49CAB80F.1020106@dilkie.com>
	<B115B9DE963A47349839D9C54E839D49@tedsdesk>
	<49CB6485.2010100@dilkie.com>
	<8B7449CB7F52FB4B82A01890152D00980100F37D@ex2003isc.interspacecomputers.com>
	<49CBB846.7010601@Dilkie.com>
Message-ID: <49CC0D78.5000208@verizonbusiness.com>


For clarification..

For folks who are billed.. you can keep paying your bill and have an 
invalid POC.

The billing POC and the whois resource POCs can be different - one can 
go stale without affecting the other.

--Heather

====================================================
  Heather Schiller	Verizon Business
  Customer Security	1.800.900.0241
  IP Address Management	help4u at verizonbusiness.com
=====================================================

Lee Dilkie wrote:
> Hi Rodgers,
> 
> This sort of indirectly aimed at the legacy holders (myself included).
> They don't have any fees.
> 
> But regardless, you don't renew your POC, which is what this policy is
> all about. You renew your numbered resource (which points at various POCs).
> 
> What Ted's trying to do here is find out which legacy numbered resources
> (networks) have no valid POCs so it can be determined how many legacy
> networks are abandoned.
> 
> -lee
> 
> Rodgers Moore wrote:
>> I'm a newbie here, so I've missed a lot of discussion.  This has
>> probably already been covered.
>>
>> We have a built in keep alive in the system.  The renewal fee.  Change
>> it from annual to quarterly for IPv4.  Or are the new policies to weed
>> out stale delegations?
>>
>> Rodgers Moore, CCIE# 8153
>>
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>> Behalf Of Lee Dilkie
>> Sent: Thursday, March 26, 2009 7:18 AM
>> To: Ted Mittelstaedt
>> Cc: 'ARIN PPML'
>> Subject: Re: [arin-ppml] Draft Policy 2008-7: Identify Invalid WHOIS
>> POC's
>>
>>
>> Ted Mittelstaedt wrote:
>>   
>>> And, once we know the amount of stale assignments in WHOIS, it is then
>>> possible to judge the viability of all of the various "IPv4
>>>     
>> reclamation"
>>   
>>> schemes and see if it's worth spending money on them.
>>>
>>> Why have ARIN spend a huge amount of time and effort and money trying
>>> to reclaim IPv4 if it turns out that after we groom WHOIS that only
>>> a small fraction of IPv4 allocations are bogus?  Conversely, if we
>>>     
>> find
>>   
>>> that, say 50% of assigned IPv4 is abandonded or unverifable, then
>>> we know that Ipv4 runout will be many years away.
>>>
>>>
>>> Ted
>>>   
>>>     
>> got it. Makes good sense.
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>   
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 




From woody at pch.net  Thu Mar 26 19:50:04 2009
From: woody at pch.net (Bill Woodcock)
Date: Thu, 26 Mar 2009 15:50:04 -0800 (PST)
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using the
 Emergency PDP)
In-Reply-To: <49CB868C.17074.9250208@farmer.umn.edu>
References: <49C911A8.5020009@arin.net> <49CB868C.17074.9250208@farmer.umn.edu>
Message-ID: <Pine.SOC.4.61.0903261534150.21454@paixhost.pch.net>

      On Thu, 26 Mar 2009, David Farmer wrote:
    > 2. Other comments about the removal of the 3 year sunset clause...

Every single sentence in the NRPM could have a sunset clause, doubling the 
size of the document and requiring that every part of it be constantly 
maintained.  Since the public _already has_ the capability to roll back 
any part of the NRPM at any time, or to override any previously-enacted 
sunset clause at any time, sunset clauses are no-ops.  

    > 1. 2008-6 included the following language, "Number resources may only be 
    > received under RSA", and I don't see that anywhere in the 2009-1 language. 

8.1, paragraph 2, among others.

ARIN does not give resources to organizations that do not sign an RSA.  
That doesn't need to be restated in every paragraph.

    > If you assume that all resources assigned through the NPRM are covered by 
    > the RSA then I might agree this is not a "material change."

Correct.

    > 2. Within 2008-6 the title of section 8.4 was "Emergency Transfer Policy for 
    > IPv4 Addresses".  2009-1 doesn't include any language to limit this 
    > to IPv4 resources only.

Is there a perceived problem there?  Is there a perceived need to 
transfer IPv6 addresses or ASNs?  If so, is that more problematic than 
IPv4 addresses?

    > If the Board intended this to include IPv6 and ANS resources, 
    > then why keep the Mergers and Acquisitions section?

That was indeed the subject of no little discussion, as I imagine 
you'll find when you read the meeting minutes.

                                -Bill



From scottleibrand at gmail.com  Thu Mar 26 19:54:38 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Thu, 26 Mar 2009 16:54:38 -0700
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using the
 Emergency PDP)
In-Reply-To: <Pine.SOC.4.61.0903261534150.21454@paixhost.pch.net>
References: <49C911A8.5020009@arin.net> <49CB868C.17074.9250208@farmer.umn.edu>
	<Pine.SOC.4.61.0903261534150.21454@paixhost.pch.net>
Message-ID: <49CC15BE.1080009@gmail.com>

Bill Woodcock wrote:
>     > 2. Within 2008-6 the title of section 8.4 was "Emergency Transfer Policy for 
>     > IPv4 Addresses".  2009-1 doesn't include any language to limit this 
>     > to IPv4 resources only.
>
> Is there a perceived problem there?  Is there a perceived need to 
> transfer IPv6 addresses or ASNs?  If so, is that more problematic than 
> IPv4 addresses?
>   

I heard a number of people express the opinion that we don't want to set 
a permanent precedent allowing transfers of IPv6 (and ASN).  Both 2008-2 
and 2008-6 were very explicit that transfers were only being allowed as 
a result of the extraordinary circumstance of IPv4 exhaustion, and that 
such transfers would not be allowed for any other type of number resource.

I believe it would be appropriate to restore such a limitation to 
section 8.3 of 2009-1.

-Scott


From kkargel at polartel.com  Thu Mar 26 20:31:48 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Thu, 26 Mar 2009 19:31:48 -0500
Subject: [arin-ppml] Draft
	Policy2009-1:	TransferPolicy	(UsingtheEmergencyPDP)
In-Reply-To: <B7CDCD59-372A-4CAB-87D7-7361217C6A6F@isoc.org>
References: <28E139F46D45AF49A31950F88C4974584C7CED@E03MVZ2-UKDY.domain1.systemhost.net>
	<49CBBA04.1000002@matthew.at>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4AF29@mail>
	<B7CDCD59-372A-4CAB-87D7-7361217C6A6F@isoc.org>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AF37@mail>






> -----Original Message-----
> From: John Schnizlein [mailto:schnizlein at isoc.org]
> Sent: Thursday, March 26, 2009 5:04 PM
> To: Kevin Kargel
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy2009-1: TransferPolicy
> (UsingtheEmergencyPDP)
> 
> Setting aside the distinction between creating a market for IPv4
> addresses, and accommodating the transfers that happen,  it seems that
> a little clarity of who bears what cost, and what the alternative to
> that cost is might be worthwhile.
> 
> Those who have IPv4 addresses when the free pools go empty would bear
> no cost created by a market.  If they convert some subset of their
> hosts from IPv4 to IPv6, they might be able to receive some
> compensation for the effort to release addresses.
> 
> Those who do not have IPv4 when the pools run dry would bear both the
> cost of addresses on the unauthorized market plus the cost of the risk
> that those addresses will be unreachable from parts of the Internet -
> or do without.
> 
> Who is harmed by this market?
> 
> John

We cannot put aside the distinction as you suggest.  Doing so is an attempt
to legitimize a bad idea.  All of this effort to hyperbolize by trying to
create hypothetical situations where a market is not harmful do not fly.  
A poke in the eye with a sharp stick is still harmful, even if you ask "But
hypothetically if you had super healing powers it wouldn't be so bad."

All of the customers of anyone who needs to get IP addresses from the market
will be harmed.  All of the cost will flow downhill until it reaches the end
user.  

Participants in an unauthorized market will not be able to artificially
raise their fees if they want to stay competitive with the companies who
obtained IP addresses legitimately.  This will be the limiter on the IP
black market.

Do not forget that there will be legitimate access to IPv6 addresses.  Once
IPv6 content becomes active IPv4 will fall more and more into disuse,
addresses will come available, and ultimately be relegated to the role of
curiosity or collectible.

> 
> On 2009Mar26, at 10:35 AM, Kevin Kargel wrote:
> 
> > I still maintain that creating an IP market will increase the cost of
> > internet to the point that it will be unaffordable by many if not
> > most.  You
> > may be willing to sacrifice that section of society but I am not.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090326/f51c3aed/attachment.bin>

From kkargel at polartel.com  Thu Mar 26 20:35:40 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Thu, 26 Mar 2009 19:35:40 -0500
Subject: [arin-ppml]
	DraftPolicy	2009-1:	TransferPolicy	(UsingtheEmergencyPDP)
In-Reply-To: <1CDB1C86-F2B6-44F4-AF0C-D497EE10EF48@isoc.org>
References: <28E139F46D45AF49A31950F88C497458523F17@E03MVZ2-UKDY.domain1.systemhost.net><49CBEBD9.3030808@matthew.at><F5AD98B6764B4504AD86143DF8449FE8@tedsdesk>
	<1CDB1C86-F2B6-44F4-AF0C-D497EE10EF48@isoc.org>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AF38@mail>


> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of John Schnizlein
> Sent: Thursday, March 26, 2009 5:09 PM
> To: Ted Mittelstaedt
> Cc: ppml at arin.net
> Subject: Re: [arin-ppml]DraftPolicy 2009-1: TransferPolicy
> (UsingtheEmergencyPDP)
> 
> Are you actually saying you think that creating these tunnels, with
> the side effect of reliance on a third party for security and
> stability, not to mention the profit of the party providing service,
> is better for the Internet than transferring an address to the party
> that wants to reach the (legacy) IPv4-only hosts that will remain on
> the Internet for some time?
> 
> Really?
> 
Yes, absolutely.  There are tunnels already in existence and working.  The
cost is much less and the harm is nonexistent.  There is a legitimate market
those wanting to reap instant profits can get in to.  Go for the v4-v6
Gateway service market.  Oh wait, I forgot, Enterprise class routers like
Cisco already do this automatically.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090326/ca4aaa2d/attachment.bin>

From owen at delong.com  Thu Mar 26 20:47:14 2009
From: owen at delong.com (Owen DeLong)
Date: Thu, 26 Mar 2009 17:47:14 -0700
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using the
	Emergency PDP)
In-Reply-To: <Pine.SOC.4.61.0903261534150.21454@paixhost.pch.net>
References: <49C911A8.5020009@arin.net> <49CB868C.17074.9250208@farmer.umn.edu>
	<Pine.SOC.4.61.0903261534150.21454@paixhost.pch.net>
Message-ID: <2C312C02-0303-4091-BC07-B49F187A59AA@delong.com>


On Mar 26, 2009, at 4:50 PM, Bill Woodcock wrote:

>      On Thu, 26 Mar 2009, David Farmer wrote:
>> 2. Other comments about the removal of the 3 year sunset clause...
>
> Every single sentence in the NRPM could have a sunset clause,  
> doubling the
> size of the document and requiring that every part of it be constantly
> maintained.  Since the public _already has_ the capability to roll  
> back
> any part of the NRPM at any time, or to override any previously- 
> enacted
> sunset clause at any time, sunset clauses are no-ops.
>
Respectfully, I disagree.  The same argument could be made about
laws with sunset clauses, but, the same applies.  While it is true that
the community can change things and could even repeal a sunset
clause, the sunset clause creates a default action that occurs unless
the community takes action.  Additionally, repealing a policy, even
if there is strong community consensus to do so, takes time.  By
having a sunset clause in place, it clearly indicates that the intent
of the community is for the policy to be temporary and short-term
in nature, and, it creates a default action of removing the policy
after some period of time, rather than requiring additional subsequent
action by the community to do so.

Clearly the sunset clause in this policy was part of what made the
policy palatable to some portion of the community. Without it, I do
not believe there was enough support for a transfer policy to call
it consensus.
>
>
> Is there a perceived problem there?  Is there a perceived need to
> transfer IPv6 addresses or ASNs?  If so, is that more problematic than
> IPv4 addresses?
>
I do not believe there is a perceived need.  The transfer of IPv4  
addresses
is being regarded by a very large portion of the community as an  
unfortunate
necessity of the current situation, not a desirable outcome.  As such,  
expanding
the scope to include IPv6 and ASN resources is, indeed, problematic.

Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090326/57c2683a/attachment.htm>

From BillD at cait.wustl.edu  Thu Mar 26 21:00:07 2009
From: BillD at cait.wustl.edu (Bill Darte)
Date: Thu, 26 Mar 2009 20:00:07 -0500
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using
	theEmergency PDP)
References: <49C911A8.5020009@arin.net> <49CB868C.17074.9250208@farmer.umn.edu>
	<Pine.SOC.4.61.0903261534150.21454@paixhost.pch.net>
	<2C312C02-0303-4091-BC07-B49F187A59AA@delong.com>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087531F44@ex1.cait.wustl.edu>

Agreed.

Bill Darte
ARIN AC


-----Original Message-----
From: arin-ppml-bounces at arin.net on behalf of Owen DeLong
Sent: Thu 3/26/2009 7:47 PM
To: Bill Woodcock
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using theEmergency PDP)
 

On Mar 26, 2009, at 4:50 PM, Bill Woodcock wrote:

>      On Thu, 26 Mar 2009, David Farmer wrote:
>> 2. Other comments about the removal of the 3 year sunset clause...
>
> Every single sentence in the NRPM could have a sunset clause,  
> doubling the
> size of the document and requiring that every part of it be constantly
> maintained.  Since the public _already has_ the capability to roll  
> back
> any part of the NRPM at any time, or to override any previously- 
> enacted
> sunset clause at any time, sunset clauses are no-ops.
>
Respectfully, I disagree.  The same argument could be made about
laws with sunset clauses, but, the same applies.  While it is true that
the community can change things and could even repeal a sunset
clause, the sunset clause creates a default action that occurs unless
the community takes action.  Additionally, repealing a policy, even
if there is strong community consensus to do so, takes time.  By
having a sunset clause in place, it clearly indicates that the intent
of the community is for the policy to be temporary and short-term
in nature, and, it creates a default action of removing the policy
after some period of time, rather than requiring additional subsequent
action by the community to do so.

Clearly the sunset clause in this policy was part of what made the
policy palatable to some portion of the community. Without it, I do
not believe there was enough support for a transfer policy to call
it consensus.
>
>
> Is there a perceived problem there?  Is there a perceived need to
> transfer IPv6 addresses or ASNs?  If so, is that more problematic than
> IPv4 addresses?
>
I do not believe there is a perceived need.  The transfer of IPv4  
addresses
is being regarded by a very large portion of the community as an  
unfortunate
necessity of the current situation, not a desirable outcome.  As such,  
expanding
the scope to include IPv6 and ASN resources is, indeed, problematic.

Owen


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090326/c62b5f40/attachment.htm>

From bicknell at ufp.org  Thu Mar 26 21:04:15 2009
From: bicknell at ufp.org (Leo Bicknell)
Date: Thu, 26 Mar 2009 20:04:15 -0500
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using the
	Emergency PDP)
In-Reply-To: <Pine.SOC.4.61.0903261534150.21454@paixhost.pch.net>
References: <49C911A8.5020009@arin.net> <49CB868C.17074.9250208@farmer.umn.edu>
	<Pine.SOC.4.61.0903261534150.21454@paixhost.pch.net>
Message-ID: <20090327010415.GA9256@ussenterprise.ufp.org>

In a message written on Thu, Mar 26, 2009 at 03:50:04PM -0800, Bill Woodcock wrote:
> Every single sentence in the NRPM could have a sunset clause, doubling the 
> size of the document and requiring that every part of it be constantly 
> maintained.  Since the public _already has_ the capability to roll back 
> any part of the NRPM at any time, or to override any previously-enacted 
> sunset clause at any time, sunset clauses are no-ops.  

I wasn't sure how far back sunset provisions went, so I turned to
Wikipeida.  http://en.wikipedia.org/wiki/Sunset_clause  It appears
this technique has been used since at least Roman times in public
policy.

In broad terms, sunset provisions can be used for two purposes:

- To reduce future workload on a body where it is expected the item
  will no longer be useful at some point.  Rather than having to waste
  time removing old policy it automatically goes.

- To require a body to re-evaluate an item via the normal debate
  process in the future because the current authors are worried
  the plan is not yet perfect, and/or the situation may change.

I suspect most people who liked the sunset provision were interested
in the second case.  The sunset provision requires public debate
on the effectiveness of the policy if it is to continue.  There is
a long history of such provisions being used with controvercial
policies, several of which are debated in the Wikipedia entry.
Since these debates have many times prompted changes, or not renewing
the policy it is easy to argue that sunset provisions have been
used to produce very useful results.

It is far from a no-op, rather it is a required-op.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090326/4d4ae214/attachment.sig>

From farmer at umn.edu  Thu Mar 26 21:24:48 2009
From: farmer at umn.edu (David Farmer)
Date: Thu, 26 Mar 2009 20:24:48 -0500
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using the
	Emergency PDP)
In-Reply-To: <Pine.SOC.4.61.0903261534150.21454@paixhost.pch.net>
References: <49C911A8.5020009@arin.net>,
	<49CB868C.17074.9250208@farmer.umn.edu>,
	<Pine.SOC.4.61.0903261534150.21454@paixhost.pch.net>
Message-ID: <49CBE490.22329.A9441A8@farmer.umn.edu>

On 26 Mar 2009 Bill Woodcock wrote:

>       On Thu, 26 Mar 2009, David Farmer wrote:
>     > 2. Other comments about the removal of the 3 year sunset
>     clause...
> 
> Every single sentence in the NRPM could have a sunset clause, doubling
> the size of the document and requiring that every part of it be
> constantly maintained.  Since the public _already has_ the capability
> to roll back any part of the NRPM at any time, or to override any
> previously-enacted sunset clause at any time, sunset clauses are
> no-ops.  

I completely agree with you on the content of your point, and personally I 
don't have a problem the end result.  But, I don't so much agree with how we 
got to the resolution of the point, process does matter some time.

>     > 1. 2008-6 included the following language, "Number resources may
>     > only be received under RSA", and I don't see that anywhere in
>     > the 2009-1 language. 
> 
> 8.1, paragraph 2, among others.
> 
> ARIN does not give resources to organizations that do not sign an RSA.
>  That doesn't need to be restated in every paragraph.
> 
>     > If you assume that all resources assigned through the NPRM are
>     > covered by the RSA then I might agree this is not a "material
>     > change."
> 
> Correct.

Thank you and as I said I just wanted a clearification; 
 
>     > 2. Within 2008-6 the title of section 8.4 was "Emergency
>     > Transfer Policy for IPv4 Addresses".  2009-1 doesn't include any
>     > language to limit this to IPv4 resources only.
> 
> Is there a perceived problem there?  Is there a perceived need to
> transfer IPv6 addresses or ASNs?  If so, is that more problematic than
> IPv4 addresses?

Wait a minute here, I've been mostly with you up to this point!  

But, I'll quote John Curran here "the material change made to the transfer 
policy by the ARIN Board is removal of the 3 year sunset clause."

Even if I agreed with you about this point, and I don't, this is a very material 
change too.  Both 2008-2 and 2008-6 very explicitly limited transfers to IPv4.  
I haven't heard anyone talking about transfuers for IPv6 and ASNs.  This is a 
way more material than the 3 year sunset clause.

>     > If the Board intended this to include IPv6 and ANS resources, 
>     > then why keep the Mergers and Acquisitions section?
> 
> That was indeed the subject of no little discussion, as I imagine
> you'll find when you read the meeting minutes.

I was trying to argue that not limiting to IPv4 was an editing mistake, by 
pointing out that the Mergers and Acquisitions section was retained.  I'm 
speechless, that you are implying that it was intentional to remove the 
limitation to IPv4 and include IPv6 and ASNs.

I believe that the majority of the community sees allowing the transfer of IPv4 
resources as the least-worst option as a result of IPv4 exhaustion. And 
personally, I'm willing to buy an emergency for IPv4, others aren't.  But, I also 
believe that a majority of the community would prefer a different option than 
transfers for IPv4 if there were a realistic one out there.  But transfers for 
IPv6 and ASNs, especially after we have done 4-byte ASNs, just isn't 
necessary, and doesn't meet any definition of the word emergency I know of.   

>                                 -Bill


=======================================================
David Farmer				     Email:	farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota			     Phone:	612-626-0815
2218 University Ave SE			     Cell:		612-812-9952
Minneapolis, MN 55414-3029		     FAX:	612-626-1818
=======================================================



From BillD at cait.wustl.edu  Thu Mar 26 21:23:18 2009
From: BillD at cait.wustl.edu (Bill Darte)
Date: Thu, 26 Mar 2009 20:23:18 -0500
Subject: [arin-ppml]
	DraftPolicy	2009-1:	TransferPolicy	(UsingtheEmergencyPDP)
References: <28E139F46D45AF49A31950F88C497458523F17@E03MVZ2-UKDY.domain1.systemhost.net><49CBEBD9.3030808@matthew.at><F5AD98B6764B4504AD86143DF8449FE8@tedsdesk><1CDB1C86-F2B6-44F4-AF0C-D497EE10EF48@isoc.org>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4AF38@mail>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087531F49@ex1.cait.wustl.edu>

Kevin,

Please, briefly, explain to me your perspective.
If not a transfer policy, or market if you insist, what then?

What is your vision of how the community would move forward from here....through IANA free pool exhaustion, through RIR exhaustion....
What do people who consider that they need IPv4 addresses do when they run out....what do people do when they consider IPv6 too risky to their performance (business) or business plan?

What exactly do you propose ARIN and all those needing addresses do?

I'm not trying to be provocative, I'm really interested.  I've seen you express at length why a transfer market is no good.  Expose your thinking on what happens going forward.

Bill Darte
ARIN AC


-----Original Message-----
From: arin-ppml-bounces at arin.net on behalf of Kevin Kargel
Sent: Thu 3/26/2009 7:35 PM
To: ppml at arin.net
Subject: Re: [arin-ppml]DraftPolicy	2009-1:	TransferPolicy	(UsingtheEmergencyPDP)
 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of John Schnizlein
> Sent: Thursday, March 26, 2009 5:09 PM
> To: Ted Mittelstaedt
> Cc: ppml at arin.net
> Subject: Re: [arin-ppml]DraftPolicy 2009-1: TransferPolicy
> (UsingtheEmergencyPDP)
> 
> Are you actually saying you think that creating these tunnels, with
> the side effect of reliance on a third party for security and
> stability, not to mention the profit of the party providing service,
> is better for the Internet than transferring an address to the party
> that wants to reach the (legacy) IPv4-only hosts that will remain on
> the Internet for some time?
> 
> Really?
> 
Yes, absolutely.  There are tunnels already in existence and working.  The
cost is much less and the harm is nonexistent.  There is a legitimate market
those wanting to reap instant profits can get in to.  Go for the v4-v6
Gateway service market.  Oh wait, I forgot, Enterprise class routers like
Cisco already do this automatically.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090326/c67e13b4/attachment.htm>

From michael.dillon at bt.com  Fri Mar 27 03:54:55 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Fri, 27 Mar 2009 07:54:55 -0000
Subject: [arin-ppml]
	Draft	Policy2009-1:	TransferPolicy	(UsingtheEmergencyPDP)
In-Reply-To: <49CBC2E6.4030309@matthew.at>
Message-ID: <28E139F46D45AF49A31950F88C497458523FB1@E03MVZ2-UKDY.domain1.systemhost.net>

> Google isn't going to stop growing just because ARIN won't 
> give them more addresses. They will go back and scavenge all 
> the ones they have, they will get them from other RIRs until 
> those RIRs are also out, they will assign additional value to 
> potential acquisitions that have existing PI IPv4 space, 
> especially if that space is underutilized, and they will 
> acquire or lease address space as necessary from other 
> entities that, with money applied, can find spare addresses 
> to release.

No they won't. Google is one of the leaders in moving to IPv6. They
don't have to scavenge, cheat, beg or borrow IPv4 addresses because they
are already making their infrastructure IPv6 compliant. In addition they
are using non-IP custom protocols internally in some of their data
centers.

> This is a lot like how Sprint and Clearwire leased ITFS (now 
> EBS) spectrum on 30-year leases from universities that didn't 
> need all the instructional television channels they were 
> licensed for. 

Completely different situation. Spectrum is fixed and finite. IPv4
addresses exist beside plentiful IPv6 resources that are free for the
asking.

> Innovative new services probably will be using IPv6.

That's why Google offers some services to IPv6 peers which are not
available on IPv4 at all.

> But 
> they'll also want to serve the large pool of existing 
> potential customers who are on
> IPv4 and who don't have access to an IPv4 to IPv6 proxy yet. 

This is a vanishingly small number of people given the ability of Google
to run 6to4 proxies in their own infrastructure. You should also
investigate how Teredo works.


> In between those two times, there is value to new entrants 
> and growing entities in acquiring more IPv4 space.

Only to entities which are not publicly traded. Any publicly traded
entity will see severe downward pressure on their share prices if they
haven't already sorted out the problem by deploying IPv6. Depressed
share prices make a company target for acquisition by a company that has
their IPv6 deployment well in hand.

--Michael Dillon


From lear at cisco.com  Fri Mar 27 06:57:42 2009
From: lear at cisco.com (Eliot Lear)
Date: Fri, 27 Mar 2009 11:57:42 +0100
Subject: [arin-ppml]
	Draft	Policy2009-1:	TransferPolicy	(UsingtheEmergencyPDP)
In-Reply-To: <B7CDCD59-372A-4CAB-87D7-7361217C6A6F@isoc.org>
References: <28E139F46D45AF49A31950F88C4974584C7CED@E03MVZ2-UKDY.domain1.systemhost.net>	<49CBBA04.1000002@matthew.at>	<70DE64CEFD6E9A4EB7FAF3A06314106601B4AF29@mail>
	<B7CDCD59-372A-4CAB-87D7-7361217C6A6F@isoc.org>
Message-ID: <49CCB126.2010205@cisco.com>

John,

I'd like to clarify your clarification.

On 3/26/09 11:04 PM, John Schnizlein wrote:
> Those who have IPv4 addresses when the free pools go empty would bear
> no cost created by a market.  If they convert some subset of their
> hosts from IPv4 to IPv6, they might be able to receive some
> compensation for the effort to release addresses.
>    

Is what you mean, "Those who have IPv4 addresses but have need of no more"?
> Those who do not have IPv4 when the pools run dry would bear both the
> cost of addresses on the unauthorized market plus the cost of the risk
> that those addresses will be unreachable from parts of the Internet -
> or do without.
>    

Is what you mean, "Those who need more IPv4 addresses..."?

This is an important distinction because...
> Who is harmed by this market?
>    

... those who have no need of IPv4 addresses would clearly benefit from 
a value being associated with them.  On the other hand, when we talk 
about harm, this is a more difficult question, because we have to ask, 
"in comparison to what?"

Eliot


From heather.schiller at verizonbusiness.com  Fri Mar 27 09:21:05 2009
From: heather.schiller at verizonbusiness.com (Heather Schiller)
Date: Fri, 27 Mar 2009 09:21:05 -0400
Subject: [arin-ppml]
 =?windows-1252?q?Draft_Policy_2008-7=3A_Identify_Inva?=
 =?windows-1252?q?lid_WHOIS_POC=92s?=
In-Reply-To: <49C7DD6E.3010106@arin.net>
References: <49C7DD6E.3010106@arin.net>
Message-ID: <49CCD2C1.6030005@verizonbusiness.com>


Feedback on ARIN Staff Comments:

1) Hijacking - this is already a problem today.  Providing a list of 
resources with stale records is essentially a list of resources at risk, 
which will allow providers to have something to check against before 
they route the block.

2) Workload - in many ways this is work that is already done when 
billing POC's go invalid.  Arguably, ARIN should have been checking POC 
validity on a recurring basis from the beginning.

3) Bulk Whois Reference - ARIN has the operational details of going 
through the bulk whois process on 
https://www.arin.net/resources/request/bulkwhois.html  which includes a 
requirement to sign an AUP.  Other sections of existing policy do not 
include operational details or further requirements for the bulk whois 
process.  The authors believe the process of signing the bulk whois 
agreement to be an operational process on the part of ARIN staff and not 
part of policy.

4) Threat of lawsuit - I understand council's comment to mean - if we 
properly announce and enforce it should be ok.  I am also thinking, as 
long as ARIN has a (an operational) process to re-establish/validate the 
POC, that would help mitigate any problems, correct?

5) Resource Impact - Yes, it will take new development and time to get 
this process in place, however the potential benefit to the community is 
also significant.

--Heather

Member Services wrote:
<snip>
> ARIN Staff Assessment
> 
> 2008-7
> 
> Title:  Identify Invalid WHOIS POC's (formerly known as WHOIS Integrity
> Policy Proposal)
> 
> Revision Submitted: 07 March 2008
> 
> 2nd Revision Submitted: 12 Feb 2009
> 
> Date of Assessment:  24 Feb 2009
> 
> The assessment of this text includes comments from ARIN staff and the
> ARIN General Counsel. It contains analysis of procedural, legal, and
> resource concerns regarding the implementation of this text as it is
> currently stated. Any changes to the language may necessitate further
> analysis by staff and Counsel.
> 
> I.  Understanding
> 
> ARIN staff understands that this will institute an annual
> re-registration of all POCs registered in WHOIS.  POCs who do not
> respond within 60 days will be marked in the database as "un-responsive"
> and if staff deems them to be invalid for any reason, may remove them
> from WHOIS.  In addition, staff will maintain a list of all address
> blocks with no valid POCs and will make this data available to any
> organization using the bulk whois policy criteria.
> 
> II.  Issues and Concerns
> 
>   A.  ARIN Staff Comments:
> 
>     * Resource records marked as ?unresponsive? or those with no POCs at
>       all could become the targets of hijackers who, in the past have
>       tended to look for address blocks that contain obsolete or stale data.
>     *  An annual re-registration of all POCs (~223,000 currently) will
>       likely result in a vast increase in workload, particularly with
>       the follow up work and research involved when a POC does not reply
>       within 60 days.  This could result in a slow down in registration
>       response and processing times.
> 
> 
> 
>     * This policy refers to the Bulk Whois policy rather than stating
>       the actual criteria under which an organization will be allowed to
>       request the list of all address blocks with no valid POCs.  It
>       would be better policy text to state the specific criteria,
>       including the requirement to sign an AUP, within this policy itself.
> 
> 
> 
>   B.  ARIN General Counsel
> 
>     * It is possible those delisted will threaten or file litigation to
>       be relisted. However, a properly promulgated policy does not pose
>       antirust or other legal concerns.
> 
> 
> 
> III. Resource Impact
> 
> The resource impact of implementing this policy is viewed as
> significant. Barring any unforeseen resource requirements, it is
> estimated that this policy could take up to 18 person months to fully
> implement from the date of ratification of the policy by the ARIN Board
> of Trustees.  It may require the following:
> 
>     * Staff training
>     * Development of new internal process and procedures and
>       modification to existing ones
>     * Creation of an automated system to track notifications, updates,
>       and current status of the POC notification. Provide allowances for
>       manual intervention and follow-up by staff.  Engineering estimates
>       that it could take up to 18 person months for the creation and
>       implementation of this system. In addition, this could impact
>       ARIN?s current project deployment schedule.
>     * Increased workload could result in the need for additional staff
> 
> 
> 
> Text assessed:
> 
> 2008-7: Identify Invalid WHOIS POC's (formally known as WHOIS Integrity
> Policy Proposal)
> 
> Revised text is as follows:
> 
> During ARINs annual WHOIS POC validation, an e-mail will be sent to
> every POC in the WHOIS database. Each POC will have a maximum of 60 days
> to respond with an affirmative that their WHOIS contact information is
> correct and complete. Unresponsive POC email addresses shall be marked
> as such in the database. If ARIN staff deems a POC to be completely and
> permanently abandoned or otherwise illegitimate, the record shall be
> deleted. ARIN will maintain, and make readily available to the
> community, a current list of address-blocks with no valid POC; this data
> will be subject to the current bulk WHOIS policy.
> 
> 
> 
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 



From schnizlein at isoc.org  Fri Mar 27 10:03:53 2009
From: schnizlein at isoc.org (John Schnizlein)
Date: Fri, 27 Mar 2009 07:03:53 -0700
Subject: [arin-ppml]
	Draft	Policy2009-1:	TransferPolicy	(UsingtheEmergencyPDP)
In-Reply-To: <49CCB126.2010205@cisco.com>
References: <28E139F46D45AF49A31950F88C4974584C7CED@E03MVZ2-UKDY.domain1.systemhost.net>	<49CBBA04.1000002@matthew.at>	<70DE64CEFD6E9A4EB7FAF3A06314106601B4AF29@mail>
	<B7CDCD59-372A-4CAB-87D7-7361217C6A6F@isoc.org>
	<49CCB126.2010205@cisco.com>
Message-ID: <BBD6B25A-713B-4032-8A3C-257AE4819665@isoc.org>


On 2009Mar27, at 3:57 AM, Eliot Lear wrote:
>
> I'd like to clarify your clarification.
>
> On 3/26/09 11:04 PM, John Schnizlein wrote:
>> Those who have IPv4 addresses when the free pools go empty would bear
>> no cost created by a market.  If they convert some subset of their
>> hosts from IPv4 to IPv6, they might be able to receive some
>> compensation for the effort to release addresses.
>
> Is what you mean, "Those who have IPv4 addresses but have need of no  
> more"?

Yes.

>> Those who do not have IPv4 when the pools run dry would bear both the
>> cost of addresses on the unauthorized market plus the cost of the  
>> risk
>> that those addresses will be unreachable from parts of the Internet -
>> or do without.
>
> Is what you mean, "Those who need more IPv4 addresses..."?

Yes.

John




From kkargel at polartel.com  Fri Mar 27 11:24:32 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Fri, 27 Mar 2009 10:24:32 -0500
Subject: [arin-ppml]
	DraftPolicy	2009-1:	TransferPolicy	(UsingtheEmergencyPDP)
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D03087531F49@ex1.cait.wustl.edu>
References: <28E139F46D45AF49A31950F88C497458523F17@E03MVZ2-UKDY.domain1.systemhost.net><49CBEBD9.3030808@matthew.at><F5AD98B6764B4504AD86143DF8449FE8@tedsdesk><1CDB1C86-F2B6-44F4-AF0C-D497EE10EF48@isoc.org>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4AF38@mail>
	<EACF8B735E9CBA4B8BAF9E4165D03087531F49@ex1.cait.wustl.edu>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AF3A@mail>


From: Bill Darte [mailto:BillD at cait.wustl.edu] 
Sent: Thursday, March 26, 2009 8:23 PM
To: Kevin Kargel; ppml at arin.net
Subject: RE: [arin-ppml]DraftPolicy 2009-1: TransferPolicy
(UsingtheEmergencyPDP)

>>Kevin,
>>
>>Please, briefly, explain to me your perspective.
>>If not a transfer policy, or market if you insist, what then?
>>
>>What is your vision of how the community would move forward from
here....through IANA free pool exhaustion, through RIR exhaustion....
>>What do people who consider that they need IPv4 addresses do when they run
out....what do people do when they consider IPv6 too risky to their
performance (business) or >>business plan?
>>
>>What exactly do you propose ARIN and all those needing addresses do?
>>
>>I'm not trying to be provocative, I'm really interested.? I've seen you
express at length why a transfer market is no good.? Expose your thinking on
what happens going >>forward.
>>
>>Bill Darte
>>ARIN AC

I don't think it is up to ARIN to decide how people should run their
businesses.  It is not up to ARIN to engineer business plans for companies.
It is up to companies to develop business plans that are functional within
the constraints that exist.  It is just up to ARIN to shepherd the resources
that exist.  ARIN cannot magically create IPv4, well, sort of they have by
supporting extending the addressing via IPv6.  

Going forward IPv4 runs to exhaustion.  The community has proven to be
innovative and cooperative.  I believe this will continue in the future.
Network administrators will work with their peers to keep things running
within whatever rules and standards exist.  

Companies that have planned forward will thrive, companies that have not
planned or have planned badly will not thrive.  This is pretty much a basic
of business.  ARIN is not responsible for companies who refuse or don't
bother to look forward.  Lack of planning on their part does not constitute
an emergency for you.

ARIN has done a great job up until this back-door implementation of the
transfer policy.  I continue to laud the past accomplishments of ARIN.  We
have a tremendous and self-healing system if we just continue to trust in
it.

I hear much wailing about the black-market dealings in IP's.  From what I
have seen this is minor traffic.  I believe this will be self limiting.
Companies that pay 100's or thousands of times as much for IP's on the black
market will have a hard time competing with companies that get IP's through
legitimate channels.  Granted we will have to be more vigilant against
hijackers, but that is the way it is.

I do think it would behoove us to identify and reclaim abandoned space, but
even that is a stop-gap measure, not a solution.

IPv4 is a finite resource.  Nothing we do will extend it in perpetuity.  We
may not be doing the community a favor by taping the bandaid ever more
firmly over a festering wound because it will hurt to take it off.

I fear for the future of ARIN.  Once we relinquish control of allocation to
a free market in reality ARIN's role is relegated to being a database.  I
believe ARIN (or it's function) is necessary for the continued smooth
operation of the Internet.  If we turn control over to capitalistic drivers
chaos will reign.  If you think about monetary driven and motivated
allocation decisions and where that will take us I am sure you will
understand.

I hope that was brief enough.  My plea to ARIN is get back on the community
track, and not focus so much about the corporate track.  Our biggest
responsibility is to society, not business.

Kevin Kargel






-----Original Message-----
From: arin-ppml-bounces at arin.net on behalf of Kevin Kargel
Sent: Thu 3/26/2009 7:35 PM
To: ppml at arin.net
Subject: Re: [arin-ppml]DraftPolicy???? 2009-1: TransferPolicy?
(UsingtheEmergencyPDP)


> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of John Schnizlein
> Sent: Thursday, March 26, 2009 5:09 PM
> To: Ted Mittelstaedt
> Cc: ppml at arin.net
> Subject: Re: [arin-ppml]DraftPolicy 2009-1: TransferPolicy
> (UsingtheEmergencyPDP)
>
> Are you actually saying you think that creating these tunnels, with
> the side effect of reliance on a third party for security and
> stability, not to mention the profit of the party providing service,
> is better for the Internet than transferring an address to the party
> that wants to reach the (legacy) IPv4-only hosts that will remain on
> the Internet for some time?
>
> Really?
>
Yes, absolutely.? There are tunnels already in existence and working.? The
cost is much less and the harm is nonexistent.? There is a legitimate market
those wanting to reap instant profits can get in to.? Go for the v4-v6
Gateway service market.? Oh wait, I forgot, Enterprise class routers like
Cisco already do this automatically.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090327/ae05102c/attachment.bin>

From bicknell at ufp.org  Fri Mar 27 12:25:56 2009
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 27 Mar 2009 11:25:56 -0500
Subject: [arin-ppml] How hard is it to transition to IPv6?
Message-ID: <20090327162556.GA57288@ussenterprise.ufp.org>


http://www.networkworld.com/news/2009/032509-google-ipv6-easy.html

At the IETF meeting there was a panel discussion on transitioing
to IPv6, at which Google gave their perspective.  I know a lot of
folks have been looking for some more concrete information on how
hard the transition will be, and here's one companies's take on it.

I would like to applaud Google for both being out front and talking
about their experiences.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090327/0f00ccf8/attachment.sig>

From BillD at cait.wustl.edu  Fri Mar 27 12:33:22 2009
From: BillD at cait.wustl.edu (Bill Darte)
Date: Fri, 27 Mar 2009 11:33:22 -0500
Subject: [arin-ppml] How hard is it to transition to IPv6?
In-Reply-To: <20090327162556.GA57288@ussenterprise.ufp.org>
References: <20090327162556.GA57288@ussenterprise.ufp.org>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D030878AB24A@ex1.cait.wustl.edu>

Nice catch Leo.
And good news for the industry....
Are you all listening out there???

Bill Darte 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Leo Bicknell
> Sent: Friday, March 27, 2009 11:26 AM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] How hard is it to transition to IPv6?
> 
> 
> http://www.networkworld.com/news/2009/032509-google-ipv6-easy.html
> 
> At the IETF meeting there was a panel discussion on 
> transitioing to IPv6, at which Google gave their perspective. 
>  I know a lot of folks have been looking for some more 
> concrete information on how hard the transition will be, and 
> here's one companies's take on it.
> 
> I would like to applaud Google for both being out front and 
> talking about their experiences.
> 
> -- 
>        Leo Bicknell - bicknell at ufp.org - CCIE 3440
>         PGP keys at http://www.ufp.org/~bicknell/
> 


From mloftis at wgops.com  Fri Mar 27 12:32:11 2009
From: mloftis at wgops.com (Michael Loftis)
Date: Fri, 27 Mar 2009 10:32:11 -0600
Subject: [arin-ppml] How hard is it to transition to IPv6?
In-Reply-To: <20090327162556.GA57288@ussenterprise.ufp.org>
References: <20090327162556.GA57288@ussenterprise.ufp.org>
Message-ID: <942D9D7DDDDC80D26685B567@ZOP-MACTEL.local>



--On March 27, 2009 11:25:56 AM -0500 Leo Bicknell <bicknell at ufp.org> wrote:

>
> http://www.networkworld.com/news/2009/032509-google-ipv6-easy.html
>
> At the IETF meeting there was a panel discussion on transitioing
> to IPv6, at which Google gave their perspective.  I know a lot of
> folks have been looking for some more concrete information on how
> hard the transition will be, and here's one companies's take on it.
>
> I would like to applaud Google for both being out front and talking
> about their experiences.

For some it's still impossible.  Eg any cable operator, why?  Consumer 
devices still don't have v6.  Even many "business" class devices do not. 
In my own experience I've run across Watchguard Firebox X Edge series, all 
lower end juniper ssg/netscreen devices -- though i'm told you can enable 
it from the CLI but it's unsupported, Juniper's M7i ASM as of 8.5R4.2 while 
it'll let you setup stateful firewalling stuff for v6 connections, it just 
doesn't work at all.  I've not tried any other ASM/Services w/ v6 though. 
And I'm sure the list goes on.





From Fred.Wettling at Bechtel.com  Fri Mar 27 12:49:23 2009
From: Fred.Wettling at Bechtel.com (Wettling, Fred)
Date: Fri, 27 Mar 2009 12:49:23 -0400
Subject: [arin-ppml] How hard is it to transition to IPv6?
In-Reply-To: <20090327162556.GA57288@ussenterprise.ufp.org>
References: <20090327162556.GA57288@ussenterprise.ufp.org>
Message-ID: <F6EF0617A25EBB43BFB93175FBB913F9318384@ASHS00094.amers.ibechtel.com>

Bechtel Internal / Non-Record//


And thanks to Google for hosting the IPv6 Implementors Conference on the
19th & 20th.  Several companies shared their experiences.  Presentations
available at this link:
https://sites.google.com/site/ipv6implementors/conference2009/agenda

Fred Wettling
Bechtel Corporation
Global IPv6 Strategies (book contains several case studies)


-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Leo Bicknell
Sent: Friday, March 27, 2009 12:26 PM
To: arin-ppml at arin.net
Subject: [arin-ppml] How hard is it to transition to IPv6?


http://www.networkworld.com/news/2009/032509-google-ipv6-easy.html

At the IETF meeting there was a panel discussion on transitioing to IPv6, at
which Google gave their perspective.  I know a lot of folks have been
looking for some more concrete information on how hard the transition will
be, and here's one companies's take on it.

I would like to applaud Google for both being out front and talking about
their experiences.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/

Bechtel Internal / Non-Record//

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6040 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090327/0689c935/attachment.bin>

From dsd at servervault.com  Fri Mar 27 13:06:14 2009
From: dsd at servervault.com (Divins, David)
Date: Fri, 27 Mar 2009 13:06:14 -0400
Subject: [arin-ppml] How hard is it to transition to IPv6?
In-Reply-To: <942D9D7DDDDC80D26685B567@ZOP-MACTEL.local>
References: <20090327162556.GA57288@ussenterprise.ufp.org>
	<942D9D7DDDDC80D26685B567@ZOP-MACTEL.local>
Message-ID: <8A3DE12E408BBC499E40C0BE733C86030154CBB0@mail1.dulles.sv.int>

Juniper does support those ssg/netscreen products on IPv6. You do need a
cli to enable:
set envar ipv6=yes

Where I see flaws is the total supporting package.  I have a router that
has no IPv4.  Yet I need a v4 address for BGP RID.  I cannot upgrade the
device via v6, nor can it use v6 log, resolver, or time services.  But
it does route and filter v6 like a madman.

Personally, I am IPv6 full steam ahead, and I think for many
organizations it will not be as bad as they suspect.  They just need
some education, a lot of FUD has been distributed.

-dsd

David Divins
Principal Engineer
ServerVault Corp.

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Michael Loftis
Sent: Friday, March 27, 2009 12:32 PM
To: Leo Bicknell; arin-ppml at arin.net
Subject: Re: [arin-ppml] How hard is it to transition to IPv6?



--On March 27, 2009 11:25:56 AM -0500 Leo Bicknell <bicknell at ufp.org>
wrote:

>
> http://www.networkworld.com/news/2009/032509-google-ipv6-easy.html
>
> At the IETF meeting there was a panel discussion on transitioing
> to IPv6, at which Google gave their perspective.  I know a lot of
> folks have been looking for some more concrete information on how
> hard the transition will be, and here's one companies's take on it.
>
> I would like to applaud Google for both being out front and talking
> about their experiences.

For some it's still impossible.  Eg any cable operator, why?  Consumer 
devices still don't have v6.  Even many "business" class devices do not.

In my own experience I've run across Watchguard Firebox X Edge series,
all 
lower end juniper ssg/netscreen devices -- though i'm told you can
enable 
it from the CLI but it's unsupported, Juniper's M7i ASM as of 8.5R4.2
while 
it'll let you setup stateful firewalling stuff for v6 connections, it
just 
doesn't work at all.  I've not tried any other ASM/Services w/ v6
though. 
And I'm sure the list goes on.



_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.


From michael at rancid.berkeley.edu  Fri Mar 27 12:47:39 2009
From: michael at rancid.berkeley.edu (Michael Sinatra)
Date: Fri, 27 Mar 2009 09:47:39 -0700
Subject: [arin-ppml] How hard is it to transition to IPv6?
In-Reply-To: <20090327162556.GA57288@ussenterprise.ufp.org>
References: <20090327162556.GA57288@ussenterprise.ufp.org>
Message-ID: <49CD032B.70805@rancid.berkeley.edu>

On 3/27/09 9:25 AM, Leo Bicknell wrote:
> http://www.networkworld.com/news/2009/032509-google-ipv6-easy.html
> 
> At the IETF meeting there was a panel discussion on transitioing
> to IPv6, at which Google gave their perspective.  I know a lot of
> folks have been looking for some more concrete information on how
> hard the transition will be, and here's one companies's take on it.
> 
> I would like to applaud Google for both being out front and talking
> about their experiences.

Having google give such an endorsement is really helpful, considering 
google's high level of credibility outside of the network-engineering 
portions of most IT service providers.

I plan to use google's experiences as leverage for getting more of my 
organization's content accessible over IPv6.

michael


From khelms at zcorum.com  Fri Mar 27 14:03:39 2009
From: khelms at zcorum.com (Scott Helms)
Date: Fri, 27 Mar 2009 14:03:39 -0400
Subject: [arin-ppml] How hard is it to transition to IPv6?
In-Reply-To: <8A3DE12E408BBC499E40C0BE733C86030154CBB0@mail1.dulles.sv.int>
References: <20090327162556.GA57288@ussenterprise.ufp.org>	<942D9D7DDDDC80D26685B567@ZOP-MACTEL.local>
	<8A3DE12E408BBC499E40C0BE733C86030154CBB0@mail1.dulles.sv.int>
Message-ID: <49CD14FB.3080709@zcorum.com>

David,

    I wish I were as optimistic as you, and my view is based on testing 
in our environment.  While it will be fairly easy for some kinds of 
companies this is going to be a total nightmare for ISP's.  It's pain 
that has to borne, but that doesn't make it easy to swallow.

Divins, David wrote:
> Juniper does support those ssg/netscreen products on IPv6. You do need a
> cli to enable:
> set envar ipv6=yes
>
> Where I see flaws is the total supporting package.  I have a router that
> has no IPv4.  Yet I need a v4 address for BGP RID.  I cannot upgrade the
> device via v6, nor can it use v6 log, resolver, or time services.  But
> it does route and filter v6 like a madman.
>
> Personally, I am IPv6 full steam ahead, and I think for many
> organizations it will not be as bad as they suspect.  They just need
> some education, a lot of FUD has been distributed.
>
> -dsd
>
> David Divins
> Principal Engineer
> ServerVault Corp.
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Michael Loftis
> Sent: Friday, March 27, 2009 12:32 PM
> To: Leo Bicknell; arin-ppml at arin.net
> Subject: Re: [arin-ppml] How hard is it to transition to IPv6?
>
>
>
> --On March 27, 2009 11:25:56 AM -0500 Leo Bicknell <bicknell at ufp.org>
> wrote:
>
>   
>> http://www.networkworld.com/news/2009/032509-google-ipv6-easy.html
>>
>> At the IETF meeting there was a panel discussion on transitioing
>> to IPv6, at which Google gave their perspective.  I know a lot of
>> folks have been looking for some more concrete information on how
>> hard the transition will be, and here's one companies's take on it.
>>
>> I would like to applaud Google for both being out front and talking
>> about their experiences.
>>     
>
> For some it's still impossible.  Eg any cable operator, why?  Consumer 
> devices still don't have v6.  Even many "business" class devices do not.
>
> In my own experience I've run across Watchguard Firebox X Edge series,
> all 
> lower end juniper ssg/netscreen devices -- though i'm told you can
> enable 
> it from the CLI but it's unsupported, Juniper's M7i ASM as of 8.5R4.2
> while 
> it'll let you setup stateful firewalling stuff for v6 connections, it
> just 
> doesn't work at all.  I've not tried any other ASM/Services w/ v6
> though. 
> And I'm sure the list goes on.
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
>
>   


-- 
Scott Helms
Vice President of Technology
ISP Alliance, Inc. DBA ZCorum
(678) 507-5000



From matthew at matthew.at  Fri Mar 27 14:04:20 2009
From: matthew at matthew.at (Matthew Kaufman)
Date: Fri, 27 Mar 2009 11:04:20 -0700
Subject: [arin-ppml] How hard is it to transition to IPv6?
In-Reply-To: <20090327162556.GA57288@ussenterprise.ufp.org>
References: <20090327162556.GA57288@ussenterprise.ufp.org>
Message-ID: <49CD1524.5080200@matthew.at>

Leo Bicknell wrote:
> http://www.networkworld.com/news/2009/032509-google-ipv6-easy.html
>
>   
Google has the advantage that they have the source code to the 
applications and developers on staff to modify that code.

This is not the case for most of the world's users of computers and/or 
embedded devices. They are looking at whether or not an upgrade is 
available, and if not whether or not a new program or device is 
available that does what their existing things do. In some cases a 
solution is not currently available at any price.

Matthew Kaufman


From bicknell at ufp.org  Fri Mar 27 14:21:30 2009
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 27 Mar 2009 13:21:30 -0500
Subject: [arin-ppml] How hard is it to transition to IPv6?
In-Reply-To: <49CD1524.5080200@matthew.at>
References: <20090327162556.GA57288@ussenterprise.ufp.org>
	<49CD1524.5080200@matthew.at>
Message-ID: <20090327182129.GA62899@ussenterprise.ufp.org>

In a message written on Fri, Mar 27, 2009 at 11:04:20AM -0700, Matthew Kaufman wrote:
> Google has the advantage that they have the source code to the 
> applications and developers on staff to modify that code.
> 
> This is not the case for most of the world's users of computers and/or 
> embedded devices. They are looking at whether or not an upgrade is 
> available, and if not whether or not a new program or device is 
> available that does what their existing things do. In some cases a 
> solution is not currently available at any price.

If you believe http://inetcore.com/project/ipv4ec/index_en.html
then we have a little over 2 years before IANA exhaustion, perhaps
another six months to RIR exhaustion, and then 6 months to ISP
exhaustion.  So we're looking at a 2.5-3 year window right now.

Google has shown with the source code and programmers you can fix
the software in ~18 months.  That's good news, isn't it?  If we can
all drive home the requirements to the vendors it seems like there
is plenty of time to get stuff fixed and deployed before it is an
issue.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090327/a2527095/attachment.sig>

From mloftis at wgops.com  Fri Mar 27 14:31:42 2009
From: mloftis at wgops.com (Michael Loftis)
Date: Fri, 27 Mar 2009 12:31:42 -0600
Subject: [arin-ppml] How hard is it to transition to IPv6?
In-Reply-To: <8A3DE12E408BBC499E40C0BE733C86030154CBB0@mail1.dulles.sv.int>
References: <20090327162556.GA57288@ussenterprise.ufp.org>
	<942D9D7DDDDC80D26685B567@ZOP-MACTEL.local>
	<8A3DE12E408BBC499E40C0BE733C86030154CBB0@mail1.dulles.sv.int>
Message-ID: <0211B4C880CCC177C0AB0347@ZOP-MACTEL.local>



--On March 27, 2009 1:06:14 PM -0400 "Divins, David" <dsd at servervault.com> 
wrote:

> Juniper does support those ssg/netscreen products on IPv6. You do need a
> cli to enable:
> set envar ipv6=yes

Yes but AFAIK, JTAC does not *support* it on smaller devices, so if it 
causes you to crash every five minutes, you're SOL.  I might be wrong on 
that now though.

>
> Where I see flaws is the total supporting package.  I have a router that
> has no IPv4.  Yet I need a v4 address for BGP RID.  I cannot upgrade the
> device via v6, nor can it use v6 log, resolver, or time services.  But
> it does route and filter v6 like a madman.
>
> Personally, I am IPv6 full steam ahead, and I think for many
> organizations it will not be as bad as they suspect.  They just need
> some education, a lot of FUD has been distributed.
>
> -dsd
>
> David Divins
> Principal Engineer
> ServerVault Corp.
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Michael Loftis
> Sent: Friday, March 27, 2009 12:32 PM
> To: Leo Bicknell; arin-ppml at arin.net
> Subject: Re: [arin-ppml] How hard is it to transition to IPv6?
>
>
>
> --On March 27, 2009 11:25:56 AM -0500 Leo Bicknell <bicknell at ufp.org>
> wrote:
>
>>
>> http://www.networkworld.com/news/2009/032509-google-ipv6-easy.html
>>
>> At the IETF meeting there was a panel discussion on transitioing
>> to IPv6, at which Google gave their perspective.  I know a lot of
>> folks have been looking for some more concrete information on how
>> hard the transition will be, and here's one companies's take on it.
>>
>> I would like to applaud Google for both being out front and talking
>> about their experiences.
>
> For some it's still impossible.  Eg any cable operator, why?  Consumer
> devices still don't have v6.  Even many "business" class devices do not.
>
> In my own experience I've run across Watchguard Firebox X Edge series,
> all
> lower end juniper ssg/netscreen devices -- though i'm told you can
> enable
> it from the CLI but it's unsupported, Juniper's M7i ASM as of 8.5R4.2
> while
> it'll let you setup stateful firewalling stuff for v6 connections, it
> just
> doesn't work at all.  I've not tried any other ASM/Services w/ v6
> though.
> And I'm sure the list goes on.
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



-- 
"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler


From vixie at isc.org  Fri Mar 27 15:19:36 2009
From: vixie at isc.org (Paul Vixie)
Date: Fri, 27 Mar 2009 19:19:36 +0000
Subject: [arin-ppml] "Google tries to break IPv6 logjam by own example"
	(C|Net News)
Message-ID: <67740.1238181576@nsa.vix.com>

"We're right now two to three years away from depleting IPv4 altogether,"
Richard Jimmerson, chief information officer of the American Registry for
Internet Numbers, said at the panel discussion. Late in the last decade and
early in this one, some predicted that the IPv4 address depletion is what
would cause the move to IPv6, he said. "Those folks who made those
predictions are partially correct."

http://news.cnet.com/8301-1001_3-10204391-92.html


From tony at lava.net  Fri Mar 27 15:49:57 2009
From: tony at lava.net (Antonio Querubin)
Date: Fri, 27 Mar 2009 09:49:57 -1000 (HST)
Subject: [arin-ppml] How hard is it to transition to IPv6?
In-Reply-To: <49CD14FB.3080709@zcorum.com>
References: <20090327162556.GA57288@ussenterprise.ufp.org>
	<942D9D7DDDDC80D26685B567@ZOP-MACTEL.local>
	<8A3DE12E408BBC499E40C0BE733C86030154CBB0@mail1.dulles.sv.int>
	<49CD14FB.3080709@zcorum.com>
Message-ID: <alpine.OSX.1.00.0903270930001.155@cust11794.lava.net>

On Fri, 27 Mar 2009, Scott Helms wrote:

>    I wish I were as optimistic as you, and my view is based on testing
> in our environment.  While it will be fairly easy for some kinds of
> companies this is going to be a total nightmare for ISP's.  It's pain
> that has to borne, but that doesn't make it easy to swallow.

I don't think it's that extreme for ISPs.  As with any major undertaking, 
it's best done by breaking the task up into small manageable pieces.  It 
will take time, but it's nowhere near as difficult as some say.  The key 
for us has been to integrate the necessary changes into normal equipment, 
infrastructure, and software/application update plans.  We started messing 
with IPv6 years ago, we're still not completely done yet, and some parts 
of our infrastructure and services may never be IPv6 ready.  But having 
started the transition process early means we're better prepared to handle 
any future customer requirements.

Antonio Querubin
whois:  AQ7-ARIN


From khelms at zcorum.com  Fri Mar 27 16:03:41 2009
From: khelms at zcorum.com (Scott Helms)
Date: Fri, 27 Mar 2009 16:03:41 -0400
Subject: [arin-ppml] How hard is it to transition to IPv6?
In-Reply-To: <alpine.OSX.1.00.0903270930001.155@cust11794.lava.net>
References: <20090327162556.GA57288@ussenterprise.ufp.org>
	<942D9D7DDDDC80D26685B567@ZOP-MACTEL.local>
	<8A3DE12E408BBC499E40C0BE733C86030154CBB0@mail1.dulles.sv.int>
	<49CD14FB.3080709@zcorum.com>
	<alpine.OSX.1.00.0903270930001.155@cust11794.lava.net>
Message-ID: <49CD311D.50607@zcorum.com>

Antonio,

    I'm frankly not that concerned about the pieces that I control, its 
the hundreds of thousands of end user devices that I don't.  In addition 
there are lot of pieces of gear that ISPs do control that don't have an 
upgrade path either because the vendor doesn't exist or the vendor 
decided to end of life the product.  I can tell you that most of the 
smaller ISPs still providing dial up, and yes there is still a ton of it 
out there, are doing it on old gear (much/most of that being Portmaster 
3s).  It's not that there isn't a solution, but it will be expensive and 
complicated and again that is before we include the issues with end user 
equipment.

Antonio Querubin wrote:
> On Fri, 27 Mar 2009, Scott Helms wrote:
>
>>    I wish I were as optimistic as you, and my view is based on testing
>> in our environment.  While it will be fairly easy for some kinds of
>> companies this is going to be a total nightmare for ISP's.  It's pain
>> that has to borne, but that doesn't make it easy to swallow.
>
> I don't think it's that extreme for ISPs.  As with any major 
> undertaking, it's best done by breaking the task up into small 
> manageable pieces.  It will take time, but it's nowhere near as 
> difficult as some say.  The key for us has been to integrate the 
> necessary changes into normal equipment, infrastructure, and 
> software/application update plans.  We started messing with IPv6 years 
> ago, we're still not completely done yet, and some parts of our 
> infrastructure and services may never be IPv6 ready.  But having 
> started the transition process early means we're better prepared to 
> handle any future customer requirements.
>
> Antonio Querubin
> whois:  AQ7-ARIN
>
>


-- 
Scott Helms
Vice President of Technology
ISP Alliance, Inc. DBA ZCorum
(678) 507-5000



From chris at uplogon.com  Fri Mar 27 16:13:48 2009
From: chris at uplogon.com (Chris Gotstein)
Date: Fri, 27 Mar 2009 15:13:48 -0500
Subject: [arin-ppml] How hard is it to transition to IPv6?
In-Reply-To: <49CD311D.50607@zcorum.com>
References: <20090327162556.GA57288@ussenterprise.ufp.org>	<942D9D7DDDDC80D26685B567@ZOP-MACTEL.local>	<8A3DE12E408BBC499E40C0BE733C86030154CBB0@mail1.dulles.sv.int>	<49CD14FB.3080709@zcorum.com>	<alpine.OSX.1.00.0903270930001.155@cust11794.lava.net>
	<49CD311D.50607@zcorum.com>
Message-ID: <49CD337C.8000206@uplogon.com>

Being a small ISP, i'll chime in with my thoughts on this.  We run a lot
of older equipment, most of it will not run IPv6 ever.  This goes for
all our dialup gear.  Dialup is dying a slow death.  I don't ever see
the need to convert our dialup users from IPv4.  Where i see the need in
our situation is on our high-speed customers like cable, dialup and
wireless.

We are going to start testing and doing limited deployment of IPv6 on
our routers and some office equipment (PCs, wireless APs, printers)
within the next year.  From there i would see us starting to be able to
offer IPv6 to our larger customers and maybe even pushing it out to new
sites that we deploy.  At this time, i don't see a need convert
everything over to IPv6.  But our goal would be to use IPv6 on any new
deployments that come up and for customers that are requesting it.

It's great to see the big guys doing this transition.  I think the next
logical step is for the small ISPs, like myself, to start the
transition.  We typically have a lot less equipment to deal with and can
be flexible in dealing with any conversion situations that come up.

Chris Gotstein
Sr Network Engineer
UP Logon/Computer Connection UP
500 N Stephenson Ave
Iron Mountain, MI 49801
Phone: 906-774-4847
Fax: 906-774-0335
chris at uplogon.com

Scott Helms wrote:
> Antonio,
> 
>     I'm frankly not that concerned about the pieces that I control, its 
> the hundreds of thousands of end user devices that I don't.  In addition 
> there are lot of pieces of gear that ISPs do control that don't have an 
> upgrade path either because the vendor doesn't exist or the vendor 
> decided to end of life the product.  I can tell you that most of the 
> smaller ISPs still providing dial up, and yes there is still a ton of it 
> out there, are doing it on old gear (much/most of that being Portmaster 
> 3s).  It's not that there isn't a solution, but it will be expensive and 
> complicated and again that is before we include the issues with end user 
> equipment.
> 
> Antonio Querubin wrote:
>> On Fri, 27 Mar 2009, Scott Helms wrote:
>>
>>>    I wish I were as optimistic as you, and my view is based on testing
>>> in our environment.  While it will be fairly easy for some kinds of
>>> companies this is going to be a total nightmare for ISP's.  It's pain
>>> that has to borne, but that doesn't make it easy to swallow.
>> I don't think it's that extreme for ISPs.  As with any major 
>> undertaking, it's best done by breaking the task up into small 
>> manageable pieces.  It will take time, but it's nowhere near as 
>> difficult as some say.  The key for us has been to integrate the 
>> necessary changes into normal equipment, infrastructure, and 
>> software/application update plans.  We started messing with IPv6 years 
>> ago, we're still not completely done yet, and some parts of our 
>> infrastructure and services may never be IPv6 ready.  But having 
>> started the transition process early means we're better prepared to 
>> handle any future customer requirements.
>>
>> Antonio Querubin
>> whois:  AQ7-ARIN
>>
>>
> 
> 



From jrhett at svcolo.com  Fri Mar 27 16:26:25 2009
From: jrhett at svcolo.com (Jo Rhett)
Date: Fri, 27 Mar 2009 13:26:25 -0700
Subject: [arin-ppml] Policy Proposal: Sunset 2008-6 on schedule
In-Reply-To: <49C3D28B.4060103@arin.net>
References: <49C3D28B.4060103@arin.net>
Message-ID: <DD8516FD-4AF4-4B61-8A6E-6B76E5E9AA37@svcolo.com>

I support this proposal in its entirety.

On Mar 20, 2009, at 10:29 AM, Member Services wrote:

> ARIN received the following policy proposal and is posting it to the
> Public Policy Mailing List (PPML) in accordance with Policy  
> Development
> Process.
>
> This proposal is in the first stage of the Policy Development Process.
> ARIN staff will perform the Clarity and Understanding step. Staff does
> not evaluate the proposal at this time, their goal is to make sure  
> that
> they understand the proposal and believe the community will as well.
> Staff will report their results to the ARIN Advisory Council (AC)  
> within
> 10 days.
>
> The AC will review the proposal at their next regularly scheduled
> meeting (if the period before the next regularly scheduled meeting is
> less than 10 days, then the period may be extended to the subsequent
> regularly scheduled meeting). The AC will decide how to utilize the
> proposal and announce the decision to the PPML.
>
> In the meantime, the AC invites everyone to comment on the proposal on
> the PPML, particularly their support or non-support and the reasoning
> behind their opinion. Such participation contributes to a thorough
> vetting and provides important guidance to the AC in their  
> deliberations.
>
> The ARIN Policy Development Process can be found at:
> http://www.arin.net/policy/pdp.html
>
> Mailing list subscription information can be found at:
> http://www.arin.net/mailing_lists/
>
> Regards,
>
> Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Policy Proposal Name: Sunset 2008-6 on schedule
>
> Proposal Originator: Owen DeLong
>
> Proposal Version: 1.0
>
> Date: 19 March 2009
>
> Proposal type: delete
>
> Policy term: permanent
>
> Policy statement:
>
> Effective March 31, 2012, the changes made to the NRPM by policy  
> 2008-6
> are to be deleted.
>
> Rationale:
>
> Part of the policy that the community developed consensus for in  
> 2008-6
> included a sunset clause.  The ARIN Board in an unprecedented action
> chose to discard this clause while approving the remainder of the  
> policy.
>
> This proposal is intended to restore the will of the community and
> ensure that this policy remains temporary as intended.
>
> Timetable for implementation: March 31, 2012
>
>
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.

-- 
Jo Rhett
senior geek

Silicon Valley Colocation
Support Phone: 408-400-0550





From tedm at ipinc.net  Fri Mar 27 16:27:43 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 27 Mar 2009 13:27:43 -0700
Subject: [arin-ppml] Draft Policy 2008-7: Identify Invalid WHOIS POC's
In-Reply-To: <49CCD2C1.6030005@verizonbusiness.com>
References: <49C7DD6E.3010106@arin.net> <49CCD2C1.6030005@verizonbusiness.com>
Message-ID: <C6DEAD436BB443C4B6A2414FCC5F1F39@tedsdesk>

Hi Heather, I didn't see the original posting from ARIN staff.

I believe they are mistaken in calling this an annual "reregistration" 
and I further feel the term carries a negative connotation.  This
is an annual verification.  It is only a reregistration for people
who do not have valid POC data in WHOIS.

The valid POCs can be handled by automated e-mail systems with a
specific URL link in the mail sent to the POC.  Network Solutions
already does this for ALL domain name holders in their registrar and
it's completely automated.  ARIN staff can contact Network Solutions
and ask how they do it if they do not understand how to do this.

ARIN staff was also given discretion in chasing after the bogus POCs
because the policy does NOT specify penalties other than those 
determined by ARIN staff.  In short, if ARIN staff doesen't want to
work on this they simply don't designate anyone as an invalid POC.
In other words, ARIN staff is being given authority to manage
the work this proposal generates and how much work it generates.

Obviously, priority should be given to bogus POC data associated with
the LARGEST registered IPv4 blocks, when they get those cleared
away, they can work on the smaller ones.

The hijacking argument is utterly illogical.  What makes an abandonded
block that has no POCs on it any more attractive than a "virgin" block
from the unassigned pool IANA just handed them?  And when Ipv4 runout
happens then ALL free unassigned blocks (blocks returned to ARIN through
attrition) will be exactly the same status.

The policy did not refer to the bulk whois request.  It states for
ARIN staff to make a report to the entire membership.

What is ARIN expecting when IPv4 runout happens?  That they will conceal
from the memership the numbers and existence of abandonded IPv4 blocks
with no POCs on them?  This would represent a policy shift from how
things are now - right now, we know the numbers of unassigned blocks.
There should be no restrictions on requesting a list of unassigned
blocks that were formerly occupied, vs unassigned blocks that were
never formerly occupied.

The only possible issue would be disclosing the list of "pending
unassigned" blocks to the public.  The policy simply does not speak
to specifics for this, because it does not carry any requirement to
ARIN staff to disclose the detailed list of those.  It only states to make a
report, period.  If ARIN is concerned with hijacking on that list,
they are not required by this policy to publish anything more than
a summary report, and making the changes in WHOIS itself.

Ted

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Heather Schiller
> Sent: Friday, March 27, 2009 6:21 AM
> To: Member Services
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy 2008-7: Identify 
> Invalid WHOIS POC's
> 
> 
> Feedback on ARIN Staff Comments:
> 
> 1) Hijacking - this is already a problem today.  Providing a 
> list of resources with stale records is essentially a list of 
> resources at risk, which will allow providers to have 
> something to check against before they route the block.
> 
> 2) Workload - in many ways this is work that is already done 
> when billing POC's go invalid.  Arguably, ARIN should have 
> been checking POC validity on a recurring basis from the beginning.
> 
> 3) Bulk Whois Reference - ARIN has the operational details of 
> going through the bulk whois process on 
> https://www.arin.net/resources/request/bulkwhois.html  which 
> includes a requirement to sign an AUP.  Other sections of 
> existing policy do not include operational details or further 
> requirements for the bulk whois process.  The authors believe 
> the process of signing the bulk whois agreement to be an 
> operational process on the part of ARIN staff and not part of policy.
> 
> 4) Threat of lawsuit - I understand council's comment to mean 
> - if we properly announce and enforce it should be ok.  I am 
> also thinking, as long as ARIN has a (an operational) process 
> to re-establish/validate the POC, that would help mitigate 
> any problems, correct?
> 
> 5) Resource Impact - Yes, it will take new development and 
> time to get this process in place, however the potential 
> benefit to the community is also significant.
> 
> --Heather
> 
> Member Services wrote:
> <snip>
> > ARIN Staff Assessment
> > 
> > 2008-7
> > 
> > Title:  Identify Invalid WHOIS POC's (formerly known as WHOIS 
> > Integrity Policy Proposal)
> > 
> > Revision Submitted: 07 March 2008
> > 
> > 2nd Revision Submitted: 12 Feb 2009
> > 
> > Date of Assessment:  24 Feb 2009
> > 
> > The assessment of this text includes comments from ARIN 
> staff and the 
> > ARIN General Counsel. It contains analysis of procedural, 
> legal, and 
> > resource concerns regarding the implementation of this text 
> as it is 
> > currently stated. Any changes to the language may 
> necessitate further 
> > analysis by staff and Counsel.
> > 
> > I.  Understanding
> > 
> > ARIN staff understands that this will institute an annual 
> > re-registration of all POCs registered in WHOIS.  POCs who do not 
> > respond within 60 days will be marked in the database as 
> "un-responsive"
> > and if staff deems them to be invalid for any reason, may 
> remove them 
> > from WHOIS.  In addition, staff will maintain a list of all address 
> > blocks with no valid POCs and will make this data available to any 
> > organization using the bulk whois policy criteria.
> > 
> > II.  Issues and Concerns
> > 
> >   A.  ARIN Staff Comments:
> > 
> >     * Resource records marked as "unresponsive" or those 
> with no POCs at
> >       all could become the targets of hijackers who, in the 
> past have
> >       tended to look for address blocks that contain 
> obsolete or stale data.
> >     *  An annual re-registration of all POCs (~223,000 
> currently) will
> >       likely result in a vast increase in workload, 
> particularly with
> >       the follow up work and research involved when a POC 
> does not reply
> >       within 60 days.  This could result in a slow down in 
> registration
> >       response and processing times.
> > 
> > 
> > 
> >     * This policy refers to the Bulk Whois policy rather 
> than stating
> >       the actual criteria under which an organization will 
> be allowed to
> >       request the list of all address blocks with no valid POCs.  It
> >       would be better policy text to state the specific criteria,
> >       including the requirement to sign an AUP, within this 
> policy itself.
> > 
> > 
> > 
> >   B.  ARIN General Counsel
> > 
> >     * It is possible those delisted will threaten or file 
> litigation to
> >       be relisted. However, a properly promulgated policy 
> does not pose
> >       antirust or other legal concerns.
> > 
> > 
> > 
> > III. Resource Impact
> > 
> > The resource impact of implementing this policy is viewed as 
> > significant. Barring any unforeseen resource requirements, it is 
> > estimated that this policy could take up to 18 person 
> months to fully 
> > implement from the date of ratification of the policy by the ARIN 
> > Board of Trustees.  It may require the following:
> > 
> >     * Staff training
> >     * Development of new internal process and procedures and
> >       modification to existing ones
> >     * Creation of an automated system to track 
> notifications, updates,
> >       and current status of the POC notification. Provide 
> allowances for
> >       manual intervention and follow-up by staff.  
> Engineering estimates
> >       that it could take up to 18 person months for the creation and
> >       implementation of this system. In addition, this could impact
> >       ARIN's current project deployment schedule.
> >     * Increased workload could result in the need for 
> additional staff
> > 
> > 
> > 
> > Text assessed:
> > 
> > 2008-7: Identify Invalid WHOIS POC's (formally known as WHOIS 
> > Integrity Policy Proposal)
> > 
> > Revised text is as follows:
> > 
> > During ARINs annual WHOIS POC validation, an e-mail will be sent to 
> > every POC in the WHOIS database. Each POC will have a maximum of 60 
> > days to respond with an affirmative that their WHOIS contact 
> > information is correct and complete. Unresponsive POC email 
> addresses 
> > shall be marked as such in the database. If ARIN staff 
> deems a POC to 
> > be completely and permanently abandoned or otherwise 
> illegitimate, the 
> > record shall be deleted. ARIN will maintain, and make readily 
> > available to the community, a current list of 
> address-blocks with no 
> > valid POC; this data will be subject to the current bulk 
> WHOIS policy.
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed 
> to the ARIN 
> > Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> > 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 
> 



From jrhett at svcolo.com  Fri Mar 27 16:33:02 2009
From: jrhett at svcolo.com (Jo Rhett)
Date: Fri, 27 Mar 2009 13:33:02 -0700
Subject: [arin-ppml] Draft Policy 2009-3 (Global): Allocation of IPv4
	Blocks to Regional Internet Registries
In-Reply-To: <49C7EB0F.3030800@gmail.com>
References: <49C7DD87.4010508@arin.net> <49C7EB0F.3030800@gmail.com>
Message-ID: <3928B421-C83D-4BB4-A5C2-4096EA4BF704@svcolo.com>


On Mar 23, 2009, at 1:03 PM, Scott Leibrand wrote:
> I would love to get feedback from PPML on the following questions:
> - What do you think of the general idea behind this proposal?
> - Do you think returns should be mandatory or optional?  Would you
> distinguish between legacy and non-legacy space?
> - Do you have any other detailed feedback on specific aspects of this
> draft policy?


Perhaps I'm being dense, but I can't figure out who this benefits.  A  
proposal always benefits someone.  Can you tell me who this proposal  
is supposed to benefit?

In short:
	ARIN will lose space -- doesn't benefit ARIN.
	No incentive to recover space -- doesn't benefit anyone except  
perhaps people who never want to give up space.

-- 
Jo Rhett
senior geek

Silicon Valley Colocation
Support Phone: 408-400-0550





From tedm at ipinc.net  Fri Mar 27 16:32:49 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 27 Mar 2009 13:32:49 -0700
Subject: [arin-ppml] How hard is it to transition to IPv6?
In-Reply-To: <942D9D7DDDDC80D26685B567@ZOP-MACTEL.local>
References: <20090327162556.GA57288@ussenterprise.ufp.org>
	<942D9D7DDDDC80D26685B567@ZOP-MACTEL.local>
Message-ID: <6D8B9E8AC67347C8B8943FEFB3C601B7@tedsdesk>


check out the dd-wrt firmware, it can be loaded on many of the small
consumer devices and it's rock solid.  IPv6 support was in the prior
release of it, was broken in the current release, and is fixed in
the beta releases.

Ted 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Michael Loftis
> Sent: Friday, March 27, 2009 9:32 AM
> To: Leo Bicknell; arin-ppml at arin.net
> Subject: Re: [arin-ppml] How hard is it to transition to IPv6?
> 
> 
> 
> --On March 27, 2009 11:25:56 AM -0500 Leo Bicknell 
> <bicknell at ufp.org> wrote:
> 
> >
> > http://www.networkworld.com/news/2009/032509-google-ipv6-easy.html
> >
> > At the IETF meeting there was a panel discussion on transitioing to 
> > IPv6, at which Google gave their perspective.  I know a lot 
> of folks 
> > have been looking for some more concrete information on how 
> hard the 
> > transition will be, and here's one companies's take on it.
> >
> > I would like to applaud Google for both being out front and talking 
> > about their experiences.
> 
> For some it's still impossible.  Eg any cable operator, why?  
> Consumer devices still don't have v6.  Even many "business" 
> class devices do not. 
> In my own experience I've run across Watchguard Firebox X 
> Edge series, all lower end juniper ssg/netscreen devices -- 
> though i'm told you can enable it from the CLI but it's 
> unsupported, Juniper's M7i ASM as of 8.5R4.2 while it'll let 
> you setup stateful firewalling stuff for v6 connections, it 
> just doesn't work at all.  I've not tried any other 
> ASM/Services w/ v6 though. 
> And I'm sure the list goes on.
> 
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 



From kkargel at polartel.com  Fri Mar 27 16:35:49 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Fri, 27 Mar 2009 15:35:49 -0500
Subject: [arin-ppml] How hard is it to transition to IPv6?
In-Reply-To: <942D9D7DDDDC80D26685B567@ZOP-MACTEL.local>
References: <20090327162556.GA57288@ussenterprise.ufp.org>
	<942D9D7DDDDC80D26685B567@ZOP-MACTEL.local>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AF3C@mail>

> --On March 27, 2009 11:25:56 AM -0500 Leo Bicknell <bicknell at ufp.org>
> wrote:
> 
> >
> > http://www.networkworld.com/news/2009/032509-google-ipv6-easy.html
> >
> > At the IETF meeting there was a panel discussion on transitioing
> > to IPv6, at which Google gave their perspective.  I know a lot of
> > folks have been looking for some more concrete information on how
> > hard the transition will be, and here's one companies's take on it.
> >
> > I would like to applaud Google for both being out front and talking
> > about their experiences.
> 
> For some it's still impossible.  Eg any cable operator, why?  Consumer
> devices still don't have v6.  Even many "business" class devices do not.
> In my own experience I've run across Watchguard Firebox X Edge series, all
> lower end juniper ssg/netscreen devices -- though i'm told you can enable
> it from the CLI but it's unsupported, Juniper's M7i ASM as of 8.5R4.2
> while
> it'll let you setup stateful firewalling stuff for v6 connections, it just
> doesn't work at all.  I've not tried any other ASM/Services w/ v6 though.
> And I'm sure the list goes on.

Difficult yes, impossible no.  There is nothing to stop a cable operator
from running IPv4 inside, even on private addresses, and then doing PAT to
the outside.  One to one PAT would function.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090327/9d33a8ad/attachment.bin>

From tedm at ipinc.net  Fri Mar 27 16:37:00 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 27 Mar 2009 13:37:00 -0700
Subject: [arin-ppml] How hard is it to transition to IPv6?
In-Reply-To: <49CD1524.5080200@matthew.at>
References: <20090327162556.GA57288@ussenterprise.ufp.org>
	<49CD1524.5080200@matthew.at>
Message-ID: <131D9C7318964D48AC33CC9768985A3C@tedsdesk>

 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Matthew Kaufman
> Sent: Friday, March 27, 2009 11:04 AM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] How hard is it to transition to IPv6?
> 
> Leo Bicknell wrote:
> > http://www.networkworld.com/news/2009/032509-google-ipv6-easy.html
> >
> >   
> Google has the advantage that they have the source code to 
> the applications and developers on staff to modify that code.
> 
> This is not the case for most of the world's users of 
> computers and/or embedded devices. They are looking at 
> whether or not an upgrade is available, and if not whether or 
> not a new program or device is available that does what their 
> existing things do. In some cases a solution is not currently 
> available at any price.
> 

And it will not be, because those were least-cost devices that
were designed by the manufacturer with a finite lifespan.

What the problem is that it's hard to convince someone that the
device they have had for the last 5 years that's still working
perfectly, will not get support from the manufacturer for upgrades.
People tend to forget that the money they saved by buying the
cheap device will need to be spent in the future on a new device,
ie; there ain't no free lunch.

SO far the only really egregious violation of this was from Cisco,
who promised IPv6 support in mainline 12.1 and 12.2 IOS then
never delivered until 12.3 IOS which doesn't run properly on
a large amount of gear that was purchased when Cisco was promising
IPv6 would be available for that gear.

Ted



From bill at herrin.us  Fri Mar 27 16:39:20 2009
From: bill at herrin.us (William Herrin)
Date: Fri, 27 Mar 2009 16:39:20 -0400
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using the
	Emergency PDP)
In-Reply-To: <49C911A8.5020009@arin.net>
References: <49C911A8.5020009@arin.net>
Message-ID: <3c3e3fca0903271339q6dd8f49ekeced041da77ca979@mail.gmail.com>

On Tue, Mar 24, 2009 at 1:00 PM, Member Services <info at arin.net> wrote:
> Draft Policy 2009-1: Transfer Policy is available below and at:
> https://www.arin.net/policy/proposals/2009_1.html

First off, here's a diff so you can see how 2009-1 would impact
section 8 in the NRPM:

http://bill.herrin.us/network/diff-2009-01.html

Some comments:

1. I adamantly OPPOSE adoption of this policy. There is no emergency
here and the use of the emergency policy process is wrongheaded and
wholly inappropriate. Should the board desire the adoption of this
policy text, it should offer it through the normal process where its
errors can be identified and corrected.

2. The changed text in 8.2 implies that a transfer of resources will
not be permitted except as a result of a merger or acquisition. Does
this rule out any kind of transfer that was previously permitted? If
so, what?

3. The original use of the word "effecting" was correct. The
instrument(s) effecting the transfer of assets. You don't affect a
change, you effect a change. The use of the word "affecting" in 2009-1
is incorrect.

Ref: http://www.wsu.edu/~brians/errors/affect.html
Ref: http://grammar.quickanddirtytips.com/affect-versus-effect.aspx

4. 2008-06 intentionally sunsetted section 8.4 three years after
adoption. This was no accident: the community has long been suspicious
of processes that effectively permit the sale of IP addresses from one
party to another. We're willing to give it a chance, but if we don't
like what we see, we don't want to have to fight again to take the
policy back out... especially with the board hinting it might try
sketchy procedural maneuvers in order to overrule such an effort.

5. From the flow of the text in 8.2 and 2009-1's 8.3, it isn't clear
whether the 8.3 is intended to clarify 8.2 or be separate from it. I
suggest retitling the sections "8.2 Transfers due to mergers and
acquisitions" and "8.3 Other transfers"

6. 2008-6 applied only to IPv4 addresses. 2009-1 applies to all number
resources. I don't personally care either way, but the consensus was
clearly for a policy that was limited in scope.

7. Although it didn't explicitly make it in to 2008-6's final text,
there was an implication that specific assignments transferred in this
manner should not be chopped up. You could release a particular
assignment, or not. Any chopping would be done at ARIN's discretion.

2009-1 explicitly states the opposite. It could reasonably be read to
permit a /32 to be released from a /16 even though current ARIN policy
does not permit new direct assignments of IPv4 /32's. 2009-1's
explicit limitation is whether the recipient can justify the address
count, not whether the assignment meets current policy overall.


For reason #1 above, I adamantly OPPOSE adoption of this policy.
Comments #2-#7 illustrate the need for this policy proposal to get the
same full treatment as every other policy proposal.

Regards,
Bill Herrin




-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From jrhett at svcolo.com  Fri Mar 27 16:40:08 2009
From: jrhett at svcolo.com (Jo Rhett)
Date: Fri, 27 Mar 2009 13:40:08 -0700
Subject: [arin-ppml] Draft Policy 2009-4: IPv4 Recovery Fund
In-Reply-To: <49C7DD9A.6030907@arin.net>
References: <49C7DD9A.6030907@arin.net>
Message-ID: <CA9B0760-9C35-4AE6-ADCC-E899FCA3C241@svcolo.com>


On Mar 23, 2009, at 12:06 PM, Member Services wrote:
> 4.X.4 Address Block Management
>
> ARIN may not offer a partial fill, that is provide a block
> smaller than the one for which the requester was approved.
>
> ARIN may split recovered blocks into multiple smaller blocks
> at the staff's discretion using the following principals:
> - It is unlikely a request will be made for the address
> block size involved in the next 60 days.
> - The block is divided into as few parts as practical.
> - There are enough bids to allow the entire block to be
> allocated.

Without having yet a final opinion on the policy, if I did support it  
I would offer that this entire section should be deleted. What if they  
have a need but only for 7/8ths of the block.  Could they not use it?   
That's downright silly.   There's no need to micro-manage the day-to- 
day workings of ARIN.

> 4.X.5 Transparency
>
> ARIN staff shall make public the current and historical
> prices of asks, bids, and executed transactions in a manor
> that facilitates the bidding process.

Is this a country property we'll be visiting to view the  
transactions?  Or do you mean "manner"?   And frankly, "a manner" is  
pretty wide open.  Let's be explicit: "Will publish ... available  
to ..."

> ARIN may:
> - Use ARIN funds to reclaim blocks when there is no specific
> demand; if such reclamation is deemed in the best interest
> of the community and there is a significant likelyhood of
> future demand.
> - Use a portion of the funds collected under this program
> to pay for the implementation of this program.

Even if I thought this was a good idea, the above paragraph would make  
me reconsider it.  So for right now, I think I'm against this policy.   
ARIN has enough to do without trying to be and play a market.

-- 
Jo Rhett
senior geek

Silicon Valley Colocation
Support Phone: 408-400-0550





From matthew at matthew.at  Fri Mar 27 16:41:24 2009
From: matthew at matthew.at (Matthew Kaufman)
Date: Fri, 27 Mar 2009 13:41:24 -0700
Subject: [arin-ppml] How hard is it to transition to IPv6?
In-Reply-To: <131D9C7318964D48AC33CC9768985A3C@tedsdesk>
References: <20090327162556.GA57288@ussenterprise.ufp.org>
	<49CD1524.5080200@matthew.at>
	<131D9C7318964D48AC33CC9768985A3C@tedsdesk>
Message-ID: <49CD39F4.8020502@matthew.at>

Ted Mittelstaedt wrote:
>
> And it will not be, because those were least-cost devices that
> were designed by the manufacturer with a finite lifespan.
>
>   
Not always true. There's all sorts of industrial process control 
equipment, for example, that was made to last forever, was supported 
well while the maker was in business, but is now not easily replaced 
with anything that exists and has IPv6 support.

Matthew Kaufman


From tedm at ipinc.net  Fri Mar 27 16:41:10 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 27 Mar 2009 13:41:10 -0700
Subject: [arin-ppml] How hard is it to transition to IPv6?
In-Reply-To: <49CD311D.50607@zcorum.com>
References: <20090327162556.GA57288@ussenterprise.ufp.org><942D9D7DDDDC80D26685B567@ZOP-MACTEL.local><8A3DE12E408BBC499E40C0BE733C86030154CBB0@mail1.dulles.sv.int><49CD14FB.3080709@zcorum.com><alpine.OSX.1.00.0903270930001.155@cust11794.lava.net>
	<49CD311D.50607@zcorum.com>
Message-ID: <0B10E1EDDFB24DEAAAD098D3F54369C9@tedsdesk>


But but but,

There's other drivers that push end user purchasing.  For example
the latest cheap-end Linksys gear now filters bittorrent and all
the other nasty chatting and p2p stuff that was designed to
bypass firewalls.   As viruses get more sophisticated the cheap
stuff is following along blocking it.  Sooner or later the value
of buying the new cheap router or DSL or cable modem will outweigh
the few bucks saved keeping the old stuff running, despite IPv6

Ted

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Helms
> Sent: Friday, March 27, 2009 1:04 PM
> To: Antonio Querubin
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] How hard is it to transition to IPv6?
> 
> Antonio,
> 
>     I'm frankly not that concerned about the pieces that I 
> control, its the hundreds of thousands of end user devices 
> that I don't.  In addition there are lot of pieces of gear 
> that ISPs do control that don't have an upgrade path either 
> because the vendor doesn't exist or the vendor decided to end 
> of life the product.  I can tell you that most of the smaller 
> ISPs still providing dial up, and yes there is still a ton of 
> it out there, are doing it on old gear (much/most of that 
> being Portmaster 3s).  It's not that there isn't a solution, 
> but it will be expensive and complicated and again that is 
> before we include the issues with end user equipment.
> 
> Antonio Querubin wrote:
> > On Fri, 27 Mar 2009, Scott Helms wrote:
> >
> >>    I wish I were as optimistic as you, and my view is based on 
> >> testing in our environment.  While it will be fairly easy for some 
> >> kinds of companies this is going to be a total nightmare 
> for ISP's.  
> >> It's pain that has to borne, but that doesn't make it easy 
> to swallow.
> >
> > I don't think it's that extreme for ISPs.  As with any major 
> > undertaking, it's best done by breaking the task up into small 
> > manageable pieces.  It will take time, but it's nowhere near as 
> > difficult as some say.  The key for us has been to integrate the 
> > necessary changes into normal equipment, infrastructure, and 
> > software/application update plans.  We started messing with 
> IPv6 years 
> > ago, we're still not completely done yet, and some parts of our 
> > infrastructure and services may never be IPv6 ready.  But having 
> > started the transition process early means we're better prepared to 
> > handle any future customer requirements.
> >
> > Antonio Querubin
> > whois:  AQ7-ARIN
> >
> >
> 
> 
> --
> Scott Helms
> Vice President of Technology
> ISP Alliance, Inc. DBA ZCorum
> (678) 507-5000
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 



From bill at herrin.us  Fri Mar 27 16:57:58 2009
From: bill at herrin.us (William Herrin)
Date: Fri, 27 Mar 2009 16:57:58 -0400
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using the
	Emergency PDP)
In-Reply-To: <3c3e3fca0903271339q6dd8f49ekeced041da77ca979@mail.gmail.com>
References: <49C911A8.5020009@arin.net>
	<3c3e3fca0903271339q6dd8f49ekeced041da77ca979@mail.gmail.com>
Message-ID: <3c3e3fca0903271357t12ada8a7qfb57f222b05cfb86@mail.gmail.com>

On Fri, Mar 27, 2009 at 4:39 PM, William Herrin <bill at herrin.us> wrote:
> On Tue, Mar 24, 2009 at 1:00 PM, Member Services <info at arin.net> wrote:
>> Draft Policy 2009-1: Transfer Policy is available below and at:
>> https://www.arin.net/policy/proposals/2009_1.html
>
> First off, here's a diff so you can see how 2009-1 would impact
> section 8 in the NRPM:
>
> http://bill.herrin.us/network/diff-2009-01.html
>
> Some comments:

Another one:

#8. Under normal ARIN policy, any legal entity which can justify its
request may receive number resources. Though normally companies or
other organizations, this does occasionally apply to individuals. AS
11875 for example.

2009-1 restricts the transfer recipients to "organizations." 2008-6
retains ARIN's broader definition of eligible recipients.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From khelms at zcorum.com  Fri Mar 27 16:59:53 2009
From: khelms at zcorum.com (Scott Helms)
Date: Fri, 27 Mar 2009 16:59:53 -0400
Subject: [arin-ppml] How hard is it to transition to IPv6?
In-Reply-To: <0B10E1EDDFB24DEAAAD098D3F54369C9@tedsdesk>
References: <20090327162556.GA57288@ussenterprise.ufp.org><942D9D7DDDDC80D26685B567@ZOP-MACTEL.local><8A3DE12E408BBC499E40C0BE733C86030154CBB0@mail1.dulles.sv.int><49CD14FB.3080709@zcorum.com><alpine.OSX.1.00.0903270930001.155@cust11794.lava.net>
	<49CD311D.50607@zcorum.com>
	<0B10E1EDDFB24DEAAAD098D3F54369C9@tedsdesk>
Message-ID: <49CD3E49.20302@zcorum.com>

Ted,

    That is certainly true, but that doesn't (unfortunately) drive the 
decisions of many and perhaps most retail consumers.  I live in an 
upscale Atlanta suburb, but doing some simple scans around my 
neighborhood shows that almost half of the wireless access points are 
wide open.  What's worse more than half of the open AP's still have 
default passwords on the device itself.  Now, that's completely 
anecdotal but I do the same test as I travel around the country and so 
far the results aren't far off.  Even around tech oriented areas I've 
seen much higher rates of owner indifference/ignorance being displayed.  
If large numbers of people in RTP are doing this, what are the chances 
that people living in rural markets are doing better?  (I do see fewer 
open systems around Research Triangle Park, but roughly 1 out 3 is still 
terrible.)  The problem for ISPs is that at the retail level many 
customers don't understand, and taking care of them will be tremendously 
expensive in terms of human resources and gear.

Ted Mittelstaedt wrote:
> But but but,
>
> There's other drivers that push end user purchasing.  For example
> the latest cheap-end Linksys gear now filters bittorrent and all
> the other nasty chatting and p2p stuff that was designed to
> bypass firewalls.   As viruses get more sophisticated the cheap
> stuff is following along blocking it.  Sooner or later the value
> of buying the new cheap router or DSL or cable modem will outweigh
> the few bucks saved keeping the old stuff running, despite IPv6
>
> Ted
>
>   
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net 
>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Helms
>> Sent: Friday, March 27, 2009 1:04 PM
>> To: Antonio Querubin
>> Cc: arin-ppml at arin.net
>> Subject: Re: [arin-ppml] How hard is it to transition to IPv6?
>>
>> Antonio,
>>
>>     I'm frankly not that concerned about the pieces that I 
>> control, its the hundreds of thousands of end user devices 
>> that I don't.  In addition there are lot of pieces of gear 
>> that ISPs do control that don't have an upgrade path either 
>> because the vendor doesn't exist or the vendor decided to end 
>> of life the product.  I can tell you that most of the smaller 
>> ISPs still providing dial up, and yes there is still a ton of 
>> it out there, are doing it on old gear (much/most of that 
>> being Portmaster 3s).  It's not that there isn't a solution, 
>> but it will be expensive and complicated and again that is 
>> before we include the issues with end user equipment.
>>
>> Antonio Querubin wrote:
>>     
>>> On Fri, 27 Mar 2009, Scott Helms wrote:
>>>
>>>       
>>>>    I wish I were as optimistic as you, and my view is based on 
>>>> testing in our environment.  While it will be fairly easy for some 
>>>> kinds of companies this is going to be a total nightmare 
>>>>         
>> for ISP's.  
>>     
>>>> It's pain that has to borne, but that doesn't make it easy 
>>>>         
>> to swallow.
>>     
>>> I don't think it's that extreme for ISPs.  As with any major 
>>> undertaking, it's best done by breaking the task up into small 
>>> manageable pieces.  It will take time, but it's nowhere near as 
>>> difficult as some say.  The key for us has been to integrate the 
>>> necessary changes into normal equipment, infrastructure, and 
>>> software/application update plans.  We started messing with 
>>>       
>> IPv6 years 
>>     
>>> ago, we're still not completely done yet, and some parts of our 
>>> infrastructure and services may never be IPv6 ready.  But having 
>>> started the transition process early means we're better prepared to 
>>> handle any future customer requirements.
>>>
>>> Antonio Querubin
>>> whois:  AQ7-ARIN
>>>
>>>
>>>       
>> --
>> Scott Helms
>> Vice President of Technology
>> ISP Alliance, Inc. DBA ZCorum
>> (678) 507-5000
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to 
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
>>     
>
>
>
>   


-- 
Scott Helms
Vice President of Technology
ISP Alliance, Inc. DBA ZCorum
(678) 507-5000



From michael.dillon at bt.com  Fri Mar 27 16:59:28 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Fri, 27 Mar 2009 20:59:28 -0000
Subject: [arin-ppml] How hard is it to transition to IPv6?
In-Reply-To: <20090327182129.GA62899@ussenterprise.ufp.org>
Message-ID: <28E139F46D45AF49A31950F88C49745859BFB5@E03MVZ2-UKDY.domain1.systemhost.net>

> Google has shown with the source code and programmers you can 
> fix the software in ~18 months.  That's good news, isn't it?  
> If we can all drive home the requirements to the vendors it 
> seems like there is plenty of time to get stuff fixed and 
> deployed before it is an issue.

Bingo!

People are wasting their breath complaining here. They should be beating
down their vendors doors to fix the IPv6 problem, and if it is equipment
bought within the last couple of years and the vendors down't have it
high enough priority with delivery promised in the next 18 months, then
they should immediately take those vendors to court and sue for damages.
Get back all the money you paid, any costs of switching out the crap
equipment for another brand that can (or will) handle IPv6, plus
damages.

Lots of companies have been negligent, both hardware/software vendors
and network operators. Of course there is still enough time to recover
from these mistakes if a company makes it a priority and sets some firm
internal targets, but if one of your suppliers is not willing to make
firm promisies, then take them to court and tear them to shreds now
before they go bankrupt. Fact is that when IPv6 takes off it will be a
flurry of activity and a lot of that will be companies moving away from
suppliers who do not have enough IPv6 support. That will drive some
companies into bankruptcy. That's just the way the economy works and in
my personal opinion it is better for the economy to drive those
companies into bankruptcy sooner rather than later.

The time has come for everyone to stop denial and admit that
circumstances are forcing us to deploy IPv6 regardless of whether it has
the kind of business case that we prefer. If senior management is not
past the denial stage and into the action stage then they are
incompetent. Enough network operators have already moved into the action
stage as well as companies like Google. It is clear that IPv6 deployment
is the way forward out of this addressing mess.

--Michael Dillon



From ppml at rsuc.gweep.net  Fri Mar 27 17:12:42 2009
From: ppml at rsuc.gweep.net (Joe Provo)
Date: Fri, 27 Mar 2009 17:12:42 -0400
Subject: [arin-ppml] How hard is it to transition to IPv6?
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D030878AB24A@ex1.cait.wustl.edu>
References: <20090327162556.GA57288@ussenterprise.ufp.org>
	<EACF8B735E9CBA4B8BAF9E4165D030878AB24A@ex1.cait.wustl.edu>
Message-ID: <20090327211242.GA67585@gweep.net>

On Fri, Mar 27, 2009 at 11:33:22AM -0500, Bill Darte wrote:
> Nice catch Leo.
> And good news for the industry....
> Are you all listening out there???

Restricting AAAAs to pre-vetted DNS neigbors is now considered 
best practice?  I suppose if you're ggoing to set aside the 
assumption that dual-stack to the desk/handheld is easy or 
realistic, then there are a lot of ways to provide V6 services 
to V6 nodes and v4 services to v4 nodes.  That pesky cross-over
between all the existing v4 stuff and additional v6 stuff is 
the hard part.


-- 
             RSUC / GweepNet / Spunk / FnB / Usenix / SAGE


From khelms at zcorum.com  Fri Mar 27 17:26:51 2009
From: khelms at zcorum.com (Scott Helms)
Date: Fri, 27 Mar 2009 17:26:51 -0400
Subject: [arin-ppml] How hard is it to transition to IPv6?
In-Reply-To: <28E139F46D45AF49A31950F88C49745859BFB5@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C49745859BFB5@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <49CD449B.1060309@zcorum.com>

Michael,

    That is an interesting choice of words.  I don't know what kind of 
people you work for/with (I assume from your email address BT) but I can 
tell you that if I told my customers, who are ISPs, that they should 
stop "complaining" because they were "negligent" the response wouldn't 
be all that friendly.  There are hard economic realities here and it is 
very easy for someone to simply say the small providers don't matter, 
but there are lots areas in the US that wouldn't have service (phone, 
cable, or Internet) if it weren't for small and apparently "negligent" 
providers.  What are ISPs supposed to do with customers that can't 
afford a compliant device?  Cut them off?  Replace the device 
ourselves?  Globally ~1.4% of active browsing sessions are from systems 
running Win 2000 and I don't have any problem saying that percentage is 
much higher in rural markets.  I still have some providers who report 
significant usage of Win 98.  While there is an unofficial patch out 
there for Win 2000 (and steering customers to it is a whole new issue) 
AFAIK there isn't anything for 98.

http://www.w3schools.com/browsers/browsers_os.asp


Finally, I am well aware that the transition will happen, you only have 
to look here:
http://i.i.com.com/cnwk.1d/i/bto/20090325/ipv4_exhaustion_comcast.png

to see that we won't have any choice sometime very soon.  What I object 
to is the idea that because Google was able to make the transition 
internally with "ease" that it will be all goodness and light for other 
kinds of service providers.


michael.dillon at bt.com wrote:
>> Google has shown with the source code and programmers you can 
>> fix the software in ~18 months.  That's good news, isn't it?  
>> If we can all drive home the requirements to the vendors it 
>> seems like there is plenty of time to get stuff fixed and 
>> deployed before it is an issue.
>>     
>
> Bingo!
>
> People are wasting their breath complaining here. They should be beating
> down their vendors doors to fix the IPv6 problem, and if it is equipment
> bought within the last couple of years and the vendors down't have it
> high enough priority with delivery promised in the next 18 months, then
> they should immediately take those vendors to court and sue for damages.
> Get back all the money you paid, any costs of switching out the crap
> equipment for another brand that can (or will) handle IPv6, plus
> damages.
>
> Lots of companies have been negligent, both hardware/software vendors
> and network operators. Of course there is still enough time to recover
> from these mistakes if a company makes it a priority and sets some firm
> internal targets, but if one of your suppliers is not willing to make
> firm promisies, then take them to court and tear them to shreds now
> before they go bankrupt. Fact is that when IPv6 takes off it will be a
> flurry of activity and a lot of that will be companies moving away from
> suppliers who do not have enough IPv6 support. That will drive some
> companies into bankruptcy. That's just the way the economy works and in
> my personal opinion it is better for the economy to drive those
> companies into bankruptcy sooner rather than later.
>
> The time has come for everyone to stop denial and admit that
> circumstances are forcing us to deploy IPv6 regardless of whether it has
> the kind of business case that we prefer. If senior management is not
> past the denial stage and into the action stage then they are
> incompetent. Enough network operators have already moved into the action
> stage as well as companies like Google. It is clear that IPv6 deployment
> is the way forward out of this addressing mess.
>
> --Michael Dillon
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
>
>   


-- 
Scott Helms
Vice President of Technology
ISP Alliance, Inc. DBA ZCorum
(678) 507-5000



From mloftis at wgops.com  Fri Mar 27 17:40:56 2009
From: mloftis at wgops.com (Michael Loftis)
Date: Fri, 27 Mar 2009 15:40:56 -0600
Subject: [arin-ppml] How hard is it to transition to IPv6?
In-Reply-To: <6D8B9E8AC67347C8B8943FEFB3C601B7@tedsdesk>
References: <20090327162556.GA57288@ussenterprise.ufp.org>
	<942D9D7DDDDC80D26685B567@ZOP-MACTEL.local>
	<6D8B9E8AC67347C8B8943FEFB3C601B7@tedsdesk>
Message-ID: <87390B2DDDE148072A5ACF1B@ZOP-MACTEL.local>



--On March 27, 2009 1:32:49 PM -0700 Ted Mittelstaedt <tedm at ipinc.net> 
wrote:

>
> check out the dd-wrt firmware, it can be loaded on many of the small
> consumer devices and it's rock solid.  IPv6 support was in the prior
> release of it, was broken in the current release, and is fixed in
> the beta releases.
>
> Ted

Unsupported third party firmware is not an option.  We're talking about 
places like C&W, RoadRunner, Rogers, Etc.  Not you and me.


From bicknell at ufp.org  Fri Mar 27 17:43:32 2009
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 27 Mar 2009 16:43:32 -0500
Subject: [arin-ppml] How hard is it to transition to IPv6?
In-Reply-To: <49CD449B.1060309@zcorum.com>
References: <28E139F46D45AF49A31950F88C49745859BFB5@E03MVZ2-UKDY.domain1.systemhost.net>
	<49CD449B.1060309@zcorum.com>
Message-ID: <20090327214332.GB72443@ussenterprise.ufp.org>

In a message written on Fri, Mar 27, 2009 at 05:26:51PM -0400, Scott Helms wrote:
> afford a compliant device?  Cut them off?  Replace the device 
> ourselves?  Globally ~1.4% of active browsing sessions are from systems 
> running Win 2000 and I don't have any problem saying that percentage is 
> much higher in rural markets.  I still have some providers who report 
> significant usage of Win 98.  While there is an unofficial patch out 
> there for Win 2000 (and steering customers to it is a whole new issue) 
> AFAIK there isn't anything for 98.

That decision is years off.

To continue with Google as the example.  www.google.com is now
available via IPv4 and Ipv6.  Even when we run out of IPv4 addresses
your Win 2000 customer will continue to be able to access www.google.com
via IPv4.  It is likely this capability will continue to work for
years, and perhaps decades.

When exhaustion occurs, you will have to turn up NEW customers on
IPv6 only.  Only those new customers will need IPv6 compliant devices
day one, so they can access google over IPv6.  You may also need
to provide some translation technologies, as not all content providers
will be as forward looking as google.

If course, if you have customers leave, or do convince some to
upgrade that will free up some IPv4 resources in your own network
that you can use to take on new customers with non-compliant devices.

With luck, most of your Win 2000 customers will have upgraded for
other reasons before you are faced with the decision of cutting
them off or not.

The trick here is, to take on a new IPv6 customer the ISP's network
must be IPv6 enabled.  You don't need to run off and pester all of
your IPv4 customers; unless they too are an ISP, leave them alone
for now.  You need to make sure your network is enabled, and your
vendors will have new equipment you can sell to new subscribers
when there are no more IPv4 resources.

This is not a flag day.  IPv4 will die very slowly, over a period
of many years.  IPv6 will take over very slowly, over a period of
years.  Runout is likely to be a minor inflection point in the
graph, not a seismic shift.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090327/cdac3131/attachment.sig>

From kkargel at polartel.com  Fri Mar 27 17:47:56 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Fri, 27 Mar 2009 16:47:56 -0500
Subject: [arin-ppml] How hard is it to transition to IPv6?
In-Reply-To: <87390B2DDDE148072A5ACF1B@ZOP-MACTEL.local>
References: <20090327162556.GA57288@ussenterprise.ufp.org><942D9D7DDDDC80D26685B567@ZOP-MACTEL.local><6D8B9E8AC67347C8B8943FEFB3C601B7@tedsdesk>
	<87390B2DDDE148072A5ACF1B@ZOP-MACTEL.local>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AF40@mail>


> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Michael Loftis
> Sent: Friday, March 27, 2009 4:41 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] How hard is it to transition to IPv6?
> 
> 
> 
> --On March 27, 2009 1:32:49 PM -0700 Ted Mittelstaedt <tedm at ipinc.net>
> wrote:
> 
> >
> > check out the dd-wrt firmware, it can be loaded on many of the small
> > consumer devices and it's rock solid.  IPv6 support was in the prior
> > release of it, was broken in the current release, and is fixed in
> > the beta releases.
> >
> > Ted
> 
> Unsupported third party firmware is not an option.  We're talking about
> places like C&W, RoadRunner, Rogers, Etc.  Not you and me.
> _______________________________________________

It sound like a tremendous business opportunity for an enterprising young
geek to me..  put the unsupported third party software on cheap routers,
sell them for cheap plus a dollar, sell maintenance..  


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090327/abf7a430/attachment.bin>

From sethm at rollernet.us  Fri Mar 27 17:54:50 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Fri, 27 Mar 2009 14:54:50 -0700
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using
 the	Emergency PDP)
In-Reply-To: <49C911A8.5020009@arin.net>
References: <49C911A8.5020009@arin.net>
Message-ID: <49CD4B2A.1080600@rollernet.us>

Member Services wrote:
> Draft Policy 2009-1
> Transfer Policy
> 
> The ARIN Board of Trustees has declared a policy emergency and is making
> use of the Emergency PDP provision in the ARIN Policy Development
> Process to revise policy.
> 
> At their meeting on 6 February 2009 the ARIN Board of Trustees, based on
> the recommendation of the ARIN Advisory Council and noting that the
> Policy Development Process had been followed, adopted Draft Policy
> 2008-6: Emergency Transfer Policy for IPv4 Addresses.
> 
> Then at their meeting on 8 March 2009, the Board noted there is a gap in
> the transfer policy that limits the availability of IPv4 address space
> at a time when otherwise available IPv4 address space will become
> scarce, and declared this gap an emergency. The Board initiated the
> Emergency PDP of the Policy Development Process in order to revise the
> transfer policy (both the existing transfer policy and the policy just
> adopted).


I OPPOSE this policy because I do not see a demonstrated need to
exercise emergency powers where the normal process would suffice. This
is strictly my opinion based on the policy itself.

~Seth


From tedm at ipinc.net  Fri Mar 27 18:02:01 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 27 Mar 2009 15:02:01 -0700
Subject: [arin-ppml] How hard is it to transition to IPv6?
In-Reply-To: <87390B2DDDE148072A5ACF1B@ZOP-MACTEL.local>
References: <20090327162556.GA57288@ussenterprise.ufp.org><942D9D7DDDDC80D26685B567@ZOP-MACTEL.local><6D8B9E8AC67347C8B8943FEFB3C601B7@tedsdesk>
	<87390B2DDDE148072A5ACF1B@ZOP-MACTEL.local>
Message-ID: <77E8E321BC32401EA0F8148BFB2647EE@tedsdesk>


Nothing is stopping the C&W, Roadrunner, and Rogers of the
world from taking the dd-wrt stuff, which is under GPL, and
using it.  Those large orgs get the manufacturers of their
cable modems to custom-build them for them anyway - that's
why those modems have those companies names sikscreened on
them after all - and they get the firmware custom-modified
to display their logos and setup their network presets.

And if they don't want to do that, the dd-wrt people have a
company that's primary means of
income is custom-modifying the firmware for OEM's like
C&W, Roadrunner, Rogers, etc.

The fact of the matter is that for those large orgs it is
cheaper for them to just buy new gear and push it out to
their userbase.  The replaced gear ends up flooding the
junk stores.  Our prmary supply of DSL modems that we send
out as freebies to new subscribers is a local computer
recycler, we get them from them for $5 a modem and over 90%
work fine.

Ted

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Michael Loftis
> Sent: Friday, March 27, 2009 2:41 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] How hard is it to transition to IPv6?
> 
> 
> 
> --On March 27, 2009 1:32:49 PM -0700 Ted Mittelstaedt <tedm at ipinc.net>
> wrote:
> 
> >
> > check out the dd-wrt firmware, it can be loaded on many of 
> the small 
> > consumer devices and it's rock solid.  IPv6 support was in 
> the prior 
> > release of it, was broken in the current release, and is 
> fixed in the 
> > beta releases.
> >
> > Ted
> 
> Unsupported third party firmware is not an option.  We're 
> talking about places like C&W, RoadRunner, Rogers, Etc.  Not 
> you and me.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 



From dwhite at olp.net  Fri Mar 27 18:09:17 2009
From: dwhite at olp.net (Dan White)
Date: Fri, 27 Mar 2009 17:09:17 -0500
Subject: [arin-ppml] How hard is it to transition to IPv6?
In-Reply-To: <87390B2DDDE148072A5ACF1B@ZOP-MACTEL.local>
References: <20090327162556.GA57288@ussenterprise.ufp.org>	<942D9D7DDDDC80D26685B567@ZOP-MACTEL.local>	<6D8B9E8AC67347C8B8943FEFB3C601B7@tedsdesk>
	<87390B2DDDE148072A5ACF1B@ZOP-MACTEL.local>
Message-ID: <49CD4E8D.8080706@olp.net>

Michael Loftis wrote:
> --On March 27, 2009 1:32:49 PM -0700 Ted Mittelstaedt <tedm at ipinc.net> 
> wrote:
>
>   
>> check out the dd-wrt firmware, it can be loaded on many of the small
>> consumer devices and it's rock solid.  IPv6 support was in the prior
>> release of it, was broken in the current release, and is fixed in
>> the beta releases.
>>
>> Ted
>>     
>
> Unsupported third party firmware is not an option.  We're talking about 
> places like C&W, RoadRunner, Rogers, Etc.  Not you and me.
>   

I agree with the idea earlier in this thread that you should be talking 
to your vendors. I've been successful in pushing one of my vendors into 
an IPv6 commitment. If you make cogent arguments about what your needs 
are, and reinforce what your time frame is, your vendors may start to 
budge in the right direction.

I would also note that IPv6 support *is* available in many broadcom 
based CPE devices - including ZyXEL, Comtrend, Zhone and Clear Access - 
but is not compiled by default. I've had an enlightening look through 
some available releases of the broadcom firmware source:

http://blog.rot13.org/2007/10/bcm963xx_git_repository.html

- Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090327/5b475887/attachment.htm>

From tedm at ipinc.net  Fri Mar 27 18:17:01 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 27 Mar 2009 15:17:01 -0700
Subject: [arin-ppml] How hard is it to transition to IPv6?
In-Reply-To: <49CD3E49.20302@zcorum.com>
References: <20090327162556.GA57288@ussenterprise.ufp.org><942D9D7DDDDC80D26685B567@ZOP-MACTEL.local><8A3DE12E408BBC499E40C0BE733C86030154CBB0@mail1.dulles.sv.int><49CD14FB.3080709@zcorum.com><alpine.OSX.1.00.0903270930001.155@cust11794.lava.net><49CD311D.50607@zcorum.com><0B10E1EDDFB24DEAAAD098D3F54369C9@tedsdesk>
	<49CD3E49.20302@zcorum.com>
Message-ID: <AB32B765209B4BA0A78BEBCD2DF97963@tedsdesk>

 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Helms
> Sent: Friday, March 27, 2009 2:00 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] How hard is it to transition to IPv6?
> 
> Ted,
> 
>     That is certainly true, but that doesn't (unfortunately) 
> drive the decisions of many and perhaps most retail 
> consumers.  I live in an upscale Atlanta suburb, but doing 
> some simple scans around my neighborhood shows that almost 
> half of the wireless access points are wide open.  What's 
> worse more than half of the open AP's still have default 
> passwords on the device itself.  Now, that's completely 
> anecdotal but I do the same test as I travel around the 
> country and so far the results aren't far off.  Even around 
> tech oriented areas I've seen much higher rates of owner 
> indifference/ignorance being displayed.  
> If large numbers of people in RTP are doing this, what are 
> the chances that people living in rural markets are doing 
> better?  (I do see fewer open systems around Research 
> Triangle Park, but roughly 1 out 3 is still
> terrible.)  The problem for ISPs is that at the retail level 
> many customers don't understand, and taking care of them will 
> be tremendously expensive in terms of human resources and gear.
> 


Our observation is that they understand very quickly when we
forward the MPAA/RIAA e-mail notification to them that claims
that the IP number assigned to them has been observed downloading
illegal mp3s and if they don't knock it off, they will be sued.

But you are right in that the fact is that a number of users won't
"get it" until the day comes, long after IPv4 runout, that the 
limited number of websites they routinely use just stop working.
THEN it will be an emergency!

Ted



From young at jsyoung.net  Fri Mar 27 19:07:39 2009
From: young at jsyoung.net (Jeff Young)
Date: Fri, 27 Mar 2009 19:07:39 -0400
Subject: [arin-ppml] How hard is it to transition to IPv6?
In-Reply-To: <28E139F46D45AF49A31950F88C49745859BFB5@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C49745859BFB5@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <A2817AC5-DF0A-4963-A6C1-B3CF3053AE45@jsyoung.net>

I can see two ways this can go.  I could easily envision a world where
NAT proliferates and becomes the defacto for every connection to the
Internet.  For instance, although the solutions involve IPv6, many of  
the
solutions before the IETF that hope to make IPv4 and IPv6 compatible
are based on NAT.

IPv6 is by no means necessary, it may be the solution we prefer, the  
less
complicated solution, the long term solution but it is by no means
necessary.  v6 will happen if and only if the user community believes it
is the easiest way to go forward.  We've met the enemy and he is us.

We face a few undeniable truths:

- IPv4 allocations will run out in the next few years.
- ISP's will be immediately and adversely affected.  They will be  
forced to
  make their networks support both v6 and v4, some will resort to NAT
  on their edges...but allow native v6 to flow.  IPv6-only hosts will  
be a reality.
- Established large organizations, small organizations, and consumers  
will
  be less affected.

The other way this can go is IPv6.  Unfortunately IPv6 advocates have
been crying "transition" (i.e. "wolf") for so long that IPv6 has a  
developed
a negative stigma.  In the face of exhaustion, I think we need to  
separate
the problem into its pieces and be pragmatic.

ISP's can either embrace v6 or start a process of reclamation and  
renumbering.
That process will likely involve as many lawyers as network  
engineers.  I
favor v6 :-).  ISP's need to support v4 and v6 -- they'll only get  
large enough
allocations to grow via v6 in the future.  I wouldn't gamble the  
growth of my
business on reclamation and NAT.

For large enterprise, I've lobbied in favor of v6.  At present,  
however, I've
only lobbied that the F500 only upgrade their content delivery (e.g.  
outward-
facing services like web, VPN, DNS,  and so on) to dual stack.

By crying "transition" in the past, we've turned off the F500 crowd to  
v6.
Established F500 networks don't need to "transition,"  they need to  
make their
services available to the coming group of v6 only hosts.  I think this  
is what Google is
doing now, they're more content provider than ISP.  Large enterprises  
can transition
the rest of their networks later and the rest of their software later,  
if ever.  To
suggest that "Google says we can do it in 18 months" won't really fly  
in large
enterprise (outside Boeing, or Bechtel, or...).

On the consumer side, my impression is that we're ahead of the game.
much of the newest gear supports v6 (in fact, early experiments like  
Teredo in
Vista and v6 tunneling in Apple Airports supported it to a fault).   
The OS's
support it well enough.

My point is, first, ISPs don't have much of a choice.  Second, if we  
are going to
lobby anyone to transition, it should be content providers.  We should  
be
suggesting that they migrate to their outward-facing services to dual- 
stack.
We should be pointing out that Google is migrating because they are a  
content
provider, not an ISP.  Anything behind the outward-facing services can  
remain
IPv4 (indefinitely).

Third, on the consumer side we need to focus on ways that v6 happens  
without
consumer involvement.  If v6 is a success we'll just wake up one  
morning to find
that IPv6 traffic just begins to grow.  No one will have "accepted"  
it.  The DNS will
return v6 and v4 addresses to hosts that are dual stack, v6 will be  
preferred and if a
path exists the content will flow v6.

jy
On Mar 27, 2009, at 4:59 PM, <michael.dillon at bt.com> wrote:

>> Google has shown with the source code and programmers you can
>> fix the software in ~18 months.  That's good news, isn't it?
>> If we can all drive home the requirements to the vendors it
>> seems like there is plenty of time to get stuff fixed and
>> deployed before it is an issue.
>
> Bingo!
>
> People are wasting their breath complaining here. They should be  
> beating
> down their vendors doors to fix the IPv6 problem, and if it is  
> equipment
> bought within the last couple of years and the vendors down't have it
> high enough priority with delivery promised in the next 18 months,  
> then
> they should immediately take those vendors to court and sue for  
> damages.
> Get back all the money you paid, any costs of switching out the crap
> equipment for another brand that can (or will) handle IPv6, plus
> damages.
>
> Lots of companies have been negligent, both hardware/software vendors
> and network operators. Of course there is still enough time to recover
> from these mistakes if a company makes it a priority and sets some  
> firm
> internal targets, but if one of your suppliers is not willing to make
> firm promisies, then take them to court and tear them to shreds now
> before they go bankrupt. Fact is that when IPv6 takes off it will be a
> flurry of activity and a lot of that will be companies moving away  
> from
> suppliers who do not have enough IPv6 support. That will drive some
> companies into bankruptcy. That's just the way the economy works and  
> in
> my personal opinion it is better for the economy to drive those
> companies into bankruptcy sooner rather than later.
>
> The time has come for everyone to stop denial and admit that
> circumstances are forcing us to deploy IPv6 regardless of whether it  
> has
> the kind of business case that we prefer. If senior management is not
> past the denial stage and into the action stage then they are
> incompetent. Enough network operators have already moved into the  
> action
> stage as well as companies like Google. It is clear that IPv6  
> deployment
> is the way forward out of this addressing mess.
>
> --Michael Dillon
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>



From jhg at omsys.com  Fri Mar 27 19:04:35 2009
From: jhg at omsys.com (Jeremy H.Griffith)
Date: Fri, 27 Mar 2009 16:04:35 -0700
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using
	the	Emergency PDP)
In-Reply-To: <49CD4B2A.1080600@rollernet.us>
References: <49C911A8.5020009@arin.net> <49CD4B2A.1080600@rollernet.us>
Message-ID: <sfmqs453feplhl10splpn440hn33ioap5o@4ax.com>

On Fri, 27 Mar 2009 14:54:50 -0700, Seth Mattinen <sethm at rollernet.us> 
wrote:

>I OPPOSE this policy because I do not see a demonstrated need to
>exercise emergency powers where the normal process would suffice. 
>This is strictly my opinion based on the policy itself.

+1

I also OPPOSE this policy, for the reason above and because
the policy itself is fatally flawed by the changes made by
the BOT.  I've never been in favor of monetizing IP addys,
but stripping the sunset clause and adding V6 and even ASNs
is way, way past prudent.  If there is an emergency here,
it is one caused entirely by this unprecedented BOT abuse
of the policy process.

So far I have seen *NO* support for this policy.  Zero.
Zip.  If it goes forward anyway, it will be very clear 
that the ideas of "consensus" and "community policy" are
mere travesties, to be discarded whenever the BOT finds
that convenient.

--JHG <jhg at omsys.com>


From michael.dillon at bt.com  Fri Mar 27 19:30:02 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Fri, 27 Mar 2009 23:30:02 -0000
Subject: [arin-ppml] How hard is it to transition to IPv6?
In-Reply-To: <49CD449B.1060309@zcorum.com>
Message-ID: <28E139F46D45AF49A31950F88C49745859BFC6@E03MVZ2-UKDY.domain1.systemhost.net>


>     That is an interesting choice of words.  I don't know 
> what kind of people you work for/with (I assume from your 
> email address BT) but I can tell you that if I told my 
> customers, who are ISPs, that they should stop "complaining" 
> because they were "negligent" the response wouldn't be all 
> that friendly. 

That is an ad hominem attack and is not allowed on the ARIN
policy discussion lists. You should be ashamed of yourself.

I don't speak for BT or any other company who hosts one of
my three email addresses. Why would you think otherwise?
Do you think that the only people on this list are owner
operators of their own business.

And read my email again, carefully this time. In effect, I told
the customers of all ISPs, not just one ISP, that they SHOULD
complain about their ISP supplier's negligence if that ISP 
supplier does not provide satisfactory timelines for IPv6 support.
If you are signing two year contracts, then you might get one 
more renegotiation cycle before IPv4 runs out. If you are signing
on for three years, you might not get a chance until it is 
too late, which means that NOW IS THE TIME TO TALK TO ALL OF
YOUR SUPPLIERS of network services and network equipment and
network software. This is simple reasoning based on the 
projected runout dates.

This is typical of ad hominem attacks. You haven't even read
my message correctly. I've noticed a similar thing in postings
that complain about grammar and spelling.

--Michael Dillon

P.S. companies don't participate on PPML, people do.

P.P.S. My employer BT has at least one ISP customer who is complaining
that we haven't got full IPv6 support soon enough. This is good. It
helps 
us to do the right thing. Arguing about IPv6 in industry fora is lots of

fun but does not lead to the right results. The only dialog that will
help
you get what you need to fully deploy IPv6 is dialog with your
suppliers.
If you aren't already engaged in that dialog this late in the game then
you definitely should be complaining to suppliers, raising ruckus with
them, escalating it with them and suing them if necessary.

Here, read about what happens when a customer complains, down near
the bottom of this page <http://www.aaisp.net.uk/news-ipv6.html>



From tedm at ipinc.net  Fri Mar 27 19:46:59 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 27 Mar 2009 16:46:59 -0700
Subject: [arin-ppml] How hard is it to transition to IPv6?
In-Reply-To: <28E139F46D45AF49A31950F88C49745859BFC6@E03MVZ2-UKDY.domain1.systemhost.net>
References: <49CD449B.1060309@zcorum.com>
	<28E139F46D45AF49A31950F88C49745859BFC6@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <3AE0B213615A40168B649C8FEE81F30E@tedsdesk>

 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of michael.dillon at bt.com
> Sent: Friday, March 27, 2009 4:30 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] How hard is it to transition to IPv6?
> 


> The only dialog 
> that will help you get what you need to fully deploy IPv6 is 
> dialog with your suppliers.
> If you aren't already engaged in that dialog this late in the 
> game then you definitely should be complaining to suppliers, 
> raising ruckus with them, escalating it with them and suing 
> them if necessary.


I couldn't agree more.

For nearly 2 years I periodically raised ruckuses with one of
my upstreams.  (you know who you are)

Then one day, partly as a result of my bitching,
they started offering native IPv6.  It turned out I wasn't the
only one of their customers bitching.

You see, I -helped- them because now they have it done and out
of the way.

Now, I just gotta finish the work on my own gateway devices (which
I found to my annoyance, have some issues)

Persistence works.

Ted



From woody at pch.net  Fri Mar 27 19:59:07 2009
From: woody at pch.net (Bill Woodcock)
Date: Fri, 27 Mar 2009 15:59:07 -0800 (PST)
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using the
 Emergency PDP)
In-Reply-To: <3c3e3fca0903271339q6dd8f49ekeced041da77ca979@mail.gmail.com>
References: <49C911A8.5020009@arin.net>
	<3c3e3fca0903271339q6dd8f49ekeced041da77ca979@mail.gmail.com>
Message-ID: <Pine.SOC.4.61.0903271552530.15203@paixhost.pch.net>

      On Fri, 27 Mar 2009, William Herrin wrote:
    > The use of the emergency policy process is wrongheaded and
    > wholly inappropriate. Should the board desire the adoption of this
    > policy text, it should offer it through the normal process.

I agree entirely.  However, some board members feel otherwise.

If you feel that board members should be allowed to participate in the 
policy process absent a declaration of emergency, and the majority 
of the membership agrees with you, a policy proposal to that effect could 
rectify this (relatively recent) situation and return dialog to a more 
moderate mode.

                                -Bill



From BillD at cait.wustl.edu  Fri Mar 27 20:37:14 2009
From: BillD at cait.wustl.edu (Bill Darte)
Date: Fri, 27 Mar 2009 19:37:14 -0500
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using the
	Emergency PDP)
References: <49C911A8.5020009@arin.net><3c3e3fca0903271339q6dd8f49ekeced041da77ca979@mail.gmail.com>
	<Pine.SOC.4.61.0903271552530.15203@paixhost.pch.net>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087531F57@ex1.cait.wustl.edu>

If the Board wants a policy proposed they simply ask someone to do it. Or, they advise the AC to do it as they did with the transfer policy proposal.  Trouble is they were not very explicit in what they wanted.  The 2008-2 while very close to what they wanted was fatally flawed but its length, complexity and legalistic language.  And, I might add the serious resistance by the community to any form of for-fee transfer policy.

So a policy that seemed to be OK with them (since there was little overall resistance to it) was proposed...2008-6.  Its (if I do say so myself) careful crafting was all about drawing the greatest consensus through protections, explicit rationale and simplicity barely passed the ACs assessment of consensus...this was helped by the explicit and outspoken encouragement (LA meeting) by ARIN counsel.

Then when when the Board received that proposal, obviously there were flaws that were never expressed, as they modified it under their emergency powers and the result is what it is.... 2009-1.

Debate now, moderate or otherwise, is appropriately being engaged on the ppml and hopefully, many will bring their sentiment whether supportive or opposing to the San Antonio meeting.  There and here the community may once again advise the AC on its views.  The more advice the AC receives the better the process and the better the policy expectations.

Bill Darte
ARIN Advisory Council


-----Original Message-----
From: arin-ppml-bounces at arin.net on behalf of Bill Woodcock
Sent: Fri 3/27/2009 6:59 PM
To: William Herrin
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using the Emergency PDP)
 
      On Fri, 27 Mar 2009, William Herrin wrote:
    > The use of the emergency policy process is wrongheaded and
    > wholly inappropriate. Should the board desire the adoption of this
    > policy text, it should offer it through the normal process.

I agree entirely.  However, some board members feel otherwise.

If you feel that board members should be allowed to participate in the 
policy process absent a declaration of emergency, and the majority 
of the membership agrees with you, a policy proposal to that effect could 
rectify this (relatively recent) situation and return dialog to a more 
moderate mode.

                                -Bill

_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090327/fcfa5c88/attachment.htm>

From stephen at sprunk.org  Fri Mar 27 20:42:56 2009
From: stephen at sprunk.org (Stephen Sprunk)
Date: Fri, 27 Mar 2009 19:42:56 -0500
Subject: [arin-ppml] How hard is it to transition to IPv6?
In-Reply-To: <28E139F46D45AF49A31950F88C49745859BFC6@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C49745859BFC6@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <49CD7290.8060900@sprunk.org>

michael.dillon at bt.com wrote:
> And read my email again, carefully this time. In effect, I told the customers of all ISPs, not just one ISP, that they SHOULD complain about their ISP supplier's negligence if that ISP supplier does not provide satisfactory timelines for IPv6 support.  If you are signing two year contracts, then you might get one more renegotiation cycle before IPv4 runs out. If you are signing on for three years, you might not get a chance until it is too late, which means that NOW IS THE TIME TO TALK TO ALL OF YOUR SUPPLIERS of network services and network equipment and network software. This is simple reasoning based on the projected runout dates.
>   

Note that "complaints" and "discussions" are, in most cases, not 
enough.  You must make it clear that support for your requested feature 
(IPv6 or anything else) is mandatory or you'll take your business to 
someone else who does offer it -- and follow through on that threat if 
they fail to comply.  Lost business, particularly from existing 
customers, is the _only_ thing that reliably motivates large companies.

Unfortunately, there simply aren't yet enough vendors out there offering 
IPv6 for these threats to work very well -- and that is why none of the 
other vendors are really working that hard at it, which creates a 
vicious cycle.  Sooner or later, though, it will be broken and IPv6 
support will appear from all the other vendors virtually overnight...

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3241 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090327/d938f7c0/attachment.bin>

From mueller at syr.edu  Fri Mar 27 23:44:29 2009
From: mueller at syr.edu (Milton L Mueller)
Date: Fri, 27 Mar 2009 23:44:29 -0400
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using
	the	Emergency PDP)
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D03087531F57@ex1.cait.wustl.edu>
References: <49C911A8.5020009@arin.net><3c3e3fca0903271339q6dd8f49ekeced041da77ca979@mail.gmail.com>
	<Pine.SOC.4.61.0903271552530.15203@paixhost.pch.net>
	<EACF8B735E9CBA4B8BAF9E4165D03087531F57@ex1.cait.wustl.edu>
Message-ID: <75822E125BCB994F8446858C4B19F0D76BE5555F@SUEX07-MBX-04.ad.syr.edu>

Hate to jump into this again, but there is some serious self-delusion going on here.

________________________________
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Bill Darte
The 2008-2 while very close to what they wanted [but] was fatally flawed [by] its length, complexity and legalistic language.

2008-2 was a viable if somewhat conservative and bureaucratic proposal. It became lengthy and complex because of good-faith efforts to respond to the dialogue on this list. I never believed that its complexity was crippling and always believed that however far it was from my own preferences, it was much better than doing nothing. The people who opposed it were simply being rigid and clinging to the good old days of a pre-scarcity address space. IMHO they are the ones responsible for the current issue.

And, I might add the serious resistance by the community to any form of for-fee transfer policy.

I love this word "the community." For those of us who understand grammar, the presence of the definite article is striking. It suggests homogeneity where there obviously is none. As I recall there are about a dozen vocal opponents to the idea of transfer markets, and an equal number of vocal supporters. And when ARIN conducted a survey they found that the majority actually favored the idea. But the vocal minority succeeded in blocking the idea. Hooray for consensus.

So a policy that seemed to be OK with them (since there was little overall resistance to it) was proposed...2008-6.  Its (if I do say so myself) careful crafting was all about drawing the greatest consensus through protections, explicit rationale and simplicity barely passed the ACs assessment of consensus...this was helped by the explicit and outspoken encouragement (LA meeting) by ARIN counsel.

I never understood 2008-6. As far as I could see it was an attempt to permit transfers while assuring everyone that everything was the same and nothing was changing. Another interpretation is that you can't rely on "consensus" among a "community" when dealing with basic economic distributional conflicts and fundamental differences in ideology. The Board - probably wisely - realized that action had to be taken, and took action.

Seriously, put aside differences about the substantive policy and ask yourself a fundamental question about consensus policy making. Perhaps it will help to put it in a different context. Suppose that The Fed's response to the financial crisis relied on "consensus" decision making and you had roughly half "the community" warning that the entire economy was headed for catastrophe unless we did X and the other half saying that we face a catastrophe if we don't do Y. If there is no "consensus" then the only option is to do nothing - which both sides think is not a viable option. What then?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090327/cccba828/attachment.htm>

From mueller at syr.edu  Sat Mar 28 02:14:15 2009
From: mueller at syr.edu (Milton L Mueller)
Date: Sat, 28 Mar 2009 02:14:15 -0400
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy
 (UsingtheEmergency	PDP)
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D030878AB1B6@ex1.cait.wustl.edu>
References: <49C911A8.5020009@arin.net>
	<997BC128AE961E4A8B880CD7442D94800A6977DC@NJCHLEXCMB01.cable.comcast.com>
	<EACF8B735E9CBA4B8BAF9E4165D030878AB1B6@ex1.cait.wustl.edu>
Message-ID: <75822E125BCB994F8446858C4B19F0D76BE55562@SUEX07-MBX-04.ad.syr.edu>

OK, I need to retract a bit of my previous message re: 2008-6. 

As amended, 2008-6 was not bad. But, having looked over the long-term record of this process, if I were to attribute a reason to the Board's (admittedly poorly explained) action, it would be this:

> -----Original Message-----
> Behalf Of Bill Darte
> Sent: Wednesday, March 25, 2009 5:21 PM
>
> 3. The implementation timetable deferred the implementation until such a
> time as there was indeed real scarity.

This was the fatal flaw in 2008-6. Scarcity is here now, especially when there is talk of rationing out the remaining v4 blocks in small parcels in ways that constrain large operators in order to equalize their ration with small operators (i.e., 2009-2). If I were a big operator looking ahead for the next 2-3 years, and worried about my ability to acquire the v4 addresses needed to remain competitive, the combination of 2008-6 (which doesn't allow transfers at all until the exhaustion of the free pool), and the rationing approach of 2009-2, I would be concerned. 

I don't think the sunset is the issue, I think it's the start date. 



From jay at impulse.net  Sat Mar 28 02:51:23 2009
From: jay at impulse.net (Jay Hennigan)
Date: Fri, 27 Mar 2009 23:51:23 -0700
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy
 (Using	the	Emergency PDP)
In-Reply-To: <sfmqs453feplhl10splpn440hn33ioap5o@4ax.com>
References: <49C911A8.5020009@arin.net> <49CD4B2A.1080600@rollernet.us>
	<sfmqs453feplhl10splpn440hn33ioap5o@4ax.com>
Message-ID: <49CDC8EB.1090405@impulse.net>

Please add my voice to those OPPOSED to this policy for the following 
reasons.

1.  In my opinion no emergency requiring action outside of normal 
policy-making procedures has been demonstrated, hence the use of 
emergency powers is completely unwarranted.

2.  I am opposed in principle to any form of for-fee transfer policy.

3.  Even if an emergency were demonstrated to exist in the case of IPv4 
address space, the policy as written is not limited to IPv4 addresses 
but includes all ARIN resources.

4.  The lack of a sunset clause causes the policy to remain in place 
even after the emergency (which in my opinion does not exist now) has 
been alleviated.

-- 
Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV


From BillD at cait.wustl.edu  Sat Mar 28 08:14:37 2009
From: BillD at cait.wustl.edu (Bill Darte)
Date: Sat, 28 Mar 2009 07:14:37 -0500
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy
	(UsingtheEmergency	PDP)
References: <49C911A8.5020009@arin.net><997BC128AE961E4A8B880CD7442D94800A6977DC@NJCHLEXCMB01.cable.comcast.com>
	<EACF8B735E9CBA4B8BAF9E4165D030878AB1B6@ex1.cait.wustl.edu>
	<75822E125BCB994F8446858C4B19F0D76BE55562@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087531F60@ex1.cait.wustl.edu>

Milton,

I'm unsure what you are retracting...
But, you believe that scarcity exists now?  Rationing has existed for many years.  The 'talk' of rationing smaller parcels than meets need is triggered when ARIN's reserve drops below a /9 in policy proposal 2009-2.  That is not nearly the case.

bd


-----Original Message-----
From: Milton L Mueller [mailto:mueller at syr.edu]
Sent: Sat 3/28/2009 1:14 AM
To: Bill Darte; arin-ppml at arin.net
Subject: RE: [arin-ppml] Draft Policy 2009-1: Transfer Policy (UsingtheEmergency	PDP)
 
OK, I need to retract a bit of my previous message re: 2008-6. 

As amended, 2008-6 was not bad. But, having looked over the long-term record of this process, if I were to attribute a reason to the Board's (admittedly poorly explained) action, it would be this:

> -----Original Message-----
> Behalf Of Bill Darte
> Sent: Wednesday, March 25, 2009 5:21 PM
>
> 3. The implementation timetable deferred the implementation until such a
> time as there was indeed real scarity.

This was the fatal flaw in 2008-6. Scarcity is here now, especially when there is talk of rationing out the remaining v4 blocks in small parcels in ways that constrain large operators in order to equalize their ration with small operators (i.e., 2009-2). If I were a big operator looking ahead for the next 2-3 years, and worried about my ability to acquire the v4 addresses needed to remain competitive, the combination of 2008-6 (which doesn't allow transfers at all until the exhaustion of the free pool), and the rationing approach of 2009-2, I would be concerned. 

I don't think the sunset is the issue, I think it's the start date. 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090328/d3e26d01/attachment.htm>

From ocl at gih.com  Sat Mar 28 10:32:35 2009
From: ocl at gih.com (Olivier MJ Crepin-Leblond)
Date: Sat, 28 Mar 2009 14:32:35 -0000
Subject: [arin-ppml] How hard is it for ARIN to transition to IPv6? (was:
	How hard is it to transition to IPv6?)
References: <20090327162556.GA57288@ussenterprise.ufp.org>
Message-ID: <D58E3CC8BB5D48FD9752FE30D03ECF62@GIH.CO.UK>

Thanks for the interesting thread, Leo. It really looks like the IPv6 
ball is rolling and I am sure that Google's example will be very 
useful to many of us trying to convince organisations to embrace IPv6 
now.

My question is somehow analogous: how hard is it for ARIN to 
transition to IPv6?
In particular, I'd like to find out when will ARIN's mail-servers 
(including the list manager) be distributing mail out using IPv6? I 
can see IPv6 in, but no IPv6 out.

Thanks,

Olivier

-- 
Olivier MJ Cr?pin-Leblond, PhD
http://www.gih.com/ocl.html 



From bicknell at ufp.org  Sun Mar 29 10:21:35 2009
From: bicknell at ufp.org (Leo Bicknell)
Date: Sun, 29 Mar 2009 09:21:35 -0500
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using the
	Emergency PDP)
In-Reply-To: <Pine.SOC.4.61.0903271552530.15203@paixhost.pch.net>
References: <49C911A8.5020009@arin.net>
	<3c3e3fca0903271339q6dd8f49ekeced041da77ca979@mail.gmail.com>
	<Pine.SOC.4.61.0903271552530.15203@paixhost.pch.net>
Message-ID: <4D11C00D-9852-4740-A75A-ADBD22ABBE4F@ufp.org>


On Mar 27, 2009, at 6:59 PM, Bill Woodcock wrote:
> If you feel that board members should be allowed to participate in the
> policy process absent a declaration of emergency, and the majority
> of the membership agrees with you, a policy proposal to that effect  
> could
> rectify this (relatively recent) situation and return dialog to a more
> moderate mode.

I don't know of anything preventing the Board from participating other  
than their own desire to remain neutral in the process.  Indeed, I  
have seen board members at the mike at public policy meetings  
commenting on policy, but I will be the first to admit that is a rare  
occurrence.

I believe the organization is stronger when the Board stays at arms  
length from the policy process.  That said, if the Board sees a  
situation brewing where it believes it will be unable to implement  
policy for any reason it has a duty to speak up in the policy process  
while that policy is being considered.

One of the Board members used a cute analogy with me in private, he  
said "[the Board] prefers to allow the AC to make [policy] sausage  
without their tripe."

My reply was simple, I prefer to make sausage without the Board's  
tripe, but if the Board sees us making sausage and has decided to be a  
vegetarian, they need to tell us before we put the sausage in front of  
them and they turn their nose up at it.  We're happy to make a nice  
risotto instead.

-- 
        Leo Bicknell - bicknell at ufp.org - CCIE 3440
         PGP keys at http://www.ufp.org/~bicknell/





From spiffnolee at yahoo.com  Sun Mar 29 11:23:54 2009
From: spiffnolee at yahoo.com (Lee Howard)
Date: Sun, 29 Mar 2009 08:23:54 -0700 (PDT)
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using the
	Emergency PDP)
In-Reply-To: <4D11C00D-9852-4740-A75A-ADBD22ABBE4F@ufp.org>
References: <49C911A8.5020009@arin.net>
	<3c3e3fca0903271339q6dd8f49ekeced041da77ca979@mail.gmail.com>
	<Pine.SOC.4.61.0903271552530.15203@paixhost.pch.net>
	<4D11C00D-9852-4740-A75A-ADBD22ABBE4F@ufp.org>
Message-ID: <612085.88395.qm@web63306.mail.re1.yahoo.com>


----- Original Message ----
> From: Leo Bicknell <bicknell at ufp.org>
> To: Bill Woodcock <woody at pch.net>
> Cc: arin-ppml at arin.net
> Sent: Sunday, March 29, 2009 10:21:35 AM
> Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using the Emergency PDP)
> 
> I don't know of anything preventing the Board from participating other  
> than their own desire to remain neutral in the process. 

"Policy proposals may be submitted by anyone in the global Internet
community except for members of the ARIN Board of Trustees or the ARIN
staff."

https://www.arin.net/policy/pdp.html

Lee



      



From kmedcalf at dessus.com  Sun Mar 29 11:26:12 2009
From: kmedcalf at dessus.com (Keith Medcalf)
Date: Sun, 29 Mar 2009 11:26:12 -0400
Subject: [arin-ppml] Draft Policy 2008-7: Identify Invalid WHOIS POC's
In-Reply-To: <C6DEAD436BB443C4B6A2414FCC5F1F39@tedsdesk>
Message-ID: <1b09e924bfa74d4b8a637aded2350ebe@mail.dessus.com>


Ted Mittelstaedt wrote:

> The valid POCs can be handled by automated e-mail systems with a
> specific URL link in the mail sent to the POC.  Network Solutions
> already does this for ALL domain name holders in their registrar and
> it's completely automated.  ARIN staff can contact Network Solutions
> and ask how they do it if they do not understand how to do this.

Network Solutions does not do this.  My domain is registered with Network Solutions and always has been.  I have nothing to update, nonetheless, the only verification attempt I ever received from them was many a year ago when they did a postal mail validation.  I have never received e-mail attempting to verify my POK data at Network Solutions.

Of course, it is possible that they (NetSol) [have] attempt[ed] to use SMTP transported web-pages sent from a non-RFC compliant SMTP server, in which case I would have never received the messages (and they would not qualify as "e-mail" anyway).

Thus my requirement that any policy authorizing e-mail (SMTP transported) verification of POK data have a very narrow definition of what qualifies as "e-mail".  In order to qualify as e-mail, the message MUST be text/plain and MUST be sent from a strictly RFC compliant SMTP host which has (a) proper forward and reverse DNS; (b) proper MX records for the sending domain; (c) must be sent from the ARIN.NET domain (not a third party mailer); and, (d) must have correct SPF records if any.

The interpretation of "e-mail" must be strictly specified.  Interpretation of what consititutes e-mail MUST NOT be open for interpretation by the unwashed, particularly those members of the unwashed who believe that web-pages by SMTP is somehow "e-mail".

-- 
()  ascii ribbon campaign against web-pages via SMTP
/\  www.asciiribbon.org 





From bicknell at ufp.org  Sun Mar 29 11:37:39 2009
From: bicknell at ufp.org (Leo Bicknell)
Date: Sun, 29 Mar 2009 10:37:39 -0500
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using the
	Emergency PDP)
In-Reply-To: <612085.88395.qm@web63306.mail.re1.yahoo.com>
References: <49C911A8.5020009@arin.net>
	<3c3e3fca0903271339q6dd8f49ekeced041da77ca979@mail.gmail.com>
	<Pine.SOC.4.61.0903271552530.15203@paixhost.pch.net>
	<4D11C00D-9852-4740-A75A-ADBD22ABBE4F@ufp.org>
	<612085.88395.qm@web63306.mail.re1.yahoo.com>
Message-ID: <E61ECD72-C0E4-47C5-89FE-F91B30CA6101@ufp.org>


On Mar 29, 2009, at 10:23 AM, Lee Howard wrote:
> "Policy proposals may be submitted by anyone in the global Internet
> community except for members of the ARIN Board of Trustees or the ARIN
> staff."

And that prevented the Board from walking up to the mike and saying  
"If this policy is passed as is, we will be forced to change it in  
ways XYZ?"

Or, for that matter, "We would prefer policy <insert template>, but  
can't submit it.  We ask that someone from the community who also  
likes this idea send it into the policy process."

My point is the Board could have, and should have, spoke up the normal  
process in an effort to avoid having to use their emergency powers.


-- 
        Leo Bicknell - bicknell at ufp.org - CCIE 3440
         PGP keys at http://www.ufp.org/~bicknell/





From bill at herrin.us  Sun Mar 29 16:40:24 2009
From: bill at herrin.us (William Herrin)
Date: Sun, 29 Mar 2009 16:40:24 -0400
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using the
	Emergency PDP)
In-Reply-To: <612085.88395.qm@web63306.mail.re1.yahoo.com>
References: <49C911A8.5020009@arin.net>
	<3c3e3fca0903271339q6dd8f49ekeced041da77ca979@mail.gmail.com>
	<Pine.SOC.4.61.0903271552530.15203@paixhost.pch.net>
	<4D11C00D-9852-4740-A75A-ADBD22ABBE4F@ufp.org>
	<612085.88395.qm@web63306.mail.re1.yahoo.com>
Message-ID: <3c3e3fca0903291340y5aae4bb3qce5d5aacaf127746@mail.gmail.com>

On Sun, Mar 29, 2009 at 11:23 AM, Lee Howard <spiffnolee at yahoo.com> wrote:
> "Policy proposals may be submitted by anyone in the global Internet
> community except for members of the ARIN Board of Trustees or the ARIN
> staff."
>
> https://www.arin.net/policy/pdp.html

Lee,

Should the board elect to promptly withdraw proposal 2009-1, let's say
by close of business Friday, it would be my pleasure to resubmit the
text of the proposal to the normal policy process and serve as the
proposal's author.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From raul at lacnic.net  Sun Mar 29 22:25:40 2009
From: raul at lacnic.net (raul at lacnic.net)
Date: Sun, 29 Mar 2009 23:25:40 -0300 (UYT)
Subject: [arin-ppml] Draft Policy 2009-3 (Global): Allocation of IPv4
 Blocks to Regional Internet Registries
Message-ID: <37137.208.54.95.48.1238379940.squirrel@webmail.lacnic.net.uy>


Dear all:

This proposal is a proposal for a global policy. It means that the same
proposal has to be approved in every region. They can be approved with
some wording differences, but the spirit of the proposal should be the
same.

The proposal was the result of a long collaboration effort of senior staff
members and board members of all the 5 RIRs and the original text is the
one that is being considered in every region.

As far as I know the authors of the proposal were not consulted by the
ARIN-AC and based on exchanges among the authors in the past few days, I
can say that in general the feeling is that the changes introduced by the
ARIN-AC are very signficant and so, this is a different proposal.

My personal view is that changing the concept of a global policy proposal
in one RIR means to avoid the approval of the policy. I strongly encourage
ARIN to put the original proposal under consideration of its community as
it is being done in the other regions. The proposal can be approved or
not, That's part of the process, but it doesn't make sense to approve a
different proposal. IMHO, the AC is able to put forward the new proposal
for discussion if they consider that it is better, and in that way to
start the process of discussion of a new global policy proposal.

I have to confess that dealing with 5 different PDPs is not so easy. I
don't know if a petition process should be started, If yes, please take
this email as the request for initiating that process.

Since this announcement was issued last Monday in the afternoon, I am not
sure how the business days are counted, but I guess that I am still within
the valid period.

However, I think that as a practices, global policy proposals should not
be changed by any advisory council or policy chair of one region due to
the impact that to change the proposal produce in the global process.


Best Regards,

Ra?l



---------------



El 23/03/2009, a las 04:05 p.m., Member Services escribi?:

Draft Policy 2009-3 (Global)
Allocation of IPv4 Blocks to Regional Internet Registries

The following draft policy text is being posted for feedback and
discussion on the Public Policy Mailing List (PPML).

This draft policy was developed by the ARIN Advisory Council (AC) from
Policy Proposal 82: Allocation of IPv4 Blocks to Regional Internet
Registries. The AC has taken the proposal and developed it into a draft
policy. The AC was required to submit text to ARIN for staff and legal
assessment prior to selecting it as a draft policy. The assessment,
along with the text that was assessed, is located below the draft policy.

On 20 March 2009 the ARIN Advisory Council (AC) selected Draft Policy
2009-3: Allocation of IPv4 Blocks to Regional Internet Registries for
adoption discussion on the PPML and at the upcoming Public Policy Meeting.

Draft Policy 2009-3 is below and can be found at:
https://www.arin.net/policy/proposals/2009_3.html

We encourage you to discuss Draft Policy 2009-3 on the PPML prior to the
ARIN XXIII Public Policy Meeting. Both the discussion on the PPML and at
the Public Policy Meeting will be used by the AC to determine the
community consensus regarding adopting this as policy.

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

All of the Draft Policies under discussion can be found at:
https://www.arin.net/policy/proposals/index.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy 2009-3 (Global)
Allocation of IPv4 Blocks to Regional Internet Registries

Date: 23 March 2009

Policy statement:

This document describes the policy governing the allocation of IPv4
address space from the IANA to the Regional Internet Registries (RIRs).
This document does not stipulate performance requirements in the
provision of services by IANA to an RIR in accordance with this policy.
Such requirements should be specified by appropriate agreements among
the RIRs and ICANN.

This policy is to be implemented in two phases.

A. Phase I: Recovery of IPv4 Address Space

Upon ratification of this policy by the ICANN Board of Directors the
IANA shall establish a mechanism to receive IPv4 address space which is
returned to it by the RIRs, and hold that address space in a 'recovered
IPv4 pool'.

Each RIR through their respective chosen policies and strategies may
recover IPv4 address space which is under their administration. At
quarterly intervals, each RIR shall return to the IANA any legacy
address space recovered, and may return to the IANA any non-legacy
address space recovered, in aggregated blocks of /24 or larger, for
inclusion in the recovered IPv4 pool.

During Phase I, no allocations will be made from the recovered IPv4
pool. Return of recovered address space (as described above) will
continue throughout Phase II.

B. Phase II: Allocation of Recovered IPv4 address space by the IANA

Upon ratification of this policy by the ICANN Board of Directors and a
declaration by the IANA that its existing free pool of unallocated IPv4
address space is depleted; Global Addressing Policy ASO-001-2 (adopted
by ICANN Board 8 April 2005) is rescinded. IANA will then commence to
allocate the IPv4 address space from the recovered IPv4 pool.

1. The following definitions apply to this policy:

a. Recovered Address Space. Recovered address space is that address
space that is returned to an RIR as a result of any activity that seeks
to reclaim unused address space or is voluntarily returned to the RIR or
is reclaimed by the RIR as a result of legal action or abuse
determination. Recovered address space does not include that address
space that is reclaimed because of non-payment of contractual fees whose
reclamation date is less than 1 year at the time of the report.

b. IPv4 Address Holdings. IPv4 address holdings are all unallocated IPv4
address space held by an RIR to include recovered address space not yet
returned less that address space that is committed in accordance with
the RIR's reservation policy and practices.

c. Aggregated address blocks. Aggregated address blocks are contiguous
prefixes that can be aggregated on natural bit boundaries. 10.0.0.0/24
and 10.0.1.0/24 are two contiguous prefixes that can be combined to form
an aggregated address block. 10.0.0.0/24 and 10.0.1.0/25 are two
contiguous prefixes that cannot be combined on a natural bit boundary to
form an aggregated block.

d. Legacy address space. IPv4 address space allocated or assigned prior
to the creation of the RIR.

2. Allocation of IPv4 Address Space

a. For the purposes of this policy, an 'IPv4 allocation period' is
defined as a 6-month period following 1 March or 1 September in each year.

b. At the beginning of each IPv4 allocation period, the IANA will
determine the 'IPv4 allocation unit' for that period, as 1/10 of its
IPv4 address pool, rounded down to the next CIDR (power-of-2) boundary.
The minimum 'IPv4 allocation unit' size will be a /24.

c. In each allocation period, each RIR may issue one IPv4 request to the
IANA. Providing that the RIR satisfies the allocation criteria described
in paragraph B.2, the IANA will allocate a single allocation unit,
composed of the smallest possible number of blocks available in its IPv4
address pool.

3. IPv4 Address Space Allocation Criteria

A RIR is eligible to receive additional IPv4 address space from the IANA
when the total of its IPv4 address holdings is less than 50% of the
current IPv4 allocation unit, and providing that it has not already
received an IPv4 allocation from the IANA during the current IPv4
allocation period.

4. Initial Allocation of IPv4 Address Space

Each new RIR shall, at the moment of recognition, be allocated one (1)
allocation unit by the IANA. If an allocation unit is not available,
then the IANA will issue this block as soon as one is available. This
allocation will be made regardless of the newly formed RIR's projected
utilization figures and shall be independent of the IPv4 address space
that may have been transferred to the new RIR by the already existing
RIRs as part of the formal transition process.

5. Reporting

a. All returned space is to be recorded in an IANA-published log of IPv4
address space transactions, with each log entry detailing the returned
address block, the date of the return, and the returning RIR.

b. All allocated space is also to be recorded in this IANA-published log
of IPv4 address space transactions, with each log entry detailing the
address blocks, the date of the allocation and the recipient RIR.

c. The IANA will maintain a public registry of the current disposition
of all IPv4 address space, detailing all reservations and current
allocations and current IANA-held address space that is unallocated.

d) The IANA may make public announcements of IPv4 address block
transactions that occur under this policy. The IANA will make
appropriate modifications to the "Internet Protocol V4 Address Space"
page of the IANA website and may make announcements to its own
appropriate announcement lists. The IANA announcements will be limited
to which address ranges, the time of allocation and to which Registry
they have been allocated.



#####

ARIN Staff Assessment

*Title: Allocation of IPv4 Blocks to the Regional Internet Registries*

*Proposal Submitted: 30 Jan 2009*

*Revision Submitted: 05 March 2009*

*Date of Assessment: 10 March 2009*

* *

I. Understanding of the Policy:

*Staff Understanding of the Proposal:*

Staff understands that this proposal would be implemented in 2 phases.
Phase 1 would require the RIRs to return recovered IPv4 legacy address
space (via policy or procedure) to the IANA and have the option of
returning recovered non-legacy address space to the IANA. Phase 2 would
start after the depletion of the IANA free pool and would nullify the
existing IANA to RIR policy (Global Addressing Policy ASO-001-2). The
new IANA to RIR policy would allow each RIR to receive approximately
1/10th of the recovered IPv4 pool from IANA once every 6 months as long
as it meets the qualification criteria written in paragraph B2. IANA
will be required to keep a log of all returned IPv4 address space and
all issued IPv4 address space from the recovered pool, as well as
maintain a public registry of the current disposition of all IPv4
address space.

II. Comments

A. ARIN Staff Comments

* The one policy that this impacts is NRPM 4.6 Amnesty and
  Aggregation, which says ?Transactions should only be accepted
  under this policy if they are in the interests of the community
  (e.g. they improve aggregation or result in a net reclamation of
  space).? Because the ARIN region holds the majority of the legacy
  address space, and most of the address space returned under this
  policy is legacy space, it would mean that there would be no ?net
  return? of address space to ARIN. ARIN would essentially be
  exchanging legacy address space for non-legacy address space, and
  returning the legacy address space it received in the exchange to
  IANA, resulting in a net loss of address space in ARIN?s available
  pool.

B. ARIN General Counsel Comments:

The current basis of allocation of numbers was established in RFC's 2008
and 2050 and is need based. If one region has greater needs than
another, the current policy of IANA does not require equal distribution
to all RIR's s. This proposed policy would establish a different
political and not needs based method for allocating returned space. It
would make each RIR an equal recipient of such space. But the level of
need and economic activity between each RI R is not equal. This policy
will tend to reallocate returned space away from where it is recovered,
in the ARIN region , and move more of it to AFRINIC and LACNIC than
current distribution principles. By equating the smaller economies and
related needs of certain regions to the needs of other regions, like
ARIN, that have greater day to day need, it in effect creates a new
political order of distribution thru equal shares. It is possible
sovereign governments in the regions with greater activity will not
agree to such a revised distribution model. The proposed policy
undermines the legal rationale for distribution.

The policy also creates a powerful disincentive for any RIR, including
ARIN, to undertake any financial expenditure of RIR dollars for programs
intended to obtain returned space for reallocation. Currently ARIN is
working towards policies such as the LRSA and 2008-6, intended to
encourage returns and use of under utilized resources, but which cost
ARIN expenditures other RIRs are not duplicating. Any policy which
creates such a disincentive by leaving expenditures with a single RIR,
who cannot benefit except to receive 20% of the returned space should be
carefully considered.

Finally, it is likely entities with number resources in the ARIN region
may be willing to return those resources for uses in the region but
unwilling to do so if 4/5 of such resources will be sent to other regions.

III. Resource Impact

The resource impact of implementing this policy is viewed as minimal. It
is estimated that this policy could require up to 3 person months of
effort to implement following ratification by the ARIN Board of
Trustees. Because this implementation is not planned, it may preempt
ARIN?s current project deployment schedule. It may require the following:

* Modifications to existing registration procedures to include the
  handling of returned/reclaimed address space and the process of
  requesting additional address space from the IANA.
* Staff training

Text assessed:

*Allocation of IPv4 Blocks to Regional Internet Registries (Global)*

*Policy statement:*

This document describes the policy governing the allocation of IPv4
address space from the IANA to the Regional Internet Registries (RIRs).
This document does not stipulate performance requirements in the
provision of services by IANA to an RIR in accordance with this policy.
Such requirements should be specified by appropriate agreements among
the RIRs and ICANN.

This policy is to be implemented in two phases.

A. Phase I: Recovery of IPv4 Address Space

Upon ratification of this policy by the ICANN Board of Directors the
IANA shall establish a mechanism to receive IPv4 address space which is
returned to it by the RIRs, and hold that address space in a 'recovered
IPv4 pool'.

Each RIR through their respective chosen policies and strategies may
recover IPv4 address space which is under their administration. At
quarterly intervals, each RIR shall return any legacy address space
recovered, and may return any non-legacy address space recovered, to the
IANA in aggregated blocks of /24 or larger, for inclusion in the
recovered IPv4 pool.

During Phase I, no allocations will be made from the recovered IPv4
pool. Return of recovered address space (as described above) will
continue throughout Phase II.

B. Phase II: Allocation of Recovered IPv4 address space by the IANA

Upon ratification of this policy by the ICANN Board of Directors and a
declaration by the IANA that its existing free pool of unallocated IPv4
address space is depleted; Global Addressing Policy ASO-001-2 (adopted
by ICANN Board 8 April 2005) is rescinded. IANA will then commence to
allocate the IPv4 address space from the recovered IPv4 pool.

1. The following definitions apply to this policy:

a. Recovered Address Space. Recovered address space is that address
space that is returned to an RIR as a result of any activity that seeks
to reclaim unused address space or is voluntarily returned to the RIR or
is reclaimed by the RIR as a result of legal action or abuse
determination. Recovered address space does not include that address
space that is reclaimed because of non-payment of contractual fees whose
reclamation date is less than 1 year at the time of the report.

b. IPv4 Address Holdings. IPv4 address holdings are all unallocated IPv4
address space held by an RIR to include recovered address space not yet
returned less that address space that is committed in accordance with
the RIR's reservation policy and practices.

c. Legacy address space. IPv4 address space allocated or assigned prior
to the creation of the RIR.

2. Allocation of IPv4 Address Space

a. For the purposes of this policy, an 'IPv4 allocation period' is
defined as a 6-month period following 1 March or 1 September in each year.

b. At the beginning of each IPv4 allocation period, the IANA will
determine the 'IPv4 allocation unit' for that period, as 1/10 of its
IPv4 address pool, rounded down to the next CIDR (power-of-2) boundary.

c. In each allocation period, each RIR may issue one IPv4 request to the
IANA. Providing that the RIR satisfies the allocation criteria described
in paragraph B.2, the IANA will allocate a single allocation unit,
composed of the smallest possible number of blocks available in its IPv4
address pool.

3. IPv4 Address Space Allocation Criteria

A RIR is eligible to receive additional IPv4 address space from the IANA
when the total of its IPv4 address holdings is less than 50% of the
current IPv4 allocation unit, and providing that it has not already
received an IPv4 allocation from the IANA during the current IPv4
allocation period.

4. Initial Allocation of IPv4 Address Space

Each new RIR shall, at the moment of recognition, be allocated one (1)
allocation unit by the IANA. If an allocation unit is not available,
then the IANA will issue this block as soon as one is available. This
allocation will be made regardless of the newly formed RIR's projected
utilization figures and shall be independent of the IPv4 address space
that may have been transferred to the new RIR by the already existing
RIRs as part of the formal transition process.

5. Reporting

a. All returned space is to be recorded in an IANA-published log of IPv4
address space transactions, with each log entry detailing the returned
address block, the date of the return, and the returning RIR.

b. All allocated space is also to be recorded in this IANA-published log
of IPv4 address space transactions, with each log entry detailing the
address blocks, the date of the allocation and the recipient RIR.

c. The IANA will maintain a public registry of the current disposition
of all IPv4 address space, detailing all reservations and current
allocations and current IANA-held address space that is unallocated.

d) The IANA may make public announcements of IPv4 address block
transactions that occur under this policy. The IANA will make
appropriate modifications to the "Internet Protocol V4 Address Space"
page of the IANA website and may make announcements to its own
appropriate announcement lists. The IANA announcements will be limited
to which address ranges, the time of allocation and to which Registry
they have been allocated.





_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.





From scottleibrand at gmail.com  Sun Mar 29 23:41:05 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Sun, 29 Mar 2009 20:41:05 -0700
Subject: [arin-ppml] Draft Policy 2009-3 (Global): Allocation of IPv4
	Blocks to Regional Internet Registries
In-Reply-To: <37137.208.54.95.48.1238379940.squirrel@webmail.lacnic.net.uy>
References: <37137.208.54.95.48.1238379940.squirrel@webmail.lacnic.net.uy>
Message-ID: <4C1054E8-D5C6-458A-90F7-F00CA7ECCEE7@gmail.com>

Raul,

I have no problem discussing the original proposal, but based on the  
PPML discussion to date, and what I've heard in discussions, IMO the  
original unamended proposal has almost no support, and is extremely  
unlikely to gain consensus in the ARIN region.  If anyone favors the  
original proposal, please speak up.

Based on our estimation of the consensus in the ARIN region, the AC  
amended the proposal to give it a better chance of passing, while  
preserving as much of the original proposal as possible. I would  
welcome additional feedback on the balance we attempted to strike,  
either here or in San Antonio.

Thanks,
Scott

On Mar 29, 2009, at 7:25 PM, raul at lacnic.net wrote:

>
> Dear all:
>
> This proposal is a proposal for a global policy. It means that the  
> same
> proposal has to be approved in every region. They can be approved with
> some wording differences, but the spirit of the proposal should be the
> same.
>
> The proposal was the result of a long collaboration effort of senior  
> staff
> members and board members of all the 5 RIRs and the original text is  
> the
> one that is being considered in every region.
>
> As far as I know the authors of the proposal were not consulted by the
> ARIN-AC and based on exchanges among the authors in the past few  
> days, I
> can say that in general the feeling is that the changes introduced  
> by the
> ARIN-AC are very signficant and so, this is a different proposal.
>
> My personal view is that changing the concept of a global policy  
> proposal
> in one RIR means to avoid the approval of the policy. I strongly  
> encourage
> ARIN to put the original proposal under consideration of its  
> community as
> it is being done in the other regions. The proposal can be approved or
> not, That's part of the process, but it doesn't make sense to  
> approve a
> different proposal. IMHO, the AC is able to put forward the new  
> proposal
> for discussion if they consider that it is better, and in that way to
> start the process of discussion of a new global policy proposal.
>
> I have to confess that dealing with 5 different PDPs is not so easy. I
> don't know if a petition process should be started, If yes, please  
> take
> this email as the request for initiating that process.
>
> Since this announcement was issued last Monday in the afternoon, I  
> am not
> sure how the business days are counted, but I guess that I am still  
> within
> the valid period.
>
> However, I think that as a practices, global policy proposals should  
> not
> be changed by any advisory council or policy chair of one region due  
> to
> the impact that to change the proposal produce in the global process.
>
>
> Best Regards,
>
> Ra?l
>
>
>
> ---------------
>
>
>
> El 23/03/2009, a las 04:05 p.m., Member Services escribi?:
>
> Draft Policy 2009-3 (Global)
> Allocation of IPv4 Blocks to Regional Internet Registries
>
> The following draft policy text is being posted for feedback and
> discussion on the Public Policy Mailing List (PPML).
>
> This draft policy was developed by the ARIN Advisory Council (AC) from
> Policy Proposal 82: Allocation of IPv4 Blocks to Regional Internet
> Registries. The AC has taken the proposal and developed it into a  
> draft
> policy. The AC was required to submit text to ARIN for staff and legal
> assessment prior to selecting it as a draft policy. The assessment,
> along with the text that was assessed, is located below the draft  
> policy.
>
> On 20 March 2009 the ARIN Advisory Council (AC) selected Draft Policy
> 2009-3: Allocation of IPv4 Blocks to Regional Internet Registries for
> adoption discussion on the PPML and at the upcoming Public Policy  
> Meeting.
>
> Draft Policy 2009-3 is below and can be found at:
> https://www.arin.net/policy/proposals/2009_3.html
>
> We encourage you to discuss Draft Policy 2009-3 on the PPML prior to  
> the
> ARIN XXIII Public Policy Meeting. Both the discussion on the PPML  
> and at
> the Public Policy Meeting will be used by the AC to determine the
> community consensus regarding adopting this as policy.
>
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
>
> All of the Draft Policies under discussion can be found at:
> https://www.arin.net/policy/proposals/index.html
>
> Regards,
>
> Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Draft Policy 2009-3 (Global)
> Allocation of IPv4 Blocks to Regional Internet Registries
>
> Date: 23 March 2009
>
> Policy statement:
>
> This document describes the policy governing the allocation of IPv4
> address space from the IANA to the Regional Internet Registries  
> (RIRs).
> This document does not stipulate performance requirements in the
> provision of services by IANA to an RIR in accordance with this  
> policy.
> Such requirements should be specified by appropriate agreements among
> the RIRs and ICANN.
>
> This policy is to be implemented in two phases.
>
> A. Phase I: Recovery of IPv4 Address Space
>
> Upon ratification of this policy by the ICANN Board of Directors the
> IANA shall establish a mechanism to receive IPv4 address space which  
> is
> returned to it by the RIRs, and hold that address space in a  
> 'recovered
> IPv4 pool'.
>
> Each RIR through their respective chosen policies and strategies may
> recover IPv4 address space which is under their administration. At
> quarterly intervals, each RIR shall return to the IANA any legacy
> address space recovered, and may return to the IANA any non-legacy
> address space recovered, in aggregated blocks of /24 or larger, for
> inclusion in the recovered IPv4 pool.
>
> During Phase I, no allocations will be made from the recovered IPv4
> pool. Return of recovered address space (as described above) will
> continue throughout Phase II.
>
> B. Phase II: Allocation of Recovered IPv4 address space by the IANA
>
> Upon ratification of this policy by the ICANN Board of Directors and a
> declaration by the IANA that its existing free pool of unallocated  
> IPv4
> address space is depleted; Global Addressing Policy ASO-001-2 (adopted
> by ICANN Board 8 April 2005) is rescinded. IANA will then commence to
> allocate the IPv4 address space from the recovered IPv4 pool.
>
> 1. The following definitions apply to this policy:
>
> a. Recovered Address Space. Recovered address space is that address
> space that is returned to an RIR as a result of any activity that  
> seeks
> to reclaim unused address space or is voluntarily returned to the  
> RIR or
> is reclaimed by the RIR as a result of legal action or abuse
> determination. Recovered address space does not include that address
> space that is reclaimed because of non-payment of contractual fees  
> whose
> reclamation date is less than 1 year at the time of the report.
>
> b. IPv4 Address Holdings. IPv4 address holdings are all unallocated  
> IPv4
> address space held by an RIR to include recovered address space not  
> yet
> returned less that address space that is committed in accordance with
> the RIR's reservation policy and practices.
>
> c. Aggregated address blocks. Aggregated address blocks are contiguous
> prefixes that can be aggregated on natural bit boundaries. 10.0.0.0/24
> and 10.0.1.0/24 are two contiguous prefixes that can be combined to  
> form
> an aggregated address block. 10.0.0.0/24 and 10.0.1.0/25 are two
> contiguous prefixes that cannot be combined on a natural bit  
> boundary to
> form an aggregated block.
>
> d. Legacy address space. IPv4 address space allocated or assigned  
> prior
> to the creation of the RIR.
>
> 2. Allocation of IPv4 Address Space
>
> a. For the purposes of this policy, an 'IPv4 allocation period' is
> defined as a 6-month period following 1 March or 1 September in each  
> year.
>
> b. At the beginning of each IPv4 allocation period, the IANA will
> determine the 'IPv4 allocation unit' for that period, as 1/10 of its
> IPv4 address pool, rounded down to the next CIDR (power-of-2)  
> boundary.
> The minimum 'IPv4 allocation unit' size will be a /24.
>
> c. In each allocation period, each RIR may issue one IPv4 request to  
> the
> IANA. Providing that the RIR satisfies the allocation criteria  
> described
> in paragraph B.2, the IANA will allocate a single allocation unit,
> composed of the smallest possible number of blocks available in its  
> IPv4
> address pool.
>
> 3. IPv4 Address Space Allocation Criteria
>
> A RIR is eligible to receive additional IPv4 address space from the  
> IANA
> when the total of its IPv4 address holdings is less than 50% of the
> current IPv4 allocation unit, and providing that it has not already
> received an IPv4 allocation from the IANA during the current IPv4
> allocation period.
>
> 4. Initial Allocation of IPv4 Address Space
>
> Each new RIR shall, at the moment of recognition, be allocated one (1)
> allocation unit by the IANA. If an allocation unit is not available,
> then the IANA will issue this block as soon as one is available. This
> allocation will be made regardless of the newly formed RIR's projected
> utilization figures and shall be independent of the IPv4 address space
> that may have been transferred to the new RIR by the already existing
> RIRs as part of the formal transition process.
>
> 5. Reporting
>
> a. All returned space is to be recorded in an IANA-published log of  
> IPv4
> address space transactions, with each log entry detailing the returned
> address block, the date of the return, and the returning RIR.
>
> b. All allocated space is also to be recorded in this IANA-published  
> log
> of IPv4 address space transactions, with each log entry detailing the
> address blocks, the date of the allocation and the recipient RIR.
>
> c. The IANA will maintain a public registry of the current disposition
> of all IPv4 address space, detailing all reservations and current
> allocations and current IANA-held address space that is unallocated.
>
> d) The IANA may make public announcements of IPv4 address block
> transactions that occur under this policy. The IANA will make
> appropriate modifications to the "Internet Protocol V4 Address Space"
> page of the IANA website and may make announcements to its own
> appropriate announcement lists. The IANA announcements will be limited
> to which address ranges, the time of allocation and to which Registry
> they have been allocated.
>
>
>
> #####
>
> ARIN Staff Assessment
>
> *Title: Allocation of IPv4 Blocks to the Regional Internet Registries*
>
> *Proposal Submitted: 30 Jan 2009*
>
> *Revision Submitted: 05 March 2009*
>
> *Date of Assessment: 10 March 2009*
>
> * *
>
> I. Understanding of the Policy:
>
> *Staff Understanding of the Proposal:*
>
> Staff understands that this proposal would be implemented in 2 phases.
> Phase 1 would require the RIRs to return recovered IPv4 legacy address
> space (via policy or procedure) to the IANA and have the option of
> returning recovered non-legacy address space to the IANA. Phase 2  
> would
> start after the depletion of the IANA free pool and would nullify the
> existing IANA to RIR policy (Global Addressing Policy ASO-001-2). The
> new IANA to RIR policy would allow each RIR to receive approximately
> 1/10th of the recovered IPv4 pool from IANA once every 6 months as  
> long
> as it meets the qualification criteria written in paragraph B2. IANA
> will be required to keep a log of all returned IPv4 address space and
> all issued IPv4 address space from the recovered pool, as well as
> maintain a public registry of the current disposition of all IPv4
> address space.
>
> II. Comments
>
> A. ARIN Staff Comments
>
> * The one policy that this impacts is NRPM 4.6 Amnesty and
>  Aggregation, which says ?Transactions should only be accepted
>  under this policy if they are in the interests of the community
>  (e.g. they improve aggregation or result in a net reclamation of
>  space).? Because the ARIN region holds the majority of the legacy
>  address space, and most of the address space returned under this
>  policy is legacy space, it would mean that there would be no ?net
>  return? of address space to ARIN. ARIN would essentially be
>  exchanging legacy address space for non-legacy address space, and
>  returning the legacy address space it received in the exchange to
>  IANA, resulting in a net loss of address space in ARIN?s available
>  pool.
>
> B. ARIN General Counsel Comments:
>
> The current basis of allocation of numbers was established in RFC's  
> 2008
> and 2050 and is need based. If one region has greater needs than
> another, the current policy of IANA does not require equal  
> distribution
> to all RIR's s. This proposed policy would establish a different
> political and not needs based method for allocating returned space. It
> would make each RIR an equal recipient of such space. But the level of
> need and economic activity between each RI R is not equal. This policy
> will tend to reallocate returned space away from where it is  
> recovered,
> in the ARIN region , and move more of it to AFRINIC and LACNIC than
> current distribution principles. By equating the smaller economies and
> related needs of certain regions to the needs of other regions, like
> ARIN, that have greater day to day need, it in effect creates a new
> political order of distribution thru equal shares. It is possible
> sovereign governments in the regions with greater activity will not
> agree to such a revised distribution model. The proposed policy
> undermines the legal rationale for distribution.
>
> The policy also creates a powerful disincentive for any RIR, including
> ARIN, to undertake any financial expenditure of RIR dollars for  
> programs
> intended to obtain returned space for reallocation. Currently ARIN is
> working towards policies such as the LRSA and 2008-6, intended to
> encourage returns and use of under utilized resources, but which cost
> ARIN expenditures other RIRs are not duplicating. Any policy which
> creates such a disincentive by leaving expenditures with a single RIR,
> who cannot benefit except to receive 20% of the returned space  
> should be
> carefully considered.
>
> Finally, it is likely entities with number resources in the ARIN  
> region
> may be willing to return those resources for uses in the region but
> unwilling to do so if 4/5 of such resources will be sent to other  
> regions.
>
> III. Resource Impact
>
> The resource impact of implementing this policy is viewed as  
> minimal. It
> is estimated that this policy could require up to 3 person months of
> effort to implement following ratification by the ARIN Board of
> Trustees. Because this implementation is not planned, it may preempt
> ARIN?s current project deployment schedule. It may require the follo 
> wing:
>
> * Modifications to existing registration procedures to include the
>  handling of returned/reclaimed address space and the process of
>  requesting additional address space from the IANA.
> * Staff training
>
> Text assessed:
>
> *Allocation of IPv4 Blocks to Regional Internet Registries (Global)*
>
> *Policy statement:*
>
> This document describes the policy governing the allocation of IPv4
> address space from the IANA to the Regional Internet Registries  
> (RIRs).
> This document does not stipulate performance requirements in the
> provision of services by IANA to an RIR in accordance with this  
> policy.
> Such requirements should be specified by appropriate agreements among
> the RIRs and ICANN.
>
> This policy is to be implemented in two phases.
>
> A. Phase I: Recovery of IPv4 Address Space
>
> Upon ratification of this policy by the ICANN Board of Directors the
> IANA shall establish a mechanism to receive IPv4 address space which  
> is
> returned to it by the RIRs, and hold that address space in a  
> 'recovered
> IPv4 pool'.
>
> Each RIR through their respective chosen policies and strategies may
> recover IPv4 address space which is under their administration. At
> quarterly intervals, each RIR shall return any legacy address space
> recovered, and may return any non-legacy address space recovered, to  
> the
> IANA in aggregated blocks of /24 or larger, for inclusion in the
> recovered IPv4 pool.
>
> During Phase I, no allocations will be made from the recovered IPv4
> pool. Return of recovered address space (as described above) will
> continue throughout Phase II.
>
> B. Phase II: Allocation of Recovered IPv4 address space by the IANA
>
> Upon ratification of this policy by the ICANN Board of Directors and a
> declaration by the IANA that its existing free pool of unallocated  
> IPv4
> address space is depleted; Global Addressing Policy ASO-001-2 (adopted
> by ICANN Board 8 April 2005) is rescinded. IANA will then commence to
> allocate the IPv4 address space from the recovered IPv4 pool.
>
> 1. The following definitions apply to this policy:
>
> a. Recovered Address Space. Recovered address space is that address
> space that is returned to an RIR as a result of any activity that  
> seeks
> to reclaim unused address space or is voluntarily returned to the  
> RIR or
> is reclaimed by the RIR as a result of legal action or abuse
> determination. Recovered address space does not include that address
> space that is reclaimed because of non-payment of contractual fees  
> whose
> reclamation date is less than 1 year at the time of the report.
>
> b. IPv4 Address Holdings. IPv4 address holdings are all unallocated  
> IPv4
> address space held by an RIR to include recovered address space not  
> yet
> returned less that address space that is committed in accordance with
> the RIR's reservation policy and practices.
>
> c. Legacy address space. IPv4 address space allocated or assigned  
> prior
> to the creation of the RIR.
>
> 2. Allocation of IPv4 Address Space
>
> a. For the purposes of this policy, an 'IPv4 allocation period' is
> defined as a 6-month period following 1 March or 1 September in each  
> year.
>
> b. At the beginning of each IPv4 allocation period, the IANA will
> determine the 'IPv4 allocation unit' for that period, as 1/10 of its
> IPv4 address pool, rounded down to the next CIDR (power-of-2)  
> boundary.
>
> c. In each allocation period, each RIR may issue one IPv4 request to  
> the
> IANA. Providing that the RIR satisfies the allocation criteria  
> described
> in paragraph B.2, the IANA will allocate a single allocation unit,
> composed of the smallest possible number of blocks available in its  
> IPv4
> address pool.
>
> 3. IPv4 Address Space Allocation Criteria
>
> A RIR is eligible to receive additional IPv4 address space from the  
> IANA
> when the total of its IPv4 address holdings is less than 50% of the
> current IPv4 allocation unit, and providing that it has not already
> received an IPv4 allocation from the IANA during the current IPv4
> allocation period.
>
> 4. Initial Allocation of IPv4 Address Space
>
> Each new RIR shall, at the moment of recognition, be allocated one (1)
> allocation unit by the IANA. If an allocation unit is not available,
> then the IANA will issue this block as soon as one is available. This
> allocation will be made regardless of the newly formed RIR's projected
> utilization figures and shall be independent of the IPv4 address space
> that may have been transferred to the new RIR by the already existing
> RIRs as part of the formal transition process.
>
> 5. Reporting
>
> a. All returned space is to be recorded in an IANA-published log of  
> IPv4
> address space transactions, with each log entry detailing the returned
> address block, the date of the return, and the returning RIR.
>
> b. All allocated space is also to be recorded in this IANA-published  
> log
> of IPv4 address space transactions, with each log entry detailing the
> address blocks, the date of the allocation and the recipient RIR.
>
> c. The IANA will maintain a public registry of the current disposition
> of all IPv4 address space, detailing all reservations and current
> allocations and current IANA-held address space that is unallocated.
>
> d) The IANA may make public announcements of IPv4 address block
> transactions that occur under this policy. The IANA will make
> appropriate modifications to the "Internet Protocol V4 Address Space"
> page of the IANA website and may make announcements to its own
> appropriate announcement lists. The IANA announcements will be limited
> to which address ranges, the time of allocation and to which Registry
> they have been allocated.
>
>
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> rin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> ny issues.


From farmer at umn.edu  Mon Mar 30 02:05:39 2009
From: farmer at umn.edu (David Farmer)
Date: Mon, 30 Mar 2009 01:05:39 -0500
Subject: [arin-ppml] Draft Policy 2009-1: Is there an Emergency?
Message-ID: <49D01AE3.21085.B9720F6@farmer.umn.edu>

I would like to motivate a discussion of the question "Is there 
an Emergency?"

I have heard several people express the opinion that they don't 
see an emergency.  I would like to respectfully disagree with 
that opinion.

In my opinion the crux of the emergency is IPv4 exhaustion 
combined with the lack of IPv6 adoption, which means we are 
going to hit the proverbial wall when it comes to functional IP 
address availability.  But when does this become an 
emergency?

Maybe we can use a car accident as a metaphor;  When does 
a car accident start?  When you hit the wall?  When the 
airbags deploy?  When you fail to make the turn or hit the 
breaks in time to prevent yourself from hitting the wall?

Using this metaphor, I propose;  IANA free pool exhaustion is 
equivalent to the car hitting the wall.  The trigger set in 2009-2: 
Depleted IPv4 Reserves, is the equivalent of the airbags going 
off shortly after the car hits the wall.  RIR and ISP free pool 
exhaustion are equivalent to the passengers hitting the interior 
of the car and the brain and internal organs colliding with the 
skull and the rest of the body, receptively.  

So when did the IPv4 car accident start, when did we hit the 
point where we would inextricably hit the wall?  I'm not exactly 
sure, but I think most of us started realizing back in 2007 that 
we were going to inextricably hit the wall.  And today, to me 
personally it is virtually unquestionable that will we are going to 
hit the wall.  We obviously haven't hit the wall just yet, but the 
car is headed toward the wall to fast to stop or turn, the 
accident must and will happen. 

Further, it is possible we don't have as much time as we think 
we do.  We currently have approximately 500 Million IPv4 
address in the IANA Free Pool.  While current projections, 
based on current usage rates, provide a little over two years to 
exhaustion[1].  However, it is not difficult to imagine scenarios 
where the IANA free pool could be exhausted much sooner 
than that.  For example, if mobile providers were to start 
issuing IPv4 address to mobile hand sets it wouldn't be hard to 
exhaust the IANA free pool in no time flat[2].  

[1] http://www.potaroo.net/tools/ipv4/index.html

[2] 
http://newsroom.parksassociates.com/article_display.cfm?articl
e_id=5128

I'm not saying that will or even should happen, but it is by no 
means impossible.  Further, under current policies if the mobile 
industry came to the RIRs for IPv4 addresses for hand set, the 
RIRs would likely have to fulfill the requests, and exhaust the 
IANA free pool in short order.  

Therefore, at least in reference to IPv4, I believe there is a 
valid Emergency.

So, I'm interested to hear other people's opinion on if there is 
an emergency.

================================================
=======
David Farmer				     Email:	
farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota			     Phone:	612-626-
0815
2218 University Ave SE			     Cell:		
612-812-9952
Minneapolis, MN 55414-3029		     FAX:	612-626-
1818
================================================
=======



From sethm at rollernet.us  Mon Mar 30 02:22:42 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Sun, 29 Mar 2009 23:22:42 -0700
Subject: [arin-ppml] Draft Policy 2009-1: Is there an Emergency?
In-Reply-To: <49D01AE3.21085.B9720F6@farmer.umn.edu>
References: <49D01AE3.21085.B9720F6@farmer.umn.edu>
Message-ID: <49D06532.1050502@rollernet.us>

David Farmer wrote:
> I would like to motivate a discussion of the question "Is there 
> an Emergency?"
> 
> I have heard several people express the opinion that they don't 
> see an emergency.  I would like to respectfully disagree with 
> that opinion.
> 
> In my opinion the crux of the emergency is IPv4 exhaustion 
> combined with the lack of IPv6 adoption, which means we are 
> going to hit the proverbial wall when it comes to functional IP 
> address availability.  But when does this become an 
> emergency?


Lack of interest in entities adopting IPv6 is not ARIN's emergency. It's
a business case issue, as in many orgs see no business case for putting
forth the effort to deploy IPv6 in their networks, not an "emergency".
Find a way to motivate these players to perform a forklift upgrade (when
they see no sense in doing so) and you've won the prize.

~Seth


From farmer at umn.edu  Mon Mar 30 02:38:19 2009
From: farmer at umn.edu (David Farmer)
Date: Mon, 30 Mar 2009 01:38:19 -0500
Subject: [arin-ppml] Draft Policy 2009-1: Is there an Emergency?
In-Reply-To: <49D06532.1050502@rollernet.us>
References: <49D01AE3.21085.B9720F6@farmer.umn.edu>,
	<49D06532.1050502@rollernet.us>
Message-ID: <49D0228B.11438.BB50A3F@farmer.umn.edu>

On 29 Mar 2009 Seth Mattinen wrote:

> David Farmer wrote:
> > I would like to motivate a discussion of the question "Is there 
> > an Emergency?"
> > 
> > I have heard several people express the opinion that they don't 
> > see an emergency.  I would like to respectfully disagree with 
> > that opinion.
> > 
> > In my opinion the crux of the emergency is IPv4 exhaustion 
> > combined with the lack of IPv6 adoption, which means we are 
> > going to hit the proverbial wall when it comes to functional IP 
> > address availability.  But when does this become an 
> > emergency?
> 
> 
> Lack of interest in entities adopting IPv6 is not ARIN's emergency. It's
> a business case issue, as in many orgs see no business case for putting
> forth the effort to deploy IPv6 in their networks, not an "emergency".
> Find a way to motivate these players to perform a forklift upgrade (when
> they see no sense in doing so) and you've won the prize.

To be clear, I agree lack of IPv6 adoption itself isn't an 
emergency, but if you combine it with IPv4 exhaustion it is.

Further, IPv4 exhaustion itself isn't an emergency either, if 
there were significant IPv6 adoption before IPv4 exhaustion 
that would be fine.

Put the two together and in my book you have an emergency, 
and that emergency is the lack of availability of useful IP 
addresses.  IPv4 will not be easily available, and IPv6 will not 
be very useful substitute.  That is an emergency.


================================================
=======
David Farmer				     Email:	
farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota			     Phone:	612-626-
0815
2218 University Ave SE			     Cell:		
612-812-9952
Minneapolis, MN 55414-3029		     FAX:	612-626-
1818
================================================
=======



From cort at kanren.net  Mon Mar 30 09:34:39 2009
From: cort at kanren.net (Cort Buffington)
Date: Mon, 30 Mar 2009 08:34:39 -0500
Subject: [arin-ppml] Draft Policy 2009-1: Is there an Emergency?
In-Reply-To: <49D06532.1050502@rollernet.us>
References: <49D01AE3.21085.B9720F6@farmer.umn.edu>
	<49D06532.1050502@rollernet.us>
Message-ID: <1910C727-ED61-4046-8A99-D0C29436E08B@kanren.net>


On Mar 30, 2009, at 1:22 AM, Seth Mattinen wrote:

> David Farmer wrote:
>>
>> In my opinion the crux of the emergency is IPv4 exhaustion
>> combined with the lack of IPv6 adoption, which means we are
>> going to hit the proverbial wall when it comes to functional IP
>> address availability.  But when does this become an
>> emergency?
>
> Lack of interest in entities adopting IPv6 is not ARIN's emergency.  
> It's
> a business case issue, as in many orgs see no business case for  
> putting
> forth the effort to deploy IPv6 in their networks, not an "emergency".
> Find a way to motivate these players to perform a forklift upgrade  
> (when
> they see no sense in doing so) and you've won the prize.
> ~Seth


This is the point I would make from all of this: If they'd been paying  
attention to more than profit for the next quarter, a forklift  
wouldn't be required, and this (will | would) not have become an  
emergency. The motivation is strategic vision beyond the earnings for  
next quarter or even fiscal year... Of course the state of our entire  
economy only emphasizes how much of this we are not doing as a society.

Emergency? I think so. But I don't think that the majority of the  
networking community will choose to deal with this until it reaches  
crisis state. By the time we reach crisis, the problem will be too big  
to worry about pointing fingers. As usual in the US, those who were  
responsible enough to deal with it before it became and emergency will  
see no benefit since there will be some kind of either bailout, or  
social acceptance of the crisis and the half-baked solutions that will  
come with waiting until two weeks past the very last date to  
reasonable address the issue.

--
Cort Buffington
Executive Director
The Kansas Research and Education Network
cort at kanren.net
Office: +1-785-856-9800 x301
Mobile: +1-785-865-7206







From plzak at arin.net  Mon Mar 30 10:08:45 2009
From: plzak at arin.net (Ray Plzak)
Date: Mon, 30 Mar 2009 10:08:45 -0400
Subject: [arin-ppml] Draft Policy 2009-3 (Global): Allocation of IPv4
 Blocks to Regional Internet Registries
In-Reply-To: <4C1054E8-D5C6-458A-90F7-F00CA7ECCEE7@gmail.com>
References: <37137.208.54.95.48.1238379940.squirrel@webmail.lacnic.net.uy>
	<4C1054E8-D5C6-458A-90F7-F00CA7ECCEE7@gmail.com>
Message-ID: <FEA070315E40A3489D38398C35FE7BB236401F6416@EDAMAME.arin.net>

The PDP provides for both proposals to be discussed in the PPM.

Ray

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand
Sent: Sunday, March 29, 2009 11:41 PM
To: Raul Echeberria
Cc: ARIN-PPML List
Subject: Re: [arin-ppml] Draft Policy 2009-3 (Global): Allocation of IPv4 Blocks to Regional Internet Registries

Raul,

I have no problem discussing the original proposal, but based on the
PPML discussion to date, and what I've heard in discussions, IMO the
original unamended proposal has almost no support, and is extremely
unlikely to gain consensus in the ARIN region.  If anyone favors the
original proposal, please speak up.

Based on our estimation of the consensus in the ARIN region, the AC
amended the proposal to give it a better chance of passing, while
preserving as much of the original proposal as possible. I would
welcome additional feedback on the balance we attempted to strike,
either here or in San Antonio.

Thanks,
Scott

On Mar 29, 2009, at 7:25 PM, raul at lacnic.net wrote:

>
> Dear all:
>
> This proposal is a proposal for a global policy. It means that the
> same
> proposal has to be approved in every region. They can be approved with
> some wording differences, but the spirit of the proposal should be the
> same.
>
> The proposal was the result of a long collaboration effort of senior
> staff
> members and board members of all the 5 RIRs and the original text is
> the
> one that is being considered in every region.
>
> As far as I know the authors of the proposal were not consulted by the
> ARIN-AC and based on exchanges among the authors in the past few
> days, I
> can say that in general the feeling is that the changes introduced
> by the
> ARIN-AC are very signficant and so, this is a different proposal.
>
> My personal view is that changing the concept of a global policy
> proposal
> in one RIR means to avoid the approval of the policy. I strongly
> encourage
> ARIN to put the original proposal under consideration of its
> community as
> it is being done in the other regions. The proposal can be approved or
> not, That's part of the process, but it doesn't make sense to
> approve a
> different proposal. IMHO, the AC is able to put forward the new
> proposal
> for discussion if they consider that it is better, and in that way to
> start the process of discussion of a new global policy proposal.
>
> I have to confess that dealing with 5 different PDPs is not so easy. I
> don't know if a petition process should be started, If yes, please
> take
> this email as the request for initiating that process.
>
> Since this announcement was issued last Monday in the afternoon, I
> am not
> sure how the business days are counted, but I guess that I am still
> within
> the valid period.
>
> However, I think that as a practices, global policy proposals should
> not
> be changed by any advisory council or policy chair of one region due
> to
> the impact that to change the proposal produce in the global process.
>
>
> Best Regards,
>
> Ra?l
>
>
>
> ---------------
>
>
>
> El 23/03/2009, a las 04:05 p.m., Member Services escribi?:
>
> Draft Policy 2009-3 (Global)
> Allocation of IPv4 Blocks to Regional Internet Registries
>
> The following draft policy text is being posted for feedback and
> discussion on the Public Policy Mailing List (PPML).
>
> This draft policy was developed by the ARIN Advisory Council (AC) from
> Policy Proposal 82: Allocation of IPv4 Blocks to Regional Internet
> Registries. The AC has taken the proposal and developed it into a
> draft
> policy. The AC was required to submit text to ARIN for staff and legal
> assessment prior to selecting it as a draft policy. The assessment,
> along with the text that was assessed, is located below the draft
> policy.
>
> On 20 March 2009 the ARIN Advisory Council (AC) selected Draft Policy
> 2009-3: Allocation of IPv4 Blocks to Regional Internet Registries for
> adoption discussion on the PPML and at the upcoming Public Policy
> Meeting.
>
> Draft Policy 2009-3 is below and can be found at:
> https://www.arin.net/policy/proposals/2009_3.html
>
> We encourage you to discuss Draft Policy 2009-3 on the PPML prior to
> the
> ARIN XXIII Public Policy Meeting. Both the discussion on the PPML
> and at
> the Public Policy Meeting will be used by the AC to determine the
> community consensus regarding adopting this as policy.
>
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
>
> All of the Draft Policies under discussion can be found at:
> https://www.arin.net/policy/proposals/index.html
>
> Regards,
>
> Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Draft Policy 2009-3 (Global)
> Allocation of IPv4 Blocks to Regional Internet Registries
>
> Date: 23 March 2009
>
> Policy statement:
>
> This document describes the policy governing the allocation of IPv4
> address space from the IANA to the Regional Internet Registries
> (RIRs).
> This document does not stipulate performance requirements in the
> provision of services by IANA to an RIR in accordance with this
> policy.
> Such requirements should be specified by appropriate agreements among
> the RIRs and ICANN.
>
> This policy is to be implemented in two phases.
>
> A. Phase I: Recovery of IPv4 Address Space
>
> Upon ratification of this policy by the ICANN Board of Directors the
> IANA shall establish a mechanism to receive IPv4 address space which
> is
> returned to it by the RIRs, and hold that address space in a
> 'recovered
> IPv4 pool'.
>
> Each RIR through their respective chosen policies and strategies may
> recover IPv4 address space which is under their administration. At
> quarterly intervals, each RIR shall return to the IANA any legacy
> address space recovered, and may return to the IANA any non-legacy
> address space recovered, in aggregated blocks of /24 or larger, for
> inclusion in the recovered IPv4 pool.
>
> During Phase I, no allocations will be made from the recovered IPv4
> pool. Return of recovered address space (as described above) will
> continue throughout Phase II.
>
> B. Phase II: Allocation of Recovered IPv4 address space by the IANA
>
> Upon ratification of this policy by the ICANN Board of Directors and a
> declaration by the IANA that its existing free pool of unallocated
> IPv4
> address space is depleted; Global Addressing Policy ASO-001-2 (adopted
> by ICANN Board 8 April 2005) is rescinded. IANA will then commence to
> allocate the IPv4 address space from the recovered IPv4 pool.
>
> 1. The following definitions apply to this policy:
>
> a. Recovered Address Space. Recovered address space is that address
> space that is returned to an RIR as a result of any activity that
> seeks
> to reclaim unused address space or is voluntarily returned to the
> RIR or
> is reclaimed by the RIR as a result of legal action or abuse
> determination. Recovered address space does not include that address
> space that is reclaimed because of non-payment of contractual fees
> whose
> reclamation date is less than 1 year at the time of the report.
>
> b. IPv4 Address Holdings. IPv4 address holdings are all unallocated
> IPv4
> address space held by an RIR to include recovered address space not
> yet
> returned less that address space that is committed in accordance with
> the RIR's reservation policy and practices.
>
> c. Aggregated address blocks. Aggregated address blocks are contiguous
> prefixes that can be aggregated on natural bit boundaries. 10.0.0.0/24
> and 10.0.1.0/24 are two contiguous prefixes that can be combined to
> form
> an aggregated address block. 10.0.0.0/24 and 10.0.1.0/25 are two
> contiguous prefixes that cannot be combined on a natural bit
> boundary to
> form an aggregated block.
>
> d. Legacy address space. IPv4 address space allocated or assigned
> prior
> to the creation of the RIR.
>
> 2. Allocation of IPv4 Address Space
>
> a. For the purposes of this policy, an 'IPv4 allocation period' is
> defined as a 6-month period following 1 March or 1 September in each
> year.
>
> b. At the beginning of each IPv4 allocation period, the IANA will
> determine the 'IPv4 allocation unit' for that period, as 1/10 of its
> IPv4 address pool, rounded down to the next CIDR (power-of-2)
> boundary.
> The minimum 'IPv4 allocation unit' size will be a /24.
>
> c. In each allocation period, each RIR may issue one IPv4 request to
> the
> IANA. Providing that the RIR satisfies the allocation criteria
> described
> in paragraph B.2, the IANA will allocate a single allocation unit,
> composed of the smallest possible number of blocks available in its
> IPv4
> address pool.
>
> 3. IPv4 Address Space Allocation Criteria
>
> A RIR is eligible to receive additional IPv4 address space from the
> IANA
> when the total of its IPv4 address holdings is less than 50% of the
> current IPv4 allocation unit, and providing that it has not already
> received an IPv4 allocation from the IANA during the current IPv4
> allocation period.
>
> 4. Initial Allocation of IPv4 Address Space
>
> Each new RIR shall, at the moment of recognition, be allocated one (1)
> allocation unit by the IANA. If an allocation unit is not available,
> then the IANA will issue this block as soon as one is available. This
> allocation will be made regardless of the newly formed RIR's projected
> utilization figures and shall be independent of the IPv4 address space
> that may have been transferred to the new RIR by the already existing
> RIRs as part of the formal transition process.
>
> 5. Reporting
>
> a. All returned space is to be recorded in an IANA-published log of
> IPv4
> address space transactions, with each log entry detailing the returned
> address block, the date of the return, and the returning RIR.
>
> b. All allocated space is also to be recorded in this IANA-published
> log
> of IPv4 address space transactions, with each log entry detailing the
> address blocks, the date of the allocation and the recipient RIR.
>
> c. The IANA will maintain a public registry of the current disposition
> of all IPv4 address space, detailing all reservations and current
> allocations and current IANA-held address space that is unallocated.
>
> d) The IANA may make public announcements of IPv4 address block
> transactions that occur under this policy. The IANA will make
> appropriate modifications to the "Internet Protocol V4 Address Space"
> page of the IANA website and may make announcements to its own
> appropriate announcement lists. The IANA announcements will be limited
> to which address ranges, the time of allocation and to which Registry
> they have been allocated.
>
>
>
> #####
>
> ARIN Staff Assessment
>
> *Title: Allocation of IPv4 Blocks to the Regional Internet Registries*
>
> *Proposal Submitted: 30 Jan 2009*
>
> *Revision Submitted: 05 March 2009*
>
> *Date of Assessment: 10 March 2009*
>
> * *
>
> I. Understanding of the Policy:
>
> *Staff Understanding of the Proposal:*
>
> Staff understands that this proposal would be implemented in 2 phases.
> Phase 1 would require the RIRs to return recovered IPv4 legacy address
> space (via policy or procedure) to the IANA and have the option of
> returning recovered non-legacy address space to the IANA. Phase 2
> would
> start after the depletion of the IANA free pool and would nullify the
> existing IANA to RIR policy (Global Addressing Policy ASO-001-2). The
> new IANA to RIR policy would allow each RIR to receive approximately
> 1/10th of the recovered IPv4 pool from IANA once every 6 months as
> long
> as it meets the qualification criteria written in paragraph B2. IANA
> will be required to keep a log of all returned IPv4 address space and
> all issued IPv4 address space from the recovered pool, as well as
> maintain a public registry of the current disposition of all IPv4
> address space.
>
> II. Comments
>
> A. ARIN Staff Comments
>
> * The one policy that this impacts is NRPM 4.6 Amnesty and
>  Aggregation, which says ?Transactions should only be accepted
>  under this policy if they are in the interests of the community
>  (e.g. they improve aggregation or result in a net reclamation of
>  space).? Because the ARIN region holds the majority of the legacy
>  address space, and most of the address space returned under this
>  policy is legacy space, it would mean that there would be no ?net
>  return? of address space to ARIN. ARIN would essentially be
>  exchanging legacy address space for non-legacy address space, and
>  returning the legacy address space it received in the exchange to
>  IANA, resulting in a net loss of address space in ARIN?s available
>  pool.
>
> B. ARIN General Counsel Comments:
>
> The current basis of allocation of numbers was established in RFC's
> 2008
> and 2050 and is need based. If one region has greater needs than
> another, the current policy of IANA does not require equal
> distribution
> to all RIR's s. This proposed policy would establish a different
> political and not needs based method for allocating returned space. It
> would make each RIR an equal recipient of such space. But the level of
> need and economic activity between each RI R is not equal. This policy
> will tend to reallocate returned space away from where it is
> recovered,
> in the ARIN region , and move more of it to AFRINIC and LACNIC than
> current distribution principles. By equating the smaller economies and
> related needs of certain regions to the needs of other regions, like
> ARIN, that have greater day to day need, it in effect creates a new
> political order of distribution thru equal shares. It is possible
> sovereign governments in the regions with greater activity will not
> agree to such a revised distribution model. The proposed policy
> undermines the legal rationale for distribution.
>
> The policy also creates a powerful disincentive for any RIR, including
> ARIN, to undertake any financial expenditure of RIR dollars for
> programs
> intended to obtain returned space for reallocation. Currently ARIN is
> working towards policies such as the LRSA and 2008-6, intended to
> encourage returns and use of under utilized resources, but which cost
> ARIN expenditures other RIRs are not duplicating. Any policy which
> creates such a disincentive by leaving expenditures with a single RIR,
> who cannot benefit except to receive 20% of the returned space
> should be
> carefully considered.
>
> Finally, it is likely entities with number resources in the ARIN
> region
> may be willing to return those resources for uses in the region but
> unwilling to do so if 4/5 of such resources will be sent to other
> regions.
>
> III. Resource Impact
>
> The resource impact of implementing this policy is viewed as
> minimal. It
> is estimated that this policy could require up to 3 person months of
> effort to implement following ratification by the ARIN Board of
> Trustees. Because this implementation is not planned, it may preempt
> ARIN?s current project deployment schedule. It may require the follo
> wing:
>
> * Modifications to existing registration procedures to include the
>  handling of returned/reclaimed address space and the process of
>  requesting additional address space from the IANA.
> * Staff training
>
> Text assessed:
>
> *Allocation of IPv4 Blocks to Regional Internet Registries (Global)*
>
> *Policy statement:*
>
> This document describes the policy governing the allocation of IPv4
> address space from the IANA to the Regional Internet Registries
> (RIRs).
> This document does not stipulate performance requirements in the
> provision of services by IANA to an RIR in accordance with this
> policy.
> Such requirements should be specified by appropriate agreements among
> the RIRs and ICANN.
>
> This policy is to be implemented in two phases.
>
> A. Phase I: Recovery of IPv4 Address Space
>
> Upon ratification of this policy by the ICANN Board of Directors the
> IANA shall establish a mechanism to receive IPv4 address space which
> is
> returned to it by the RIRs, and hold that address space in a
> 'recovered
> IPv4 pool'.
>
> Each RIR through their respective chosen policies and strategies may
> recover IPv4 address space which is under their administration. At
> quarterly intervals, each RIR shall return any legacy address space
> recovered, and may return any non-legacy address space recovered, to
> the
> IANA in aggregated blocks of /24 or larger, for inclusion in the
> recovered IPv4 pool.
>
> During Phase I, no allocations will be made from the recovered IPv4
> pool. Return of recovered address space (as described above) will
> continue throughout Phase II.
>
> B. Phase II: Allocation of Recovered IPv4 address space by the IANA
>
> Upon ratification of this policy by the ICANN Board of Directors and a
> declaration by the IANA that its existing free pool of unallocated
> IPv4
> address space is depleted; Global Addressing Policy ASO-001-2 (adopted
> by ICANN Board 8 April 2005) is rescinded. IANA will then commence to
> allocate the IPv4 address space from the recovered IPv4 pool.
>
> 1. The following definitions apply to this policy:
>
> a. Recovered Address Space. Recovered address space is that address
> space that is returned to an RIR as a result of any activity that
> seeks
> to reclaim unused address space or is voluntarily returned to the
> RIR or
> is reclaimed by the RIR as a result of legal action or abuse
> determination. Recovered address space does not include that address
> space that is reclaimed because of non-payment of contractual fees
> whose
> reclamation date is less than 1 year at the time of the report.
>
> b. IPv4 Address Holdings. IPv4 address holdings are all unallocated
> IPv4
> address space held by an RIR to include recovered address space not
> yet
> returned less that address space that is committed in accordance with
> the RIR's reservation policy and practices.
>
> c. Legacy address space. IPv4 address space allocated or assigned
> prior
> to the creation of the RIR.
>
> 2. Allocation of IPv4 Address Space
>
> a. For the purposes of this policy, an 'IPv4 allocation period' is
> defined as a 6-month period following 1 March or 1 September in each
> year.
>
> b. At the beginning of each IPv4 allocation period, the IANA will
> determine the 'IPv4 allocation unit' for that period, as 1/10 of its
> IPv4 address pool, rounded down to the next CIDR (power-of-2)
> boundary.
>
> c. In each allocation period, each RIR may issue one IPv4 request to
> the
> IANA. Providing that the RIR satisfies the allocation criteria
> described
> in paragraph B.2, the IANA will allocate a single allocation unit,
> composed of the smallest possible number of blocks available in its
> IPv4
> address pool.
>
> 3. IPv4 Address Space Allocation Criteria
>
> A RIR is eligible to receive additional IPv4 address space from the
> IANA
> when the total of its IPv4 address holdings is less than 50% of the
> current IPv4 allocation unit, and providing that it has not already
> received an IPv4 allocation from the IANA during the current IPv4
> allocation period.
>
> 4. Initial Allocation of IPv4 Address Space
>
> Each new RIR shall, at the moment of recognition, be allocated one (1)
> allocation unit by the IANA. If an allocation unit is not available,
> then the IANA will issue this block as soon as one is available. This
> allocation will be made regardless of the newly formed RIR's projected
> utilization figures and shall be independent of the IPv4 address space
> that may have been transferred to the new RIR by the already existing
> RIRs as part of the formal transition process.
>
> 5. Reporting
>
> a. All returned space is to be recorded in an IANA-published log of
> IPv4
> address space transactions, with each log entry detailing the returned
> address block, the date of the return, and the returning RIR.
>
> b. All allocated space is also to be recorded in this IANA-published
> log
> of IPv4 address space transactions, with each log entry detailing the
> address blocks, the date of the allocation and the recipient RIR.
>
> c. The IANA will maintain a public registry of the current disposition
> of all IPv4 address space, detailing all reservations and current
> allocations and current IANA-held address space that is unallocated.
>
> d) The IANA may make public announcements of IPv4 address block
> transactions that occur under this policy. The IANA will make
> appropriate modifications to the "Internet Protocol V4 Address Space"
> page of the IANA website and may make announcements to its own
> appropriate announcement lists. The IANA announcements will be limited
> to which address ranges, the time of allocation and to which Registry
> they have been allocated.
>
>
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> rin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> ny issues.
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.

From khelms at zcorum.com  Mon Mar 30 10:15:06 2009
From: khelms at zcorum.com (Scott Helms)
Date: Mon, 30 Mar 2009 10:15:06 -0400
Subject: [arin-ppml] How hard is it to transition to IPv6?
In-Reply-To: <28E139F46D45AF49A31950F88C49745859BFC6@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C49745859BFC6@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <49D0D3EA.40603@zcorum.com>

Michael,

    I didn't get to reply to this earlier and only do so now to make 
sure I am communicating clearly.  I did not intend for anything to be 
taken as an attack, but I do feel very strongly that the industry in 
general ignores the smaller providers and I took your comments as 
continuing that cavalier approach.

michael.dillon at bt.com wrote:
>>     That is an interesting choice of words.  I don't know 
>> what kind of people you work for/with (I assume from your 
>> email address BT) but I can tell you that if I told my 
>> customers, who are ISPs, that they should stop "complaining" 
>> because they were "negligent" the response wouldn't be all 
>> that friendly. 
>>     
>
> That is an ad hominem attack and is not allowed on the ARIN
> policy discussion lists. You should be ashamed of yourself.
>   
Err, what?  This wasn't an attack of any sort and was much cooler than 
the initial reply I typed.  Perhaps the word negligent doesn't mean the 
same thing to you as it does to me, but that has an extremely negative 
connotation IMO.  When you use strong wording you will get a strong 
response.

> I don't speak for BT or any other company who hosts one of
> my three email addresses. Why would you think otherwise?
> Do you think that the only people on this list are owner
> operators of their own business.
>   
I never said anything about owner/operators.  I'm not nor does that have 
any bearing on the conversation in my view, what does is experience at 
various kinds and sizes of organizations.  That was my entire point, 
working at BT doesn't give you a clear picture of the challenges the 
face small and medium ISP's any more than working at a small ISP would 
give someone a good understanding of the issues that BT faces.  
Certainly anyone with any experience in the industry will understand far 
more than the general public or even other technology professionals but 
not enough insight to be able to say that X will be problematic while Y 
will be easy.

> And read my email again, carefully this time. In effect, I told
> the customers of all ISPs, not just one ISP, that they SHOULD
> complain about their ISP supplier's negligence if that ISP 
> supplier does not provide satisfactory timelines for IPv6 support.
> If you are signing two year contracts, then you might get one 
> more renegotiation cycle before IPv4 runs out. If you are signing
> on for three years, you might not get a chance until it is 
> too late, which means that NOW IS THE TIME TO TALK TO ALL OF
> YOUR SUPPLIERS of network services and network equipment and
> network software. This is simple reasoning based on the 
> projected runout dates.
>   
We are, have been, and will continue to do so but again the largest 
challenges that ISPs face are the pieces that end users directly 
control.  What I was trying to get across, and apparently failing, was 
that the Google example is not particularly applicable to ISPs, 
especially small and medium ones.

> P.P.S. My employer BT has at least one ISP customer who is complaining
> that we haven't got full IPv6 support soon enough. This is good. It
> helps 
> us to do the right thing. Arguing about IPv6 in industry fora is lots of
>
> fun but does not lead to the right results. The only dialog that will
> help
> you get what you need to fully deploy IPv6 is dialog with your
> suppliers.
> If you aren't already engaged in that dialog this late in the game then
> you definitely should be complaining to suppliers, raising ruckus with
> them, escalating it with them and suing them if necessary.
>
> Here, read about what happens when a customer complains, down near
> the bottom of this page <http://www.aaisp.net.uk/news-ipv6.html>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
>
>   


-- 
Scott Helms
Vice President of Technology
ISP Alliance, Inc. DBA ZCorum
(678) 507-5000



From farmer at umn.edu  Mon Mar 30 10:39:24 2009
From: farmer at umn.edu (David Farmer)
Date: Mon, 30 Mar 2009 09:39:24 -0500
Subject: [arin-ppml] Draft Policy 2009-3 (Global): Allocation of IPv4
	Blocks to Regional Internet Registries
In-Reply-To: <FEA070315E40A3489D38398C35FE7BB236401F6416@EDAMAME.arin.net>
References: <37137.208.54.95.48.1238379940.squirrel@webmail.lacnic.net.uy>,
	<4C1054E8-D5C6-458A-90F7-F00CA7ECCEE7@gmail.com>,
	<FEA070315E40A3489D38398C35FE7BB236401F6416@EDAMAME.arin.net>
Message-ID: <49D0934C.913.D6D7EC7@farmer.umn.edu>

Ray,

I am probablly missreading something in the PDP, but I'm not 
sure how that is possible.  At least without a successful 
petition, I believe the only text that can be discussed for 
adoption is the Draft Policy created by the AC.

On 30 Mar 2009 Ray Plzak wrote:

> The PDP provides for both proposals to be discussed in the PPM.
> 
> Ray
> 
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand
> Sent: Sunday, March 29, 2009 11:41 PM
> To: Raul Echeberria
> Cc: ARIN-PPML List
> Subject: Re: [arin-ppml] Draft Policy 2009-3 (Global): Allocation of IPv4 Blocks to Regional Internet Registries
> 
> Raul,
> 
> I have no problem discussing the original proposal, but based on the
> PPML discussion to date, and what I've heard in discussions, IMO the
> original unamended proposal has almost no support, and is extremely
> unlikely to gain consensus in the ARIN region.  If anyone favors the
> original proposal, please speak up.
> 
> Based on our estimation of the consensus in the ARIN region, the AC
> amended the proposal to give it a better chance of passing, while
> preserving as much of the original proposal as possible. I would
> welcome additional feedback on the balance we attempted to strike,
> either here or in San Antonio.
> 
> Thanks,
> Scott
> 
> On Mar 29, 2009, at 7:25 PM, raul at lacnic.net wrote:
> 
> >
> > Dear all:
> >
> > This proposal is a proposal for a global policy. It means that the
> > same
> > proposal has to be approved in every region. They can be approved with
> > some wording differences, but the spirit of the proposal should be the
> > same.
> >
> > The proposal was the result of a long collaboration effort of senior
> > staff
> > members and board members of all the 5 RIRs and the original text is
> > the
> > one that is being considered in every region.
> >
> > As far as I know the authors of the proposal were not consulted by the
> > ARIN-AC and based on exchanges among the authors in the past few
> > days, I
> > can say that in general the feeling is that the changes introduced
> > by the
> > ARIN-AC are very signficant and so, this is a different proposal.
> >
> > My personal view is that changing the concept of a global policy
> > proposal
> > in one RIR means to avoid the approval of the policy. I strongly
> > encourage
> > ARIN to put the original proposal under consideration of its
> > community as
> > it is being done in the other regions. The proposal can be approved or
> > not, That's part of the process, but it doesn't make sense to
> > approve a
> > different proposal. IMHO, the AC is able to put forward the new
> > proposal
> > for discussion if they consider that it is better, and in that way to
> > start the process of discussion of a new global policy proposal.
> >
> > I have to confess that dealing with 5 different PDPs is not so easy. I
> > don't know if a petition process should be started, If yes, please
> > take
> > this email as the request for initiating that process.
> >
> > Since this announcement was issued last Monday in the afternoon, I
> > am not
> > sure how the business days are counted, but I guess that I am still
> > within
> > the valid period.
> >
> > However, I think that as a practices, global policy proposals should
> > not
> > be changed by any advisory council or policy chair of one region due
> > to
> > the impact that to change the proposal produce in the global process.
> >
> >
> > Best Regards,
> >
> > Ra?l
> >
> >
> >
> > ---------------
> >
> >
> >
> > El 23/03/2009, a las 04:05 p.m., Member Services escribi?:
> >
> > Draft Policy 2009-3 (Global)
> > Allocation of IPv4 Blocks to Regional Internet Registries
> >
> > The following draft policy text is being posted for feedback and
> > discussion on the Public Policy Mailing List (PPML).
> >
> > This draft policy was developed by the ARIN Advisory Council (AC) from
> > Policy Proposal 82: Allocation of IPv4 Blocks to Regional Internet
> > Registries. The AC has taken the proposal and developed it into a
> > draft
> > policy. The AC was required to submit text to ARIN for staff and legal
> > assessment prior to selecting it as a draft policy. The assessment,
> > along with the text that was assessed, is located below the draft
> > policy.
> >
> > On 20 March 2009 the ARIN Advisory Council (AC) selected Draft Policy
> > 2009-3: Allocation of IPv4 Blocks to Regional Internet Registries for
> > adoption discussion on the PPML and at the upcoming Public Policy
> > Meeting.
> >
> > Draft Policy 2009-3 is below and can be found at:
> > https://www.arin.net/policy/proposals/2009_3.html
> >
> > We encourage you to discuss Draft Policy 2009-3 on the PPML prior to
> > the
> > ARIN XXIII Public Policy Meeting. Both the discussion on the PPML
> > and at
> > the Public Policy Meeting will be used by the AC to determine the
> > community consensus regarding adopting this as policy.
> >
> > The ARIN Policy Development Process can be found at:
> > https://www.arin.net/policy/pdp.html
> >
> > All of the Draft Policies under discussion can be found at:
> > https://www.arin.net/policy/proposals/index.html
> >
> > Regards,
> >
> > Member Services
> > American Registry for Internet Numbers (ARIN)
> >
> >
> > ## * ##
> >
> >
> > Draft Policy 2009-3 (Global)
> > Allocation of IPv4 Blocks to Regional Internet Registries
> >
> > Date: 23 March 2009
> >
> > Policy statement:
> >
> > This document describes the policy governing the allocation of IPv4
> > address space from the IANA to the Regional Internet Registries
> > (RIRs).
> > This document does not stipulate performance requirements in the
> > provision of services by IANA to an RIR in accordance with this
> > policy.
> > Such requirements should be specified by appropriate agreements among
> > the RIRs and ICANN.
> >
> > This policy is to be implemented in two phases.
> >
> > A. Phase I: Recovery of IPv4 Address Space
> >
> > Upon ratification of this policy by the ICANN Board of Directors the
> > IANA shall establish a mechanism to receive IPv4 address space which
> > is
> > returned to it by the RIRs, and hold that address space in a
> > 'recovered
> > IPv4 pool'.
> >
> > Each RIR through their respective chosen policies and strategies may
> > recover IPv4 address space which is under their administration. At
> > quarterly intervals, each RIR shall return to the IANA any legacy
> > address space recovered, and may return to the IANA any non-legacy
> > address space recovered, in aggregated blocks of /24 or larger, for
> > inclusion in the recovered IPv4 pool.
> >
> > During Phase I, no allocations will be made from the recovered IPv4
> > pool. Return of recovered address space (as described above) will
> > continue throughout Phase II.
> >
> > B. Phase II: Allocation of Recovered IPv4 address space by the IANA
> >
> > Upon ratification of this policy by the ICANN Board of Directors and a
> > declaration by the IANA that its existing free pool of unallocated
> > IPv4
> > address space is depleted; Global Addressing Policy ASO-001-2 (adopted
> > by ICANN Board 8 April 2005) is rescinded. IANA will then commence to
> > allocate the IPv4 address space from the recovered IPv4 pool.
> >
> > 1. The following definitions apply to this policy:
> >
> > a. Recovered Address Space. Recovered address space is that address
> > space that is returned to an RIR as a result of any activity that
> > seeks
> > to reclaim unused address space or is voluntarily returned to the
> > RIR or
> > is reclaimed by the RIR as a result of legal action or abuse
> > determination. Recovered address space does not include that address
> > space that is reclaimed because of non-payment of contractual fees
> > whose
> > reclamation date is less than 1 year at the time of the report.
> >
> > b. IPv4 Address Holdings. IPv4 address holdings are all unallocated
> > IPv4
> > address space held by an RIR to include recovered address space not
> > yet
> > returned less that address space that is committed in accordance with
> > the RIR's reservation policy and practices.
> >
> > c. Aggregated address blocks. Aggregated address blocks are contiguous
> > prefixes that can be aggregated on natural bit boundaries. 10.0.0.0/24
> > and 10.0.1.0/24 are two contiguous prefixes that can be combined to
> > form
> > an aggregated address block. 10.0.0.0/24 and 10.0.1.0/25 are two
> > contiguous prefixes that cannot be combined on a natural bit
> > boundary to
> > form an aggregated block.
> >
> > d. Legacy address space. IPv4 address space allocated or assigned
> > prior
> > to the creation of the RIR.
> >
> > 2. Allocation of IPv4 Address Space
> >
> > a. For the purposes of this policy, an 'IPv4 allocation period' is
> > defined as a 6-month period following 1 March or 1 September in each
> > year.
> >
> > b. At the beginning of each IPv4 allocation period, the IANA will
> > determine the 'IPv4 allocation unit' for that period, as 1/10 of its
> > IPv4 address pool, rounded down to the next CIDR (power-of-2)
> > boundary.
> > The minimum 'IPv4 allocation unit' size will be a /24.
> >
> > c. In each allocation period, each RIR may issue one IPv4 request to
> > the
> > IANA. Providing that the RIR satisfies the allocation criteria
> > described
> > in paragraph B.2, the IANA will allocate a single allocation unit,
> > composed of the smallest possible number of blocks available in its
> > IPv4
> > address pool.
> >
> > 3. IPv4 Address Space Allocation Criteria
> >
> > A RIR is eligible to receive additional IPv4 address space from the
> > IANA
> > when the total of its IPv4 address holdings is less than 50% of the
> > current IPv4 allocation unit, and providing that it has not already
> > received an IPv4 allocation from the IANA during the current IPv4
> > allocation period.
> >
> > 4. Initial Allocation of IPv4 Address Space
> >
> > Each new RIR shall, at the moment of recognition, be allocated one (1)
> > allocation unit by the IANA. If an allocation unit is not available,
> > then the IANA will issue this block as soon as one is available. This
> > allocation will be made regardless of the newly formed RIR's projected
> > utilization figures and shall be independent of the IPv4 address space
> > that may have been transferred to the new RIR by the already existing
> > RIRs as part of the formal transition process.
> >
> > 5. Reporting
> >
> > a. All returned space is to be recorded in an IANA-published log of
> > IPv4
> > address space transactions, with each log entry detailing the returned
> > address block, the date of the return, and the returning RIR.
> >
> > b. All allocated space is also to be recorded in this IANA-published
> > log
> > of IPv4 address space transactions, with each log entry detailing the
> > address blocks, the date of the allocation and the recipient RIR.
> >
> > c. The IANA will maintain a public registry of the current disposition
> > of all IPv4 address space, detailing all reservations and current
> > allocations and current IANA-held address space that is unallocated.
> >
> > d) The IANA may make public announcements of IPv4 address block
> > transactions that occur under this policy. The IANA will make
> > appropriate modifications to the "Internet Protocol V4 Address Space"
> > page of the IANA website and may make announcements to its own
> > appropriate announcement lists. The IANA announcements will be limited
> > to which address ranges, the time of allocation and to which Registry
> > they have been allocated.
> >
> >
> >
> > #####
> >
> > ARIN Staff Assessment
> >
> > *Title: Allocation of IPv4 Blocks to the Regional Internet Registries*
> >
> > *Proposal Submitted: 30 Jan 2009*
> >
> > *Revision Submitted: 05 March 2009*
> >
> > *Date of Assessment: 10 March 2009*
> >
> > * *
> >
> > I. Understanding of the Policy:
> >
> > *Staff Understanding of the Proposal:*
> >
> > Staff understands that this proposal would be implemented in 2 phases.
> > Phase 1 would require the RIRs to return recovered IPv4 legacy address
> > space (via policy or procedure) to the IANA and have the option of
> > returning recovered non-legacy address space to the IANA. Phase 2
> > would
> > start after the depletion of the IANA free pool and would nullify the
> > existing IANA to RIR policy (Global Addressing Policy ASO-001-2). The
> > new IANA to RIR policy would allow each RIR to receive approximately
> > 1/10th of the recovered IPv4 pool from IANA once every 6 months as
> > long
> > as it meets the qualification criteria written in paragraph B2. IANA
> > will be required to keep a log of all returned IPv4 address space and
> > all issued IPv4 address space from the recovered pool, as well as
> > maintain a public registry of the current disposition of all IPv4
> > address space.
> >
> > II. Comments
> >
> > A. ARIN Staff Comments
> >
> > * The one policy that this impacts is NRPM 4.6 Amnesty and
> >  Aggregation, which says "Transactions should only be accepted
> >  under this policy if they are in the interests of the community
> >  (e.g. they improve aggregation or result in a net reclamation of
> >  space)." Because the ARIN region holds the majority of the legacy
> >  address space, and most of the address space returned under this
> >  policy is legacy space, it would mean that there would be no "net
> >  return" of address space to ARIN. ARIN would essentially be
> >  exchanging legacy address space for non-legacy address space, and
> >  returning the legacy address space it received in the exchange to
> >  IANA, resulting in a net loss of address space in ARIN?s available
> >  pool.
> >
> > B. ARIN General Counsel Comments:
> >
> > The current basis of allocation of numbers was established in RFC's
> > 2008
> > and 2050 and is need based. If one region has greater needs than
> > another, the current policy of IANA does not require equal
> > distribution
> > to all RIR's s. This proposed policy would establish a different
> > political and not needs based method for allocating returned space. It
> > would make each RIR an equal recipient of such space. But the level of
> > need and economic activity between each RI R is not equal. This policy
> > will tend to reallocate returned space away from where it is
> > recovered,
> > in the ARIN region , and move more of it to AFRINIC and LACNIC than
> > current distribution principles. By equating the smaller economies and
> > related needs of certain regions to the needs of other regions, like
> > ARIN, that have greater day to day need, it in effect creates a new
> > political order of distribution thru equal shares. It is possible
> > sovereign governments in the regions with greater activity will not
> > agree to such a revised distribution model. The proposed policy
> > undermines the legal rationale for distribution.
> >
> > The policy also creates a powerful disincentive for any RIR, including
> > ARIN, to undertake any financial expenditure of RIR dollars for
> > programs
> > intended to obtain returned space for reallocation. Currently ARIN is
> > working towards policies such as the LRSA and 2008-6, intended to
> > encourage returns and use of under utilized resources, but which cost
> > ARIN expenditures other RIRs are not duplicating. Any policy which
> > creates such a disincentive by leaving expenditures with a single RIR,
> > who cannot benefit except to receive 20% of the returned space
> > should be
> > carefully considered.
> >
> > Finally, it is likely entities with number resources in the ARIN
> > region
> > may be willing to return those resources for uses in the region but
> > unwilling to do so if 4/5 of such resources will be sent to other
> > regions.
> >
> > III. Resource Impact
> >
> > The resource impact of implementing this policy is viewed as
> > minimal. It
> > is estimated that this policy could require up to 3 person months of
> > effort to implement following ratification by the ARIN Board of
> > Trustees. Because this implementation is not planned, it may preempt
> > ARIN?s current project deployment schedule. It may require the follo
> > wing:
> >
> > * Modifications to existing registration procedures to include the
> >  handling of returned/reclaimed address space and the process of
> >  requesting additional address space from the IANA.
> > * Staff training
> >
> > Text assessed:
> >
> > *Allocation of IPv4 Blocks to Regional Internet Registries (Global)*
> >
> > *Policy statement:*
> >
> > This document describes the policy governing the allocation of IPv4
> > address space from the IANA to the Regional Internet Registries
> > (RIRs).
> > This document does not stipulate performance requirements in the
> > provision of services by IANA to an RIR in accordance with this
> > policy.
> > Such requirements should be specified by appropriate agreements among
> > the RIRs and ICANN.
> >
> > This policy is to be implemented in two phases.
> >
> > A. Phase I: Recovery of IPv4 Address Space
> >
> > Upon ratification of this policy by the ICANN Board of Directors the
> > IANA shall establish a mechanism to receive IPv4 address space which
> > is
> > returned to it by the RIRs, and hold that address space in a
> > 'recovered
> > IPv4 pool'.
> >
> > Each RIR through their respective chosen policies and strategies may
> > recover IPv4 address space which is under their administration. At
> > quarterly intervals, each RIR shall return any legacy address space
> > recovered, and may return any non-legacy address space recovered, to
> > the
> > IANA in aggregated blocks of /24 or larger, for inclusion in the
> > recovered IPv4 pool.
> >
> > During Phase I, no allocations will be made from the recovered IPv4
> > pool. Return of recovered address space (as described above) will
> > continue throughout Phase II.
> >
> > B. Phase II: Allocation of Recovered IPv4 address space by the IANA
> >
> > Upon ratification of this policy by the ICANN Board of Directors and a
> > declaration by the IANA that its existing free pool of unallocated
> > IPv4
> > address space is depleted; Global Addressing Policy ASO-001-2 (adopted
> > by ICANN Board 8 April 2005) is rescinded. IANA will then commence to
> > allocate the IPv4 address space from the recovered IPv4 pool.
> >
> > 1. The following definitions apply to this policy:
> >
> > a. Recovered Address Space. Recovered address space is that address
> > space that is returned to an RIR as a result of any activity that
> > seeks
> > to reclaim unused address space or is voluntarily returned to the
> > RIR or
> > is reclaimed by the RIR as a result of legal action or abuse
> > determination. Recovered address space does not include that address
> > space that is reclaimed because of non-payment of contractual fees
> > whose
> > reclamation date is less than 1 year at the time of the report.
> >
> > b. IPv4 Address Holdings. IPv4 address holdings are all unallocated
> > IPv4
> > address space held by an RIR to include recovered address space not
> > yet
> > returned less that address space that is committed in accordance with
> > the RIR's reservation policy and practices.
> >
> > c. Legacy address space. IPv4 address space allocated or assigned
> > prior
> > to the creation of the RIR.
> >
> > 2. Allocation of IPv4 Address Space
> >
> > a. For the purposes of this policy, an 'IPv4 allocation period' is
> > defined as a 6-month period following 1 March or 1 September in each
> > year.
> >
> > b. At the beginning of each IPv4 allocation period, the IANA will
> > determine the 'IPv4 allocation unit' for that period, as 1/10 of its
> > IPv4 address pool, rounded down to the next CIDR (power-of-2)
> > boundary.
> >
> > c. In each allocation period, each RIR may issue one IPv4 request to
> > the
> > IANA. Providing that the RIR satisfies the allocation criteria
> > described
> > in paragraph B.2, the IANA will allocate a single allocation unit,
> > composed of the smallest possible number of blocks available in its
> > IPv4
> > address pool.
> >
> > 3. IPv4 Address Space Allocation Criteria
> >
> > A RIR is eligible to receive additional IPv4 address space from the
> > IANA
> > when the total of its IPv4 address holdings is less than 50% of the
> > current IPv4 allocation unit, and providing that it has not already
> > received an IPv4 allocation from the IANA during the current IPv4
> > allocation period.
> >
> > 4. Initial Allocation of IPv4 Address Space
> >
> > Each new RIR shall, at the moment of recognition, be allocated one (1)
> > allocation unit by the IANA. If an allocation unit is not available,
> > then the IANA will issue this block as soon as one is available. This
> > allocation will be made regardless of the newly formed RIR's projected
> > utilization figures and shall be independent of the IPv4 address space
> > that may have been transferred to the new RIR by the already existing
> > RIRs as part of the formal transition process.
> >
> > 5. Reporting
> >
> > a. All returned space is to be recorded in an IANA-published log of
> > IPv4
> > address space transactions, with each log entry detailing the returned
> > address block, the date of the return, and the returning RIR.
> >
> > b. All allocated space is also to be recorded in this IANA-published
> > log
> > of IPv4 address space transactions, with each log entry detailing the
> > address blocks, the date of the allocation and the recipient RIR.
> >
> > c. The IANA will maintain a public registry of the current disposition
> > of all IPv4 address space, detailing all reservations and current
> > allocations and current IANA-held address space that is unallocated.
> >
> > d) The IANA may make public announcements of IPv4 address block
> > transactions that occur under this policy. The IANA will make
> > appropriate modifications to the "Internet Protocol V4 Address Space"
> > page of the IANA website and may make announcements to its own
> > appropriate announcement lists. The IANA announcements will be limited
> > to which address ranges, the time of allocation and to which Registry
> > they have been allocated.
> >
> >
> >
> >
> >
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> >
> >
> >
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> > rin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> >
> >
> >
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> > ny issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



================================================
=======
David Farmer				     Email:	
farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota			     Phone:	612-626-
0815
2218 University Ave SE			     Cell:		
612-812-9952
Minneapolis, MN 55414-3029		     FAX:	612-626-
1818
================================================
=======



From plzak at arin.net  Mon Mar 30 10:44:32 2009
From: plzak at arin.net (Ray Plzak)
Date: Mon, 30 Mar 2009 10:44:32 -0400
Subject: [arin-ppml] Draft Policy 2009-3 (Global): Allocation of IPv4
 Blocks to Regional Internet Registries
In-Reply-To: <49D0934C.913.D6D7EC7@farmer.umn.edu>
References: <37137.208.54.95.48.1238379940.squirrel@webmail.lacnic.net.uy>,
	<4C1054E8-D5C6-458A-90F7-F00CA7ECCEE7@gmail.com>,
	<FEA070315E40A3489D38398C35FE7BB236401F6416@EDAMAME.arin.net>
	<49D0934C.913.D6D7EC7@farmer.umn.edu>
Message-ID: <FEA070315E40A3489D38398C35FE7BB236401F6430@EDAMAME.arin.net>

A petition would be necessary.

Ray

-----Original Message-----
From: David Farmer [mailto:farmer at umn.edu]
Sent: Monday, March 30, 2009 10:39 AM
To: Ray Plzak
Cc: ARIN-PPML List
Subject: Re: [arin-ppml] Draft Policy 2009-3 (Global): Allocation of IPv4 Blocks to Regional Internet Registries

Ray,

I am probablly missreading something in the PDP, but I'm not
sure how that is possible.  At least without a successful
petition, I believe the only text that can be discussed for
adoption is the Draft Policy created by the AC.

On 30 Mar 2009 Ray Plzak wrote:

> The PDP provides for both proposals to be discussed in the PPM.
>
> Ray
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand
> Sent: Sunday, March 29, 2009 11:41 PM
> To: Raul Echeberria
> Cc: ARIN-PPML List
> Subject: Re: [arin-ppml] Draft Policy 2009-3 (Global): Allocation of IPv4 Blocks to Regional Internet Registries
>
> Raul,
>
> I have no problem discussing the original proposal, but based on the
> PPML discussion to date, and what I've heard in discussions, IMO the
> original unamended proposal has almost no support, and is extremely
> unlikely to gain consensus in the ARIN region.  If anyone favors the
> original proposal, please speak up.
>
> Based on our estimation of the consensus in the ARIN region, the AC
> amended the proposal to give it a better chance of passing, while
> preserving as much of the original proposal as possible. I would
> welcome additional feedback on the balance we attempted to strike,
> either here or in San Antonio.
>
> Thanks,
> Scott
>
> On Mar 29, 2009, at 7:25 PM, raul at lacnic.net wrote:
>
> >
> > Dear all:
> >
> > This proposal is a proposal for a global policy. It means that the
> > same
> > proposal has to be approved in every region. They can be approved with
> > some wording differences, but the spirit of the proposal should be the
> > same.
> >
> > The proposal was the result of a long collaboration effort of senior
> > staff
> > members and board members of all the 5 RIRs and the original text is
> > the
> > one that is being considered in every region.
> >
> > As far as I know the authors of the proposal were not consulted by the
> > ARIN-AC and based on exchanges among the authors in the past few
> > days, I
> > can say that in general the feeling is that the changes introduced
> > by the
> > ARIN-AC are very signficant and so, this is a different proposal.
> >
> > My personal view is that changing the concept of a global policy
> > proposal
> > in one RIR means to avoid the approval of the policy. I strongly
> > encourage
> > ARIN to put the original proposal under consideration of its
> > community as
> > it is being done in the other regions. The proposal can be approved or
> > not, That's part of the process, but it doesn't make sense to
> > approve a
> > different proposal. IMHO, the AC is able to put forward the new
> > proposal
> > for discussion if they consider that it is better, and in that way to
> > start the process of discussion of a new global policy proposal.
> >
> > I have to confess that dealing with 5 different PDPs is not so easy. I
> > don't know if a petition process should be started, If yes, please
> > take
> > this email as the request for initiating that process.
> >
> > Since this announcement was issued last Monday in the afternoon, I
> > am not
> > sure how the business days are counted, but I guess that I am still
> > within
> > the valid period.
> >
> > However, I think that as a practices, global policy proposals should
> > not
> > be changed by any advisory council or policy chair of one region due
> > to
> > the impact that to change the proposal produce in the global process.
> >
> >
> > Best Regards,
> >
> > Ra?l
> >
> >
> >
> > ---------------
> >
> >
> >
> > El 23/03/2009, a las 04:05 p.m., Member Services escribi?:
> >
> > Draft Policy 2009-3 (Global)
> > Allocation of IPv4 Blocks to Regional Internet Registries
> >
> > The following draft policy text is being posted for feedback and
> > discussion on the Public Policy Mailing List (PPML).
> >
> > This draft policy was developed by the ARIN Advisory Council (AC) from
> > Policy Proposal 82: Allocation of IPv4 Blocks to Regional Internet
> > Registries. The AC has taken the proposal and developed it into a
> > draft
> > policy. The AC was required to submit text to ARIN for staff and legal
> > assessment prior to selecting it as a draft policy. The assessment,
> > along with the text that was assessed, is located below the draft
> > policy.
> >
> > On 20 March 2009 the ARIN Advisory Council (AC) selected Draft Policy
> > 2009-3: Allocation of IPv4 Blocks to Regional Internet Registries for
> > adoption discussion on the PPML and at the upcoming Public Policy
> > Meeting.
> >
> > Draft Policy 2009-3 is below and can be found at:
> > https://www.arin.net/policy/proposals/2009_3.html
> >
> > We encourage you to discuss Draft Policy 2009-3 on the PPML prior to
> > the
> > ARIN XXIII Public Policy Meeting. Both the discussion on the PPML
> > and at
> > the Public Policy Meeting will be used by the AC to determine the
> > community consensus regarding adopting this as policy.
> >
> > The ARIN Policy Development Process can be found at:
> > https://www.arin.net/policy/pdp.html
> >
> > All of the Draft Policies under discussion can be found at:
> > https://www.arin.net/policy/proposals/index.html
> >
> > Regards,
> >
> > Member Services
> > American Registry for Internet Numbers (ARIN)
> >
> >
> > ## * ##
> >
> >
> > Draft Policy 2009-3 (Global)
> > Allocation of IPv4 Blocks to Regional Internet Registries
> >
> > Date: 23 March 2009
> >
> > Policy statement:
> >
> > This document describes the policy governing the allocation of IPv4
> > address space from the IANA to the Regional Internet Registries
> > (RIRs).
> > This document does not stipulate performance requirements in the
> > provision of services by IANA to an RIR in accordance with this
> > policy.
> > Such requirements should be specified by appropriate agreements among
> > the RIRs and ICANN.
> >
> > This policy is to be implemented in two phases.
> >
> > A. Phase I: Recovery of IPv4 Address Space
> >
> > Upon ratification of this policy by the ICANN Board of Directors the
> > IANA shall establish a mechanism to receive IPv4 address space which
> > is
> > returned to it by the RIRs, and hold that address space in a
> > 'recovered
> > IPv4 pool'.
> >
> > Each RIR through their respective chosen policies and strategies may
> > recover IPv4 address space which is under their administration. At
> > quarterly intervals, each RIR shall return to the IANA any legacy
> > address space recovered, and may return to the IANA any non-legacy
> > address space recovered, in aggregated blocks of /24 or larger, for
> > inclusion in the recovered IPv4 pool.
> >
> > During Phase I, no allocations will be made from the recovered IPv4
> > pool. Return of recovered address space (as described above) will
> > continue throughout Phase II.
> >
> > B. Phase II: Allocation of Recovered IPv4 address space by the IANA
> >
> > Upon ratification of this policy by the ICANN Board of Directors and a
> > declaration by the IANA that its existing free pool of unallocated
> > IPv4
> > address space is depleted; Global Addressing Policy ASO-001-2 (adopted
> > by ICANN Board 8 April 2005) is rescinded. IANA will then commence to
> > allocate the IPv4 address space from the recovered IPv4 pool.
> >
> > 1. The following definitions apply to this policy:
> >
> > a. Recovered Address Space. Recovered address space is that address
> > space that is returned to an RIR as a result of any activity that
> > seeks
> > to reclaim unused address space or is voluntarily returned to the
> > RIR or
> > is reclaimed by the RIR as a result of legal action or abuse
> > determination. Recovered address space does not include that address
> > space that is reclaimed because of non-payment of contractual fees
> > whose
> > reclamation date is less than 1 year at the time of the report.
> >
> > b. IPv4 Address Holdings. IPv4 address holdings are all unallocated
> > IPv4
> > address space held by an RIR to include recovered address space not
> > yet
> > returned less that address space that is committed in accordance with
> > the RIR's reservation policy and practices.
> >
> > c. Aggregated address blocks. Aggregated address blocks are contiguous
> > prefixes that can be aggregated on natural bit boundaries. 10.0.0.0/24
> > and 10.0.1.0/24 are two contiguous prefixes that can be combined to
> > form
> > an aggregated address block. 10.0.0.0/24 and 10.0.1.0/25 are two
> > contiguous prefixes that cannot be combined on a natural bit
> > boundary to
> > form an aggregated block.
> >
> > d. Legacy address space. IPv4 address space allocated or assigned
> > prior
> > to the creation of the RIR.
> >
> > 2. Allocation of IPv4 Address Space
> >
> > a. For the purposes of this policy, an 'IPv4 allocation period' is
> > defined as a 6-month period following 1 March or 1 September in each
> > year.
> >
> > b. At the beginning of each IPv4 allocation period, the IANA will
> > determine the 'IPv4 allocation unit' for that period, as 1/10 of its
> > IPv4 address pool, rounded down to the next CIDR (power-of-2)
> > boundary.
> > The minimum 'IPv4 allocation unit' size will be a /24.
> >
> > c. In each allocation period, each RIR may issue one IPv4 request to
> > the
> > IANA. Providing that the RIR satisfies the allocation criteria
> > described
> > in paragraph B.2, the IANA will allocate a single allocation unit,
> > composed of the smallest possible number of blocks available in its
> > IPv4
> > address pool.
> >
> > 3. IPv4 Address Space Allocation Criteria
> >
> > A RIR is eligible to receive additional IPv4 address space from the
> > IANA
> > when the total of its IPv4 address holdings is less than 50% of the
> > current IPv4 allocation unit, and providing that it has not already
> > received an IPv4 allocation from the IANA during the current IPv4
> > allocation period.
> >
> > 4. Initial Allocation of IPv4 Address Space
> >
> > Each new RIR shall, at the moment of recognition, be allocated one (1)
> > allocation unit by the IANA. If an allocation unit is not available,
> > then the IANA will issue this block as soon as one is available. This
> > allocation will be made regardless of the newly formed RIR's projected
> > utilization figures and shall be independent of the IPv4 address space
> > that may have been transferred to the new RIR by the already existing
> > RIRs as part of the formal transition process.
> >
> > 5. Reporting
> >
> > a. All returned space is to be recorded in an IANA-published log of
> > IPv4
> > address space transactions, with each log entry detailing the returned
> > address block, the date of the return, and the returning RIR.
> >
> > b. All allocated space is also to be recorded in this IANA-published
> > log
> > of IPv4 address space transactions, with each log entry detailing the
> > address blocks, the date of the allocation and the recipient RIR.
> >
> > c. The IANA will maintain a public registry of the current disposition
> > of all IPv4 address space, detailing all reservations and current
> > allocations and current IANA-held address space that is unallocated.
> >
> > d) The IANA may make public announcements of IPv4 address block
> > transactions that occur under this policy. The IANA will make
> > appropriate modifications to the "Internet Protocol V4 Address Space"
> > page of the IANA website and may make announcements to its own
> > appropriate announcement lists. The IANA announcements will be limited
> > to which address ranges, the time of allocation and to which Registry
> > they have been allocated.
> >
> >
> >
> > #####
> >
> > ARIN Staff Assessment
> >
> > *Title: Allocation of IPv4 Blocks to the Regional Internet Registries*
> >
> > *Proposal Submitted: 30 Jan 2009*
> >
> > *Revision Submitted: 05 March 2009*
> >
> > *Date of Assessment: 10 March 2009*
> >
> > * *
> >
> > I. Understanding of the Policy:
> >
> > *Staff Understanding of the Proposal:*
> >
> > Staff understands that this proposal would be implemented in 2 phases.
> > Phase 1 would require the RIRs to return recovered IPv4 legacy address
> > space (via policy or procedure) to the IANA and have the option of
> > returning recovered non-legacy address space to the IANA. Phase 2
> > would
> > start after the depletion of the IANA free pool and would nullify the
> > existing IANA to RIR policy (Global Addressing Policy ASO-001-2). The
> > new IANA to RIR policy would allow each RIR to receive approximately
> > 1/10th of the recovered IPv4 pool from IANA once every 6 months as
> > long
> > as it meets the qualification criteria written in paragraph B2. IANA
> > will be required to keep a log of all returned IPv4 address space and
> > all issued IPv4 address space from the recovered pool, as well as
> > maintain a public registry of the current disposition of all IPv4
> > address space.
> >
> > II. Comments
> >
> > A. ARIN Staff Comments
> >
> > * The one policy that this impacts is NRPM 4.6 Amnesty and
> >  Aggregation, which says "Transactions should only be accepted
> >  under this policy if they are in the interests of the community
> >  (e.g. they improve aggregation or result in a net reclamation of
> >  space)." Because the ARIN region holds the majority of the legacy
> >  address space, and most of the address space returned under this
> >  policy is legacy space, it would mean that there would be no "net
> >  return" of address space to ARIN. ARIN would essentially be
> >  exchanging legacy address space for non-legacy address space, and
> >  returning the legacy address space it received in the exchange to
> >  IANA, resulting in a net loss of address space in ARIN?s available
> >  pool.
> >
> > B. ARIN General Counsel Comments:
> >
> > The current basis of allocation of numbers was established in RFC's
> > 2008
> > and 2050 and is need based. If one region has greater needs than
> > another, the current policy of IANA does not require equal
> > distribution
> > to all RIR's s. This proposed policy would establish a different
> > political and not needs based method for allocating returned space. It
> > would make each RIR an equal recipient of such space. But the level of
> > need and economic activity between each RI R is not equal. This policy
> > will tend to reallocate returned space away from where it is
> > recovered,
> > in the ARIN region , and move more of it to AFRINIC and LACNIC than
> > current distribution principles. By equating the smaller economies and
> > related needs of certain regions to the needs of other regions, like
> > ARIN, that have greater day to day need, it in effect creates a new
> > political order of distribution thru equal shares. It is possible
> > sovereign governments in the regions with greater activity will not
> > agree to such a revised distribution model. The proposed policy
> > undermines the legal rationale for distribution.
> >
> > The policy also creates a powerful disincentive for any RIR, including
> > ARIN, to undertake any financial expenditure of RIR dollars for
> > programs
> > intended to obtain returned space for reallocation. Currently ARIN is
> > working towards policies such as the LRSA and 2008-6, intended to
> > encourage returns and use of under utilized resources, but which cost
> > ARIN expenditures other RIRs are not duplicating. Any policy which
> > creates such a disincentive by leaving expenditures with a single RIR,
> > who cannot benefit except to receive 20% of the returned space
> > should be
> > carefully considered.
> >
> > Finally, it is likely entities with number resources in the ARIN
> > region
> > may be willing to return those resources for uses in the region but
> > unwilling to do so if 4/5 of such resources will be sent to other
> > regions.
> >
> > III. Resource Impact
> >
> > The resource impact of implementing this policy is viewed as
> > minimal. It
> > is estimated that this policy could require up to 3 person months of
> > effort to implement following ratification by the ARIN Board of
> > Trustees. Because this implementation is not planned, it may preempt
> > ARIN?s current project deployment schedule. It may require the follo
> > wing:
> >
> > * Modifications to existing registration procedures to include the
> >  handling of returned/reclaimed address space and the process of
> >  requesting additional address space from the IANA.
> > * Staff training
> >
> > Text assessed:
> >
> > *Allocation of IPv4 Blocks to Regional Internet Registries (Global)*
> >
> > *Policy statement:*
> >
> > This document describes the policy governing the allocation of IPv4
> > address space from the IANA to the Regional Internet Registries
> > (RIRs).
> > This document does not stipulate performance requirements in the
> > provision of services by IANA to an RIR in accordance with this
> > policy.
> > Such requirements should be specified by appropriate agreements among
> > the RIRs and ICANN.
> >
> > This policy is to be implemented in two phases.
> >
> > A. Phase I: Recovery of IPv4 Address Space
> >
> > Upon ratification of this policy by the ICANN Board of Directors the
> > IANA shall establish a mechanism to receive IPv4 address space which
> > is
> > returned to it by the RIRs, and hold that address space in a
> > 'recovered
> > IPv4 pool'.
> >
> > Each RIR through their respective chosen policies and strategies may
> > recover IPv4 address space which is under their administration. At
> > quarterly intervals, each RIR shall return any legacy address space
> > recovered, and may return any non-legacy address space recovered, to
> > the
> > IANA in aggregated blocks of /24 or larger, for inclusion in the
> > recovered IPv4 pool.
> >
> > During Phase I, no allocations will be made from the recovered IPv4
> > pool. Return of recovered address space (as described above) will
> > continue throughout Phase II.
> >
> > B. Phase II: Allocation of Recovered IPv4 address space by the IANA
> >
> > Upon ratification of this policy by the ICANN Board of Directors and a
> > declaration by the IANA that its existing free pool of unallocated
> > IPv4
> > address space is depleted; Global Addressing Policy ASO-001-2 (adopted
> > by ICANN Board 8 April 2005) is rescinded. IANA will then commence to
> > allocate the IPv4 address space from the recovered IPv4 pool.
> >
> > 1. The following definitions apply to this policy:
> >
> > a. Recovered Address Space. Recovered address space is that address
> > space that is returned to an RIR as a result of any activity that
> > seeks
> > to reclaim unused address space or is voluntarily returned to the
> > RIR or
> > is reclaimed by the RIR as a result of legal action or abuse
> > determination. Recovered address space does not include that address
> > space that is reclaimed because of non-payment of contractual fees
> > whose
> > reclamation date is less than 1 year at the time of the report.
> >
> > b. IPv4 Address Holdings. IPv4 address holdings are all unallocated
> > IPv4
> > address space held by an RIR to include recovered address space not
> > yet
> > returned less that address space that is committed in accordance with
> > the RIR's reservation policy and practices.
> >
> > c. Legacy address space. IPv4 address space allocated or assigned
> > prior
> > to the creation of the RIR.
> >
> > 2. Allocation of IPv4 Address Space
> >
> > a. For the purposes of this policy, an 'IPv4 allocation period' is
> > defined as a 6-month period following 1 March or 1 September in each
> > year.
> >
> > b. At the beginning of each IPv4 allocation period, the IANA will
> > determine the 'IPv4 allocation unit' for that period, as 1/10 of its
> > IPv4 address pool, rounded down to the next CIDR (power-of-2)
> > boundary.
> >
> > c. In each allocation period, each RIR may issue one IPv4 request to
> > the
> > IANA. Providing that the RIR satisfies the allocation criteria
> > described
> > in paragraph B.2, the IANA will allocate a single allocation unit,
> > composed of the smallest possible number of blocks available in its
> > IPv4
> > address pool.
> >
> > 3. IPv4 Address Space Allocation Criteria
> >
> > A RIR is eligible to receive additional IPv4 address space from the
> > IANA
> > when the total of its IPv4 address holdings is less than 50% of the
> > current IPv4 allocation unit, and providing that it has not already
> > received an IPv4 allocation from the IANA during the current IPv4
> > allocation period.
> >
> > 4. Initial Allocation of IPv4 Address Space
> >
> > Each new RIR shall, at the moment of recognition, be allocated one (1)
> > allocation unit by the IANA. If an allocation unit is not available,
> > then the IANA will issue this block as soon as one is available. This
> > allocation will be made regardless of the newly formed RIR's projected
> > utilization figures and shall be independent of the IPv4 address space
> > that may have been transferred to the new RIR by the already existing
> > RIRs as part of the formal transition process.
> >
> > 5. Reporting
> >
> > a. All returned space is to be recorded in an IANA-published log of
> > IPv4
> > address space transactions, with each log entry detailing the returned
> > address block, the date of the return, and the returning RIR.
> >
> > b. All allocated space is also to be recorded in this IANA-published
> > log
> > of IPv4 address space transactions, with each log entry detailing the
> > address blocks, the date of the allocation and the recipient RIR.
> >
> > c. The IANA will maintain a public registry of the current disposition
> > of all IPv4 address space, detailing all reservations and current
> > allocations and current IANA-held address space that is unallocated.
> >
> > d) The IANA may make public announcements of IPv4 address block
> > transactions that occur under this policy. The IANA will make
> > appropriate modifications to the "Internet Protocol V4 Address Space"
> > page of the IANA website and may make announcements to its own
> > appropriate announcement lists. The IANA announcements will be limited
> > to which address ranges, the time of allocation and to which Registry
> > they have been allocated.
> >
> >
> >
> >
> >
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> >
> >
> >
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> > rin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> >
> >
> >
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> > ny issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



================================================
=======
David Farmer                                 Email:
farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota                      Phone:     612-626-
0815
2218 University Ave SE                       Cell:
612-812-9952
Minneapolis, MN 55414-3029                   FAX:       612-626-
1818
================================================
=======




From BillD at cait.wustl.edu  Mon Mar 30 10:53:36 2009
From: BillD at cait.wustl.edu (Bill Darte)
Date: Mon, 30 Mar 2009 09:53:36 -0500
Subject: [arin-ppml] Draft Policy 2009-3 (Global): Allocation of IPv4
	Blocks to Regional Internet Registries
In-Reply-To: <FEA070315E40A3489D38398C35FE7BB236401F6430@EDAMAME.arin.net>
References: <37137.208.54.95.48.1238379940.squirrel@webmail.lacnic.net.uy>,
	<4C1054E8-D5C6-458A-90F7-F00CA7ECCEE7@gmail.com>,
	<FEA070315E40A3489D38398C35FE7BB236401F6416@EDAMAME.arin.net><49D0934C.913.D6D7EC7@farmer.umn.edu>
	<FEA070315E40A3489D38398C35FE7BB236401F6430@EDAMAME.arin.net>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D030878AB289@ex1.cait.wustl.edu>

Or, the AC version could be discussed for adoption, but the original proposal text could be presented for contrast of course.

bs

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ray Plzak
> Sent: Monday, March 30, 2009 9:45 AM
> To: David Farmer
> Cc: ARIN-PPML List
> Subject: Re: [arin-ppml] Draft Policy 2009-3 (Global): 
> Allocation of IPv4 Blocks to Regional Internet Registries
> 
> A petition would be necessary.
> 
> Ray
> 
> -----Original Message-----
> From: David Farmer [mailto:farmer at umn.edu]
> Sent: Monday, March 30, 2009 10:39 AM
> To: Ray Plzak
> Cc: ARIN-PPML List
> Subject: Re: [arin-ppml] Draft Policy 2009-3 (Global): 
> Allocation of IPv4 Blocks to Regional Internet Registries
> 
> Ray,
> 
> I am probablly missreading something in the PDP, but I'm not 
> sure how that is possible.  At least without a successful 
> petition, I believe the only text that can be discussed for 
> adoption is the Draft Policy created by the AC.
> 
> On 30 Mar 2009 Ray Plzak wrote:
> 
> > The PDP provides for both proposals to be discussed in the PPM.
> >
> > Ray
> >
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] 
> > On Behalf Of Scott Leibrand
> > Sent: Sunday, March 29, 2009 11:41 PM
> > To: Raul Echeberria
> > Cc: ARIN-PPML List
> > Subject: Re: [arin-ppml] Draft Policy 2009-3 (Global): 
> Allocation of 
> > IPv4 Blocks to Regional Internet Registries
> >
> > Raul,
> >
> > I have no problem discussing the original proposal, but 
> based on the 
> > PPML discussion to date, and what I've heard in 
> discussions, IMO the 
> > original unamended proposal has almost no support, and is extremely 
> > unlikely to gain consensus in the ARIN region.  If anyone 
> favors the 
> > original proposal, please speak up.
> >
> > Based on our estimation of the consensus in the ARIN region, the AC 
> > amended the proposal to give it a better chance of passing, while 
> > preserving as much of the original proposal as possible. I would 
> > welcome additional feedback on the balance we attempted to strike, 
> > either here or in San Antonio.
> >
> > Thanks,
> > Scott
> >
> > On Mar 29, 2009, at 7:25 PM, raul at lacnic.net wrote:
> >
> > >
> > > Dear all:
> > >
> > > This proposal is a proposal for a global policy. It means 
> that the 
> > > same proposal has to be approved in every region. They can be 
> > > approved with some wording differences, but the spirit of the 
> > > proposal should be the same.
> > >
> > > The proposal was the result of a long collaboration 
> effort of senior 
> > > staff members and board members of all the 5 RIRs and the 
> original 
> > > text is the one that is being considered in every region.
> > >
> > > As far as I know the authors of the proposal were not 
> consulted by 
> > > the ARIN-AC and based on exchanges among the authors in 
> the past few 
> > > days, I can say that in general the feeling is that the changes 
> > > introduced by the ARIN-AC are very signficant and so, this is a 
> > > different proposal.
> > >
> > > My personal view is that changing the concept of a global policy 
> > > proposal in one RIR means to avoid the approval of the policy. I 
> > > strongly encourage ARIN to put the original proposal under 
> > > consideration of its community as it is being done in the other 
> > > regions. The proposal can be approved or not, That's part of the 
> > > process, but it doesn't make sense to approve a different 
> proposal. 
> > > IMHO, the AC is able to put forward the new proposal for 
> discussion 
> > > if they consider that it is better, and in that way to start the 
> > > process of discussion of a new global policy proposal.
> > >
> > > I have to confess that dealing with 5 different PDPs is 
> not so easy. 
> > > I don't know if a petition process should be started, If 
> yes, please 
> > > take this email as the request for initiating that process.
> > >
> > > Since this announcement was issued last Monday in the 
> afternoon, I 
> > > am not sure how the business days are counted, but I 
> guess that I am 
> > > still within the valid period.
> > >
> > > However, I think that as a practices, global policy 
> proposals should 
> > > not be changed by any advisory council or policy chair of 
> one region 
> > > due to the impact that to change the proposal produce in 
> the global 
> > > process.
> > >
> > >
> > > Best Regards,
> > >
> > > Ra?l
> > >
> > >
> > >
> > > ---------------
> > >
> > >
> > >
> > > El 23/03/2009, a las 04:05 p.m., Member Services escribi?:
> > >
> > > Draft Policy 2009-3 (Global)
> > > Allocation of IPv4 Blocks to Regional Internet Registries
> > >
> > > The following draft policy text is being posted for feedback and 
> > > discussion on the Public Policy Mailing List (PPML).
> > >
> > > This draft policy was developed by the ARIN Advisory Council (AC) 
> > > from Policy Proposal 82: Allocation of IPv4 Blocks to Regional 
> > > Internet Registries. The AC has taken the proposal and 
> developed it 
> > > into a draft policy. The AC was required to submit text 
> to ARIN for 
> > > staff and legal assessment prior to selecting it as a 
> draft policy. 
> > > The assessment, along with the text that was assessed, is located 
> > > below the draft policy.
> > >
> > > On 20 March 2009 the ARIN Advisory Council (AC) selected Draft 
> > > Policy
> > > 2009-3: Allocation of IPv4 Blocks to Regional Internet Registries 
> > > for adoption discussion on the PPML and at the upcoming Public 
> > > Policy Meeting.
> > >
> > > Draft Policy 2009-3 is below and can be found at:
> > > https://www.arin.net/policy/proposals/2009_3.html
> > >
> > > We encourage you to discuss Draft Policy 2009-3 on the 
> PPML prior to 
> > > the ARIN XXIII Public Policy Meeting. Both the discussion on the 
> > > PPML and at the Public Policy Meeting will be used by the AC to 
> > > determine the community consensus regarding adopting this 
> as policy.
> > >
> > > The ARIN Policy Development Process can be found at:
> > > https://www.arin.net/policy/pdp.html
> > >
> > > All of the Draft Policies under discussion can be found at:
> > > https://www.arin.net/policy/proposals/index.html
> > >
> > > Regards,
> > >
> > > Member Services
> > > American Registry for Internet Numbers (ARIN)
> > >
> > >
> > > ## * ##
> > >
> > >
> > > Draft Policy 2009-3 (Global)
> > > Allocation of IPv4 Blocks to Regional Internet Registries
> > >
> > > Date: 23 March 2009
> > >
> > > Policy statement:
> > >
> > > This document describes the policy governing the 
> allocation of IPv4 
> > > address space from the IANA to the Regional Internet Registries 
> > > (RIRs).
> > > This document does not stipulate performance requirements in the 
> > > provision of services by IANA to an RIR in accordance with this 
> > > policy.
> > > Such requirements should be specified by appropriate agreements 
> > > among the RIRs and ICANN.
> > >
> > > This policy is to be implemented in two phases.
> > >
> > > A. Phase I: Recovery of IPv4 Address Space
> > >
> > > Upon ratification of this policy by the ICANN Board of 
> Directors the 
> > > IANA shall establish a mechanism to receive IPv4 address 
> space which 
> > > is returned to it by the RIRs, and hold that address space in a 
> > > 'recovered
> > > IPv4 pool'.
> > >
> > > Each RIR through their respective chosen policies and 
> strategies may 
> > > recover IPv4 address space which is under their 
> administration. At 
> > > quarterly intervals, each RIR shall return to the IANA any legacy 
> > > address space recovered, and may return to the IANA any 
> non-legacy 
> > > address space recovered, in aggregated blocks of /24 or 
> larger, for 
> > > inclusion in the recovered IPv4 pool.
> > >
> > > During Phase I, no allocations will be made from the 
> recovered IPv4 
> > > pool. Return of recovered address space (as described above) will 
> > > continue throughout Phase II.
> > >
> > > B. Phase II: Allocation of Recovered IPv4 address space 
> by the IANA
> > >
> > > Upon ratification of this policy by the ICANN Board of 
> Directors and 
> > > a declaration by the IANA that its existing free pool of 
> unallocated
> > > IPv4
> > > address space is depleted; Global Addressing Policy ASO-001-2 
> > > (adopted by ICANN Board 8 April 2005) is rescinded. IANA 
> will then 
> > > commence to allocate the IPv4 address space from the 
> recovered IPv4 pool.
> > >
> > > 1. The following definitions apply to this policy:
> > >
> > > a. Recovered Address Space. Recovered address space is 
> that address 
> > > space that is returned to an RIR as a result of any activity that 
> > > seeks to reclaim unused address space or is voluntarily 
> returned to 
> > > the RIR or is reclaimed by the RIR as a result of legal action or 
> > > abuse determination. Recovered address space does not 
> include that 
> > > address space that is reclaimed because of non-payment of 
> > > contractual fees whose reclamation date is less than 1 
> year at the 
> > > time of the report.
> > >
> > > b. IPv4 Address Holdings. IPv4 address holdings are all 
> unallocated
> > > IPv4
> > > address space held by an RIR to include recovered address 
> space not 
> > > yet returned less that address space that is committed in 
> accordance 
> > > with the RIR's reservation policy and practices.
> > >
> > > c. Aggregated address blocks. Aggregated address blocks are 
> > > contiguous prefixes that can be aggregated on natural bit 
> > > boundaries. 10.0.0.0/24 and 10.0.1.0/24 are two 
> contiguous prefixes 
> > > that can be combined to form an aggregated address block. 
> > > 10.0.0.0/24 and 10.0.1.0/25 are two contiguous prefixes 
> that cannot 
> > > be combined on a natural bit boundary to form an aggregated block.
> > >
> > > d. Legacy address space. IPv4 address space allocated or assigned 
> > > prior to the creation of the RIR.
> > >
> > > 2. Allocation of IPv4 Address Space
> > >
> > > a. For the purposes of this policy, an 'IPv4 allocation 
> period' is 
> > > defined as a 6-month period following 1 March or 1 
> September in each 
> > > year.
> > >
> > > b. At the beginning of each IPv4 allocation period, the IANA will 
> > > determine the 'IPv4 allocation unit' for that period, as 
> 1/10 of its
> > > IPv4 address pool, rounded down to the next CIDR (power-of-2) 
> > > boundary.
> > > The minimum 'IPv4 allocation unit' size will be a /24.
> > >
> > > c. In each allocation period, each RIR may issue one IPv4 
> request to 
> > > the IANA. Providing that the RIR satisfies the allocation 
> criteria 
> > > described in paragraph B.2, the IANA will allocate a single 
> > > allocation unit, composed of the smallest possible number 
> of blocks 
> > > available in its
> > > IPv4
> > > address pool.
> > >
> > > 3. IPv4 Address Space Allocation Criteria
> > >
> > > A RIR is eligible to receive additional IPv4 address 
> space from the 
> > > IANA when the total of its IPv4 address holdings is less 
> than 50% of 
> > > the current IPv4 allocation unit, and providing that it has not 
> > > already received an IPv4 allocation from the IANA during 
> the current 
> > > IPv4 allocation period.
> > >
> > > 4. Initial Allocation of IPv4 Address Space
> > >
> > > Each new RIR shall, at the moment of recognition, be 
> allocated one 
> > > (1) allocation unit by the IANA. If an allocation unit is not 
> > > available, then the IANA will issue this block as soon as one is 
> > > available. This allocation will be made regardless of the newly 
> > > formed RIR's projected utilization figures and shall be 
> independent 
> > > of the IPv4 address space that may have been transferred 
> to the new 
> > > RIR by the already existing RIRs as part of the formal 
> transition process.
> > >
> > > 5. Reporting
> > >
> > > a. All returned space is to be recorded in an 
> IANA-published log of
> > > IPv4
> > > address space transactions, with each log entry detailing the 
> > > returned address block, the date of the return, and the 
> returning RIR.
> > >
> > > b. All allocated space is also to be recorded in this 
> IANA-published 
> > > log of IPv4 address space transactions, with each log entry 
> > > detailing the address blocks, the date of the allocation and the 
> > > recipient RIR.
> > >
> > > c. The IANA will maintain a public registry of the current 
> > > disposition of all IPv4 address space, detailing all reservations 
> > > and current allocations and current IANA-held address 
> space that is unallocated.
> > >
> > > d) The IANA may make public announcements of IPv4 address block 
> > > transactions that occur under this policy. The IANA will make 
> > > appropriate modifications to the "Internet Protocol V4 
> Address Space"
> > > page of the IANA website and may make announcements to its own 
> > > appropriate announcement lists. The IANA announcements will be 
> > > limited to which address ranges, the time of allocation 
> and to which 
> > > Registry they have been allocated.
> > >
> > >
> > >
> > > #####
> > >
> > > ARIN Staff Assessment
> > >
> > > *Title: Allocation of IPv4 Blocks to the Regional Internet 
> > > Registries*
> > >
> > > *Proposal Submitted: 30 Jan 2009*
> > >
> > > *Revision Submitted: 05 March 2009*
> > >
> > > *Date of Assessment: 10 March 2009*
> > >
> > > * *
> > >
> > > I. Understanding of the Policy:
> > >
> > > *Staff Understanding of the Proposal:*
> > >
> > > Staff understands that this proposal would be implemented 
> in 2 phases.
> > > Phase 1 would require the RIRs to return recovered IPv4 legacy 
> > > address space (via policy or procedure) to the IANA and have the 
> > > option of returning recovered non-legacy address space to 
> the IANA. 
> > > Phase 2 would start after the depletion of the IANA free pool and 
> > > would nullify the existing IANA to RIR policy (Global Addressing 
> > > Policy ASO-001-2). The new IANA to RIR policy would allow 
> each RIR 
> > > to receive approximately 1/10th of the recovered IPv4 
> pool from IANA 
> > > once every 6 months as long as it meets the qualification 
> criteria 
> > > written in paragraph B2. IANA will be required to keep a 
> log of all 
> > > returned IPv4 address space and all issued IPv4 address 
> space from 
> > > the recovered pool, as well as maintain a public registry of the 
> > > current disposition of all IPv4 address space.
> > >
> > > II. Comments
> > >
> > > A. ARIN Staff Comments
> > >
> > > * The one policy that this impacts is NRPM 4.6 Amnesty and  
> > > Aggregation, which says "Transactions should only be 
> accepted  under 
> > > this policy if they are in the interests of the community  (e.g. 
> > > they improve aggregation or result in a net reclamation 
> of  space)." 
> > > Because the ARIN region holds the majority of the legacy  address 
> > > space, and most of the address space returned under this  
> policy is 
> > > legacy space, it would mean that there would be no "net  
> return" of 
> > > address space to ARIN. ARIN would essentially be  
> exchanging legacy 
> > > address space for non-legacy address space, and  returning the 
> > > legacy address space it received in the exchange to  
> IANA, resulting 
> > > in a net loss of address space in ARIN?s available  pool.
> > >
> > > B. ARIN General Counsel Comments:
> > >
> > > The current basis of allocation of numbers was 
> established in RFC's
> > > 2008
> > > and 2050 and is need based. If one region has greater needs than 
> > > another, the current policy of IANA does not require equal 
> > > distribution to all RIR's s. This proposed policy would 
> establish a 
> > > different political and not needs based method for allocating 
> > > returned space. It would make each RIR an equal recipient of such 
> > > space. But the level of need and economic activity 
> between each RI R 
> > > is not equal. This policy will tend to reallocate returned space 
> > > away from where it is recovered, in the ARIN region , and 
> move more 
> > > of it to AFRINIC and LACNIC than current distribution 
> principles. By 
> > > equating the smaller economies and related needs of 
> certain regions 
> > > to the needs of other regions, like ARIN, that have 
> greater day to 
> > > day need, it in effect creates a new political order of 
> distribution 
> > > thru equal shares. It is possible sovereign governments in the 
> > > regions with greater activity will not agree to such a revised 
> > > distribution model. The proposed policy undermines the legal 
> > > rationale for distribution.
> > >
> > > The policy also creates a powerful disincentive for any RIR, 
> > > including ARIN, to undertake any financial expenditure of RIR 
> > > dollars for programs intended to obtain returned space for 
> > > reallocation. Currently ARIN is working towards policies 
> such as the 
> > > LRSA and 2008-6, intended to encourage returns and use of under 
> > > utilized resources, but which cost ARIN expenditures 
> other RIRs are 
> > > not duplicating. Any policy which creates such a disincentive by 
> > > leaving expenditures with a single RIR, who cannot 
> benefit except to 
> > > receive 20% of the returned space should be carefully considered.
> > >
> > > Finally, it is likely entities with number resources in the ARIN 
> > > region may be willing to return those resources for uses in the 
> > > region but unwilling to do so if 4/5 of such resources 
> will be sent 
> > > to other regions.
> > >
> > > III. Resource Impact
> > >
> > > The resource impact of implementing this policy is viewed as 
> > > minimal. It is estimated that this policy could require up to 3 
> > > person months of effort to implement following 
> ratification by the 
> > > ARIN Board of Trustees. Because this implementation is 
> not planned, 
> > > it may preempt ARIN?s current project deployment schedule. It may 
> > > require the follo
> > > wing:
> > >
> > > * Modifications to existing registration procedures to 
> include the  
> > > handling of returned/reclaimed address space and the process of  
> > > requesting additional address space from the IANA.
> > > * Staff training
> > >
> > > Text assessed:
> > >
> > > *Allocation of IPv4 Blocks to Regional Internet 
> Registries (Global)*
> > >
> > > *Policy statement:*
> > >
> > > This document describes the policy governing the 
> allocation of IPv4 
> > > address space from the IANA to the Regional Internet Registries 
> > > (RIRs).
> > > This document does not stipulate performance requirements in the 
> > > provision of services by IANA to an RIR in accordance with this 
> > > policy.
> > > Such requirements should be specified by appropriate agreements 
> > > among the RIRs and ICANN.
> > >
> > > This policy is to be implemented in two phases.
> > >
> > > A. Phase I: Recovery of IPv4 Address Space
> > >
> > > Upon ratification of this policy by the ICANN Board of 
> Directors the 
> > > IANA shall establish a mechanism to receive IPv4 address 
> space which 
> > > is returned to it by the RIRs, and hold that address space in a 
> > > 'recovered
> > > IPv4 pool'.
> > >
> > > Each RIR through their respective chosen policies and 
> strategies may 
> > > recover IPv4 address space which is under their 
> administration. At 
> > > quarterly intervals, each RIR shall return any legacy 
> address space 
> > > recovered, and may return any non-legacy address space 
> recovered, to 
> > > the IANA in aggregated blocks of /24 or larger, for 
> inclusion in the 
> > > recovered IPv4 pool.
> > >
> > > During Phase I, no allocations will be made from the 
> recovered IPv4 
> > > pool. Return of recovered address space (as described above) will 
> > > continue throughout Phase II.
> > >
> > > B. Phase II: Allocation of Recovered IPv4 address space 
> by the IANA
> > >
> > > Upon ratification of this policy by the ICANN Board of 
> Directors and 
> > > a declaration by the IANA that its existing free pool of 
> unallocated
> > > IPv4
> > > address space is depleted; Global Addressing Policy ASO-001-2 
> > > (adopted by ICANN Board 8 April 2005) is rescinded. IANA 
> will then 
> > > commence to allocate the IPv4 address space from the 
> recovered IPv4 pool.
> > >
> > > 1. The following definitions apply to this policy:
> > >
> > > a. Recovered Address Space. Recovered address space is 
> that address 
> > > space that is returned to an RIR as a result of any activity that 
> > > seeks to reclaim unused address space or is voluntarily 
> returned to 
> > > the RIR or is reclaimed by the RIR as a result of legal action or 
> > > abuse determination. Recovered address space does not 
> include that 
> > > address space that is reclaimed because of non-payment of 
> > > contractual fees whose reclamation date is less than 1 
> year at the 
> > > time of the report.
> > >
> > > b. IPv4 Address Holdings. IPv4 address holdings are all 
> unallocated
> > > IPv4
> > > address space held by an RIR to include recovered address 
> space not 
> > > yet returned less that address space that is committed in 
> accordance 
> > > with the RIR's reservation policy and practices.
> > >
> > > c. Legacy address space. IPv4 address space allocated or assigned 
> > > prior to the creation of the RIR.
> > >
> > > 2. Allocation of IPv4 Address Space
> > >
> > > a. For the purposes of this policy, an 'IPv4 allocation 
> period' is 
> > > defined as a 6-month period following 1 March or 1 
> September in each 
> > > year.
> > >
> > > b. At the beginning of each IPv4 allocation period, the IANA will 
> > > determine the 'IPv4 allocation unit' for that period, as 
> 1/10 of its
> > > IPv4 address pool, rounded down to the next CIDR (power-of-2) 
> > > boundary.
> > >
> > > c. In each allocation period, each RIR may issue one IPv4 
> request to 
> > > the IANA. Providing that the RIR satisfies the allocation 
> criteria 
> > > described in paragraph B.2, the IANA will allocate a single 
> > > allocation unit, composed of the smallest possible number 
> of blocks 
> > > available in its
> > > IPv4
> > > address pool.
> > >
> > > 3. IPv4 Address Space Allocation Criteria
> > >
> > > A RIR is eligible to receive additional IPv4 address 
> space from the 
> > > IANA when the total of its IPv4 address holdings is less 
> than 50% of 
> > > the current IPv4 allocation unit, and providing that it has not 
> > > already received an IPv4 allocation from the IANA during 
> the current 
> > > IPv4 allocation period.
> > >
> > > 4. Initial Allocation of IPv4 Address Space
> > >
> > > Each new RIR shall, at the moment of recognition, be 
> allocated one 
> > > (1) allocation unit by the IANA. If an allocation unit is not 
> > > available, then the IANA will issue this block as soon as one is 
> > > available. This allocation will be made regardless of the newly 
> > > formed RIR's projected utilization figures and shall be 
> independent 
> > > of the IPv4 address space that may have been transferred 
> to the new 
> > > RIR by the already existing RIRs as part of the formal 
> transition process.
> > >
> > > 5. Reporting
> > >
> > > a. All returned space is to be recorded in an 
> IANA-published log of
> > > IPv4
> > > address space transactions, with each log entry detailing the 
> > > returned address block, the date of the return, and the 
> returning RIR.
> > >
> > > b. All allocated space is also to be recorded in this 
> IANA-published 
> > > log of IPv4 address space transactions, with each log entry 
> > > detailing the address blocks, the date of the allocation and the 
> > > recipient RIR.
> > >
> > > c. The IANA will maintain a public registry of the current 
> > > disposition of all IPv4 address space, detailing all reservations 
> > > and current allocations and current IANA-held address 
> space that is unallocated.
> > >
> > > d) The IANA may make public announcements of IPv4 address block 
> > > transactions that occur under this policy. The IANA will make 
> > > appropriate modifications to the "Internet Protocol V4 
> Address Space"
> > > page of the IANA website and may make announcements to its own 
> > > appropriate announcement lists. The IANA announcements will be 
> > > limited to which address ranges, the time of allocation 
> and to which 
> > > Registry they have been allocated.
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > PPML
> > > You are receiving this message because you are subscribed to the 
> > > ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > > Unsubscribe or manage your mailing list subscription at:
> > > http://lists.arin.net/mailman/listinfo/arin-ppml
> > > Please contact info at arin.net if you experience any issues.
> > >
> > >
> > >
> > > _______________________________________________
> > > PPML
> > > You are receiving this message because you are subscribed to the 
> > > ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > > Unsubscribe or manage your mailing list subscription at:
> > > http://lists.arin.net/mailman/listinfo/arin-ppml
> > > Please contact info at arin.net if you experience any issues.
> > > rin.net/mailman/listinfo/arin-ppml
> > > Please contact info at arin.net if you experience any issues.
> > >
> > >
> > >
> > > _______________________________________________
> > > PPML
> > > You are receiving this message because you are subscribed to the 
> > > ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > > Unsubscribe or manage your mailing list subscription at:
> > > http://lists.arin.net/mailman/listinfo/arin-ppml
> > > Please contact info at arin.net if you experience any issues.
> > > ny issues.
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed 
> to the ARIN 
> > Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed 
> to the ARIN 
> > Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> 
> 
> 
> ================================================
> =======
> David Farmer                                 Email:
> farmer at umn.edu
> Office of Information Technology
> Networking & Telecomunication Services
> University of Minnesota                      Phone:     612-626-
> 0815
> 2218 University Ave SE                       Cell:
> 612-812-9952
> Minneapolis, MN 55414-3029                   FAX:       612-626-
> 1818
> ================================================
> =======
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 


From michael.dillon at bt.com  Mon Mar 30 10:56:29 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 30 Mar 2009 15:56:29 +0100
Subject: [arin-ppml] How hard is it to transition to IPv6?
In-Reply-To: <49D0D3EA.40603@zcorum.com>
Message-ID: <28E139F46D45AF49A31950F88C49745859CD17@E03MVZ2-UKDY.domain1.systemhost.net>


>     I didn't get to reply to this earlier and only do so now 
> to make sure I am communicating clearly.  

You're not! Communication begins with listening and understanding.

> but I do feel very 
> strongly that the industry in general ignores the smaller 
> providers and I took your comments as continuing that 
> cavalier approach.

This is a gross misunderstanding on your part and you still
don't seem to get it. You have it 180 degrees backwards.

> > That is an ad hominem attack and is not allowed on the ARIN
> > policy discussion lists. You should be ashamed of yourself.
> >   
> Err, what?  This wasn't an attack of any sort and was much 
> cooler than 
> the initial reply I typed.  Perhaps the word negligent 
> doesn't mean the 
> same thing to you as it does to me, but that has an extremely 
> negative 
> connotation IMO.  When you use strong wording you will get a strong 
> response.

Making incorrect and innaccurate claims about a company's postion
is negligent. Just because a person happens to work for company X 
does not mean that a person's comments are the position of 
company X. I sign my name on all my posts to make it clear that
the message is MY OPINION. Reverse engineering mail headers and
making incorrect and unwarranted statements on the basis of a
domain name found there, is negligent to you. It just makes you
look stupid.

> > And read my email again, carefully this time. In effect, I told
> > the customers of all ISPs, not just one ISP, that they SHOULD
> > complain about their ISP supplier's negligence if that ISP 
> > supplier does not provide satisfactory timelines for IPv6 support.

> We are, have been, and will continue to do so but again the largest 
> challenges that ISPs face are the pieces that end users directly 
> control.  What I was trying to get across, and apparently 
> failing, was 
> that the Google example is not particularly applicable to ISPs, 
> especially small and medium ones.

Weasely words. It's still not clear to me that you get it.
I suggested that folks complain to suppliers and you called
me on the carpet for getting folks to complain to their customers
which is 180 degrees opposite from what I said.

And I so have many years of experienc in small business so I
know the resource constraints people are up against. But I also
know that small businesses have greater flexibility in changing
direction and moving quickly to sieze an opportunity. I remember
when I visited an ISP in a town of 80,000 in the mountains of
British Columbia and they showed me how they had built their own
terminal servers on Linux boxes with some 16-port serial cards.
They have a young college guy there who was hacking the Linux drivers
to make it do what they needed.

Moaning won't solve your problems. Tell vendors what you need
and if they won't give it to you, SWITCH VENDORS or build your
own. As a small company you have better chances of success by 
switching or building your own. Stop complaining about policies
and ARIN and the government and big companies because none of
that helps you to be ready for IPv6.

If you don't want to manage your company through the IPv6 transition
then either shut it down or sell it. There is no way to prevent
that transition from happening in the next couple of years.

--Michael Dillon





From farmer at umn.edu  Mon Mar 30 11:00:29 2009
From: farmer at umn.edu (David Farmer)
Date: Mon, 30 Mar 2009 10:00:29 -0500
Subject: [arin-ppml] Draft Policy 2009-3 (Global): Allocation of IPv4
	Blocks to Regional Internet Registries
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D030878AB289@ex1.cait.wustl.edu>
References: <37137.208.54.95.48.1238379940.squirrel@webmail.lacnic.net.uy>,
	<FEA070315E40A3489D38398C35FE7BB236401F6430@EDAMAME.arin.net>,
	<EACF8B735E9CBA4B8BAF9E4165D030878AB289@ex1.cait.wustl.edu>
Message-ID: <49D0983D.20757.D80CBB2@farmer.umn.edu>

On 30 Mar 2009 Bill Darte wrote:

> Or, the AC version could be discussed for adoption, but the original
> proposal text could be presented for contrast of course. 

I agree, but I don't think that is what Raul was requesting.

> bs
> 
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net 
> > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ray Plzak
> > Sent: Monday, March 30, 2009 9:45 AM
> > To: David Farmer
> > Cc: ARIN-PPML List
> > Subject: Re: [arin-ppml] Draft Policy 2009-3 (Global): 
> > Allocation of IPv4 Blocks to Regional Internet Registries
> > 
> > A petition would be necessary.
> > 
> > Ray
> > 
> > -----Original Message-----
> > From: David Farmer [mailto:farmer at umn.edu]
> > Sent: Monday, March 30, 2009 10:39 AM
> > To: Ray Plzak
> > Cc: ARIN-PPML List
> > Subject: Re: [arin-ppml] Draft Policy 2009-3 (Global): 
> > Allocation of IPv4 Blocks to Regional Internet Registries
> > 
> > Ray,
> > 
> > I am probablly missreading something in the PDP, but I'm not 
> > sure how that is possible.  At least without a successful 
> > petition, I believe the only text that can be discussed for 
> > adoption is the Draft Policy created by the AC.
> > 
> > On 30 Mar 2009 Ray Plzak wrote:
> > 
> > > The PDP provides for both proposals to be discussed in the PPM.
> > >
> > > Ray
> > >
> > > -----Original Message-----
> > > From: arin-ppml-bounces at arin.net 
> > [mailto:arin-ppml-bounces at arin.net] 
> > > On Behalf Of Scott Leibrand
> > > Sent: Sunday, March 29, 2009 11:41 PM
> > > To: Raul Echeberria
> > > Cc: ARIN-PPML List
> > > Subject: Re: [arin-ppml] Draft Policy 2009-3 (Global): 
> > Allocation of 
> > > IPv4 Blocks to Regional Internet Registries
> > >
> > > Raul,
> > >
> > > I have no problem discussing the original proposal, but 
> > based on the 
> > > PPML discussion to date, and what I've heard in 
> > discussions, IMO the 
> > > original unamended proposal has almost no support, and is extremely 
> > > unlikely to gain consensus in the ARIN region.  If anyone 
> > favors the 
> > > original proposal, please speak up.
> > >
> > > Based on our estimation of the consensus in the ARIN region, the AC 
> > > amended the proposal to give it a better chance of passing, while 
> > > preserving as much of the original proposal as possible. I would 
> > > welcome additional feedback on the balance we attempted to strike, 
> > > either here or in San Antonio.
> > >
> > > Thanks,
> > > Scott
> > >
> > > On Mar 29, 2009, at 7:25 PM, raul at lacnic.net wrote:
> > >
> > > >
> > > > Dear all:
> > > >
> > > > This proposal is a proposal for a global policy. It means 
> > that the 
> > > > same proposal has to be approved in every region. They can be 
> > > > approved with some wording differences, but the spirit of the 
> > > > proposal should be the same.
> > > >
> > > > The proposal was the result of a long collaboration 
> > effort of senior 
> > > > staff members and board members of all the 5 RIRs and the 
> > original 
> > > > text is the one that is being considered in every region.
> > > >
> > > > As far as I know the authors of the proposal were not 
> > consulted by 
> > > > the ARIN-AC and based on exchanges among the authors in 
> > the past few 
> > > > days, I can say that in general the feeling is that the changes 
> > > > introduced by the ARIN-AC are very signficant and so, this is a 
> > > > different proposal.
> > > >
> > > > My personal view is that changing the concept of a global policy 
> > > > proposal in one RIR means to avoid the approval of the policy. I 
> > > > strongly encourage ARIN to put the original proposal under 
> > > > consideration of its community as it is being done in the other 
> > > > regions. The proposal can be approved or not, That's part of the 
> > > > process, but it doesn't make sense to approve a different 
> > proposal. 
> > > > IMHO, the AC is able to put forward the new proposal for 
> > discussion 
> > > > if they consider that it is better, and in that way to start the 
> > > > process of discussion of a new global policy proposal.
> > > >
> > > > I have to confess that dealing with 5 different PDPs is 
> > not so easy. 
> > > > I don't know if a petition process should be started, If 
> > yes, please 
> > > > take this email as the request for initiating that process.
> > > >
> > > > Since this announcement was issued last Monday in the 
> > afternoon, I 
> > > > am not sure how the business days are counted, but I 
> > guess that I am 
> > > > still within the valid period.
> > > >
> > > > However, I think that as a practices, global policy 
> > proposals should 
> > > > not be changed by any advisory council or policy chair of 
> > one region 
> > > > due to the impact that to change the proposal produce in 
> > the global 
> > > > process.
> > > >
> > > >
> > > > Best Regards,
> > > >
> > > > Ra?l
> > > >
> > > >
> > > >
> > > > ---------------
> > > >
> > > >
> > > >
> > > > El 23/03/2009, a las 04:05 p.m., Member Services escribi?:
> > > >
> > > > Draft Policy 2009-3 (Global)
> > > > Allocation of IPv4 Blocks to Regional Internet Registries
> > > >
> > > > The following draft policy text is being posted for feedback and 
> > > > discussion on the Public Policy Mailing List (PPML).
> > > >
> > > > This draft policy was developed by the ARIN Advisory Council (AC) 
> > > > from Policy Proposal 82: Allocation of IPv4 Blocks to Regional 
> > > > Internet Registries. The AC has taken the proposal and 
> > developed it 
> > > > into a draft policy. The AC was required to submit text 
> > to ARIN for 
> > > > staff and legal assessment prior to selecting it as a 
> > draft policy. 
> > > > The assessment, along with the text that was assessed, is located 
> > > > below the draft policy.
> > > >
> > > > On 20 March 2009 the ARIN Advisory Council (AC) selected Draft 
> > > > Policy
> > > > 2009-3: Allocation of IPv4 Blocks to Regional Internet Registries 
> > > > for adoption discussion on the PPML and at the upcoming Public 
> > > > Policy Meeting.
> > > >
> > > > Draft Policy 2009-3 is below and can be found at:
> > > > https://www.arin.net/policy/proposals/2009_3.html
> > > >
> > > > We encourage you to discuss Draft Policy 2009-3 on the 
> > PPML prior to 
> > > > the ARIN XXIII Public Policy Meeting. Both the discussion on the 
> > > > PPML and at the Public Policy Meeting will be used by the AC to 
> > > > determine the community consensus regarding adopting this 
> > as policy.
> > > >
> > > > The ARIN Policy Development Process can be found at:
> > > > https://www.arin.net/policy/pdp.html
> > > >
> > > > All of the Draft Policies under discussion can be found at:
> > > > https://www.arin.net/policy/proposals/index.html
> > > >
> > > > Regards,
> > > >
> > > > Member Services
> > > > American Registry for Internet Numbers (ARIN)
> > > >
> > > >
> > > > ## * ##
> > > >
> > > >
> > > > Draft Policy 2009-3 (Global)
> > > > Allocation of IPv4 Blocks to Regional Internet Registries
> > > >
> > > > Date: 23 March 2009
> > > >
> > > > Policy statement:
> > > >
> > > > This document describes the policy governing the 
> > allocation of IPv4 
> > > > address space from the IANA to the Regional Internet Registries 
> > > > (RIRs).
> > > > This document does not stipulate performance requirements in the 
> > > > provision of services by IANA to an RIR in accordance with this 
> > > > policy.
> > > > Such requirements should be specified by appropriate agreements 
> > > > among the RIRs and ICANN.
> > > >
> > > > This policy is to be implemented in two phases.
> > > >
> > > > A. Phase I: Recovery of IPv4 Address Space
> > > >
> > > > Upon ratification of this policy by the ICANN Board of 
> > Directors the 
> > > > IANA shall establish a mechanism to receive IPv4 address 
> > space which 
> > > > is returned to it by the RIRs, and hold that address space in a 
> > > > 'recovered
> > > > IPv4 pool'.
> > > >
> > > > Each RIR through their respective chosen policies and 
> > strategies may 
> > > > recover IPv4 address space which is under their 
> > administration. At 
> > > > quarterly intervals, each RIR shall return to the IANA any legacy 
> > > > address space recovered, and may return to the IANA any 
> > non-legacy 
> > > > address space recovered, in aggregated blocks of /24 or 
> > larger, for 
> > > > inclusion in the recovered IPv4 pool.
> > > >
> > > > During Phase I, no allocations will be made from the 
> > recovered IPv4 
> > > > pool. Return of recovered address space (as described above) will 
> > > > continue throughout Phase II.
> > > >
> > > > B. Phase II: Allocation of Recovered IPv4 address space 
> > by the IANA
> > > >
> > > > Upon ratification of this policy by the ICANN Board of 
> > Directors and 
> > > > a declaration by the IANA that its existing free pool of 
> > unallocated
> > > > IPv4
> > > > address space is depleted; Global Addressing Policy ASO-001-2 
> > > > (adopted by ICANN Board 8 April 2005) is rescinded. IANA 
> > will then 
> > > > commence to allocate the IPv4 address space from the 
> > recovered IPv4 pool.
> > > >
> > > > 1. The following definitions apply to this policy:
> > > >
> > > > a. Recovered Address Space. Recovered address space is 
> > that address 
> > > > space that is returned to an RIR as a result of any activity that 
> > > > seeks to reclaim unused address space or is voluntarily 
> > returned to 
> > > > the RIR or is reclaimed by the RIR as a result of legal action or 
> > > > abuse determination. Recovered address space does not 
> > include that 
> > > > address space that is reclaimed because of non-payment of 
> > > > contractual fees whose reclamation date is less than 1 
> > year at the 
> > > > time of the report.
> > > >
> > > > b. IPv4 Address Holdings. IPv4 address holdings are all 
> > unallocated
> > > > IPv4
> > > > address space held by an RIR to include recovered address 
> > space not 
> > > > yet returned less that address space that is committed in 
> > accordance 
> > > > with the RIR's reservation policy and practices.
> > > >
> > > > c. Aggregated address blocks. Aggregated address blocks are 
> > > > contiguous prefixes that can be aggregated on natural bit 
> > > > boundaries. 10.0.0.0/24 and 10.0.1.0/24 are two 
> > contiguous prefixes 
> > > > that can be combined to form an aggregated address block. 
> > > > 10.0.0.0/24 and 10.0.1.0/25 are two contiguous prefixes 
> > that cannot 
> > > > be combined on a natural bit boundary to form an aggregated block.
> > > >
> > > > d. Legacy address space. IPv4 address space allocated or assigned 
> > > > prior to the creation of the RIR.
> > > >
> > > > 2. Allocation of IPv4 Address Space
> > > >
> > > > a. For the purposes of this policy, an 'IPv4 allocation 
> > period' is 
> > > > defined as a 6-month period following 1 March or 1 
> > September in each 
> > > > year.
> > > >
> > > > b. At the beginning of each IPv4 allocation period, the IANA will 
> > > > determine the 'IPv4 allocation unit' for that period, as 
> > 1/10 of its
> > > > IPv4 address pool, rounded down to the next CIDR (power-of-2) 
> > > > boundary.
> > > > The minimum 'IPv4 allocation unit' size will be a /24.
> > > >
> > > > c. In each allocation period, each RIR may issue one IPv4 
> > request to 
> > > > the IANA. Providing that the RIR satisfies the allocation 
> > criteria 
> > > > described in paragraph B.2, the IANA will allocate a single 
> > > > allocation unit, composed of the smallest possible number 
> > of blocks 
> > > > available in its
> > > > IPv4
> > > > address pool.
> > > >
> > > > 3. IPv4 Address Space Allocation Criteria
> > > >
> > > > A RIR is eligible to receive additional IPv4 address 
> > space from the 
> > > > IANA when the total of its IPv4 address holdings is less 
> > than 50% of 
> > > > the current IPv4 allocation unit, and providing that it has not 
> > > > already received an IPv4 allocation from the IANA during 
> > the current 
> > > > IPv4 allocation period.
> > > >
> > > > 4. Initial Allocation of IPv4 Address Space
> > > >
> > > > Each new RIR shall, at the moment of recognition, be 
> > allocated one 
> > > > (1) allocation unit by the IANA. If an allocation unit is not 
> > > > available, then the IANA will issue this block as soon as one is 
> > > > available. This allocation will be made regardless of the newly 
> > > > formed RIR's projected utilization figures and shall be 
> > independent 
> > > > of the IPv4 address space that may have been transferred 
> > to the new 
> > > > RIR by the already existing RIRs as part of the formal 
> > transition process.
> > > >
> > > > 5. Reporting
> > > >
> > > > a. All returned space is to be recorded in an 
> > IANA-published log of
> > > > IPv4
> > > > address space transactions, with each log entry detailing the 
> > > > returned address block, the date of the return, and the 
> > returning RIR.
> > > >
> > > > b. All allocated space is also to be recorded in this 
> > IANA-published 
> > > > log of IPv4 address space transactions, with each log entry 
> > > > detailing the address blocks, the date of the allocation and the 
> > > > recipient RIR.
> > > >
> > > > c. The IANA will maintain a public registry of the current 
> > > > disposition of all IPv4 address space, detailing all reservations 
> > > > and current allocations and current IANA-held address 
> > space that is unallocated.
> > > >
> > > > d) The IANA may make public announcements of IPv4 address block 
> > > > transactions that occur under this policy. The IANA will make 
> > > > appropriate modifications to the "Internet Protocol V4 
> > Address Space"
> > > > page of the IANA website and may make announcements to its own 
> > > > appropriate announcement lists. The IANA announcements will be 
> > > > limited to which address ranges, the time of allocation 
> > and to which 
> > > > Registry they have been allocated.
> > > >
> > > >
> > > >
> > > > #####
> > > >
> > > > ARIN Staff Assessment
> > > >
> > > > *Title: Allocation of IPv4 Blocks to the Regional Internet 
> > > > Registries*
> > > >
> > > > *Proposal Submitted: 30 Jan 2009*
> > > >
> > > > *Revision Submitted: 05 March 2009*
> > > >
> > > > *Date of Assessment: 10 March 2009*
> > > >
> > > > * *
> > > >
> > > > I. Understanding of the Policy:
> > > >
> > > > *Staff Understanding of the Proposal:*
> > > >
> > > > Staff understands that this proposal would be implemented 
> > in 2 phases.
> > > > Phase 1 would require the RIRs to return recovered IPv4 legacy 
> > > > address space (via policy or procedure) to the IANA and have the 
> > > > option of returning recovered non-legacy address space to 
> > the IANA. 
> > > > Phase 2 would start after the depletion of the IANA free pool and 
> > > > would nullify the existing IANA to RIR policy (Global Addressing 
> > > > Policy ASO-001-2). The new IANA to RIR policy would allow 
> > each RIR 
> > > > to receive approximately 1/10th of the recovered IPv4 
> > pool from IANA 
> > > > once every 6 months as long as it meets the qualification 
> > criteria 
> > > > written in paragraph B2. IANA will be required to keep a 
> > log of all 
> > > > returned IPv4 address space and all issued IPv4 address 
> > space from 
> > > > the recovered pool, as well as maintain a public registry of the 
> > > > current disposition of all IPv4 address space.
> > > >
> > > > II. Comments
> > > >
> > > > A. ARIN Staff Comments
> > > >
> > > > * The one policy that this impacts is NRPM 4.6 Amnesty and  
> > > > Aggregation, which says "Transactions should only be 
> > accepted  under 
> > > > this policy if they are in the interests of the community  (e.g. 
> > > > they improve aggregation or result in a net reclamation 
> > of  space)." 
> > > > Because the ARIN region holds the majority of the legacy  address 
> > > > space, and most of the address space returned under this  
> > policy is 
> > > > legacy space, it would mean that there would be no "net  
> > return" of 
> > > > address space to ARIN. ARIN would essentially be  
> > exchanging legacy 
> > > > address space for non-legacy address space, and  returning the 
> > > > legacy address space it received in the exchange to  
> > IANA, resulting 
> > > > in a net loss of address space in ARIN?s available  pool.
> > > >
> > > > B. ARIN General Counsel Comments:
> > > >
> > > > The current basis of allocation of numbers was 
> > established in RFC's
> > > > 2008
> > > > and 2050 and is need based. If one region has greater needs than 
> > > > another, the current policy of IANA does not require equal 
> > > > distribution to all RIR's s. This proposed policy would 
> > establish a 
> > > > different political and not needs based method for allocating 
> > > > returned space. It would make each RIR an equal recipient of such 
> > > > space. But the level of need and economic activity 
> > between each RI R 
> > > > is not equal. This policy will tend to reallocate returned space 
> > > > away from where it is recovered, in the ARIN region , and 
> > move more 
> > > > of it to AFRINIC and LACNIC than current distribution 
> > principles. By 
> > > > equating the smaller economies and related needs of 
> > certain regions 
> > > > to the needs of other regions, like ARIN, that have 
> > greater day to 
> > > > day need, it in effect creates a new political order of 
> > distribution 
> > > > thru equal shares. It is possible sovereign governments in the 
> > > > regions with greater activity will not agree to such a revised 
> > > > distribution model. The proposed policy undermines the legal 
> > > > rationale for distribution.
> > > >
> > > > The policy also creates a powerful disincentive for any RIR, 
> > > > including ARIN, to undertake any financial expenditure of RIR 
> > > > dollars for programs intended to obtain returned space for 
> > > > reallocation. Currently ARIN is working towards policies 
> > such as the 
> > > > LRSA and 2008-6, intended to encourage returns and use of under 
> > > > utilized resources, but which cost ARIN expenditures 
> > other RIRs are 
> > > > not duplicating. Any policy which creates such a disincentive by 
> > > > leaving expenditures with a single RIR, who cannot 
> > benefit except to 
> > > > receive 20% of the returned space should be carefully considered.
> > > >
> > > > Finally, it is likely entities with number resources in the ARIN 
> > > > region may be willing to return those resources for uses in the 
> > > > region but unwilling to do so if 4/5 of such resources 
> > will be sent 
> > > > to other regions.
> > > >
> > > > III. Resource Impact
> > > >
> > > > The resource impact of implementing this policy is viewed as 
> > > > minimal. It is estimated that this policy could require up to 3 
> > > > person months of effort to implement following 
> > ratification by the 
> > > > ARIN Board of Trustees. Because this implementation is 
> > not planned, 
> > > > it may preempt ARIN?s current project deployment schedule. It may 
> > > > require the follo
> > > > wing:
> > > >
> > > > * Modifications to existing registration procedures to 
> > include the  
> > > > handling of returned/reclaimed address space and the process of  
> > > > requesting additional address space from the IANA.
> > > > * Staff training
> > > >
> > > > Text assessed:
> > > >
> > > > *Allocation of IPv4 Blocks to Regional Internet 
> > Registries (Global)*
> > > >
> > > > *Policy statement:*
> > > >
> > > > This document describes the policy governing the 
> > allocation of IPv4 
> > > > address space from the IANA to the Regional Internet Registries 
> > > > (RIRs).
> > > > This document does not stipulate performance requirements in the 
> > > > provision of services by IANA to an RIR in accordance with this 
> > > > policy.
> > > > Such requirements should be specified by appropriate agreements 
> > > > among the RIRs and ICANN.
> > > >
> > > > This policy is to be implemented in two phases.
> > > >
> > > > A. Phase I: Recovery of IPv4 Address Space
> > > >
> > > > Upon ratification of this policy by the ICANN Board of 
> > Directors the 
> > > > IANA shall establish a mechanism to receive IPv4 address 
> > space which 
> > > > is returned to it by the RIRs, and hold that address space in a 
> > > > 'recovered
> > > > IPv4 pool'.
> > > >
> > > > Each RIR through their respective chosen policies and 
> > strategies may 
> > > > recover IPv4 address space which is under their 
> > administration. At 
> > > > quarterly intervals, each RIR shall return any legacy 
> > address space 
> > > > recovered, and may return any non-legacy address space 
> > recovered, to 
> > > > the IANA in aggregated blocks of /24 or larger, for 
> > inclusion in the 
> > > > recovered IPv4 pool.
> > > >
> > > > During Phase I, no allocations will be made from the 
> > recovered IPv4 
> > > > pool. Return of recovered address space (as described above) will 
> > > > continue throughout Phase II.
> > > >
> > > > B. Phase II: Allocation of Recovered IPv4 address space 
> > by the IANA
> > > >
> > > > Upon ratification of this policy by the ICANN Board of 
> > Directors and 
> > > > a declaration by the IANA that its existing free pool of 
> > unallocated
> > > > IPv4
> > > > address space is depleted; Global Addressing Policy ASO-001-2 
> > > > (adopted by ICANN Board 8 April 2005) is rescinded. IANA 
> > will then 
> > > > commence to allocate the IPv4 address space from the 
> > recovered IPv4 pool.
> > > >
> > > > 1. The following definitions apply to this policy:
> > > >
> > > > a. Recovered Address Space. Recovered address space is 
> > that address 
> > > > space that is returned to an RIR as a result of any activity that 
> > > > seeks to reclaim unused address space or is voluntarily 
> > returned to 
> > > > the RIR or is reclaimed by the RIR as a result of legal action or 
> > > > abuse determination. Recovered address space does not 
> > include that 
> > > > address space that is reclaimed because of non-payment of 
> > > > contractual fees whose reclamation date is less than 1 
> > year at the 
> > > > time of the report.
> > > >
> > > > b. IPv4 Address Holdings. IPv4 address holdings are all 
> > unallocated
> > > > IPv4
> > > > address space held by an RIR to include recovered address 
> > space not 
> > > > yet returned less that address space that is committed in 
> > accordance 
> > > > with the RIR's reservation policy and practices.
> > > >
> > > > c. Legacy address space. IPv4 address space allocated or assigned 
> > > > prior to the creation of the RIR.
> > > >
> > > > 2. Allocation of IPv4 Address Space
> > > >
> > > > a. For the purposes of this policy, an 'IPv4 allocation 
> > period' is 
> > > > defined as a 6-month period following 1 March or 1 
> > September in each 
> > > > year.
> > > >
> > > > b. At the beginning of each IPv4 allocation period, the IANA will 
> > > > determine the 'IPv4 allocation unit' for that period, as 
> > 1/10 of its
> > > > IPv4 address pool, rounded down to the next CIDR (power-of-2) 
> > > > boundary.
> > > >
> > > > c. In each allocation period, each RIR may issue one IPv4 
> > request to 
> > > > the IANA. Providing that the RIR satisfies the allocation 
> > criteria 
> > > > described in paragraph B.2, the IANA will allocate a single 
> > > > allocation unit, composed of the smallest possible number 
> > of blocks 
> > > > available in its
> > > > IPv4
> > > > address pool.
> > > >
> > > > 3. IPv4 Address Space Allocation Criteria
> > > >
> > > > A RIR is eligible to receive additional IPv4 address 
> > space from the 
> > > > IANA when the total of its IPv4 address holdings is less 
> > than 50% of 
> > > > the current IPv4 allocation unit, and providing that it has not 
> > > > already received an IPv4 allocation from the IANA during 
> > the current 
> > > > IPv4 allocation period.
> > > >
> > > > 4. Initial Allocation of IPv4 Address Space
> > > >
> > > > Each new RIR shall, at the moment of recognition, be 
> > allocated one 
> > > > (1) allocation unit by the IANA. If an allocation unit is not 
> > > > available, then the IANA will issue this block as soon as one is 
> > > > available. This allocation will be made regardless of the newly 
> > > > formed RIR's projected utilization figures and shall be 
> > independent 
> > > > of the IPv4 address space that may have been transferred 
> > to the new 
> > > > RIR by the already existing RIRs as part of the formal 
> > transition process.
> > > >
> > > > 5. Reporting
> > > >
> > > > a. All returned space is to be recorded in an 
> > IANA-published log of
> > > > IPv4
> > > > address space transactions, with each log entry detailing the 
> > > > returned address block, the date of the return, and the 
> > returning RIR.
> > > >
> > > > b. All allocated space is also to be recorded in this 
> > IANA-published 
> > > > log of IPv4 address space transactions, with each log entry 
> > > > detailing the address blocks, the date of the allocation and the 
> > > > recipient RIR.
> > > >
> > > > c. The IANA will maintain a public registry of the current 
> > > > disposition of all IPv4 address space, detailing all reservations 
> > > > and current allocations and current IANA-held address 
> > space that is unallocated.
> > > >
> > > > d) The IANA may make public announcements of IPv4 address block 
> > > > transactions that occur under this policy. The IANA will make 
> > > > appropriate modifications to the "Internet Protocol V4 
> > Address Space"
> > > > page of the IANA website and may make announcements to its own 
> > > > appropriate announcement lists. The IANA announcements will be 
> > > > limited to which address ranges, the time of allocation 
> > and to which 
> > > > Registry they have been allocated.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > PPML
> > > > You are receiving this message because you are subscribed to the 
> > > > ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > > > Unsubscribe or manage your mailing list subscription at:
> > > > http://lists.arin.net/mailman/listinfo/arin-ppml
> > > > Please contact info at arin.net if you experience any issues.
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > PPML
> > > > You are receiving this message because you are subscribed to the 
> > > > ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > > > Unsubscribe or manage your mailing list subscription at:
> > > > http://lists.arin.net/mailman/listinfo/arin-ppml
> > > > Please contact info at arin.net if you experience any issues.
> > > > rin.net/mailman/listinfo/arin-ppml
> > > > Please contact info at arin.net if you experience any issues.
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > PPML
> > > > You are receiving this message because you are subscribed to the 
> > > > ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > > > Unsubscribe or manage your mailing list subscription at:
> > > > http://lists.arin.net/mailman/listinfo/arin-ppml
> > > > Please contact info at arin.net if you experience any issues.
> > > > ny issues.
> > > _______________________________________________
> > > PPML
> > > You are receiving this message because you are subscribed 
> > to the ARIN 
> > > Public Policy Mailing List (ARIN-PPML at arin.net).
> > > Unsubscribe or manage your mailing list subscription at:
> > > http://lists.arin.net/mailman/listinfo/arin-ppml
> > > Please contact info at arin.net if you experience any issues.
> > > _______________________________________________
> > > PPML
> > > You are receiving this message because you are subscribed 
> > to the ARIN 
> > > Public Policy Mailing List (ARIN-PPML at arin.net).
> > > Unsubscribe or manage your mailing list subscription at:
> > > http://lists.arin.net/mailman/listinfo/arin-ppml
> > > Please contact info at arin.net if you experience any issues.
> > 
> > 
> > 
> > ================================================
> > =======
> > David Farmer                                 Email:
> > farmer at umn.edu
> > Office of Information Technology
> > Networking & Telecomunication Services
> > University of Minnesota                      Phone:     612-626-
> > 0815
> > 2218 University Ave SE                       Cell:
> > 612-812-9952
> > Minneapolis, MN 55414-3029                   FAX:       612-626-
> > 1818
> > ================================================
> > =======
> > 
> > 
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to 
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> > 



================================================
=======
David Farmer				     Email:	
farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota			     Phone:	612-626-
0815
2218 University Ave SE			     Cell:		
612-812-9952
Minneapolis, MN 55414-3029		     FAX:	612-626-
1818
================================================
=======



From khelms at zcorum.com  Mon Mar 30 11:12:36 2009
From: khelms at zcorum.com (Scott Helms)
Date: Mon, 30 Mar 2009 11:12:36 -0400
Subject: [arin-ppml] How hard is it to transition to IPv6?
In-Reply-To: <28E139F46D45AF49A31950F88C49745859CD17@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C49745859CD17@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <49D0E164.7000102@zcorum.com>

Michael,

    I'll reply directly to avoid further side tracking of the list, 
since we continue to talk past each other.

michael.dillon at bt.com wrote:
>>     I didn't get to reply to this earlier and only do so now 
>> to make sure I am communicating clearly.  
>>     
>
> You're not! Communication begins with listening and understanding.
>
>   
>> but I do feel very 
>> strongly that the industry in general ignores the smaller 
>> providers and I took your comments as continuing that 
>> cavalier approach.
>>     
>
> This is a gross misunderstanding on your part and you still
> don't seem to get it. You have it 180 degrees backwards.
>
>   
>>> That is an ad hominem attack and is not allowed on the ARIN
>>> policy discussion lists. You should be ashamed of yourself.
>>>   
>>>       
>> Err, what?  This wasn't an attack of any sort and was much 
>> cooler than 
>> the initial reply I typed.  Perhaps the word negligent 
>> doesn't mean the 
>> same thing to you as it does to me, but that has an extremely 
>> negative 
>> connotation IMO.  When you use strong wording you will get a strong 
>> response.
>>     
>
> Making incorrect and innaccurate claims about a company's postion
> is negligent. Just because a person happens to work for company X 
> does not mean that a person's comments are the position of 
> company X. I sign my name on all my posts to make it clear that
> the message is MY OPINION. Reverse engineering mail headers and
> making incorrect and unwarranted statements on the basis of a
> domain name found there, is negligent to you. It just makes you
> look stupid.
>
>   
>>> And read my email again, carefully this time. In effect, I told
>>> the customers of all ISPs, not just one ISP, that they SHOULD
>>> complain about their ISP supplier's negligence if that ISP 
>>> supplier does not provide satisfactory timelines for IPv6 support.
>>>       
>
>   
>> We are, have been, and will continue to do so but again the largest 
>> challenges that ISPs face are the pieces that end users directly 
>> control.  What I was trying to get across, and apparently 
>> failing, was 
>> that the Google example is not particularly applicable to ISPs, 
>> especially small and medium ones.
>>     
>
> Weasely words. It's still not clear to me that you get it.
> I suggested that folks complain to suppliers and you called
> me on the carpet for getting folks to complain to their customers
> which is 180 degrees opposite from what I said.
>
> And I so have many years of experienc in small business so I
> know the resource constraints people are up against. But I also
> know that small businesses have greater flexibility in changing
> direction and moving quickly to sieze an opportunity. I remember
> when I visited an ISP in a town of 80,000 in the mountains of
> British Columbia and they showed me how they had built their own
> terminal servers on Linux boxes with some 16-port serial cards.
> They have a young college guy there who was hacking the Linux drivers
> to make it do what they needed.
>
> Moaning won't solve your problems. Tell vendors what you need
> and if they won't give it to you, SWITCH VENDORS or build your
> own. As a small company you have better chances of success by 
> switching or building your own. Stop complaining about policies
> and ARIN and the government and big companies because none of
> that helps you to be ready for IPv6.
>
> If you don't want to manage your company through the IPv6 transition
> then either shut it down or sell it. There is no way to prevent
> that transition from happening in the next couple of years.
>
> --Michael Dillon
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
>
>   


-- 
Scott Helms
Vice President of Technology
ISP Alliance, Inc. DBA ZCorum
(678) 507-5000



From mksmith at adhost.com  Mon Mar 30 11:35:13 2009
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Mon, 30 Mar 2009 08:35:13 -0700
Subject: [arin-ppml] Draft Policy 2009-1: Is there an Emergency?
In-Reply-To: <49D01AE3.21085.B9720F6@farmer.umn.edu>
References: <49D01AE3.21085.B9720F6@farmer.umn.edu>
Message-ID: <17838240D9A5544AAA5FF95F8D52031605B42C67@ad-exh01.adhost.lan>

Hello Everyone:

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of David Farmer
Sent: Sunday, March 29, 2009 11:06 PM
To: arin-ppml at arin.net
Subject: [arin-ppml] Draft Policy 2009-1: Is there an Emergency?

I would like to motivate a discussion of the question "Is there 
an Emergency?"

--------------------------
[Michael K. Smith - Adhost] 

I think v4 run-out will become an emergency, but we're not there yet.
The Board's decision to invoke their emergency powers for something that
may (but I agree, likely) will happen in the future seems a bit like
preemptive CPR. 

Regards,

Mike


From spiffnolee at yahoo.com  Mon Mar 30 12:07:03 2009
From: spiffnolee at yahoo.com (Lee Howard)
Date: Mon, 30 Mar 2009 09:07:03 -0700 (PDT)
Subject: [arin-ppml] clarification of Board actions Feb 2 and Mar 18, 2009
Message-ID: <376189.27706.qm@web63303.mail.re1.yahoo.com>



The community has requested clarification from the Board on
the series of events and motivations that led to the emergency draft proposal
2009-1: Transfer Policy.

At its February 6, 2009 meeting,  the Board accepted the recommendation of the
Advisory Council, finding that the process had been followed, and adopted
policy proposal 2008-6: Emergency Transfer Policy for IPv4 Addresses.  The 
Board has been concerned for some time that the lack of a liberalized transfer 
policy would create legal risk: that we had not provided a mechanism to improve 
the efficient utilization of previously-allocated resources, and that this risk was 
significant enough to jeopardize ARIN?s ability to fulfill its stewardship mission.

The sense of the Board is that a transfer policy is needed well before IANA?s 
last IPv4 allocation, to allow early transfers and ease the demand for IPv4 
numbers from ARIN.  Allowing for the possibility that demand might increase 
as IANA allocates its last IPv4 numbers, the Board believes that there is 
insufficient time for another full policy cycle.  The policy in 2008-6 allowed 
the Board to activate it by declaring an emergency, which the Board did.
The policy had certain gaps which, in the Board?s opinion, allowed for 
exploitation.  As noted in the minutes of the February 6 meeting, the Board 
resolved to make certain edits to the policy that  had just been adopted.  
These edits were out of order: according to ARIN?s Policy Development 
Process, the Board of Trustees may (in emergency circumstances) suspend 
a policy or propose a policy, but may not edit the Number Resource Policy
Manual directly.  Therefore, at its March 18, 2009 meeting, the Board 
rescinded its action editing the policy, and proposed a new policy, which is 
2009-1: Transfer Policy.  The minutes of that meeting will be published once 
Board members have reviewed them, according to the published procedure.


The
discussion of Draft Policy  2009-1: Transfer Policy has provided
valuable 
input to the Board of Trustees.   The Board notes that this draft policy
includes substantial
changes to current policy, and encourages constructive 
discussion of the
draft policy as written.

Lee Howard
ARIN Secretary, but speaking without Board resolution


      



From martin.hannigan at batelnet.bs  Mon Mar 30 12:24:12 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Mon, 30 Mar 2009 12:24:12 -0400
Subject: [arin-ppml] Draft Policy 2009-3 (Global): Allocation of IPv4
	Blocks to Regional Internet Registries
In-Reply-To: <49D0983D.20757.D80CBB2@farmer.umn.edu>
References: <37137.208.54.95.48.1238379940.squirrel@webmail.lacnic.net.uy>
	<FEA070315E40A3489D38398C35FE7BB236401F6430@EDAMAME.arin.net>
	<EACF8B735E9CBA4B8BAF9E4165D030878AB289@ex1.cait.wustl.edu>
	<49D0983D.20757.D80CBB2@farmer.umn.edu>
Message-ID: <4607e1d50903300924g52329a6ftf556a810551f4101@mail.gmail.com>

On Mon, Mar 30, 2009 at 11:00 AM, David Farmer <farmer at umn.edu> wrote:

> On 30 Mar 2009 Bill Darte wrote:
>
> > Or, the AC version could be discussed for adoption, but the original
> > proposal text could be presented for contrast of course.
>
> I agree, but I don't think that is what Raul was requesting.
>
>
Whatever is being requested must be within AC's purview as provided for in
the ARIN PDP.  The PDP seems to indicate that the AC can modify "any"
proposal that comes before it. The policy proposal presentation doesn't have
to be limited, but considering that a) the summaries, community followup,
the revised proposal, and the result of that public activity, and b) the
potential to introduce irrelevant and confusing information, I would be in
favor of _not_ presenting the original version of the proposal since it is
technically "dead". Isn't it?

All considered, I don't think negotiating the option to pull the trigger on
the petition process is what PPML is for. If they authors intend to do it,
they should go ahead and use that tool.


Best Regards,

-M<
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090330/a5b5c5bb/attachment.htm>

From kkargel at polartel.com  Mon Mar 30 12:30:52 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 30 Mar 2009 11:30:52 -0500
Subject: [arin-ppml] clarification of Board actions Feb 2 and Mar 18,
	2009
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AF47@mail>
References: <376189.27706.qm@web63303.mail.re1.yahoo.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4AF47@mail>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AF48@mail>

> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> > Behalf Of Lee Howard
> > Sent: Monday, March 30, 2009 11:07 AM
> > To: ppml at arin.net
> > Subject: [arin-ppml] clarification of Board actions Feb 2 and Mar 18,
> 2009
> >
> >
> >
> > The community has requested clarification from the Board on
> > the series of events and motivations that led to the emergency draft
> > proposal
> > 2009-1: Transfer Policy.
> >
> > At its February 6, 2009 meeting,  the Board accepted the recommendation
> of
> > the
> > Advisory Council, finding that the process had been followed, and
> adopted
> > policy proposal 2008-6: Emergency Transfer Policy for IPv4 Addresses.
> The
> > Board has been concerned for some time that the lack of a liberalized
> > transfer
> > policy would create legal risk: that we had not provided a mechanism to
> > improve
> > the efficient utilization of previously-allocated resources, and that
> this
> > risk was
> > significant enough to jeopardize ARIN's ability to fulfill its
> stewardship
> > mission.
> >
> 
 Could someone please explain to me what legal risk there is from ARIN
 continuing to fulfill it's mission without creating an IP market?  
 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090330/27deadd6/attachment.bin>

From bill at herrin.us  Mon Mar 30 13:20:58 2009
From: bill at herrin.us (William Herrin)
Date: Mon, 30 Mar 2009 13:20:58 -0400
Subject: [arin-ppml] clarification of Board actions Feb 2 and Mar 18,
	2009
In-Reply-To: <376189.27706.qm@web63303.mail.re1.yahoo.com>
References: <376189.27706.qm@web63303.mail.re1.yahoo.com>
Message-ID: <3c3e3fca0903301020sece2869scfb385ce6fcd4fb7@mail.gmail.com>

On Mon, Mar 30, 2009 at 12:07 PM, Lee Howard <spiffnolee at yahoo.com> wrote:
> At its February 6, 2009 meeting, ?the Board accepted the recommendation of the
> Advisory Council, finding that the process had been followed, and adopted
> policy proposal 2008-6: Emergency Transfer Policy for IPv4 Addresses.

Hi Lee,

For reference, the 2/6/09 meeting minutes are at
https://www.arin.net/about_us/bot/bot2009_0206.html . Section 6
contains the part associated with proposal 2008-6. It's about a dozen
paragraphs long.


> Allowing for the possibility that demand might increase
> as IANA allocates its last IPv4 numbers, the Board believes that there is
> insufficient time for another full policy cycle.

I would ask the board to justify this claim. Policy 2008-6 was
introduced 8/26/2008 and the board had the opportunity to ratify it
2/6/2009, slightly less than 6 months later. Given that the best
available projections don't show the IANA free pool depleting inside
the next 24 months nor ARIN's free pool depleting within the next 36,
what is the *factual basis* for the conclusion that less than 6 months
may remain before the inability to sell IP addresses causes an
operational problem?


>?The policy in 2008-6 allowed
> the Board to activate it by declaring an emergency,

Er, what?

I'm not aware of of any text in 2008-6 which required or even
recommended that the board declare an emergency in order to activate
it. My understanding of 2008-6 was that it was to be active upon
finding of consensus and ratification by the board. The word
"emergency" in the title was a no-op; it's presence in a proposal
title has no defined meaning within the published PDP. It only
reflected the author's view that creating a transfer policy was
important.

I supported 2008-6. I disapproved of the use of the word "emergency"
in the title and would have opposed the policy had I believed the word
to be anything more than a no-op. I doubt I'm the only one in this
position.


> The policy had certain gaps which, in the Board?s opinion, allowed for
> exploitation.

The meeting minutes offer no explanation or support for this finding
whatsoever. It seems inexplicable given that 2009-1 opens things
rather wider than 2008-6.


>?As noted in the minutes of the February 6 meeting, the Board
> resolved to make certain edits to the policy that ?had just been adopted.
> These edits were out of order:

And they still are. Absent a *properly documented* emergency, 2009-1
is out of order.

It ain't an emergency just 'cause you say so. How does the phrase go?
"A decent respect to the opinions of mankind requires that they should
declare the causes which impel them." Smart fellow, the guy who
figured out that one.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From owen at delong.com  Mon Mar 30 13:20:14 2009
From: owen at delong.com (Owen DeLong)
Date: Mon, 30 Mar 2009 10:20:14 -0700
Subject: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using the
	Emergency PDP)
In-Reply-To: <612085.88395.qm@web63306.mail.re1.yahoo.com>
References: <49C911A8.5020009@arin.net>
	<3c3e3fca0903271339q6dd8f49ekeced041da77ca979@mail.gmail.com>
	<Pine.SOC.4.61.0903271552530.15203@paixhost.pch.net>
	<4D11C00D-9852-4740-A75A-ADBD22ABBE4F@ufp.org>
	<612085.88395.qm@web63306.mail.re1.yahoo.com>
Message-ID: <DE0D385B-604D-4DE1-BD88-E0EFE7D1F98E@delong.com>


On Mar 29, 2009, at 8:23 AM, Lee Howard wrote:

>
> ----- Original Message ----
>> From: Leo Bicknell <bicknell at ufp.org>
>> To: Bill Woodcock <woody at pch.net>
>> Cc: arin-ppml at arin.net
>> Sent: Sunday, March 29, 2009 10:21:35 AM
>> Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy  
>> (Using the Emergency PDP)
>>
>> I don't know of anything preventing the Board from participating  
>> other
>> than their own desire to remain neutral in the process.
>
> "Policy proposals may be submitted by anyone in the global Internet
> community except for members of the ARIN Board of Trustees or the ARIN
> staff."
>
> https://www.arin.net/policy/pdp.html
>
> Lee
>
>

This prevents them from proposing a policy, but, it does not prevent
them from commenting on or giving direction to the AC regarding
an existing proposal.

Owen



From tedm at ipinc.net  Mon Mar 30 13:48:31 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 30 Mar 2009 10:48:31 -0700
Subject: [arin-ppml] How hard is it to transition to IPv6?
In-Reply-To: <49CD7290.8060900@sprunk.org>
References: <28E139F46D45AF49A31950F88C49745859BFC6@E03MVZ2-UKDY.domain1.systemhost.net>
	<49CD7290.8060900@sprunk.org>
Message-ID: <40F4213F98FB45D6AB974BE50A35EC4B@tedsdesk>

 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Stephen Sprunk
> Sent: Friday, March 27, 2009 5:43 PM
> To: michael.dillon at bt.com
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] How hard is it to transition to IPv6?
> 
> michael.dillon at bt.com wrote:
> > And read my email again, carefully this time. In effect, I 
> told the customers of all ISPs, not just one ISP, that they 
> SHOULD complain about their ISP supplier's negligence if that 
> ISP supplier does not provide satisfactory timelines for IPv6 
> support.  If you are signing two year contracts, then you 
> might get one more renegotiation cycle before IPv4 runs out. 
> If you are signing on for three years, you might not get a 
> chance until it is too late, which means that NOW IS THE TIME 
> TO TALK TO ALL OF YOUR SUPPLIERS of network services and 
> network equipment and network software. This is simple 
> reasoning based on the projected runout dates.
> >   
> 
> Note that "complaints" and "discussions" are, in most cases, 
> not enough.  You must make it clear that support for your 
> requested feature
> (IPv6 or anything else) is mandatory or you'll take your 
> business to someone else who does offer it -- and follow 
> through on that threat if they fail to comply.  Lost 
> business, particularly from existing customers, is the _only_ 
> thing that reliably motivates large companies.
> 

I must disagree with this approach.

We've had a handful of ultimatims from customers in our history.
I'm sure that every network provider has.  All of them I can
recall are outrageous.  For example, one time a customer with
an infected server (which we had identified was infected and was
spamming millions of pieces of mail a day as well as attacking
servers across the Internet) in our colo 
demanded that we allow them to continue running this webserver
for a week because they were too busy to get around to fixing
it - and that if we didn't let them do it, they would pull out
their server.  I can tell you that made a difficult decision
(cutting off their service, designing filters, etc.) very very easy.

Almost always, issuing a simple ultimatim is counterproductive.  We
have also discovered with experience that many times, responding to
an ultimatim is a waste of time - because by the time the customer
issues one, they already have made an internal decision to leave
anyway, and they are just mad at you for "forcing" them to leave,
so many times these are "spite" ultimatims.

When pushed, large companies look at everything from a cost/benefit ratio.
Meaning, how much money will it take to satisfy a current customer
demand vs how much money it will take to write off a current customer
and get a new one.  Right now, IPv6 cost to implement for a lot of these
large companies is higher than the cost to write off a customer demanding
IPv6 and get a new one not demanding IPv6 to replace it  In other words,
in a large ISP that isn't offering IPv6 right now, the chief of network
operations isn't going to get in trouble from his CEO if he tells a
customer issuing an ultimatim to screw themselves, because he can easily
show that answering that will cost more money than the customer is
worth.

Even the US Government, which you wouild think is the 600 pound gorilla
on this, discovered that.  They mandated IPv6 for last year - and still
a lot of their vendors weren't in compliance by the deadline.  Some likely
still aren't.  I'm sure all are working on it, though.

If every IPv6-demanding customer simply writes off a vendor and gets a
new one that is supplying IPv6, it is going to
end up creating several large networks who have all the IPv6 business
while the rest of the world is IPv4 and then everything will grind to
a halt with regards to IPv6 penetration.

Obviously, if your being pressed by a customer to sell them IPv6 and
your business is structured to where you're the flea on that customers
back (like if they are 90% of your business) you don't have a choice
if your feeds or peers don't supply IPv6.

But, for most other people, I think just being persistent and continuing
to bother your vendors, asking for it, would eventually work.  After all,
vendors know they have to switch over to it eventually and I think all
the large ones are working on it.

Ted



From info at arin.net  Mon Mar 30 14:02:49 2009
From: info at arin.net (Member Services)
Date: Mon, 30 Mar 2009 14:02:49 -0400
Subject: [arin-ppml] Draft Policy 2009-3 (Global): Allocation of IPv4
 Blocks to Regional Internet Registries
In-Reply-To: <37137.208.54.95.48.1238379940.squirrel@webmail.lacnic.net.uy>
References: <37137.208.54.95.48.1238379940.squirrel@webmail.lacnic.net.uy>
Message-ID: <49D10949.9000803@arin.net>

Raul,

According to the ARIN Policy Development Process the petition period for
the upcoming San Antonio meeting closed on 13 March 2009. The deadline
information was posted to PPML earlier this month, see the post:
http://lists.arin.net/pipermail/arin-ppml/2009-March/013106.html

The draft policy is under discussion, statements of support and
opposition are welcome and appreciated. Both the discussion on the PPML
and at the Public Policy Meeting will be used by the AC to determine the
community consensus regarding adopting this as policy.

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)

raul at lacnic.net wrote:
> Dear all:
>
> This proposal is a proposal for a global policy. It means that the same
> proposal has to be approved in every region. They can be approved with
> some wording differences, but the spirit of the proposal should be the
> same.
>
> The proposal was the result of a long collaboration effort of senior staff
> members and board members of all the 5 RIRs and the original text is the
> one that is being considered in every region.
>
> As far as I know the authors of the proposal were not consulted by the
> ARIN-AC and based on exchanges among the authors in the past few days, I
> can say that in general the feeling is that the changes introduced by the
> ARIN-AC are very signficant and so, this is a different proposal.
>
> My personal view is that changing the concept of a global policy proposal
> in one RIR means to avoid the approval of the policy. I strongly encourage
> ARIN to put the original proposal under consideration of its community as
> it is being done in the other regions. The proposal can be approved or
> not, That's part of the process, but it doesn't make sense to approve a
> different proposal. IMHO, the AC is able to put forward the new proposal
> for discussion if they consider that it is better, and in that way to
> start the process of discussion of a new global policy proposal.
>
> I have to confess that dealing with 5 different PDPs is not so easy. I
> don't know if a petition process should be started, If yes, please take
> this email as the request for initiating that process.
>
> Since this announcement was issued last Monday in the afternoon, I am not
> sure how the business days are counted, but I guess that I am still within
> the valid period.
>
> However, I think that as a practices, global policy proposals should not
> be changed by any advisory council or policy chair of one region due to
> the impact that to change the proposal produce in the global process.
>
>
> Best Regards,
>
> Ra?l
>
>
>
> ---------------
>
>
>
> El 23/03/2009, a las 04:05 p.m., Member Services escribi?:
>
> Draft Policy 2009-3 (Global)
> Allocation of IPv4 Blocks to Regional Internet Registries
>
> The following draft policy text is being posted for feedback and
> discussion on the Public Policy Mailing List (PPML).
>
> This draft policy was developed by the ARIN Advisory Council (AC) from
> Policy Proposal 82: Allocation of IPv4 Blocks to Regional Internet
> Registries. The AC has taken the proposal and developed it into a draft
> policy. The AC was required to submit text to ARIN for staff and legal
> assessment prior to selecting it as a draft policy. The assessment,
> along with the text that was assessed, is located below the draft policy.
>
> On 20 March 2009 the ARIN Advisory Council (AC) selected Draft Policy
> 2009-3: Allocation of IPv4 Blocks to Regional Internet Registries for
> adoption discussion on the PPML and at the upcoming Public Policy Meeting.
>
> Draft Policy 2009-3 is below and can be found at:
> https://www.arin.net/policy/proposals/2009_3.html
>
> We encourage you to discuss Draft Policy 2009-3 on the PPML prior to the
> ARIN XXIII Public Policy Meeting. Both the discussion on the PPML and at
> the Public Policy Meeting will be used by the AC to determine the
> community consensus regarding adopting this as policy.
>
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
>
> All of the Draft Policies under discussion can be found at:
> https://www.arin.net/policy/proposals/index.html
>
> Regards,
>
> Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Draft Policy 2009-3 (Global)
> Allocation of IPv4 Blocks to Regional Internet Registries
>
> Date: 23 March 2009
>
> Policy statement:
>
> This document describes the policy governing the allocation of IPv4
> address space from the IANA to the Regional Internet Registries (RIRs).
> This document does not stipulate performance requirements in the
> provision of services by IANA to an RIR in accordance with this policy.
> Such requirements should be specified by appropriate agreements among
> the RIRs and ICANN.
>
> This policy is to be implemented in two phases.
>
> A. Phase I: Recovery of IPv4 Address Space
>
> Upon ratification of this policy by the ICANN Board of Directors the
> IANA shall establish a mechanism to receive IPv4 address space which is
> returned to it by the RIRs, and hold that address space in a 'recovered
> IPv4 pool'.
>
> Each RIR through their respective chosen policies and strategies may
> recover IPv4 address space which is under their administration. At
> quarterly intervals, each RIR shall return to the IANA any legacy
> address space recovered, and may return to the IANA any non-legacy
> address space recovered, in aggregated blocks of /24 or larger, for
> inclusion in the recovered IPv4 pool.
>
> During Phase I, no allocations will be made from the recovered IPv4
> pool. Return of recovered address space (as described above) will
> continue throughout Phase II.
>
> B. Phase II: Allocation of Recovered IPv4 address space by the IANA
>
> Upon ratification of this policy by the ICANN Board of Directors and a
> declaration by the IANA that its existing free pool of unallocated IPv4
> address space is depleted; Global Addressing Policy ASO-001-2 (adopted
> by ICANN Board 8 April 2005) is rescinded. IANA will then commence to
> allocate the IPv4 address space from the recovered IPv4 pool.
>
> 1. The following definitions apply to this policy:
>
> a. Recovered Address Space. Recovered address space is that address
> space that is returned to an RIR as a result of any activity that seeks
> to reclaim unused address space or is voluntarily returned to the RIR or
> is reclaimed by the RIR as a result of legal action or abuse
> determination. Recovered address space does not include that address
> space that is reclaimed because of non-payment of contractual fees whose
> reclamation date is less than 1 year at the time of the report.
>
> b. IPv4 Address Holdings. IPv4 address holdings are all unallocated IPv4
> address space held by an RIR to include recovered address space not yet
> returned less that address space that is committed in accordance with
> the RIR's reservation policy and practices.
>
> c. Aggregated address blocks. Aggregated address blocks are contiguous
> prefixes that can be aggregated on natural bit boundaries. 10.0.0.0/24
> and 10.0.1.0/24 are two contiguous prefixes that can be combined to form
> an aggregated address block. 10.0.0.0/24 and 10.0.1.0/25 are two
> contiguous prefixes that cannot be combined on a natural bit boundary to
> form an aggregated block.
>
> d. Legacy address space. IPv4 address space allocated or assigned prior
> to the creation of the RIR.
>
> 2. Allocation of IPv4 Address Space
>
> a. For the purposes of this policy, an 'IPv4 allocation period' is
> defined as a 6-month period following 1 March or 1 September in each year.
>
> b. At the beginning of each IPv4 allocation period, the IANA will
> determine the 'IPv4 allocation unit' for that period, as 1/10 of its
> IPv4 address pool, rounded down to the next CIDR (power-of-2) boundary.
> The minimum 'IPv4 allocation unit' size will be a /24.
>
> c. In each allocation period, each RIR may issue one IPv4 request to the
> IANA. Providing that the RIR satisfies the allocation criteria described
> in paragraph B.2, the IANA will allocate a single allocation unit,
> composed of the smallest possible number of blocks available in its IPv4
> address pool.
>
> 3. IPv4 Address Space Allocation Criteria
>
> A RIR is eligible to receive additional IPv4 address space from the IANA
> when the total of its IPv4 address holdings is less than 50% of the
> current IPv4 allocation unit, and providing that it has not already
> received an IPv4 allocation from the IANA during the current IPv4
> allocation period.
>
> 4. Initial Allocation of IPv4 Address Space
>
> Each new RIR shall, at the moment of recognition, be allocated one (1)
> allocation unit by the IANA. If an allocation unit is not available,
> then the IANA will issue this block as soon as one is available. This
> allocation will be made regardless of the newly formed RIR's projected
> utilization figures and shall be independent of the IPv4 address space
> that may have been transferred to the new RIR by the already existing
> RIRs as part of the formal transition process.
>
> 5. Reporting
>
> a. All returned space is to be recorded in an IANA-published log of IPv4
> address space transactions, with each log entry detailing the returned
> address block, the date of the return, and the returning RIR.
>
> b. All allocated space is also to be recorded in this IANA-published log
> of IPv4 address space transactions, with each log entry detailing the
> address blocks, the date of the allocation and the recipient RIR.
>
> c. The IANA will maintain a public registry of the current disposition
> of all IPv4 address space, detailing all reservations and current
> allocations and current IANA-held address space that is unallocated.
>
> d) The IANA may make public announcements of IPv4 address block
> transactions that occur under this policy. The IANA will make
> appropriate modifications to the "Internet Protocol V4 Address Space"
> page of the IANA website and may make announcements to its own
> appropriate announcement lists. The IANA announcements will be limited
> to which address ranges, the time of allocation and to which Registry
> they have been allocated.
>
>
>
> #####
>
> ARIN Staff Assessment
>
> *Title: Allocation of IPv4 Blocks to the Regional Internet Registries*
>
> *Proposal Submitted: 30 Jan 2009*
>
> *Revision Submitted: 05 March 2009*
>
> *Date of Assessment: 10 March 2009*
>
> * *
>
> I. Understanding of the Policy:
>
> *Staff Understanding of the Proposal:*
>
> Staff understands that this proposal would be implemented in 2 phases.
> Phase 1 would require the RIRs to return recovered IPv4 legacy address
> space (via policy or procedure) to the IANA and have the option of
> returning recovered non-legacy address space to the IANA. Phase 2 would
> start after the depletion of the IANA free pool and would nullify the
> existing IANA to RIR policy (Global Addressing Policy ASO-001-2). The
> new IANA to RIR policy would allow each RIR to receive approximately
> 1/10th of the recovered IPv4 pool from IANA once every 6 months as long
> as it meets the qualification criteria written in paragraph B2. IANA
> will be required to keep a log of all returned IPv4 address space and
> all issued IPv4 address space from the recovered pool, as well as
> maintain a public registry of the current disposition of all IPv4
> address space.
>
> II. Comments
>
> A. ARIN Staff Comments
>
> * The one policy that this impacts is NRPM 4.6 Amnesty and
>   Aggregation, which says ?Transactions should only be accepted
>   under this policy if they are in the interests of the community
>   (e.g. they improve aggregation or result in a net reclamation of
>   space).? Because the ARIN region holds the majority of the legacy
>   address space, and most of the address space returned under this
>   policy is legacy space, it would mean that there would be no ?net
>   return? of address space to ARIN. ARIN would essentially be
>   exchanging legacy address space for non-legacy address space, and
>   returning the legacy address space it received in the exchange to
>   IANA, resulting in a net loss of address space in ARIN?s available
>   pool.
>
> B. ARIN General Counsel Comments:
>
> The current basis of allocation of numbers was established in RFC's 2008
> and 2050 and is need based. If one region has greater needs than
> another, the current policy of IANA does not require equal distribution
> to all RIR's s. This proposed policy would establish a different
> political and not needs based method for allocating returned space. It
> would make each RIR an equal recipient of such space. But the level of
> need and economic activity between each RI R is not equal. This policy
> will tend to reallocate returned space away from where it is recovered,
> in the ARIN region , and move more of it to AFRINIC and LACNIC than
> current distribution principles. By equating the smaller economies and
> related needs of certain regions to the needs of other regions, like
> ARIN, that have greater day to day need, it in effect creates a new
> political order of distribution thru equal shares. It is possible
> sovereign governments in the regions with greater activity will not
> agree to such a revised distribution model. The proposed policy
> undermines the legal rationale for distribution.
>
> The policy also creates a powerful disincentive for any RIR, including
> ARIN, to undertake any financial expenditure of RIR dollars for programs
> intended to obtain returned space for reallocation. Currently ARIN is
> working towards policies such as the LRSA and 2008-6, intended to
> encourage returns and use of under utilized resources, but which cost
> ARIN expenditures other RIRs are not duplicating. Any policy which
> creates such a disincentive by leaving expenditures with a single RIR,
> who cannot benefit except to receive 20% of the returned space should be
> carefully considered.
>
> Finally, it is likely entities with number resources in the ARIN region
> may be willing to return those resources for uses in the region but
> unwilling to do so if 4/5 of such resources will be sent to other regions.
>
> III. Resource Impact
>
> The resource impact of implementing this policy is viewed as minimal. It
> is estimated that this policy could require up to 3 person months of
> effort to implement following ratification by the ARIN Board of
> Trustees. Because this implementation is not planned, it may preempt
> ARIN?s current project deployment schedule. It may require the following:
>
> * Modifications to existing registration procedures to include the
>   handling of returned/reclaimed address space and the process of
>   requesting additional address space from the IANA.
> * Staff training
>
> Text assessed:
>
> *Allocation of IPv4 Blocks to Regional Internet Registries (Global)*
>
> *Policy statement:*
>
> This document describes the policy governing the allocation of IPv4
> address space from the IANA to the Regional Internet Registries (RIRs).
> This document does not stipulate performance requirements in the
> provision of services by IANA to an RIR in accordance with this policy.
> Such requirements should be specified by appropriate agreements among
> the RIRs and ICANN.
>
> This policy is to be implemented in two phases.
>
> A. Phase I: Recovery of IPv4 Address Space
>
> Upon ratification of this policy by the ICANN Board of Directors the
> IANA shall establish a mechanism to receive IPv4 address space which is
> returned to it by the RIRs, and hold that address space in a 'recovered
> IPv4 pool'.
>
> Each RIR through their respective chosen policies and strategies may
> recover IPv4 address space which is under their administration. At
> quarterly intervals, each RIR shall return any legacy address space
> recovered, and may return any non-legacy address space recovered, to the
> IANA in aggregated blocks of /24 or larger, for inclusion in the
> recovered IPv4 pool.
>
> During Phase I, no allocations will be made from the recovered IPv4
> pool. Return of recovered address space (as described above) will
> continue throughout Phase II.
>
> B. Phase II: Allocation of Recovered IPv4 address space by the IANA
>
> Upon ratification of this policy by the ICANN Board of Directors and a
> declaration by the IANA that its existing free pool of unallocated IPv4
> address space is depleted; Global Addressing Policy ASO-001-2 (adopted
> by ICANN Board 8 April 2005) is rescinded. IANA will then commence to
> allocate the IPv4 address space from the recovered IPv4 pool.
>
> 1. The following definitions apply to this policy:
>
> a. Recovered Address Space. Recovered address space is that address
> space that is returned to an RIR as a result of any activity that seeks
> to reclaim unused address space or is voluntarily returned to the RIR or
> is reclaimed by the RIR as a result of legal action or abuse
> determination. Recovered address space does not include that address
> space that is reclaimed because of non-payment of contractual fees whose
> reclamation date is less than 1 year at the time of the report.
>
> b. IPv4 Address Holdings. IPv4 address holdings are all unallocated IPv4
> address space held by an RIR to include recovered address space not yet
> returned less that address space that is committed in accordance with
> the RIR's reservation policy and practices.
>
> c. Legacy address space. IPv4 address space allocated or assigned prior
> to the creation of the RIR.
>
> 2. Allocation of IPv4 Address Space
>
> a. For the purposes of this policy, an 'IPv4 allocation period' is
> defined as a 6-month period following 1 March or 1 September in each year.
>
> b. At the beginning of each IPv4 allocation period, the IANA will
> determine the 'IPv4 allocation unit' for that period, as 1/10 of its
> IPv4 address pool, rounded down to the next CIDR (power-of-2) boundary.
>
> c. In each allocation period, each RIR may issue one IPv4 request to the
> IANA. Providing that the RIR satisfies the allocation criteria described
> in paragraph B.2, the IANA will allocate a single allocation unit,
> composed of the smallest possible number of blocks available in its IPv4
> address pool.
>
> 3. IPv4 Address Space Allocation Criteria
>
> A RIR is eligible to receive additional IPv4 address space from the IANA
> when the total of its IPv4 address holdings is less than 50% of the
> current IPv4 allocation unit, and providing that it has not already
> received an IPv4 allocation from the IANA during the current IPv4
> allocation period.
>
> 4. Initial Allocation of IPv4 Address Space
>
> Each new RIR shall, at the moment of recognition, be allocated one (1)
> allocation unit by the IANA. If an allocation unit is not available,
> then the IANA will issue this block as soon as one is available. This
> allocation will be made regardless of the newly formed RIR's projected
> utilization figures and shall be independent of the IPv4 address space
> that may have been transferred to the new RIR by the already existing
> RIRs as part of the formal transition process.
>
> 5. Reporting
>
> a. All returned space is to be recorded in an IANA-published log of IPv4
> address space transactions, with each log entry detailing the returned
> address block, the date of the return, and the returning RIR.
>
> b. All allocated space is also to be recorded in this IANA-published log
> of IPv4 address space transactions, with each log entry detailing the
> address blocks, the date of the allocation and the recipient RIR.
>
> c. The IANA will maintain a public registry of the current disposition
> of all IPv4 address space, detailing all reservations and current
> allocations and current IANA-held address space that is unallocated.
>
> d) The IANA may make public announcements of IPv4 address block
> transactions that occur under this policy. The IANA will make
> appropriate modifications to the "Internet Protocol V4 Address Space"
> page of the IANA website and may make announcements to its own
> appropriate announcement lists. The IANA announcements will be limited
> to which address ranges, the time of allocation and to which Registry
> they have been allocated.
>
>
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
>
>
>   



From tedm at ipinc.net  Mon Mar 30 14:38:43 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 30 Mar 2009 11:38:43 -0700
Subject: [arin-ppml] Draft Policy 2008-7: Identify Invalid WHOIS POC's
In-Reply-To: <1b09e924bfa74d4b8a637aded2350ebe@mail.dessus.com>
References: <C6DEAD436BB443C4B6A2414FCC5F1F39@tedsdesk>
	<1b09e924bfa74d4b8a637aded2350ebe@mail.dessus.com>
Message-ID: <B5B3524EDAD44F7D8C54A31EFB848507@tedsdesk>

 

> -----Original Message-----
> From: Keith Medcalf [mailto:kmedcalf at dessus.com] 
> Sent: Sunday, March 29, 2009 8:26 AM
> To: Ted Mittelstaedt
> Cc: arin-ppml at arin.net
> Subject: RE: [arin-ppml] Draft Policy 2008-7: Identify 
> Invalid WHOIS POC's
> 
> 
> Ted Mittelstaedt wrote:
> 
> > The valid POCs can be handled by automated e-mail systems with a 
> > specific URL link in the mail sent to the POC.  Network Solutions 
> > already does this for ALL domain name holders in their 
> registrar and 
> > it's completely automated.  ARIN staff can contact Network 
> Solutions 
> > and ask how they do it if they do not understand how to do this.
> 
> Network Solutions does not do this.  My domain is registered 
> with Network Solutions and always has been.  I have nothing 
> to update, nonetheless, the only verification attempt I ever 
> received from them was many a year ago when they did a postal 
> mail validation.  I have never received e-mail attempting to 
> verify my POK data at Network Solutions.
> 

Yes, they absolutely do do this, I have several verification 
e-mails from them in my archives.  The reason you haven't got
mails from them is that they already verified that your domain
resolves.

Here's the text of the last one of these I can find (I usually
delete these):

--------------------------
Return-Path: <partnerprogram at networksolutions.com>
Received: from heron.networksolutions.com (heron.networksolutions.com
[205.178.190.224])
	by mail.ipinc.net (8.13.8/8.13.8) with ESMTP id l5TIprmP030813
	for <hostmaster at ipinc.net>; Fri, 29 Jun 2007 11:51:56 -0700 (PDT)
	(envelope-from partnerprogram at networksolutions.com)
Received: from VAMAIL3.CORPIT.NSI.NET (vamail1.corpit.nsi.net
[10.216.32.25])
	by heron.networksolutions.com (8.12.10/8.12.10) with ESMTP id
l5TIpln7002813
	for <hostmaster at ipinc.net>; Fri, 29 Jun 2007 14:51:48 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_001_01C7BA7E.8BC4A0B8"
Subject: Domains in Your Account Require Attention
Date: Fri, 29 Jun 2007 14:51:47 -0400
Message-ID:
<9E93DEC285888046B8949287D8B837640466F285 at VAMAIL3.CORPIT.NSI.NET>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: Domains in Your Account Require Attention
thread-index: Ace6fouh27SlVfbqRG2H+J9XFV0t5g==
From: "Network Solutions Partner Program"
<partnerprogram at networksolutions.com>
To: <hostmaster at ipinc.net>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0
(mail.ipinc.net [65.75.192.11]); Fri, 29 Jun 2007 11:51:56 -0700 (PDT)
X-Virus-Scanned: ClamAV 0.90.2/3556/Fri Jun 29 09:23:10 2007 on
mail.ipinc.net
X-Virus-Status: Clean
X-Spam-Status: No, score=0.5 required=4.1 tests=DNS_FROM_RFC_ABUSE,
	HTML_MESSAGE autolearn=disabled version=3.1.8
X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on mail.ipinc.net


Dear Valued Partner:

In the spirit of Internet good citizenship, Network Solutions has looked at
its domain name inventory under management and is making efforts to have all
domains resolve as expected by the Internet community. As a courtesy, we did
an analysis on your inventory and have found 2 domain names that do not
resolve. Our analysis included several checks over time to ensure that the
domain and common third level extensions of the domain such as "www", "ftp",
"mail", did not resolve to any IP address.  To NOT resolve, a query to the
name server of record for a given domain had to either not respond at all or
respond in a manner indicating it had no information for that domain. 

Attached you will find a list of domains that fit the above description at
the time we completed our analysis. We are writing to ask that you make
arrangements to have these resolve properly. Alternately, you may choose to
do nothing and beginning on or about July 29, 2007 Network Solutions will
update the DNS on your behalf to resolve to an under construction page.

Regards, 

Network SolutionsR Partner Program
--------------------------

In the above case, what generated this was a domain name that
a customer owned who went bankrupt that was pointing to a set of
old nameservers that we abandoned.

Apparently NetSol assumes that a domain name with servers that
are resolving for that name has a contact reachable via e-mail.
Which makes sense - if a nameserver resolves anything, even a
SOA, for a domain, that means someone is paying the operator of
that nameserver to respond to queries, and thus if the published
WHOIS data for the domain is bogus, you still can reach the
person who owns the domain via their host of the nameservers that
are responding to queries for it.

But, for Netsol to know this, they still had to scan through
their list of registered names.  Just because you didn't get
a verification e-mail, doesn't mean they didn't do some kind
of address verification.  Maybe they just connected to your
mailserver, did a HELO, MAIL FROM, RECPT TO, and when the
server responded with an OK, disconnected.  That's how the
spammers dig up e-mail addresses, after all.

> Of course, it is possible that they (NetSol) [have] 
> attempt[ed] to use SMTP transported web-pages sent from a 
> non-RFC compliant SMTP server, in which case I would have 
> never received the messages (and they would not qualify as 
> "e-mail" anyway).
> 

Um, did you note the X-Spam-Status: line above?  The header is
a most interesting read.

> Thus my requirement that any policy authorizing e-mail (SMTP 
> transported) verification of POK data have a very narrow 
> definition of what qualifies as "e-mail".

You could also greatly expand the "Invalid WHOIS POC" policy
proposal by stating that any POC attached to a currently-advertised
netblock is reachable if their upstream is reachable.

But, this shifts the focus on the netblocks.  Keep in mind that
a netblock may have multiple POCs attached to it, some legitimate,
some old and stale and bogus.  It is not a 1-to-1 ratio.  Thus,
deleting and invalidating a POC does not necessarily affect a
netblock.

You could easily have a POC that is just one contact on a block
that has multiple POCs on it, the rest of which are legitimate and
responding, get deleted as a result of our policy proposal.  This 
is behavior we WANT!  Why have stale POC entries cluttering up WHOIS?

And, what about POC's that were tied to a netblock that was later
returned, and ARIN made a mistake and didn't delete the POC and it's
still bouncing around in WHOIS?

We just did not want to clutter up the proposal with these kinds of
details.

> In order to 
> qualify as e-mail, the message MUST be text/plain and MUST be 
> sent from a strictly RFC compliant SMTP host which has (a) 
> proper forward and reverse DNS; (b) proper MX records for the 
> sending domain; (c) must be sent from the ARIN.NET domain 
> (not a third party mailer); and, (d) must have correct SPF 
> records if any.
> 
> The interpretation of "e-mail" must be strictly specified.  
> Interpretation of what consititutes e-mail MUST NOT be open 
> for interpretation by the unwashed, particularly those 
> members of the unwashed who believe that web-pages by SMTP is 
> somehow "e-mail".
> 

Keep in mind that every SUCCESSFUL delivery of a verification
email results in LESS WORK for ARIN staff in following up.  Thus,
there's a built-in incentive to figure out how to get their 
verification message, and it's follow-ups, accepted.

Your objection is basically against SMTP connections to your
mailserver that are "more spammmy" ie: more like those coming
from a spammer, and less like those coming from a legitimate
mailserver.  Since lots and lots of sites these days are running
all kinds of spam filters that rank incoming mail as more and
less spammy, the less spamlike that ARIN's verification mails
are, the greater chance for acceptance by everyone.  In short,
you and they would have the same goals, thus why write these
details into the policy?

Maybe ARIN will find some sites so messed-up that the initial verification
e-mail that's strict RFC is ignored, while a second "more spamlike"
mail that is a HTMLized "web-page SMTP" would be responded to.
Are you so hostile to HTMLized mail that you would want to
deny these sites the ability to respond?  After all the goal is
POC verification, not to make people suffer who are too dumb to read
plain text mails.

Ted




From bill at herrin.us  Mon Mar 30 14:42:52 2009
From: bill at herrin.us (William Herrin)
Date: Mon, 30 Mar 2009 14:42:52 -0400
Subject: [arin-ppml] clarification of Board actions Feb 2 and Mar 18,
	2009
In-Reply-To: <75822E125BCB994F8446858C4B19F0D76BEA10BE@SUEX07-MBX-04.ad.syr.edu>
References: <376189.27706.qm@web63303.mail.re1.yahoo.com>
	<3c3e3fca0903301020sece2869scfb385ce6fcd4fb7@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D76BEA10BE@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <3c3e3fca0903301142v59412978wc38a3b3c64340806@mail.gmail.com>

On Mon, Mar 30, 2009 at 2:04 PM, Milton L Mueller <mueller at syr.edu> wrote:
> So you are claiming that a policy that had the word "emergency" in the title
> represented no agreement that anything approximating an emergency was involved.

Milton,

I claim that under the published PDP the mere presence of the word
"emergency" in the title neither requested nor required any action of
the BoT other than what they would have done if the word had not been
present.

I also claim that the consensus support for 2008-6 was for the
proposal in total, not for any particular part of it severed from the
rest.


> apparently all those others, like you, failed to make this clear in the discussion of the policy

IIRC, I did complain about the use of the word "emergency" in the
title. Later, after the final revision, I didn't see the need to argue
over semantics: the word was a functional no-op and it's presence
helped some portion of the community accept the proposal.


But let's not get sidelined. Whether the board needed to declare an
emergency to activate 2008-6 is the least of the issues facing us.

Regards,
Bill Herrin

-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From mueller at syr.edu  Mon Mar 30 14:04:06 2009
From: mueller at syr.edu (Milton L Mueller)
Date: Mon, 30 Mar 2009 14:04:06 -0400
Subject: [arin-ppml] clarification of Board actions Feb 2 and Mar 18,
	2009
In-Reply-To: <3c3e3fca0903301020sece2869scfb385ce6fcd4fb7@mail.gmail.com>
References: <376189.27706.qm@web63303.mail.re1.yahoo.com>
	<3c3e3fca0903301020sece2869scfb385ce6fcd4fb7@mail.gmail.com>
Message-ID: <75822E125BCB994F8446858C4B19F0D76BEA10BE@SUEX07-MBX-04.ad.syr.edu>

> -----Original Message-----
> 
> I'm not aware of of any text in 2008-6 which required or even
> recommended that the board declare an emergency in order to activate
> it. My understanding of 2008-6 was that it was to be active upon
> finding of consensus and ratification by the board. The word
> "emergency" in the title was a no-op; it's presence in a proposal
> title has no defined meaning within the published PDP. It only
> reflected the author's view that creating a transfer policy was
> important.

So you are claiming that a policy that had the word "emergency" in the title both 
1. had broad consensus and 
2. represented no agreement that anything approximating an emergency was involved. 

interesting interpretation. 

> I supported 2008-6. I disapproved of the use of the word "emergency"
> in the title and would have opposed the policy had I believed the word
> to be anything more than a no-op. I doubt I'm the only one in this
> position.

apparently all those others, like you, failed to make this clear in the discussion of the policy 



From scottleibrand at gmail.com  Mon Mar 30 15:36:40 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Mon, 30 Mar 2009 12:36:40 -0700
Subject: [arin-ppml] Draft Policy 2009-3 (Global): Allocation of IPv4
 Blocks to Regional Internet Registries
In-Reply-To: <49D10949.9000803@arin.net>
References: <37137.208.54.95.48.1238379940.squirrel@webmail.lacnic.net.uy>
	<49D10949.9000803@arin.net>
Message-ID: <49D11F48.6090905@gmail.com>

Raul,

Given that it's too late to initiate a separate discussion petition for 
the San Antonio meeting, I would like to assure you that I will do what 
I can to make sure that we get feedback from the community at that 
meeting as to the support for the original proposed text, as well as for 
the revised version.  If there is a clear community consensus in favor 
of either language, my own personal opinion is that we'll be able to 
move the proposal forward, with any applicable edits, at that point.

In order to prepare for such discussion, I'd welcome feedback from the 
PPML on the following questions:

 - Do you support the original proposed text of 2009-3, requiring return 
of any reclaimed space to IANA for redistribution?  Why or why not?
 - Do you support the current modified text of 2009-3, requiring return 
of any reclaimed legacy space, but making optional the return of any 
non-legacy space?  Why or why not?
 - Would you support some other revised version of 2009-3?  If so, what 
would you want to change?  (For example, we could make all returns 
optional, for both legacy and non-legacy space.)
 - If you oppose 2009-3 completely, do you believe that current policy 
is adequate, or would you support some other mechanism to allow for the 
reallocation of IPv4 blocks between RIRs?

Thanks,
Scott

Member Services wrote:
> Raul,
>
> According to the ARIN Policy Development Process the petition period for
> the upcoming San Antonio meeting closed on 13 March 2009. The deadline
> information was posted to PPML earlier this month, see the post:
> http://lists.arin.net/pipermail/arin-ppml/2009-March/013106.html
>
> The draft policy is under discussion, statements of support and
> opposition are welcome and appreciated. Both the discussion on the PPML
> and at the Public Policy Meeting will be used by the AC to determine the
> community consensus regarding adopting this as policy.
>
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
>
> Regards,
>
> Member Services
> American Registry for Internet Numbers (ARIN)
>
> raul at lacnic.net wrote:
>   
>> Dear all:
>>
>> This proposal is a proposal for a global policy. It means that the same
>> proposal has to be approved in every region. They can be approved with
>> some wording differences, but the spirit of the proposal should be the
>> same.
>>
>> The proposal was the result of a long collaboration effort of senior staff
>> members and board members of all the 5 RIRs and the original text is the
>> one that is being considered in every region.
>>
>> As far as I know the authors of the proposal were not consulted by the
>> ARIN-AC and based on exchanges among the authors in the past few days, I
>> can say that in general the feeling is that the changes introduced by the
>> ARIN-AC are very signficant and so, this is a different proposal.
>>
>> My personal view is that changing the concept of a global policy proposal
>> in one RIR means to avoid the approval of the policy. I strongly encourage
>> ARIN to put the original proposal under consideration of its community as
>> it is being done in the other regions. The proposal can be approved or
>> not, That's part of the process, but it doesn't make sense to approve a
>> different proposal. IMHO, the AC is able to put forward the new proposal
>> for discussion if they consider that it is better, and in that way to
>> start the process of discussion of a new global policy proposal.
>>
>> I have to confess that dealing with 5 different PDPs is not so easy. I
>> don't know if a petition process should be started, If yes, please take
>> this email as the request for initiating that process.
>>
>> Since this announcement was issued last Monday in the afternoon, I am not
>> sure how the business days are counted, but I guess that I am still within
>> the valid period.
>>
>> However, I think that as a practices, global policy proposals should not
>> be changed by any advisory council or policy chair of one region due to
>> the impact that to change the proposal produce in the global process.
>>
>>
>> Best Regards,
>>
>> Ra?l
>>
>>
>>
>> ---------------
>>
>>
>>
>> El 23/03/2009, a las 04:05 p.m., Member Services escribi?:
>>
>> Draft Policy 2009-3 (Global)
>> Allocation of IPv4 Blocks to Regional Internet Registries
>>
>> The following draft policy text is being posted for feedback and
>> discussion on the Public Policy Mailing List (PPML).
>>
>> This draft policy was developed by the ARIN Advisory Council (AC) from
>> Policy Proposal 82: Allocation of IPv4 Blocks to Regional Internet
>> Registries. The AC has taken the proposal and developed it into a draft
>> policy. The AC was required to submit text to ARIN for staff and legal
>> assessment prior to selecting it as a draft policy. The assessment,
>> along with the text that was assessed, is located below the draft policy.
>>
>> On 20 March 2009 the ARIN Advisory Council (AC) selected Draft Policy
>> 2009-3: Allocation of IPv4 Blocks to Regional Internet Registries for
>> adoption discussion on the PPML and at the upcoming Public Policy Meeting.
>>
>> Draft Policy 2009-3 is below and can be found at:
>> https://www.arin.net/policy/proposals/2009_3.html
>>
>> We encourage you to discuss Draft Policy 2009-3 on the PPML prior to the
>> ARIN XXIII Public Policy Meeting. Both the discussion on the PPML and at
>> the Public Policy Meeting will be used by the AC to determine the
>> community consensus regarding adopting this as policy.
>>
>> The ARIN Policy Development Process can be found at:
>> https://www.arin.net/policy/pdp.html
>>
>> All of the Draft Policies under discussion can be found at:
>> https://www.arin.net/policy/proposals/index.html
>>
>> Regards,
>>
>> Member Services
>> American Registry for Internet Numbers (ARIN)
>>
>>
>> ## * ##
>>
>>
>> Draft Policy 2009-3 (Global)
>> Allocation of IPv4 Blocks to Regional Internet Registries
>>
>> Date: 23 March 2009
>>
>> Policy statement:
>>
>> This document describes the policy governing the allocation of IPv4
>> address space from the IANA to the Regional Internet Registries (RIRs).
>> This document does not stipulate performance requirements in the
>> provision of services by IANA to an RIR in accordance with this policy.
>> Such requirements should be specified by appropriate agreements among
>> the RIRs and ICANN.
>>
>> This policy is to be implemented in two phases.
>>
>> A. Phase I: Recovery of IPv4 Address Space
>>
>> Upon ratification of this policy by the ICANN Board of Directors the
>> IANA shall establish a mechanism to receive IPv4 address space which is
>> returned to it by the RIRs, and hold that address space in a 'recovered
>> IPv4 pool'.
>>
>> Each RIR through their respective chosen policies and strategies may
>> recover IPv4 address space which is under their administration. At
>> quarterly intervals, each RIR shall return to the IANA any legacy
>> address space recovered, and may return to the IANA any non-legacy
>> address space recovered, in aggregated blocks of /24 or larger, for
>> inclusion in the recovered IPv4 pool.
>>
>> During Phase I, no allocations will be made from the recovered IPv4
>> pool. Return of recovered address space (as described above) will
>> continue throughout Phase II.
>>
>> B. Phase II: Allocation of Recovered IPv4 address space by the IANA
>>
>> Upon ratification of this policy by the ICANN Board of Directors and a
>> declaration by the IANA that its existing free pool of unallocated IPv4
>> address space is depleted; Global Addressing Policy ASO-001-2 (adopted
>> by ICANN Board 8 April 2005) is rescinded. IANA will then commence to
>> allocate the IPv4 address space from the recovered IPv4 pool.
>>
>> 1. The following definitions apply to this policy:
>>
>> a. Recovered Address Space. Recovered address space is that address
>> space that is returned to an RIR as a result of any activity that seeks
>> to reclaim unused address space or is voluntarily returned to the RIR or
>> is reclaimed by the RIR as a result of legal action or abuse
>> determination. Recovered address space does not include that address
>> space that is reclaimed because of non-payment of contractual fees whose
>> reclamation date is less than 1 year at the time of the report.
>>
>> b. IPv4 Address Holdings. IPv4 address holdings are all unallocated IPv4
>> address space held by an RIR to include recovered address space not yet
>> returned less that address space that is committed in accordance with
>> the RIR's reservation policy and practices.
>>
>> c. Aggregated address blocks. Aggregated address blocks are contiguous
>> prefixes that can be aggregated on natural bit boundaries. 10.0.0.0/24
>> and 10.0.1.0/24 are two contiguous prefixes that can be combined to form
>> an aggregated address block. 10.0.0.0/24 and 10.0.1.0/25 are two
>> contiguous prefixes that cannot be combined on a natural bit boundary to
>> form an aggregated block.
>>
>> d. Legacy address space. IPv4 address space allocated or assigned prior
>> to the creation of the RIR.
>>
>> 2. Allocation of IPv4 Address Space
>>
>> a. For the purposes of this policy, an 'IPv4 allocation period' is
>> defined as a 6-month period following 1 March or 1 September in each year.
>>
>> b. At the beginning of each IPv4 allocation period, the IANA will
>> determine the 'IPv4 allocation unit' for that period, as 1/10 of its
>> IPv4 address pool, rounded down to the next CIDR (power-of-2) boundary.
>> The minimum 'IPv4 allocation unit' size will be a /24.
>>
>> c. In each allocation period, each RIR may issue one IPv4 request to the
>> IANA. Providing that the RIR satisfies the allocation criteria described
>> in paragraph B.2, the IANA will allocate a single allocation unit,
>> composed of the smallest possible number of blocks available in its IPv4
>> address pool.
>>
>> 3. IPv4 Address Space Allocation Criteria
>>
>> A RIR is eligible to receive additional IPv4 address space from the IANA
>> when the total of its IPv4 address holdings is less than 50% of the
>> current IPv4 allocation unit, and providing that it has not already
>> received an IPv4 allocation from the IANA during the current IPv4
>> allocation period.
>>
>> 4. Initial Allocation of IPv4 Address Space
>>
>> Each new RIR shall, at the moment of recognition, be allocated one (1)
>> allocation unit by the IANA. If an allocation unit is not available,
>> then the IANA will issue this block as soon as one is available. This
>> allocation will be made regardless of the newly formed RIR's projected
>> utilization figures and shall be independent of the IPv4 address space
>> that may have been transferred to the new RIR by the already existing
>> RIRs as part of the formal transition process.
>>
>> 5. Reporting
>>
>> a. All returned space is to be recorded in an IANA-published log of IPv4
>> address space transactions, with each log entry detailing the returned
>> address block, the date of the return, and the returning RIR.
>>
>> b. All allocated space is also to be recorded in this IANA-published log
>> of IPv4 address space transactions, with each log entry detailing the
>> address blocks, the date of the allocation and the recipient RIR.
>>
>> c. The IANA will maintain a public registry of the current disposition
>> of all IPv4 address space, detailing all reservations and current
>> allocations and current IANA-held address space that is unallocated.
>>
>> d) The IANA may make public announcements of IPv4 address block
>> transactions that occur under this policy. The IANA will make
>> appropriate modifications to the "Internet Protocol V4 Address Space"
>> page of the IANA website and may make announcements to its own
>> appropriate announcement lists. The IANA announcements will be limited
>> to which address ranges, the time of allocation and to which Registry
>> they have been allocated.
>>
>>
>>
>> #####
>>
>> ARIN Staff Assessment
>>
>> *Title: Allocation of IPv4 Blocks to the Regional Internet Registries*
>>
>> *Proposal Submitted: 30 Jan 2009*
>>
>> *Revision Submitted: 05 March 2009*
>>
>> *Date of Assessment: 10 March 2009*
>>
>> * *
>>
>> I. Understanding of the Policy:
>>
>> *Staff Understanding of the Proposal:*
>>
>> Staff understands that this proposal would be implemented in 2 phases.
>> Phase 1 would require the RIRs to return recovered IPv4 legacy address
>> space (via policy or procedure) to the IANA and have the option of
>> returning recovered non-legacy address space to the IANA. Phase 2 would
>> start after the depletion of the IANA free pool and would nullify the
>> existing IANA to RIR policy (Global Addressing Policy ASO-001-2). The
>> new IANA to RIR policy would allow each RIR to receive approximately
>> 1/10th of the recovered IPv4 pool from IANA once every 6 months as long
>> as it meets the qualification criteria written in paragraph B2. IANA
>> will be required to keep a log of all returned IPv4 address space and
>> all issued IPv4 address space from the recovered pool, as well as
>> maintain a public registry of the current disposition of all IPv4
>> address space.
>>
>> II. Comments
>>
>> A. ARIN Staff Comments
>>
>> * The one policy that this impacts is NRPM 4.6 Amnesty and
>>   Aggregation, which says ?Transactions should only be accepted
>>   under this policy if they are in the interests of the community
>>   (e.g. they improve aggregation or result in a net reclamation of
>>   space).? Because the ARIN region holds the majority of the legacy
>>   address space, and most of the address space returned under this
>>   policy is legacy space, it would mean that there would be no ?net
>>   return? of address space to ARIN. ARIN would essentially be
>>   exchanging legacy address space for non-legacy address space, and
>>   returning the legacy address space it received in the exchange to
>>   IANA, resulting in a net loss of address space in ARIN?s available
>>   pool.
>>
>> B. ARIN General Counsel Comments:
>>
>> The current basis of allocation of numbers was established in RFC's 2008
>> and 2050 and is need based. If one region has greater needs than
>> another, the current policy of IANA does not require equal distribution
>> to all RIR's s. This proposed policy would establish a different
>> political and not needs based method for allocating returned space. It
>> would make each RIR an equal recipient of such space. But the level of
>> need and economic activity between each RI R is not equal. This policy
>> will tend to reallocate returned space away from where it is recovered,
>> in the ARIN region , and move more of it to AFRINIC and LACNIC than
>> current distribution principles. By equating the smaller economies and
>> related needs of certain regions to the needs of other regions, like
>> ARIN, that have greater day to day need, it in effect creates a new
>> political order of distribution thru equal shares. It is possible
>> sovereign governments in the regions with greater activity will not
>> agree to such a revised distribution model. The proposed policy
>> undermines the legal rationale for distribution.
>>
>> The policy also creates a powerful disincentive for any RIR, including
>> ARIN, to undertake any financial expenditure of RIR dollars for programs
>> intended to obtain returned space for reallocation. Currently ARIN is
>> working towards policies such as the LRSA and 2008-6, intended to
>> encourage returns and use of under utilized resources, but which cost
>> ARIN expenditures other RIRs are not duplicating. Any policy which
>> creates such a disincentive by leaving expenditures with a single RIR,
>> who cannot benefit except to receive 20% of the returned space should be
>> carefully considered.
>>
>> Finally, it is likely entities with number resources in the ARIN region
>> may be willing to return those resources for uses in the region but
>> unwilling to do so if 4/5 of such resources will be sent to other regions.
>>
>> III. Resource Impact
>>
>> The resource impact of implementing this policy is viewed as minimal. It
>> is estimated that this policy could require up to 3 person months of
>> effort to implement following ratification by the ARIN Board of
>> Trustees. Because this implementation is not planned, it may preempt
>> ARIN?s current project deployment schedule. It may require the following:
>>
>> * Modifications to existing registration procedures to include the
>>   handling of returned/reclaimed address space and the process of
>>   requesting additional address space from the IANA.
>> * Staff training
>>
>> Text assessed:
>>
>> *Allocation of IPv4 Blocks to Regional Internet Registries (Global)*
>>
>> *Policy statement:*
>>
>> This document describes the policy governing the allocation of IPv4
>> address space from the IANA to the Regional Internet Registries (RIRs).
>> This document does not stipulate performance requirements in the
>> provision of services by IANA to an RIR in accordance with this policy.
>> Such requirements should be specified by appropriate agreements among
>> the RIRs and ICANN.
>>
>> This policy is to be implemented in two phases.
>>
>> A. Phase I: Recovery of IPv4 Address Space
>>
>> Upon ratification of this policy by the ICANN Board of Directors the
>> IANA shall establish a mechanism to receive IPv4 address space which is
>> returned to it by the RIRs, and hold that address space in a 'recovered
>> IPv4 pool'.
>>
>> Each RIR through their respective chosen policies and strategies may
>> recover IPv4 address space which is under their administration. At
>> quarterly intervals, each RIR shall return any legacy address space
>> recovered, and may return any non-legacy address space recovered, to the
>> IANA in aggregated blocks of /24 or larger, for inclusion in the
>> recovered IPv4 pool.
>>
>> During Phase I, no allocations will be made from the recovered IPv4
>> pool. Return of recovered address space (as described above) will
>> continue throughout Phase II.
>>
>> B. Phase II: Allocation of Recovered IPv4 address space by the IANA
>>
>> Upon ratification of this policy by the ICANN Board of Directors and a
>> declaration by the IANA that its existing free pool of unallocated IPv4
>> address space is depleted; Global Addressing Policy ASO-001-2 (adopted
>> by ICANN Board 8 April 2005) is rescinded. IANA will then commence to
>> allocate the IPv4 address space from the recovered IPv4 pool.
>>
>> 1. The following definitions apply to this policy:
>>
>> a. Recovered Address Space. Recovered address space is that address
>> space that is returned to an RIR as a result of any activity that seeks
>> to reclaim unused address space or is voluntarily returned to the RIR or
>> is reclaimed by the RIR as a result of legal action or abuse
>> determination. Recovered address space does not include that address
>> space that is reclaimed because of non-payment of contractual fees whose
>> reclamation date is less than 1 year at the time of the report.
>>
>> b. IPv4 Address Holdings. IPv4 address holdings are all unallocated IPv4
>> address space held by an RIR to include recovered address space not yet
>> returned less that address space that is committed in accordance with
>> the RIR's reservation policy and practices.
>>
>> c. Legacy address space. IPv4 address space allocated or assigned prior
>> to the creation of the RIR.
>>
>> 2. Allocation of IPv4 Address Space
>>
>> a. For the purposes of this policy, an 'IPv4 allocation period' is
>> defined as a 6-month period following 1 March or 1 September in each year.
>>
>> b. At the beginning of each IPv4 allocation period, the IANA will
>> determine the 'IPv4 allocation unit' for that period, as 1/10 of its
>> IPv4 address pool, rounded down to the next CIDR (power-of-2) boundary.
>>
>> c. In each allocation period, each RIR may issue one IPv4 request to the
>> IANA. Providing that the RIR satisfies the allocation criteria described
>> in paragraph B.2, the IANA will allocate a single allocation unit,
>> composed of the smallest possible number of blocks available in its IPv4
>> address pool.
>>
>> 3. IPv4 Address Space Allocation Criteria
>>
>> A RIR is eligible to receive additional IPv4 address space from the IANA
>> when the total of its IPv4 address holdings is less than 50% of the
>> current IPv4 allocation unit, and providing that it has not already
>> received an IPv4 allocation from the IANA during the current IPv4
>> allocation period.
>>
>> 4. Initial Allocation of IPv4 Address Space
>>
>> Each new RIR shall, at the moment of recognition, be allocated one (1)
>> allocation unit by the IANA. If an allocation unit is not available,
>> then the IANA will issue this block as soon as one is available. This
>> allocation will be made regardless of the newly formed RIR's projected
>> utilization figures and shall be independent of the IPv4 address space
>> that may have been transferred to the new RIR by the already existing
>> RIRs as part of the formal transition process.
>>
>> 5. Reporting
>>
>> a. All returned space is to be recorded in an IANA-published log of IPv4
>> address space transactions, with each log entry detailing the returned
>> address block, the date of the return, and the returning RIR.
>>
>> b. All allocated space is also to be recorded in this IANA-published log
>> of IPv4 address space transactions, with each log entry detailing the
>> address blocks, the date of the allocation and the recipient RIR.
>>
>> c. The IANA will maintain a public registry of the current disposition
>> of all IPv4 address space, detailing all reservations and current
>> allocations and current IANA-held address space that is unallocated.
>>
>> d) The IANA may make public announcements of IPv4 address block
>> transactions that occur under this policy. The IANA will make
>> appropriate modifications to the "Internet Protocol V4 Address Space"
>> page of the IANA website and may make announcements to its own
>> appropriate announcement lists. The IANA announcements will be limited
>> to which address ranges, the time of allocation and to which Registry
>> they have been allocated.
>>
>>
>>
>>
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
>>
>>
>>   
>>     
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>   


From BillD at cait.wustl.edu  Mon Mar 30 15:39:50 2009
From: BillD at cait.wustl.edu (Bill Darte)
Date: Mon, 30 Mar 2009 14:39:50 -0500
Subject: [arin-ppml] clarification of Board actions Feb 2 and Mar 18,
	2009
In-Reply-To: <75822E125BCB994F8446858C4B19F0D76BEA10BE@SUEX07-MBX-04.ad.syr.edu>
References: <376189.27706.qm@web63303.mail.re1.yahoo.com><3c3e3fca0903301020sece2869scfb385ce6fcd4fb7@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D76BEA10BE@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D030878AB2C7@ex1.cait.wustl.edu>

As the presenter of 2008-6 in LA and author of the original version of
the proposal.

I can say definitively that the proposal expected that the Board of
Trustees of ARIN would exercise their judgement over the criticality of
shortage of v4 addresses in the future which would impact the ability of
ARIN to continue business as usual.  They would then implement the
policy (if it hadn't been updated or obsoleted by other policy or
circumstance) and begin to accept enduser transfers that met current
ARIN need requirements.  The word emergency was place in the title and
explained by stating the policy's intent to provide a short term
response to a shortage of v4 addresses before v6 was sufficently viable
or well established to meet most everyone's needs. 

Bill Darte
ARIN Advisory Council

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Milton L Mueller
> Sent: Monday, March 30, 2009 1:04 PM
> To: 'William Herrin'; Lee Howard
> Cc: ppml at arin.net
> Subject: Re: [arin-ppml] clarification of Board actions Feb 2 
> and Mar 18,2009
> 
> > -----Original Message-----
> > 
> > I'm not aware of of any text in 2008-6 which required or even 
> > recommended that the board declare an emergency in order to 
> activate 
> > it. My understanding of 2008-6 was that it was to be active upon 
> > finding of consensus and ratification by the board. The word 
> > "emergency" in the title was a no-op; it's presence in a proposal 
> > title has no defined meaning within the published PDP. It only 
> > reflected the author's view that creating a transfer policy was 
> > important.
> 
> So you are claiming that a policy that had the word 
> "emergency" in the title both 1. had broad consensus and 2. 
> represented no agreement that anything approximating an 
> emergency was involved. 
> 
> interesting interpretation. 
> 
> > I supported 2008-6. I disapproved of the use of the word "emergency"
> > in the title and would have opposed the policy had I 
> believed the word 
> > to be anything more than a no-op. I doubt I'm the only one in this 
> > position.
> 
> apparently all those others, like you, failed to make this 
> clear in the discussion of the policy 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 


From cgrundemann at gmail.com  Mon Mar 30 15:54:29 2009
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Mon, 30 Mar 2009 13:54:29 -0600
Subject: [arin-ppml]
	=?windows-1252?q?Draft_Policy_2008-7=3A_Identify_Inva?=
	=?windows-1252?q?lid_WHOIS_POC=92s?=
In-Reply-To: <49C7DD6E.3010106@arin.net>
References: <49C7DD6E.3010106@arin.net>
Message-ID: <443de7ad0903301254p14d69273tb784c27718fb2a20@mail.gmail.com>

On Mon, Mar 23, 2009 at 13:05, Member Services <info at arin.net> wrote:
> SUBJECT: Draft Policy 2008-7: Identify Invalid WHOIS POC?s
>
> Draft Policy 2008-7
> Identify Invalid WHOIS POC?s
>
> The following draft policy text is being posted for feedback and
> discussion on the Public Policy Mailing List (PPML).
>
> After the October 2008 Public Policy Meeting the ARIN Advisory Council
> (AC) decided that 2008-7 required more work. The text below was
> developed by the AC with help from the proposal originators. The AC was
> required to submit text to ARIN for staff and legal assessment prior to
> selecting it as a draft policy. The assessment, along with the text that
> was assessed, is located below the draft policy.
>
> On 20 March 2009 the ARIN Advisory Council (AC) selected Draft Policy
> 2008-7: Identify Invalid WHOIS POC?s (formally known as WHOIS Integrity
> Policy Proposal) for adoption discussion on the PPML and at the upcoming
> Public Policy Meeting.
>
> Draft Policy 2008-7 is below and can be found at:
> https://www.arin.net/policy/proposals/2008_7.html
>
> We encourage you to discuss Draft Policy 2008-7 on PPML prior to the
> ARIN XXIII Public Policy Meeting. Both the discussion on the PPML and at
> the Public Policy Meeting will be used by the ARIN Advisory Council to
> determine the community consensus regarding adopting this as policy.
>
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
>
> All of the Draft Policies under discussion can be found at:
> https://www.arin.net/policy/proposals/index.html
>
> Regards,
>
> Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Draft Policy 2008-7
> Identify Invalid WHOIS POC?s
>
> Date: 23 March 2009
>
> Policy Statement:
>
> During ARINs annual WHOIS POC validation, an e-mail will be sent to
> every POC in the WHOIS database. Each POC will have a maximum of 60 days
> to respond with an affirmative that their WHOIS contact information is
> correct and complete. Unresponsive POC email addresses shall be marked
> as such in the database. If ARIN staff deems a POC to be completely and
> permanently abandoned or otherwise illegitimate, the record shall be
> deleted. ARIN will maintain, and make readily available to the
> community, a current list of address-blocks with no valid POC; this data
> will be subject to the current bulk WHOIS policy.
>
> Timetable for implementation: Immediate
>
>
> #####
>
> ARIN Staff Assessment
>
> 2008-7
>
> Title: ?Identify Invalid WHOIS POC's (formerly known as WHOIS Integrity
> Policy Proposal)
>
> Revision Submitted: 07 March 2008
>
> 2nd Revision Submitted: 12 Feb 2009
>
> Date of Assessment: ?24 Feb 2009
>
> The assessment of this text includes comments from ARIN staff and the
> ARIN General Counsel. It contains analysis of procedural, legal, and
> resource concerns regarding the implementation of this text as it is
> currently stated. Any changes to the language may necessitate further
> analysis by staff and Counsel.
>
> I. ?Understanding
>
> ARIN staff understands that this will institute an annual
> re-registration of all POCs registered in WHOIS. ?POCs who do not
> respond within 60 days will be marked in the database as "un-responsive"
> and if staff deems them to be invalid for any reason, may remove them
> from WHOIS. ?In addition, staff will maintain a list of all address
> blocks with no valid POCs and will make this data available to any
> organization using the bulk whois policy criteria.
>
> II. ?Issues and Concerns
>
> ?A. ?ARIN Staff Comments:
>
> ? ?* Resource records marked as ?unresponsive? or those with no POCs at
> ? ? ?all could become the targets of hijackers who, in the past have
> ? ? ?tended to look for address blocks that contain obsolete or stale data.

This is exactly why I (and I believe the other authors of this
proposed policy) wanted the discloser to be required.  Hijackers, like
spammers, phishers and other criminals spend their time finding this
kind of data -- the idea of this portion of this policy is to give
everyone the data that we can assume hijackers (probably) already
have.  This public disclosure of netblocks with out any valid POCs
will hopefully encourage the rightful holders of those blocks to
update their POC info and if not, it at least allows the rest of the
community to be mindful of such blocks.

> ? ?* ?An annual re-registration of all POCs (~223,000 currently) will
> ? ? ?likely result in a vast increase in workload, particularly with
> ? ? ?the follow up work and research involved when a POC does not reply
> ? ? ?within 60 days. ?This could result in a slow down in registration
> ? ? ?response and processing times.

This proposal does not require a "re-registration of all POCs"
annually.  It requires an email validation of all POCs annually and
that POCs which do not respond to email have their record marked as
such -- this is meant to be an entirely automated process.  The policy
then grants ARIN staff the discretion to do follow up work and
research on POCs; it does not require that ARIN follow up on every (or
even any) unresponsive POC every year -- it is meant to allow staff to
follow up where they can/need and give them authority to lock or
remove POCs that are found to be completely illegitimate (those that
don't respond to repeated and various contact attempts, etc).

> ? ?* This policy refers to the Bulk Whois policy rather than stating
> ? ? ?the actual criteria under which an organization will be allowed to
> ? ? ?request the list of all address blocks with no valid POCs. ?It
> ? ? ?would be better policy text to state the specific criteria,
> ? ? ?including the requirement to sign an AUP, within this policy itself.
>

"ARIN will maintain, and make readily available to the community, a
current list of address-blocks with no valid POC; this data will be
subject to the current bulk WHOIS policy."

My understanding of this text is that the list of address blocks with
no valid POCs should be available to anyone interested in it.    We
chose to reference the Bulk WHOIS policy instead of re-stating it here
so as to maintain a central policy regarding WHOIS data.  It seems to
me that when we get away from this and start repeating things we open
the door for conflicting policy down the road when one area is updated
but another repetitive area is not...   Beyond that, we again tried to
leave operational details to staff.

~Chris

>
>
> ?B. ?ARIN General Counsel
>
> ? ?* It is possible those delisted will threaten or file litigation to
> ? ? ?be relisted. However, a properly promulgated policy does not pose
> ? ? ?antirust or other legal concerns.
>
>
>
> III. Resource Impact
>
> The resource impact of implementing this policy is viewed as
> significant. Barring any unforeseen resource requirements, it is
> estimated that this policy could take up to 18 person months to fully
> implement from the date of ratification of the policy by the ARIN Board
> of Trustees. ?It may require the following:
>
> ? ?* Staff training
> ? ?* Development of new internal process and procedures and
> ? ? ?modification to existing ones
> ? ?* Creation of an automated system to track notifications, updates,
> ? ? ?and current status of the POC notification. Provide allowances for
> ? ? ?manual intervention and follow-up by staff. ?Engineering estimates
> ? ? ?that it could take up to 18 person months for the creation and
> ? ? ?implementation of this system. In addition, this could impact
> ? ? ?ARIN?s current project deployment schedule.
> ? ?* Increased workload could result in the need for additional staff
>
>
>
> Text assessed:
>
> 2008-7: Identify Invalid WHOIS POC's (formally known as WHOIS Integrity
> Policy Proposal)
>
> Revised text is as follows:
>
> During ARINs annual WHOIS POC validation, an e-mail will be sent to
> every POC in the WHOIS database. Each POC will have a maximum of 60 days
> to respond with an affirmative that their WHOIS contact information is
> correct and complete. Unresponsive POC email addresses shall be marked
> as such in the database. If ARIN staff deems a POC to be completely and
> permanently abandoned or otherwise illegitimate, the record shall be
> deleted. ARIN will maintain, and make readily available to the
> community, a current list of address-blocks with no valid POC; this data
> will be subject to the current bulk WHOIS policy.
>
>
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>

-- 
Chris Grundemann
weblog.chrisgrundemann.com


From raul at lacnic.net  Mon Mar 30 15:58:00 2009
From: raul at lacnic.net (Raul Echeberria)
Date: Mon, 30 Mar 2009 16:58:00 -0300
Subject: [arin-ppml] Draft Policy 2009-3 (Global): Allocation of IPv4
	Blocks to Regional Internet Registries
In-Reply-To: <49D11F48.6090905@gmail.com>
References: <37137.208.54.95.48.1238379940.squirrel@webmail.lacnic.net.uy>
	<49D10949.9000803@arin.net> <49D11F48.6090905@gmail.com>
Message-ID: <9EDA9B03-C069-44B5-B06D-D60E510849FE@lacnic.net>


Thanks,

Ra?l



El 30/03/2009, a las 04:36 p.m., Scott Leibrand escribi?:

> Raul,
>
> Given that it's too late to initiate a separate discussion petition  
> for the San Antonio meeting, I would like to assure you that I will  
> do what I can to make sure that we get feedback from the community  
> at that meeting as to the support for the original proposed text, as  
> well as for the revised version.  If there is a clear community  
> consensus in favor of either language, my own personal opinion is  
> that we'll be able to move the proposal forward, with any applicable  
> edits, at that point.
>
> In order to prepare for such discussion, I'd welcome feedback from  
> the PPML on the following questions:
>
> - Do you support the original proposed text of 2009-3, requiring  
> return of any reclaimed space to IANA for redistribution?  Why or  
> why not?
> - Do you support the current modified text of 2009-3, requiring  
> return of any reclaimed legacy space, but making optional the return  
> of any non-legacy space?  Why or why not?
> - Would you support some other revised version of 2009-3?  If so,  
> what would you want to change?  (For example, we could make all  
> returns optional, for both legacy and non-legacy space.)
> - If you oppose 2009-3 completely, do you believe that current  
> policy is adequate, or would you support some other mechanism to  
> allow for the reallocation of IPv4 blocks between RIRs?
>
> Thanks,
> Scott
>
> Member Services wrote:
>> Raul,
>>
>> According to the ARIN Policy Development Process the petition  
>> period for
>> the upcoming San Antonio meeting closed on 13 March 2009. The  
>> deadline
>> information was posted to PPML earlier this month, see the post:
>> http://lists.arin.net/pipermail/arin-ppml/2009-March/013106.html
>>
>> The draft policy is under discussion, statements of support and
>> opposition are welcome and appreciated. Both the discussion on the  
>> PPML
>> and at the Public Policy Meeting will be used by the AC to  
>> determine the
>> community consensus regarding adopting this as policy.
>>
>> The ARIN Policy Development Process can be found at:
>> https://www.arin.net/policy/pdp.html
>>
>> Regards,
>>
>> Member Services
>> American Registry for Internet Numbers (ARIN)
>>
>> raul at lacnic.net wrote:
>>
>>> Dear all:
>>>
>>> This proposal is a proposal for a global policy. It means that the  
>>> same
>>> proposal has to be approved in every region. They can be approved  
>>> with
>>> some wording differences, but the spirit of the proposal should be  
>>> the
>>> same.
>>>
>>> The proposal was the result of a long collaboration effort of  
>>> senior staff
>>> members and board members of all the 5 RIRs and the original text  
>>> is the
>>> one that is being considered in every region.
>>>
>>> As far as I know the authors of the proposal were not consulted by  
>>> the
>>> ARIN-AC and based on exchanges among the authors in the past few  
>>> days, I
>>> can say that in general the feeling is that the changes introduced  
>>> by the
>>> ARIN-AC are very signficant and so, this is a different proposal.
>>>
>>> My personal view is that changing the concept of a global policy  
>>> proposal
>>> in one RIR means to avoid the approval of the policy. I strongly  
>>> encourage
>>> ARIN to put the original proposal under consideration of its  
>>> community as
>>> it is being done in the other regions. The proposal can be  
>>> approved or
>>> not, That's part of the process, but it doesn't make sense to  
>>> approve a
>>> different proposal. IMHO, the AC is able to put forward the new  
>>> proposal
>>> for discussion if they consider that it is better, and in that way  
>>> to
>>> start the process of discussion of a new global policy proposal.
>>>
>>> I have to confess that dealing with 5 different PDPs is not so  
>>> easy. I
>>> don't know if a petition process should be started, If yes, please  
>>> take
>>> this email as the request for initiating that process.
>>>
>>> Since this announcement was issued last Monday in the afternoon, I  
>>> am not
>>> sure how the business days are counted, but I guess that I am  
>>> still within
>>> the valid period.
>>>
>>> However, I think that as a practices, global policy proposals  
>>> should not
>>> be changed by any advisory council or policy chair of one region  
>>> due to
>>> the impact that to change the proposal produce in the global  
>>> process.
>>>
>>>
>>> Best Regards,
>>>
>>> Ra?l
>>>
>>>
>>>
>>> ---------------
>>>
>>>
>>>
>>> El 23/03/2009, a las 04:05 p.m., Member Services escribi?:
>>>
>>> Draft Policy 2009-3 (Global)
>>> Allocation of IPv4 Blocks to Regional Internet Registries
>>>
>>> The following draft policy text is being posted for feedback and
>>> discussion on the Public Policy Mailing List (PPML).
>>>
>>> This draft policy was developed by the ARIN Advisory Council (AC)  
>>> from
>>> Policy Proposal 82: Allocation of IPv4 Blocks to Regional Internet
>>> Registries. The AC has taken the proposal and developed it into a  
>>> draft
>>> policy. The AC was required to submit text to ARIN for staff and  
>>> legal
>>> assessment prior to selecting it as a draft policy. The assessment,
>>> along with the text that was assessed, is located below the draft  
>>> policy.
>>>
>>> On 20 March 2009 the ARIN Advisory Council (AC) selected Draft  
>>> Policy
>>> 2009-3: Allocation of IPv4 Blocks to Regional Internet Registries  
>>> for
>>> adoption discussion on the PPML and at the upcoming Public Policy  
>>> Meeting.
>>>
>>> Draft Policy 2009-3 is below and can be found at:
>>> https://www.arin.net/policy/proposals/2009_3.html
>>>
>>> We encourage you to discuss Draft Policy 2009-3 on the PPML prior  
>>> to the
>>> ARIN XXIII Public Policy Meeting. Both the discussion on the PPML  
>>> and at
>>> the Public Policy Meeting will be used by the AC to determine the
>>> community consensus regarding adopting this as policy.
>>>
>>> The ARIN Policy Development Process can be found at:
>>> https://www.arin.net/policy/pdp.html
>>>
>>> All of the Draft Policies under discussion can be found at:
>>> https://www.arin.net/policy/proposals/index.html
>>>
>>> Regards,
>>>
>>> Member Services
>>> American Registry for Internet Numbers (ARIN)
>>>
>>>
>>> ## * ##
>>>
>>>
>>> Draft Policy 2009-3 (Global)
>>> Allocation of IPv4 Blocks to Regional Internet Registries
>>>
>>> Date: 23 March 2009
>>>
>>> Policy statement:
>>>
>>> This document describes the policy governing the allocation of IPv4
>>> address space from the IANA to the Regional Internet Registries  
>>> (RIRs).
>>> This document does not stipulate performance requirements in the
>>> provision of services by IANA to an RIR in accordance with this  
>>> policy.
>>> Such requirements should be specified by appropriate agreements  
>>> among
>>> the RIRs and ICANN.
>>>
>>> This policy is to be implemented in two phases.
>>>
>>> A. Phase I: Recovery of IPv4 Address Space
>>>
>>> Upon ratification of this policy by the ICANN Board of Directors the
>>> IANA shall establish a mechanism to receive IPv4 address space  
>>> which is
>>> returned to it by the RIRs, and hold that address space in a  
>>> 'recovered
>>> IPv4 pool'.
>>>
>>> Each RIR through their respective chosen policies and strategies may
>>> recover IPv4 address space which is under their administration. At
>>> quarterly intervals, each RIR shall return to the IANA any legacy
>>> address space recovered, and may return to the IANA any non-legacy
>>> address space recovered, in aggregated blocks of /24 or larger, for
>>> inclusion in the recovered IPv4 pool.
>>>
>>> During Phase I, no allocations will be made from the recovered IPv4
>>> pool. Return of recovered address space (as described above) will
>>> continue throughout Phase II.
>>>
>>> B. Phase II: Allocation of Recovered IPv4 address space by the IANA
>>>
>>> Upon ratification of this policy by the ICANN Board of Directors  
>>> and a
>>> declaration by the IANA that its existing free pool of unallocated  
>>> IPv4
>>> address space is depleted; Global Addressing Policy ASO-001-2  
>>> (adopted
>>> by ICANN Board 8 April 2005) is rescinded. IANA will then commence  
>>> to
>>> allocate the IPv4 address space from the recovered IPv4 pool.
>>>
>>> 1. The following definitions apply to this policy:
>>>
>>> a. Recovered Address Space. Recovered address space is that address
>>> space that is returned to an RIR as a result of any activity that  
>>> seeks
>>> to reclaim unused address space or is voluntarily returned to the  
>>> RIR or
>>> is reclaimed by the RIR as a result of legal action or abuse
>>> determination. Recovered address space does not include that address
>>> space that is reclaimed because of non-payment of contractual fees  
>>> whose
>>> reclamation date is less than 1 year at the time of the report.
>>>
>>> b. IPv4 Address Holdings. IPv4 address holdings are all  
>>> unallocated IPv4
>>> address space held by an RIR to include recovered address space  
>>> not yet
>>> returned less that address space that is committed in accordance  
>>> with
>>> the RIR's reservation policy and practices.
>>>
>>> c. Aggregated address blocks. Aggregated address blocks are  
>>> contiguous
>>> prefixes that can be aggregated on natural bit boundaries.  
>>> 10.0.0.0/24
>>> and 10.0.1.0/24 are two contiguous prefixes that can be combined  
>>> to form
>>> an aggregated address block. 10.0.0.0/24 and 10.0.1.0/25 are two
>>> contiguous prefixes that cannot be combined on a natural bit  
>>> boundary to
>>> form an aggregated block.
>>>
>>> d. Legacy address space. IPv4 address space allocated or assigned  
>>> prior
>>> to the creation of the RIR.
>>>
>>> 2. Allocation of IPv4 Address Space
>>>
>>> a. For the purposes of this policy, an 'IPv4 allocation period' is
>>> defined as a 6-month period following 1 March or 1 September in  
>>> each year.
>>>
>>> b. At the beginning of each IPv4 allocation period, the IANA will
>>> determine the 'IPv4 allocation unit' for that period, as 1/10 of its
>>> IPv4 address pool, rounded down to the next CIDR (power-of-2)  
>>> boundary.
>>> The minimum 'IPv4 allocation unit' size will be a /24.
>>>
>>> c. In each allocation period, each RIR may issue one IPv4 request  
>>> to the
>>> IANA. Providing that the RIR satisfies the allocation criteria  
>>> described
>>> in paragraph B.2, the IANA will allocate a single allocation unit,
>>> composed of the smallest possible number of blocks available in  
>>> its IPv4
>>> address pool.
>>>
>>> 3. IPv4 Address Space Allocation Criteria
>>>
>>> A RIR is eligible to receive additional IPv4 address space from  
>>> the IANA
>>> when the total of its IPv4 address holdings is less than 50% of the
>>> current IPv4 allocation unit, and providing that it has not already
>>> received an IPv4 allocation from the IANA during the current IPv4
>>> allocation period.
>>>
>>> 4. Initial Allocation of IPv4 Address Space
>>>
>>> Each new RIR shall, at the moment of recognition, be allocated one  
>>> (1)
>>> allocation unit by the IANA. If an allocation unit is not available,
>>> then the IANA will issue this block as soon as one is available.  
>>> This
>>> allocation will be made regardless of the newly formed RIR's  
>>> projected
>>> utilization figures and shall be independent of the IPv4 address  
>>> space
>>> that may have been transferred to the new RIR by the already  
>>> existing
>>> RIRs as part of the formal transition process.
>>>
>>> 5. Reporting
>>>
>>> a. All returned space is to be recorded in an IANA-published log  
>>> of IPv4
>>> address space transactions, with each log entry detailing the  
>>> returned
>>> address block, the date of the return, and the returning RIR.
>>>
>>> b. All allocated space is also to be recorded in this IANA- 
>>> published log
>>> of IPv4 address space transactions, with each log entry detailing  
>>> the
>>> address blocks, the date of the allocation and the recipient RIR.
>>>
>>> c. The IANA will maintain a public registry of the current  
>>> disposition
>>> of all IPv4 address space, detailing all reservations and current
>>> allocations and current IANA-held address space that is unallocated.
>>>
>>> d) The IANA may make public announcements of IPv4 address block
>>> transactions that occur under this policy. The IANA will make
>>> appropriate modifications to the "Internet Protocol V4 Address  
>>> Space"
>>> page of the IANA website and may make announcements to its own
>>> appropriate announcement lists. The IANA announcements will be  
>>> limited
>>> to which address ranges, the time of allocation and to which  
>>> Registry
>>> they have been allocated.
>>>
>>>
>>>
>>> #####
>>>
>>> ARIN Staff Assessment
>>>
>>> *Title: Allocation of IPv4 Blocks to the Regional Internet  
>>> Registries*
>>>
>>> *Proposal Submitted: 30 Jan 2009*
>>>
>>> *Revision Submitted: 05 March 2009*
>>>
>>> *Date of Assessment: 10 March 2009*
>>>
>>> * *
>>>
>>> I. Understanding of the Policy:
>>>
>>> *Staff Understanding of the Proposal:*
>>>
>>> Staff understands that this proposal would be implemented in 2  
>>> phases.
>>> Phase 1 would require the RIRs to return recovered IPv4 legacy  
>>> address
>>> space (via policy or procedure) to the IANA and have the option of
>>> returning recovered non-legacy address space to the IANA. Phase 2  
>>> would
>>> start after the depletion of the IANA free pool and would nullify  
>>> the
>>> existing IANA to RIR policy (Global Addressing Policy ASO-001-2).  
>>> The
>>> new IANA to RIR policy would allow each RIR to receive approximately
>>> 1/10th of the recovered IPv4 pool from IANA once every 6 months as  
>>> long
>>> as it meets the qualification criteria written in paragraph B2. IANA
>>> will be required to keep a log of all returned IPv4 address space  
>>> and
>>> all issued IPv4 address space from the recovered pool, as well as
>>> maintain a public registry of the current disposition of all IPv4
>>> address space.
>>>
>>> II. Comments
>>>
>>> A. ARIN Staff Comments
>>>
>>> * The one policy that this impacts is NRPM 4.6 Amnesty and
>>>  Aggregation, which says ?Transactions should only be accepted
>>>  under this policy if they are in the interests of the community
>>>  (e.g. they improve aggregation or result in a net reclamation of
>>>  space).? Because the ARIN region holds the majority of the legacy
>>>  address space, and most of the address space returned under this
>>>  policy is legacy space, it would mean that there would be no ?net
>>>  return? of address space to ARIN. ARIN would essentially be
>>>  exchanging legacy address space for non-legacy address space, and
>>>  returning the legacy address space it received in the exchange to
>>>  IANA, resulting in a net loss of address space in ARIN?s available
>>>  pool.
>>>
>>> B. ARIN General Counsel Comments:
>>>
>>> The current basis of allocation of numbers was established in  
>>> RFC's 2008
>>> and 2050 and is need based. If one region has greater needs than
>>> another, the current policy of IANA does not require equal  
>>> distribution
>>> to all RIR's s. This proposed policy would establish a different
>>> political and not needs based method for allocating returned  
>>> space. It
>>> would make each RIR an equal recipient of such space. But the  
>>> level of
>>> need and economic activity between each RI R is not equal. This  
>>> policy
>>> will tend to reallocate returned space away from where it is  
>>> recovered,
>>> in the ARIN region , and move more of it to AFRINIC and LACNIC than
>>> current distribution principles. By equating the smaller economies  
>>> and
>>> related needs of certain regions to the needs of other regions, like
>>> ARIN, that have greater day to day need, it in effect creates a new
>>> political order of distribution thru equal shares. It is possible
>>> sovereign governments in the regions with greater activity will not
>>> agree to such a revised distribution model. The proposed policy
>>> undermines the legal rationale for distribution.
>>>
>>> The policy also creates a powerful disincentive for any RIR,  
>>> including
>>> ARIN, to undertake any financial expenditure of RIR dollars for  
>>> programs
>>> intended to obtain returned space for reallocation. Currently ARIN  
>>> is
>>> working towards policies such as the LRSA and 2008-6, intended to
>>> encourage returns and use of under utilized resources, but which  
>>> cost
>>> ARIN expenditures other RIRs are not duplicating. Any policy which
>>> creates such a disincentive by leaving expenditures with a single  
>>> RIR,
>>> who cannot benefit except to receive 20% of the returned space  
>>> should be
>>> carefully considered.
>>>
>>> Finally, it is likely entities with number resources in the ARIN  
>>> region
>>> may be willing to return those resources for uses in the region but
>>> unwilling to do so if 4/5 of such resources will be sent to other  
>>> regions.
>>>
>>> III. Resource Impact
>>>
>>> The resource impact of implementing this policy is viewed as  
>>> minimal. It
>>> is estimated that this policy could require up to 3 person months of
>>> effort to implement following ratification by the ARIN Board of
>>> Trustees. Because this implementation is not planned, it may preempt
>>> ARIN?s current project deployment schedule. It may require the  
>>> following:
>>>
>>> * Modifications to existing registration procedures to include the
>>>  handling of returned/reclaimed address space and the process of
>>>  requesting additional address space from the IANA.
>>> * Staff training
>>>
>>> Text assessed:
>>>
>>> *Allocation of IPv4 Blocks to Regional Internet Registries (Global)*
>>>
>>> *Policy statement:*
>>>
>>> This document describes the policy governing the allocation of IPv4
>>> address space from the IANA to the Regional Internet Registries  
>>> (RIRs).
>>> This document does not stipulate performance requirements in the
>>> provision of services by IANA to an RIR in accordance with this  
>>> policy.
>>> Such requirements should be specified by appropriate agreements  
>>> among
>>> the RIRs and ICANN.
>>>
>>> This policy is to be implemented in two phases.
>>>
>>> A. Phase I: Recovery of IPv4 Address Space
>>>
>>> Upon ratification of this policy by the ICANN Board of Directors the
>>> IANA shall establish a mechanism to receive IPv4 address space  
>>> which is
>>> returned to it by the RIRs, and hold that address space in a  
>>> 'recovered
>>> IPv4 pool'.
>>>
>>> Each RIR through their respective chosen policies and strategies may
>>> recover IPv4 address space which is under their administration. At
>>> quarterly intervals, each RIR shall return any legacy address space
>>> recovered, and may return any non-legacy address space recovered,  
>>> to the
>>> IANA in aggregated blocks of /24 or larger, for inclusion in the
>>> recovered IPv4 pool.
>>>
>>> During Phase I, no allocations will be made from the recovered IPv4
>>> pool. Return of recovered address space (as described above) will
>>> continue throughout Phase II.
>>>
>>> B. Phase II: Allocation of Recovered IPv4 address space by the IANA
>>>
>>> Upon ratification of this policy by the ICANN Board of Directors  
>>> and a
>>> declaration by the IANA that its existing free pool of unallocated  
>>> IPv4
>>> address space is depleted; Global Addressing Policy ASO-001-2  
>>> (adopted
>>> by ICANN Board 8 April 2005) is rescinded. IANA will then commence  
>>> to
>>> allocate the IPv4 address space from the recovered IPv4 pool.
>>>
>>> 1. The following definitions apply to this policy:
>>>
>>> a. Recovered Address Space. Recovered address space is that address
>>> space that is returned to an RIR as a result of any activity that  
>>> seeks
>>> to reclaim unused address space or is voluntarily returned to the  
>>> RIR or
>>> is reclaimed by the RIR as a result of legal action or abuse
>>> determination. Recovered address space does not include that address
>>> space that is reclaimed because of non-payment of contractual fees  
>>> whose
>>> reclamation date is less than 1 year at the time of the report.
>>>
>>> b. IPv4 Address Holdings. IPv4 address holdings are all  
>>> unallocated IPv4
>>> address space held by an RIR to include recovered address space  
>>> not yet
>>> returned less that address space that is committed in accordance  
>>> with
>>> the RIR's reservation policy and practices.
>>>
>>> c. Legacy address space. IPv4 address space allocated or assigned  
>>> prior
>>> to the creation of the RIR.
>>>
>>> 2. Allocation of IPv4 Address Space
>>>
>>> a. For the purposes of this policy, an 'IPv4 allocation period' is
>>> defined as a 6-month period following 1 March or 1 September in  
>>> each year.
>>>
>>> b. At the beginning of each IPv4 allocation period, the IANA will
>>> determine the 'IPv4 allocation unit' for that period, as 1/10 of its
>>> IPv4 address pool, rounded down to the next CIDR (power-of-2)  
>>> boundary.
>>>
>>> c. In each allocation period, each RIR may issue one IPv4 request  
>>> to the
>>> IANA. Providing that the RIR satisfies the allocation criteria  
>>> described
>>> in paragraph B.2, the IANA will allocate a single allocation unit,
>>> composed of the smallest possible number of blocks available in  
>>> its IPv4
>>> address pool.
>>>
>>> 3. IPv4 Address Space Allocation Criteria
>>>
>>> A RIR is eligible to receive additional IPv4 address space from  
>>> the IANA
>>> when the total of its IPv4 address holdings is less than 50% of the
>>> current IPv4 allocation unit, and providing that it has not already
>>> received an IPv4 allocation from the IANA during the current IPv4
>>> allocation period.
>>>
>>> 4. Initial Allocation of IPv4 Address Space
>>>
>>> Each new RIR shall, at the moment of recognition, be allocated one  
>>> (1)
>>> allocation unit by the IANA. If an allocation unit is not available,
>>> then the IANA will issue this block as soon as one is available.  
>>> This
>>> allocation will be made regardless of the newly formed RIR's  
>>> projected
>>> utilization figures and shall be independent of the IPv4 address  
>>> space
>>> that may have been transferred to the new RIR by the already  
>>> existing
>>> RIRs as part of the formal transition process.
>>>
>>> 5. Reporting
>>>
>>> a. All returned space is to be recorded in an IANA-published log  
>>> of IPv4
>>> address space transactions, with each log entry detailing the  
>>> returned
>>> address block, the date of the return, and the returning RIR.
>>>
>>> b. All allocated space is also to be recorded in this IANA- 
>>> published log
>>> of IPv4 address space transactions, with each log entry detailing  
>>> the
>>> address blocks, the date of the allocation and the recipient RIR.
>>>
>>> c. The IANA will maintain a public registry of the current  
>>> disposition
>>> of all IPv4 address space, detailing all reservations and current
>>> allocations and current IANA-held address space that is unallocated.
>>>
>>> d) The IANA may make public announcements of IPv4 address block
>>> transactions that occur under this policy. The IANA will make
>>> appropriate modifications to the "Internet Protocol V4 Address  
>>> Space"
>>> page of the IANA website and may make announcements to its own
>>> appropriate announcement lists. The IANA announcements will be  
>>> limited
>>> to which address ranges, the time of allocation and to which  
>>> Registry
>>> they have been allocated.
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>



From martin.hannigan at batelnet.bs  Mon Mar 30 16:18:07 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Mon, 30 Mar 2009 13:18:07 -0700
Subject: [arin-ppml] Draft Policy 2009-3 (Global): Allocation of IPv4
	Blocks to Regional Internet Registries
In-Reply-To: <9EDA9B03-C069-44B5-B06D-D60E510849FE@lacnic.net>
References: <37137.208.54.95.48.1238379940.squirrel@webmail.lacnic.net.uy>
	<49D10949.9000803@arin.net> <49D11F48.6090905@gmail.com>
	<9EDA9B03-C069-44B5-B06D-D60E510849FE@lacnic.net>
Message-ID: <4607e1d50903301318y3c142303g42a991f6be79b0a6@mail.gmail.com>

Scott,

You indicated that there is no consensus with regards to this policy
advancing.  Why is this policy advancing at all then?  Regardless of
it being a global policy, there's no requirement to do anything other
than to run this policy through the process fairly. Failing to succeed
in that process is a sometimes expected result.

A perception may be starting to develop that this policy isn't being
treated equally with regards to other policies I.e. continuing to be
pushed for discussion without support.


Best,

Martin



On 3/30/09, Raul Echeberria <raul at lacnic.net> wrote:
>
> Thanks,
>
> Ra?l
>
>
>
> El 30/03/2009, a las 04:36 p.m., Scott Leibrand escribi?:
>
>> Raul,
>>
>> Given that it's too late to initiate a separate discussion petition
>> for the San Antonio meeting, I would like to assure you that I will
>> do what I can to make sure that we get feedback from the community
>> at that meeting as to the support for the original proposed text, as
>> well as for the revised version.  If there is a clear community
>> consensus in favor of either language, my own personal opinion is
>> that we'll be able to move the proposal forward, with any applicable
>> edits, at that point.
>>
>> In order to prepare for such discussion, I'd welcome feedback from
>> the PPML on the following questions:
>>
>> - Do you support the original proposed text of 2009-3, requiring
>> return of any reclaimed space to IANA for redistribution?  Why or
>> why not?
>> - Do you support the current modified text of 2009-3, requiring
>> return of any reclaimed legacy space, but making optional the return
>> of any non-legacy space?  Why or why not?
>> - Would you support some other revised version of 2009-3?  If so,
>> what would you want to change?  (For example, we could make all
>> returns optional, for both legacy and non-legacy space.)
>> - If you oppose 2009-3 completely, do you believe that current
>> policy is adequate, or would you support some other mechanism to
>> allow for the reallocation of IPv4 blocks between RIRs?
>>
>> Thanks,
>> Scott
>>
>> Member Services wrote:
>>> Raul,
>>>
>>> According to the ARIN Policy Development Process the petition
>>> period for
>>> the upcoming San Antonio meeting closed on 13 March 2009. The
>>> deadline
>>> information was posted to PPML earlier this month, see the post:
>>> http://lists.arin.net/pipermail/arin-ppml/2009-March/013106.html
>>>
>>> The draft policy is under discussion, statements of support and
>>> opposition are welcome and appreciated. Both the discussion on the
>>> PPML
>>> and at the Public Policy Meeting will be used by the AC to
>>> determine the
>>> community consensus regarding adopting this as policy.
>>>
>>> The ARIN Policy Development Process can be found at:
>>> https://www.arin.net/policy/pdp.html
>>>
>>> Regards,
>>>
>>> Member Services
>>> American Registry for Internet Numbers (ARIN)
>>>
>>> raul at lacnic.net wrote:
>>>
>>>> Dear all:
>>>>
>>>> This proposal is a proposal for a global policy. It means that the
>>>> same
>>>> proposal has to be approved in every region. They can be approved
>>>> with
>>>> some wording differences, but the spirit of the proposal should be
>>>> the
>>>> same.
>>>>
>>>> The proposal was the result of a long collaboration effort of
>>>> senior staff
>>>> members and board members of all the 5 RIRs and the original text
>>>> is the
>>>> one that is being considered in every region.
>>>>
>>>> As far as I know the authors of the proposal were not consulted by
>>>> the
>>>> ARIN-AC and based on exchanges among the authors in the past few
>>>> days, I
>>>> can say that in general the feeling is that the changes introduced
>>>> by the
>>>> ARIN-AC are very signficant and so, this is a different proposal.
>>>>
>>>> My personal view is that changing the concept of a global policy
>>>> proposal
>>>> in one RIR means to avoid the approval of the policy. I strongly
>>>> encourage
>>>> ARIN to put the original proposal under consideration of its
>>>> community as
>>>> it is being done in the other regions. The proposal can be
>>>> approved or
>>>> not, That's part of the process, but it doesn't make sense to
>>>> approve a
>>>> different proposal. IMHO, the AC is able to put forward the new
>>>> proposal
>>>> for discussion if they consider that it is better, and in that way
>>>> to
>>>> start the process of discussion of a new global policy proposal.
>>>>
>>>> I have to confess that dealing with 5 different PDPs is not so
>>>> easy. I
>>>> don't know if a petition process should be started, If yes, please
>>>> take
>>>> this email as the request for initiating that process.
>>>>
>>>> Since this announcement was issued last Monday in the afternoon, I
>>>> am not
>>>> sure how the business days are counted, but I guess that I am
>>>> still within
>>>> the valid period.
>>>>
>>>> However, I think that as a practices, global policy proposals
>>>> should not
>>>> be changed by any advisory council or policy chair of one region
>>>> due to
>>>> the impact that to change the proposal produce in the global
>>>> process.
>>>>
>>>>
>>>> Best Regards,
>>>>
>>>> Ra?l
>>>>
>>>>
>>>>
>>>> ---------------
>>>>
>>>>
>>>>
>>>> El 23/03/2009, a las 04:05 p.m., Member Services escribi?:
>>>>
>>>> Draft Policy 2009-3 (Global)
>>>> Allocation of IPv4 Blocks to Regional Internet Registries
>>>>
>>>> The following draft policy text is being posted for feedback and
>>>> discussion on the Public Policy Mailing List (PPML).
>>>>
>>>> This draft policy was developed by the ARIN Advisory Council (AC)
>>>> from
>>>> Policy Proposal 82: Allocation of IPv4 Blocks to Regional Internet
>>>> Registries. The AC has taken the proposal and developed it into a
>>>> draft
>>>> policy. The AC was required to submit text to ARIN for staff and
>>>> legal
>>>> assessment prior to selecting it as a draft policy. The assessment,
>>>> along with the text that was assessed, is located below the draft
>>>> policy.
>>>>
>>>> On 20 March 2009 the ARIN Advisory Council (AC) selected Draft
>>>> Policy
>>>> 2009-3: Allocation of IPv4 Blocks to Regional Internet Registries
>>>> for
>>>> adoption discussion on the PPML and at the upcoming Public Policy
>>>> Meeting.
>>>>
>>>> Draft Policy 2009-3 is below and can be found at:
>>>> https://www.arin.net/policy/proposals/2009_3.html
>>>>
>>>> We encourage you to discuss Draft Policy 2009-3 on the PPML prior
>>>> to the
>>>> ARIN XXIII Public Policy Meeting. Both the discussion on the PPML
>>>> and at
>>>> the Public Policy Meeting will be used by the AC to determine the
>>>> community consensus regarding adopting this as policy.
>>>>
>>>> The ARIN Policy Development Process can be found at:
>>>> https://www.arin.net/policy/pdp.html
>>>>
>>>> All of the Draft Policies under discussion can be found at:
>>>> https://www.arin.net/policy/proposals/index.html
>>>>
>>>> Regards,
>>>>
>>>> Member Services
>>>> American Registry for Internet Numbers (ARIN)
>>>>
>>>>
>>>> ## * ##
>>>>
>>>>
>>>> Draft Policy 2009-3 (Global)
>>>> Allocation of IPv4 Blocks to Regional Internet Registries
>>>>
>>>> Date: 23 March 2009
>>>>
>>>> Policy statement:
>>>>
>>>> This document describes the policy governing the allocation of IPv4
>>>> address space from the IANA to the Regional Internet Registries
>>>> (RIRs).
>>>> This document does not stipulate performance requirements in the
>>>> provision of services by IANA to an RIR in accordance with this
>>>> policy.
>>>> Such requirements should be specified by appropriate agreements
>>>> among
>>>> the RIRs and ICANN.
>>>>
>>>> This policy is to be implemented in two phases.
>>>>
>>>> A. Phase I: Recovery of IPv4 Address Space
>>>>
>>>> Upon ratification of this policy by the ICANN Board of Directors the
>>>> IANA shall establish a mechanism to receive IPv4 address space
>>>> which is
>>>> returned to it by the RIRs, and hold that address space in a
>>>> 'recovered
>>>> IPv4 pool'.
>>>>
>>>> Each RIR through their respective chosen policies and strategies may
>>>> recover IPv4 address space which is under their administration. At
>>>> quarterly intervals, each RIR shall return to the IANA any legacy
>>>> address space recovered, and may return to the IANA any non-legacy
>>>> address space recovered, in aggregated blocks of /24 or larger, for
>>>> inclusion in the recovered IPv4 pool.
>>>>
>>>> During Phase I, no allocations will be made from the recovered IPv4
>>>> pool. Return of recovered address space (as described above) will
>>>> continue throughout Phase II.
>>>>
>>>> B. Phase II: Allocation of Recovered IPv4 address space by the IANA
>>>>
>>>> Upon ratification of this policy by the ICANN Board of Directors
>>>> and a
>>>> declaration by the IANA that its existing free pool of unallocated
>>>> IPv4
>>>> address space is depleted; Global Addressing Policy ASO-001-2
>>>> (adopted
>>>> by ICANN Board 8 April 2005) is rescinded. IANA will then commence
>>>> to
>>>> allocate the IPv4 address space from the recovered IPv4 pool.
>>>>
>>>> 1. The following definitions apply to this policy:
>>>>
>>>> a. Recovered Address Space. Recovered address space is that address
>>>> space that is returned to an RIR as a result of any activity that
>>>> seeks
>>>> to reclaim unused address space or is voluntarily returned to the
>>>> RIR or
>>>> is reclaimed by the RIR as a result of legal action or abuse
>>>> determination. Recovered address space does not include that address
>>>> space that is reclaimed because of non-payment of contractual fees
>>>> whose
>>>> reclamation date is less than 1 year at the time of the report.
>>>>
>>>> b. IPv4 Address Holdings. IPv4 address holdings are all
>>>> unallocated IPv4
>>>> address space held by an RIR to include recovered address space
>>>> not yet
>>>> returned less that address space that is committed in accordance
>>>> with
>>>> the RIR's reservation policy and practices.
>>>>
>>>> c. Aggregated address blocks. Aggregated address blocks are
>>>> contiguous
>>>> prefixes that can be aggregated on natural bit boundaries.
>>>> 10.0.0.0/24
>>>> and 10.0.1.0/24 are two contiguous prefixes that can be combined
>>>> to form
>>>> an aggregated address block. 10.0.0.0/24 and 10.0.1.0/25 are two
>>>> contiguous prefixes that cannot be combined on a natural bit
>>>> boundary to
>>>> form an aggregated block.
>>>>
>>>> d. Legacy address space. IPv4 address space allocated or assigned
>>>> prior
>>>> to the creation of the RIR.
>>>>
>>>> 2. Allocation of IPv4 Address Space
>>>>
>>>> a. For the purposes of this policy, an 'IPv4 allocation period' is
>>>> defined as a 6-month period following 1 March or 1 September in
>>>> each year.
>>>>
>>>> b. At the beginning of each IPv4 allocation period, the IANA will
>>>> determine the 'IPv4 allocation unit' for that period, as 1/10 of its
>>>> IPv4 address pool, rounded down to the next CIDR (power-of-2)
>>>> boundary.
>>>> The minimum 'IPv4 allocation unit' size will be a /24.
>>>>
>>>> c. In each allocation period, each RIR may issue one IPv4 request
>>>> to the
>>>> IANA. Providing that the RIR satisfies the allocation criteria
>>>> described
>>>> in paragraph B.2, the IANA will allocate a single allocation unit,
>>>> composed of the smallest possible number of blocks available in
>>>> its IPv4
>>>> address pool.
>>>>
>>>> 3. IPv4 Address Space Allocation Criteria
>>>>
>>>> A RIR is eligible to receive additional IPv4 address space from
>>>> the IANA
>>>> when the total of its IPv4 address holdings is less than 50% of the
>>>> current IPv4 allocation unit, and providing that it has not already
>>>> received an IPv4 allocation from the IANA during the current IPv4
>>>> allocation period.
>>>>
>>>> 4. Initial Allocation of IPv4 Address Space
>>>>
>>>> Each new RIR shall, at the moment of recognition, be allocated one
>>>> (1)
>>>> allocation unit by the IANA. If an allocation unit is not available,
>>>> then the IANA will issue this block as soon as one is available.
>>>> This
>>>> allocation will be made regardless of the newly formed RIR's
>>>> projected
>>>> utilization figures and shall be independent of the IPv4 address
>>>> space
>>>> that may have been transferred to the new RIR by the already
>>>> existing
>>>> RIRs as part of the formal transition process.
>>>>
>>>> 5. Reporting
>>>>
>>>> a. All returned space is to be recorded in an IANA-published log
>>>> of IPv4
>>>> address space transactions, with each log entry detailing the
>>>> returned
>>>> address block, the date of the return, and the returning RIR.
>>>>
>>>> b. All allocated space is also to be recorded in this IANA-
>>>> published log
>>>> of IPv4 address space transactions, with each log entry detailing
>>>> the
>>>> address blocks, the date of the allocation and the recipient RIR.
>>>>
>>>> c. The IANA will maintain a public registry of the current
>>>> disposition
>>>> of all IPv4 address space, detailing all reservations and current
>>>> allocations and current IANA-held address space that is unallocated.
>>>>
>>>> d) The IANA may make public announcements of IPv4 address block
>>>> transactions that occur under this policy. The IANA will make
>>>> appropriate modifications to the "Internet Protocol V4 Address
>>>> Space"
>>>> page of the IANA website and may make announcements to its own
>>>> appropriate announcement lists. The IANA announcements will be
>>>> limited
>>>> to which address ranges, the time of allocation and to which
>>>> Registry
>>>> they have been allocated.
>>>>
>>>>
>>>>
>>>> #####
>>>>
>>>> ARIN Staff Assessment
>>>>
>>>> *Title: Allocation of IPv4 Blocks to the Regional Internet
>>>> Registries*
>>>>
>>>> *Proposal Submitted: 30 Jan 2009*
>>>>
>>>> *Revision Submitted: 05 March 2009*
>>>>
>>>> *Date of Assessment: 10 March 2009*
>>>>
>>>> * *
>>>>
>>>> I. Understanding of the Policy:
>>>>
>>>> *Staff Understanding of the Proposal:*
>>>>
>>>> Staff understands that this proposal would be implemented in 2
>>>> phases.
>>>> Phase 1 would require the RIRs to return recovered IPv4 legacy
>>>> address
>>>> space (via policy or procedure) to the IANA and have the option of
>>>> returning recovered non-legacy address space to the IANA. Phase 2
>>>> would
>>>> start after the depletion of the IANA free pool and would nullify
>>>> the
>>>> existing IANA to RIR policy (Global Addressing Policy ASO-001-2).
>>>> The
>>>> new IANA to RIR policy would allow each RIR to receive approximately
>>>> 1/10th of the recovered IPv4 pool from IANA once every 6 months as
>>>> long
>>>> as it meets the qualification criteria written in paragraph B2. IANA
>>>> will be required to keep a log of all returned IPv4 address space
>>>> and
>>>> all issued IPv4 address space from the recovered pool, as well as
>>>> maintain a public registry of the current disposition of all IPv4
>>>> address space.
>>>>
>>>> II. Comments
>>>>
>>>> A. ARIN Staff Comments
>>>>
>>>> * The one policy that this impacts is NRPM 4.6 Amnesty and
>>>>  Aggregation, which says ?Transactions should only be accepted
>>>>  under this policy if they are in the interests of the community
>>>>  (e.g. they improve aggregation or result in a net reclamation of
>>>>  space).? Because the ARIN region holds the majority of the legacy
>>>>  address space, and most of the address space returned under this
>>>>  policy is legacy space, it would mean that there would be no ?net
>>>>  return? of address space to ARIN. ARIN would essentially be
>>>>  exchanging legacy address space for non-legacy address space, and
>>>>  returning the legacy address space it received in the exchange to
>>>>  IANA, resulting in a net loss of address space in ARIN?s available
>>>>  pool.
>>>>
>>>> B. ARIN General Counsel Comments:
>>>>
>>>> The current basis of allocation of numbers was established in
>>>> RFC's 2008
>>>> and 2050 and is need based. If one region has greater needs than
>>>> another, the current policy of IANA does not require equal
>>>> distribution
>>>> to all RIR's s. This proposed policy would establish a different
>>>> political and not needs based method for allocating returned
>>>> space. It
>>>> would make each RIR an equal recipient of such space. But the
>>>> level of
>>>> need and economic activity between each RI R is not equal. This
>>>> policy
>>>> will tend to reallocate returned space away from where it is
>>>> recovered,
>>>> in the ARIN region , and move more of it to AFRINIC and LACNIC than
>>>> current distribution principles. By equating the smaller economies
>>>> and
>>>> related needs of certain regions to the needs of other regions, like
>>>> ARIN, that have greater day to day need, it in effect creates a new
>>>> political order of distribution thru equal shares. It is possible
>>>> sovereign governments in the regions with greater activity will not
>>>> agree to such a revised distribution model. The proposed policy
>>>> undermines the legal rationale for distribution.
>>>>
>>>> The policy also creates a powerful disincentive for any RIR,
>>>> including
>>>> ARIN, to undertake any financial expenditure of RIR dollars for
>>>> programs
>>>> intended to obtain returned space for reallocation. Currently ARIN
>>>> is
>>>> working towards policies such as the LRSA and 2008-6, intended to
>>>> encourage returns and use of under utilized resources, but which
>>>> cost
>>>> ARIN expenditures other RIRs are not duplicating. Any policy which
>>>> creates such a disincentive by leaving expenditures with a single
>>>> RIR,
>>>> who cannot benefit except to receive 20% of the returned space
>>>> should be
>>>> carefully considered.
>>>>
>>>> Finally, it is likely entities with number resources in the ARIN
>>>> region
>>>> may be willing to return those resources for uses in the region but
>>>> unwilling to do so if 4/5 of such resources will be sent to other
>>>> regions.
>>>>
>>>> III. Resource Impact
>>>>
>>>> The resource impact of implementing this policy is viewed as
>>>> minimal. It
>>>> is estimated that this policy could require up to 3 person months of
>>>> effort to implement following ratification by the ARIN Board of
>>>> Trustees. Because this implementation is not planned, it may preempt
>>>> ARIN?s current project deployment schedule. It may require the
>>>> following:
>>>>
>>>> * Modifications to existing registration procedures to include the
>>>>  handling of returned/reclaimed address space and the process of
>>>>  requesting additional address space from the IANA.
>>>> * Staff training
>>>>
>>>> Text assessed:
>>>>
>>>> *Allocation of IPv4 Blocks to Regional Internet Registries (Global)*
>>>>
>>>> *Policy statement:*
>>>>
>>>> This document describes the policy governing the allocation of IPv4
>>>> address space from the IANA to the Regional Internet Registries
>>>> (RIRs).
>>>> This document does not stipulate performance requirements in the
>>>> provision of services by IANA to an RIR in accordance with this
>>>> policy.
>>>> Such requirements should be specified by appropriate agreements
>>>> among
>>>> the RIRs and ICANN.
>>>>
>>>> This policy is to be implemented in two phases.
>>>>
>>>> A. Phase I: Recovery of IPv4 Address Space
>>>>
>>>> Upon ratification of this policy by the ICANN Board of Directors the
>>>> IANA shall establish a mechanism to receive IPv4 address space
>>>> which is
>>>> returned to it by the RIRs, and hold that address space in a
>>>> 'recovered
>>>> IPv4 pool'.
>>>>
>>>> Each RIR through their respective chosen policies and strategies may
>>>> recover IPv4 address space which is under their administration. At
>>>> quarterly intervals, each RIR shall return any legacy address space
>>>> recovered, and may return any non-legacy address space recovered,
>>>> to the
>>>> IANA in aggregated blocks of /24 or larger, for inclusion in the
>>>> recovered IPv4 pool.
>>>>
>>>> During Phase I, no allocations will be made from the recovered IPv4
>>>> pool. Return of recovered address space (as described above) will
>>>> continue throughout Phase II.
>>>>
>>>> B. Phase II: Allocation of Recovered IPv4 address space by the IANA
>>>>
>>>> Upon ratification of this policy by the ICANN Board of Directors
>>>> and a
>>>> declaration by the IANA that its existing free pool of unallocated
>>>> IPv4
>>>> address space is depleted; Global Addressing Policy ASO-001-2
>>>> (adopted
>>>> by ICANN Board 8 April 2005) is rescinded. IANA will then commence
>>>> to
>>>> allocate the IPv4 address space from the recovered IPv4 pool.
>>>>
>>>> 1. The following definitions apply to this policy:
>>>>
>>>> a. Recovered Address Space. Recovered address space is that address
>>>> space that is returned to an RIR as a result of any activity that
>>>> seeks
>>>> to reclaim unused address space or is voluntarily returned to the
>>>> RIR or
>>>> is reclaimed by the RIR as a result of legal action or abuse
>>>> determination. Recovered address space does not include that address
>>>> space that is reclaimed because of non-payment of contractual fees
>>>> whose
>>>> reclamation date is less than 1 year at the time of the report.
>>>>
>>>> b. IPv4 Address Holdings. IPv4 address holdings are all
>>>> unallocated IPv4
>>>> address space held by an RIR to include recovered address space
>>>> not yet
>>>> returned less that address space that is committed in accordance
>>>> with
>>>> the RIR's reservation policy and practices.
>>>>
>>>> c. Legacy address space. IPv4 address space allocated or assigned
>>>> prior
>>>> to the creation of the RIR.
>>>>
>>>> 2. Allocation of IPv4 Address Space
>>>>
>>>> a. For the purposes of this policy, an 'IPv4 allocation period' is
>>>> defined as a 6-month period following 1 March or 1 September in
>>>> each year.
>>>>
>>>> b. At the beginning of each IPv4 allocation period, the IANA will
>>>> determine the 'IPv4 allocation unit' for that period, as 1/10 of its
>>>> IPv4 address pool, rounded down to the next CIDR (power-of-2)
>>>> boundary.
>>>>
>>>> c. In each allocation period, each RIR may issue one IPv4 request
>>>> to the
>>>> IANA. Providing that the RIR satisfies the allocation criteria
>>>> described
>>>> in paragraph B.2, the IANA will allocate a single allocation unit,
>>>> composed of the smallest possible number of blocks available in
>>>> its IPv4
>>>> address pool.
>>>>
>>>> 3. IPv4 Address Space Allocation Criteria
>>>>
>>>> A RIR is eligible to receive additional IPv4 address space from
>>>> the IANA
>>>> when the total of its IPv4 address holdings is less than 50% of the
>>>> current IPv4 allocation unit, and providing that it has not already
>>>> received an IPv4 allocation from the IANA during the current IPv4
>>>> allocation period.
>>>>
>>>> 4. Initial Allocation of IPv4 Address Space
>>>>
>>>> Each new RIR shall, at the moment of recognition, be allocated one
>>>> (1)
>>>> allocation unit by the IANA. If an allocation unit is not available,
>>>> then the IANA will issue this block as soon as one is available.
>>>> This
>>>> allocation will be made regardless of the newly formed RIR's
>>>> projected
>>>> utilization figures and shall be independent of the IPv4 address
>>>> space
>>>> that may have been transferred to the new RIR by the already
>>>> existing
>>>> RIRs as part of the formal transition process.
>>>>
>>>> 5. Reporting
>>>>
>>>> a. All returned space is to be recorded in an IANA-published log
>>>> of IPv4
>>>> address space transactions, with each log entry detailing the
>>>> returned
>>>> address block, the date of the return, and the returning RIR.
>>>>
>>>> b. All allocated space is also to be recorded in this IANA-
>>>> published log
>>>> of IPv4 address space transactions, with each log entry detailing
>>>> the
>>>> address blocks, the date of the allocation and the recipient RIR.
>>>>
>>>> c. The IANA will maintain a public registry of the current
>>>> disposition
>>>> of all IPv4 address space, detailing all reservations and current
>>>> allocations and current IANA-held address space that is unallocated.
>>>>
>>>> d) The IANA may make public announcements of IPv4 address block
>>>> transactions that occur under this policy. The IANA will make
>>>> appropriate modifications to the "Internet Protocol V4 Address
>>>> Space"
>>>> page of the IANA website and may make announcements to its own
>>>> appropriate announcement lists. The IANA announcements will be
>>>> limited
>>>> to which address ranges, the time of allocation and to which
>>>> Registry
>>>> they have been allocated.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> PPML
>>>> You are receiving this message because you are subscribed to
>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>> Please contact info at arin.net if you experience any issues.
>>>>
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>>>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>

-- 
Sent from my mobile device


From bill at herrin.us  Mon Mar 30 16:24:09 2009
From: bill at herrin.us (William Herrin)
Date: Mon, 30 Mar 2009 16:24:09 -0400
Subject: [arin-ppml] clarification of Board actions Feb 2 and Mar 18,
	2009
In-Reply-To: <3c3e3fca0903301020sece2869scfb385ce6fcd4fb7@mail.gmail.com>
References: <376189.27706.qm@web63303.mail.re1.yahoo.com>
	<3c3e3fca0903301020sece2869scfb385ce6fcd4fb7@mail.gmail.com>
Message-ID: <3c3e3fca0903301324x63986d15h38e07a97d2f52b58@mail.gmail.com>

On Mon, Mar 30, 2009 at 1:20 PM, William Herrin <bill at herrin.us> wrote:
>>?The policy in 2008-6 allowed
>> the Board to activate it by declaring an emergency,
>
> Er, what?
>
> I'm not aware of of any text in 2008-6 which required or even
> recommended that the board declare an emergency in order to activate

Lee,

I retract the above statement. 2008-6 specified:

   Timetable for implementation:

   This policy [...]  would be implemented when [...] IPv4 address
   resources in the ARIN Region reach a threshold of scarcity
   recognized by the ARIN Board of Trustees as requiring this policy
   implementation.

It was there in every version of 2008-6, including the ones that I
supported. I concede that this text could reasonably be interpreted as
requiring a declaration of emergency for activation.

The rest of what I said and asked stands. As I told Milton, this
particular question was the least of them.

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From scottleibrand at gmail.com  Mon Mar 30 16:40:23 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Mon, 30 Mar 2009 13:40:23 -0700
Subject: [arin-ppml] Draft Policy 2009-3 (Global): Allocation of IPv4
 Blocks to Regional Internet Registries
In-Reply-To: <4607e1d50903301318y3c142303g42a991f6be79b0a6@mail.gmail.com>
References: <37137.208.54.95.48.1238379940.squirrel@webmail.lacnic.net.uy>	
	<49D10949.9000803@arin.net> <49D11F48.6090905@gmail.com>	
	<9EDA9B03-C069-44B5-B06D-D60E510849FE@lacnic.net>
	<4607e1d50903301318y3c142303g42a991f6be79b0a6@mail.gmail.com>
Message-ID: <49D12E37.9040307@gmail.com>

Running this policy through the process fairly is exactly what we're 
trying to do here.  I'm certainly not pushing for (or against) 
adoption.  (My opinion of the draft policy is rather nuanced: I can 
elaborate separately if you'd like.) While I don't think there is a 
consensus for adopting the original policy proposal, I also don't see a 
consensus for abandoning the proposal without first discussing it at a 
public policy meeting.

In more general terms, the required level of support for advancing a 
policy proposal for discussion at the public policy meeting is much 
lower than the level of consensus required for adopting such a policy.  
If such consensus is not demonstrated at the public policy meeting, and 
there is no consensus among the community that the AC should continue 
working on the policy, then the AC is much more likely to vote to 
abandon the proposal at that time.

-Scott

Martin Hannigan wrote:
> Scott,
>
> You indicated that there is no consensus with regards to this policy
> advancing.  Why is this policy advancing at all then?  Regardless of
> it being a global policy, there's no requirement to do anything other
> than to run this policy through the process fairly. Failing to succeed
> in that process is a sometimes expected result.
>
> A perception may be starting to develop that this policy isn't being
> treated equally with regards to other policies I.e. continuing to be
> pushed for discussion without support.
>
>
> Best,
>
> Martin
>
>
>
> On 3/30/09, Raul Echeberria <raul at lacnic.net> wrote:
>   
>> Thanks,
>>
>> Ra?l
>>
>>
>>
>> El 30/03/2009, a las 04:36 p.m., Scott Leibrand escribi?:
>>
>>     
>>> Raul,
>>>
>>> Given that it's too late to initiate a separate discussion petition
>>> for the San Antonio meeting, I would like to assure you that I will
>>> do what I can to make sure that we get feedback from the community
>>> at that meeting as to the support for the original proposed text, as
>>> well as for the revised version.  If there is a clear community
>>> consensus in favor of either language, my own personal opinion is
>>> that we'll be able to move the proposal forward, with any applicable
>>> edits, at that point.
>>>
>>> In order to prepare for such discussion, I'd welcome feedback from
>>> the PPML on the following questions:
>>>
>>> - Do you support the original proposed text of 2009-3, requiring
>>> return of any reclaimed space to IANA for redistribution?  Why or
>>> why not?
>>> - Do you support the current modified text of 2009-3, requiring
>>> return of any reclaimed legacy space, but making optional the return
>>> of any non-legacy space?  Why or why not?
>>> - Would you support some other revised version of 2009-3?  If so,
>>> what would you want to change?  (For example, we could make all
>>> returns optional, for both legacy and non-legacy space.)
>>> - If you oppose 2009-3 completely, do you believe that current
>>> policy is adequate, or would you support some other mechanism to
>>> allow for the reallocation of IPv4 blocks between RIRs?
>>>
>>> Thanks,
>>> Scott
>>>
>>> Member Services wrote:
>>>       
>>>> Raul,
>>>>
>>>> According to the ARIN Policy Development Process the petition
>>>> period for
>>>> the upcoming San Antonio meeting closed on 13 March 2009. The
>>>> deadline
>>>> information was posted to PPML earlier this month, see the post:
>>>> http://lists.arin.net/pipermail/arin-ppml/2009-March/013106.html
>>>>
>>>> The draft policy is under discussion, statements of support and
>>>> opposition are welcome and appreciated. Both the discussion on the
>>>> PPML
>>>> and at the Public Policy Meeting will be used by the AC to
>>>> determine the
>>>> community consensus regarding adopting this as policy.
>>>>
>>>> The ARIN Policy Development Process can be found at:
>>>> https://www.arin.net/policy/pdp.html
>>>>
>>>> Regards,
>>>>
>>>> Member Services
>>>> American Registry for Internet Numbers (ARIN)
>>>>
>>>> raul at lacnic.net wrote:
>>>>
>>>>         
>>>>> Dear all:
>>>>>
>>>>> This proposal is a proposal for a global policy. It means that the
>>>>> same
>>>>> proposal has to be approved in every region. They can be approved
>>>>> with
>>>>> some wording differences, but the spirit of the proposal should be
>>>>> the
>>>>> same.
>>>>>
>>>>> The proposal was the result of a long collaboration effort of
>>>>> senior staff
>>>>> members and board members of all the 5 RIRs and the original text
>>>>> is the
>>>>> one that is being considered in every region.
>>>>>
>>>>> As far as I know the authors of the proposal were not consulted by
>>>>> the
>>>>> ARIN-AC and based on exchanges among the authors in the past few
>>>>> days, I
>>>>> can say that in general the feeling is that the changes introduced
>>>>> by the
>>>>> ARIN-AC are very signficant and so, this is a different proposal.
>>>>>
>>>>> My personal view is that changing the concept of a global policy
>>>>> proposal
>>>>> in one RIR means to avoid the approval of the policy. I strongly
>>>>> encourage
>>>>> ARIN to put the original proposal under consideration of its
>>>>> community as
>>>>> it is being done in the other regions. The proposal can be
>>>>> approved or
>>>>> not, That's part of the process, but it doesn't make sense to
>>>>> approve a
>>>>> different proposal. IMHO, the AC is able to put forward the new
>>>>> proposal
>>>>> for discussion if they consider that it is better, and in that way
>>>>> to
>>>>> start the process of discussion of a new global policy proposal.
>>>>>
>>>>> I have to confess that dealing with 5 different PDPs is not so
>>>>> easy. I
>>>>> don't know if a petition process should be started, If yes, please
>>>>> take
>>>>> this email as the request for initiating that process.
>>>>>
>>>>> Since this announcement was issued last Monday in the afternoon, I
>>>>> am not
>>>>> sure how the business days are counted, but I guess that I am
>>>>> still within
>>>>> the valid period.
>>>>>
>>>>> However, I think that as a practices, global policy proposals
>>>>> should not
>>>>> be changed by any advisory council or policy chair of one region
>>>>> due to
>>>>> the impact that to change the proposal produce in the global
>>>>> process.
>>>>>
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Ra?l
>>>>>
>>>>>
>>>>>
>>>>> ---------------
>>>>>
>>>>>
>>>>>
>>>>> El 23/03/2009, a las 04:05 p.m., Member Services escribi?:
>>>>>
>>>>> Draft Policy 2009-3 (Global)
>>>>> Allocation of IPv4 Blocks to Regional Internet Registries
>>>>>
>>>>> The following draft policy text is being posted for feedback and
>>>>> discussion on the Public Policy Mailing List (PPML).
>>>>>
>>>>> This draft policy was developed by the ARIN Advisory Council (AC)
>>>>> from
>>>>> Policy Proposal 82: Allocation of IPv4 Blocks to Regional Internet
>>>>> Registries. The AC has taken the proposal and developed it into a
>>>>> draft
>>>>> policy. The AC was required to submit text to ARIN for staff and
>>>>> legal
>>>>> assessment prior to selecting it as a draft policy. The assessment,
>>>>> along with the text that was assessed, is located below the draft
>>>>> policy.
>>>>>
>>>>> On 20 March 2009 the ARIN Advisory Council (AC) selected Draft
>>>>> Policy
>>>>> 2009-3: Allocation of IPv4 Blocks to Regional Internet Registries
>>>>> for
>>>>> adoption discussion on the PPML and at the upcoming Public Policy
>>>>> Meeting.
>>>>>
>>>>> Draft Policy 2009-3 is below and can be found at:
>>>>> https://www.arin.net/policy/proposals/2009_3.html
>>>>>
>>>>> We encourage you to discuss Draft Policy 2009-3 on the PPML prior
>>>>> to the
>>>>> ARIN XXIII Public Policy Meeting. Both the discussion on the PPML
>>>>> and at
>>>>> the Public Policy Meeting will be used by the AC to determine the
>>>>> community consensus regarding adopting this as policy.
>>>>>
>>>>> The ARIN Policy Development Process can be found at:
>>>>> https://www.arin.net/policy/pdp.html
>>>>>
>>>>> All of the Draft Policies under discussion can be found at:
>>>>> https://www.arin.net/policy/proposals/index.html
>>>>>
>>>>> Regards,
>>>>>
>>>>> Member Services
>>>>> American Registry for Internet Numbers (ARIN)
>>>>>
>>>>>
>>>>> ## * ##
>>>>>
>>>>>
>>>>> Draft Policy 2009-3 (Global)
>>>>> Allocation of IPv4 Blocks to Regional Internet Registries
>>>>>
>>>>> Date: 23 March 2009
>>>>>
>>>>> Policy statement:
>>>>>
>>>>> This document describes the policy governing the allocation of IPv4
>>>>> address space from the IANA to the Regional Internet Registries
>>>>> (RIRs).
>>>>> This document does not stipulate performance requirements in the
>>>>> provision of services by IANA to an RIR in accordance with this
>>>>> policy.
>>>>> Such requirements should be specified by appropriate agreements
>>>>> among
>>>>> the RIRs and ICANN.
>>>>>
>>>>> This policy is to be implemented in two phases.
>>>>>
>>>>> A. Phase I: Recovery of IPv4 Address Space
>>>>>
>>>>> Upon ratification of this policy by the ICANN Board of Directors the
>>>>> IANA shall establish a mechanism to receive IPv4 address space
>>>>> which is
>>>>> returned to it by the RIRs, and hold that address space in a
>>>>> 'recovered
>>>>> IPv4 pool'.
>>>>>
>>>>> Each RIR through their respective chosen policies and strategies may
>>>>> recover IPv4 address space which is under their administration. At
>>>>> quarterly intervals, each RIR shall return to the IANA any legacy
>>>>> address space recovered, and may return to the IANA any non-legacy
>>>>> address space recovered, in aggregated blocks of /24 or larger, for
>>>>> inclusion in the recovered IPv4 pool.
>>>>>
>>>>> During Phase I, no allocations will be made from the recovered IPv4
>>>>> pool. Return of recovered address space (as described above) will
>>>>> continue throughout Phase II.
>>>>>
>>>>> B. Phase II: Allocation of Recovered IPv4 address space by the IANA
>>>>>
>>>>> Upon ratification of this policy by the ICANN Board of Directors
>>>>> and a
>>>>> declaration by the IANA that its existing free pool of unallocated
>>>>> IPv4
>>>>> address space is depleted; Global Addressing Policy ASO-001-2
>>>>> (adopted
>>>>> by ICANN Board 8 April 2005) is rescinded. IANA will then commence
>>>>> to
>>>>> allocate the IPv4 address space from the recovered IPv4 pool.
>>>>>
>>>>> 1. The following definitions apply to this policy:
>>>>>
>>>>> a. Recovered Address Space. Recovered address space is that address
>>>>> space that is returned to an RIR as a result of any activity that
>>>>> seeks
>>>>> to reclaim unused address space or is voluntarily returned to the
>>>>> RIR or
>>>>> is reclaimed by the RIR as a result of legal action or abuse
>>>>> determination. Recovered address space does not include that address
>>>>> space that is reclaimed because of non-payment of contractual fees
>>>>> whose
>>>>> reclamation date is less than 1 year at the time of the report.
>>>>>
>>>>> b. IPv4 Address Holdings. IPv4 address holdings are all
>>>>> unallocated IPv4
>>>>> address space held by an RIR to include recovered address space
>>>>> not yet
>>>>> returned less that address space that is committed in accordance
>>>>> with
>>>>> the RIR's reservation policy and practices.
>>>>>
>>>>> c. Aggregated address blocks. Aggregated address blocks are
>>>>> contiguous
>>>>> prefixes that can be aggregated on natural bit boundaries.
>>>>> 10.0.0.0/24
>>>>> and 10.0.1.0/24 are two contiguous prefixes that can be combined
>>>>> to form
>>>>> an aggregated address block. 10.0.0.0/24 and 10.0.1.0/25 are two
>>>>> contiguous prefixes that cannot be combined on a natural bit
>>>>> boundary to
>>>>> form an aggregated block.
>>>>>
>>>>> d. Legacy address space. IPv4 address space allocated or assigned
>>>>> prior
>>>>> to the creation of the RIR.
>>>>>
>>>>> 2. Allocation of IPv4 Address Space
>>>>>
>>>>> a. For the purposes of this policy, an 'IPv4 allocation period' is
>>>>> defined as a 6-month period following 1 March or 1 September in
>>>>> each year.
>>>>>
>>>>> b. At the beginning of each IPv4 allocation period, the IANA will
>>>>> determine the 'IPv4 allocation unit' for that period, as 1/10 of its
>>>>> IPv4 address pool, rounded down to the next CIDR (power-of-2)
>>>>> boundary.
>>>>> The minimum 'IPv4 allocation unit' size will be a /24.
>>>>>
>>>>> c. In each allocation period, each RIR may issue one IPv4 request
>>>>> to the
>>>>> IANA. Providing that the RIR satisfies the allocation criteria
>>>>> described
>>>>> in paragraph B.2, the IANA will allocate a single allocation unit,
>>>>> composed of the smallest possible number of blocks available in
>>>>> its IPv4
>>>>> address pool.
>>>>>
>>>>> 3. IPv4 Address Space Allocation Criteria
>>>>>
>>>>> A RIR is eligible to receive additional IPv4 address space from
>>>>> the IANA
>>>>> when the total of its IPv4 address holdings is less than 50% of the
>>>>> current IPv4 allocation unit, and providing that it has not already
>>>>> received an IPv4 allocation from the IANA during the current IPv4
>>>>> allocation period.
>>>>>
>>>>> 4. Initial Allocation of IPv4 Address Space
>>>>>
>>>>> Each new RIR shall, at the moment of recognition, be allocated one
>>>>> (1)
>>>>> allocation unit by the IANA. If an allocation unit is not available,
>>>>> then the IANA will issue this block as soon as one is available.
>>>>> This
>>>>> allocation will be made regardless of the newly formed RIR's
>>>>> projected
>>>>> utilization figures and shall be independent of the IPv4 address
>>>>> space
>>>>> that may have been transferred to the new RIR by the already
>>>>> existing
>>>>> RIRs as part of the formal transition process.
>>>>>
>>>>> 5. Reporting
>>>>>
>>>>> a. All returned space is to be recorded in an IANA-published log
>>>>> of IPv4
>>>>> address space transactions, with each log entry detailing the
>>>>> returned
>>>>> address block, the date of the return, and the returning RIR.
>>>>>
>>>>> b. All allocated space is also to be recorded in this IANA-
>>>>> published log
>>>>> of IPv4 address space transactions, with each log entry detailing
>>>>> the
>>>>> address blocks, the date of the allocation and the recipient RIR.
>>>>>
>>>>> c. The IANA will maintain a public registry of the current
>>>>> disposition
>>>>> of all IPv4 address space, detailing all reservations and current
>>>>> allocations and current IANA-held address space that is unallocated.
>>>>>
>>>>> d) The IANA may make public announcements of IPv4 address block
>>>>> transactions that occur under this policy. The IANA will make
>>>>> appropriate modifications to the "Internet Protocol V4 Address
>>>>> Space"
>>>>> page of the IANA website and may make announcements to its own
>>>>> appropriate announcement lists. The IANA announcements will be
>>>>> limited
>>>>> to which address ranges, the time of allocation and to which
>>>>> Registry
>>>>> they have been allocated.
>>>>>
>>>>>
>>>>>
>>>>> #####
>>>>>
>>>>> ARIN Staff Assessment
>>>>>
>>>>> *Title: Allocation of IPv4 Blocks to the Regional Internet
>>>>> Registries*
>>>>>
>>>>> *Proposal Submitted: 30 Jan 2009*
>>>>>
>>>>> *Revision Submitted: 05 March 2009*
>>>>>
>>>>> *Date of Assessment: 10 March 2009*
>>>>>
>>>>> * *
>>>>>
>>>>> I. Understanding of the Policy:
>>>>>
>>>>> *Staff Understanding of the Proposal:*
>>>>>
>>>>> Staff understands that this proposal would be implemented in 2
>>>>> phases.
>>>>> Phase 1 would require the RIRs to return recovered IPv4 legacy
>>>>> address
>>>>> space (via policy or procedure) to the IANA and have the option of
>>>>> returning recovered non-legacy address space to the IANA. Phase 2
>>>>> would
>>>>> start after the depletion of the IANA free pool and would nullify
>>>>> the
>>>>> existing IANA to RIR policy (Global Addressing Policy ASO-001-2).
>>>>> The
>>>>> new IANA to RIR policy would allow each RIR to receive approximately
>>>>> 1/10th of the recovered IPv4 pool from IANA once every 6 months as
>>>>> long
>>>>> as it meets the qualification criteria written in paragraph B2. IANA
>>>>> will be required to keep a log of all returned IPv4 address space
>>>>> and
>>>>> all issued IPv4 address space from the recovered pool, as well as
>>>>> maintain a public registry of the current disposition of all IPv4
>>>>> address space.
>>>>>
>>>>> II. Comments
>>>>>
>>>>> A. ARIN Staff Comments
>>>>>
>>>>> * The one policy that this impacts is NRPM 4.6 Amnesty and
>>>>>  Aggregation, which says ?Transactions should only be accepted
>>>>>  under this policy if they are in the interests of the community
>>>>>  (e.g. they improve aggregation or result in a net reclamation of
>>>>>  space).? Because the ARIN region holds the majority of the legacy
>>>>>  address space, and most of the address space returned under this
>>>>>  policy is legacy space, it would mean that there would be no ?net
>>>>>  return? of address space to ARIN. ARIN would essentially be
>>>>>  exchanging legacy address space for non-legacy address space, and
>>>>>  returning the legacy address space it received in the exchange to
>>>>>  IANA, resulting in a net loss of address space in ARIN?s available
>>>>>  pool.
>>>>>
>>>>> B. ARIN General Counsel Comments:
>>>>>
>>>>> The current basis of allocation of numbers was established in
>>>>> RFC's 2008
>>>>> and 2050 and is need based. If one region has greater needs than
>>>>> another, the current policy of IANA does not require equal
>>>>> distribution
>>>>> to all RIR's s. This proposed policy would establish a different
>>>>> political and not needs based method for allocating returned
>>>>> space. It
>>>>> would make each RIR an equal recipient of such space. But the
>>>>> level of
>>>>> need and economic activity between each RI R is not equal. This
>>>>> policy
>>>>> will tend to reallocate returned space away from where it is
>>>>> recovered,
>>>>> in the ARIN region , and move more of it to AFRINIC and LACNIC than
>>>>> current distribution principles. By equating the smaller economies
>>>>> and
>>>>> related needs of certain regions to the needs of other regions, like
>>>>> ARIN, that have greater day to day need, it in effect creates a new
>>>>> political order of distribution thru equal shares. It is possible
>>>>> sovereign governments in the regions with greater activity will not
>>>>> agree to such a revised distribution model. The proposed policy
>>>>> undermines the legal rationale for distribution.
>>>>>
>>>>> The policy also creates a powerful disincentive for any RIR,
>>>>> including
>>>>> ARIN, to undertake any financial expenditure of RIR dollars for
>>>>> programs
>>>>> intended to obtain returned space for reallocation. Currently ARIN
>>>>> is
>>>>> working towards policies such as the LRSA and 2008-6, intended to
>>>>> encourage returns and use of under utilized resources, but which
>>>>> cost
>>>>> ARIN expenditures other RIRs are not duplicating. Any policy which
>>>>> creates such a disincentive by leaving expenditures with a single
>>>>> RIR,
>>>>> who cannot benefit except to receive 20% of the returned space
>>>>> should be
>>>>> carefully considered.
>>>>>
>>>>> Finally, it is likely entities with number resources in the ARIN
>>>>> region
>>>>> may be willing to return those resources for uses in the region but
>>>>> unwilling to do so if 4/5 of such resources will be sent to other
>>>>> regions.
>>>>>
>>>>> III. Resource Impact
>>>>>
>>>>> The resource impact of implementing this policy is viewed as
>>>>> minimal. It
>>>>> is estimated that this policy could require up to 3 person months of
>>>>> effort to implement following ratification by the ARIN Board of
>>>>> Trustees. Because this implementation is not planned, it may preempt
>>>>> ARIN?s current project deployment schedule. It may require the
>>>>> following:
>>>>>
>>>>> * Modifications to existing registration procedures to include the
>>>>>  handling of returned/reclaimed address space and the process of
>>>>>  requesting additional address space from the IANA.
>>>>> * Staff training
>>>>>
>>>>> Text assessed:
>>>>>
>>>>> *Allocation of IPv4 Blocks to Regional Internet Registries (Global)*
>>>>>
>>>>> *Policy statement:*
>>>>>
>>>>> This document describes the policy governing the allocation of IPv4
>>>>> address space from the IANA to the Regional Internet Registries
>>>>> (RIRs).
>>>>> This document does not stipulate performance requirements in the
>>>>> provision of services by IANA to an RIR in accordance with this
>>>>> policy.
>>>>> Such requirements should be specified by appropriate agreements
>>>>> among
>>>>> the RIRs and ICANN.
>>>>>
>>>>> This policy is to be implemented in two phases.
>>>>>
>>>>> A. Phase I: Recovery of IPv4 Address Space
>>>>>
>>>>> Upon ratification of this policy by the ICANN Board of Directors the
>>>>> IANA shall establish a mechanism to receive IPv4 address space
>>>>> which is
>>>>> returned to it by the RIRs, and hold that address space in a
>>>>> 'recovered
>>>>> IPv4 pool'.
>>>>>
>>>>> Each RIR through their respective chosen policies and strategies may
>>>>> recover IPv4 address space which is under their administration. At
>>>>> quarterly intervals, each RIR shall return any legacy address space
>>>>> recovered, and may return any non-legacy address space recovered,
>>>>> to the
>>>>> IANA in aggregated blocks of /24 or larger, for inclusion in the
>>>>> recovered IPv4 pool.
>>>>>
>>>>> During Phase I, no allocations will be made from the recovered IPv4
>>>>> pool. Return of recovered address space (as described above) will
>>>>> continue throughout Phase II.
>>>>>
>>>>> B. Phase II: Allocation of Recovered IPv4 address space by the IANA
>>>>>
>>>>> Upon ratification of this policy by the ICANN Board of Directors
>>>>> and a
>>>>> declaration by the IANA that its existing free pool of unallocated
>>>>> IPv4
>>>>> address space is depleted; Global Addressing Policy ASO-001-2
>>>>> (adopted
>>>>> by ICANN Board 8 April 2005) is rescinded. IANA will then commence
>>>>> to
>>>>> allocate the IPv4 address space from the recovered IPv4 pool.
>>>>>
>>>>> 1. The following definitions apply to this policy:
>>>>>
>>>>> a. Recovered Address Space. Recovered address space is that address
>>>>> space that is returned to an RIR as a result of any activity that
>>>>> seeks
>>>>> to reclaim unused address space or is voluntarily returned to the
>>>>> RIR or
>>>>> is reclaimed by the RIR as a result of legal action or abuse
>>>>> determination. Recovered address space does not include that address
>>>>> space that is reclaimed because of non-payment of contractual fees
>>>>> whose
>>>>> reclamation date is less than 1 year at the time of the report.
>>>>>
>>>>> b. IPv4 Address Holdings. IPv4 address holdings are all
>>>>> unallocated IPv4
>>>>> address space held by an RIR to include recovered address space
>>>>> not yet
>>>>> returned less that address space that is committed in accordance
>>>>> with
>>>>> the RIR's reservation policy and practices.
>>>>>
>>>>> c. Legacy address space. IPv4 address space allocated or assigned
>>>>> prior
>>>>> to the creation of the RIR.
>>>>>
>>>>> 2. Allocation of IPv4 Address Space
>>>>>
>>>>> a. For the purposes of this policy, an 'IPv4 allocation period' is
>>>>> defined as a 6-month period following 1 March or 1 September in
>>>>> each year.
>>>>>
>>>>> b. At the beginning of each IPv4 allocation period, the IANA will
>>>>> determine the 'IPv4 allocation unit' for that period, as 1/10 of its
>>>>> IPv4 address pool, rounded down to the next CIDR (power-of-2)
>>>>> boundary.
>>>>>
>>>>> c. In each allocation period, each RIR may issue one IPv4 request
>>>>> to the
>>>>> IANA. Providing that the RIR satisfies the allocation criteria
>>>>> described
>>>>> in paragraph B.2, the IANA will allocate a single allocation unit,
>>>>> composed of the smallest possible number of blocks available in
>>>>> its IPv4
>>>>> address pool.
>>>>>
>>>>> 3. IPv4 Address Space Allocation Criteria
>>>>>
>>>>> A RIR is eligible to receive additional IPv4 address space from
>>>>> the IANA
>>>>> when the total of its IPv4 address holdings is less than 50% of the
>>>>> current IPv4 allocation unit, and providing that it has not already
>>>>> received an IPv4 allocation from the IANA during the current IPv4
>>>>> allocation period.
>>>>>
>>>>> 4. Initial Allocation of IPv4 Address Space
>>>>>
>>>>> Each new RIR shall, at the moment of recognition, be allocated one
>>>>> (1)
>>>>> allocation unit by the IANA. If an allocation unit is not available,
>>>>> then the IANA will issue this block as soon as one is available.
>>>>> This
>>>>> allocation will be made regardless of the newly formed RIR's
>>>>> projected
>>>>> utilization figures and shall be independent of the IPv4 address
>>>>> space
>>>>> that may have been transferred to the new RIR by the already
>>>>> existing
>>>>> RIRs as part of the formal transition process.
>>>>>
>>>>> 5. Reporting
>>>>>
>>>>> a. All returned space is to be recorded in an IANA-published log
>>>>> of IPv4
>>>>> address space transactions, with each log entry detailing the
>>>>> returned
>>>>> address block, the date of the return, and the returning RIR.
>>>>>
>>>>> b. All allocated space is also to be recorded in this IANA-
>>>>> published log
>>>>> of IPv4 address space transactions, with each log entry detailing
>>>>> the
>>>>> address blocks, the date of the allocation and the recipient RIR.
>>>>>
>>>>> c. The IANA will maintain a public registry of the current
>>>>> disposition
>>>>> of all IPv4 address space, detailing all reservations and current
>>>>> allocations and current IANA-held address space that is unallocated.
>>>>>
>>>>> d) The IANA may make public announcements of IPv4 address block
>>>>> transactions that occur under this policy. The IANA will make
>>>>> appropriate modifications to the "Internet Protocol V4 Address
>>>>> Space"
>>>>> page of the IANA website and may make announcements to its own
>>>>> appropriate announcement lists. The IANA announcements will be
>>>>> limited
>>>>> to which address ranges, the time of allocation and to which
>>>>> Registry
>>>>> they have been allocated.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> PPML
>>>>> You are receiving this message because you are subscribed to
>>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>>>> Unsubscribe or manage your mailing list subscription at:
>>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>>> Please contact info at arin.net if you experience any issues.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>           
>>>> _______________________________________________
>>>> PPML
>>>> You are receiving this message because you are subscribed to
>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>> Please contact info at arin.net if you experience any issues.
>>>>
>>>>         
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
>>     
>
>   


From tedm at ipinc.net  Mon Mar 30 16:47:39 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 30 Mar 2009 13:47:39 -0700
Subject: [arin-ppml]
	=?iso-8859-1?q?Draft_Policy_2008-7=3A_Identify_Invali?=
	=?iso-8859-1?q?d_WHOIS_POC=27s?=
In-Reply-To: <443de7ad0903301254p14d69273tb784c27718fb2a20@mail.gmail.com>
References: <49C7DD6E.3010106@arin.net>
	<443de7ad0903301254p14d69273tb784c27718fb2a20@mail.gmail.com>
Message-ID: <A5F94DDCE26E4FF3BE50E8E2AE6948D5@tedsdesk>

 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Chris Grundemann
> Sent: Monday, March 30, 2009 12:54 PM
> To: Member Services
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml]Draft Policy 2008-7: Identify Invalid 
> WHOIS POC?s
> 
> On Mon, Mar 23, 2009 at 13:05, Member Services <info at arin.net> wrote:
> > SUBJECT: Draft Policy 2008-7: Identify Invalid WHOIS POC?s
> >
> > Draft Policy 2008-7
> > Identify Invalid WHOIS POC?s
> >
> > The following draft policy text is being posted for feedback and 
> > discussion on the Public Policy Mailing List (PPML).
> >
> > After the October 2008 Public Policy Meeting the ARIN 
> Advisory Council
> > (AC) decided that 2008-7 required more work. The text below was 
> > developed by the AC with help from the proposal originators. The AC 
> > was required to submit text to ARIN for staff and legal assessment 
> > prior to selecting it as a draft policy. The assessment, along with 
> > the text that was assessed, is located below the draft policy.
> >
> > On 20 March 2009 the ARIN Advisory Council (AC) selected 
> Draft Policy
> > 2008-7: Identify Invalid WHOIS POC?s (formally known as WHOIS 
> > Integrity Policy Proposal) for adoption discussion on the 
> PPML and at 
> > the upcoming Public Policy Meeting.
> >
> > Draft Policy 2008-7 is below and can be found at:
> > https://www.arin.net/policy/proposals/2008_7.html
> >
> > We encourage you to discuss Draft Policy 2008-7 on PPML 
> prior to the 
> > ARIN XXIII Public Policy Meeting. Both the discussion on 
> the PPML and 
> > at the Public Policy Meeting will be used by the ARIN 
> Advisory Council 
> > to determine the community consensus regarding adopting 
> this as policy.
> >
> > The ARIN Policy Development Process can be found at:
> > https://www.arin.net/policy/pdp.html
> >
> > All of the Draft Policies under discussion can be found at:
> > https://www.arin.net/policy/proposals/index.html
> >
> > Regards,
> >
> > Member Services
> > American Registry for Internet Numbers (ARIN)
> >
> >
> > ## * ##
> >
> >
> > Draft Policy 2008-7
> > Identify Invalid WHOIS POC?s
> >
> > Date: 23 March 2009
> >
> > Policy Statement:
> >
> > During ARINs annual WHOIS POC validation, an e-mail will be sent to 
> > every POC in the WHOIS database. Each POC will have a maximum of 60 
> > days to respond with an affirmative that their WHOIS contact 
> > information is correct and complete. Unresponsive POC email 
> addresses 
> > shall be marked as such in the database. If ARIN staff 
> deems a POC to 
> > be completely and permanently abandoned or otherwise 
> illegitimate, the 
> > record shall be deleted. ARIN will maintain, and make readily 
> > available to the community, a current list of 
> address-blocks with no 
> > valid POC; this data will be subject to the current bulk 
> WHOIS policy.
> >
> > Timetable for implementation: Immediate
> >
> >
> > #####
> >
> > ARIN Staff Assessment
> >
> > 2008-7
> >
> > Title: ?Identify Invalid WHOIS POC's (formerly known as WHOIS 
> > Integrity Policy Proposal)
> >
> > Revision Submitted: 07 March 2008
> >
> > 2nd Revision Submitted: 12 Feb 2009
> >
> > Date of Assessment: ?24 Feb 2009
> >
> > The assessment of this text includes comments from ARIN 
> staff and the 
> > ARIN General Counsel. It contains analysis of procedural, 
> legal, and 
> > resource concerns regarding the implementation of this text 
> as it is 
> > currently stated. Any changes to the language may 
> necessitate further 
> > analysis by staff and Counsel.
> >
> > I. ?Understanding
> >
> > ARIN staff understands that this will institute an annual 
> > re-registration of all POCs registered in WHOIS. ?POCs who do not 
> > respond within 60 days will be marked in the database as 
> "un-responsive"
> > and if staff deems them to be invalid for any reason, may 
> remove them 
> > from WHOIS. ?In addition, staff will maintain a list of all address 
> > blocks with no valid POCs and will make this data available to any 
> > organization using the bulk whois policy criteria.
> >
> > II. ?Issues and Concerns
> >
> > ?A. ?ARIN Staff Comments:
> >
> > ? ?* Resource records marked as ?unresponsive? or those 
> with no POCs 
> > at
> > ? ? ?all could become the targets of hijackers who, in the past have
> > ? ? ?tended to look for address blocks that contain 
> obsolete or stale data.
> 
> This is exactly why I (and I believe the other authors of 
> this proposed policy) wanted the discloser to be required.  
> Hijackers, like spammers, phishers and other criminals spend 
> their time finding this kind of data -- the idea of this 
> portion of this policy is to give everyone the data that we 
> can assume hijackers (probably) already have.  This public 
> disclosure of netblocks with out any valid POCs will 
> hopefully encourage the rightful holders of those blocks to 
> update their POC info and if not, it at least allows the rest 
> of the community to be mindful of such blocks.
> 
> > ? ?* ?An annual re-registration of all POCs (~223,000 
> currently) will
> > ? ? ?likely result in a vast increase in workload, particularly with
> > ? ? ?the follow up work and research involved when a POC does not 
> > reply
> > ? ? ?within 60 days. ?This could result in a slow down in 
> registration
> > ? ? ?response and processing times.
> 
> This proposal does not require a "re-registration of all POCs"
> annually.  It requires an email validation of all POCs 
> annually and that POCs which do not respond to email have 
> their record marked as such -- this is meant to be an 
> entirely automated process.  The policy then grants ARIN 
> staff the discretion to do follow up work and research on 
> POCs; it does not require that ARIN follow up on every (or 
> even any) unresponsive POC every year -- it is meant to allow 
> staff to follow up where they can/need and give them 
> authority to lock or remove POCs that are found to be 
> completely illegitimate (those that don't respond to repeated 
> and various contact attempts, etc).
> 
> > ? ?* This policy refers to the Bulk Whois policy rather than stating
> > ? ? ?the actual criteria under which an organization will 
> be allowed 
> > to
> > ? ? ?request the list of all address blocks with no valid POCs. ?It
> > ? ? ?would be better policy text to state the specific criteria,
> > ? ? ?including the requirement to sign an AUP, within this 
> policy itself.
> >
> 
> "ARIN will maintain, and make readily available to the 
> community, a current list of address-blocks with no valid 
> POC; this data will be subject to the current bulk WHOIS policy."
> 
> My understanding of this text is that the list of address blocks with
> no valid POCs should be available to anyone interested in it.    We
> chose to reference the Bulk WHOIS policy instead of 
> re-stating it here so as to maintain a central policy 
> regarding WHOIS data. 

Chris and I are two of the authors on this policy.

The statement:

"...this data will be subject to the current bulk WHOIS policy..."

was added so as to direct ARIN staff that the list of address blocks
without valid POC, discovered through this policy, was NOT to be considered
special, privileged information,
and it would not allow our policy proposal to be construed as granting
these "found" blocks any special "blocking" of this data within WHOIS.

It is my suggestion that people worried about hijackers finding stale blocks
create and submit a policy proposal that deals with making, or not making,
available such status in WHOIS.  Maybe you want it available via bulk but
not individual query - whatever.  You have to be aware that "non-virginial"
IPv4 blocks can be added into WHOIS from ARIN staff from OTHER PROCESSES
than our whois grooming policy proposal.

So, if your objection to our proposal is based on this hijacking thing,
then I submit that your barking up the wrong tree because "holes"
already exist right now in WHOIS data submission, and your not objecting
to them.

To see what I mean, issue these queries:

whois -h whois.arin.net 206.50.0.0
whois -h whois.arin.net 206.51.0.0
whois -h whois.arin.net 206.52.0.0

Note that 206.50 and 206.52 are both assigned to NTT but 206.51 is not.
That is because 206.51.0.0 was occupied by some other org that went
defunct - otherwise don't you think that NTT and ARIN would have both
wanted NTT to be assigned a contiguous block?

When the original owner of 206.51 disappeared, ARIN hasn't yet reassigned
that block - so it just removed all POC's from it and left the block
just floating in WHOIS.

This very-hijackable block only took me about 10 minutes to find, with WHOIS
queries issued by hand, by typing each one in.  So please, if the hijacking
thing is really your concern, then address it, and quit knocking our policy.

Ted



From martin.hannigan at batelnet.bs  Mon Mar 30 16:51:21 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Mon, 30 Mar 2009 16:51:21 -0400
Subject: [arin-ppml] Draft Policy 2009-3 (Global): Allocation of IPv4
	Blocks to Regional Internet Registries
In-Reply-To: <49D12E37.9040307@gmail.com>
References: <37137.208.54.95.48.1238379940.squirrel@webmail.lacnic.net.uy>
	<49D10949.9000803@arin.net> <49D11F48.6090905@gmail.com>
	<9EDA9B03-C069-44B5-B06D-D60E510849FE@lacnic.net>
	<4607e1d50903301318y3c142303g42a991f6be79b0a6@mail.gmail.com>
	<49D12E37.9040307@gmail.com>
Message-ID: <4607e1d50903301351o52e48c66n21163809fcf0f630@mail.gmail.com>

Scott,

You already pointed out that there was no consensus to move this
policy forward and there still appears to be none. You haven't
included not advancing this policy in the options that you provided to
the community either. You're pushing the line between fairness and
zealous advocacy quite hard from my perspective.


Best,

Martin



On 3/30/09, Scott Leibrand <scottleibrand at gmail.com> wrote:
> Running this policy through the process fairly is exactly what we're
> trying to do here.  I'm certainly not pushing for (or against)
> adoption.  (My opinion of the draft policy is rather nuanced: I can
> elaborate separately if you'd like.) While I don't think there is a
> consensus for adopting the original policy proposal, I also don't see a
> consensus for abandoning the proposal without first discussing it at a
> public policy meeting.
>
> In more general terms, the required level of support for advancing a
> policy proposal for discussion at the public policy meeting is much
> lower than the level of consensus required for adopting such a policy.
> If such consensus is not demonstrated at the public policy meeting, and
> there is no consensus among the community that the AC should continue
> working on the policy, then the AC is much more likely to vote to
> abandon the proposal at that time.
>
> -Scott
>
> Martin Hannigan wrote:
>> Scott,
>>
>> You indicated that there is no consensus with regards to this policy
>> advancing.  Why is this policy advancing at all then?  Regardless of
>> it being a global policy, there's no requirement to do anything other
>> than to run this policy through the process fairly. Failing to succeed
>> in that process is a sometimes expected result.
>>
>> A perception may be starting to develop that this policy isn't being
>> treated equally with regards to other policies I.e. continuing to be
>> pushed for discussion without support.
>>
>>
>> Best,
>>
>> Martin
>>
>>
>>
>> On 3/30/09, Raul Echeberria <raul at lacnic.net> wrote:
>>
>>> Thanks,
>>>
>>> Ra?l
>>>
>>>
>>>
>>> El 30/03/2009, a las 04:36 p.m., Scott Leibrand escribi?:
>>>
>>>
>>>> Raul,
>>>>
>>>> Given that it's too late to initiate a separate discussion petition
>>>> for the San Antonio meeting, I would like to assure you that I will
>>>> do what I can to make sure that we get feedback from the community
>>>> at that meeting as to the support for the original proposed text, as
>>>> well as for the revised version.  If there is a clear community
>>>> consensus in favor of either language, my own personal opinion is
>>>> that we'll be able to move the proposal forward, with any applicable
>>>> edits, at that point.
>>>>
>>>> In order to prepare for such discussion, I'd welcome feedback from
>>>> the PPML on the following questions:
>>>>
>>>> - Do you support the original proposed text of 2009-3, requiring
>>>> return of any reclaimed space to IANA for redistribution?  Why or
>>>> why not?
>>>> - Do you support the current modified text of 2009-3, requiring
>>>> return of any reclaimed legacy space, but making optional the return
>>>> of any non-legacy space?  Why or why not?
>>>> - Would you support some other revised version of 2009-3?  If so,
>>>> what would you want to change?  (For example, we could make all
>>>> returns optional, for both legacy and non-legacy space.)
>>>> - If you oppose 2009-3 completely, do you believe that current
>>>> policy is adequate, or would you support some other mechanism to
>>>> allow for the reallocation of IPv4 blocks between RIRs?
>>>>
>>>> Thanks,
>>>> Scott
>>>>
>>>> Member Services wrote:
>>>>
>>>>> Raul,
>>>>>
>>>>> According to the ARIN Policy Development Process the petition
>>>>> period for
>>>>> the upcoming San Antonio meeting closed on 13 March 2009. The
>>>>> deadline
>>>>> information was posted to PPML earlier this month, see the post:
>>>>> http://lists.arin.net/pipermail/arin-ppml/2009-March/013106.html
>>>>>
>>>>> The draft policy is under discussion, statements of support and
>>>>> opposition are welcome and appreciated. Both the discussion on the
>>>>> PPML
>>>>> and at the Public Policy Meeting will be used by the AC to
>>>>> determine the
>>>>> community consensus regarding adopting this as policy.
>>>>>
>>>>> The ARIN Policy Development Process can be found at:
>>>>> https://www.arin.net/policy/pdp.html
>>>>>
>>>>> Regards,
>>>>>
>>>>> Member Services
>>>>> American Registry for Internet Numbers (ARIN)
>>>>>
>>>>> raul at lacnic.net wrote:
>>>>>
>>>>>
>>>>>> Dear all:
>>>>>>
>>>>>> This proposal is a proposal for a global policy. It means that the
>>>>>> same
>>>>>> proposal has to be approved in every region. They can be approved
>>>>>> with
>>>>>> some wording differences, but the spirit of the proposal should be
>>>>>> the
>>>>>> same.
>>>>>>
>>>>>> The proposal was the result of a long collaboration effort of
>>>>>> senior staff
>>>>>> members and board members of all the 5 RIRs and the original text
>>>>>> is the
>>>>>> one that is being considered in every region.
>>>>>>
>>>>>> As far as I know the authors of the proposal were not consulted by
>>>>>> the
>>>>>> ARIN-AC and based on exchanges among the authors in the past few
>>>>>> days, I
>>>>>> can say that in general the feeling is that the changes introduced
>>>>>> by the
>>>>>> ARIN-AC are very signficant and so, this is a different proposal.
>>>>>>
>>>>>> My personal view is that changing the concept of a global policy
>>>>>> proposal
>>>>>> in one RIR means to avoid the approval of the policy. I strongly
>>>>>> encourage
>>>>>> ARIN to put the original proposal under consideration of its
>>>>>> community as
>>>>>> it is being done in the other regions. The proposal can be
>>>>>> approved or
>>>>>> not, That's part of the process, but it doesn't make sense to
>>>>>> approve a
>>>>>> different proposal. IMHO, the AC is able to put forward the new
>>>>>> proposal
>>>>>> for discussion if they consider that it is better, and in that way
>>>>>> to
>>>>>> start the process of discussion of a new global policy proposal.
>>>>>>
>>>>>> I have to confess that dealing with 5 different PDPs is not so
>>>>>> easy. I
>>>>>> don't know if a petition process should be started, If yes, please
>>>>>> take
>>>>>> this email as the request for initiating that process.
>>>>>>
>>>>>> Since this announcement was issued last Monday in the afternoon, I
>>>>>> am not
>>>>>> sure how the business days are counted, but I guess that I am
>>>>>> still within
>>>>>> the valid period.
>>>>>>
>>>>>> However, I think that as a practices, global policy proposals
>>>>>> should not
>>>>>> be changed by any advisory council or policy chair of one region
>>>>>> due to
>>>>>> the impact that to change the proposal produce in the global
>>>>>> process.
>>>>>>
>>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> Ra?l
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------
>>>>>>
>>>>>>
>>>>>>
>>>>>> El 23/03/2009, a las 04:05 p.m., Member Services escribi?:
>>>>>>
>>>>>> Draft Policy 2009-3 (Global)
>>>>>> Allocation of IPv4 Blocks to Regional Internet Registries
>>>>>>
>>>>>> The following draft policy text is being posted for feedback and
>>>>>> discussion on the Public Policy Mailing List (PPML).
>>>>>>
>>>>>> This draft policy was developed by the ARIN Advisory Council (AC)
>>>>>> from
>>>>>> Policy Proposal 82: Allocation of IPv4 Blocks to Regional Internet
>>>>>> Registries. The AC has taken the proposal and developed it into a
>>>>>> draft
>>>>>> policy. The AC was required to submit text to ARIN for staff and
>>>>>> legal
>>>>>> assessment prior to selecting it as a draft policy. The assessment,
>>>>>> along with the text that was assessed, is located below the draft
>>>>>> policy.
>>>>>>
>>>>>> On 20 March 2009 the ARIN Advisory Council (AC) selected Draft
>>>>>> Policy
>>>>>> 2009-3: Allocation of IPv4 Blocks to Regional Internet Registries
>>>>>> for
>>>>>> adoption discussion on the PPML and at the upcoming Public Policy
>>>>>> Meeting.
>>>>>>
>>>>>> Draft Policy 2009-3 is below and can be found at:
>>>>>> https://www.arin.net/policy/proposals/2009_3.html
>>>>>>
>>>>>> We encourage you to discuss Draft Policy 2009-3 on the PPML prior
>>>>>> to the
>>>>>> ARIN XXIII Public Policy Meeting. Both the discussion on the PPML
>>>>>> and at
>>>>>> the Public Policy Meeting will be used by the AC to determine the
>>>>>> community consensus regarding adopting this as policy.
>>>>>>
>>>>>> The ARIN Policy Development Process can be found at:
>>>>>> https://www.arin.net/policy/pdp.html
>>>>>>
>>>>>> All of the Draft Policies under discussion can be found at:
>>>>>> https://www.arin.net/policy/proposals/index.html
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Member Services
>>>>>> American Registry for Internet Numbers (ARIN)
>>>>>>
>>>>>>
>>>>>> ## * ##
>>>>>>
>>>>>>
>>>>>> Draft Policy 2009-3 (Global)
>>>>>> Allocation of IPv4 Blocks to Regional Internet Registries
>>>>>>
>>>>>> Date: 23 March 2009
>>>>>>
>>>>>> Policy statement:
>>>>>>
>>>>>> This document describes the policy governing the allocation of IPv4
>>>>>> address space from the IANA to the Regional Internet Registries
>>>>>> (RIRs).
>>>>>> This document does not stipulate performance requirements in the
>>>>>> provision of services by IANA to an RIR in accordance with this
>>>>>> policy.
>>>>>> Such requirements should be specified by appropriate agreements
>>>>>> among
>>>>>> the RIRs and ICANN.
>>>>>>
>>>>>> This policy is to be implemented in two phases.
>>>>>>
>>>>>> A. Phase I: Recovery of IPv4 Address Space
>>>>>>
>>>>>> Upon ratification of this policy by the ICANN Board of Directors the
>>>>>> IANA shall establish a mechanism to receive IPv4 address space
>>>>>> which is
>>>>>> returned to it by the RIRs, and hold that address space in a
>>>>>> 'recovered
>>>>>> IPv4 pool'.
>>>>>>
>>>>>> Each RIR through their respective chosen policies and strategies may
>>>>>> recover IPv4 address space which is under their administration. At
>>>>>> quarterly intervals, each RIR shall return to the IANA any legacy
>>>>>> address space recovered, and may return to the IANA any non-legacy
>>>>>> address space recovered, in aggregated blocks of /24 or larger, for
>>>>>> inclusion in the recovered IPv4 pool.
>>>>>>
>>>>>> During Phase I, no allocations will be made from the recovered IPv4
>>>>>> pool. Return of recovered address space (as described above) will
>>>>>> continue throughout Phase II.
>>>>>>
>>>>>> B. Phase II: Allocation of Recovered IPv4 address space by the IANA
>>>>>>
>>>>>> Upon ratification of this policy by the ICANN Board of Directors
>>>>>> and a
>>>>>> declaration by the IANA that its existing free pool of unallocated
>>>>>> IPv4
>>>>>> address space is depleted; Global Addressing Policy ASO-001-2
>>>>>> (adopted
>>>>>> by ICANN Board 8 April 2005) is rescinded. IANA will then commence
>>>>>> to
>>>>>> allocate the IPv4 address space from the recovered IPv4 pool.
>>>>>>
>>>>>> 1. The following definitions apply to this policy:
>>>>>>
>>>>>> a. Recovered Address Space. Recovered address space is that address
>>>>>> space that is returned to an RIR as a result of any activity that
>>>>>> seeks
>>>>>> to reclaim unused address space or is voluntarily returned to the
>>>>>> RIR or
>>>>>> is reclaimed by the RIR as a result of legal action or abuse
>>>>>> determination. Recovered address space does not include that address
>>>>>> space that is reclaimed because of non-payment of contractual fees
>>>>>> whose
>>>>>> reclamation date is less than 1 year at the time of the report.
>>>>>>
>>>>>> b. IPv4 Address Holdings. IPv4 address holdings are all
>>>>>> unallocated IPv4
>>>>>> address space held by an RIR to include recovered address space
>>>>>> not yet
>>>>>> returned less that address space that is committed in accordance
>>>>>> with
>>>>>> the RIR's reservation policy and practices.
>>>>>>
>>>>>> c. Aggregated address blocks. Aggregated address blocks are
>>>>>> contiguous
>>>>>> prefixes that can be aggregated on natural bit boundaries.
>>>>>> 10.0.0.0/24
>>>>>> and 10.0.1.0/24 are two contiguous prefixes that can be combined
>>>>>> to form
>>>>>> an aggregated address block. 10.0.0.0/24 and 10.0.1.0/25 are two
>>>>>> contiguous prefixes that cannot be combined on a natural bit
>>>>>> boundary to
>>>>>> form an aggregated block.
>>>>>>
>>>>>> d. Legacy address space. IPv4 address space allocated or assigned
>>>>>> prior
>>>>>> to the creation of the RIR.
>>>>>>
>>>>>> 2. Allocation of IPv4 Address Space
>>>>>>
>>>>>> a. For the purposes of this policy, an 'IPv4 allocation period' is
>>>>>> defined as a 6-month period following 1 March or 1 September in
>>>>>> each year.
>>>>>>
>>>>>> b. At the beginning of each IPv4 allocation period, the IANA will
>>>>>> determine the 'IPv4 allocation unit' for that period, as 1/10 of its
>>>>>> IPv4 address pool, rounded down to the next CIDR (power-of-2)
>>>>>> boundary.
>>>>>> The minimum 'IPv4 allocation unit' size will be a /24.
>>>>>>
>>>>>> c. In each allocation period, each RIR may issue one IPv4 request
>>>>>> to the
>>>>>> IANA. Providing that the RIR satisfies the allocation criteria
>>>>>> described
>>>>>> in paragraph B.2, the IANA will allocate a single allocation unit,
>>>>>> composed of the smallest possible number of blocks available in
>>>>>> its IPv4
>>>>>> address pool.
>>>>>>
>>>>>> 3. IPv4 Address Space Allocation Criteria
>>>>>>
>>>>>> A RIR is eligible to receive additional IPv4 address space from
>>>>>> the IANA
>>>>>> when the total of its IPv4 address holdings is less than 50% of the
>>>>>> current IPv4 allocation unit, and providing that it has not already
>>>>>> received an IPv4 allocation from the IANA during the current IPv4
>>>>>> allocation period.
>>>>>>
>>>>>> 4. Initial Allocation of IPv4 Address Space
>>>>>>
>>>>>> Each new RIR shall, at the moment of recognition, be allocated one
>>>>>> (1)
>>>>>> allocation unit by the IANA. If an allocation unit is not available,
>>>>>> then the IANA will issue this block as soon as one is available.
>>>>>> This
>>>>>> allocation will be made regardless of the newly formed RIR's
>>>>>> projected
>>>>>> utilization figures and shall be independent of the IPv4 address
>>>>>> space
>>>>>> that may have been transferred to the new RIR by the already
>>>>>> existing
>>>>>> RIRs as part of the formal transition process.
>>>>>>
>>>>>> 5. Reporting
>>>>>>
>>>>>> a. All returned space is to be recorded in an IANA-published log
>>>>>> of IPv4
>>>>>> address space transactions, with each log entry detailing the
>>>>>> returned
>>>>>> address block, the date of the return, and the returning RIR.
>>>>>>
>>>>>> b. All allocated space is also to be recorded in this IANA-
>>>>>> published log
>>>>>> of IPv4 address space transactions, with each log entry detailing
>>>>>> the
>>>>>> address blocks, the date of the allocation and the recipient RIR.
>>>>>>
>>>>>> c. The IANA will maintain a public registry of the current
>>>>>> disposition
>>>>>> of all IPv4 address space, detailing all reservations and current
>>>>>> allocations and current IANA-held address space that is unallocated.
>>>>>>
>>>>>> d) The IANA may make public announcements of IPv4 address block
>>>>>> transactions that occur under this policy. The IANA will make
>>>>>> appropriate modifications to the "Internet Protocol V4 Address
>>>>>> Space"
>>>>>> page of the IANA website and may make announcements to its own
>>>>>> appropriate announcement lists. The IANA announcements will be
>>>>>> limited
>>>>>> to which address ranges, the time of allocation and to which
>>>>>> Registry
>>>>>> they have been allocated.
>>>>>>
>>>>>>
>>>>>>
>>>>>> #####
>>>>>>
>>>>>> ARIN Staff Assessment
>>>>>>
>>>>>> *Title: Allocation of IPv4 Blocks to the Regional Internet
>>>>>> Registries*
>>>>>>
>>>>>> *Proposal Submitted: 30 Jan 2009*
>>>>>>
>>>>>> *Revision Submitted: 05 March 2009*
>>>>>>
>>>>>> *Date of Assessment: 10 March 2009*
>>>>>>
>>>>>> * *
>>>>>>
>>>>>> I. Understanding of the Policy:
>>>>>>
>>>>>> *Staff Understanding of the Proposal:*
>>>>>>
>>>>>> Staff understands that this proposal would be implemented in 2
>>>>>> phases.
>>>>>> Phase 1 would require the RIRs to return recovered IPv4 legacy
>>>>>> address
>>>>>> space (via policy or procedure) to the IANA and have the option of
>>>>>> returning recovered non-legacy address space to the IANA. Phase 2
>>>>>> would
>>>>>> start after the depletion of the IANA free pool and would nullify
>>>>>> the
>>>>>> existing IANA to RIR policy (Global Addressing Policy ASO-001-2).
>>>>>> The
>>>>>> new IANA to RIR policy would allow each RIR to receive approximately
>>>>>> 1/10th of the recovered IPv4 pool from IANA once every 6 months as
>>>>>> long
>>>>>> as it meets the qualification criteria written in paragraph B2. IANA
>>>>>> will be required to keep a log of all returned IPv4 address space
>>>>>> and
>>>>>> all issued IPv4 address space from the recovered pool, as well as
>>>>>> maintain a public registry of the current disposition of all IPv4
>>>>>> address space.
>>>>>>
>>>>>> II. Comments
>>>>>>
>>>>>> A. ARIN Staff Comments
>>>>>>
>>>>>> * The one policy that this impacts is NRPM 4.6 Amnesty and
>>>>>>  Aggregation, which says ?Transactions should only be accepted
>>>>>>  under this policy if they are in the interests of the community
>>>>>>  (e.g. they improve aggregation or result in a net reclamation of
>>>>>>  space).? Because the ARIN region holds the majority of the legacy
>>>>>>  address space, and most of the address space returned under this
>>>>>>  policy is legacy space, it would mean that there would be no ?net
>>>>>>  return? of address space to ARIN. ARIN would essentially be
>>>>>>  exchanging legacy address space for non-legacy address space, and
>>>>>>  returning the legacy address space it received in the exchange to
>>>>>>  IANA, resulting in a net loss of address space in ARIN?s available
>>>>>>  pool.
>>>>>>
>>>>>> B. ARIN General Counsel Comments:
>>>>>>
>>>>>> The current basis of allocation of numbers was established in
>>>>>> RFC's 2008
>>>>>> and 2050 and is need based. If one region has greater needs than
>>>>>> another, the current policy of IANA does not require equal
>>>>>> distribution
>>>>>> to all RIR's s. This proposed policy would establish a different
>>>>>> political and not needs based method for allocating returned
>>>>>> space. It
>>>>>> would make each RIR an equal recipient of such space. But the
>>>>>> level of
>>>>>> need and economic activity between each RI R is not equal. This
>>>>>> policy
>>>>>> will tend to reallocate returned space away from where it is
>>>>>> recovered,
>>>>>> in the ARIN region , and move more of it to AFRINIC and LACNIC than
>>>>>> current distribution principles. By equating the smaller economies
>>>>>> and
>>>>>> related needs of certain regions to the needs of other regions, like
>>>>>> ARIN, that have greater day to day need, it in effect creates a new
>>>>>> political order of distribution thru equal shares. It is possible
>>>>>> sovereign governments in the regions with greater activity will not
>>>>>> agree to such a revised distribution model. The proposed policy
>>>>>> undermines the legal rationale for distribution.
>>>>>>
>>>>>> The policy also creates a powerful disincentive for any RIR,
>>>>>> including
>>>>>> ARIN, to undertake any financial expenditure of RIR dollars for
>>>>>> programs
>>>>>> intended to obtain returned space for reallocation. Currently ARIN
>>>>>> is
>>>>>> working towards policies such as the LRSA and 2008-6, intended to
>>>>>> encourage returns and use of under utilized resources, but which
>>>>>> cost
>>>>>> ARIN expenditures other RIRs are not duplicating. Any policy which
>>>>>> creates such a disincentive by leaving expenditures with a single
>>>>>> RIR,
>>>>>> who cannot benefit except to receive 20% of the returned space
>>>>>> should be
>>>>>> carefully considered.
>>>>>>
>>>>>> Finally, it is likely entities with number resources in the ARIN
>>>>>> region
>>>>>> may be willing to return those resources for uses in the region but
>>>>>> unwilling to do so if 4/5 of such resources will be sent to other
>>>>>> regions.
>>>>>>
>>>>>> III. Resource Impact
>>>>>>
>>>>>> The resource impact of implementing this policy is viewed as
>>>>>> minimal. It
>>>>>> is estimated that this policy could require up to 3 person months of
>>>>>> effort to implement following ratification by the ARIN Board of
>>>>>> Trustees. Because this implementation is not planned, it may preempt
>>>>>> ARIN?s current project deployment schedule. It may require the
>>>>>> following:
>>>>>>
>>>>>> * Modifications to existing registration procedures to include the
>>>>>>  handling of returned/reclaimed address space and the process of
>>>>>>  requesting additional address space from the IANA.
>>>>>> * Staff training
>>>>>>
>>>>>> Text assessed:
>>>>>>
>>>>>> *Allocation of IPv4 Blocks to Regional Internet Registries (Global)*
>>>>>>
>>>>>> *Policy statement:*
>>>>>>
>>>>>> This document describes the policy governing the allocation of IPv4
>>>>>> address space from the IANA to the Regional Internet Registries
>>>>>> (RIRs).
>>>>>> This document does not stipulate performance requirements in the
>>>>>> provision of services by IANA to an RIR in accordance with this
>>>>>> policy.
>>>>>> Such requirements should be specified by appropriate agreements
>>>>>> among
>>>>>> the RIRs and ICANN.
>>>>>>
>>>>>> This policy is to be implemented in two phases.
>>>>>>
>>>>>> A. Phase I: Recovery of IPv4 Address Space
>>>>>>
>>>>>> Upon ratification of this policy by the ICANN Board of Directors the
>>>>>> IANA shall establish a mechanism to receive IPv4 address space
>>>>>> which is
>>>>>> returned to it by the RIRs, and hold that address space in a
>>>>>> 'recovered
>>>>>> IPv4 pool'.
>>>>>>
>>>>>> Each RIR through their respective chosen policies and strategies may
>>>>>> recover IPv4 address space which is under their administration. At
>>>>>> quarterly intervals, each RIR shall return any legacy address space
>>>>>> recovered, and may return any non-legacy address space recovered,
>>>>>> to the
>>>>>> IANA in aggregated blocks of /24 or larger, for inclusion in the
>>>>>> recovered IPv4 pool.
>>>>>>
>>>>>> During Phase I, no allocations will be made from the recovered IPv4
>>>>>> pool. Return of recovered address space (as described above) will
>>>>>> continue throughout Phase II.
>>>>>>
>>>>>> B. Phase II: Allocation of Recovered IPv4 address space by the IANA
>>>>>>
>>>>>> Upon ratification of this policy by the ICANN Board of Directors
>>>>>> and a
>>>>>> declaration by the IANA that its existing free pool of unallocated
>>>>>> IPv4
>>>>>> address space is depleted; Global Addressing Policy ASO-001-2
>>>>>> (adopted
>>>>>> by ICANN Board 8 April 2005) is rescinded. IANA will then commence
>>>>>> to
>>>>>> allocate the IPv4 address space from the recovered IPv4 pool.
>>>>>>
>>>>>> 1. The following definitions apply to this policy:
>>>>>>
>>>>>> a. Recovered Address Space. Recovered address space is that address
>>>>>> space that is returned to an RIR as a result of any activity that
>>>>>> seeks
>>>>>> to reclaim unused address space or is voluntarily returned to the
>>>>>> RIR or
>>>>>> is reclaimed by the RIR as a result of legal action or abuse
>>>>>> determination. Recovered address space does not include that address
>>>>>> space that is reclaimed because of non-payment of contractual fees
>>>>>> whose
>>>>>> reclamation date is less than 1 year at the time of the report.
>>>>>>
>>>>>> b. IPv4 Address Holdings. IPv4 address holdings are all
>>>>>> unallocated IPv4
>>>>>> address space held by an RIR to include recovered address space
>>>>>> not yet
>>>>>> returned less that address space that is committed in accordance
>>>>>> with
>>>>>> the RIR's reservation policy and practices.
>>>>>>
>>>>>> c. Legacy address space. IPv4 address space allocated or assigned
>>>>>> prior
>>>>>> to the creation of the RIR.
>>>>>>
>>>>>> 2. Allocation of IPv4 Address Space
>>>>>>
>>>>>> a. For the purposes of this policy, an 'IPv4 allocation period' is
>>>>>> defined as a 6-month period following 1 March or 1 September in
>>>>>> each year.
>>>>>>
>>>>>> b. At the beginning of each IPv4 allocation period, the IANA will
>>>>>> determine the 'IPv4 allocation unit' for that period, as 1/10 of its
>>>>>> IPv4 address pool, rounded down to the next CIDR (power-of-2)
>>>>>> boundary.
>>>>>>
>>>>>> c. In each allocation period, each RIR may issue one IPv4 request
>>>>>> to the
>>>>>> IANA. Providing that the RIR satisfies the allocation criteria
>>>>>> described
>>>>>> in paragraph B.2, the IANA will allocate a single allocation unit,
>>>>>> composed of the smallest possible number of blocks available in
>>>>>> its IPv4
>>>>>> address pool.
>>>>>>
>>>>>> 3. IPv4 Address Space Allocation Criteria
>>>>>>
>>>>>> A RIR is eligible to receive additional IPv4 address space from
>>>>>> the IANA
>>>>>> when the total of its IPv4 address holdings is less than 50% of the
>>>>>> current IPv4 allocation unit, and providing that it has not already
>>>>>> received an IPv4 allocation from the IANA during the current IPv4
>>>>>> allocation period.
>>>>>>
>>>>>> 4. Initial Allocation of IPv4 Address Space
>>>>>>
>>>>>> Each new RIR shall, at the moment of recognition, be allocated one
>>>>>> (1)
>>>>>> allocation unit by the IANA. If an allocation unit is not available,
>>>>>> then the IANA will issue this block as soon as one is available.
>>>>>> This
>>>>>> allocation will be made regardless of the newly formed RIR's
>>>>>> projected
>>>>>> utilization figures and shall be independent of the IPv4 address
>>>>>> space
>>>>>> that may have been transferred to the new RIR by the already
>>>>>> existing
>>>>>> RIRs as part of the formal transition process.
>>>>>>
>>>>>> 5. Reporting
>>>>>>
>>>>>> a. All returned space is to be recorded in an IANA-published log
>>>>>> of IPv4
>>>>>> address space transactions, with each log entry detailing the
>>>>>> returned
>>>>>> address block, the date of the return, and the returning RIR.
>>>>>>
>>>>>> b. All allocated space is also to be recorded in this IANA-
>>>>>> published log
>>>>>> of IPv4 address space transactions, with each log entry detailing
>>>>>> the
>>>>>> address blocks, the date of the allocation and the recipient RIR.
>>>>>>
>>>>>> c. The IANA will maintain a public registry of the current
>>>>>> disposition
>>>>>> of all IPv4 address space, detailing all reservations and current
>>>>>> allocations and current IANA-held address space that is unallocated.
>>>>>>
>>>>>> d) The IANA may make public announcements of IPv4 address block
>>>>>> transactions that occur under this policy. The IANA will make
>>>>>> appropriate modifications to the "Internet Protocol V4 Address
>>>>>> Space"
>>>>>> page of the IANA website and may make announcements to its own
>>>>>> appropriate announcement lists. The IANA announcements will be
>>>>>> limited
>>>>>> to which address ranges, the time of allocation and to which
>>>>>> Registry
>>>>>> they have been allocated.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> PPML
>>>>>> You are receiving this message because you are subscribed to
>>>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>>>>> Unsubscribe or manage your mailing list subscription at:
>>>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>>>> Please contact info at arin.net if you experience any issues.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> PPML
>>>>> You are receiving this message because you are subscribed to
>>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>>>> Unsubscribe or manage your mailing list subscription at:
>>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>>> Please contact info at arin.net if you experience any issues.
>>>>>
>>>>>
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>>>
>>>
>>
>>
>

-- 
Sent from my mobile device


From farmer at umn.edu  Mon Mar 30 17:03:29 2009
From: farmer at umn.edu (David Farmer)
Date: Mon, 30 Mar 2009 16:03:29 -0500
Subject: [arin-ppml] Draft Policy 2009-3 (Global): Allocation of IPv4
	Blocks to Regional Internet Registries
In-Reply-To: <4607e1d50903301318y3c142303g42a991f6be79b0a6@mail.gmail.com>
References: <37137.208.54.95.48.1238379940.squirrel@webmail.lacnic.net.uy>,
	<9EDA9B03-C069-44B5-B06D-D60E510849FE@lacnic.net>,
	<4607e1d50903301318y3c142303g42a991f6be79b0a6@mail.gmail.com>
Message-ID: <49D0ED51.20718.ECD2165@farmer.umn.edu>

I don't read that Scott was saying that there is no consensus 
with regards to this Draft Proposal.  The AC made edits and 
moved the proposal forward to discussion for adoption, all be it 
with minimum consensus within the AC.  Even though I did not 
support moving this forward either the original or the edited 
versions, to the best of my understanding of the new PDP, the 
process was followed.

This exchange has been in regards to a Discussion Petition, to 
include the original version of the Proposal in the PPM for 
discussion for adoption, and that petition process by no means 
requires a consensus of the community it only requires 10 
people to support the petition.  

Further, personally I see some serious timing issues in the 
PDP process especially around the Discussion Petition.  The 
AC seems to be allowed to Publish Draft Proposals, after the 
deadline for a petition.  This seems problematic to me and 
several others I believe, the AC is collecting several tweaks we 
are going to suggest to the PDP, if you have suggestions send 
them our way.  

So while I do not support the original policy proposal as written, 
or even the edited draft policy, I do think it is unfortunate that 
Raul will not be able to petition, and what Scott proposes 
seems reasonable to me.

I will provide some comments on the text in a separate email.    

On 30 Mar 2009 Martin Hannigan wrote:

> Scott,
> 
> You indicated that there is no consensus with regards to this policy
> advancing.  Why is this policy advancing at all then?  Regardless of
> it being a global policy, there's no requirement to do anything other
> than to run this policy through the process fairly. Failing to succeed
> in that process is a sometimes expected result.
> 
> A perception may be starting to develop that this policy isn't being
> treated equally with regards to other policies I.e. continuing to be
> pushed for discussion without support.
> 
> 
> Best,
> 
> Martin
> 
> 
> 
> On 3/30/09, Raul Echeberria <raul at lacnic.net> wrote:
> >
> > Thanks,
> >
> > Ra?l
> >
> >
> >
> > El 30/03/2009, a las 04:36 p.m., Scott Leibrand escribi?:
> >
> >> Raul,
> >>
> >> Given that it's too late to initiate a separate discussion petition
> >> for the San Antonio meeting, I would like to assure you that I will
> >> do what I can to make sure that we get feedback from the community
> >> at that meeting as to the support for the original proposed text, as
> >> well as for the revised version.  If there is a clear community
> >> consensus in favor of either language, my own personal opinion is
> >> that we'll be able to move the proposal forward, with any applicable
> >> edits, at that point.
> >>
> >> In order to prepare for such discussion, I'd welcome feedback from
> >> the PPML on the following questions:
> >>
> >> - Do you support the original proposed text of 2009-3, requiring
> >> return of any reclaimed space to IANA for redistribution?  Why or
> >> why not?
> >> - Do you support the current modified text of 2009-3, requiring
> >> return of any reclaimed legacy space, but making optional the return
> >> of any non-legacy space?  Why or why not?
> >> - Would you support some other revised version of 2009-3?  If so,
> >> what would you want to change?  (For example, we could make all
> >> returns optional, for both legacy and non-legacy space.)
> >> - If you oppose 2009-3 completely, do you believe that current
> >> policy is adequate, or would you support some other mechanism to
> >> allow for the reallocation of IPv4 blocks between RIRs?
> >>
> >> Thanks,
> >> Scott
> >>
> >> Member Services wrote:
> >>> Raul,
> >>>
> >>> According to the ARIN Policy Development Process the petition
> >>> period for
> >>> the upcoming San Antonio meeting closed on 13 March 2009. The
> >>> deadline
> >>> information was posted to PPML earlier this month, see the post:
> >>> http://lists.arin.net/pipermail/arin-ppml/2009-March/013106.html
> >>>
> >>> The draft policy is under discussion, statements of support and
> >>> opposition are welcome and appreciated. Both the discussion on the
> >>> PPML
> >>> and at the Public Policy Meeting will be used by the AC to
> >>> determine the
> >>> community consensus regarding adopting this as policy.
> >>>
> >>> The ARIN Policy Development Process can be found at:
> >>> https://www.arin.net/policy/pdp.html
> >>>
> >>> Regards,
> >>>
> >>> Member Services
> >>> American Registry for Internet Numbers (ARIN)
> >>>
> >>> raul at lacnic.net wrote:
> >>>
> >>>> Dear all:
> >>>>
> >>>> This proposal is a proposal for a global policy. It means that the
> >>>> same
> >>>> proposal has to be approved in every region. They can be approved
> >>>> with
> >>>> some wording differences, but the spirit of the proposal should be
> >>>> the
> >>>> same.
> >>>>
> >>>> The proposal was the result of a long collaboration effort of
> >>>> senior staff
> >>>> members and board members of all the 5 RIRs and the original text
> >>>> is the
> >>>> one that is being considered in every region.
> >>>>
> >>>> As far as I know the authors of the proposal were not consulted by
> >>>> the
> >>>> ARIN-AC and based on exchanges among the authors in the past few
> >>>> days, I
> >>>> can say that in general the feeling is that the changes introduced
> >>>> by the
> >>>> ARIN-AC are very signficant and so, this is a different proposal.
> >>>>
> >>>> My personal view is that changing the concept of a global policy
> >>>> proposal
> >>>> in one RIR means to avoid the approval of the policy. I strongly
> >>>> encourage
> >>>> ARIN to put the original proposal under consideration of its
> >>>> community as
> >>>> it is being done in the other regions. The proposal can be
> >>>> approved or
> >>>> not, That's part of the process, but it doesn't make sense to
> >>>> approve a
> >>>> different proposal. IMHO, the AC is able to put forward the new
> >>>> proposal
> >>>> for discussion if they consider that it is better, and in that way
> >>>> to
> >>>> start the process of discussion of a new global policy proposal.
> >>>>
> >>>> I have to confess that dealing with 5 different PDPs is not so
> >>>> easy. I
> >>>> don't know if a petition process should be started, If yes, please
> >>>> take
> >>>> this email as the request for initiating that process.
> >>>>
> >>>> Since this announcement was issued last Monday in the afternoon, I
> >>>> am not
> >>>> sure how the business days are counted, but I guess that I am
> >>>> still within
> >>>> the valid period.
> >>>>
> >>>> However, I think that as a practices, global policy proposals
> >>>> should not
> >>>> be changed by any advisory council or policy chair of one region
> >>>> due to
> >>>> the impact that to change the proposal produce in the global
> >>>> process.
> >>>>
> >>>>
> >>>> Best Regards,
> >>>>
> >>>> Ra?l
> >>>>
> >>>>
> >>>>
> >>>> ---------------
> >>>>
> >>>>
> >>>>
> >>>> El 23/03/2009, a las 04:05 p.m., Member Services escribi?:
> >>>>
> >>>> Draft Policy 2009-3 (Global)
> >>>> Allocation of IPv4 Blocks to Regional Internet Registries
> >>>>
> >>>> The following draft policy text is being posted for feedback and
> >>>> discussion on the Public Policy Mailing List (PPML).
> >>>>
> >>>> This draft policy was developed by the ARIN Advisory Council (AC)
> >>>> from
> >>>> Policy Proposal 82: Allocation of IPv4 Blocks to Regional Internet
> >>>> Registries. The AC has taken the proposal and developed it into a
> >>>> draft
> >>>> policy. The AC was required to submit text to ARIN for staff and
> >>>> legal
> >>>> assessment prior to selecting it as a draft policy. The assessment,
> >>>> along with the text that was assessed, is located below the draft
> >>>> policy.
> >>>>
> >>>> On 20 March 2009 the ARIN Advisory Council (AC) selected Draft
> >>>> Policy
> >>>> 2009-3: Allocation of IPv4 Blocks to Regional Internet Registries
> >>>> for
> >>>> adoption discussion on the PPML and at the upcoming Public Policy
> >>>> Meeting.
> >>>>
> >>>> Draft Policy 2009-3 is below and can be found at:
> >>>> https://www.arin.net/policy/proposals/2009_3.html
> >>>>
> >>>> We encourage you to discuss Draft Policy 2009-3 on the PPML prior
> >>>> to the
> >>>> ARIN XXIII Public Policy Meeting. Both the discussion on the PPML
> >>>> and at
> >>>> the Public Policy Meeting will be used by the AC to determine the
> >>>> community consensus regarding adopting this as policy.
> >>>>
> >>>> The ARIN Policy Development Process can be found at:
> >>>> https://www.arin.net/policy/pdp.html
> >>>>
> >>>> All of the Draft Policies under discussion can be found at:
> >>>> https://www.arin.net/policy/proposals/index.html
> >>>>
> >>>> Regards,
> >>>>
> >>>> Member Services
> >>>> American Registry for Internet Numbers (ARIN)
> >>>>
> >>>>
> >>>> ## * ##
> >>>>
> >>>>
> >>>> Draft Policy 2009-3 (Global)
> >>>> Allocation of IPv4 Blocks to Regional Internet Registries
> >>>>
> >>>> Date: 23 March 2009
> >>>>
> >>>> Policy statement:
> >>>>
> >>>> This document describes the policy governing the allocation of IPv4
> >>>> address space from the IANA to the Regional Internet Registries
> >>>> (RIRs).
> >>>> This document does not stipulate performance requirements in the
> >>>> provision of services by IANA to an RIR in accordance with this
> >>>> policy.
> >>>> Such requirements should be specified by appropriate agreements
> >>>> among
> >>>> the RIRs and ICANN.
> >>>>
> >>>> This policy is to be implemented in two phases.
> >>>>
> >>>> A. Phase I: Recovery of IPv4 Address Space
> >>>>
> >>>> Upon ratification of this policy by the ICANN Board of Directors the
> >>>> IANA shall establish a mechanism to receive IPv4 address space
> >>>> which is
> >>>> returned to it by the RIRs, and hold that address space in a
> >>>> 'recovered
> >>>> IPv4 pool'.
> >>>>
> >>>> Each RIR through their respective chosen policies and strategies may
> >>>> recover IPv4 address space which is under their administration. At
> >>>> quarterly intervals, each RIR shall return to the IANA any legacy
> >>>> address space recovered, and may return to the IANA any non-legacy
> >>>> address space recovered, in aggregated blocks of /24 or larger, for
> >>>> inclusion in the recovered IPv4 pool.
> >>>>
> >>>> During Phase I, no allocations will be made from the recovered IPv4
> >>>> pool. Return of recovered address space (as described above) will
> >>>> continue throughout Phase II.
> >>>>
> >>>> B. Phase II: Allocation of Recovered IPv4 address space by the IANA
> >>>>
> >>>> Upon ratification of this policy by the ICANN Board of Directors
> >>>> and a
> >>>> declaration by the IANA that its existing free pool of unallocated
> >>>> IPv4
> >>>> address space is depleted; Global Addressing Policy ASO-001-2
> >>>> (adopted
> >>>> by ICANN Board 8 April 2005) is rescinded. IANA will then commence
> >>>> to
> >>>> allocate the IPv4 address space from the recovered IPv4 pool.
> >>>>
> >>>> 1. The following definitions apply to this policy:
> >>>>
> >>>> a. Recovered Address Space. Recovered address space is that address
> >>>> space that is returned to an RIR as a result of any activity that
> >>>> seeks
> >>>> to reclaim unused address space or is voluntarily returned to the
> >>>> RIR or
> >>>> is reclaimed by the RIR as a result of legal action or abuse
> >>>> determination. Recovered address space does not include that address
> >>>> space that is reclaimed because of non-payment of contractual fees
> >>>> whose
> >>>> reclamation date is less than 1 year at the time of the report.
> >>>>
> >>>> b. IPv4 Address Holdings. IPv4 address holdings are all
> >>>> unallocated IPv4
> >>>> address space held by an RIR to include recovered address space
> >>>> not yet
> >>>> returned less that address space that is committed in accordance
> >>>> with
> >>>> the RIR's reservation policy and practices.
> >>>>
> >>>> c. Aggregated address blocks. Aggregated address blocks are
> >>>> contiguous
> >>>> prefixes that can be aggregated on natural bit boundaries.
> >>>> 10.0.0.0/24
> >>>> and 10.0.1.0/24 are two contiguous prefixes that can be combined
> >>>> to form
> >>>> an aggregated address block. 10.0.0.0/24 and 10.0.1.0/25 are two
> >>>> contiguous prefixes that cannot be combined on a natural bit
> >>>> boundary to
> >>>> form an aggregated block.
> >>>>
> >>>> d. Legacy address space. IPv4 address space allocated or assigned
> >>>> prior
> >>>> to the creation of the RIR.
> >>>>
> >>>> 2. Allocation of IPv4 Address Space
> >>>>
> >>>> a. For the purposes of this policy, an 'IPv4 allocation period' is
> >>>> defined as a 6-month period following 1 March or 1 September in
> >>>> each year.
> >>>>
> >>>> b. At the beginning of each IPv4 allocation period, the IANA will
> >>>> determine the 'IPv4 allocation unit' for that period, as 1/10 of its
> >>>> IPv4 address pool, rounded down to the next CIDR (power-of-2)
> >>>> boundary.
> >>>> The minimum 'IPv4 allocation unit' size will be a /24.
> >>>>
> >>>> c. In each allocation period, each RIR may issue one IPv4 request
> >>>> to the
> >>>> IANA. Providing that the RIR satisfies the allocation criteria
> >>>> described
> >>>> in paragraph B.2, the IANA will allocate a single allocation unit,
> >>>> composed of the smallest possible number of blocks available in
> >>>> its IPv4
> >>>> address pool.
> >>>>
> >>>> 3. IPv4 Address Space Allocation Criteria
> >>>>
> >>>> A RIR is eligible to receive additional IPv4 address space from
> >>>> the IANA
> >>>> when the total of its IPv4 address holdings is less than 50% of the
> >>>> current IPv4 allocation unit, and providing that it has not already
> >>>> received an IPv4 allocation from the IANA during the current IPv4
> >>>> allocation period.
> >>>>
> >>>> 4. Initial Allocation of IPv4 Address Space
> >>>>
> >>>> Each new RIR shall, at the moment of recognition, be allocated one
> >>>> (1)
> >>>> allocation unit by the IANA. If an allocation unit is not available,
> >>>> then the IANA will issue this block as soon as one is available.
> >>>> This
> >>>> allocation will be made regardless of the newly formed RIR's
> >>>> projected
> >>>> utilization figures and shall be independent of the IPv4 address
> >>>> space
> >>>> that may have been transferred to the new RIR by the already
> >>>> existing
> >>>> RIRs as part of the formal transition process.
> >>>>
> >>>> 5. Reporting
> >>>>
> >>>> a. All returned space is to be recorded in an IANA-published log
> >>>> of IPv4
> >>>> address space transactions, with each log entry detailing the
> >>>> returned
> >>>> address block, the date of the return, and the returning RIR.
> >>>>
> >>>> b. All allocated space is also to be recorded in this IANA-
> >>>> published log
> >>>> of IPv4 address space transactions, with each log entry detailing
> >>>> the
> >>>> address blocks, the date of the allocation and the recipient RIR.
> >>>>
> >>>> c. The IANA will maintain a public registry of the current
> >>>> disposition
> >>>> of all IPv4 address space, detailing all reservations and current
> >>>> allocations and current IANA-held address space that is unallocated.
> >>>>
> >>>> d) The IANA may make public announcements of IPv4 address block
> >>>> transactions that occur under this policy. The IANA will make
> >>>> appropriate modifications to the "Internet Protocol V4 Address
> >>>> Space"
> >>>> page of the IANA website and may make announcements to its own
> >>>> appropriate announcement lists. The IANA announcements will be
> >>>> limited
> >>>> to which address ranges, the time of allocation and to which
> >>>> Registry
> >>>> they have been allocated.
> >>>>
> >>>>
> >>>>
> >>>> #####
> >>>>
> >>>> ARIN Staff Assessment
> >>>>
> >>>> *Title: Allocation of IPv4 Blocks to the Regional Internet
> >>>> Registries*
> >>>>
> >>>> *Proposal Submitted: 30 Jan 2009*
> >>>>
> >>>> *Revision Submitted: 05 March 2009*
> >>>>
> >>>> *Date of Assessment: 10 March 2009*
> >>>>
> >>>> * *
> >>>>
> >>>> I. Understanding of the Policy:
> >>>>
> >>>> *Staff Understanding of the Proposal:*
> >>>>
> >>>> Staff understands that this proposal would be implemented in 2
> >>>> phases.
> >>>> Phase 1 would require the RIRs to return recovered IPv4 legacy
> >>>> address
> >>>> space (via policy or procedure) to the IANA and have the option of
> >>>> returning recovered non-legacy address space to the IANA. Phase 2
> >>>> would
> >>>> start after the depletion of the IANA free pool and would nullify
> >>>> the
> >>>> existing IANA to RIR policy (Global Addressing Policy ASO-001-2).
> >>>> The
> >>>> new IANA to RIR policy would allow each RIR to receive approximately
> >>>> 1/10th of the recovered IPv4 pool from IANA once every 6 months as
> >>>> long
> >>>> as it meets the qualification criteria written in paragraph B2. IANA
> >>>> will be required to keep a log of all returned IPv4 address space
> >>>> and
> >>>> all issued IPv4 address space from the recovered pool, as well as
> >>>> maintain a public registry of the current disposition of all IPv4
> >>>> address space.
> >>>>
> >>>> II. Comments
> >>>>
> >>>> A. ARIN Staff Comments
> >>>>
> >>>> * The one policy that this impacts is NRPM 4.6 Amnesty and
> >>>>  Aggregation, which says "Transactions should only be accepted
> >>>>  under this policy if they are in the interests of the community
> >>>>  (e.g. they improve aggregation or result in a net reclamation of
> >>>>  space)." Because the ARIN region holds the majority of the legacy
> >>>>  address space, and most of the address space returned under this
> >>>>  policy is legacy space, it would mean that there would be no "net
> >>>>  return" of address space to ARIN. ARIN would essentially be
> >>>>  exchanging legacy address space for non-legacy address space, and
> >>>>  returning the legacy address space it received in the exchange to
> >>>>  IANA, resulting in a net loss of address space in ARIN?s available
> >>>>  pool.
> >>>>
> >>>> B. ARIN General Counsel Comments:
> >>>>
> >>>> The current basis of allocation of numbers was established in
> >>>> RFC's 2008
> >>>> and 2050 and is need based. If one region has greater needs than
> >>>> another, the current policy of IANA does not require equal
> >>>> distribution
> >>>> to all RIR's s. This proposed policy would establish a different
> >>>> political and not needs based method for allocating returned
> >>>> space. It
> >>>> would make each RIR an equal recipient of such space. But the
> >>>> level of
> >>>> need and economic activity between each RI R is not equal. This
> >>>> policy
> >>>> will tend to reallocate returned space away from where it is
> >>>> recovered,
> >>>> in the ARIN region , and move more of it to AFRINIC and LACNIC than
> >>>> current distribution principles. By equating the smaller economies
> >>>> and
> >>>> related needs of certain regions to the needs of other regions, like
> >>>> ARIN, that have greater day to day need, it in effect creates a new
> >>>> political order of distribution thru equal shares. It is possible
> >>>> sovereign governments in the regions with greater activity will not
> >>>> agree to such a revised distribution model. The proposed policy
> >>>> undermines the legal rationale for distribution.
> >>>>
> >>>> The policy also creates a powerful disincentive for any RIR,
> >>>> including
> >>>> ARIN, to undertake any financial expenditure of RIR dollars for
> >>>> programs
> >>>> intended to obtain returned space for reallocation. Currently ARIN
> >>>> is
> >>>> working towards policies such as the LRSA and 2008-6, intended to
> >>>> encourage returns and use of under utilized resources, but which
> >>>> cost
> >>>> ARIN expenditures other RIRs are not duplicating. Any policy which
> >>>> creates such a disincentive by leaving expenditures with a single
> >>>> RIR,
> >>>> who cannot benefit except to receive 20% of the returned space
> >>>> should be
> >>>> carefully considered.
> >>>>
> >>>> Finally, it is likely entities with number resources in the ARIN
> >>>> region
> >>>> may be willing to return those resources for uses in the region but
> >>>> unwilling to do so if 4/5 of such resources will be sent to other
> >>>> regions.
> >>>>
> >>>> III. Resource Impact
> >>>>
> >>>> The resource impact of implementing this policy is viewed as
> >>>> minimal. It
> >>>> is estimated that this policy could require up to 3 person months of
> >>>> effort to implement following ratification by the ARIN Board of
> >>>> Trustees. Because this implementation is not planned, it may preempt
> >>>> ARIN?s current project deployment schedule. It may require the
> >>>> following:
> >>>>
> >>>> * Modifications to existing registration procedures to include the
> >>>>  handling of returned/reclaimed address space and the process of
> >>>>  requesting additional address space from the IANA.
> >>>> * Staff training
> >>>>
> >>>> Text assessed:
> >>>>
> >>>> *Allocation of IPv4 Blocks to Regional Internet Registries (Global)*
> >>>>
> >>>> *Policy statement:*
> >>>>
> >>>> This document describes the policy governing the allocation of IPv4
> >>>> address space from the IANA to the Regional Internet Registries
> >>>> (RIRs).
> >>>> This document does not stipulate performance requirements in the
> >>>> provision of services by IANA to an RIR in accordance with this
> >>>> policy.
> >>>> Such requirements should be specified by appropriate agreements
> >>>> among
> >>>> the RIRs and ICANN.
> >>>>
> >>>> This policy is to be implemented in two phases.
> >>>>
> >>>> A. Phase I: Recovery of IPv4 Address Space
> >>>>
> >>>> Upon ratification of this policy by the ICANN Board of Directors the
> >>>> IANA shall establish a mechanism to receive IPv4 address space
> >>>> which is
> >>>> returned to it by the RIRs, and hold that address space in a
> >>>> 'recovered
> >>>> IPv4 pool'.
> >>>>
> >>>> Each RIR through their respective chosen policies and strategies may
> >>>> recover IPv4 address space which is under their administration. At
> >>>> quarterly intervals, each RIR shall return any legacy address space
> >>>> recovered, and may return any non-legacy address space recovered,
> >>>> to the
> >>>> IANA in aggregated blocks of /24 or larger, for inclusion in the
> >>>> recovered IPv4 pool.
> >>>>
> >>>> During Phase I, no allocations will be made from the recovered IPv4
> >>>> pool. Return of recovered address space (as described above) will
> >>>> continue throughout Phase II.
> >>>>
> >>>> B. Phase II: Allocation of Recovered IPv4 address space by the IANA
> >>>>
> >>>> Upon ratification of this policy by the ICANN Board of Directors
> >>>> and a
> >>>> declaration by the IANA that its existing free pool of unallocated
> >>>> IPv4
> >>>> address space is depleted; Global Addressing Policy ASO-001-2
> >>>> (adopted
> >>>> by ICANN Board 8 April 2005) is rescinded. IANA will then commence
> >>>> to
> >>>> allocate the IPv4 address space from the recovered IPv4 pool.
> >>>>
> >>>> 1. The following definitions apply to this policy:
> >>>>
> >>>> a. Recovered Address Space. Recovered address space is that address
> >>>> space that is returned to an RIR as a result of any activity that
> >>>> seeks
> >>>> to reclaim unused address space or is voluntarily returned to the
> >>>> RIR or
> >>>> is reclaimed by the RIR as a result of legal action or abuse
> >>>> determination. Recovered address space does not include that address
> >>>> space that is reclaimed because of non-payment of contractual fees
> >>>> whose
> >>>> reclamation date is less than 1 year at the time of the report.
> >>>>
> >>>> b. IPv4 Address Holdings. IPv4 address holdings are all
> >>>> unallocated IPv4
> >>>> address space held by an RIR to include recovered address space
> >>>> not yet
> >>>> returned less that address space that is committed in accordance
> >>>> with
> >>>> the RIR's reservation policy and practices.
> >>>>
> >>>> c. Legacy address space. IPv4 address space allocated or assigned
> >>>> prior
> >>>> to the creation of the RIR.
> >>>>
> >>>> 2. Allocation of IPv4 Address Space
> >>>>
> >>>> a. For the purposes of this policy, an 'IPv4 allocation period' is
> >>>> defined as a 6-month period following 1 March or 1 September in
> >>>> each year.
> >>>>
> >>>> b. At the beginning of each IPv4 allocation period, the IANA will
> >>>> determine the 'IPv4 allocation unit' for that period, as 1/10 of its
> >>>> IPv4 address pool, rounded down to the next CIDR (power-of-2)
> >>>> boundary.
> >>>>
> >>>> c. In each allocation period, each RIR may issue one IPv4 request
> >>>> to the
> >>>> IANA. Providing that the RIR satisfies the allocation criteria
> >>>> described
> >>>> in paragraph B.2, the IANA will allocate a single allocation unit,
> >>>> composed of the smallest possible number of blocks available in
> >>>> its IPv4
> >>>> address pool.
> >>>>
> >>>> 3. IPv4 Address Space Allocation Criteria
> >>>>
> >>>> A RIR is eligible to receive additional IPv4 address space from
> >>>> the IANA
> >>>> when the total of its IPv4 address holdings is less than 50% of the
> >>>> current IPv4 allocation unit, and providing that it has not already
> >>>> received an IPv4 allocation from the IANA during the current IPv4
> >>>> allocation period.
> >>>>
> >>>> 4. Initial Allocation of IPv4 Address Space
> >>>>
> >>>> Each new RIR shall, at the moment of recognition, be allocated one
> >>>> (1)
> >>>> allocation unit by the IANA. If an allocation unit is not available,
> >>>> then the IANA will issue this block as soon as one is available.
> >>>> This
> >>>> allocation will be made regardless of the newly formed RIR's
> >>>> projected
> >>>> utilization figures and shall be independent of the IPv4 address
> >>>> space
> >>>> that may have been transferred to the new RIR by the already
> >>>> existing
> >>>> RIRs as part of the formal transition process.
> >>>>
> >>>> 5. Reporting
> >>>>
> >>>> a. All returned space is to be recorded in an IANA-published log
> >>>> of IPv4
> >>>> address space transactions, with each log entry detailing the
> >>>> returned
> >>>> address block, the date of the return, and the returning RIR.
> >>>>
> >>>> b. All allocated space is also to be recorded in this IANA-
> >>>> published log
> >>>> of IPv4 address space transactions, with each log entry detailing
> >>>> the
> >>>> address blocks, the date of the allocation and the recipient RIR.
> >>>>
> >>>> c. The IANA will maintain a public registry of the current
> >>>> disposition
> >>>> of all IPv4 address space, detailing all reservations and current
> >>>> allocations and current IANA-held address space that is unallocated.
> >>>>
> >>>> d) The IANA may make public announcements of IPv4 address block
> >>>> transactions that occur under this policy. The IANA will make
> >>>> appropriate modifications to the "Internet Protocol V4 Address
> >>>> Space"
> >>>> page of the IANA website and may make announcements to its own
> >>>> appropriate announcement lists. The IANA announcements will be
> >>>> limited
> >>>> to which address ranges, the time of allocation and to which
> >>>> Registry
> >>>> they have been allocated.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> PPML
> >>>> You are receiving this message because you are subscribed to
> >>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> >>>> Unsubscribe or manage your mailing list subscription at:
> >>>> http://lists.arin.net/mailman/listinfo/arin-ppml
> >>>> Please contact info at arin.net if you experience any issues.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>> _______________________________________________
> >>> PPML
> >>> You are receiving this message because you are subscribed to
> >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> >>> Unsubscribe or manage your mailing list subscription at:
> >>> http://lists.arin.net/mailman/listinfo/arin-ppml
> >>> Please contact info at arin.net if you experience any issues.
> >>>
> >
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> >
> 
> -- 
> Sent from my mobile device
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



================================================
=======
David Farmer				     Email:	
farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota			     Phone:	612-626-
0815
2218 University Ave SE			     Cell:		
612-812-9952
Minneapolis, MN 55414-3029		     FAX:	612-626-
1818
================================================
=======



From farmer at umn.edu  Mon Mar 30 17:06:54 2009
From: farmer at umn.edu (David Farmer)
Date: Mon, 30 Mar 2009 16:06:54 -0500
Subject: [arin-ppml] Draft Policy 2009-3 (Global): Allocation of IPv4
	Blocks to Regional Internet Registries
In-Reply-To: <4607e1d50903301351o52e48c66n21163809fcf0f630@mail.gmail.com>
References: <37137.208.54.95.48.1238379940.squirrel@webmail.lacnic.net.uy>,
	<49D12E37.9040307@gmail.com>,
	<4607e1d50903301351o52e48c66n21163809fcf0f630@mail.gmail.com>
Message-ID: <49D0EE1E.23043.ED04123@farmer.umn.edu>

On 30 Mar 2009 Martin Hannigan wrote:

> Scott,
> 
> You already pointed out that there was no consensus to move this
> policy forward and there still appears to be none. You haven't
> included not advancing this policy in the options that you provided to
> the community either. 

Not in those exact words but I believe that is the intent of 

"- If you oppose 2009-3 completely, do you believe that current policy is 
adequate, or would you support some other mechanism to allow for the 
reallocation of IPv4 blocks between RIRs?"

> You're pushing the line between fairness and
> zealous advocacy quite hard from my perspective.

I thought he was being fair.



=======================================================
David Farmer				     Email:	farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota			     Phone:	612-626-0815
2218 University Ave SE			     Cell:		612-812-9952
Minneapolis, MN 55414-3029		     FAX:	612-626-1818
=======================================================



From mueller at syr.edu  Mon Mar 30 17:16:57 2009
From: mueller at syr.edu (Milton L Mueller)
Date: Mon, 30 Mar 2009 17:16:57 -0400
Subject: [arin-ppml] Draft Policy 2009-3 (Global): Allocation of IPv4
 Blocks to Regional Internet Registries
In-Reply-To: <49D12E37.9040307@gmail.com>
References: <37137.208.54.95.48.1238379940.squirrel@webmail.lacnic.net.uy>
	<49D10949.9000803@arin.net> <49D11F48.6090905@gmail.com>
	<9EDA9B03-C069-44B5-B06D-D60E510849FE@lacnic.net>
	<4607e1d50903301318y3c142303g42a991f6be79b0a6@mail.gmail.com>
	<49D12E37.9040307@gmail.com>
Message-ID: <75822E125BCB994F8446858C4B19F0D76BEA10C0@SUEX07-MBX-04.ad.syr.edu>

 

> -----Original Message-----
> (My opinion of the draft policy is rather nuanced: I can 
> elaborate separately if you'd like.) 

I'd like



From scottleibrand at gmail.com  Mon Mar 30 17:25:27 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Mon, 30 Mar 2009 14:25:27 -0700
Subject: [arin-ppml] Draft Policy 2009-3 (Global): Allocation of IPv4
 Blocks to Regional Internet Registries
In-Reply-To: <4607e1d50903301351o52e48c66n21163809fcf0f630@mail.gmail.com>
References: <37137.208.54.95.48.1238379940.squirrel@webmail.lacnic.net.uy>	
	<49D10949.9000803@arin.net> <49D11F48.6090905@gmail.com>	
	<9EDA9B03-C069-44B5-B06D-D60E510849FE@lacnic.net>	
	<4607e1d50903301318y3c142303g42a991f6be79b0a6@mail.gmail.com>	
	<49D12E37.9040307@gmail.com>
	<4607e1d50903301351o52e48c66n21163809fcf0f630@mail.gmail.com>
Message-ID: <49D138C7.7040207@gmail.com>

Apparently I'm not communicating clearly.  Let me try again, in case 
David's clarifications didn't do the trick completely.

Not advancing the proposal (abandoning it) is definitely an option.  If 
that is what the community wants, as demonstrated via PPML and the 
public policy meeting in San Antonio, then that's what I'll vote for at 
the AC meeting afterward.

In many cases, I've observed that there is a significant difference 
between the opinions people choose to express on PPML, and those that 
the broader community expresses at the public policy meeting.  
Therefore, I am reluctant to abandon a policy proposal like this without 
first discussing it at the meeting, unless we see an overwhelmingly 
negative reaction on PPML, coupled with a complete lack of support.  I 
don't think we saw that in this case.

Perhaps it would also help to express my own opinion on this draft 
policy as well:

I believe that there is a need for some sort of policy for what the IANA 
should do after it has allocated all unallocated IPv4 /8s.  2009-3 is 
one such option, but I believe that the original proposed text would be 
problematic, because the mandatory return of reclaimed space removes 
most of the incentive for RIRs to reclaim space.  As a possible 
alternative, I think that making the return of reclaimed space optional 
would eliminate that concern, but it might also make the proposal 
completely irrelevant.  So as a compromise position, it might make sense 
to make return of legacy space (allocated prior to RIR creation) 
mandatory, while leaving return of non-legacy space mandatory.

Even after making such changes, I'm not sure whether I support 2009-3.  
However, I think it's a good starting point for the discussion of how to 
reallocate space between RIRs after IANA exhaustion.  (One other 
alternative might be some sort of inter-RIR transfer policy.)

Hope that clarifies things a bit,
Scott

Martin Hannigan wrote:
> Scott,
>
> You already pointed out that there was no consensus to move this
> policy forward and there still appears to be none. You haven't
> included not advancing this policy in the options that you provided to
> the community either. You're pushing the line between fairness and
> zealous advocacy quite hard from my perspective.
>
>
> Best,
>
> Martin
>
>
>
> On 3/30/09, Scott Leibrand <scottleibrand at gmail.com> wrote:
>   
>> Running this policy through the process fairly is exactly what we're
>> trying to do here.  I'm certainly not pushing for (or against)
>> adoption.  (My opinion of the draft policy is rather nuanced: I can
>> elaborate separately if you'd like.) While I don't think there is a
>> consensus for adopting the original policy proposal, I also don't see a
>> consensus for abandoning the proposal without first discussing it at a
>> public policy meeting.
>>
>> In more general terms, the required level of support for advancing a
>> policy proposal for discussion at the public policy meeting is much
>> lower than the level of consensus required for adopting such a policy.
>> If such consensus is not demonstrated at the public policy meeting, and
>> there is no consensus among the community that the AC should continue
>> working on the policy, then the AC is much more likely to vote to
>> abandon the proposal at that time.
>>
>> -Scott
>>
>> Martin Hannigan wrote:
>>     
>>> Scott,
>>>
>>> You indicated that there is no consensus with regards to this policy
>>> advancing.  Why is this policy advancing at all then?  Regardless of
>>> it being a global policy, there's no requirement to do anything other
>>> than to run this policy through the process fairly. Failing to succeed
>>> in that process is a sometimes expected result.
>>>
>>> A perception may be starting to develop that this policy isn't being
>>> treated equally with regards to other policies I.e. continuing to be
>>> pushed for discussion without support.
>>>
>>>
>>> Best,
>>>
>>> Martin
>>>
>>>
>>>
>>> On 3/30/09, Raul Echeberria <raul at lacnic.net> wrote:
>>>
>>>       
>>>> Thanks,
>>>>
>>>> Ra?l
>>>>
>>>>
>>>>
>>>> El 30/03/2009, a las 04:36 p.m., Scott Leibrand escribi?:
>>>>
>>>>
>>>>         
>>>>> Raul,
>>>>>
>>>>> Given that it's too late to initiate a separate discussion petition
>>>>> for the San Antonio meeting, I would like to assure you that I will
>>>>> do what I can to make sure that we get feedback from the community
>>>>> at that meeting as to the support for the original proposed text, as
>>>>> well as for the revised version.  If there is a clear community
>>>>> consensus in favor of either language, my own personal opinion is
>>>>> that we'll be able to move the proposal forward, with any applicable
>>>>> edits, at that point.
>>>>>
>>>>> In order to prepare for such discussion, I'd welcome feedback from
>>>>> the PPML on the following questions:
>>>>>
>>>>> - Do you support the original proposed text of 2009-3, requiring
>>>>> return of any reclaimed space to IANA for redistribution?  Why or
>>>>> why not?
>>>>> - Do you support the current modified text of 2009-3, requiring
>>>>> return of any reclaimed legacy space, but making optional the return
>>>>> of any non-legacy space?  Why or why not?
>>>>> - Would you support some other revised version of 2009-3?  If so,
>>>>> what would you want to change?  (For example, we could make all
>>>>> returns optional, for both legacy and non-legacy space.)
>>>>> - If you oppose 2009-3 completely, do you believe that current
>>>>> policy is adequate, or would you support some other mechanism to
>>>>> allow for the reallocation of IPv4 blocks between RIRs?
>>>>>
>>>>> Thanks,
>>>>> Scott
>>>>>
>>>>> Member Services wrote:
>>>>>
>>>>>           
>>>>>> Raul,
>>>>>>
>>>>>> According to the ARIN Policy Development Process the petition
>>>>>> period for
>>>>>> the upcoming San Antonio meeting closed on 13 March 2009. The
>>>>>> deadline
>>>>>> information was posted to PPML earlier this month, see the post:
>>>>>> http://lists.arin.net/pipermail/arin-ppml/2009-March/013106.html
>>>>>>
>>>>>> The draft policy is under discussion, statements of support and
>>>>>> opposition are welcome and appreciated. Both the discussion on the
>>>>>> PPML
>>>>>> and at the Public Policy Meeting will be used by the AC to
>>>>>> determine the
>>>>>> community consensus regarding adopting this as policy.
>>>>>>
>>>>>> The ARIN Policy Development Process can be found at:
>>>>>> https://www.arin.net/policy/pdp.html
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Member Services
>>>>>> American Registry for Internet Numbers (ARIN)
>>>>>>
>>>>>> raul at lacnic.net wrote:
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> Dear all:
>>>>>>>
>>>>>>> This proposal is a proposal for a global policy. It means that the
>>>>>>> same
>>>>>>> proposal has to be approved in every region. They can be approved
>>>>>>> with
>>>>>>> some wording differences, but the spirit of the proposal should be
>>>>>>> the
>>>>>>> same.
>>>>>>>
>>>>>>> The proposal was the result of a long collaboration effort of
>>>>>>> senior staff
>>>>>>> members and board members of all the 5 RIRs and the original text
>>>>>>> is the
>>>>>>> one that is being considered in every region.
>>>>>>>
>>>>>>> As far as I know the authors of the proposal were not consulted by
>>>>>>> the
>>>>>>> ARIN-AC and based on exchanges among the authors in the past few
>>>>>>> days, I
>>>>>>> can say that in general the feeling is that the changes introduced
>>>>>>> by the
>>>>>>> ARIN-AC are very signficant and so, this is a different proposal.
>>>>>>>
>>>>>>> My personal view is that changing the concept of a global policy
>>>>>>> proposal
>>>>>>> in one RIR means to avoid the approval of the policy. I strongly
>>>>>>> encourage
>>>>>>> ARIN to put the original proposal under consideration of its
>>>>>>> community as
>>>>>>> it is being done in the other regions. The proposal can be
>>>>>>> approved or
>>>>>>> not, That's part of the process, but it doesn't make sense to
>>>>>>> approve a
>>>>>>> different proposal. IMHO, the AC is able to put forward the new
>>>>>>> proposal
>>>>>>> for discussion if they consider that it is better, and in that way
>>>>>>> to
>>>>>>> start the process of discussion of a new global policy proposal.
>>>>>>>
>>>>>>> I have to confess that dealing with 5 different PDPs is not so
>>>>>>> easy. I
>>>>>>> don't know if a petition process should be started, If yes, please
>>>>>>> take
>>>>>>> this email as the request for initiating that process.
>>>>>>>
>>>>>>> Since this announcement was issued last Monday in the afternoon, I
>>>>>>> am not
>>>>>>> sure how the business days are counted, but I guess that I am
>>>>>>> still within
>>>>>>> the valid period.
>>>>>>>
>>>>>>> However, I think that as a practices, global policy proposals
>>>>>>> should not
>>>>>>> be changed by any advisory council or policy chair of one region
>>>>>>> due to
>>>>>>> the impact that to change the proposal produce in the global
>>>>>>> process.
>>>>>>>
>>>>>>>
>>>>>>> Best Regards,
>>>>>>>
>>>>>>> Ra?l
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> El 23/03/2009, a las 04:05 p.m., Member Services escribi?:
>>>>>>>
>>>>>>> Draft Policy 2009-3 (Global)
>>>>>>> Allocation of IPv4 Blocks to Regional Internet Registries
>>>>>>>
>>>>>>> The following draft policy text is being posted for feedback and
>>>>>>> discussion on the Public Policy Mailing List (PPML).
>>>>>>>
>>>>>>> This draft policy was developed by the ARIN Advisory Council (AC)
>>>>>>> from
>>>>>>> Policy Proposal 82: Allocation of IPv4 Blocks to Regional Internet
>>>>>>> Registries. The AC has taken the proposal and developed it into a
>>>>>>> draft
>>>>>>> policy. The AC was required to submit text to ARIN for staff and
>>>>>>> legal
>>>>>>> assessment prior to selecting it as a draft policy. The assessment,
>>>>>>> along with the text that was assessed, is located below the draft
>>>>>>> policy.
>>>>>>>
>>>>>>> On 20 March 2009 the ARIN Advisory Council (AC) selected Draft
>>>>>>> Policy
>>>>>>> 2009-3: Allocation of IPv4 Blocks to Regional Internet Registries
>>>>>>> for
>>>>>>> adoption discussion on the PPML and at the upcoming Public Policy
>>>>>>> Meeting.
>>>>>>>
>>>>>>> Draft Policy 2009-3 is below and can be found at:
>>>>>>> https://www.arin.net/policy/proposals/2009_3.html
>>>>>>>
>>>>>>> We encourage you to discuss Draft Policy 2009-3 on the PPML prior
>>>>>>> to the
>>>>>>> ARIN XXIII Public Policy Meeting. Both the discussion on the PPML
>>>>>>> and at
>>>>>>> the Public Policy Meeting will be used by the AC to determine the
>>>>>>> community consensus regarding adopting this as policy.
>>>>>>>
>>>>>>> The ARIN Policy Development Process can be found at:
>>>>>>> https://www.arin.net/policy/pdp.html
>>>>>>>
>>>>>>> All of the Draft Policies under discussion can be found at:
>>>>>>> https://www.arin.net/policy/proposals/index.html
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Member Services
>>>>>>> American Registry for Internet Numbers (ARIN)
>>>>>>>
>>>>>>>
>>>>>>> ## * ##
>>>>>>>
>>>>>>>
>>>>>>> Draft Policy 2009-3 (Global)
>>>>>>> Allocation of IPv4 Blocks to Regional Internet Registries
>>>>>>>
>>>>>>> Date: 23 March 2009
>>>>>>>
>>>>>>> Policy statement:
>>>>>>>
>>>>>>> This document describes the policy governing the allocation of IPv4
>>>>>>> address space from the IANA to the Regional Internet Registries
>>>>>>> (RIRs).
>>>>>>> This document does not stipulate performance requirements in the
>>>>>>> provision of services by IANA to an RIR in accordance with this
>>>>>>> policy.
>>>>>>> Such requirements should be specified by appropriate agreements
>>>>>>> among
>>>>>>> the RIRs and ICANN.
>>>>>>>
>>>>>>> This policy is to be implemented in two phases.
>>>>>>>
>>>>>>> A. Phase I: Recovery of IPv4 Address Space
>>>>>>>
>>>>>>> Upon ratification of this policy by the ICANN Board of Directors the
>>>>>>> IANA shall establish a mechanism to receive IPv4 address space
>>>>>>> which is
>>>>>>> returned to it by the RIRs, and hold that address space in a
>>>>>>> 'recovered
>>>>>>> IPv4 pool'.
>>>>>>>
>>>>>>> Each RIR through their respective chosen policies and strategies may
>>>>>>> recover IPv4 address space which is under their administration. At
>>>>>>> quarterly intervals, each RIR shall return to the IANA any legacy
>>>>>>> address space recovered, and may return to the IANA any non-legacy
>>>>>>> address space recovered, in aggregated blocks of /24 or larger, for
>>>>>>> inclusion in the recovered IPv4 pool.
>>>>>>>
>>>>>>> During Phase I, no allocations will be made from the recovered IPv4
>>>>>>> pool. Return of recovered address space (as described above) will
>>>>>>> continue throughout Phase II.
>>>>>>>
>>>>>>> B. Phase II: Allocation of Recovered IPv4 address space by the IANA
>>>>>>>
>>>>>>> Upon ratification of this policy by the ICANN Board of Directors
>>>>>>> and a
>>>>>>> declaration by the IANA that its existing free pool of unallocated
>>>>>>> IPv4
>>>>>>> address space is depleted; Global Addressing Policy ASO-001-2
>>>>>>> (adopted
>>>>>>> by ICANN Board 8 April 2005) is rescinded. IANA will then commence
>>>>>>> to
>>>>>>> allocate the IPv4 address space from the recovered IPv4 pool.
>>>>>>>
>>>>>>> 1. The following definitions apply to this policy:
>>>>>>>
>>>>>>> a. Recovered Address Space. Recovered address space is that address
>>>>>>> space that is returned to an RIR as a result of any activity that
>>>>>>> seeks
>>>>>>> to reclaim unused address space or is voluntarily returned to the
>>>>>>> RIR or
>>>>>>> is reclaimed by the RIR as a result of legal action or abuse
>>>>>>> determination. Recovered address space does not include that address
>>>>>>> space that is reclaimed because of non-payment of contractual fees
>>>>>>> whose
>>>>>>> reclamation date is less than 1 year at the time of the report.
>>>>>>>
>>>>>>> b. IPv4 Address Holdings. IPv4 address holdings are all
>>>>>>> unallocated IPv4
>>>>>>> address space held by an RIR to include recovered address space
>>>>>>> not yet
>>>>>>> returned less that address space that is committed in accordance
>>>>>>> with
>>>>>>> the RIR's reservation policy and practices.
>>>>>>>
>>>>>>> c. Aggregated address blocks. Aggregated address blocks are
>>>>>>> contiguous
>>>>>>> prefixes that can be aggregated on natural bit boundaries.
>>>>>>> 10.0.0.0/24
>>>>>>> and 10.0.1.0/24 are two contiguous prefixes that can be combined
>>>>>>> to form
>>>>>>> an aggregated address block. 10.0.0.0/24 and 10.0.1.0/25 are two
>>>>>>> contiguous prefixes that cannot be combined on a natural bit
>>>>>>> boundary to
>>>>>>> form an aggregated block.
>>>>>>>
>>>>>>> d. Legacy address space. IPv4 address space allocated or assigned
>>>>>>> prior
>>>>>>> to the creation of the RIR.
>>>>>>>
>>>>>>> 2. Allocation of IPv4 Address Space
>>>>>>>
>>>>>>> a. For the purposes of this policy, an 'IPv4 allocation period' is
>>>>>>> defined as a 6-month period following 1 March or 1 September in
>>>>>>> each year.
>>>>>>>
>>>>>>> b. At the beginning of each IPv4 allocation period, the IANA will
>>>>>>> determine the 'IPv4 allocation unit' for that period, as 1/10 of its
>>>>>>> IPv4 address pool, rounded down to the next CIDR (power-of-2)
>>>>>>> boundary.
>>>>>>> The minimum 'IPv4 allocation unit' size will be a /24.
>>>>>>>
>>>>>>> c. In each allocation period, each RIR may issue one IPv4 request
>>>>>>> to the
>>>>>>> IANA. Providing that the RIR satisfies the allocation criteria
>>>>>>> described
>>>>>>> in paragraph B.2, the IANA will allocate a single allocation unit,
>>>>>>> composed of the smallest possible number of blocks available in
>>>>>>> its IPv4
>>>>>>> address pool.
>>>>>>>
>>>>>>> 3. IPv4 Address Space Allocation Criteria
>>>>>>>
>>>>>>> A RIR is eligible to receive additional IPv4 address space from
>>>>>>> the IANA
>>>>>>> when the total of its IPv4 address holdings is less than 50% of the
>>>>>>> current IPv4 allocation unit, and providing that it has not already
>>>>>>> received an IPv4 allocation from the IANA during the current IPv4
>>>>>>> allocation period.
>>>>>>>
>>>>>>> 4. Initial Allocation of IPv4 Address Space
>>>>>>>
>>>>>>> Each new RIR shall, at the moment of recognition, be allocated one
>>>>>>> (1)
>>>>>>> allocation unit by the IANA. If an allocation unit is not available,
>>>>>>> then the IANA will issue this block as soon as one is available.
>>>>>>> This
>>>>>>> allocation will be made regardless of the newly formed RIR's
>>>>>>> projected
>>>>>>> utilization figures and shall be independent of the IPv4 address
>>>>>>> space
>>>>>>> that may have been transferred to the new RIR by the already
>>>>>>> existing
>>>>>>> RIRs as part of the formal transition process.
>>>>>>>
>>>>>>> 5. Reporting
>>>>>>>
>>>>>>> a. All returned space is to be recorded in an IANA-published log
>>>>>>> of IPv4
>>>>>>> address space transactions, with each log entry detailing the
>>>>>>> returned
>>>>>>> address block, the date of the return, and the returning RIR.
>>>>>>>
>>>>>>> b. All allocated space is also to be recorded in this IANA-
>>>>>>> published log
>>>>>>> of IPv4 address space transactions, with each log entry detailing
>>>>>>> the
>>>>>>> address blocks, the date of the allocation and the recipient RIR.
>>>>>>>
>>>>>>> c. The IANA will maintain a public registry of the current
>>>>>>> disposition
>>>>>>> of all IPv4 address space, detailing all reservations and current
>>>>>>> allocations and current IANA-held address space that is unallocated.
>>>>>>>
>>>>>>> d) The IANA may make public announcements of IPv4 address block
>>>>>>> transactions that occur under this policy. The IANA will make
>>>>>>> appropriate modifications to the "Internet Protocol V4 Address
>>>>>>> Space"
>>>>>>> page of the IANA website and may make announcements to its own
>>>>>>> appropriate announcement lists. The IANA announcements will be
>>>>>>> limited
>>>>>>> to which address ranges, the time of allocation and to which
>>>>>>> Registry
>>>>>>> they have been allocated.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> #####
>>>>>>>
>>>>>>> ARIN Staff Assessment
>>>>>>>
>>>>>>> *Title: Allocation of IPv4 Blocks to the Regional Internet
>>>>>>> Registries*
>>>>>>>
>>>>>>> *Proposal Submitted: 30 Jan 2009*
>>>>>>>
>>>>>>> *Revision Submitted: 05 March 2009*
>>>>>>>
>>>>>>> *Date of Assessment: 10 March 2009*
>>>>>>>
>>>>>>> * *
>>>>>>>
>>>>>>> I. Understanding of the Policy:
>>>>>>>
>>>>>>> *Staff Understanding of the Proposal:*
>>>>>>>
>>>>>>> Staff understands that this proposal would be implemented in 2
>>>>>>> phases.
>>>>>>> Phase 1 would require the RIRs to return recovered IPv4 legacy
>>>>>>> address
>>>>>>> space (via policy or procedure) to the IANA and have the option of
>>>>>>> returning recovered non-legacy address space to the IANA. Phase 2
>>>>>>> would
>>>>>>> start after the depletion of the IANA free pool and would nullify
>>>>>>> the
>>>>>>> existing IANA to RIR policy (Global Addressing Policy ASO-001-2).
>>>>>>> The
>>>>>>> new IANA to RIR policy would allow each RIR to receive approximately
>>>>>>> 1/10th of the recovered IPv4 pool from IANA once every 6 months as
>>>>>>> long
>>>>>>> as it meets the qualification criteria written in paragraph B2. IANA
>>>>>>> will be required to keep a log of all returned IPv4 address space
>>>>>>> and
>>>>>>> all issued IPv4 address space from the recovered pool, as well as
>>>>>>> maintain a public registry of the current disposition of all IPv4
>>>>>>> address space.
>>>>>>>
>>>>>>> II. Comments
>>>>>>>
>>>>>>> A. ARIN Staff Comments
>>>>>>>
>>>>>>> * The one policy that this impacts is NRPM 4.6 Amnesty and
>>>>>>>  Aggregation, which says ?Transactions should only be accepted
>>>>>>>  under this policy if they are in the interests of the community
>>>>>>>  (e.g. they improve aggregation or result in a net reclamation of
>>>>>>>  space).? Because the ARIN region holds the majority of the legacy
>>>>>>>  address space, and most of the address space returned under this
>>>>>>>  policy is legacy space, it would mean that there would be no ?net
>>>>>>>  return? of address space to ARIN. ARIN would essentially be
>>>>>>>  exchanging legacy address space for non-legacy address space, and
>>>>>>>  returning the legacy address space it received in the exchange to
>>>>>>>  IANA, resulting in a net loss of address space in ARIN?s available
>>>>>>>  pool.
>>>>>>>
>>>>>>> B. ARIN General Counsel Comments:
>>>>>>>
>>>>>>> The current basis of allocation of numbers was established in
>>>>>>> RFC's 2008
>>>>>>> and 2050 and is need based. If one region has greater needs than
>>>>>>> another, the current policy of IANA does not require equal
>>>>>>> distribution
>>>>>>> to all RIR's s. This proposed policy would establish a different
>>>>>>> political and not needs based method for allocating returned
>>>>>>> space. It
>>>>>>> would make each RIR an equal recipient of such space. But the
>>>>>>> level of
>>>>>>> need and economic activity between each RI R is not equal. This
>>>>>>> policy
>>>>>>> will tend to reallocate returned space away from where it is
>>>>>>> recovered,
>>>>>>> in the ARIN region , and move more of it to AFRINIC and LACNIC than
>>>>>>> current distribution principles. By equating the smaller economies
>>>>>>> and
>>>>>>> related needs of certain regions to the needs of other regions, like
>>>>>>> ARIN, that have greater day to day need, it in effect creates a new
>>>>>>> political order of distribution thru equal shares. It is possible
>>>>>>> sovereign governments in the regions with greater activity will not
>>>>>>> agree to such a revised distribution model. The proposed policy
>>>>>>> undermines the legal rationale for distribution.
>>>>>>>
>>>>>>> The policy also creates a powerful disincentive for any RIR,
>>>>>>> including
>>>>>>> ARIN, to undertake any financial expenditure of RIR dollars for
>>>>>>> programs
>>>>>>> intended to obtain returned space for reallocation. Currently ARIN
>>>>>>> is
>>>>>>> working towards policies such as the LRSA and 2008-6, intended to
>>>>>>> encourage returns and use of under utilized resources, but which
>>>>>>> cost
>>>>>>> ARIN expenditures other RIRs are not duplicating. Any policy which
>>>>>>> creates such a disincentive by leaving expenditures with a single
>>>>>>> RIR,
>>>>>>> who cannot benefit except to receive 20% of the returned space
>>>>>>> should be
>>>>>>> carefully considered.
>>>>>>>
>>>>>>> Finally, it is likely entities with number resources in the ARIN
>>>>>>> region
>>>>>>> may be willing to return those resources for uses in the region but
>>>>>>> unwilling to do so if 4/5 of such resources will be sent to other
>>>>>>> regions.
>>>>>>>
>>>>>>> III. Resource Impact
>>>>>>>
>>>>>>> The resource impact of implementing this policy is viewed as
>>>>>>> minimal. It
>>>>>>> is estimated that this policy could require up to 3 person months of
>>>>>>> effort to implement following ratification by the ARIN Board of
>>>>>>> Trustees. Because this implementation is not planned, it may preempt
>>>>>>> ARIN?s current project deployment schedule. It may require the
>>>>>>> following:
>>>>>>>
>>>>>>> * Modifications to existing registration procedures to include the
>>>>>>>  handling of returned/reclaimed address space and the process of
>>>>>>>  requesting additional address space from the IANA.
>>>>>>> * Staff training
>>>>>>>
>>>>>>> Text assessed:
>>>>>>>
>>>>>>> *Allocation of IPv4 Blocks to Regional Internet Registries (Global)*
>>>>>>>
>>>>>>> *Policy statement:*
>>>>>>>
>>>>>>> This document describes the policy governing the allocation of IPv4
>>>>>>> address space from the IANA to the Regional Internet Registries
>>>>>>> (RIRs).
>>>>>>> This document does not stipulate performance requirements in the
>>>>>>> provision of services by IANA to an RIR in accordance with this
>>>>>>> policy.
>>>>>>> Such requirements should be specified by appropriate agreements
>>>>>>> among
>>>>>>> the RIRs and ICANN.
>>>>>>>
>>>>>>> This policy is to be implemented in two phases.
>>>>>>>
>>>>>>> A. Phase I: Recovery of IPv4 Address Space
>>>>>>>
>>>>>>> Upon ratification of this policy by the ICANN Board of Directors the
>>>>>>> IANA shall establish a mechanism to receive IPv4 address space
>>>>>>> which is
>>>>>>> returned to it by the RIRs, and hold that address space in a
>>>>>>> 'recovered
>>>>>>> IPv4 pool'.
>>>>>>>
>>>>>>> Each RIR through their respective chosen policies and strategies may
>>>>>>> recover IPv4 address space which is under their administration. At
>>>>>>> quarterly intervals, each RIR shall return any legacy address space
>>>>>>> recovered, and may return any non-legacy address space recovered,
>>>>>>> to the
>>>>>>> IANA in aggregated blocks of /24 or larger, for inclusion in the
>>>>>>> recovered IPv4 pool.
>>>>>>>
>>>>>>> During Phase I, no allocations will be made from the recovered IPv4
>>>>>>> pool. Return of recovered address space (as described above) will
>>>>>>> continue throughout Phase II.
>>>>>>>
>>>>>>> B. Phase II: Allocation of Recovered IPv4 address space by the IANA
>>>>>>>
>>>>>>> Upon ratification of this policy by the ICANN Board of Directors
>>>>>>> and a
>>>>>>> declaration by the IANA that its existing free pool of unallocated
>>>>>>> IPv4
>>>>>>> address space is depleted; Global Addressing Policy ASO-001-2
>>>>>>> (adopted
>>>>>>> by ICANN Board 8 April 2005) is rescinded. IANA will then commence
>>>>>>> to
>>>>>>> allocate the IPv4 address space from the recovered IPv4 pool.
>>>>>>>
>>>>>>> 1. The following definitions apply to this policy:
>>>>>>>
>>>>>>> a. Recovered Address Space. Recovered address space is that address
>>>>>>> space that is returned to an RIR as a result of any activity that
>>>>>>> seeks
>>>>>>> to reclaim unused address space or is voluntarily returned to the
>>>>>>> RIR or
>>>>>>> is reclaimed by the RIR as a result of legal action or abuse
>>>>>>> determination. Recovered address space does not include that address
>>>>>>> space that is reclaimed because of non-payment of contractual fees
>>>>>>> whose
>>>>>>> reclamation date is less than 1 year at the time of the report.
>>>>>>>
>>>>>>> b. IPv4 Address Holdings. IPv4 address holdings are all
>>>>>>> unallocated IPv4
>>>>>>> address space held by an RIR to include recovered address space
>>>>>>> not yet
>>>>>>> returned less that address space that is committed in accordance
>>>>>>> with
>>>>>>> the RIR's reservation policy and practices.
>>>>>>>
>>>>>>> c. Legacy address space. IPv4 address space allocated or assigned
>>>>>>> prior
>>>>>>> to the creation of the RIR.
>>>>>>>
>>>>>>> 2. Allocation of IPv4 Address Space
>>>>>>>
>>>>>>> a. For the purposes of this policy, an 'IPv4 allocation period' is
>>>>>>> defined as a 6-month period following 1 March or 1 September in
>>>>>>> each year.
>>>>>>>
>>>>>>> b. At the beginning of each IPv4 allocation period, the IANA will
>>>>>>> determine the 'IPv4 allocation unit' for that period, as 1/10 of its
>>>>>>> IPv4 address pool, rounded down to the next CIDR (power-of-2)
>>>>>>> boundary.
>>>>>>>
>>>>>>> c. In each allocation period, each RIR may issue one IPv4 request
>>>>>>> to the
>>>>>>> IANA. Providing that the RIR satisfies the allocation criteria
>>>>>>> described
>>>>>>> in paragraph B.2, the IANA will allocate a single allocation unit,
>>>>>>> composed of the smallest possible number of blocks available in
>>>>>>> its IPv4
>>>>>>> address pool.
>>>>>>>
>>>>>>> 3. IPv4 Address Space Allocation Criteria
>>>>>>>
>>>>>>> A RIR is eligible to receive additional IPv4 address space from
>>>>>>> the IANA
>>>>>>> when the total of its IPv4 address holdings is less than 50% of the
>>>>>>> current IPv4 allocation unit, and providing that it has not already
>>>>>>> received an IPv4 allocation from the IANA during the current IPv4
>>>>>>> allocation period.
>>>>>>>
>>>>>>> 4. Initial Allocation of IPv4 Address Space
>>>>>>>
>>>>>>> Each new RIR shall, at the moment of recognition, be allocated one
>>>>>>> (1)
>>>>>>> allocation unit by the IANA. If an allocation unit is not available,
>>>>>>> then the IANA will issue this block as soon as one is available.
>>>>>>> This
>>>>>>> allocation will be made regardless of the newly formed RIR's
>>>>>>> projected
>>>>>>> utilization figures and shall be independent of the IPv4 address
>>>>>>> space
>>>>>>> that may have been transferred to the new RIR by the already
>>>>>>> existing
>>>>>>> RIRs as part of the formal transition process.
>>>>>>>
>>>>>>> 5. Reporting
>>>>>>>
>>>>>>> a. All returned space is to be recorded in an IANA-published log
>>>>>>> of IPv4
>>>>>>> address space transactions, with each log entry detailing the
>>>>>>> returned
>>>>>>> address block, the date of the return, and the returning RIR.
>>>>>>>
>>>>>>> b. All allocated space is also to be recorded in this IANA-
>>>>>>> published log
>>>>>>> of IPv4 address space transactions, with each log entry detailing
>>>>>>> the
>>>>>>> address blocks, the date of the allocation and the recipient RIR.
>>>>>>>
>>>>>>> c. The IANA will maintain a public registry of the current
>>>>>>> disposition
>>>>>>> of all IPv4 address space, detailing all reservations and current
>>>>>>> allocations and current IANA-held address space that is unallocated.
>>>>>>>
>>>>>>> d) The IANA may make public announcements of IPv4 address block
>>>>>>> transactions that occur under this policy. The IANA will make
>>>>>>> appropriate modifications to the "Internet Protocol V4 Address
>>>>>>> Space"
>>>>>>> page of the IANA website and may make announcements to its own
>>>>>>> appropriate announcement lists. The IANA announcements will be
>>>>>>> limited
>>>>>>> to which address ranges, the time of allocation and to which
>>>>>>> Registry
>>>>>>> they have been allocated.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> PPML
>>>>>>> You are receiving this message because you are subscribed to
>>>>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>>>>>> Unsubscribe or manage your mailing list subscription at:
>>>>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>>>>> Please contact info at arin.net if you experience any issues.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>> _______________________________________________
>>>>>> PPML
>>>>>> You are receiving this message because you are subscribed to
>>>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>>>>> Unsubscribe or manage your mailing list subscription at:
>>>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>>>> Please contact info at arin.net if you experience any issues.
>>>>>>
>>>>>>
>>>>>>             
>>>> _______________________________________________
>>>> PPML
>>>> You are receiving this message because you are subscribed to
>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>> Please contact info at arin.net if you experience any issues.
>>>>
>>>>
>>>>         
>>>       
>
>   


From scottleibrand at gmail.com  Mon Mar 30 18:00:19 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Mon, 30 Mar 2009 15:00:19 -0700
Subject: [arin-ppml] Draft Policy 2009-3 (Global): Allocation of IPv4
 Blocks to Regional Internet Registries
In-Reply-To: <49D138C7.7040207@gmail.com>
References: <37137.208.54.95.48.1238379940.squirrel@webmail.lacnic.net.uy>	
	<49D10949.9000803@arin.net> <49D11F48.6090905@gmail.com>	
	<9EDA9B03-C069-44B5-B06D-D60E510849FE@lacnic.net>	
	<4607e1d50903301318y3c142303g42a991f6be79b0a6@mail.gmail.com>	
	<49D12E37.9040307@gmail.com>
	<4607e1d50903301351o52e48c66n21163809fcf0f630@mail.gmail.com>
	<49D138C7.7040207@gmail.com>
Message-ID: <49D140F3.7010606@gmail.com>

Scott Leibrand wrote:
>
> I believe that there is a need for some sort of policy for what the 
> IANA should do after it has allocated all unallocated IPv4 /8s.  
> 2009-3 is one such option, but I believe that the original proposed 
> text would be problematic, because the mandatory return of reclaimed 
> space removes most of the incentive for RIRs to reclaim space.  As a 
> possible alternative, I think that making the return of reclaimed 
> space optional would eliminate that concern, but it might also make 
> the proposal completely irrelevant.  So as a compromise position, it 
> might make sense to make return of legacy space (allocated prior to 
> RIR creation) mandatory, while leaving return of non-legacy space 
> mandatory.

Sorry, that last sentence makes no sense.  What I meant to write was "it 
might make sense to make return of legacy space (allocated prior to RIR 
creation) mandatory, while leaving return of non-legacy space *optional*."

Sorry,
Scott


From Daniel_Alexander at Cable.Comcast.com  Mon Mar 30 18:10:52 2009
From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel)
Date: Mon, 30 Mar 2009 18:10:52 -0400
Subject: [arin-ppml] Summary of 2009-1 discussion so far
Message-ID: <997BC128AE961E4A8B880CD7442D94800A83EE7D@NJCHLEXCMB01.cable.comcast.com>


Hello All,

This email is rather long but I wanted to try and summarize some of the
discussion of 2009-1 so far. My apologies if I neglected any particular
comments or if my counts might be off. I was trying to select one or two
points from each of the major issues, and I was consolidating more than
one thread. If you have not done so already, please let the AC know if
you are in favor or against this proposal, or if you have specific
suggestions as to how the wording should be changed.

Thanks,
Dan Alexander
ARIN AC


PPML Postings: As of 5pm 3/30

In Favor:

  None stated


Opposed:

  Leo Bicknell
  Kevin Kargel
  Ted Mittelstaedt
  William Herrin
  Seth Mattinen
  Jeremy H Griffith
  Jay Hennigan


Contributions:

1  Dan Alexander
7  Leo Bicknell
1  Cort Buffington (CB)
1  Dale W Carder
3  John Curran
7  Bill Darte
3  Owen DeLong (OD)
4  Michael Dillon
7  David Farmer
1  Jeremy H Griffith (JG)
5  Martin Hannigan (MH)
1  Jay Hennigan
6  William Herrin (WH)
5  Lee Howard (LH)
11 Kevin Kargel
4  Mathew Kaufman
2  Eliot Lear
4  Scott Leibrand (SL)
2  Seth Mattinen (SM)
6  Ted Mittelstaedt
3  Milton L Mueller
4  John Schnizlein
1  Michael K Smith
1  Stephen Sprunk
2  Bill Woodcock


Notable Points:

Recurring questions of clarity and procedure. 
	Why did the BoT use the Emergency PDP? 
	Where is the proper explanation in the meeting minutes? 
	What was the emergency?
	Why was this needed?
	Is 2008-6 actually accepted and just not implemented?

(OD) "The same argument could be made about laws with sunset clauses,
but, the same applies.  While it is true that the community can change
things and could even repeal a sunset clause, the sunset clause creates
a default action that occurs unless the community takes action.
Additionally, repealing a policy, even
if there is strong community consensus to do so, takes time.  By having
a sunset clause in place, it clearly indicates that the intent of the
community is for the policy to be temporary and short-term in nature,
and, it creates a default action of removing the policy after some
period of time, rather than requiring additional subsequent action by
the community to do so."

(LB) "In broad terms, sunset provisions can be used for two purposes:
- To reduce future workload on a body where it is expected the item
  will no longer be useful at some point.  Rather than having to waste
  time removing old policy it automatically goes.
- To require a body to re-evaluate an item via the normal debate
  process in the future because the current authors are worried
  the plan is not yet perfect, and/or the situation may change."

(WH) "2008-06 intentionally sunsetted section 8.4 three years after
adoption. This was no accident: the community has long been suspicious
of processes that effectively permit the sale of IP addresses from one
party to another. We're willing to give it a chance, but if we don't
like what we see, we don't want to have to fight again to take the
policy back out... especially with the board hinting it might try
sketchy procedural maneuvers in order to overrule such an effort."

(WH) "Under normal ARIN policy, any legal entity which can justify its
request may receive number resources. Though normally companies or other
organizations, this does occasionally apply to individuals. AS 11875 for
example. 2009-1 restricts the transfer recipients to "organizations."
2008-6 retains ARIN's broader definition of eligible recipients."

(JG) "So far I have seen *NO* support for this policy.  Zero.
Zip.  If it goes forward anyway, it will be very clear that the ideas of
"consensus" and "community policy" are mere travesties, to be discarded
whenever the BOT finds that convenient."

(WH) "Should the board elect to promptly withdraw proposal 2009-1, let's
say by close of business Friday, it would be my pleasure to resubmit the
text of the proposal to the normal policy process and serve as the
proposal's author."

(SM) "Lack of interest in entities adopting IPv6 is not ARIN's
emergency. It's a business case issue, as in many orgs see no business
case for putting forth the effort to deploy IPv6 in their networks, not
an "emergency"."

(CB) "Emergency? I think so. But I don't think that the majority of the
networking community will choose to deal with this until it reaches
crisis state. By the time we reach crisis, the problem will be too big
to worry about pointing fingers. As usual in the US, those who were
responsible enough to deal with it before it became and emergency will
see no benefit since there will be some kind of either bailout, or
social acceptance of the crisis and the half-baked solutions that will
come with waiting until two weeks past the very last date to reasonable
address the issue." 

(LH) "The sense of the Board is that a transfer policy is needed well
before IANA's last IPv4 allocation, to allow early transfers and ease
the demand for IPv4 numbers from ARIN.  Allowing for the possibility
that demand might increase as IANA allocates its last IPv4 numbers, the
Board believes that there is insufficient time for another full policy
cycle.  The policy in 2008-6 allowed the Board to activate it by
declaring an emergency, which the Board did. The policy had certain gaps
which, in the Board's opinion, allowed for exploitation.  As noted in
the minutes of the February 6 meeting, the Board resolved to make
certain edits to the policy that  had just been adopted. These edits
were out of order: according to ARIN's Policy Development Process, the
Board of Trustees may (in emergency circumstances) suspend a policy or
propose a policy, but may not edit the Number Resource Policy Manual
directly.  Therefore, at its March 18, 2009 meeting, the Board rescinded
its action editing the policy, and proposed a new policy, which is
2009-1: Transfer Policy.  The minutes of that meeting will be published
once Board members have reviewed them, according to the published
procedure."


Suggestions:

(MH) "Number resources are issued based on justified need to
organizations and not to individuals that represent those organizations.
Upon notification that a major negative event related to the
Corporations solvency [define these in definitions] has occurred, ARIN
will freeze all assigned  provider independent "PI" address space,
ASN's, and affiliated resources deemed necessary to protect ARIN
assigned number resources and their disposition. Changes to these
resources during the negative event will be processed in a manner
consistent with ARIN policy and agreements in effect at the time of the
negative event".

(SL) "I heard a number of people express the opinion that we don't want
to set a permanent precedent allowing transfers of IPv6 (and ASN).  Both
2008-2 and 2008-6 were very explicit that transfers were only being
allowed as a result of the extraordinary circumstance of IPv4
exhaustion, and that such transfers would not be allowed for any other
type of number resource. I believe it would be appropriate to restore
such a limitation to section 8.3 of 2009-1."

(WH) "The changed text in 8.2 implies that a transfer of resources will
not be permitted except as a result of a merger or acquisition. Does
this rule out any kind of transfer that was previously permitted? If so,
what?"

(WH) "The original use of the word "effecting" was correct. The
instrument(s) effecting the transfer of assets. You don't affect a
change, you effect a change. The use of the word "affecting" in 2009-1
is incorrect."


From mksmith at adhost.com  Mon Mar 30 18:13:27 2009
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Mon, 30 Mar 2009 15:13:27 -0700
Subject: [arin-ppml] Summary of 2009-1 discussion so far
In-Reply-To: <997BC128AE961E4A8B880CD7442D94800A83EE7D@NJCHLEXCMB01.cable.comcast.com>
References: <997BC128AE961E4A8B880CD7442D94800A83EE7D@NJCHLEXCMB01.cable.comcast.com>
Message-ID: <17838240D9A5544AAA5FF95F8D52031605B42D50@ad-exh01.adhost.lan>



Opposed:

  Leo Bicknell
  Kevin Kargel
  Ted Mittelstaedt
  William Herrin
  Seth Mattinen
  Jeremy H Griffith
  Jay Hennigan
+ Michael K. Smith

Regards,

Mike 


From matthew at matthew.at  Mon Mar 30 18:16:07 2009
From: matthew at matthew.at (Matthew Kaufman)
Date: Mon, 30 Mar 2009 15:16:07 -0700
Subject: [arin-ppml] Summary of 2009-1 discussion so far
In-Reply-To: <17838240D9A5544AAA5FF95F8D52031605B42D50@ad-exh01.adhost.lan>
References: <997BC128AE961E4A8B880CD7442D94800A83EE7D@NJCHLEXCMB01.cable.comcast.com>
	<17838240D9A5544AAA5FF95F8D52031605B42D50@ad-exh01.adhost.lan>
Message-ID: <49D144A7.5080507@matthew.at>

I am in strong favor of a simple and easy to use transfer policy but 
opposed to any policy that has critical items (e.g., sunset clauses) 
changed by the board after members agree on something.

So I'm against this one.

Matthew Kaufman


From heather.schiller at verizonbusiness.com  Mon Mar 30 19:07:09 2009
From: heather.schiller at verizonbusiness.com (Heather Schiller)
Date: Mon, 30 Mar 2009 19:07:09 -0400
Subject: [arin-ppml] Draft Policy 2009-3 (Global): Allocation of IPv4
 Blocks to Regional Internet Registries
In-Reply-To: <37137.208.54.95.48.1238379940.squirrel@webmail.lacnic.net.uy>
References: <37137.208.54.95.48.1238379940.squirrel@webmail.lacnic.net.uy>
Message-ID: <49D1509D.5030907@verizonbusiness.com>


raul at lacnic.net wrote:
> Dear all:
> 
> This proposal is a proposal for a global policy. It means that the same
> proposal has to be approved in every region. They can be approved with
> some wording differences, but the spirit of the proposal should be the
> same.


Today there is no global or local mechanism to keep the policy text the 
same as it is discussed across regions.  Every region is entitled to 
make changes in accordance with their PDP.  The current ARIN PDP gives 
the AC the flexibility to modify text, with or without input from the 
authors.  Without a distinction that "Global Policies" should be handled 
differently the AC is within it's right to act in the best interest of 
it's community and modify text accordingly.

To be blunt, I think this is a failing across the RIR's - there should 
be some mechanism to handle "Global Policies" differently.  The other 
issue is on the flipside - once a "Global Policy" has been passed, there 
is nothing preventing any one region from changing it.  So any process 
for handling "Global Policies" should lock the text and require future 
revisions to go through a "Global PDP".

> 
> The proposal was the result of a long collaboration effort of senior staff
> members and board members of all the 5 RIRs and the original text is the
> one that is being considered in every region.
> 

APNIC changed the text at their meeting in February:

http://www.apnic.net/policy/proposals/prop-069-v002.html

"Consensus reached at APNIC 27 in Manila, Philippines. See Version 3 for 
proposal text that incorporates the feedback from APNIC 27."

Would it be fair for other RIR's to complain that the text changed at 
the APNIC meeting?


> As far as I know the authors of the proposal were not consulted by the
> ARIN-AC and based on exchanges among the authors in the past few days, I
> can say that in general the feeling is that the changes introduced by the
> ARIN-AC are very signficant and so, this is a different proposal.

As far as I know none of the other regions were consulted before the 
changes that were made from the APNIC meeting.  The results of the 
changes were distributed to the other RIR's after the fact.  You are 
already changing the text as it's in progress being discussed throughout 
the regions.

There was significant feedback against this proposal in the ARIN region. 
  The AC took in feedback from the mailing list, and in accordance with 
the PDP, changed the text in advance, in order for it to stand a better 
chance vs waiting for the meeting, letting it get pummeled, and either 
being shelved or being revised and having to go through another policy 
cycle. The latter would have delayed the entire process, in our region 
and others, since the revisions would have to go back to APNIC and other 
RIR's for approval.  The process for getting a "global policy" through 
all 5 regions is long enough to begin with.

> 
> My personal view is that changing the concept of a global policy proposal
> in one RIR means to avoid the approval of the policy. I strongly encourage
> ARIN to put the original proposal under consideration of its community as
> it is being done in the other regions. The proposal can be approved or
> not, That's part of the process, but it doesn't make sense to approve a
> different proposal. IMHO, the AC is able to put forward the new proposal
> for discussion if they consider that it is better, and in that way to
> start the process of discussion of a new global policy proposal.
> 
> I have to confess that dealing with 5 different PDPs is not so easy. I
> don't know if a petition process should be started, If yes, please take
> this email as the request for initiating that process.

Here is a link to the ARIN PDP:
https://www.arin.net/policy/pdp.html

Section 2.4 covers the petition process.  You can't say "I don't know if 
a petition process should be started, If yes, please take this email as 
the request for initiating that process."  Who are you asking to decide? 
  It's up to you (or someone else in the community) to decide whether or 
not to initiate the petition process, no one is going to do it for you.


> 
> Since this announcement was issued last Monday in the afternoon, I am not
> sure how the business days are counted, but I guess that I am still within
> the valid period.
> 
> However, I think that as a practices, global policy proposals should not
> be changed by any advisory council or policy chair of one region due to
> the impact that to change the proposal produce in the global process.
> 

Our region's current procedure allows us to make such changes.  As you 
are a member of the EC I would encourage you to work with your fellow 
RIR's to close this loophole by developing a process to handle Global 
Policies and to utilize the ASO AC to shepherd policy throughout the 5 
regions.



> 
> Best Regards,
> 
> Ra?l
> 
> 
> 
> ---------------
> 
> 
> 
> El 23/03/2009, a las 04:05 p.m., Member Services escribi?:
> 
> Draft Policy 2009-3 (Global)
> Allocation of IPv4 Blocks to Regional Internet Registries
> 
> The following draft policy text is being posted for feedback and
> discussion on the Public Policy Mailing List (PPML).
> 
> This draft policy was developed by the ARIN Advisory Council (AC) from
> Policy Proposal 82: Allocation of IPv4 Blocks to Regional Internet
> Registries. The AC has taken the proposal and developed it into a draft
> policy. The AC was required to submit text to ARIN for staff and legal
> assessment prior to selecting it as a draft policy. The assessment,
> along with the text that was assessed, is located below the draft policy.
> 
> On 20 March 2009 the ARIN Advisory Council (AC) selected Draft Policy
> 2009-3: Allocation of IPv4 Blocks to Regional Internet Registries for
> adoption discussion on the PPML and at the upcoming Public Policy Meeting.
> 
> Draft Policy 2009-3 is below and can be found at:
> https://www.arin.net/policy/proposals/2009_3.html
> 
> We encourage you to discuss Draft Policy 2009-3 on the PPML prior to the
> ARIN XXIII Public Policy Meeting. Both the discussion on the PPML and at
> the Public Policy Meeting will be used by the AC to determine the
> community consensus regarding adopting this as policy.
> 
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
> 
> All of the Draft Policies under discussion can be found at:
> https://www.arin.net/policy/proposals/index.html
> 
> Regards,
> 
> Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> ## * ##
> 
> 
> Draft Policy 2009-3 (Global)
> Allocation of IPv4 Blocks to Regional Internet Registries
> 
> Date: 23 March 2009
> 
> Policy statement:
> 
> This document describes the policy governing the allocation of IPv4
> address space from the IANA to the Regional Internet Registries (RIRs).
> This document does not stipulate performance requirements in the
> provision of services by IANA to an RIR in accordance with this policy.
> Such requirements should be specified by appropriate agreements among
> the RIRs and ICANN.
> 
> This policy is to be implemented in two phases.
> 
> A. Phase I: Recovery of IPv4 Address Space
> 
> Upon ratification of this policy by the ICANN Board of Directors the
> IANA shall establish a mechanism to receive IPv4 address space which is
> returned to it by the RIRs, and hold that address space in a 'recovered
> IPv4 pool'.
> 
> Each RIR through their respective chosen policies and strategies may
> recover IPv4 address space which is under their administration. At
> quarterly intervals, each RIR shall return to the IANA any legacy
> address space recovered, and may return to the IANA any non-legacy
> address space recovered, in aggregated blocks of /24 or larger, for
> inclusion in the recovered IPv4 pool.
> 
> During Phase I, no allocations will be made from the recovered IPv4
> pool. Return of recovered address space (as described above) will
> continue throughout Phase II.
> 
> B. Phase II: Allocation of Recovered IPv4 address space by the IANA
> 
> Upon ratification of this policy by the ICANN Board of Directors and a
> declaration by the IANA that its existing free pool of unallocated IPv4
> address space is depleted; Global Addressing Policy ASO-001-2 (adopted
> by ICANN Board 8 April 2005) is rescinded. IANA will then commence to
> allocate the IPv4 address space from the recovered IPv4 pool.
> 
> 1. The following definitions apply to this policy:
> 
> a. Recovered Address Space. Recovered address space is that address
> space that is returned to an RIR as a result of any activity that seeks
> to reclaim unused address space or is voluntarily returned to the RIR or
> is reclaimed by the RIR as a result of legal action or abuse
> determination. Recovered address space does not include that address
> space that is reclaimed because of non-payment of contractual fees whose
> reclamation date is less than 1 year at the time of the report.
> 
> b. IPv4 Address Holdings. IPv4 address holdings are all unallocated IPv4
> address space held by an RIR to include recovered address space not yet
> returned less that address space that is committed in accordance with
> the RIR's reservation policy and practices.
> 
> c. Aggregated address blocks. Aggregated address blocks are contiguous
> prefixes that can be aggregated on natural bit boundaries. 10.0.0.0/24
> and 10.0.1.0/24 are two contiguous prefixes that can be combined to form
> an aggregated address block. 10.0.0.0/24 and 10.0.1.0/25 are two
> contiguous prefixes that cannot be combined on a natural bit boundary to
> form an aggregated block.
> 
> d. Legacy address space. IPv4 address space allocated or assigned prior
> to the creation of the RIR.
> 
> 2. Allocation of IPv4 Address Space
> 
> a. For the purposes of this policy, an 'IPv4 allocation period' is
> defined as a 6-month period following 1 March or 1 September in each year.
> 
> b. At the beginning of each IPv4 allocation period, the IANA will
> determine the 'IPv4 allocation unit' for that period, as 1/10 of its
> IPv4 address pool, rounded down to the next CIDR (power-of-2) boundary.
> The minimum 'IPv4 allocation unit' size will be a /24.
> 
> c. In each allocation period, each RIR may issue one IPv4 request to the
> IANA. Providing that the RIR satisfies the allocation criteria described
> in paragraph B.2, the IANA will allocate a single allocation unit,
> composed of the smallest possible number of blocks available in its IPv4
> address pool.
> 
> 3. IPv4 Address Space Allocation Criteria
> 
> A RIR is eligible to receive additional IPv4 address space from the IANA
> when the total of its IPv4 address holdings is less than 50% of the
> current IPv4 allocation unit, and providing that it has not already
> received an IPv4 allocation from the IANA during the current IPv4
> allocation period.
> 
> 4. Initial Allocation of IPv4 Address Space
> 
> Each new RIR shall, at the moment of recognition, be allocated one (1)
> allocation unit by the IANA. If an allocation unit is not available,
> then the IANA will issue this block as soon as one is available. This
> allocation will be made regardless of the newly formed RIR's projected
> utilization figures and shall be independent of the IPv4 address space
> that may have been transferred to the new RIR by the already existing
> RIRs as part of the formal transition process.
> 
> 5. Reporting
> 
> a. All returned space is to be recorded in an IANA-published log of IPv4
> address space transactions, with each log entry detailing the returned
> address block, the date of the return, and the returning RIR.
> 
> b. All allocated space is also to be recorded in this IANA-published log
> of IPv4 address space transactions, with each log entry detailing the
> address blocks, the date of the allocation and the recipient RIR.
> 
> c. The IANA will maintain a public registry of the current disposition
> of all IPv4 address space, detailing all reservations and current
> allocations and current IANA-held address space that is unallocated.
> 
> d) The IANA may make public announcements of IPv4 address block
> transactions that occur under this policy. The IANA will make
> appropriate modifications to the "Internet Protocol V4 Address Space"
> page of the IANA website and may make announcements to its own
> appropriate announcement lists. The IANA announcements will be limited
> to which address ranges, the time of allocation and to which Registry
> they have been allocated.
> 
> 
> 
> #####
> 
> ARIN Staff Assessment
> 
> *Title: Allocation of IPv4 Blocks to the Regional Internet Registries*
> 
> *Proposal Submitted: 30 Jan 2009*
> 
> *Revision Submitted: 05 March 2009*
> 
> *Date of Assessment: 10 March 2009*
> 
> * *
> 
> I. Understanding of the Policy:
> 
> *Staff Understanding of the Proposal:*
> 
> Staff understands that this proposal would be implemented in 2 phases.
> Phase 1 would require the RIRs to return recovered IPv4 legacy address
> space (via policy or procedure) to the IANA and have the option of
> returning recovered non-legacy address space to the IANA. Phase 2 would
> start after the depletion of the IANA free pool and would nullify the
> existing IANA to RIR policy (Global Addressing Policy ASO-001-2). The
> new IANA to RIR policy would allow each RIR to receive approximately
> 1/10th of the recovered IPv4 pool from IANA once every 6 months as long
> as it meets the qualification criteria written in paragraph B2. IANA
> will be required to keep a log of all returned IPv4 address space and
> all issued IPv4 address space from the recovered pool, as well as
> maintain a public registry of the current disposition of all IPv4
> address space.
> 
> II. Comments
> 
> A. ARIN Staff Comments
> 
> * The one policy that this impacts is NRPM 4.6 Amnesty and
>   Aggregation, which says ?Transactions should only be accepted
>   under this policy if they are in the interests of the community
>   (e.g. they improve aggregation or result in a net reclamation of
>   space).? Because the ARIN region holds the majority of the legacy
>   address space, and most of the address space returned under this
>   policy is legacy space, it would mean that there would be no ?net
>   return? of address space to ARIN. ARIN would essentially be
>   exchanging legacy address space for non-legacy address space, and
>   returning the legacy address space it received in the exchange to
>   IANA, resulting in a net loss of address space in ARIN?s available
>   pool.
> 
> B. ARIN General Counsel Comments:
> 
> The current basis of allocation of numbers was established in RFC's 2008
> and 2050 and is need based. If one region has greater needs than
> another, the current policy of IANA does not require equal distribution
> to all RIR's s. This proposed policy would establish a different
> political and not needs based method for allocating returned space. It
> would make each RIR an equal recipient of such space. But the level of
> need and economic activity between each RI R is not equal. This policy
> will tend to reallocate returned space away from where it is recovered,
> in the ARIN region , and move more of it to AFRINIC and LACNIC than
> current distribution principles. By equating the smaller economies and
> related needs of certain regions to the needs of other regions, like
> ARIN, that have greater day to day need, it in effect creates a new
> political order of distribution thru equal shares. It is possible
> sovereign governments in the regions with greater activity will not
> agree to such a revised distribution model. The proposed policy
> undermines the legal rationale for distribution.
> 
> The policy also creates a powerful disincentive for any RIR, including
> ARIN, to undertake any financial expenditure of RIR dollars for programs
> intended to obtain returned space for reallocation. Currently ARIN is
> working towards policies such as the LRSA and 2008-6, intended to
> encourage returns and use of under utilized resources, but which cost
> ARIN expenditures other RIRs are not duplicating. Any policy which
> creates such a disincentive by leaving expenditures with a single RIR,
> who cannot benefit except to receive 20% of the returned space should be
> carefully considered.
> 
> Finally, it is likely entities with number resources in the ARIN region
> may be willing to return those resources for uses in the region but
> unwilling to do so if 4/5 of such resources will be sent to other regions.
> 
> III. Resource Impact
> 
> The resource impact of implementing this policy is viewed as minimal. It
> is estimated that this policy could require up to 3 person months of
> effort to implement following ratification by the ARIN Board of
> Trustees. Because this implementation is not planned, it may preempt
> ARIN?s current project deployment schedule. It may require the following:
> 
> * Modifications to existing registration procedures to include the
>   handling of returned/reclaimed address space and the process of
>   requesting additional address space from the IANA.
> * Staff training
> 
> Text assessed:
> 
> *Allocation of IPv4 Blocks to Regional Internet Registries (Global)*
> 
> *Policy statement:*
> 
> This document describes the policy governing the allocation of IPv4
> address space from the IANA to the Regional Internet Registries (RIRs).
> This document does not stipulate performance requirements in the
> provision of services by IANA to an RIR in accordance with this policy.
> Such requirements should be specified by appropriate agreements among
> the RIRs and ICANN.
> 
> This policy is to be implemented in two phases.
> 
> A. Phase I: Recovery of IPv4 Address Space
> 
> Upon ratification of this policy by the ICANN Board of Directors the
> IANA shall establish a mechanism to receive IPv4 address space which is
> returned to it by the RIRs, and hold that address space in a 'recovered
> IPv4 pool'.
> 
> Each RIR through their respective chosen policies and strategies may
> recover IPv4 address space which is under their administration. At
> quarterly intervals, each RIR shall return any legacy address space
> recovered, and may return any non-legacy address space recovered, to the
> IANA in aggregated blocks of /24 or larger, for inclusion in the
> recovered IPv4 pool.
> 
> During Phase I, no allocations will be made from the recovered IPv4
> pool. Return of recovered address space (as described above) will
> continue throughout Phase II.
> 
> B. Phase II: Allocation of Recovered IPv4 address space by the IANA
> 
> Upon ratification of this policy by the ICANN Board of Directors and a
> declaration by the IANA that its existing free pool of unallocated IPv4
> address space is depleted; Global Addressing Policy ASO-001-2 (adopted
> by ICANN Board 8 April 2005) is rescinded. IANA will then commence to
> allocate the IPv4 address space from the recovered IPv4 pool.
> 
> 1. The following definitions apply to this policy:
> 
> a. Recovered Address Space. Recovered address space is that address
> space that is returned to an RIR as a result of any activity that seeks
> to reclaim unused address space or is voluntarily returned to the RIR or
> is reclaimed by the RIR as a result of legal action or abuse
> determination. Recovered address space does not include that address
> space that is reclaimed because of non-payment of contractual fees whose
> reclamation date is less than 1 year at the time of the report.
> 
> b. IPv4 Address Holdings. IPv4 address holdings are all unallocated IPv4
> address space held by an RIR to include recovered address space not yet
> returned less that address space that is committed in accordance with
> the RIR's reservation policy and practices.
> 
> c. Legacy address space. IPv4 address space allocated or assigned prior
> to the creation of the RIR.
> 
> 2. Allocation of IPv4 Address Space
> 
> a. For the purposes of this policy, an 'IPv4 allocation period' is
> defined as a 6-month period following 1 March or 1 September in each year.
> 
> b. At the beginning of each IPv4 allocation period, the IANA will
> determine the 'IPv4 allocation unit' for that period, as 1/10 of its
> IPv4 address pool, rounded down to the next CIDR (power-of-2) boundary.
> 
> c. In each allocation period, each RIR may issue one IPv4 request to the
> IANA. Providing that the RIR satisfies the allocation criteria described
> in paragraph B.2, the IANA will allocate a single allocation unit,
> composed of the smallest possible number of blocks available in its IPv4
> address pool.
> 
> 3. IPv4 Address Space Allocation Criteria
> 
> A RIR is eligible to receive additional IPv4 address space from the IANA
> when the total of its IPv4 address holdings is less than 50% of the
> current IPv4 allocation unit, and providing that it has not already
> received an IPv4 allocation from the IANA during the current IPv4
> allocation period.
> 
> 4. Initial Allocation of IPv4 Address Space
> 
> Each new RIR shall, at the moment of recognition, be allocated one (1)
> allocation unit by the IANA. If an allocation unit is not available,
> then the IANA will issue this block as soon as one is available. This
> allocation will be made regardless of the newly formed RIR's projected
> utilization figures and shall be independent of the IPv4 address space
> that may have been transferred to the new RIR by the already existing
> RIRs as part of the formal transition process.
> 
> 5. Reporting
> 
> a. All returned space is to be recorded in an IANA-published log of IPv4
> address space transactions, with each log entry detailing the returned
> address block, the date of the return, and the returning RIR.
> 
> b. All allocated space is also to be recorded in this IANA-published log
> of IPv4 address space transactions, with each log entry detailing the
> address blocks, the date of the allocation and the recipient RIR.
> 
> c. The IANA will maintain a public registry of the current disposition
> of all IPv4 address space, detailing all reservations and current
> allocations and current IANA-held address space that is unallocated.
> 
> d) The IANA may make public announcements of IPv4 address block
> transactions that occur under this policy. The IANA will make
> appropriate modifications to the "Internet Protocol V4 Address Space"
> page of the IANA website and may make announcements to its own
> appropriate announcement lists. The IANA announcements will be limited
> to which address ranges, the time of allocation and to which Registry
> they have been allocated.
> 
> 
> 
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 



From marla.azinger at frontiercorp.com  Mon Mar 30 19:36:07 2009
From: marla.azinger at frontiercorp.com (Azinger, Marla)
Date: Mon, 30 Mar 2009 19:36:07 -0400
Subject: [arin-ppml] Draft Policy 2009-3 (Global): Allocation of IPv4
 Blocks to Regional Internet Registries
In-Reply-To: <49D1509D.5030907@verizonbusiness.com>
References: <37137.208.54.95.48.1238379940.squirrel@webmail.lacnic.net.uy>
	<49D1509D.5030907@verizonbusiness.com>
Message-ID: <2E2FECEBAE57CC4BAACDE67638305F10484CF8FB85@ROCH-EXCH1.corp.pvt>

The only way to even attempt having a textual version that all RIR's can agree on would be to actively seek out input from the community of the RIR's and injecting the input before submitting it for Global consideration (non just select members who's names appear on the proposal).  The route this policy took was straight from authors and directly to submission and never took into consideration input from community members.  So the back lash of skipping the community is now being felt. Now community input is coming out after the formal submission to all the RIR's and this basically doubles the difficulty of achieving any consensus on a policy that reads the same in all RIR's.

There may not be a "Global PDP" but it sure would help to post any global idea to the different RIR communities first.  Then incorporate their input into one proposal that includes a rational that explains what regions required particular text in the proposal if its not blatantly clear in the proposal itself. Then proceed to submit the official proposal version to each RIR.

Cheers
Marla Azinger



-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Heather Schiller
Sent: Monday, March 30, 2009 4:07 PM
To: raul at lacnic.net
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft Policy 2009-3 (Global): Allocation of IPv4 Blocks to Regional Internet Registries


raul at lacnic.net wrote:
> Dear all:
>
> This proposal is a proposal for a global policy. It means that the
> same proposal has to be approved in every region. They can be approved
> with some wording differences, but the spirit of the proposal should
> be the same.


Today there is no global or local mechanism to keep the policy text the same as it is discussed across regions.  Every region is entitled to make changes in accordance with their PDP.  The current ARIN PDP gives the AC the flexibility to modify text, with or without input from the authors.  Without a distinction that "Global Policies" should be handled differently the AC is within it's right to act in the best interest of it's community and modify text accordingly.

To be blunt, I think this is a failing across the RIR's - there should be some mechanism to handle "Global Policies" differently.  The other issue is on the flipside - once a "Global Policy" has been passed, there is nothing preventing any one region from changing it.  So any process for handling "Global Policies" should lock the text and require future revisions to go through a "Global PDP".

>
> The proposal was the result of a long collaboration effort of senior
> staff members and board members of all the 5 RIRs and the original
> text is the one that is being considered in every region.
>

APNIC changed the text at their meeting in February:

http://www.apnic.net/policy/proposals/prop-069-v002.html

"Consensus reached at APNIC 27 in Manila, Philippines. See Version 3 for proposal text that incorporates the feedback from APNIC 27."

Would it be fair for other RIR's to complain that the text changed at the APNIC meeting?


> As far as I know the authors of the proposal were not consulted by the
> ARIN-AC and based on exchanges among the authors in the past few days,
> I can say that in general the feeling is that the changes introduced
> by the ARIN-AC are very signficant and so, this is a different proposal.

As far as I know none of the other regions were consulted before the changes that were made from the APNIC meeting.  The results of the changes were distributed to the other RIR's after the fact.  You are already changing the text as it's in progress being discussed throughout the regions.

There was significant feedback against this proposal in the ARIN region.
  The AC took in feedback from the mailing list, and in accordance with the PDP, changed the text in advance, in order for it to stand a better chance vs waiting for the meeting, letting it get pummeled, and either being shelved or being revised and having to go through another policy cycle. The latter would have delayed the entire process, in our region and others, since the revisions would have to go back to APNIC and other RIR's for approval.  The process for getting a "global policy" through all 5 regions is long enough to begin with.

>
> My personal view is that changing the concept of a global policy
> proposal in one RIR means to avoid the approval of the policy. I
> strongly encourage ARIN to put the original proposal under
> consideration of its community as it is being done in the other
> regions. The proposal can be approved or not, That's part of the
> process, but it doesn't make sense to approve a different proposal.
> IMHO, the AC is able to put forward the new proposal for discussion if
> they consider that it is better, and in that way to start the process of discussion of a new global policy proposal.
>
> I have to confess that dealing with 5 different PDPs is not so easy. I
> don't know if a petition process should be started, If yes, please
> take this email as the request for initiating that process.

Here is a link to the ARIN PDP:
https://www.arin.net/policy/pdp.html

Section 2.4 covers the petition process.  You can't say "I don't know if a petition process should be started, If yes, please take this email as the request for initiating that process."  Who are you asking to decide?
  It's up to you (or someone else in the community) to decide whether or not to initiate the petition process, no one is going to do it for you.


>
> Since this announcement was issued last Monday in the afternoon, I am
> not sure how the business days are counted, but I guess that I am
> still within the valid period.
>
> However, I think that as a practices, global policy proposals should
> not be changed by any advisory council or policy chair of one region
> due to the impact that to change the proposal produce in the global process.
>

Our region's current procedure allows us to make such changes.  As you are a member of the EC I would encourage you to work with your fellow RIR's to close this loophole by developing a process to handle Global Policies and to utilize the ASO AC to shepherd policy throughout the 5 regions.



>
> Best Regards,
>
> Ra?l
>
>
>
> ---------------
>
>
>
> El 23/03/2009, a las 04:05 p.m., Member Services escribi?:
>
> Draft Policy 2009-3 (Global)
> Allocation of IPv4 Blocks to Regional Internet Registries
>
> The following draft policy text is being posted for feedback and
> discussion on the Public Policy Mailing List (PPML).
>
> This draft policy was developed by the ARIN Advisory Council (AC) from
> Policy Proposal 82: Allocation of IPv4 Blocks to Regional Internet
> Registries. The AC has taken the proposal and developed it into a
> draft policy. The AC was required to submit text to ARIN for staff and
> legal assessment prior to selecting it as a draft policy. The
> assessment, along with the text that was assessed, is located below the draft policy.
>
> On 20 March 2009 the ARIN Advisory Council (AC) selected Draft Policy
> 2009-3: Allocation of IPv4 Blocks to Regional Internet Registries for
> adoption discussion on the PPML and at the upcoming Public Policy Meeting.
>
> Draft Policy 2009-3 is below and can be found at:
> https://www.arin.net/policy/proposals/2009_3.html
>
> We encourage you to discuss Draft Policy 2009-3 on the PPML prior to
> the ARIN XXIII Public Policy Meeting. Both the discussion on the PPML
> and at the Public Policy Meeting will be used by the AC to determine
> the community consensus regarding adopting this as policy.
>
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
>
> All of the Draft Policies under discussion can be found at:
> https://www.arin.net/policy/proposals/index.html
>
> Regards,
>
> Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Draft Policy 2009-3 (Global)
> Allocation of IPv4 Blocks to Regional Internet Registries
>
> Date: 23 March 2009
>
> Policy statement:
>
> This document describes the policy governing the allocation of IPv4
> address space from the IANA to the Regional Internet Registries (RIRs).
> This document does not stipulate performance requirements in the
> provision of services by IANA to an RIR in accordance with this policy.
> Such requirements should be specified by appropriate agreements among
> the RIRs and ICANN.
>
> This policy is to be implemented in two phases.
>
> A. Phase I: Recovery of IPv4 Address Space
>
> Upon ratification of this policy by the ICANN Board of Directors the
> IANA shall establish a mechanism to receive IPv4 address space which
> is returned to it by the RIRs, and hold that address space in a
> 'recovered
> IPv4 pool'.
>
> Each RIR through their respective chosen policies and strategies may
> recover IPv4 address space which is under their administration. At
> quarterly intervals, each RIR shall return to the IANA any legacy
> address space recovered, and may return to the IANA any non-legacy
> address space recovered, in aggregated blocks of /24 or larger, for
> inclusion in the recovered IPv4 pool.
>
> During Phase I, no allocations will be made from the recovered IPv4
> pool. Return of recovered address space (as described above) will
> continue throughout Phase II.
>
> B. Phase II: Allocation of Recovered IPv4 address space by the IANA
>
> Upon ratification of this policy by the ICANN Board of Directors and a
> declaration by the IANA that its existing free pool of unallocated
> IPv4 address space is depleted; Global Addressing Policy ASO-001-2
> (adopted by ICANN Board 8 April 2005) is rescinded. IANA will then
> commence to allocate the IPv4 address space from the recovered IPv4 pool.
>
> 1. The following definitions apply to this policy:
>
> a. Recovered Address Space. Recovered address space is that address
> space that is returned to an RIR as a result of any activity that
> seeks to reclaim unused address space or is voluntarily returned to
> the RIR or is reclaimed by the RIR as a result of legal action or
> abuse determination. Recovered address space does not include that
> address space that is reclaimed because of non-payment of contractual
> fees whose reclamation date is less than 1 year at the time of the report.
>
> b. IPv4 Address Holdings. IPv4 address holdings are all unallocated
> IPv4 address space held by an RIR to include recovered address space
> not yet returned less that address space that is committed in
> accordance with the RIR's reservation policy and practices.
>
> c. Aggregated address blocks. Aggregated address blocks are contiguous
> prefixes that can be aggregated on natural bit boundaries. 10.0.0.0/24
> and 10.0.1.0/24 are two contiguous prefixes that can be combined to
> form an aggregated address block. 10.0.0.0/24 and 10.0.1.0/25 are two
> contiguous prefixes that cannot be combined on a natural bit boundary
> to form an aggregated block.
>
> d. Legacy address space. IPv4 address space allocated or assigned
> prior to the creation of the RIR.
>
> 2. Allocation of IPv4 Address Space
>
> a. For the purposes of this policy, an 'IPv4 allocation period' is
> defined as a 6-month period following 1 March or 1 September in each year.
>
> b. At the beginning of each IPv4 allocation period, the IANA will
> determine the 'IPv4 allocation unit' for that period, as 1/10 of its
> IPv4 address pool, rounded down to the next CIDR (power-of-2) boundary.
> The minimum 'IPv4 allocation unit' size will be a /24.
>
> c. In each allocation period, each RIR may issue one IPv4 request to
> the IANA. Providing that the RIR satisfies the allocation criteria
> described in paragraph B.2, the IANA will allocate a single allocation
> unit, composed of the smallest possible number of blocks available in
> its IPv4 address pool.
>
> 3. IPv4 Address Space Allocation Criteria
>
> A RIR is eligible to receive additional IPv4 address space from the
> IANA when the total of its IPv4 address holdings is less than 50% of
> the current IPv4 allocation unit, and providing that it has not
> already received an IPv4 allocation from the IANA during the current
> IPv4 allocation period.
>
> 4. Initial Allocation of IPv4 Address Space
>
> Each new RIR shall, at the moment of recognition, be allocated one (1)
> allocation unit by the IANA. If an allocation unit is not available,
> then the IANA will issue this block as soon as one is available. This
> allocation will be made regardless of the newly formed RIR's projected
> utilization figures and shall be independent of the IPv4 address space
> that may have been transferred to the new RIR by the already existing
> RIRs as part of the formal transition process.
>
> 5. Reporting
>
> a. All returned space is to be recorded in an IANA-published log of
> IPv4 address space transactions, with each log entry detailing the
> returned address block, the date of the return, and the returning RIR.
>
> b. All allocated space is also to be recorded in this IANA-published
> log of IPv4 address space transactions, with each log entry detailing
> the address blocks, the date of the allocation and the recipient RIR.
>
> c. The IANA will maintain a public registry of the current disposition
> of all IPv4 address space, detailing all reservations and current
> allocations and current IANA-held address space that is unallocated.
>
> d) The IANA may make public announcements of IPv4 address block
> transactions that occur under this policy. The IANA will make
> appropriate modifications to the "Internet Protocol V4 Address Space"
> page of the IANA website and may make announcements to its own
> appropriate announcement lists. The IANA announcements will be limited
> to which address ranges, the time of allocation and to which Registry
> they have been allocated.
>
>
>
> #####
>
> ARIN Staff Assessment
>
> *Title: Allocation of IPv4 Blocks to the Regional Internet Registries*
>
> *Proposal Submitted: 30 Jan 2009*
>
> *Revision Submitted: 05 March 2009*
>
> *Date of Assessment: 10 March 2009*
>
> * *
>
> I. Understanding of the Policy:
>
> *Staff Understanding of the Proposal:*
>
> Staff understands that this proposal would be implemented in 2 phases.
> Phase 1 would require the RIRs to return recovered IPv4 legacy address
> space (via policy or procedure) to the IANA and have the option of
> returning recovered non-legacy address space to the IANA. Phase 2
> would start after the depletion of the IANA free pool and would
> nullify the existing IANA to RIR policy (Global Addressing Policy
> ASO-001-2). The new IANA to RIR policy would allow each RIR to receive
> approximately 1/10th of the recovered IPv4 pool from IANA once every 6
> months as long as it meets the qualification criteria written in
> paragraph B2. IANA will be required to keep a log of all returned IPv4
> address space and all issued IPv4 address space from the recovered
> pool, as well as maintain a public registry of the current disposition
> of all IPv4 address space.
>
> II. Comments
>
> A. ARIN Staff Comments
>
> * The one policy that this impacts is NRPM 4.6 Amnesty and
>   Aggregation, which says "Transactions should only be accepted
>   under this policy if they are in the interests of the community
>   (e.g. they improve aggregation or result in a net reclamation of
>   space)." Because the ARIN region holds the majority of the legacy
>   address space, and most of the address space returned under this
>   policy is legacy space, it would mean that there would be no "net
>   return" of address space to ARIN. ARIN would essentially be
>   exchanging legacy address space for non-legacy address space, and
>   returning the legacy address space it received in the exchange to
>   IANA, resulting in a net loss of address space in ARIN's available
>   pool.
>
> B. ARIN General Counsel Comments:
>
> The current basis of allocation of numbers was established in RFC's
> 2008 and 2050 and is need based. If one region has greater needs than
> another, the current policy of IANA does not require equal
> distribution to all RIR's s. This proposed policy would establish a
> different political and not needs based method for allocating returned
> space. It would make each RIR an equal recipient of such space. But
> the level of need and economic activity between each RI R is not
> equal. This policy will tend to reallocate returned space away from
> where it is recovered, in the ARIN region , and move more of it to
> AFRINIC and LACNIC than current distribution principles. By equating
> the smaller economies and related needs of certain regions to the
> needs of other regions, like ARIN, that have greater day to day need,
> it in effect creates a new political order of distribution thru equal
> shares. It is possible sovereign governments in the regions with
> greater activity will not agree to such a revised distribution model.
> The proposed policy undermines the legal rationale for distribution.
>
> The policy also creates a powerful disincentive for any RIR, including
> ARIN, to undertake any financial expenditure of RIR dollars for
> programs intended to obtain returned space for reallocation. Currently
> ARIN is working towards policies such as the LRSA and 2008-6, intended
> to encourage returns and use of under utilized resources, but which
> cost ARIN expenditures other RIRs are not duplicating. Any policy
> which creates such a disincentive by leaving expenditures with a
> single RIR, who cannot benefit except to receive 20% of the returned
> space should be carefully considered.
>
> Finally, it is likely entities with number resources in the ARIN
> region may be willing to return those resources for uses in the region
> but unwilling to do so if 4/5 of such resources will be sent to other regions.
>
> III. Resource Impact
>
> The resource impact of implementing this policy is viewed as minimal.
> It is estimated that this policy could require up to 3 person months
> of effort to implement following ratification by the ARIN Board of
> Trustees. Because this implementation is not planned, it may preempt
> ARIN's current project deployment schedule. It may require the following:
>
> * Modifications to existing registration procedures to include the
>   handling of returned/reclaimed address space and the process of
>   requesting additional address space from the IANA.
> * Staff training
>
> Text assessed:
>
> *Allocation of IPv4 Blocks to Regional Internet Registries (Global)*
>
> *Policy statement:*
>
> This document describes the policy governing the allocation of IPv4
> address space from the IANA to the Regional Internet Registries (RIRs).
> This document does not stipulate performance requirements in the
> provision of services by IANA to an RIR in accordance with this policy.
> Such requirements should be specified by appropriate agreements among
> the RIRs and ICANN.
>
> This policy is to be implemented in two phases.
>
> A. Phase I: Recovery of IPv4 Address Space
>
> Upon ratification of this policy by the ICANN Board of Directors the
> IANA shall establish a mechanism to receive IPv4 address space which
> is returned to it by the RIRs, and hold that address space in a
> 'recovered
> IPv4 pool'.
>
> Each RIR through their respective chosen policies and strategies may
> recover IPv4 address space which is under their administration. At
> quarterly intervals, each RIR shall return any legacy address space
> recovered, and may return any non-legacy address space recovered, to
> the IANA in aggregated blocks of /24 or larger, for inclusion in the
> recovered IPv4 pool.
>
> During Phase I, no allocations will be made from the recovered IPv4
> pool. Return of recovered address space (as described above) will
> continue throughout Phase II.
>
> B. Phase II: Allocation of Recovered IPv4 address space by the IANA
>
> Upon ratification of this policy by the ICANN Board of Directors and a
> declaration by the IANA that its existing free pool of unallocated
> IPv4 address space is depleted; Global Addressing Policy ASO-001-2
> (adopted by ICANN Board 8 April 2005) is rescinded. IANA will then
> commence to allocate the IPv4 address space from the recovered IPv4 pool.
>
> 1. The following definitions apply to this policy:
>
> a. Recovered Address Space. Recovered address space is that address
> space that is returned to an RIR as a result of any activity that
> seeks to reclaim unused address space or is voluntarily returned to
> the RIR or is reclaimed by the RIR as a result of legal action or
> abuse determination. Recovered address space does not include that
> address space that is reclaimed because of non-payment of contractual
> fees whose reclamation date is less than 1 year at the time of the report.
>
> b. IPv4 Address Holdings. IPv4 address holdings are all unallocated
> IPv4 address space held by an RIR to include recovered address space
> not yet returned less that address space that is committed in
> accordance with the RIR's reservation policy and practices.
>
> c. Legacy address space. IPv4 address space allocated or assigned
> prior to the creation of the RIR.
>
> 2. Allocation of IPv4 Address Space
>
> a. For the purposes of this policy, an 'IPv4 allocation period' is
> defined as a 6-month period following 1 March or 1 September in each year.
>
> b. At the beginning of each IPv4 allocation period, the IANA will
> determine the 'IPv4 allocation unit' for that period, as 1/10 of its
> IPv4 address pool, rounded down to the next CIDR (power-of-2) boundary.
>
> c. In each allocation period, each RIR may issue one IPv4 request to
> the IANA. Providing that the RIR satisfies the allocation criteria
> described in paragraph B.2, the IANA will allocate a single allocation
> unit, composed of the smallest possible number of blocks available in
> its IPv4 address pool.
>
> 3. IPv4 Address Space Allocation Criteria
>
> A RIR is eligible to receive additional IPv4 address space from the
> IANA when the total of its IPv4 address holdings is less than 50% of
> the current IPv4 allocation unit, and providing that it has not
> already received an IPv4 allocation from the IANA during the current
> IPv4 allocation period.
>
> 4. Initial Allocation of IPv4 Address Space
>
> Each new RIR shall, at the moment of recognition, be allocated one (1)
> allocation unit by the IANA. If an allocation unit is not available,
> then the IANA will issue this block as soon as one is available. This
> allocation will be made regardless of the newly formed RIR's projected
> utilization figures and shall be independent of the IPv4 address space
> that may have been transferred to the new RIR by the already existing
> RIRs as part of the formal transition process.
>
> 5. Reporting
>
> a. All returned space is to be recorded in an IANA-published log of
> IPv4 address space transactions, with each log entry detailing the
> returned address block, the date of the return, and the returning RIR.
>
> b. All allocated space is also to be recorded in this IANA-published
> log of IPv4 address space transactions, with each log entry detailing
> the address blocks, the date of the allocation and the recipient RIR.
>
> c. The IANA will maintain a public registry of the current disposition
> of all IPv4 address space, detailing all reservations and current
> allocations and current IANA-held address space that is unallocated.
>
> d) The IANA may make public announcements of IPv4 address block
> transactions that occur under this policy. The IANA will make
> appropriate modifications to the "Internet Protocol V4 Address Space"
> page of the IANA website and may make announcements to its own
> appropriate announcement lists. The IANA announcements will be limited
> to which address ranges, the time of allocation and to which Registry
> they have been allocated.
>
>
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN
> Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN
> Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>

_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.


From tedm at ipinc.net  Mon Mar 30 20:38:05 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 30 Mar 2009 17:38:05 -0700
Subject: [arin-ppml] clarification of Board actions Feb 2 and Mar 18,
	2009
In-Reply-To: <376189.27706.qm@web63303.mail.re1.yahoo.com>
References: <376189.27706.qm@web63303.mail.re1.yahoo.com>
Message-ID: <107DD4CEABC54F669D321A6EB64005F3@tedsdesk>

 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Lee Howard
> Sent: Monday, March 30, 2009 9:07 AM
> To: ppml at arin.net
> Subject: [arin-ppml] clarification of Board actions Feb 2 and 
> Mar 18, 2009
> 


> The 
> Board has been concerned for some time that the lack of a 
> liberalized transfer policy would create legal risk: that we 
> had not provided a mechanism to improve the efficient 
> utilization of previously-allocated resources, and that this 
> risk was significant enough to jeopardize ARIN's ability to 
> fulfill its stewardship mission.
> 

I have been saying this same thing for years and this is
why I proposed the POC cleanup.  HOWEVER it must be clear that
this statement presumes that the legal risk is created by
the lack of a liberalized transfer policy.  This is a fundamentally
flawed argument.  The legal risk is NOT created by this,
the legal risk is created by INSUFFICIENT utilization of
assignable IPv4.

The fear argument goes something like this:

When IPv4 runs out some large cash-rich org will request a
block and be denied.  That org will then spend it's money
lobbying it's nation's government that the RIR's know that
there's lots of available IPv4 tied up in old assignments that
aren't being used, and that because ARIN has the bulk of it,
and ARIN hasn't done enough to scavenge out this stale addressing,
that ARIN is no longer functioning, and that the U.N. needs
to assign a committee - like WIPO was done with the DNS 
system - to interfere and take control of the assignment
mechanism away from ARIN.

ARIN will cease to exist and chaos will ensue.  Previously signed
contracts will be voided out under the guise of an emergency.  There
is plenty of legal precedent for this - for example, in the US a bankruptcy
court can wipe out contracts if it wants.

As a follower of politics, I personally think this argument
has a lot of validity.  But the Board and ARIN staff and many
people are falling for the idea that the problem is in the
transfer policy.  It IS NOT and NEVER HAS BEEN.

It is in operations - it is failure to properly document
use of IP addressing.

Any county government today has FAR BETTER documentation of
land deeds than ARIN has of orgs assigned to IP addressing.
And their taxation departments go to the utmost in finding
landowners.

It is NOT necessary to create a buying-and-selling market of
IP numbers to obtain close to 100% use of routable IPv4.  It
is merely necessary to prove that all assignable, routable IPv4
is in use on the Internet.  Cleaning and grooming WHOIS is a
major first step.

IMHO what ARIN and the Board are attempting to do is take the
easy way out.  They figure if they hang up a for-sale sign on
IP addressing that there's enough bottom-feeders and scavengers
out on the Internet who will be looking for a quick buck, who
will set themselves up as "brokers" of these IPv4 sales, that
if they end up getting sued, or if the United Nations decides
to get involved, that they can make the argument that since 
a financial incentive now exists with this buying-and-selling market
to scavenge up old IPv4 addresses, obviously, there's no abandoned
IPv4 floating around on the Internet, because the scavengers
are out there fishing it out of the pond.

IMHO this is a very weak argument.  It also assumes that 
after the former-bottom-feeders, now IP-brokers
have finished cleaning out the IPv4 pool of usable IPv4, that
they will mildly go off into the sunset, and disappear.  That
isn't what will happen.  Instead these people will simply
move into the business of creating complex obfuscating
schemes to get portable IPv6 to people who do not and never will
meet the qualifications for their own addressing - and the number of
routes in the dfz will soar to immense levels.

It is like if the State of California decided that since they
can't document 10% of the current whereabouts of tax-dodging
landowners owning land in CA, that they should just declare that 
any Realtor who thinks that a piece of land is abandoned
is now allowed to just sell it to the highest bidder - instead
of what they actually do, which is the state takes back ownership of the
property as a result of failure to pay taxes.

It is an utterly ridiculous argument when applied to most
scarce resources, and the reason some people are thinking
it has validity to IP addressing is simply because they aren't
very experienced with the messes that are created when trying to do this
kind of thing with public resources.

Ted



From BillD at cait.wustl.edu  Mon Mar 30 21:13:46 2009
From: BillD at cait.wustl.edu (Bill Darte)
Date: Mon, 30 Mar 2009 20:13:46 -0500
Subject: [arin-ppml] clarification of Board actions Feb 2 and Mar 18,
	2009
References: <376189.27706.qm@web63303.mail.re1.yahoo.com>
	<107DD4CEABC54F669D321A6EB64005F3@tedsdesk>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087531F88@ex1.cait.wustl.edu>

So do you think ARIN needs to ask for all address space to be re-justified, documented and when there is obvious under-utilization they reclaim it?

Bill Darte


-----Original Message-----
From: arin-ppml-bounces at arin.net on behalf of Ted Mittelstaedt
Sent: Mon 3/30/2009 7:38 PM
To: 'Lee Howard'; ppml at arin.net
Subject: Re: [arin-ppml] clarification of Board actions Feb 2 and Mar 18,2009
 
 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Lee Howard
> Sent: Monday, March 30, 2009 9:07 AM
> To: ppml at arin.net
> Subject: [arin-ppml] clarification of Board actions Feb 2 and 
> Mar 18, 2009
> 


> The 
> Board has been concerned for some time that the lack of a 
> liberalized transfer policy would create legal risk: that we 
> had not provided a mechanism to improve the efficient 
> utilization of previously-allocated resources, and that this 
> risk was significant enough to jeopardize ARIN's ability to 
> fulfill its stewardship mission.
> 

I have been saying this same thing for years and this is
why I proposed the POC cleanup.  HOWEVER it must be clear that
this statement presumes that the legal risk is created by
the lack of a liberalized transfer policy.  This is a fundamentally
flawed argument.  The legal risk is NOT created by this,
the legal risk is created by INSUFFICIENT utilization of
assignable IPv4.

The fear argument goes something like this:

When IPv4 runs out some large cash-rich org will request a
block and be denied.  That org will then spend it's money
lobbying it's nation's government that the RIR's know that
there's lots of available IPv4 tied up in old assignments that
aren't being used, and that because ARIN has the bulk of it,
and ARIN hasn't done enough to scavenge out this stale addressing,
that ARIN is no longer functioning, and that the U.N. needs
to assign a committee - like WIPO was done with the DNS 
system - to interfere and take control of the assignment
mechanism away from ARIN.

ARIN will cease to exist and chaos will ensue.  Previously signed
contracts will be voided out under the guise of an emergency.  There
is plenty of legal precedent for this - for example, in the US a bankruptcy
court can wipe out contracts if it wants.

As a follower of politics, I personally think this argument
has a lot of validity.  But the Board and ARIN staff and many
people are falling for the idea that the problem is in the
transfer policy.  It IS NOT and NEVER HAS BEEN.

It is in operations - it is failure to properly document
use of IP addressing.

Any county government today has FAR BETTER documentation of
land deeds than ARIN has of orgs assigned to IP addressing.
And their taxation departments go to the utmost in finding
landowners.

It is NOT necessary to create a buying-and-selling market of
IP numbers to obtain close to 100% use of routable IPv4.  It
is merely necessary to prove that all assignable, routable IPv4
is in use on the Internet.  Cleaning and grooming WHOIS is a
major first step.

IMHO what ARIN and the Board are attempting to do is take the
easy way out.  They figure if they hang up a for-sale sign on
IP addressing that there's enough bottom-feeders and scavengers
out on the Internet who will be looking for a quick buck, who
will set themselves up as "brokers" of these IPv4 sales, that
if they end up getting sued, or if the United Nations decides
to get involved, that they can make the argument that since 
a financial incentive now exists with this buying-and-selling market
to scavenge up old IPv4 addresses, obviously, there's no abandoned
IPv4 floating around on the Internet, because the scavengers
are out there fishing it out of the pond.

IMHO this is a very weak argument.  It also assumes that 
after the former-bottom-feeders, now IP-brokers
have finished cleaning out the IPv4 pool of usable IPv4, that
they will mildly go off into the sunset, and disappear.  That
isn't what will happen.  Instead these people will simply
move into the business of creating complex obfuscating
schemes to get portable IPv6 to people who do not and never will
meet the qualifications for their own addressing - and the number of
routes in the dfz will soar to immense levels.

It is like if the State of California decided that since they
can't document 10% of the current whereabouts of tax-dodging
landowners owning land in CA, that they should just declare that 
any Realtor who thinks that a piece of land is abandoned
is now allowed to just sell it to the highest bidder - instead
of what they actually do, which is the state takes back ownership of the
property as a result of failure to pay taxes.

It is an utterly ridiculous argument when applied to most
scarce resources, and the reason some people are thinking
it has validity to IP addressing is simply because they aren't
very experienced with the messes that are created when trying to do this
kind of thing with public resources.

Ted

_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090330/8e4cf0a8/attachment.htm>

From dogwallah at gmail.com  Tue Mar 31 00:51:14 2009
From: dogwallah at gmail.com (McTim)
Date: Tue, 31 Mar 2009 07:51:14 +0300
Subject: [arin-ppml] clarification of Board actions Feb 2 and Mar 18,
	2009
In-Reply-To: <107DD4CEABC54F669D321A6EB64005F3@tedsdesk>
References: <376189.27706.qm@web63303.mail.re1.yahoo.com>
	<107DD4CEABC54F669D321A6EB64005F3@tedsdesk>
Message-ID: <f65fb55e0903302151h4a681b29j354b7445d7576e2@mail.gmail.com>

On 3/31/09, Ted Mittelstaedt <tedm at ipinc.net> wrote:
>
>
> > The
>  > Board has been concerned for some time that the lack of a
>  > liberalized transfer policy would create legal risk: that we
>  > had not provided a mechanism to improve the efficient
>  > utilization of previously-allocated resources, and that this
>  > risk was significant enough to jeopardize ARIN's ability to
>  > fulfill its stewardship mission.
>  >
>
>
> I have been saying this same thing for years and this is
>  why I proposed the POC cleanup.  HOWEVER it must be clear that
>  this statement presumes that the legal risk is created by
>  the lack of a liberalized transfer policy.  This is a fundamentally
>  flawed argument.  The legal risk is NOT created by this,
>  the legal risk is created by INSUFFICIENT utilization of
>  assignable IPv4.
>
>  The fear argument goes something like this:
>
>  When IPv4 runs out some large cash-rich org will request a
>  block and be denied.  That org will then spend it's money
>  lobbying it's nation's government that the RIR's know that
>  there's lots of available IPv4 tied up in old assignments that
>  aren't being used, and that because ARIN has the bulk of it,
>  and ARIN hasn't done enough to scavenge out this stale addressing,
>  that ARIN is no longer functioning, and that the U.N. needs
>  to assign a committee - like WIPO was done with the DNS
>  system - to interfere and take control of the assignment
>  mechanism away from ARIN.

..and they will be doing this with a fleet of black helicopters
landing in Chantilly?

-- 
Cheers,

McTim


From michael.dillon at bt.com  Tue Mar 31 04:26:31 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 31 Mar 2009 09:26:31 +0100
Subject: [arin-ppml] How hard is it to transition to IPv6?
In-Reply-To: <40F4213F98FB45D6AB974BE50A35EC4B@tedsdesk>
Message-ID: <28E139F46D45AF49A31950F88C49745863EBE2@E03MVZ2-UKDY.domain1.systemhost.net>

> Almost always, issuing a simple ultimatim is 
> counterproductive. 

Agreed. If you are going to give a supplier an ultimatum
about IPv6 it has to be realistic. For instance you might
refuse to sign a multiyear contract and only sign a one
year renewal with the caveat that if IPv6 support is not
clearly on the cards by the following year, there will 
not be another renewal.

You have to be realistic about the effort that a vendor
has to make and about the timelines for v4 runout which
are still about two years away. Today, if you want to
be tough, demand that they have IPv6 on their roadmap 
with full availability targeted two years from now, and
put it in your contract that they provide quarterly reports
on progress towards IPv6 availability. This would work with
vendors of DSL gateway devices, with firewall vendors who
you pay for support contracts, or with upstream ISPs.

> When pushed, large companies look at everything from a 
> cost/benefit ratio.

Some companies will go down the road of tactical thinking
where all decisions are made based on immediate profitability.
Those companies are likely to back themselves into a corner
when IPv6 bursts onto the scene. Even if there is a profitable
business to be made mopping up all the IPv4 diehard customers
from other ISPs, it will be difficult to get the supply of IPv4
addresses needed to do this.

> Even the US Government, which you wouild think is the 600 
> pound gorilla on this, discovered that.  They mandated IPv6 
> for last year - and still a lot of their vendors weren't in 
> compliance by the deadline.  Some likely still aren't.  I'm 
> sure all are working on it, though.

The USG didn't make a realistic demand. They just drew a line
in the sand without any relation to IPv6 transition plans of
their agencies.

> But, for most other people, I think just being persistent and 
> continuing to bother your vendors, asking for it, would 
> eventually work.  After all, vendors know they have to switch 
> over to it eventually and I think all the large ones are 
> working on it.

It could eventually work but it depends on how you communicate 
it to the vendor. You want to make it clear that there is a 
timeline, that you yourself are deploying according to a timeline
and that you want the vendor to commit to also develop to that
timeline. In the past, people just put it as an RFP requirement
without any dialog to back it up, and vendors got used to
ignoring it.

--Michael Dillon


From martin.hannigan at batelnet.bs  Tue Mar 31 08:49:58 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Tue, 31 Mar 2009 08:49:58 -0400
Subject: [arin-ppml] Draft Policy 2009-3 (Global): Allocation of IPv4
	Blocks to Regional Internet Registries
In-Reply-To: <2E2FECEBAE57CC4BAACDE67638305F10484CF8FB85@ROCH-EXCH1.corp.pvt>
References: <37137.208.54.95.48.1238379940.squirrel@webmail.lacnic.net.uy>
	<49D1509D.5030907@verizonbusiness.com>
	<2E2FECEBAE57CC4BAACDE67638305F10484CF8FB85@ROCH-EXCH1.corp.pvt>
Message-ID: <4607e1d50903310549q442bcb5oe277d23ad702c396@mail.gmail.com>

On Mon, Mar 30, 2009 at 7:36 PM, Azinger, Marla <
marla.azinger at frontiercorp.com> wrote:

> The only way to even attempt having a textual version that all RIR's can
> agree on would be to actively seek out input from the community of the RIR's
> and injecting the input before submitting it for Global consideration (non
> just select members who's names appear on the proposal).  The route this
> policy took was straight from authors and directly to submission and never
> took into consideration input from community members.  So the back lash of
> skipping the community is now being felt. Now community input is coming out
> after the formal submission to all the RIR's and this basically doubles the
> difficulty of achieving any consensus on a policy that reads the same in all
> RIR's.


The current global policy process that was established through the ICANN and
RIR MoU and attachments was designed for simpler times I.e less political.
If you have a policy that is a straight, non controversial, IANA to RIR
mechanism for allocating ASN or IP address resources it works quite well.
That global policy is good example of an efficient use of the capability.
Regarding seeking community input beforehand, I agree with you, but that's
good for global or regional policy and isn't something that should come as a
surprise.

Any global policy related to IPv4 address space will undoubtedly test the
global policy capabilities of the RIR's as it is currently written. Imposing
policy on other regions and challenging their autonomy should be extremely
difficult. This policy has shown us that there is no such thing as a "shoe
in" and that the policy cabapability established inter-RIR works fairly
well.

Best Regards,

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090331/82ab9fca/attachment.htm>

From martin.hannigan at batelnet.bs  Tue Mar 31 08:54:41 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Tue, 31 Mar 2009 08:54:41 -0400
Subject: [arin-ppml] Draft Policy 2009-3 (Global): Allocation of IPv4
	Blocks to Regional Internet Registries
In-Reply-To: <49D138C7.7040207@gmail.com>
References: <37137.208.54.95.48.1238379940.squirrel@webmail.lacnic.net.uy>
	<49D10949.9000803@arin.net> <49D11F48.6090905@gmail.com>
	<9EDA9B03-C069-44B5-B06D-D60E510849FE@lacnic.net>
	<4607e1d50903301318y3c142303g42a991f6be79b0a6@mail.gmail.com>
	<49D12E37.9040307@gmail.com>
	<4607e1d50903301351o52e48c66n21163809fcf0f630@mail.gmail.com>
	<49D138C7.7040207@gmail.com>
Message-ID: <4607e1d50903310554x6b3943dakc318724d5ef9879c@mail.gmail.com>

On Mon, Mar 30, 2009 at 5:25 PM, Scott Leibrand <scottleibrand at gmail.com>wrote:

[ clip ]


>
> Not advancing the proposal (abandoning it) is definitely an option.


[ clip ]


Thank you, Scott. I support abandoning this proposal altogether.

Best Regards,

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090331/796ca525/attachment.htm>

From farmer at umn.edu  Tue Mar 31 09:27:47 2009
From: farmer at umn.edu (David Farmer)
Date: Tue, 31 Mar 2009 08:27:47 -0500
Subject: [arin-ppml] Draft Policy 2009-3 (Global): Allocation of IPv4
	Blocks to Regional Internet Registries
In-Reply-To: <4607e1d50903310554x6b3943dakc318724d5ef9879c@mail.gmail.com>
References: <37137.208.54.95.48.1238379940.squirrel@webmail.lacnic.net.uy>,
	<49D138C7.7040207@gmail.com>,
	<4607e1d50903310554x6b3943dakc318724d5ef9879c@mail.gmail.com>
Message-ID: <49D1D403.7676.302754E@farmer.umn.edu>

On 31 Mar 2009 Martin Hannigan wrote:

> On Mon, Mar 30, 2009 at 5:25 PM, Scott Leibrand <scottleibrand at gmail.com>wrote:
> 
> [ clip ]
> >
> > Not advancing the proposal (abandoning it) is definitely an option.
>
> [ clip ]
>  
> Thank you, Scott. I support abandoning this proposal altogether.
>
> Best Regards,
> 
> Martin
> 

I'll reask Scotts question then;

On 30 Mar 2009 Scott Leibrand wrote:

>  - If you oppose 2009-3 completely, do you believe that current policy 
> is adequate, or would you support some other mechanism to allow for the 
> reallocation of IPv4 blocks between RIRs?




================================================
=======
David Farmer				     Email:	
farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota			     Phone:	612-626-
0815
2218 University Ave SE			     Cell:		
612-812-9952
Minneapolis, MN 55414-3029		     FAX:	612-626-
1818
================================================
=======



From martin.hannigan at batelnet.bs  Tue Mar 31 09:35:37 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Tue, 31 Mar 2009 09:35:37 -0400
Subject: [arin-ppml] Draft Policy 2009-3 (Global): Allocation of IPv4
	Blocks to Regional Internet Registries
In-Reply-To: <49D1D403.7676.302754E@farmer.umn.edu>
References: <37137.208.54.95.48.1238379940.squirrel@webmail.lacnic.net.uy>
	<49D138C7.7040207@gmail.com>
	<4607e1d50903310554x6b3943dakc318724d5ef9879c@mail.gmail.com>
	<49D1D403.7676.302754E@farmer.umn.edu>
Message-ID: <4607e1d50903310635m5f39fec0tce4fc59ebb31573e@mail.gmail.com>

On Tue, Mar 31, 2009 at 9:27 AM, David Farmer <farmer at umn.edu> wrote:

> On 31 Mar 2009 Martin Hannigan wrote:
>
> > On Mon, Mar 30, 2009 at 5:25 PM, Scott Leibrand <scottleibrand at gmail.com
> >wrote:
> >
> > [ clip ]
> > >
> > > Not advancing the proposal (abandoning it) is definitely an option.
> >
> > [ clip ]
> >
> > Thank you, Scott. I support abandoning this proposal altogether.
> >
> > Best Regards,
> >
> > Martin
> >
>
> I'll reask Scotts question then;
>
> On 30 Mar 2009 Scott Leibrand wrote:
>
> >  - If you oppose 2009-3 completely, do you believe that current policy
> > is adequate, or would you support some other mechanism to allow for the
> > reallocation of IPv4 blocks between RIRs?
>


Sorry David, square pegs->round holes.

Best,

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090331/1a33401b/attachment.htm>

From mueller at syr.edu  Tue Mar 31 09:41:13 2009
From: mueller at syr.edu (Milton L Mueller)
Date: Tue, 31 Mar 2009 09:41:13 -0400
Subject: [arin-ppml] clarification of Board actions Feb 2 and Mar 18,
	2009
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D03087531F88@ex1.cait.wustl.edu>
References: <376189.27706.qm@web63303.mail.re1.yahoo.com>
	<107DD4CEABC54F669D321A6EB64005F3@tedsdesk>
	<EACF8B735E9CBA4B8BAF9E4165D03087531F88@ex1.cait.wustl.edu>
Message-ID: <75822E125BCB994F8446858C4B19F0D76BE5560A@SUEX07-MBX-04.ad.syr.edu>

The fear argument goes something like this:

When IPv4 runs out some large cash-rich org will request a
block and be denied.  That org will then spend it's money
lobbying it's nation's government that the RIR's know that
there's lots of available IPv4 tied up in old assignments that
aren't being used, and that because ARIN has the bulk of it,
and ARIN hasn't done enough to scavenge out this stale addressing,

So far, so plausible. Your scenario goes comically awry at this point, however:

that ARIN is no longer functioning, and that the U.N. needs
to assign a committee - like WIPO was done with the DNS
system - to interfere and take control of the assignment
mechanism away from ARIN.

As someone who does a bit more than "follow" the global politics of Internet governance, I can assure you that large, cash-rich organizations (ISPs) in North America are the last parties on earth who will want to call in the United Nations. It is true that the ITU would like to get address allocation/assignment back into an intergovernmental system. It is also true that the entire Internet industry and the USG are implacably opposed to that. Outside of China and a few middle eastern countries like Syria, you would have a hard time telling me who does support that.

ARIN will cease to exist and chaos will ensue.

Really? Just like that? I shake with fear.

It is NOT necessary to create a buying-and-selling market of
IP numbers to obtain close to 100% use of routable IPv4.  It
is merely necessary to prove that all assignable, routable IPv4
is in use on the Internet.  Cleaning and grooming WHOIS is a
major first step.

What you seem to miss is that a transfer system, executed properly, is the best way to clean and groom the Whois system because it harnesses the private incentive to benefit from trades. ARIN can either swim upstream or swim downstream.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090331/c7ed327b/attachment.htm>

From tvest at pch.net  Tue Mar 31 10:13:38 2009
From: tvest at pch.net (Tom Vest)
Date: Tue, 31 Mar 2009 10:13:38 -0400
Subject: [arin-ppml] clarification of Board actions Feb 2 and Mar 18,
	2009
In-Reply-To: <75822E125BCB994F8446858C4B19F0D76BE5560A@SUEX07-MBX-04.ad.syr.edu>
References: <376189.27706.qm@web63303.mail.re1.yahoo.com>
	<107DD4CEABC54F669D321A6EB64005F3@tedsdesk>
	<EACF8B735E9CBA4B8BAF9E4165D03087531F88@ex1.cait.wustl.edu>
	<75822E125BCB994F8446858C4B19F0D76BE5560A@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <0B1F5A0C-C917-4F23-8C19-61EC83C280EF@pch.net>


On Mar 31, 2009, at 9:41 AM, Milton L Mueller wrote:

> The fear argument goes something like this:
>
> When IPv4 runs out some large cash-rich org will request a
> block and be denied.  That org will then spend it's money
> lobbying it's nation's government that the RIR's know that
> there's lots of available IPv4 tied up in old assignments that
> aren't being used, and that because ARIN has the bulk of it,
> and ARIN hasn't done enough to scavenge out this stale addressing,
>
> So far, so plausible. Your scenario goes comically awry at this  
> point, however:
>
> that ARIN is no longer functioning, and that the U.N. needs
> to assign a committee - like WIPO was done with the DNS
> system - to interfere and take control of the assignment
> mechanism away from ARIN.
>
> As someone who does a bit more than ?follow? the global politics of  
> Internet governance, I can assure you that large, cash-rich  
> organizations (ISPs) in North America are the last parties on earth  
> who will want to call in the United Nations. It is true that the ITU  
> would like to get address allocation/assignment back into an  
> intergovernmental system. It is also true that the entire Internet  
> industry and the USG are implacably opposed to that. Outside of  
> China and a few middle eastern countries like Syria, you would have  
> a hard time telling me who does support that.
>
> ARIN will cease to exist and chaos will ensue.
>
> Really? Just like that? I shake with fear.
>
> It is NOT necessary to create a buying-and-selling market of
> IP numbers to obtain close to 100% use of routable IPv4.  It
> is merely necessary to prove that all assignable, routable IPv4
> is in use on the Internet.  Cleaning and grooming WHOIS is a
> major first step.
>
> What you seem to miss is that a transfer system, executed properly,  
> is the best way to clean and groom the Whois system because it  
> harnesses the private incentive to benefit from trades. ARIN can  
> either swim upstream or swim downstream.
>
Yes, the proof of that assertion is evident in the current state of  
DNS-related whois.

The only reason that dysfunctional DNS whois can be abided without  
(even greater) consequence is because the number registries continue  
to be widely accepted as good enough -- and efforts to further improve  
their quality (real and perceived) are underway.

The private incentives to trade are, by definition, private. Presuming  
that you can know in advance that they will balance in favor of public  
identifiability of number resources would be irresponsible, and  
unrealistic in the face of actual industry experience.

Milton, we are still waiting your views on what "cleaning and  
grooming" actually means -- the last time an inquiry into this  
question was made, you provided no response:

On Aug 31, 2008, at 4:24 PM, Tom Vest wrote:

> Hi Milton,
>
> A couple of quick questions:
>
> 1. Do you think that the completeness and accuracy of current DNS  
> whois is the right standard for IP number whois?
>
> 2. Does your vision for individual privacy rights extend to  
> "corporate persons," or only to natural persons?
> -- It would appear that you reject the distinction in DNS whois:
> http://forum.icann.org/lists/gnso-reg-sgc/msg00072.html
>
> Thanks,
>
> TV


On Sep 2, 2008, at 11:42 AM, Milton L Mueller wrote:

>> -----Original Message-----
>> From: Tom Vest [mailto:tvest at pch.net]
>>
>> A couple of quick questions:
>>
>> 1. Do you think that the completeness and accuracy of current DNS
>> whois is the right standard for IP number whois?
>
> I have a more relevant question to ask. Do you think that IP number
> Whois should be optimized to permit copyright holders to identify
> individual file-sharers on ISP networks and serve legal process on  
> them?
>
> You answer that first, we'll discuss the details of DNS Whois
> afterwards. It is a subject I know a lot about.

Since you raised this issue again, I believe that it would be helpful  
if you actually shared your views on this matter this time around.

Thanks,

TV





From kkargel at polartel.com  Tue Mar 31 11:30:44 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 31 Mar 2009 10:30:44 -0500
Subject: [arin-ppml] Summary of 2009-1 discussion so far
In-Reply-To: <997BC128AE961E4A8B880CD7442D94800A83EE7D@NJCHLEXCMB01.cable.comcast.com>
References: <997BC128AE961E4A8B880CD7442D94800A83EE7D@NJCHLEXCMB01.cable.comcast.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AF4E@mail>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Alexander, Daniel
> Sent: Monday, March 30, 2009 5:11 PM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Summary of 2009-1 discussion so far
> 
> 
> Hello All,
> 
> This email is rather long but I wanted to try and summarize some of the
> discussion of 2009-1 so far. My apologies if I neglected any particular
> comments or if my counts might be off. I was trying to select one or two
> points from each of the major issues, and I was consolidating more than
> one thread. If you have not done so already, please let the AC know if
> you are in favor or against this proposal, or if you have specific
> suggestions as to how the wording should be changed.
> 
> 
> Notable Points:
> 
> Recurring questions of clarity and procedure.
> 	Why did the BoT use the Emergency PDP?
> 	Where is the proper explanation in the meeting minutes?
> 	What was the emergency?
> 	Why was this needed?
> 	Is 2008-6 actually accepted and just not implemented?
> 
Don't forget the point that any proposal promoting a monetized P2P transfer
policy is bad.  

Kevin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090331/722f4732/attachment.bin>

From kkargel at polartel.com  Tue Mar 31 11:38:18 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 31 Mar 2009 10:38:18 -0500
Subject: [arin-ppml] clarification of Board actions Feb 2 and Mar 18,
	2009
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D03087531F88@ex1.cait.wustl.edu>
References: <376189.27706.qm@web63303.mail.re1.yahoo.com><107DD4CEABC54F669D321A6EB64005F3@tedsdesk>
	<EACF8B735E9CBA4B8BAF9E4165D03087531F88@ex1.cait.wustl.edu>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AF4F@mail>

________________________________________
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Bill Darte
Sent: Monday, March 30, 2009 8:14 PM
To: Ted Mittelstaedt; Lee Howard; ppml at arin.net
Subject: Re: [arin-ppml] clarification of Board actions Feb 2 and Mar
18,2009

>>So do you think ARIN needs to ask for all address space to be
re-justified, documented and when there is obvious under-utilization they
reclaim it?

>>Bill Darte


I don't think that is anything close to what he said.  I for one have no
problem with refreshing my POC and ORG records.  I would not like to see it
be an annual task perhaps, but I see no problem with doing it once for the
good of the community.  

Kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090331/7ea5919b/attachment.bin>

From kkargel at polartel.com  Tue Mar 31 12:03:48 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 31 Mar 2009 11:03:48 -0500
Subject: [arin-ppml] clarification of Board actions Feb 2 and Mar 18,
	2009
In-Reply-To: <75822E125BCB994F8446858C4B19F0D76BE5560A@SUEX07-MBX-04.ad.syr.edu>
References: <376189.27706.qm@web63303.mail.re1.yahoo.com><107DD4CEABC54F669D321A6EB64005F3@tedsdesk><EACF8B735E9CBA4B8BAF9E4165D03087531F88@ex1.cait.wustl.edu>
	<75822E125BCB994F8446858C4B19F0D76BE5560A@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AF50@mail>

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Milton L Mueller
Sent: Tuesday, March 31, 2009 8:41 AM
To: ppml at arin.net
Subject: Re: [arin-ppml] clarification of Board actions Feb 2 and Mar
18,2009

>>The fear argument goes something like this:

>>When IPv4 runs out some large cash-rich org will request a
>>block and be denied.? That org will then spend it's money
>>lobbying it's nation's government that the RIR's know that
>>there's lots of available IPv4 tied up in old assignments that
>>aren't being used, and that because ARIN has the bulk of it,
>>and ARIN hasn't done enough to scavenge out this stale addressing,
>>So far, so plausible. Your scenario goes comically awry at this point,
however:
>>that ARIN is no longer functioning, and that the U.N. needs
>>to assign a committee - like WIPO was done with the DNS
>>system - to interfere and take control of the assignment
>>mechanism away from ARIN.
>As someone who does a bit more than ?follow? the global politics of
Internet governance, I can assure you that large, cash-rich organizations
(ISPs) in North America are >the last parties on earth who will want to call
in the United Nations. It is true that the ITU would like to get address
allocation/assignment back into an >intergovernmental system. It is also
true that the entire Internet industry and the USG are implacably opposed to
that. Outside of China and a few middle eastern countries >like Syria, you
would have a hard time telling me who does support that. 
>ARIN will cease to exist and chaos will ensue.? 
>Really? Just like that? I shake with fear.
>It is NOT necessary to create a buying-and-selling market of
>IP numbers to obtain close to 100% use of routable IPv4.? It
>is merely necessary to prove that all assignable, routable IPv4
>is in use on the Internet.? Cleaning and grooming WHOIS is a
>major first step.
>What you seem to miss is that a transfer system, executed properly, is the
best way to clean and groom the Whois system because it harnesses the
private incentive to >benefit from trades. ARIN can either swim upstream or
swim downstream. ?

A transfer system will inexorably raise the cost of doing business on the
internet.  However you paint it this is a bad thing for the community and
for society.  I will continue to oppose P2P transfer policies whenever they
are presented.

Something I have started to consider, which has it's own set of flaws, would
perhaps be an ARIN run publically accessible auction for returned IP space
which would pay the returnee an amount not greater than the registration
fees they had already given ARIN for that IP block, or in the case of legacy
space an amount equal to some reasonable multiple of registration fees for
the block (10?).  An alternative to an auction would be a lottery with the
winner of the lottery to pay to ARIN the publically stated amount used to
reimburse the returnee their registration fees plus ARIN handling charges.
This would be fair to the public, would not foment a runaway commodities
market, and would offer some small incentive to return IP netblocks.  The
lottery concept would avoid ARIN profit taking.  The accepting organization
would of course have to meet current ARIN criteria for any netblock they
received.  I have not thought this through enough to be even close to a
proposal.

Kevin



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090331/b70fd3f4/attachment.bin>

From cgrundemann at gmail.com  Tue Mar 31 12:53:34 2009
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Tue, 31 Mar 2009 10:53:34 -0600
Subject: [arin-ppml] Summary of 2009-1 discussion so far
In-Reply-To: <17838240D9A5544AAA5FF95F8D52031605B42D50@ad-exh01.adhost.lan>
References: <997BC128AE961E4A8B880CD7442D94800A83EE7D@NJCHLEXCMB01.cable.comcast.com>
	<17838240D9A5544AAA5FF95F8D52031605B42D50@ad-exh01.adhost.lan>
Message-ID: <443de7ad0903310953p186ad1f8v9868c2c84d26b5c6@mail.gmail.com>

On Mon, Mar 30, 2009 at 16:13, Michael K. Smith - Adhost
<mksmith at adhost.com> wrote:
>
>
> Opposed:
>
> ?Leo Bicknell
> ?Kevin Kargel
> ?Ted Mittelstaedt
> ?William Herrin
> ?Seth Mattinen
> ?Jeremy H Griffith
> ?Jay Hennigan
> + Michael K. Smith
+ Chris Grundemann

I am not convinced that the need is great enough for the BoT to invoke
the emergency PDP; neither through flaws in 2008-6 which the community
accepted nor through current circumstances.

My $.02: I agree with others that the Board's concerns should have
been raised during the transfer policy discussions that have taken
place over the last year plus (almost two?).  I further agree that the
simplicity, sunset clause, IPv4 exclusivity and (explicit) RSA
restriction were major factors in the communities acceptance of
2008-6.

I think that the best method of proceeding is for the Board to take
one of three actions (none include 2009-1 or the emergency PDP):
1)  Accept 2008-6 as presented and set an implementation date (which
could be immediately since they appear to believe that is what is
needed).
 - This gets a more open transfer policy on the books now (which the
Board obviously sees as an urgent need) and maintains community
consensus as an integral part of the policy process.
2)  Reject 2008-6 and publicly state their reasons in detail; this
could (would probably) include a call for someone to propose a policy
which addresses these concerns.
 - This allows the BoT's concerns to be addressed (by the community)
and maintains community consensus as an integral part of the policy
process.
3)  Accept 2008-6 as presented, set an implementation date and call
for a new proposal to address it's gaps before such date.
 - This hits all three targets; it gets a more open transfer policy on
the books now, allows the BoT's concerns to be addressed (by the
community) and maintains community consensus as an integral part of
the policy process.

I would warn strongly against alienating the community at large as we
dive into a period that is certain to be chaotic enough under the best
circumstances...

~Chris

>
> Regards,
>
> Mike
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
-- 
Chris Grundemann
weblog.chrisgrundemann.com


From mueller at syr.edu  Tue Mar 31 14:47:22 2009
From: mueller at syr.edu (Milton L Mueller)
Date: Tue, 31 Mar 2009 14:47:22 -0400
Subject: [arin-ppml] Draft Policy 2009-3 (Global): Allocation of IPv4
 Blocks to Regional Internet Registries
In-Reply-To: <49D140F3.7010606@gmail.com>
References: <37137.208.54.95.48.1238379940.squirrel@webmail.lacnic.net.uy>
	<49D10949.9000803@arin.net> <49D11F48.6090905@gmail.com>
	<9EDA9B03-C069-44B5-B06D-D60E510849FE@lacnic.net>
	<4607e1d50903301318y3c142303g42a991f6be79b0a6@mail.gmail.com>
	<49D12E37.9040307@gmail.com>
	<4607e1d50903301351o52e48c66n21163809fcf0f630@mail.gmail.com>
	<49D138C7.7040207@gmail.com> <49D140F3.7010606@gmail.com>
Message-ID: <75822E125BCB994F8446858C4B19F0D76BE5561D@SUEX07-MBX-04.ad.syr.edu>



> -----Original Message-----
> > the mandatory return of reclaimed
> > space removes most of the incentive for RIRs to reclaim space.

What?? The RIRs have "incentives"??? Now here I thought they were transparent vessels for the community will.  ;-)

> > So as a compromise position, it
> > might make sense to make return of legacy space (allocated prior to
> > RIR creation) mandatory, while leaving return of non-legacy space
> > optional.

A good idea as far as it goes. But what incentive would the RIRs have to reclaim legacy space then? 

--MM


From tedm at ipinc.net  Tue Mar 31 15:31:45 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 31 Mar 2009 12:31:45 -0700
Subject: [arin-ppml] clarification of Board actions Feb 2 and Mar 18,
	2009
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D03087531F88@ex1.cait.wustl.edu>
References: <376189.27706.qm@web63303.mail.re1.yahoo.com>
	<107DD4CEABC54F669D321A6EB64005F3@tedsdesk>
	<EACF8B735E9CBA4B8BAF9E4165D03087531F88@ex1.cait.wustl.edu>
Message-ID: <7E6F17317F9C42E48D0C4D84D39700F7@tedsdesk>

I would not go that far right now.
 
I can forsee a time that there will be a lot of pressure on ARIN to
rejustify all IPv4 blocks.
 
I personally would not like having to do that, but OTOH our IPv4 holdings
are small and
it is not like it would take many weeks of effort.  However I would fight
doing this if
the current situation with legacy holders essentially getting their IPv4
numbering for free
was perpetuated.
 
I think professionally that the industry would be damaged by being forced to
rejustify
IPv4 holdings as it would encourage widespread fraudulent reporting, and it
would put
ARIN in the position where they would be happy to have fraudulent reports
since it would
just allow them to pass the buck and go back to whatever was pressuring them
and
say "see, they say they have 100% utilization so prove they don't"  It would
also sink
a lot of labor and money into existing IPv4 holdings which would be better
spent on
IPv6 transitioning efforts.  And of course, once an org spends money on
cleaning up
existing IPv4 holdings they will want to get their money's worth out of the
labor so it
would strongly encourage continuation of IPv4.
 
>From a political viewpoint if ARIN cleans up things now, it will give them
the deniability
they need later on to fight against ham-handed efforts by governments to
force continuation
of IPv4.  It's real difficult to argue there's a lot of unused IPv4 when
ARIN has a list of all
IPv4 holders that are current.
 
What I do think they need to do right now is verify what is documented.  My
guess is
that if they start verification efforts now that by IPv4 runout date, they
will have completed
verification on everything larger than a /16 and my guess is that the major
players with
political dollars and muscle to throw around, will not be interested in a
non-contiguous
block of IPv4 that is smaller than that.
 
Almost certainly, the small fry (of which we are) will be begging for under
/16 and smaller
all the way down to /22's, /23's, /24's, for the next decade.  But, the
small fry do not
have the political muscle and money to influence governments and seriously
damage
the RIR system, and can thus be safely ignored.
 
I realize this is a cynical view but I'm speaking from what your typical
government bureaucrat
would be thinking, who doesn't know an IP address from a postal address.  I
know that
the people who really understand this are a lot more concerned with the rest
of the
community.  But I just see the amount of money flowing over the Internet
today, and I
think it is really naive to think that we will be able to fight against that
sort of influence
unless we have everything signed in triplicate, sent in, sent back, queried,
lost, found,
subjected to public enquiry, lost again, and finally buried in soft peat for
three months and
recycled as firelighters.
 
Ted
 



  _____  

From: Bill Darte [mailto:BillD at cait.wustl.edu] 
Sent: Monday, March 30, 2009 6:14 PM
To: Ted Mittelstaedt; Lee Howard; ppml at arin.net
Subject: RE: [arin-ppml] clarification of Board actions Feb 2 and Mar
18,2009



So do you think ARIN needs to ask for all address space to be re-justified,
documented and when there is obvious under-utilization they reclaim it?

Bill Darte


-----Original Message-----
From: arin-ppml-bounces at arin.net on behalf of Ted Mittelstaedt
Sent: Mon 3/30/2009 7:38 PM
To: 'Lee Howard'; ppml at arin.net
Subject: Re: [arin-ppml] clarification of Board actions Feb 2 and Mar
18,2009



> -----Original Message-----
> From: arin-ppml-bounces at arin.net
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Lee Howard
> Sent: Monday, March 30, 2009 9:07 AM
> To: ppml at arin.net
> Subject: [arin-ppml] clarification of Board actions Feb 2 and
> Mar 18, 2009
>


> The
> Board has been concerned for some time that the lack of a
> liberalized transfer policy would create legal risk: that we
> had not provided a mechanism to improve the efficient
> utilization of previously-allocated resources, and that this
> risk was significant enough to jeopardize ARIN's ability to
> fulfill its stewardship mission.
>

I have been saying this same thing for years and this is
why I proposed the POC cleanup.  HOWEVER it must be clear that
this statement presumes that the legal risk is created by
the lack of a liberalized transfer policy.  This is a fundamentally
flawed argument.  The legal risk is NOT created by this,
the legal risk is created by INSUFFICIENT utilization of
assignable IPv4.

The fear argument goes something like this:

When IPv4 runs out some large cash-rich org will request a
block and be denied.  That org will then spend it's money
lobbying it's nation's government that the RIR's know that
there's lots of available IPv4 tied up in old assignments that
aren't being used, and that because ARIN has the bulk of it,
and ARIN hasn't done enough to scavenge out this stale addressing,
that ARIN is no longer functioning, and that the U.N. needs
to assign a committee - like WIPO was done with the DNS
system - to interfere and take control of the assignment
mechanism away from ARIN.

ARIN will cease to exist and chaos will ensue.  Previously signed
contracts will be voided out under the guise of an emergency.  There
is plenty of legal precedent for this - for example, in the US a bankruptcy
court can wipe out contracts if it wants.

As a follower of politics, I personally think this argument
has a lot of validity.  But the Board and ARIN staff and many
people are falling for the idea that the problem is in the
transfer policy.  It IS NOT and NEVER HAS BEEN.

It is in operations - it is failure to properly document
use of IP addressing.

Any county government today has FAR BETTER documentation of
land deeds than ARIN has of orgs assigned to IP addressing.
And their taxation departments go to the utmost in finding
landowners.

It is NOT necessary to create a buying-and-selling market of
IP numbers to obtain close to 100% use of routable IPv4.  It
is merely necessary to prove that all assignable, routable IPv4
is in use on the Internet.  Cleaning and grooming WHOIS is a
major first step.

IMHO what ARIN and the Board are attempting to do is take the
easy way out.  They figure if they hang up a for-sale sign on
IP addressing that there's enough bottom-feeders and scavengers
out on the Internet who will be looking for a quick buck, who
will set themselves up as "brokers" of these IPv4 sales, that
if they end up getting sued, or if the United Nations decides
to get involved, that they can make the argument that since
a financial incentive now exists with this buying-and-selling market
to scavenge up old IPv4 addresses, obviously, there's no abandoned
IPv4 floating around on the Internet, because the scavengers
are out there fishing it out of the pond.

IMHO this is a very weak argument.  It also assumes that
after the former-bottom-feeders, now IP-brokers
have finished cleaning out the IPv4 pool of usable IPv4, that
they will mildly go off into the sunset, and disappear.  That
isn't what will happen.  Instead these people will simply
move into the business of creating complex obfuscating
schemes to get portable IPv6 to people who do not and never will
meet the qualifications for their own addressing - and the number of
routes in the dfz will soar to immense levels.

It is like if the State of California decided that since they
can't document 10% of the current whereabouts of tax-dodging
landowners owning land in CA, that they should just declare that
any Realtor who thinks that a piece of land is abandoned
is now allowed to just sell it to the highest bidder - instead
of what they actually do, which is the state takes back ownership of the
property as a result of failure to pay taxes.

It is an utterly ridiculous argument when applied to most
scarce resources, and the reason some people are thinking
it has validity to IP addressing is simply because they aren't
very experienced with the messes that are created when trying to do this
kind of thing with public resources.

Ted

_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090331/59c582c2/attachment.htm>

From tedm at ipinc.net  Tue Mar 31 15:38:59 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 31 Mar 2009 12:38:59 -0700
Subject: [arin-ppml] clarification of Board actions Feb 2 and Mar 18,
	2009
In-Reply-To: <f65fb55e0903302151h4a681b29j354b7445d7576e2@mail.gmail.com>
References: <376189.27706.qm@web63303.mail.re1.yahoo.com>
	<107DD4CEABC54F669D321A6EB64005F3@tedsdesk>
	<f65fb55e0903302151h4a681b29j354b7445d7576e2@mail.gmail.com>
Message-ID: <1FAC298BB17E4964946B3D6FACF2A131@tedsdesk>

 

> -----Original Message-----
> From: McTim [mailto:dogwallah at gmail.com] 
> Sent: Monday, March 30, 2009 9:51 PM
> To: Ted Mittelstaedt
> Cc: ppml at arin.net
> Subject: Re: [arin-ppml] clarification of Board actions Feb 2 
> and Mar 18, 2009
> 
> >
> >  The fear argument goes something like this:
> >
> >  When IPv4 runs out some large cash-rich org will request a 
>  block and 
> > be denied.  That org will then spend it's money  lobbying it's 
> > nation's government that the RIR's know that  there's lots of 
> > available IPv4 tied up in old assignments that  aren't 
> being used, and 
> > that because ARIN has the bulk of it,  and ARIN hasn't done 
> enough to 
> > scavenge out this stale addressing,  that ARIN is no longer 
> > functioning, and that the U.N. needs  to assign a committee - like 
> > WIPO was done with the DNS  system - to interfere and take 
> control of 
> > the assignment  mechanism away from ARIN.
> 
> ..and they will be doing this with a fleet of black 
> helicopters landing in Chantilly?
> 

Only if the ARIN staff forget to wear their tinfoil hats.

Seriously though, just consider one little thing for a moment,
the US banking system.  You know, the same banking system that
mugged the US Government late last year for 700 billion dollars.

Think of just how much money those bank CEOs have saved with firing
tellers and replacing them with online banking access over the
Internet.

Now, imagine ARIN telling Chase Bank "sorry, you can't setup that
new online banking center because we think the world has run out
out of IPv4 addresses but we aren't sure because we lost track of
a couple million of them" and try to guess how long ARIN would exist
as an entity after that.

Party's over, folks.  Time to get down and get serious about this
or be content allowing it go to the bureaucrats.

Ted



From tedm at ipinc.net  Tue Mar 31 15:49:45 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 31 Mar 2009 12:49:45 -0700
Subject: [arin-ppml] clarification of Board actions Feb 2 and Mar 18,
	2009
In-Reply-To: <75822E125BCB994F8446858C4B19F0D76BE5560A@SUEX07-MBX-04.ad.syr.edu>
References: <376189.27706.qm@web63303.mail.re1.yahoo.com><107DD4CEABC54F669D321A6EB64005F3@tedsdesk><EACF8B735E9CBA4B8BAF9E4165D03087531F88@ex1.cait.wustl.edu>
	<75822E125BCB994F8446858C4B19F0D76BE5560A@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <D4564024C1B94D5EB88A256CD8B83921@tedsdesk>

 


________________________________

	From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
On Behalf Of Milton L Mueller
	Sent: Tuesday, March 31, 2009 6:41 AM
	To: ppml at arin.net
	Subject: Re: [arin-ppml] clarification of Board actions Feb 2 and
Mar 18,2009
	
	

		It is NOT necessary to create a buying-and-selling market of
	IP numbers to obtain close to 100% use of routable IPv4.  It
	is merely necessary to prove that all assignable, routable IPv4
	is in use on the Internet.  Cleaning and grooming WHOIS is a
	major first step.

	What you seem to miss is that a transfer system, executed properly,
is the best way to clean and groom the Whois system because it harnesses the
private incentive to benefit from trades. ARIN can either swim upstream or
swim downstream.   

Milton,

  This is a leading argument.  We have a dirty WHOIS that needs cleaning.  A
transfer system will clean it.  Therefore a transfer system is the best way
to clean it.  Your conveniently failing to supply any reasoning
of WHY it is the best way other than "just because"

As for your assertion that the major NA ISP's are opposed to increasing
government involvement, that does not invalidate the fear argument at all.
Substitute
the "UN" with "coalition of the largest and richest NA ISPs" and you have
exactly the same scenario - namely, that we have something right now that
operates somewhat democratically, and it will be changed into a system
that is operated autocratically for the good of the rich.

  But frankly I happen to believe the power of government is far larger than
any group of rich ISPs. The US Government, after all, broke up Bell
Telephone.
Pushing around a bunch of ISP's will be child's play.

Ted



From schnizlein at isoc.org  Tue Mar 31 15:59:53 2009
From: schnizlein at isoc.org (John Schnizlein)
Date: Tue, 31 Mar 2009 15:59:53 -0400
Subject: [arin-ppml] clarification of Board actions Feb 2 and Mar 18,
	2009
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AF50@mail>
References: <376189.27706.qm@web63303.mail.re1.yahoo.com><107DD4CEABC54F669D321A6EB64005F3@tedsdesk><EACF8B735E9CBA4B8BAF9E4165D03087531F88@ex1.cait.wustl.edu>
	<75822E125BCB994F8446858C4B19F0D76BE5560A@SUEX07-MBX-04.ad.syr.edu>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4AF50@mail>
Message-ID: <F6697CCB-A06D-4CC9-9D12-D85128C6291E@isoc.org>

Thank you for the clear and strong statement, about which I have some  
questions.

On 2009Mar31, at 12:03 PM, Kevin Kargel wrote:

> A transfer system will inexorably raise the cost of doing business  
> on the
> internet.

I can see that the cost of deploying more IPv4 would likely rise with  
scarcity.  How would this affect anyone else?

>  However you paint it this is a bad thing for the community and
> for society.

Could it be good for the Internet for the cost of deploying IPv4 to  
increase while the cost of deploying IPv6 remains constant, or  
decreases with experience?  Remember that the goal is to replace IPv4  
with IPv6 to maintain global end-to-end transparency.

> I will continue to oppose P2P transfer policies whenever they
> are presented.
>
> Something I have started to consider, which has it's own set of  
> flaws, would
> perhaps be an ARIN run publically accessible auction for returned IP  
> space
> which would pay the returnee an amount not greater than the  
> registration
> fees they had already given ARIN for that IP block, or in the case  
> of legacy
> space an amount equal to some reasonable multiple of registration  
> fees for
> the block (10?).

Would this constitute a monopoly setting prices for IPv4 address space  
in the region?

What would be the cost of compliance with regulation of a monopoly,  
assuming it were legal?

> An alternative to an auction would be a lottery with the
> winner of the lottery to pay to ARIN the publically stated amount  
> used to
> reimburse the returnee their registration fees plus ARIN handling  
> charges.

This seems to add the complication of gambling to the monopoly  
operation.  What about those locations where gambling is not legal?

> This would be fair to the public, would not foment a runaway  
> commodities
> market, and would offer some small incentive to return IP netblocks.

Is a small incentive enough to induce parties to forego the larger  
incentives potentially available through transfers not authorized by  
ARIN?

>  The lottery concept would avoid ARIN profit taking.  The accepting  
> organization
> would of course have to meet current ARIN criteria for any netblock  
> they
> received.  I have not thought this through enough to be even close  
> to a
> proposal.

Let's think through the implications together.

John


From tedm at ipinc.net  Tue Mar 31 16:29:48 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 31 Mar 2009 13:29:48 -0700
Subject: [arin-ppml] clarification of Board actions Feb 2 and Mar 18,
	2009
In-Reply-To: <F6697CCB-A06D-4CC9-9D12-D85128C6291E@isoc.org>
References: <376189.27706.qm@web63303.mail.re1.yahoo.com><107DD4CEABC54F669D321A6EB64005F3@tedsdesk><EACF8B735E9CBA4B8BAF9E4165D03087531F88@ex1.cait.wustl.edu><75822E125BCB994F8446858C4B19F0D76BE5560A@SUEX07-MBX-04.ad.syr.edu><70DE64CEFD6E9A4EB7FAF3A06314106601B4AF50@mail>
	<F6697CCB-A06D-4CC9-9D12-D85128C6291E@isoc.org>
Message-ID: <F206D0F4280D420B855C6487EA558E2B@tedsdesk>

 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Schnizlein
> Sent: Tuesday, March 31, 2009 1:00 PM
> To: Kevin Kargel
> Cc: ppml at arin.net
> Subject: Re: [arin-ppml] clarification of Board actions Feb 2 
> and Mar 18,2009
> 
> Thank you for the clear and strong statement, about which I 
> have some questions.
> 
> On 2009Mar31, at 12:03 PM, Kevin Kargel wrote:
> 
> > A transfer system will inexorably raise the cost of doing 
> business on 
> > the internet.
> 
> I can see that the cost of deploying more IPv4 would likely 
> rise with scarcity.  How would this affect anyone else?
> 

Post IPv4 runout, the only new assignable IPv4 will be "dirty"
meaning already broken up into smaller blocks.  An org needing
a /18 could satisfy this with, for example, 2 non-contiguous
/19's, or a /19 and 2 /20's, and so on.  All discontiguous.
Further, the existence of multiple "brokers" greatly reduces
the possibility of a single entity (ie: ARIN) from gathering
together multiple small blocks and coalescing adjacent ones into
larger blocks, or "trading" a larger contiguous block for
smaller non-adjacent ones.

As a result you have far more rapid growth of BGP advertisements
on the Internet, meaning everyone needs to buy more ram for their
routers a lot sooner and retire working gear a lot sooner.

Also, the mere existence of a transfer market means ISP's
are much more likely to consider the runout date to be highly
elastic, rather than a freight train speeding down on them - this
removes incentive to move to IPv6 and creates an incentive to
spend more and more money pushing off the date they have to
start converting over.  Keep in mind the longer the transition
takes, the longer we all have to dual-stack and the more complex
that problem troubleshooting becomes, and more labor spent on
it.

This also chips away at the authority of the RIR as it creates
the false impression by the "purchasers" that IP addresses are
"property" and thus once they buy them, they can do what they
want with them and do not have to justify need - once more, this
increases the incentive to get portable numbers and decreases
the incentive to get numbers from your upstream, increasing
BGP routing advertisements.

What are you going to tell the guy who spent $500 on a /24 and
has an ISP willing to advertise it for him, that ARIN is going
to rule he's in violation of the NRPM and they are going to take
that /24 and give it to someone else as part of a larger aggregate?
He will file a lawsuit and your going to clog the court system
with these "buzzing flies" lawsuits.

Ted



From matthew at matthew.at  Tue Mar 31 17:00:41 2009
From: matthew at matthew.at (Matthew Kaufman)
Date: Tue, 31 Mar 2009 14:00:41 -0700
Subject: [arin-ppml] clarification of Board actions Feb 2 and Mar 18,
 2009
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AF50@mail>
References: <376189.27706.qm@web63303.mail.re1.yahoo.com><107DD4CEABC54F669D321A6EB64005F3@tedsdesk><EACF8B735E9CBA4B8BAF9E4165D03087531F88@ex1.cait.wustl.edu>	<75822E125BCB994F8446858C4B19F0D76BE5560A@SUEX07-MBX-04.ad.syr.edu>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4AF50@mail>
Message-ID: <49D28479.9080207@matthew.at>

Kevin Kargel wrote:
>
> A transfer system will inexorably raise the cost of doing business on the
> internet.  However you paint it this is a bad thing for the community and
> for society.  
Running out of IPv4 address will inexorably raise the cost of doing 
business on the IPv4 Internet for growing or new entrants *whether or 
not* there is a transfer system. Any new or growing entity that for 
whatever reason *needs* an IPv4 address that isn't available is a bad 
thing for that entity and possibly for the community.

And that's true even without pointing out that there already is a -- 
albeit more complicated to use -- transfer system in place today. If, 
for instance, that mechanism (buying existing entities or spinoffs of 
existing entities and recycling their addresses) was also made 
unavailable, the business cost to entities which need IPv4 space in 
order to keep growing or in order to enter the market will rise 
significantly (they would be required to use PA space from ISPs which 
might charge much more for it, or simply be unable to efficiently deploy 
the service they need to deploy, etc.) Even switching to IPv6 is a 
business cost to existing entities which cannot be avoided when IPv4 
addresses run out.

In short there's just no getting around a rise in the cost of doing 
business on the Internet, and whatever side effects that creates. So 
using an increase in cost to justify being against a transfer policy is 
akin to being opposed to a transfer policy because "if a transfer policy 
exists, the sun will rise tomorrow."

> I will continue to oppose P2P transfer policies whenever they
> are presented.
>   
This much is clear.

Matthew Kaufman


From kkargel at polartel.com  Tue Mar 31 17:07:34 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 31 Mar 2009 16:07:34 -0500
Subject: [arin-ppml] clarification of Board actions Feb 2 and Mar 18,
	2009
In-Reply-To: <49D28479.9080207@matthew.at>
References: <376189.27706.qm@web63303.mail.re1.yahoo.com><107DD4CEABC54F669D321A6EB64005F3@tedsdesk><EACF8B735E9CBA4B8BAF9E4165D03087531F88@ex1.cait.wustl.edu>	<75822E125BCB994F8446858C4B19F0D76BE5560A@SUEX07-MBX-04.ad.syr.edu>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4AF50@mail>
	<49D28479.9080207@matthew.at>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AF67@mail>



> -----Original Message-----
> From: Matthew Kaufman [mailto:matthew at matthew.at]
> Sent: Tuesday, March 31, 2009 4:01 PM
> To: Kevin Kargel
> Cc: Milton L Mueller; ppml at arin.net
> Subject: Re: [arin-ppml] clarification of Board actions Feb 2 and Mar 18,
> 2009
> 
> Kevin Kargel wrote:
> >
> 
> In short there's just no getting around a rise in the cost of doing
> business on the Internet, and whatever side effects that creates. So
> using an increase in cost to justify being against a transfer policy is
> akin to being opposed to a transfer policy because "if a transfer policy
> exists, the sun will rise tomorrow."

I agree there is no getting around a rise in cost.  The distinction is in
the order of magnitude of the rise in cost.  

If ARIN is managing the redistribution at least we have a benevolent entity
managing the process.

In the free market the only limit to cost is what the market will bear.  He
with the deepest pockets will dictate the cost.

It will hurt if the dentist cleans your teeth, it will hurt if the dentist
does a root canal, so by your logic you might as well get the root canal.
The difference is the order of magnitutde.


> 
> > I will continue to oppose P2P transfer policies whenever they
> > are presented.
> >
> This much is clear.
> 
> Matthew Kaufman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090331/d235cb9c/attachment.bin>

From matthew at matthew.at  Tue Mar 31 17:10:41 2009
From: matthew at matthew.at (Matthew Kaufman)
Date: Tue, 31 Mar 2009 14:10:41 -0700
Subject: [arin-ppml] clarification of Board actions Feb 2 and Mar 18,
 2009
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AF67@mail>
References: <376189.27706.qm@web63303.mail.re1.yahoo.com><107DD4CEABC54F669D321A6EB64005F3@tedsdesk><EACF8B735E9CBA4B8BAF9E4165D03087531F88@ex1.cait.wustl.edu>	<75822E125BCB994F8446858C4B19F0D76BE5560A@SUEX07-MBX-04.ad.syr.edu>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4AF50@mail>
	<49D28479.9080207@matthew.at>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4AF67@mail>
Message-ID: <49D286D1.6080705@matthew.at>

Kevin Kargel wrote:
>
> If ARIN is managing the redistribution at least we have a benevolent entity
> managing the process.
>
>   
If that benevolent entity doesn't pay market rates to people who might 
have IP addresses that, at some cost to them, they could return AND 
doesn't forcibly reclaim all space and redistribute it on a needs basis, 
then it won't have very many addresses to give back out.
> In the free market the only limit to cost is what the market will bear.  He
> with the deepest pockets will dictate the cost.
>   
Because there's already another transfer mechanism, that will already be 
true.
> It will hurt if the dentist cleans your teeth, it will hurt if the dentist
> does a root canal, so by your logic you might as well get the root canal.
> The difference is the order of magnitutde.
>   
If my teeth hurt and there's an appointment for a root canal available 
tomorrow and no appointments for cleanings for the next 7 years, I might 
very well just go get the root canal and move on to other more pressing 
issues.

Matthew Kaufman



From cgrundemann at gmail.com  Tue Mar 31 17:17:16 2009
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Tue, 31 Mar 2009 15:17:16 -0600
Subject: [arin-ppml] Draft Policy 2009-1: Is there an Emergency?
In-Reply-To: <49D01AE3.21085.B9720F6@farmer.umn.edu>
References: <49D01AE3.21085.B9720F6@farmer.umn.edu>
Message-ID: <443de7ad0903311417ifd8622cv55bf1272d90ae9e8@mail.gmail.com>

On Mon, Mar 30, 2009 at 00:05, David Farmer <farmer at umn.edu> wrote:
> I would like to motivate a discussion of the question "Is there
> an Emergency?"
>
> I have heard several people express the opinion that they don't
> see an emergency. ?I would like to respectfully disagree with
> that opinion.
>
> In my opinion the crux of the emergency is IPv4 exhaustion
> combined with the lack of IPv6 adoption, which means we are
> going to hit the proverbial wall when it comes to functional IP
> address availability. ?But when does this become an
> emergency?
>
> Maybe we can use a car accident as a metaphor; ?When does
> a car accident start? ?When you hit the wall? ?When the
> airbags deploy? ?When you fail to make the turn or hit the
> breaks in time to prevent yourself from hitting the wall?
>
> Using this metaphor, I propose; ?IANA free pool exhaustion is
> equivalent to the car hitting the wall. ?The trigger set in 2009-2:
> Depleted IPv4 Reserves, is the equivalent of the airbags going
> off shortly after the car hits the wall. ?RIR and ISP free pool
> exhaustion are equivalent to the passengers hitting the interior
> of the car and the brain and internal organs colliding with the
> skull and the rest of the body, receptively.
>
> So when did the IPv4 car accident start, when did we hit the
> point where we would inextricably hit the wall? ?I'm not exactly
> sure, but I think most of us started realizing back in 2007 that
> we were going to inextricably hit the wall. ?And today, to me
> personally it is virtually unquestionable that will we are going to
> hit the wall. ?We obviously haven't hit the wall just yet, but the
> car is headed toward the wall to fast to stop or turn, the
> accident must and will happen.

I am not convinced that the car hitting the wall analogy is of much
use when discussing IPv4 free-pool exhaustion, mainly because I can't
seem to envision many organizations (if any) exploding at IANA, RIR,
or ISP free IPv4 runout.  Perhaps a car running out of gas is a more
applicable comparison?  I know it lacks the drama of a giant fireball
but it seems more accurate.  Organizations unable to obtain more
address space will not cease to exist, they will simply cease to grow
(unless they adopt an alternative source of IP / fuel).  Also, I have
a very hard time determining the location of a single collective car
along this path - as someone (please forgive me for not looking up
who) astutely pointed out in a previous ppml thread; IPv4 free pool
exhaustion has effectively already happened for many orgs who will not
be able to justify an allocation in the near future (2- years) but may
need more addresses in the longer term.

So there are a bunch of vehicles all moving along fueled (almost
exclusively) by IPv4 and if nothing is done, they will stop moving.
So the emergency is not a collision but a stall and when that happens
is largely dependent on each individual vehicle's actions.  Mega ISP
is akin to a bus carrying many customers along with them and thus
burning fuel quite quickly; but they have a lot of it.  Mom's Shop is
more like a hybrid; carrying little fuel but only sipping it along the
way.  And ARIN is pit lane, the gas station -- with one obvious
difference; IP is not truly consumed so those no longer needing it to
fuel their car can return it to the station (or transfer it to
others).

>From this perspective the emergency begins for each vehicle when they
reach a point where they _will_ stall.  I think the better question
though (and the one you are asking) is when does it become an
emergency for the community as a whole?  When is it an emergency for
the ARIN region?  Unfortunately, to this I do not have a definitive
answer.  Is it when we know that any one member will stall?  Or when
10% reach that point?  25%, 50%?  What portion of our community is at
this point already?

The thing I wonder about most though, is when the BoT declared this an
emergency, were they speaking about the ARIN community or ARIN itself
(or maybe both)?

~Chris

>
> Further, it is possible we don't have as much time as we think
> we do. ?We currently have approximately 500 Million IPv4
> address in the IANA Free Pool. ?While current projections,
> based on current usage rates, provide a little over two years to
> exhaustion[1]. ?However, it is not difficult to imagine scenarios
> where the IANA free pool could be exhausted much sooner
> than that. ?For example, if mobile providers were to start
> issuing IPv4 address to mobile hand sets it wouldn't be hard to
> exhaust the IANA free pool in no time flat[2].
>
> [1] http://www.potaroo.net/tools/ipv4/index.html
>
> [2]
> http://newsroom.parksassociates.com/article_display.cfm?articl
> e_id=5128
>
> I'm not saying that will or even should happen, but it is by no
> means impossible. ?Further, under current policies if the mobile
> industry came to the RIRs for IPv4 addresses for hand set, the
> RIRs would likely have to fulfill the requests, and exhaust the
> IANA free pool in short order.
>
> Therefore, at least in reference to IPv4, I believe there is a
> valid Emergency.
>
> So, I'm interested to hear other people's opinion on if there is
> an emergency.
>
> ================================================
> =======
> David Farmer ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Email:
> farmer at umn.edu
> Office of Information Technology
> Networking & Telecomunication Services
> University of Minnesota ? ? ? ? ? ? ? ? ? ? ?Phone: ? ? 612-626-
> 0815
> 2218 University Ave SE ? ? ? ? ? ? ? ? ? ? ? Cell:
> 612-812-9952
> Minneapolis, MN 55414-3029 ? ? ? ? ? ? ? ? ? FAX: ? ? ? 612-626-
> 1818
> ================================================
> =======
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
-- 
Chris Grundemann
weblog.chrisgrundemann.com


From kkargel at polartel.com  Tue Mar 31 17:18:41 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 31 Mar 2009 16:18:41 -0500
Subject: [arin-ppml] clarification of Board actions Feb 2 and Mar 18,
	2009
In-Reply-To: <49D286D1.6080705@matthew.at>
References: <376189.27706.qm@web63303.mail.re1.yahoo.com><107DD4CEABC54F669D321A6EB64005F3@tedsdesk><EACF8B735E9CBA4B8BAF9E4165D03087531F88@ex1.cait.wustl.edu>	<75822E125BCB994F8446858C4B19F0D76BE5560A@SUEX07-MBX-04.ad.syr.edu>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4AF50@mail>
	<49D28479.9080207@matthew.at>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4AF67@mail>
	<49D286D1.6080705@matthew.at>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AF68@mail>


> From: Matthew Kaufman [mailto:matthew at matthew.at]
> Sent: Tuesday, March 31, 2009 4:11 PM
> To: Kevin Kargel
> Cc: Milton L Mueller; ppml at arin.net
> Subject: Re: [arin-ppml] clarification of Board actions Feb 2 and Mar 18,
> 2009
> 
> Kevin Kargel wrote:
> >
> > If ARIN is managing the redistribution at least we have a benevolent
> entity
> > managing the process.
> >
> >
> If that benevolent entity doesn't pay market rates to people who might
> have IP addresses that, at some cost to them, they could return AND
> doesn't forcibly reclaim all space and redistribute it on a needs basis,
> then it won't have very many addresses to give back out.

Why do people try to act like a transfer policy will solve the problem of
IPv4 runout?  It won't..  IPv4 will exhaust, it is a finite resource, the
need is greater than the availability.  

A transfer policy will at most be a short term bandaid to extend the useful
life of IPv4 by some period of months..  it cannot extend the runout
indefinitely.

The cost and pain of applying this bandaid far outweigh any benefit it might
offer.  This says nothing about the cost and pain of ripping it off when you
are done with it.  

> > In the free market the only limit to cost is what the market will bear.
> He
> > with the deepest pockets will dictate the cost.
> >
> Because there's already another transfer mechanism, that will already be
> true.
> > It will hurt if the dentist cleans your teeth, it will hurt if the
> dentist
> > does a root canal, so by your logic you might as well get the root
> canal.
> > The difference is the order of magnitutde.
> >
> If my teeth hurt and there's an appointment for a root canal available
> tomorrow and no appointments for cleanings for the next 7 years, I might
> very well just go get the root canal and move on to other more pressing
> issues.

I wish I were your dentist, I would only have appointments available for the
most expensive procedures.  Instead of giving you x-rays we could give you
exploratory excavations and cover them with fillings and caps!  WooHoo!  

Of course your middle class neighbor then wouldn't be able to afford
dentistry at all..

> 
> Matthew Kaufman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090331/5d85c992/attachment.bin>

From matthew at matthew.at  Tue Mar 31 17:21:47 2009
From: matthew at matthew.at (Matthew Kaufman)
Date: Tue, 31 Mar 2009 14:21:47 -0700
Subject: [arin-ppml] clarification of Board actions Feb 2 and Mar 18,
 2009
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AF68@mail>
References: <376189.27706.qm@web63303.mail.re1.yahoo.com><107DD4CEABC54F669D321A6EB64005F3@tedsdesk><EACF8B735E9CBA4B8BAF9E4165D03087531F88@ex1.cait.wustl.edu>	<75822E125BCB994F8446858C4B19F0D76BE5560A@SUEX07-MBX-04.ad.syr.edu>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4AF50@mail>
	<49D28479.9080207@matthew.at>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4AF67@mail>
	<49D286D1.6080705@matthew.at>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4AF68@mail>
Message-ID: <49D2896B.20703@matthew.at>

Kevin Kargel wrote:
> A transfer policy will at most be a short term bandaid to extend the useful
> life of IPv4 by some period of months..  it cannot extend the runout
> indefinitely.
>   
If you're right then this "huge additional cost" only lasts a few months 
as well... so who cares?

Matthew Kaufman


From tedm at ipinc.net  Tue Mar 31 17:24:16 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 31 Mar 2009 14:24:16 -0700
Subject: [arin-ppml] Draft Policy 2009-1: Is there an Emergency?
In-Reply-To: <443de7ad0903311417ifd8622cv55bf1272d90ae9e8@mail.gmail.com>
References: <49D01AE3.21085.B9720F6@farmer.umn.edu>
	<443de7ad0903311417ifd8622cv55bf1272d90ae9e8@mail.gmail.com>
Message-ID: <3154F9E0A3EF469BA057F7BCEF52A536@tedsdesk>

 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Chris Grundemann
> Sent: Tuesday, March 31, 2009 2:17 PM
> To: David Farmer
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy 2009-1: Is there an Emergency?
> 
> >From this perspective the emergency begins for each vehicle when they
> reach a point where they _will_ stall.  I think the better 
> question though (and the one you are asking) is when does it 
> become an emergency for the community as a whole?  When is it 
> an emergency for the ARIN region?  Unfortunately, to this I 
> do not have a definitive answer.  Is it when we know that any 
> one member will stall?  Or when 10% reach that point?  25%, 
> 50%?  What portion of our community is at this point already?
> 

I disagree with this car analogy stuff.  The UPv4 runout is
much more a road analogy

It is like everyone owns cars that are 4 feet wide, all roads
are 4 feet wide - but we just ran out of land, so now, all
new roads can only be 3 feet wide and nobody's existing car
will fit on them.  But, new cars will fit on both old and
new roads.  So from now on all new road construction will be
3 foot wide roads and everyone who owns an existing 4 foot wide road
can run either 3 or 4 foot wide cars on it - but drivers will
need to get the new 3 foot wide cars to be able to run over
the entire road system.

Lots of drivers will simply avoid going to the places served by
the 3 foot wide roads, until that is we get smart and start putting
all the clothing-optional beaches at the end of 3 foot wide roads. ;-)

Ted



From sethm at rollernet.us  Tue Mar 31 18:44:16 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Tue, 31 Mar 2009 15:44:16 -0700
Subject: [arin-ppml] clarification of Board actions Feb 2 and Mar 18,
 2009
In-Reply-To: <1FAC298BB17E4964946B3D6FACF2A131@tedsdesk>
References: <376189.27706.qm@web63303.mail.re1.yahoo.com>	<107DD4CEABC54F669D321A6EB64005F3@tedsdesk>	<f65fb55e0903302151h4a681b29j354b7445d7576e2@mail.gmail.com>
	<1FAC298BB17E4964946B3D6FACF2A131@tedsdesk>
Message-ID: <49D29CC0.6090202@rollernet.us>

Ted Mittelstaedt wrote:

> 
> Only if the ARIN staff forget to wear their tinfoil hats.
> 
> Seriously though, just consider one little thing for a moment,
> the US banking system.  You know, the same banking system that
> mugged the US Government late last year for 700 billion dollars.
> 
> Think of just how much money those bank CEOs have saved with firing
> tellers and replacing them with online banking access over the
> Internet.
> 
> Now, imagine ARIN telling Chase Bank "sorry, you can't setup that
> new online banking center because we think the world has run out
> out of IPv4 addresses but we aren't sure because we lost track of
> a couple million of them" and try to guess how long ARIN would exist
> as an entity after that.
> 
> Party's over, folks.  Time to get down and get serious about this
> or be content allowing it go to the bureaucrats.
> 


A more plausible scenario (I think) if it comes down to lawsuits is
people like me and my /22 being reclaimed upon because I'm unable to
afford more lawyers than Chase or other large orgs that want more space.
Only after the small orgs are gone and forced back to PA space will it
become government controlled. Or the big orgs will fight it out until
the whole thing is tied up in 20 levels of lawsuits.

Just a theory, but one that small players like myself think about.

~Seth


From kkargel at polartel.com  Tue Mar 31 18:58:53 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 31 Mar 2009 17:58:53 -0500
Subject: [arin-ppml] clarification of Board actions Feb 2 and Mar 18,
	2009
In-Reply-To: <49D29CC0.6090202@rollernet.us>
References: <376189.27706.qm@web63303.mail.re1.yahoo.com>	<107DD4CEABC54F669D321A6EB64005F3@tedsdesk>	<f65fb55e0903302151h4a681b29j354b7445d7576e2@mail.gmail.com><1FAC298BB17E4964946B3D6FACF2A131@tedsdesk>
	<49D29CC0.6090202@rollernet.us>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AF73@mail>


> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Seth Mattinen
> Sent: Tuesday, March 31, 2009 5:44 PM
> To: ppml at arin.net
> Subject: Re: [arin-ppml] clarification of Board actions Feb 2 and Mar 18,
> 2009
> 
> Ted Mittelstaedt wrote:
> 
> >
> > Only if the ARIN staff forget to wear their tinfoil hats.
> >
> > Seriously though, just consider one little thing for a moment,
> > the US banking system.  You know, the same banking system that
> > mugged the US Government late last year for 700 billion dollars.
> >
> > Think of just how much money those bank CEOs have saved with firing
> > tellers and replacing them with online banking access over the
> > Internet.
> >
> > Now, imagine ARIN telling Chase Bank "sorry, you can't setup that
> > new online banking center because we think the world has run out
> > out of IPv4 addresses but we aren't sure because we lost track of
> > a couple million of them" and try to guess how long ARIN would exist
> > as an entity after that.
> >
> > Party's over, folks.  Time to get down and get serious about this
> > or be content allowing it go to the bureaucrats.
> >
> 
> 
> A more plausible scenario (I think) if it comes down to lawsuits is
> people like me and my /22 being reclaimed upon because I'm unable to
> afford more lawyers than Chase or other large orgs that want more space.
> Only after the small orgs are gone and forced back to PA space will it
> become government controlled. Or the big orgs will fight it out until
> the whole thing is tied up in 20 levels of lawsuits.
> 
> Just a theory, but one that small players like myself think about.
> 
> ~Seth

If it gets that ugly there will be a general revolt.  The old timers among
us will remember the ugliness that can happen when turf wars spring up in IP
space.  Things have to happen cooperatively or the whole thing comes
tumbling down.  

This is one of the wonderful things about the way the internet is
architected.  While it is a "cooperative anarchy" the "cooperative" part is
just as important as the "anarchy" part.  It's very vulnerability is one of
the things that keeps people working together.

Anyone who has tried to fend off a DDoS attack without the benefit of a huge
pipe or a VERY cooperative upstream knows what I am talking about.  Throw in
a bunch of IP spoofing and multiple upstreams and it compounds quickly.

Granted there are defenses on modern networks, but they are neither
infallible nor always appropriate.  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090331/cee516f6/attachment.bin>

From martin.hannigan at batelnet.bs  Tue Mar 31 19:07:32 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Tue, 31 Mar 2009 19:07:32 -0400
Subject: [arin-ppml] Draft Policy 2009-3 (Global): Allocation of IPv4
	Blocks to Regional Internet Registries
In-Reply-To: <49D140F3.7010606@gmail.com>
References: <37137.208.54.95.48.1238379940.squirrel@webmail.lacnic.net.uy>
	<49D10949.9000803@arin.net> <49D11F48.6090905@gmail.com>
	<9EDA9B03-C069-44B5-B06D-D60E510849FE@lacnic.net>
	<4607e1d50903301318y3c142303g42a991f6be79b0a6@mail.gmail.com>
	<49D12E37.9040307@gmail.com>
	<4607e1d50903301351o52e48c66n21163809fcf0f630@mail.gmail.com>
	<49D138C7.7040207@gmail.com> <49D140F3.7010606@gmail.com>
Message-ID: <4607e1d50903311607v1b9fe158j5e7089e22355428f@mail.gmail.com>

On Mon, Mar 30, 2009 at 6:00 PM, Scott Leibrand <scottleibrand at gmail.com>wrote:

> Scott Leibrand wrote:
>
>>
>>
[ clip ]



> 2009-3 is one such option, but I believe that the original proposed text
>> would be problematic, because the mandatory return of reclaimed space
>> removes most of the incentive for RIRs to reclaim space.  As a possible
>> alternative, I think that making the return of reclaimed space optional
>> would eliminate that concern, but it might also make the
>
>
Changing the intent of a submitted policy doesn't seem like a sustainable
course of action for any policy. We aren't making a good idea better, we're
taking a challenging idea and making it into a different idea. Interesting.
This is potentially a flaw in the new PDP.

Under the new policy process, if the author withdraws the policy, do your
revisions die with it?

Best,

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090331/76e898b0/attachment.htm>

From sam at sports-spectrum.com  Tue Mar 31 18:54:59 2009
From: sam at sports-spectrum.com (Sam Polito)
Date: Tue, 31 Mar 2009 17:54:59 -0500
Subject: [arin-ppml] Draft Policy 2009-1: Is there an Emergency?
Message-ID: <7D77D19B5E364280834E6EFFC99C57AA@scoreboard.local>

I'm totally lost but maybe someone can help I'm sports spectrum and thinking
about changing my Internet provider.When I change providers can my IP
addresses follow me?

Thanks


MCI Communications Services, Inc. d/b/a Verizon Business UUNET65-2
(NET-65-240-0-0-1)
                                  65.240.0.0 - 65.253.255.255
SPORTS SPECTRUM INC, THE UU-65-248-200 (NET-65-248-200-0-1)
                                  65.248.200.0 - 65.248.200.255

----- Original Message ----- 
From: "Sam Polito" <sam-SPAM at sports-spectrum.com>
To: "Chris Grundemann" <cgrundemann at gmail.com>; "David Farmer" 
<farmer at umn.edu>
Cc: <arin-ppml at arin.net>
Sent: Tuesday, March 31, 2009 5:54 PM
Subject: Re: [arin-ppml] Draft Policy 2009-1: Is there an Emergency?


> I'm totally lost but maybe someone can help I'm sports spectrum and 
> thinking about changing my Internet provider.When I change providers can 
> my IP addresses follow me?
>
> Thanks
>
>
> MCI Communications Services, Inc. d/b/a Verizon Business UUNET65-2 
> (NET-65-240-0-0-1)
>                                  65.240.0.0 - 65.253.255.255
> SPORTS SPECTRUM INC, THE UU-65-248-200 (NET-65-248-200-0-1)
>                                  65.248.200.0 - 65.248.200.255
>
> ----- Original Message ----- 
> From: "Chris Grundemann" <cgrundemann at gmail.com>
> To: "David Farmer" <farmer at umn.edu>
> Cc: <arin-ppml at arin.net>
> Sent: Tuesday, March 31, 2009 4:17 PM
> Subject: Re: [arin-ppml] Draft Policy 2009-1: Is there an Emergency?
>
>
> On Mon, Mar 30, 2009 at 00:05, David Farmer <farmer at umn.edu> wrote:
>> I would like to motivate a discussion of the question "Is there
>> an Emergency?"
>>
>> I have heard several people express the opinion that they don't
>> see an emergency. I would like to respectfully disagree with
>> that opinion.
>>
>> In my opinion the crux of the emergency is IPv4 exhaustion
>> combined with the lack of IPv6 adoption, which means we are
>> going to hit the proverbial wall when it comes to functional IP
>> address availability. But when does this become an
>> emergency?
>>
>> Maybe we can use a car accident as a metaphor; When does
>> a car accident start? When you hit the wall? When the
>> airbags deploy? When you fail to make the turn or hit the
>> breaks in time to prevent yourself from hitting the wall?
>>
>> Using this metaphor, I propose; IANA free pool exhaustion is
>> equivalent to the car hitting the wall. The trigger set in 2009-2:
>> Depleted IPv4 Reserves, is the equivalent of the airbags going
>> off shortly after the car hits the wall. RIR and ISP free pool
>> exhaustion are equivalent to the passengers hitting the interior
>> of the car and the brain and internal organs colliding with the
>> skull and the rest of the body, receptively.
>>
>> So when did the IPv4 car accident start, when did we hit the
>> point where we would inextricably hit the wall? I'm not exactly
>> sure, but I think most of us started realizing back in 2007 that
>> we were going to inextricably hit the wall. And today, to me
>> personally it is virtually unquestionable that will we are going to
>> hit the wall. We obviously haven't hit the wall just yet, but the
>> car is headed toward the wall to fast to stop or turn, the
>> accident must and will happen.
>
> I am not convinced that the car hitting the wall analogy is of much
> use when discussing IPv4 free-pool exhaustion, mainly because I can't
> seem to envision many organizations (if any) exploding at IANA, RIR,
> or ISP free IPv4 runout.  Perhaps a car running out of gas is a more
> applicable comparison?  I know it lacks the drama of a giant fireball
> but it seems more accurate.  Organizations unable to obtain more
> address space will not cease to exist, they will simply cease to grow
> (unless they adopt an alternative source of IP / fuel).  Also, I have
> a very hard time determining the location of a single collective car
> along this path - as someone (please forgive me for not looking up
> who) astutely pointed out in a previous ppml thread; IPv4 free pool
> exhaustion has effectively already happened for many orgs who will not
> be able to justify an allocation in the near future (2- years) but may
> need more addresses in the longer term.
>
> So there are a bunch of vehicles all moving along fueled (almost
> exclusively) by IPv4 and if nothing is done, they will stop moving.
> So the emergency is not a collision but a stall and when that happens
> is largely dependent on each individual vehicle's actions.  Mega ISP
> is akin to a bus carrying many customers along with them and thus
> burning fuel quite quickly; but they have a lot of it.  Mom's Shop is
> more like a hybrid; carrying little fuel but only sipping it along the
> way.  And ARIN is pit lane, the gas station -- with one obvious
> difference; IP is not truly consumed so those no longer needing it to
> fuel their car can return it to the station (or transfer it to
> others).
>
>>From this perspective the emergency begins for each vehicle when they
> reach a point where they _will_ stall.  I think the better question
> though (and the one you are asking) is when does it become an
> emergency for the community as a whole?  When is it an emergency for
> the ARIN region?  Unfortunately, to this I do not have a definitive
> answer.  Is it when we know that any one member will stall?  Or when
> 10% reach that point?  25%, 50%?  What portion of our community is at
> this point already?
>
> The thing I wonder about most though, is when the BoT declared this an
> emergency, were they speaking about the ARIN community or ARIN itself
> (or maybe both)?
>
> ~Chris
>
>>
>> Further, it is possible we don't have as much time as we think
>> we do. We currently have approximately 500 Million IPv4
>> address in the IANA Free Pool. While current projections,
>> based on current usage rates, provide a little over two years to
>> exhaustion[1]. However, it is not difficult to imagine scenarios
>> where the IANA free pool could be exhausted much sooner
>> than that. For example, if mobile providers were to start
>> issuing IPv4 address to mobile hand sets it wouldn't be hard to
>> exhaust the IANA free pool in no time flat[2].
>>
>> [1] http://www.potaroo.net/tools/ipv4/index.html
>>
>> [2]
>> http://newsroom.parksassociates.com/article_display.cfm?articl
>> e_id=5128
>>
>> I'm not saying that will or even should happen, but it is by no
>> means impossible. Further, under current policies if the mobile
>> industry came to the RIRs for IPv4 addresses for hand set, the
>> RIRs would likely have to fulfill the requests, and exhaust the
>> IANA free pool in short order.
>>
>> Therefore, at least in reference to IPv4, I believe there is a
>> valid Emergency.
>>
>> So, I'm interested to hear other people's opinion on if there is
>> an emergency.
>>
>> ================================================
>> =======
>> David Farmer Email:
>> farmer at umn.edu
>> Office of Information Technology
>> Networking & Telecomunication Services
>> University of Minnesota Phone: 612-626-
>> 0815
>> 2218 University Ave SE Cell:
>> 612-812-9952
>> Minneapolis, MN 55414-3029 FAX: 612-626-
>> 1818
>> ================================================
>> =======
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
> -- 
> Chris Grundemann
> weblog.chrisgrundemann.com
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
> 



From farmer at umn.edu  Tue Mar 31 19:09:01 2009
From: farmer at umn.edu (David Farmer)
Date: Tue, 31 Mar 2009 18:09:01 -0500
Subject: [arin-ppml] Can I keep my address space? was: Re:Draft Policy
	2009-1: Is there an Emergency?
In-Reply-To: <80C5A90644934AF797D01D8E15841534@scoreboard.local>
References: <49D01AE3.21085.B9720F6@farmer.umn.edu>,
	<80C5A90644934AF797D01D8E15841534@scoreboard.local>
Message-ID: <49D25C3D.16673.5169D7B@farmer.umn.edu>

Short answer is NO!

Longer answer is only if Verizon is willing to let you, which is 
almost certenly NO, but you would have to ask them.  If you 
are a really big customer of other services you might be able 
to, but still probablly NO! 

Verizon is who ARIN has allocated the 65.248.0.0/14 block to, 
you have a sub-assignement from MCI, and have no direct 
relationship with ARIN.

On 31 Mar 2009 Sam Polito wrote:

> I'm totally lost but maybe someone can help I'm sports spectrum and thinking 
> about changing my Internet provider.When I change providers can my IP 
> addresses follow me?
> 
> Thanks
> 
> 
> MCI Communications Services, Inc. d/b/a Verizon Business UUNET65-2 
> (NET-65-240-0-0-1)
>                                   65.240.0.0 - 65.253.255.255
> SPORTS SPECTRUM INC, THE UU-65-248-200 (NET-65-248-200-0-1)
>                                   65.248.200.0 - 65.248.200.255


================================================
=======
David Farmer				     Email:	
farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota			     Phone:	612-626-
0815
2218 University Ave SE			     Cell:		
612-812-9952
Minneapolis, MN 55414-3029		     FAX:	612-626-
1818
================================================
=======



From mueller at syr.edu  Tue Mar 31 14:38:40 2009
From: mueller at syr.edu (Milton L Mueller)
Date: Tue, 31 Mar 2009 14:38:40 -0400
Subject: [arin-ppml] clarification of Board actions Feb 2 and Mar 18,
 2009
In-Reply-To: <0B1F5A0C-C917-4F23-8C19-61EC83C280EF@pch.net>
References: <376189.27706.qm@web63303.mail.re1.yahoo.com>
	<107DD4CEABC54F669D321A6EB64005F3@tedsdesk>
	<EACF8B735E9CBA4B8BAF9E4165D03087531F88@ex1.cait.wustl.edu>
	<75822E125BCB994F8446858C4B19F0D76BE5560A@SUEX07-MBX-04.ad.syr.edu>
	<0B1F5A0C-C917-4F23-8C19-61EC83C280EF@pch.net>
Message-ID: <75822E125BCB994F8446858C4B19F0D76BE5561C@SUEX07-MBX-04.ad.syr.edu>

Tom, 
I'm sorry you have become either so sloppy or so focused ad hominem (or both) that you've lost sight of simple fact-checking.  Your question on Aug 31 2008 not only led to a response from me but about twenty messages in response and a long discussion. Check the September 08 archives, please.

> -----Original Message-----
> 
> Milton, we are still waiting your views on what "cleaning and
> grooming" actually means -- the last time an inquiry into this
> question was made, you provided no response:
> 
> On Aug 31, 2008, at 4:24 PM, Tom Vest wrote:
> 
> > Hi Milton,
> >
> > A couple of quick questions:
> >
> > 1. Do you think that the completeness and accuracy of current DNS
> > whois is the right standard for IP number whois?
> >
> > 2. Does your vision for individual privacy rights extend to
> > "corporate persons," or only to natural persons?
> > -- It would appear that you reject the distinction in DNS whois:
> > http://forum.icann.org/lists/gnso-reg-sgc/msg00072.html
> >
> > Thanks,
> >
> > TV
> 
> 


From kkargel at polartel.com  Tue Mar 31 19:20:56 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 31 Mar 2009 18:20:56 -0500
Subject: [arin-ppml] Draft Policy 2009-1: Is there an Emergency?
In-Reply-To: <7D77D19B5E364280834E6EFFC99C57AA@scoreboard.local>
References: <7D77D19B5E364280834E6EFFC99C57AA@scoreboard.local>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AF75@mail>


This is exactly why people go through the trouble to get their own
allocation of portable IP addresses.  This might be difficult for you to do
as you are only consuming a Class C (/24) now, and (I am sure everyone will
correct me if I am wrong) the minimum allocation for a multi-homed end user
is a /22.  

If you are thinking of getting your own IP's to take with you I would
suggest you get started yesterday.  It will get tougher and/or more
expensive as we get closer to IP exhaustion.  A good starting point would be
to read
https://www.arin.net/Barbados/handouts/quickguide_resources_jan09.pdf

Some of the other folks here may have a suggestion of a more functional or
appropriate list to pose your question/request at.

Kevin



> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Sam Polito
> Sent: Tuesday, March 31, 2009 5:55 PM
> To: Sam Polito; Chris Grundemann; David Farmer
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy 2009-1: Is there an Emergency?
> 
> I'm totally lost but maybe someone can help I'm sports spectrum and
> thinking
> about changing my Internet provider.When I change providers can my IP
> addresses follow me?
> 
> Thanks
> 
> 
> MCI Communications Services, Inc. d/b/a Verizon Business UUNET65-2
> (NET-65-240-0-0-1)
>                                   65.240.0.0 - 65.253.255.255
> SPORTS SPECTRUM INC, THE UU-65-248-200 (NET-65-248-200-0-1)
>                                   65.248.200.0 - 65.248.200.255
> 
> ----- Original Message -----
> From: "Sam Polito" <sam-SPAM at sports-spectrum.com>
> To: "Chris Grundemann" <cgrundemann at gmail.com>; "David Farmer"
> <farmer at umn.edu>
> Cc: <arin-ppml at arin.net>
> Sent: Tuesday, March 31, 2009 5:54 PM
> Subject: Re: [arin-ppml] Draft Policy 2009-1: Is there an Emergency?
> 
> 
> > I'm totally lost but maybe someone can help I'm sports spectrum and
> > thinking about changing my Internet provider.When I change providers can
> > my IP addresses follow me?
> >
> > Thanks
> >
> >
> > MCI Communications Services, Inc. d/b/a Verizon Business UUNET65-2
> > (NET-65-240-0-0-1)
> >                                  65.240.0.0 - 65.253.255.255
> > SPORTS SPECTRUM INC, THE UU-65-248-200 (NET-65-248-200-0-1)
> >                                  65.248.200.0 - 65.248.200.255
> >
> > ----- Original Message -----
> > From: "Chris Grundemann" <cgrundemann at gmail.com>
> > To: "David Farmer" <farmer at umn.edu>
> > Cc: <arin-ppml at arin.net>
> > Sent: Tuesday, March 31, 2009 4:17 PM
> > Subject: Re: [arin-ppml] Draft Policy 2009-1: Is there an Emergency?
> >
> >
> > On Mon, Mar 30, 2009 at 00:05, David Farmer <farmer at umn.edu> wrote:
> >> I would like to motivate a discussion of the question "Is there
> >> an Emergency?"
> >>
> >> I have heard several people express the opinion that they don't
> >> see an emergency. I would like to respectfully disagree with
> >> that opinion.
> >>
> >> In my opinion the crux of the emergency is IPv4 exhaustion
> >> combined with the lack of IPv6 adoption, which means we are
> >> going to hit the proverbial wall when it comes to functional IP
> >> address availability. But when does this become an
> >> emergency?
> >>
> >> Maybe we can use a car accident as a metaphor; When does
> >> a car accident start? When you hit the wall? When the
> >> airbags deploy? When you fail to make the turn or hit the
> >> breaks in time to prevent yourself from hitting the wall?
> >>
> >> Using this metaphor, I propose; IANA free pool exhaustion is
> >> equivalent to the car hitting the wall. The trigger set in 2009-2:
> >> Depleted IPv4 Reserves, is the equivalent of the airbags going
> >> off shortly after the car hits the wall. RIR and ISP free pool
> >> exhaustion are equivalent to the passengers hitting the interior
> >> of the car and the brain and internal organs colliding with the
> >> skull and the rest of the body, receptively.
> >>
> >> So when did the IPv4 car accident start, when did we hit the
> >> point where we would inextricably hit the wall? I'm not exactly
> >> sure, but I think most of us started realizing back in 2007 that
> >> we were going to inextricably hit the wall. And today, to me
> >> personally it is virtually unquestionable that will we are going to
> >> hit the wall. We obviously haven't hit the wall just yet, but the
> >> car is headed toward the wall to fast to stop or turn, the
> >> accident must and will happen.
> >
> > I am not convinced that the car hitting the wall analogy is of much
> > use when discussing IPv4 free-pool exhaustion, mainly because I can't
> > seem to envision many organizations (if any) exploding at IANA, RIR,
> > or ISP free IPv4 runout.  Perhaps a car running out of gas is a more
> > applicable comparison?  I know it lacks the drama of a giant fireball
> > but it seems more accurate.  Organizations unable to obtain more
> > address space will not cease to exist, they will simply cease to grow
> > (unless they adopt an alternative source of IP / fuel).  Also, I have
> > a very hard time determining the location of a single collective car
> > along this path - as someone (please forgive me for not looking up
> > who) astutely pointed out in a previous ppml thread; IPv4 free pool
> > exhaustion has effectively already happened for many orgs who will not
> > be able to justify an allocation in the near future (2- years) but may
> > need more addresses in the longer term.
> >
> > So there are a bunch of vehicles all moving along fueled (almost
> > exclusively) by IPv4 and if nothing is done, they will stop moving.
> > So the emergency is not a collision but a stall and when that happens
> > is largely dependent on each individual vehicle's actions.  Mega ISP
> > is akin to a bus carrying many customers along with them and thus
> > burning fuel quite quickly; but they have a lot of it.  Mom's Shop is
> > more like a hybrid; carrying little fuel but only sipping it along the
> > way.  And ARIN is pit lane, the gas station -- with one obvious
> > difference; IP is not truly consumed so those no longer needing it to
> > fuel their car can return it to the station (or transfer it to
> > others).
> >
> >>From this perspective the emergency begins for each vehicle when they
> > reach a point where they _will_ stall.  I think the better question
> > though (and the one you are asking) is when does it become an
> > emergency for the community as a whole?  When is it an emergency for
> > the ARIN region?  Unfortunately, to this I do not have a definitive
> > answer.  Is it when we know that any one member will stall?  Or when
> > 10% reach that point?  25%, 50%?  What portion of our community is at
> > this point already?
> >
> > The thing I wonder about most though, is when the BoT declared this an
> > emergency, were they speaking about the ARIN community or ARIN itself
> > (or maybe both)?
> >
> > ~Chris
> >
> >>
> >> Further, it is possible we don't have as much time as we think
> >> we do. We currently have approximately 500 Million IPv4
> >> address in the IANA Free Pool. While current projections,
> >> based on current usage rates, provide a little over two years to
> >> exhaustion[1]. However, it is not difficult to imagine scenarios
> >> where the IANA free pool could be exhausted much sooner
> >> than that. For example, if mobile providers were to start
> >> issuing IPv4 address to mobile hand sets it wouldn't be hard to
> >> exhaust the IANA free pool in no time flat[2].
> >>
> >> [1] http://www.potaroo.net/tools/ipv4/index.html
> >>
> >> [2]
> >> http://newsroom.parksassociates.com/article_display.cfm?articl
> >> e_id=5128
> >>
> >> I'm not saying that will or even should happen, but it is by no
> >> means impossible. Further, under current policies if the mobile
> >> industry came to the RIRs for IPv4 addresses for hand set, the
> >> RIRs would likely have to fulfill the requests, and exhaust the
> >> IANA free pool in short order.
> >>
> >> Therefore, at least in reference to IPv4, I believe there is a
> >> valid Emergency.
> >>
> >> So, I'm interested to hear other people's opinion on if there is
> >> an emergency.
> >>
> >> ================================================
> >> =======
> >> David Farmer Email:
> >> farmer at umn.edu
> >> Office of Information Technology
> >> Networking & Telecomunication Services
> >> University of Minnesota Phone: 612-626-
> >> 0815
> >> 2218 University Ave SE Cell:
> >> 612-812-9952
> >> Minneapolis, MN 55414-3029 FAX: 612-626-
> >> 1818
> >> ================================================
> >> =======
> >>
> >> _______________________________________________
> >> PPML
> >> You are receiving this message because you are subscribed to
> >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> >> Unsubscribe or manage your mailing list subscription at:
> >> http://lists.arin.net/mailman/listinfo/arin-ppml
> >> Please contact info at arin.net if you experience any issues.
> >>
> > --
> > Chris Grundemann
> > weblog.chrisgrundemann.com
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> >
> >
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090331/d43c41ea/attachment.bin>

From farmer at umn.edu  Tue Mar 31 19:34:43 2009
From: farmer at umn.edu (David Farmer)
Date: Tue, 31 Mar 2009 18:34:43 -0500
Subject: [arin-ppml] Draft Policy 2009-3 (Global): Allocation of IPv4
	Blocks to Regional Internet Registries
In-Reply-To: <4607e1d50903311607v1b9fe158j5e7089e22355428f@mail.gmail.com>
References: <37137.208.54.95.48.1238379940.squirrel@webmail.lacnic.net.uy>,
	<49D140F3.7010606@gmail.com>,
	<4607e1d50903311607v1b9fe158j5e7089e22355428f@mail.gmail.com>
Message-ID: <49D26243.32677.52E23A3@farmer.umn.edu>

On 31 Mar 2009 Martin Hannigan wrote:

> On Mon, Mar 30, 2009 at 6:00 PM, Scott Leibrand <scottleibrand at gmail.com>wrote:
> 
> > Scott Leibrand wrote:
> >
> [ clip ]
> 
> > 2009-3 is one such option, but I believe that the original proposed text
> >> would be problematic, because the mandatory return of reclaimed space
> >> removes most of the incentive for RIRs to reclaim space.  As a possible
> >> alternative, I think that making the return of reclaimed space optional
> >> would eliminate that concern, but it might also make the
> >
> >
> Changing the intent of a submitted policy doesn't seem like a sustainable
> course of action for any policy. We aren't making a good idea better, we're
> taking a challenging idea and making it into a different idea. Interesting.
> This is potentially a flaw in the new PDP.
> 
> Under the new policy process, if the author withdraws the policy, do your
> revisions die with it?

My understaing is no, that would not kill this, the AC would have to officially 
abandon the Draft Policy or Policy Proposal.  According to the PDP, once the 
AC accepts the Policy Proposal to work on it really no longer belongs to the 
Author.  It then belongs to the AC, which is why we could change it.  

Now, in all likelyhood if the Authors abandon the Global Policy effort, the AC 
would likely abandon this Draft Policy.  But, I am only speculating as I am 
only one member of the AC, but I don't think I am to far out on a limb here.



=======================================================
David Farmer				     Email:	farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota			     Phone:	612-626-0815
2218 University Ave SE			     Cell:		612-812-9952
Minneapolis, MN 55414-3029		     FAX:	612-626-1818
=======================================================



From joelja at bogus.com  Tue Mar 31 19:28:17 2009
From: joelja at bogus.com (Joel Jaeggli)
Date: Tue, 31 Mar 2009 16:28:17 -0700
Subject: [arin-ppml] How hard is it to transition to IPv6?
In-Reply-To: <8A3DE12E408BBC499E40C0BE733C86030154CBB0@mail1.dulles.sv.int>
References: <20090327162556.GA57288@ussenterprise.ufp.org>	<942D9D7DDDDC80D26685B567@ZOP-MACTEL.local>
	<8A3DE12E408BBC499E40C0BE733C86030154CBB0@mail1.dulles.sv.int>
Message-ID: <49D2A711.5040405@bogus.com>

Divins, David wrote:
> Juniper does support those ssg/netscreen products on IPv6. You do need a
> cli to enable:
> set envar ipv6=yes
> 
> Where I see flaws is the total supporting package.  I have a router that
> has no IPv4.  Yet I need a v4 address for BGP RID.

strickly speaking router-id is a 32 bit number, it just happens to map
to a v4 ip addresss in most of your devices.

>  I cannot upgrade the
> device via v6, nor can it use v6 log, resolver, or time services.  But
> it does route and filter v6 like a madman.

> Personally, I am IPv6 full steam ahead, and I think for many
> organizations it will not be as bad as they suspect.  They just need
> some education, a lot of FUD has been distributed.
> 
> -dsd
> 
> David Divins
> Principal Engineer
> ServerVault Corp.
> 
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Michael Loftis
> Sent: Friday, March 27, 2009 12:32 PM
> To: Leo Bicknell; arin-ppml at arin.net
> Subject: Re: [arin-ppml] How hard is it to transition to IPv6?
> 
> 
> 
> --On March 27, 2009 11:25:56 AM -0500 Leo Bicknell <bicknell at ufp.org>
> wrote:
> 
>> http://www.networkworld.com/news/2009/032509-google-ipv6-easy.html
>>
>> At the IETF meeting there was a panel discussion on transitioing
>> to IPv6, at which Google gave their perspective.  I know a lot of
>> folks have been looking for some more concrete information on how
>> hard the transition will be, and here's one companies's take on it.
>>
>> I would like to applaud Google for both being out front and talking
>> about their experiences.
> 
> For some it's still impossible.  Eg any cable operator, why?  Consumer 
> devices still don't have v6.  Even many "business" class devices do not.
> 
> In my own experience I've run across Watchguard Firebox X Edge series,
> all 
> lower end juniper ssg/netscreen devices -- though i'm told you can
> enable 
> it from the CLI but it's unsupported, Juniper's M7i ASM as of 8.5R4.2
> while 
> it'll let you setup stateful firewalling stuff for v6 connections, it
> just 
> doesn't work at all.  I've not tried any other ASM/Services w/ v6
> though. 
> And I'm sure the list goes on.
> 
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 



From farmer at umn.edu  Tue Mar 31 19:47:37 2009
From: farmer at umn.edu (David Farmer)
Date: Tue, 31 Mar 2009 18:47:37 -0500
Subject: [arin-ppml] Draft Policy 2009-1: Is there an Emergency?
In-Reply-To: <443de7ad0903311417ifd8622cv55bf1272d90ae9e8@mail.gmail.com>
References: <49D01AE3.21085.B9720F6@farmer.umn.edu>,
	<443de7ad0903311417ifd8622cv55bf1272d90ae9e8@mail.gmail.com>
Message-ID: <49D26549.30445.539F3AF@farmer.umn.edu>

On 31 Mar 2009 Chris Grundemann wrote:

> I am not convinced that the car hitting the wall analogy is of much
> use when discussing IPv4 free-pool exhaustion, mainly because I can't
> seem to envision many organizations (if any) exploding at IANA, RIR,
> or ISP free IPv4 runout.  Perhaps a car running out of gas is a more
> applicable comparison?  

I like the car running out of gas analogy too, but I wanted the the airbag 
analogy for 2009-2, and the airbags don't go off when you run out of gas, at 
least I hope the don't. ;)

> I know it lacks the drama of a giant fireball but it seems more
> accurate.  

Cars only burst into a fireballs in Hollywood, I think it is some in the gas out 
there. :)  

A car accident also, makes me think of the irresistible force (Internet Growth) 
hitting the immovable object (IPv4 exhaustion), and the violent interaction 
that I believe will happen.  I just believe that that interaction is in slow motion 
something like a 1ms in the car accident equals a day for IPv4 exhaustion.

> Organizations unable to obtain more
> address space will not cease to exist, they will simply cease to grow
> (unless they adopt an alternative source of IP / fuel).  Also, I have
> a very hard time determining the location of a single collective car
> along this path - as someone (please forgive me for not looking up
> who) astutely pointed out in a previous ppml thread; IPv4 free pool
> exhaustion has effectively already happened for many orgs who will not
> be able to justify an allocation in the near future (2- years) but may
> need more addresses in the longer term.

That was me, and thanks for the quote. :)

That is way we call them metaphores and analogies.

Another analogy is Y2K and Digital TV is another, none of them are perfect, 
but many of them fit in one way or another.  I picked a car acident because I 
was trying to modivate a discussion about why this is an emergency.  Which 
I still think it is.



=======================================================
David Farmer				     Email:	farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota			     Phone:	612-626-0815
2218 University Ave SE			     Cell:		612-812-9952
Minneapolis, MN 55414-3029		     FAX:	612-626-1818
=======================================================



From tvest at pch.net  Tue Mar 31 21:24:25 2009
From: tvest at pch.net (Tom Vest)
Date: Tue, 31 Mar 2009 21:24:25 -0400
Subject: [arin-ppml] clarification of Board actions Feb 2 and Mar 18,
	2009
In-Reply-To: <75822E125BCB994F8446858C4B19F0D76BE5561C@SUEX07-MBX-04.ad.syr.edu>
References: <376189.27706.qm@web63303.mail.re1.yahoo.com>
	<107DD4CEABC54F669D321A6EB64005F3@tedsdesk>
	<EACF8B735E9CBA4B8BAF9E4165D03087531F88@ex1.cait.wustl.edu>
	<75822E125BCB994F8446858C4B19F0D76BE5560A@SUEX07-MBX-04.ad.syr.edu>
	<0B1F5A0C-C917-4F23-8C19-61EC83C280EF@pch.net>
	<75822E125BCB994F8446858C4B19F0D76BE5561C@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <369B4C02-F962-47C2-B2F3-2E274455081F@pch.net>

Hi Milton,

I find several messages from you in September on this subject:

1. http://lists.arin.net/pipermail/arin-ppml/2008-September/011788.html

...where you promise to share your experience on this subject:

> "This is typical of the debates we went through on the DNS side. I  
> see we
> have perhaps another 10 years of work to do on the address side.
> Like many people coming to these debates with limited knowledge of the
> legal, historical and political aspects of privacy and data protection
> debates, James presents us with a series of oversimplified false
> dichotomies..."


2. http://lists.arin.net/pipermail/arin-ppml/2008-September/011786.html

...where you clearly state that IP number whois should not be treated  
like DNS whois in any way.
My apologies for forgetting about this one. My memory was clouded by  
another statement in the same email, in which the purpose of IP number  
whois is raised, as if this were a mystery with no current answer:

> So first we establish the PURPOSE of the data, and what are the  
> limits of its appropriate use, and THEN we can settle on how  
> "complete and accurate" it is.


This brings us back to the first question that I raised again today.
If you do not agree that the IP number whois has a clear purpose now,  
or you disagree with that purpose and/or the way that it has been  
implemented, then it would be helpful if you would clarify what,  
specifically, you think should change. In other words, on your  
preferred view of IP number whois, what exactly would "cleaning and  
grooming" entail?


For the second question, I have to refer back to email (1):

1. http://lists.arin.net/pipermail/arin-ppml/2008-September/011788.html

> Wrt to registration records, there is a clear distinction to be made
> between individuals, which the law refers to as natural persons, and
> "legal persons" which are not persons at all but organizations.  
> Privacy
> rights mostly inhere in individuals, natural persons. This is
> well-established in privacy law. However, organizations also have some
> weaker rights to withhold information from public exposure.

Since the publicly exposed parts of IP number whois are almost  
universally "organizational" in substance (granted, with some orgs  
being sole proprietorships), I'm curious if, in your view, the privacy  
rights of "artificial persons" would afford them the right to withhold  
or restrict usage of any information that is currently present in IP  
number whois?

I raised the question again today in part because of the highly  
qualified response given in September:

3. http://lists.arin.net/pipermail/arin-ppml/2008-September/011802.html

> I am not saying that there should be no address Whois. ARIN's IP  
> address Whois, from a privacy standpoint, poses no serious problems  
> today. It tells you which company has been assigned the address  
> block and gives you contact info for that company. That is all it  
> needs to do to fulfill its operational purpose, which is to maintain  
> uniqueness and promote conservation and aggregation and other forms  
> of routing stability.

Perhaps I'm over-interpreting, but your messages do convey the  
impression that IP number whois could or should be changed, albeit in  
ways that remain unstated. If I am over-interpreting, then by all  
means please say so. Alternately, it would be helpful to the policy  
development process if you would clearly state what, if any,  
additional privacy rights could be asserted now or should be  
guaranteed in the future for the "artificial persons" that are present  
in IP number whois records.

On the claim of "ad hominem", I don't believe that anything of the  
kind was present in my first message today, and I'll leave it at that.  
I have no wish to repeat the squabbles of last year. If we could  
arrive at some clarity on the these two questions, then all of us  
could get on with more productive endeavors.

TV

On Mar 31, 2009, at 2:38 PM, Milton L Mueller wrote:

> Tom,
> I'm sorry you have become either so sloppy or so focused ad hominem  
> (or both) that you've lost sight of simple fact-checking.  Your  
> question on Aug 31 2008 not only led to a response from me but about  
> twenty messages in response and a long discussion. Check the  
> September 08 archives, please.


>> -----Original Message-----
>>
>> Milton, we are still waiting your views on what "cleaning and
>> grooming" actually means -- the last time an inquiry into this
>> question was made, you provided no response:
>>
>> On Aug 31, 2008, at 4:24 PM, Tom Vest wrote:
>>
>>> Hi Milton,
>>>
>>> A couple of quick questions:
>>>
>>> 1. Do you think that the completeness and accuracy of current DNS
>>> whois is the right standard for IP number whois?
>>>
>>> 2. Does your vision for individual privacy rights extend to
>>> "corporate persons," or only to natural persons?
>>> -- It would appear that you reject the distinction in DNS whois:
>>> http://forum.icann.org/lists/gnso-reg-sgc/msg00072.html
>>>
>>> Thanks,
>>>
>>> TV
>>
>>



From joelja at bogus.com  Tue Mar 31 23:24:17 2009
From: joelja at bogus.com (Joel Jaeggli)
Date: Tue, 31 Mar 2009 20:24:17 -0700
Subject: [arin-ppml] How hard is it to transition to IPv6?
In-Reply-To: <131D9C7318964D48AC33CC9768985A3C@tedsdesk>
References: <20090327162556.GA57288@ussenterprise.ufp.org>	<49CD1524.5080200@matthew.at>
	<131D9C7318964D48AC33CC9768985A3C@tedsdesk>
Message-ID: <49D2DE61.8020403@bogus.com>

Ted Mittelstaedt wrote:

> What the problem is that it's hard to convince someone that the
> device they have had for the last 5 years that's still working
> perfectly, will not get support from the manufacturer for upgrades.

Actually it's not, and in most case the adoption will be driven by the
same things it was last time. ie more speed  on the wan from your *dsl
platform docsis 3.0 or ftth deployment or on the lan side from 802.11n
or gigabit ethernet, the trick always is sneak the new software support
in with some things the customer really think they want... How many of
us are still using the same cpe we were using in the era of 256K dsl
service?