From packetgrrl at gmail.com  Tue Aug  2 11:00:01 2011
From: packetgrrl at gmail.com (cja@daydream.com)
Date: Tue, 2 Aug 2011 09:00:01 -0600
Subject: [arin-ppml] Fwd: [OPSAWG] WGLC on shared transition space
In-Reply-To: <20110802145602.C7987DC4344@newdev.eecs.harvard.edu>
References: <20110802145602.C7987DC4344@newdev.eecs.harvard.edu>
Message-ID: <CAMvf=7aBQFBAz1nHCCwCwvA+v7eytO+y_jkOigARayQ9aBcZ-Q@mail.gmail.com>

I am forwarding this because I feel that it is of interest to this
community.  My apologies if you are on the OPSAWG list and have already seen
this.

Thanks
----Cathy

---------- Forwarded message ----------
From: Scott O. Bradner <sob at harvard.edu>
Date: Tue, Aug 2, 2011 at 8:56 AM
Subject: [OPSAWG] WGLC on shared transition space
To: opsawg at ietf.org



this starts a WGLC on draft-weil-shared-transition-space-request-03.txt

comments to the list by Aug 16 please

Scott

---
A New Internet-Draft is available from the on-line Internet-Drafts
directories.

       Title           : IANA Reserved IPv4 Prefix for Shared Transition
Space
       Author(s)       : Jason Weil
                        Victor Kuarsingh
                        Chris Donley
                        Telstra Corp
                        Marla Azinger
       Filename        : draft-weil-shared-transition-space-request-03.txt
       Pages           : 12
       Date            : 2011-08-02

 This document requests a reserved IANA IPv4 address allocation as
 Shared Transition Space to support the deployment of IPv4 address
 sharing technologies post IPv4 exhaustion


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-weil-shared-transition-space-request-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-weil-shared-transition-space-request-03.txt
_______________________________________________
OPSAWG mailing list
OPSAWG at ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110802/14cff8d4/attachment.htm>

From cgrundemann at gmail.com  Thu Aug  4 13:20:39 2011
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Thu, 4 Aug 2011 11:20:39 -0600
Subject: [arin-ppml] Fwd: [OPSAWG] WGLC on shared transition space
In-Reply-To: <CAMvf=7aBQFBAz1nHCCwCwvA+v7eytO+y_jkOigARayQ9aBcZ-Q@mail.gmail.com>
References: <20110802145602.C7987DC4344@newdev.eecs.harvard.edu>
	<CAMvf=7aBQFBAz1nHCCwCwvA+v7eytO+y_jkOigARayQ9aBcZ-Q@mail.gmail.com>
Message-ID: <CAC1-dtkxSgNfwHimHgdPbaqSbCjhbsMPtCqtt4__A9LQ2jzX4Q@mail.gmail.com>

If you have an opinion one way or the other on this issue, I highly
encourage you to voice it on the OPSAWG list while this draft is in
last call (aka now). You can join the list here:
https://www.ietf.org/mailman/listinfo/opsawg

Cheers,
~Chris


On Tue, Aug 2, 2011 at 09:00, cja at daydream.com <packetgrrl at gmail.com> wrote:
> I am forwarding this because I feel that it is of interest to this
> community. ?My apologies if you are on the OPSAWG list and have already seen
> this.
> Thanks
> ----Cathy
>
> ---------- Forwarded message ----------
> From: Scott O. Bradner <sob at harvard.edu>
> Date: Tue, Aug 2, 2011 at 8:56 AM
> Subject: [OPSAWG] WGLC on shared transition space
> To: opsawg at ietf.org
>
>
>
> this starts a WGLC on draft-weil-shared-transition-space-request-03.txt
>
> comments to the list by Aug 16 please
>
> Scott
>
> ---
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
> ? ? ? ?Title ? ? ? ? ? : IANA Reserved IPv4 Prefix for Shared Transition
> Space
> ? ? ? ?Author(s) ? ? ? : Jason Weil
> ? ? ? ? ? ? ? ? ? ? ? ? Victor Kuarsingh
> ? ? ? ? ? ? ? ? ? ? ? ? Chris Donley
> ? ? ? ? ? ? ? ? ? ? ? ? Telstra Corp
> ? ? ? ? ? ? ? ? ? ? ? ? Marla Azinger
> ? ? ? ?Filename ? ? ? ?: draft-weil-shared-transition-space-request-03.txt
> ? ? ? ?Pages ? ? ? ? ? : 12
> ? ? ? ?Date ? ? ? ? ? ?: 2011-08-02
>
> ?This document requests a reserved IANA IPv4 address allocation as
> ?Shared Transition Space to support the deployment of IPv4 address
> ?sharing technologies post IPv4 exhaustion
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-weil-shared-transition-space-request-03.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-weil-shared-transition-space-request-03.txt
> _______________________________________________
> OPSAWG mailing list
> OPSAWG at ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>



-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.theIPv6experts.net
www.coisoc.org


From narten at us.ibm.com  Fri Aug  5 00:53:02 2011
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 05 Aug 2011 00:53:02 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201108050453.p754r237029223@rotala.raleigh.ibm.com>

Total of 5 messages in the last 7 days.
 
script run at: Fri Aug  5 00:53:02 EDT 2011
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 20.00% |    1 | 30.48% |    12548 | jcurran at arin.net
 20.00% |    1 | 22.30% |     9181 | packetgrrl at gmail.com
 20.00% |    1 | 17.10% |     7041 | cgrundemann at gmail.com
 20.00% |    1 | 16.32% |     6720 | scottleibrand at gmail.com
 20.00% |    1 | 13.80% |     5684 | narten at us.ibm.com
--------+------+--------+----------+------------------------
100.00% |    5 |100.00% |    41174 | Total


From mysidia at gmail.com  Sat Aug  6 19:41:48 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Sat, 6 Aug 2011 18:41:48 -0500
Subject: [arin-ppml] Fwd: spam from an IP 'broker'
Message-ID: <CAAAwwbXaqHbfo05JffUDq83YK4CSuwT=tA+kuAZL-bvHrbv1AQ@mail.gmail.com>

So now  IP speculators have the gall to  attempt to start trying to
sell IPs on public mailing lists..
It raises a question....  the 'documentation' requirements in 8.2 for merger
and acquisition, requiring to show physical network assets transfer with IPs...

This may not be intended, but nothing in 8.3 appears to preclude it
from being used when 8.2
is supposed to be used.    There is nothing in 8.3 that says related
organizations cannot name
each other as the recipient for specified transfer,  and skip all the
documentation required in
8.2 for a merger/acquisition.  (?)

Perhaps the 8.3  policy could be adjusted to add some requirement, to
dissuade trying
to  "sell shells of a company"  with no  non-IP assets, to acquire
resources  separate from the networks
they belong to.

e.g.  "A 12 month waiting period after an organization is acquired,
before it may transfer any resources
under an 8.3 specified transfer policy.    Any transfers to a new
parent, controlling, or related organization
must be executed under 8.2,  and include transfer of equipment the
resources are assigned to."

---------- Forwarded message ----------
From: IPv4 Brokers <XXXXXXXXXXX at gmail.com>
Date: Sat, Aug 6, 2011 at 5:31 PM
Subject: Corporation for Sale with IPv4 Assets
To: nanog at nanog.org


North American Corporation (domiciled in Nevada) is for sale.

All non-IPv4 assets and debts (and other liabilities) have been transferred
to another related corporation.

IPv4 Assets include:
1 - ASN; and
3 - /20 networks (12,288 IP Addresses) direct allocations (non-legacy).

Multiple options available for sale/purchase. ?Motivated sellers.

Please e-mail: XXXXXXXXXXX at gmail.com or call/text: (404) 532-XXXX.

Available on Saturday and Sunday for discussion.


From info at arin.net  Mon Aug  8 16:00:41 2011
From: info at arin.net (ARIN)
Date: Mon, 08 Aug 2011 16:00:41 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - July 2011
In-Reply-To: <4E2F16D9.7090601@arin.net>
References: <4E2F16D9.7090601@arin.net>
Message-ID: <4E404069.9040703@arin.net>

> The AC abandoned proposals 140 and 154. Anyone dissatisfied with these
> decisions may initiate a petition. The petition to advance these
> proposals would be the "Discussion Petition." The deadline to begin a
> petition will be five business days after the AC's draft meeting
> minutes are published.

The deadline for petitions is 15 August 2011.

The AC's draft minutes of their 21 July 2011 meeting are available at:
https://www.arin.net/about_us/ac/index.html

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


On 7/26/11 3:34 PM, ARIN wrote:
> In accordance with the ARIN Policy Development Process, the ARIN
> Advisory Council (AC) held a meeting on 21 July 2011 and made
> decisions about several proposals.
>
> The AC selected the following proposal as a draft policy for adoption
> discussion online and at the ARIN XXVIII Public Policy Meeting in
> Philadelphia in October. The draft policy will be posted shortly to the
> PPML.
>
>   ARIN-prop-141 Combined M&A and Specified Transfers
>
> The following proposals have been added to the AC's docket for
> development and evaluation:
>
>   ARIN-prop-155 IPv4 Number Resources for Use Within Region
>
> The AC abandoned the following proposals:
>
>   ARIN-prop-140 Business Failure Clarification
>   ARIN-prop-154 Shared Space for IPv4 Address Extension (w/ IETF
> considerations)
>
> Regarding proposal 140: Having reviewed the proposal - and underlying
> policy that is the subject of the proposal - the AC agrees with the
> staff assessment [included below] that existing policy does not
> require clarification. Existing policy is well-understood and utilized
> by the ARIN community. Furthermore, the proposal text is confusing to
> many and would not have resulted in clearer policy. If there is in
> fact a problem to be remedied, the AC encourages further conversation
> to bring it to light, so that the community can address it more directly.
>
> The ARIN AC voted to abandon Proposal 154 because it considered the
> policy to be redundant considering the Board of Trustees has this same
> recommendation still on its table from policy 2011-5. The AC will
> continue to monitor events related to this policy concept as they
> develop from the Board of Trustees, the IAB, and the IETF.
>
> The AC thanks the authors and the community for their continuing effort
> and contributions to these and all other policy considerations.
>
> The AC abandoned proposals 140 and 154. Anyone dissatisfied with these
> decisions may initiate a petition. The petition to advance these
> proposals would be the "Discussion Petition." The deadline to begin a
> petition will be five business days after the AC's draft meeting
> minutes are published. For more information on starting and
> participating in petitions, see PDP Petitions at:
> https://www.arin.net/policy/pdp_petitions.html
>
> Draft Policy and Proposal texts are available at:
> https://www.arin.net/policy/proposals/index.html
>
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
>
> Regards,
>
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Staff Assessment
>
> Proposal 140
> Business Failure Clarification
>
> Date of Assessment:  13 July 2011
>
> 1. Proposal Summary (Staff Understanding)
>
> This proposal changes existing NRPM section 8.1 (Transfer) Principles
> to state that any business that ceases to exist should notify ARIN as
> soon as possible so that the number resources can be returned to ARIN.
>
> 2. Comments
>
> A. ARIN Staff Comments
>
> Current implementation of this policy is that when an organization
> goes out of business or ceases to exist, the registered POC cannot
> ?sell, transfer, assign, or give the number resource to any other
> person or organization? and must notify ARIN of the business dissolution.
>
>  ? Based on staff experience, the existing policy language has been
> well understood and utilized by the ARIN community since it was first
> implemented.
>  ? Therefore, this proposal may be unnecessary since it appears to
> address a non-existent problem.
>
>
> B. ARIN General Counsel
>      Pending
>
> 3. Resource Impact
>
> This policy would have minimal resource impact from an implementation
> aspect.  It is estimated that implementation would occur within 3
> months after ratification by the ARIN  Board of Trustees.
> The following would be needed in order to implement:
>
>  ? Updated guidelines
>  ? Staff training
>
>
> 4. Proposal Text
>
> Policy statement:
>
> Modify Section 8.1. Strike "Thus, if a company goes out of business"
> and replace with "If an organization ceases to exist". Replace "must
> notify ARIN if a business fails" with "should notify ARIN that the
> oganization has ceased to exist".
>
> the resultant text:
>
> "Number resources are issued, based on justified need, to
> organizations, not to individuals representing those organizations. If
> an organization ceases to exist, 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. If a transfer is not promptly
> requested and justified, the POC should notify ARIN that the
> organization has ceased to exist so the assigned number resources can
> be returned to the available pool of number resources."
>
> Rationale: Potential confusion exists over the requirement to return
> address space from a bankrupt entity. This is a needed clarification
> to the policy manual.
>
> This text removes any mention of special treatment of bankrupt
> entities that was mentioned in version 1 and which may not comply with
> law.
> "must notify" is replaced with "should notify" in order to reflect
> that the POC may not have the authority or permission to make the
> notification.



From narten at us.ibm.com  Fri Aug 12 00:53:02 2011
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 12 Aug 2011 00:53:02 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201108120453.p7C4r2Vf029903@rotala.raleigh.ibm.com>

Total of 3 messages in the last 7 days.
 
script run at: Fri Aug 12 00:53:02 EDT 2011
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 33.33% |    1 | 46.26% |     9792 | info at arin.net
 33.33% |    1 | 28.39% |     6008 | mysidia at gmail.com
 33.33% |    1 | 25.35% |     5366 | narten at us.ibm.com
--------+------+--------+----------+------------------------
100.00% |    3 |100.00% |    21166 | Total


From bensons at queuefull.net  Wed Aug 17 10:15:27 2011
From: bensons at queuefull.net (Benson Schliesser)
Date: Wed, 17 Aug 2011 09:15:27 -0500
Subject: [arin-ppml] Fwd: [OPSAWG] end of WGLC on transition space
References: <CA7135B1.13AB7%bschlies@cisco.com>
Message-ID: <D32C0E50-C94B-4571-9195-C5D5A7CF4711@queuefull.net>

Sorry for the forwarded message, but I thought this might be of interest to PPML.

The IETF Ops Area Working Group has concluded that there is consensus around reserving an IPv4 /10 prefix for Shared Transition Space.  This specific message (below) is in reference to http://tools.ietf.org/html/draft-weil-shared-transition-space-request-03 which, in turn, points to http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-01 as an applicability statement.

Cheers,
-Benson


> ------ Forwarded Message
> From: "Scott O. Bradner" <sob at harvard.edu>
> Date: Wed, 17 Aug 2011 07:49:46 -0400 (EDT)
> To: <opsawg at ietf.org>
> Subject: [OPSAWG] end of WGLC on transition space
> 
> this concludes the opsawg WGLC on shared transition space
> 
> There were 45 messages from 22 people on the opsawg mailing list in
> response to the WGLC.  Assuming I counted correctly, four of the
> posters were opposed to the proposal, 17 in favor and one said he was
> not in favor or opposed.
> 
> Based on the mailing list discussion I would conclude that there is
> consensus in support of the proposal.
> 
> In addition the proposal was discussed during the opsawg session in
> Quebec City.  Seventy nine people signed opsawg blue sheets for that
> session and I expect that a number of people present for the
> discussion did not sign since the room was standing room only and the
> blue sheets did not get to everyone and a number of people left after
> the shared transition space discussion.
> 
> Most people in room raised a hand when asked if the supported goal of
> ID, I did not see any that disagreed but a few people spoke against
> the proposal so I may have missed a few hands.
> 
> 
> from RFC 2418
>   In the case where a consensus which has been reached during a face-
>   to-face meeting is being verified on a mailing list the people who
>   were in the meeting and expressed agreement must be taken into
>   account.  If there were 100 people in a meeting and only a few people
>   on the mailing list disagree with the consensus of the meeting then
>   the consensus should be seen as being verified.  Note that enough
>   time should be given to the verification process for the mailing list
>   readers to understand and consider any objections that may be raised
>   on the list.  The normal two week last-call period should be
>   sufficient for this.
> 
> Thus, based on the combination of the very strong support shown in
> the face-to-face meeting and the strong support in response to the
> WGLC, I conclude that the WG has reached consensus in support of the
> proposal.
> 
> I will now forward a request to the ADs that the ID be published
> using the AD sponsored procedure.
> 
> Scott
> 
> 
> 
> 
> 
> _______________________________________________
> OPSAWG mailing list
> OPSAWG at ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
> 
> ------ End of Forwarded Message



From owen at delong.com  Thu Aug 18 17:21:07 2011
From: owen at delong.com (Owen DeLong)
Date: Thu, 18 Aug 2011 14:21:07 -0700
Subject: [arin-ppml] Submitted to ARIN Consultation and Suggestion Process
Message-ID: <C581DB7E-0E92-4405-9081-4654EF5A1CF5@delong.com>

I have submitted the following to the ACSP. If you feel that this would benefit the community as I do, I encourage you to express support of such action to ARIN here on PPML.

Owen



Suggestion:

ARIN should maintain and publish a list of all prefixes transfered under section 8.3. The list should identify the original prefix (the block originally held by the transferor) and each subdivided prefix (each partial block derived from that original block) transferred under this policy and the date each prefix was transferred.

Upon implementation of this suggestion, ARIN should include in the list at the earliest possible time all prefixes which have been transferred under section 8.3 to date.


Rationale:
The community has a right to know which prefixes have been added or are the result of transfer-related disaggregation. This will provide accurate data in a central well-known location. It will also provide a valuable tool for the community and the AC to evaluate the effectiveness and any negative consequences from the transfer policy.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2105 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110818/6b83f0dc/attachment.p7s>

From bensons at queuefull.net  Thu Aug 18 17:33:27 2011
From: bensons at queuefull.net (Benson Schliesser)
Date: Thu, 18 Aug 2011 16:33:27 -0500
Subject: [arin-ppml] Submitted to ARIN Consultation and Suggestion
	Process
In-Reply-To: <C581DB7E-0E92-4405-9081-4654EF5A1CF5@delong.com>
References: <C581DB7E-0E92-4405-9081-4654EF5A1CF5@delong.com>
Message-ID: <D16C03DC-BA59-4DE0-93B0-07D98F6331B9@queuefull.net>

Hi, Owen -

On Aug 18, 2011, at 4:21 PM, Owen DeLong wrote:

> Suggestion:
> 
> ARIN should maintain and publish a list of all prefixes transfered under section 8.3. The list should identify the original prefix (the block originally held by the transferor) and each subdivided prefix (each partial block derived from that original block) transferred under this policy and the date each prefix was transferred.

I rather think there are two issues here:  First, I agree that the community needs information on how transfers have been (de)aggregated.  This doesn't necessarily require that the actual prefixes be exposed - in fact, it would be more useful to have summarized information rather than individual prefix details in this report.  Second, I agree that the community needs something like a "who-was" service.  Together, I think these achieve what your recommendation describes.

Thoughts?

Cheers,
-Benson



From owen at delong.com  Thu Aug 18 17:54:12 2011
From: owen at delong.com (Owen DeLong)
Date: Thu, 18 Aug 2011 14:54:12 -0700
Subject: [arin-ppml] Submitted to ARIN Consultation and Suggestion
	Process
In-Reply-To: <D16C03DC-BA59-4DE0-93B0-07D98F6331B9@queuefull.net>
References: <C581DB7E-0E92-4405-9081-4654EF5A1CF5@delong.com>
	<D16C03DC-BA59-4DE0-93B0-07D98F6331B9@queuefull.net>
Message-ID: <E2E0CDF0-846E-4A28-8ECE-52228C5AF54E@delong.com>


On Aug 18, 2011, at 2:33 PM, Benson Schliesser wrote:

> Hi, Owen -
> 
> On Aug 18, 2011, at 4:21 PM, Owen DeLong wrote:
> 
>> Suggestion:
>> 
>> ARIN should maintain and publish a list of all prefixes transfered under section 8.3. The list should identify the original prefix (the block originally held by the transferor) and each subdivided prefix (each partial block derived from that original block) transferred under this policy and the date each prefix was transferred.
> 
> I rather think there are two issues here:  First, I agree that the community needs information on how transfers have been (de)aggregated.  This doesn't necessarily require that the actual prefixes be exposed - in fact, it would be more useful to have summarized information rather than individual prefix details in this report.  Second, I agree that the community needs something like a "who-was" service.  Together, I think these achieve what your recommendation describes.
> 

I believe that people who run routers might prefer to be able to exclude routes based on a first-come-first-serve basis when their routers start running out of memory. While the aggregated data can help with the policy part, policy alone is not the only concern as transfers become more common.


The ability to do so requires exposure of the individual prefixes.

You are correct that all of the data I want published is already published, but, correlating it requires:

1.	A lot of additional workload on ARIN's whois servers
2.	Subscription to the daily address allocation feed (Are transfers published in that?)
3.	ARIN actually implementing the who-was service that they agreed should be made
	available some time ago, but, which continues to go unimplemented.

As such, I believe that this list is valuable as suggested and relatively trivial for ARIN to implement.

Owen

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

From bensons at queuefull.net  Thu Aug 18 18:01:24 2011
From: bensons at queuefull.net (Benson Schliesser)
Date: Thu, 18 Aug 2011 17:01:24 -0500
Subject: [arin-ppml] Submitted to ARIN Consultation and Suggestion
	Process
In-Reply-To: <E2E0CDF0-846E-4A28-8ECE-52228C5AF54E@delong.com>
References: <C581DB7E-0E92-4405-9081-4654EF5A1CF5@delong.com>
	<D16C03DC-BA59-4DE0-93B0-07D98F6331B9@queuefull.net>
	<E2E0CDF0-846E-4A28-8ECE-52228C5AF54E@delong.com>
Message-ID: <26E168BC-8AC2-4DDA-AFF2-360A1B2976B4@queuefull.net>


On Aug 18, 2011, at 4:54 PM, Owen DeLong wrote:

> I believe that people who run routers might prefer to be able to exclude routes based on a first-come-first-serve basis when their routers start running out of memory. While the aggregated data can help with the policy part, policy alone is not the only concern as transfers become more common.
> 
> The ability to do so requires exposure of the individual prefixes.

Are you suggesting that people might drop routes (e.g. because of resource limitations) based on whether they were disaggregated due to a transfer?  In my view, such a decision should be based on the value of reachability to the prefix in question (not the way the prefix was acquired), so if I understand you correctly then I disagree.  Can you clarify?

Thanks,
-Benson




From heather.skanks at gmail.com  Thu Aug 18 18:05:21 2011
From: heather.skanks at gmail.com (Heather Schiller)
Date: Thu, 18 Aug 2011 18:05:21 -0400
Subject: [arin-ppml] Submitted to ARIN Consultation and Suggestion
	Process
In-Reply-To: <D16C03DC-BA59-4DE0-93B0-07D98F6331B9@queuefull.net>
References: <C581DB7E-0E92-4405-9081-4654EF5A1CF5@delong.com>
	<D16C03DC-BA59-4DE0-93B0-07D98F6331B9@queuefull.net>
Message-ID: <CADricwo33+12tFF6F0C+ymsYZXD1gxDN9wyTFR+whir+nhZbqA@mail.gmail.com>

On Thu, Aug 18, 2011 at 5:33 PM, Benson Schliesser
<bensons at queuefull.net> wrote:
>?Second, I agree that the community needs something like a "who-was" service. ?Together, I think these achieve what your
> recommendation describes.

It's been >3 years since I submitted that suggestion:
https://www.arin.net/participate/acsp/suggestions/2008-15.html



>
> Thoughts?
>
> Cheers,
> -Benson
>
> _______________________________________________
> 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 Aug 18 18:22:32 2011
From: kkargel at polartel.com (Kevin Kargel)
Date: Thu, 18 Aug 2011 17:22:32 -0500
Subject: [arin-ppml] Submitted to ARIN Consultation and
	Suggestion	Process
In-Reply-To: <26E168BC-8AC2-4DDA-AFF2-360A1B2976B4@queuefull.net>
References: <C581DB7E-0E92-4405-9081-4654EF5A1CF5@delong.com>
	<D16C03DC-BA59-4DE0-93B0-07D98F6331B9@queuefull.net>
	<E2E0CDF0-846E-4A28-8ECE-52228C5AF54E@delong.com>
	<26E168BC-8AC2-4DDA-AFF2-360A1B2976B4@queuefull.net>
Message-ID: <8695009A81378E48879980039EEDAD280114CB3717@MAIL1.polartel.local>

I support Owen's proposal..

 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Benson Schliesser
> Sent: Thursday, August 18, 2011 5:01 PM
> To: Owen DeLong
> Cc: ARIN PPML; Advisory Council
> Subject: Re: [arin-ppml] Submitted to ARIN Consultation and Suggestion
> Process
> 
> 
> On Aug 18, 2011, at 4:54 PM, Owen DeLong wrote:
> 
> > I believe that people who run routers might prefer to be able to exclude
> routes based on a first-come-first-serve basis when their routers start
> running out of memory. While the aggregated data can help with the policy
> part, policy alone is not the only concern as transfers become more
> common.
> >
> > The ability to do so requires exposure of the individual prefixes.
> 
> Are you suggesting that people might drop routes (e.g. because of resource
> limitations) based on whether they were disaggregated due to a transfer?
> In my view, such a decision should be based on the value of reachability
> to the prefix in question (not the way the prefix was acquired), so if I
> understand you correctly then I disagree.  Can you clarify?

IMHO network operators should be able to make routing decisions based on whatever the heck they want to base the decisions for *their* network on.  I do believe that this would provide valuable information to the community.

> 
> Thanks,
> -Benson
> 
> 
> _______________________________________________
> 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  Thu Aug 18 20:04:30 2011
From: owen at delong.com (Owen DeLong)
Date: Thu, 18 Aug 2011 17:04:30 -0700
Subject: [arin-ppml] Submitted to ARIN Consultation and Suggestion
	Process
In-Reply-To: <26E168BC-8AC2-4DDA-AFF2-360A1B2976B4@queuefull.net>
References: <C581DB7E-0E92-4405-9081-4654EF5A1CF5@delong.com>
	<D16C03DC-BA59-4DE0-93B0-07D98F6331B9@queuefull.net>
	<E2E0CDF0-846E-4A28-8ECE-52228C5AF54E@delong.com>
	<26E168BC-8AC2-4DDA-AFF2-360A1B2976B4@queuefull.net>
Message-ID: <C5DA0188-9E6F-437D-BC6E-585921322B79@delong.com>


On Aug 18, 2011, at 3:01 PM, Benson Schliesser wrote:

> 
> On Aug 18, 2011, at 4:54 PM, Owen DeLong wrote:
> 
>> I believe that people who run routers might prefer to be able to exclude routes based on a first-come-first-serve basis when their routers start running out of memory. While the aggregated data can help with the policy part, policy alone is not the only concern as transfers become more common.
>> 
>> The ability to do so requires exposure of the individual prefixes.
> 
> Are you suggesting that people might drop routes (e.g. because of resource limitations) based on whether they were disaggregated due to a transfer?  In my view, such a decision should be based on the value of reachability to the prefix in question (not the way the prefix was acquired), so if I understand you correctly then I disagree.  Can you clarify?
> 
> Thanks,
> -Benson
> 

I'm suggesting that when it comes time to choose which routes to drop due to resource limitations, the most recent transfers might be the choice some people would prefer to make. (e.g. keep what has been working the longest working and let the suffering fall to those who joined the game most recently).

Not so much the way the prefix was acquired as when the prefix was acquired. IMHO, if you acquire prefixes that late in the game, you should expect that some people might be out of routing slots and may not be able to carry them. IPv4 is doomed to this fate IMHO. As such, I see no reason to have the internet degrade into arbitrary value judgments over the desire to reach a prefix (after all, if some ASN between you and the destination has a different value judgment, you lose until the point where the subset of prefixes that are actually globally reachable is a tiny fraction of those being advertised).

Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2105 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110818/0ffdd397/attachment.p7s>

From hannigan at gmail.com  Thu Aug 18 20:43:50 2011
From: hannigan at gmail.com (Martin Hannigan)
Date: Thu, 18 Aug 2011 20:43:50 -0400
Subject: [arin-ppml] [arin-council] Submitted to ARIN Consultation and
 Suggestion Process
In-Reply-To: <C5DA0188-9E6F-437D-BC6E-585921322B79@delong.com>
References: <C581DB7E-0E92-4405-9081-4654EF5A1CF5@delong.com>
	<D16C03DC-BA59-4DE0-93B0-07D98F6331B9@queuefull.net>
	<E2E0CDF0-846E-4A28-8ECE-52228C5AF54E@delong.com>
	<26E168BC-8AC2-4DDA-AFF2-360A1B2976B4@queuefull.net>
	<C5DA0188-9E6F-437D-BC6E-585921322B79@delong.com>
Message-ID: <CAMDXq5OJP27wYPp+fqbRH9AFD9HWwpSnJX3ks_xx6hob3QdkXQ@mail.gmail.com>

On Thu, Aug 18, 2011 at 8:04 PM, Owen DeLong <owen at delong.com> wrote:
>

[ clip ]

> I'm suggesting that when it comes time to choose which routes to drop due to resource limitations, the most recent transfers might be the choice some people would prefer to make. (e.g. keep what has been working the longest working and let the suffering fall to those who joined the game most recently).
>


The above statement demonstrates a reason why we should discourage
such a suggestion and make such a task difficult and
 available to those who take the time to first become clued. It's
already acknowledged that there is enough data out there to do it. If
the transparency becomes insanely important. someone will develop a
tool. I think we're at a stage of "good enough".


Best,

-M<


From kgenessy at uen.org  Thu Aug 18 20:34:18 2011
From: kgenessy at uen.org (Kelly Genessy)
Date: Thu, 18 Aug 2011 18:34:18 -0600
Subject: [arin-ppml] Submitted to ARIN Consultation and
	Suggestion	Process
In-Reply-To: <C5DA0188-9E6F-437D-BC6E-585921322B79@delong.com>
References: <C581DB7E-0E92-4405-9081-4654EF5A1CF5@delong.com>
	<D16C03DC-BA59-4DE0-93B0-07D98F6331B9@queuefull.net>
	<E2E0CDF0-846E-4A28-8ECE-52228C5AF54E@delong.com>
	<26E168BC-8AC2-4DDA-AFF2-360A1B2976B4@queuefull.net>
	<C5DA0188-9E6F-437D-BC6E-585921322B79@delong.com>
Message-ID: <32265AE9-FA41-48A2-8DD7-411593837537@uen.org>



Sent from my IPhone. 

On Aug 18, 2011, at 6:06 PM, "Owen DeLong" <owen at delong.com> wrote:

> 
> On Aug 18, 2011, at 3:01 PM, Benson Schliesser wrote:
> 
>> 
>> On Aug 18, 2011, at 4:54 PM, Owen DeLong wrote:
>> 
>>> I believe that people who run routers might prefer to be able to exclude routes based on a first-come-first-serve basis when their routers start running out of memory. While the aggregated data can help with the policy part, policy alone is not the only concern as transfers become more common.
>>> 
>>> The ability to do so requires exposure of the individual prefixes.
>> 
>> Are you suggesting that people might drop routes (e.g. because of resource limitations) based on whether they were disaggregated due to a transfer?  In my view, such a decision should be based on the value of reachability to the prefix in question (not the way the prefix was acquired), so if I understand you correctly then I disagree.  Can you clarify?
>> 
>> Thanks,
>> -Benson
>> 
> 
> I'm suggesting that when it comes time to choose which routes to drop due to resource limitations, the most recent transfers might be the choice some people would prefer to make. (e.g. keep what has been working the longest working and let the suffering fall to those who joined the game most recently).
> 
> Not so much the way the prefix was acquired as when the prefix was acquired. IMHO, if you acquire prefixes that late in the game, you should expect that some people might be out of routing slots and may not be able to carry them. IPv4 is doomed to this fate IMHO. As such, I see no reason to have the internet degrade into arbitrary value judgments over the desire to reach a prefix (after all, if some ASN between you and the destination has a different value judgment, you lose until the point where the subset of prefixes that are actually globally reachable is a tiny fraction of those being advertised).
> 
> Owen
> 
> <smime.p7s>
> _______________________________________________
> 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 mysidia at gmail.com  Thu Aug 18 20:45:56 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Thu, 18 Aug 2011 19:45:56 -0500
Subject: [arin-ppml] Submitted to ARIN Consultation and Suggestion
	Process
In-Reply-To: <C5DA0188-9E6F-437D-BC6E-585921322B79@delong.com>
References: <C581DB7E-0E92-4405-9081-4654EF5A1CF5@delong.com>
	<D16C03DC-BA59-4DE0-93B0-07D98F6331B9@queuefull.net>
	<E2E0CDF0-846E-4A28-8ECE-52228C5AF54E@delong.com>
	<26E168BC-8AC2-4DDA-AFF2-360A1B2976B4@queuefull.net>
	<C5DA0188-9E6F-437D-BC6E-585921322B79@delong.com>
Message-ID: <CAAAwwbVBFuX-3W-m4x+9D1mW49Bc-o4swbVxo3T3YFbMn9R99g@mail.gmail.com>

On Thu, Aug 18, 2011 at 7:04 PM, Owen DeLong <owen at delong.com> wrote:

I would be in favor of ARIN maintaining and publishing a list of
prefixes transferred under 8.3
as suggested.

>
>I see no reason to have the internet degrade into arbitrary value judgments over the desire to reach a prefix (after all, if some ASN between you and the destination has a different value judgment, you lose until the point where the subset of prefixes that are actually globally reachable is a tiny fraction of those being advertised).
>

If the number of prefixes globally reachable drops to a sufficiently
low number, then
that would mean the internet is no longer global,  and IPv4 is
essentially over....

I'm sure the "international" prefixes, such as ones issued to other
RIRs will be the first to
be blocked from resource constrained folks' tables.     But most
likely this will mean the
people doing that filtering will start taking a default route from
their transit providers,
to avoid losing reachability.

How much public interest is there in a non-global internet, really?

If it becomes non-global, enough network participants may eventually
be lost, that advertised prefixes drops
and therefore memory consumption and IPv4 address utilization drops

> Owen
--
-JH


From paul at redbarn.org  Thu Aug 18 20:53:16 2011
From: paul at redbarn.org (Paul Vixie)
Date: Fri, 19 Aug 2011 00:53:16 +0000
Subject: [arin-ppml] [arin-council] Submitted to ARIN Consultation and
	Suggestion Process
In-Reply-To: <C5DA0188-9E6F-437D-BC6E-585921322B79@delong.com>
References: <C581DB7E-0E92-4405-9081-4654EF5A1CF5@delong.com>
	<26E168BC-8AC2-4DDA-AFF2-360A1B2976B4@queuefull.net>
	<C5DA0188-9E6F-437D-BC6E-585921322B79@delong.com>
Message-ID: <201108190053.16730.paul@redbarn.org>

On Friday, August 19, 2011 12:04:30 am Owen DeLong wrote:
> I'm suggesting that when it comes time to choose which routes to drop due
> to resource limitations, the most recent transfers might be the choice
> some people would prefer to make. (e.g. keep what has been working the
> longest working and let the suffering fall to those who joined the game
> most recently).

do you mean "joined" or do you mean "changed" ?

> Not so much the way the prefix was acquired as when the prefix was
> acquired. IMHO, if you acquire prefixes that late in the game, you should
> expect that some people might be out of routing slots and may not be able
> to carry them. IPv4 is doomed to this fate IMHO. ...

can you explain why IPv6 would not be similarly doomed ?


From narten at us.ibm.com  Fri Aug 19 00:53:02 2011
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 19 Aug 2011 00:53:02 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201108190453.p7J4r2YO003872@rotala.raleigh.ibm.com>

Total of 13 messages in the last 7 days.
 
script run at: Fri Aug 19 00:53:02 EDT 2011
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 23.08% |    3 | 34.15% |    29477 | owen at delong.com
 23.08% |    3 | 19.76% |    17054 | bensons at queuefull.net
  7.69% |    1 |  8.11% |     7004 | kgenessy at uen.org
  7.69% |    1 |  6.93% |     5983 | kkargel at polartel.com
  7.69% |    1 |  6.80% |     5868 | mysidia at gmail.com
  7.69% |    1 |  6.25% |     5397 | hannigan at gmail.com
  7.69% |    1 |  6.12% |     5279 | heather.skanks at gmail.com
  7.69% |    1 |  6.07% |     5237 | narten at us.ibm.com
  7.69% |    1 |  5.82% |     5027 | paul at redbarn.org
--------+------+--------+----------+------------------------
100.00% |   13 |100.00% |    86326 | Total


From owen at delong.com  Fri Aug 19 03:59:51 2011
From: owen at delong.com (Owen DeLong)
Date: Fri, 19 Aug 2011 00:59:51 -0700
Subject: [arin-ppml] [arin-council] Submitted to ARIN Consultation and
	Suggestion Process
In-Reply-To: <CAMDXq5OJP27wYPp+fqbRH9AFD9HWwpSnJX3ks_xx6hob3QdkXQ@mail.gmail.com>
References: <C581DB7E-0E92-4405-9081-4654EF5A1CF5@delong.com>
	<D16C03DC-BA59-4DE0-93B0-07D98F6331B9@queuefull.net>
	<E2E0CDF0-846E-4A28-8ECE-52228C5AF54E@delong.com>
	<26E168BC-8AC2-4DDA-AFF2-360A1B2976B4@queuefull.net>
	<C5DA0188-9E6F-437D-BC6E-585921322B79@delong.com>
	<CAMDXq5OJP27wYPp+fqbRH9AFD9HWwpSnJX3ks_xx6hob3QdkXQ@mail.gmail.com>
Message-ID: <7691FF9C-2ECA-4340-BF93-5AD5923C878A@delong.com>


On Aug 18, 2011, at 5:43 PM, Martin Hannigan wrote:

> On Thu, Aug 18, 2011 at 8:04 PM, Owen DeLong <owen at delong.com> wrote:
>> 
> 
> [ clip ]
> 
>> I'm suggesting that when it comes time to choose which routes to drop due to resource limitations, the most recent transfers might be the choice some people would prefer to make. (e.g. keep what has been working the longest working and let the suffering fall to those who joined the game most recently).
>> 
> 
> 
> The above statement demonstrates a reason why we should discourage
> such a suggestion and make such a task difficult and
> available to those who take the time to first become clued. It's
> already acknowledged that there is enough data out there to do it. If
> the transparency becomes insanely important. someone will develop a
> tool. I think we're at a stage of "good enough".
> 

No, we've acknowledged that the data _SHOULD_ be there, but, the who-was 
service that would be needed has not come to fruition. This list would be easier
(less software development) for the ARIN staff, so, hopefully it could actually
get implemented instead of just promised some day.

Care to explain how the community benefits from making this difficult?

Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2105 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110819/6bbc1bc3/attachment.p7s>

From owen at delong.com  Fri Aug 19 04:02:15 2011
From: owen at delong.com (Owen DeLong)
Date: Fri, 19 Aug 2011 01:02:15 -0700
Subject: [arin-ppml] Submitted to ARIN Consultation and Suggestion
	Process
In-Reply-To: <CAAAwwbVBFuX-3W-m4x+9D1mW49Bc-o4swbVxo3T3YFbMn9R99g@mail.gmail.com>
References: <C581DB7E-0E92-4405-9081-4654EF5A1CF5@delong.com>
	<D16C03DC-BA59-4DE0-93B0-07D98F6331B9@queuefull.net>
	<E2E0CDF0-846E-4A28-8ECE-52228C5AF54E@delong.com>
	<26E168BC-8AC2-4DDA-AFF2-360A1B2976B4@queuefull.net>
	<C5DA0188-9E6F-437D-BC6E-585921322B79@delong.com>
	<CAAAwwbVBFuX-3W-m4x+9D1mW49Bc-o4swbVxo3T3YFbMn9R99g@mail.gmail.com>
Message-ID: <282F2FD0-389C-49C4-B479-85C66FF7E3DE@delong.com>


On Aug 18, 2011, at 5:45 PM, Jimmy Hess wrote:

> On Thu, Aug 18, 2011 at 7:04 PM, Owen DeLong <owen at delong.com> wrote:
> 
> I would be in favor of ARIN maintaining and publishing a list of
> prefixes transferred under 8.3
> as suggested.
> 
>> 
>> I see no reason to have the internet degrade into arbitrary value judgments over the desire to reach a prefix (after all, if some ASN between you and the destination has a different value judgment, you lose until the point where the subset of prefixes that are actually globally reachable is a tiny fraction of those being advertised).
>> 
> 
> If the number of prefixes globally reachable drops to a sufficiently
> low number, then
> that would mean the internet is no longer global,  and IPv4 is
> essentially over....
> 
> I'm sure the "international" prefixes, such as ones issued to other
> RIRs will be the first to
> be blocked from resource constrained folks' tables.     But most
> likely this will mean the
> people doing that filtering will start taking a default route from
> their transit providers,
> to avoid losing reachability.
> 

I'm talking about the coming day when the transfer markets have
sufficiently exploded the routing table that the DFZ providers are
having to make route acceptance decisions.

> How much public interest is there in a non-global internet, really?
> 
> If it becomes non-global, enough network participants may eventually
> be lost, that advertised prefixes drops
> and therefore memory consumption and IPv4 address utilization drops
> 

Interested or not, I think it is the inevitable reality of the future of IPv4 in
one form or another.

Arguably, NAT has already done part of this.

Owen

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

From owen at delong.com  Fri Aug 19 04:08:36 2011
From: owen at delong.com (Owen DeLong)
Date: Fri, 19 Aug 2011 01:08:36 -0700
Subject: [arin-ppml] [arin-council] Submitted to ARIN Consultation and
	Suggestion Process
In-Reply-To: <201108190053.16730.paul@redbarn.org>
References: <C581DB7E-0E92-4405-9081-4654EF5A1CF5@delong.com>
	<26E168BC-8AC2-4DDA-AFF2-360A1B2976B4@queuefull.net>
	<C5DA0188-9E6F-437D-BC6E-585921322B79@delong.com>
	<201108190053.16730.paul@redbarn.org>
Message-ID: <44BCF1C8-B481-4D5A-B077-4DB156D929EC@delong.com>


On Aug 18, 2011, at 5:53 PM, Paul Vixie wrote:

> On Friday, August 19, 2011 12:04:30 am Owen DeLong wrote:
>> I'm suggesting that when it comes time to choose which routes to drop due
>> to resource limitations, the most recent transfers might be the choice
>> some people would prefer to make. (e.g. keep what has been working the
>> longest working and let the suffering fall to those who joined the game
>> most recently).
> 
> do you mean "joined" or do you mean "changed" ?
> 

I believe I mean joined.

On at least a theoretical level, prefixes that are freshly disaggregated through
NRPM 8.3 transfers are most likely being used to serve new users or provide
new services.

>> Not so much the way the prefix was acquired as when the prefix was
>> acquired. IMHO, if you acquire prefixes that late in the game, you should
>> expect that some people might be out of routing slots and may not be able
>> to carry them. IPv4 is doomed to this fate IMHO. ...
> 
> can you explain why IPv6 would not be similarly doomed ?

Because I don't need another /16 when I put 65,000 hosts on my /64?

Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2105 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110819/34adcf7d/attachment.p7s>

From heather.skanks at gmail.com  Fri Aug 19 10:48:09 2011
From: heather.skanks at gmail.com (Heather Schiller)
Date: Fri, 19 Aug 2011 10:48:09 -0400
Subject: [arin-ppml] [arin-council] Submitted to ARIN Consultation and
 Suggestion Process
In-Reply-To: <44BCF1C8-B481-4D5A-B077-4DB156D929EC@delong.com>
References: <C581DB7E-0E92-4405-9081-4654EF5A1CF5@delong.com>
	<26E168BC-8AC2-4DDA-AFF2-360A1B2976B4@queuefull.net>
	<C5DA0188-9E6F-437D-BC6E-585921322B79@delong.com>
	<201108190053.16730.paul@redbarn.org>
	<44BCF1C8-B481-4D5A-B077-4DB156D929EC@delong.com>
Message-ID: <CADricwqTTod-2jdcpqp9oFbyCPUT2-nrzrkgrXQOB0u7kd2K5A@mail.gmail.com>

On Fri, Aug 19, 2011 at 4:08 AM, Owen DeLong <owen at delong.com> wrote:
>
> On Aug 18, 2011, at 5:53 PM, Paul Vixie wrote:
>.
>
>>> Not so much the way the prefix was acquired as when the prefix was
>>> acquired. IMHO, if you acquire prefixes that late in the game, you should
>>> expect that some people might be out of routing slots and may not be able
>>> to carry them. IPv4 is doomed to this fate IMHO. ...
>>
>> can you explain why IPv6 would not be similarly doomed ?
>
> Because I don't need another /16 when I put 65,000 hosts on my /64?
>
> Owen
>

I believe Paul's point is: What makes you so sure that people with
limited routing slots, will choose to carry those new fangled v6
things that only geeks are using, versus turning off v6 in order to
carry more v4 routes?  There isn't a magical routing table separation
inside the box.  Providers know who they can reach on v4, they know
there is content on v4 and that they will have less complaints and
more customers working if they choose v4 over v6.  Another thing that
could happen is that folks move to filter on /23 or shorter, instead
of /24.  It's hard to imagine that today, but that may be more
palatable than dropping entire regions.

In all of this, I have not seen a push for better aggregation - so
here is a nudge.. if you see your company on the list, go ask why and
see what can be done to aggregate.
http://www.cidr-report.org/as2.0/#Gains  for the full list.

ASnum  	NetsNow	  NetsAggr	  NetGain	  % Gain  	Description
Table  	371480	  219140	  152340	  41.0%  	All ASes
 	 	 	 	 	
AS6389  	3583	  231	  3352	  93.6%  	BELLSOUTH-NET-BLK - BellSouth.net Inc.
AS18566  	1912	  376	  1536	  80.3%  	COVAD - Covad Communications Co.
AS4766  	2498	  969	  1529	  61.2%  	KIXS-AS-KR Korea Telecom
AS22773  	1433	  106	  1327	  92.6%  	ASN-CXA-ALL-CCI-22773-RDC - Cox
Communications Inc.
AS4755  	1531	  223	  1308	  85.4%  	TATACOMM-AS TATA Communications
formerly VSNL is Leading ISP


From joelja at bogus.com  Fri Aug 19 11:12:26 2011
From: joelja at bogus.com (Joel Jaeggli)
Date: Fri, 19 Aug 2011 08:12:26 -0700
Subject: [arin-ppml] [arin-council] Submitted to ARIN Consultation and
	Suggestion Process
In-Reply-To: <CADricwqTTod-2jdcpqp9oFbyCPUT2-nrzrkgrXQOB0u7kd2K5A@mail.gmail.com>
References: <C581DB7E-0E92-4405-9081-4654EF5A1CF5@delong.com>
	<26E168BC-8AC2-4DDA-AFF2-360A1B2976B4@queuefull.net>
	<C5DA0188-9E6F-437D-BC6E-585921322B79@delong.com>
	<201108190053.16730.paul@redbarn.org>
	<44BCF1C8-B481-4D5A-B077-4DB156D929EC@delong.com>
	<CADricwqTTod-2jdcpqp9oFbyCPUT2-nrzrkgrXQOB0u7kd2K5A@mail.gmail.com>
Message-ID: <CD6F48CC-02D0-4471-A1F7-252709D98315@bogus.com>


On Aug 19, 2011, at 7:48 AM, Heather Schiller wrote:

> On Fri, Aug 19, 2011 at 4:08 AM, Owen DeLong <owen at delong.com> wrote:
>> 
>> On Aug 18, 2011, at 5:53 PM, Paul Vixie wrote:
>> .
>> 
>>>> Not so much the way the prefix was acquired as when the prefix was
>>>> acquired. IMHO, if you acquire prefixes that late in the game, you should
>>>> expect that some people might be out of routing slots and may not be able
>>>> to carry them. IPv4 is doomed to this fate IMHO. ...
>>> 
>>> can you explain why IPv6 would not be similarly doomed ?
>> 
>> Because I don't need another /16 when I put 65,000 hosts on my /64?
>> 
>> Owen
>> 
> 
> I believe Paul's point is: What makes you so sure that people with
> limited routing slots, will choose to carry those new fangled v6
> things that only geeks are using, versus turning off v6 in order to
> carry more v4 routes?

Assuming that your box is configured for a cam split of something like .5 million v4 routes and 16k v6 routes (I know of boxes with this split), dialing back v6 to zero only gets you around a 7% increase in your available v4 routes. that might be enough in a pinch but it doesn't solve your ipv4 problem by any means.

>  There isn't a magical routing table separation
> inside the box.  Providers know who they can reach on v4, they know
> there is content on v4 and that they will have less complaints and
> more customers working if they choose v4 over v6.  Another thing that
> could happen is that folks move to filter on /23 or shorter, instead
> of /24.  It's hard to imagine that today, but that may be more
> palatable than dropping entire regions.

an alternative of course beyond fib compression by policy, is buying new linecards or routers, which does happen...

Not to many AS border routers are limited to 255k routes anymore, we've had and have surmounted this problem many times before, and so long as it doesn't happen too quickly planned obsolecence takes it's course. if you fit a line to the cidr (reports) in 2007/2008 you'll be buying new routers in 2012/2013.

> In all of this, I have not seen a push for better aggregation

Shame has never worked before, why would it now?

> - so
> here is a nudge.. if you see your company on the list, go ask why and
> see what can be done to aggregate.
> http://www.cidr-report.org/as2.0/#Gains  for the full list.
> 
> ASnum  	NetsNow	  NetsAggr	  NetGain	  % Gain  	Description
> Table  	371480	  219140	  152340	  41.0%  	All ASes
> 	 	 	 	 	
> AS6389  	3583	  231	  3352	  93.6%  	BELLSOUTH-NET-BLK - BellSouth.net Inc.
> AS18566  	1912	  376	  1536	  80.3%  	COVAD - Covad Communications Co.
> AS4766  	2498	  969	  1529	  61.2%  	KIXS-AS-KR Korea Telecom
> AS22773  	1433	  106	  1327	  92.6%  	ASN-CXA-ALL-CCI-22773-RDC - Cox
> Communications Inc.
> AS4755  	1531	  223	  1308	  85.4%  	TATACOMM-AS TATA Communications
> formerly VSNL is Leading ISP
> _______________________________________________
> 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 bensons at queuefull.net  Fri Aug 19 15:33:03 2011
From: bensons at queuefull.net (Benson Schliesser)
Date: Fri, 19 Aug 2011 14:33:03 -0500
Subject: [arin-ppml] Fwd: Last Call:
	<draft-weil-shared-transition-space-request-03.txt> (IANA
	Reserved IPv4 Prefix for Shared Transition Space) to
	Informational RFC
References: <20110819161025.15887.78808.idtracker@ietfa.amsl.com>
Message-ID: <AF73F0F5-0DF8-4E16-92AE-9F7129DCEF50@queuefull.net>

FYI.  As described in my previous message on this topic, the IETF document asking for a Shared Transition Space reservation (IPv4 /10) is making progress and is now going through IETF Last Call.

Cheers,
-Benson


Begin forwarded message:

> From: The IESG <iesg-secretary at ietf.org>
> Date: August 19, 2011 11:10:25 AM CDT
> To: IETF-Announce <ietf-announce at ietf.org>
> Subject: Last Call: <draft-weil-shared-transition-space-request-03.txt> (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC
> Reply-To: ietf at ietf.org
> 
> 
> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'IANA Reserved IPv4 Prefix for Shared Transition Space'
>  <draft-weil-shared-transition-space-request-03.txt> as an Informational
> RFC
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf at ietf.org mailing lists by 2011-09-16. Exceptionally, comments may be
> sent to iesg at ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>   This document requests a reserved IANA IPv4 address allocation as
>   Shared Transition Space to support the deployment of IPv4 address
>   sharing technologies post IPv4 exhaustion
> 
> 
> 
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-weil-shared-transition-space-request/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-weil-shared-transition-space-request/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce at ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110819/08160e92/attachment.htm>

From owen at delong.com  Fri Aug 19 15:43:32 2011
From: owen at delong.com (Owen DeLong)
Date: Fri, 19 Aug 2011 12:43:32 -0700
Subject: [arin-ppml] [arin-council] Submitted to ARIN Consultation and
	Suggestion Process
In-Reply-To: <CADricwqTTod-2jdcpqp9oFbyCPUT2-nrzrkgrXQOB0u7kd2K5A@mail.gmail.com>
References: <C581DB7E-0E92-4405-9081-4654EF5A1CF5@delong.com>
	<26E168BC-8AC2-4DDA-AFF2-360A1B2976B4@queuefull.net>
	<C5DA0188-9E6F-437D-BC6E-585921322B79@delong.com>
	<201108190053.16730.paul@redbarn.org>
	<44BCF1C8-B481-4D5A-B077-4DB156D929EC@delong.com>
	<CADricwqTTod-2jdcpqp9oFbyCPUT2-nrzrkgrXQOB0u7kd2K5A@mail.gmail.com>
Message-ID: <EA42F5E3-84CF-4144-B59A-57166F93638B@delong.com>


On Aug 19, 2011, at 7:48 AM, Heather Schiller wrote:

> On Fri, Aug 19, 2011 at 4:08 AM, Owen DeLong <owen at delong.com> wrote:
>> 
>> On Aug 18, 2011, at 5:53 PM, Paul Vixie wrote:
>> .
>> 
>>>> Not so much the way the prefix was acquired as when the prefix was
>>>> acquired. IMHO, if you acquire prefixes that late in the game, you should
>>>> expect that some people might be out of routing slots and may not be able
>>>> to carry them. IPv4 is doomed to this fate IMHO. ...
>>> 
>>> can you explain why IPv6 would not be similarly doomed ?
>> 
>> Because I don't need another /16 when I put 65,000 hosts on my /64?
>> 
>> Owen
>> 
> 
> I believe Paul's point is: What makes you so sure that people with
> limited routing slots, will choose to carry those new fangled v6
> things that only geeks are using, versus turning off v6 in order to
> carry more v4 routes?  There isn't a magical routing table separation
> inside the box.  Providers know who they can reach on v4, they know
> there is content on v4 and that they will have less complaints and
> more customers working if they choose v4 over v6.  Another thing that

That's very true. However, I think that most network engineers are able
to see that IPv6 has a sustainable future and IPv4 does not. I can't
imagine that very many providers would actually consider turning off
IPv6 to make IPv4 routing slots available as doing so would be so utterly
self-defeating.

I suspect those that do will not subsequently be viable long enough
for this to truly matter.

> could happen is that folks move to filter on /23 or shorter, instead
> of /24.  It's hard to imagine that today, but that may be more
> palatable than dropping entire regions.
> 

I wouldn't think people would drop entire regions. I can, however, foresee
people dropping newer IPv4 routes in favor of preserving pre-existing
aggregates.

> In all of this, I have not seen a push for better aggregation - so
> here is a nudge.. if you see your company on the list, go ask why and
> see what can be done to aggregate.
> http://www.cidr-report.org/as2.0/#Gains  for the full list.
> 
> ASnum  	NetsNow	  NetsAggr	  NetGain	  % Gain  	Description
> Table  	371480	  219140	  152340	  41.0%  	All ASes
> 	 	 	 	 	
> AS6389  	3583	  231	  3352	  93.6%  	BELLSOUTH-NET-BLK - BellSouth.net Inc.
> AS18566  	1912	  376	  1536	  80.3%  	COVAD - Covad Communications Co.
> AS4766  	2498	  969	  1529	  61.2%  	KIXS-AS-KR Korea Telecom
> AS22773  	1433	  106	  1327	  92.6%  	ASN-CXA-ALL-CCI-22773-RDC - Cox
> Communications Inc.
> AS4755  	1531	  223	  1308	  85.4%  	TATACOMM-AS TATA Communications
> formerly VSNL is Leading ISP

Yep... That will forestall the situation for a little while if people actually
do something about it.

Owen



From owen at delong.com  Fri Aug 19 15:52:59 2011
From: owen at delong.com (Owen DeLong)
Date: Fri, 19 Aug 2011 12:52:59 -0700
Subject: [arin-ppml] [arin-council] Submitted to ARIN Consultation and
	Suggestion Process
In-Reply-To: <CD6F48CC-02D0-4471-A1F7-252709D98315@bogus.com>
References: <C581DB7E-0E92-4405-9081-4654EF5A1CF5@delong.com>
	<26E168BC-8AC2-4DDA-AFF2-360A1B2976B4@queuefull.net>
	<C5DA0188-9E6F-437D-BC6E-585921322B79@delong.com>
	<201108190053.16730.paul@redbarn.org>
	<44BCF1C8-B481-4D5A-B077-4DB156D929EC@delong.com>
	<CADricwqTTod-2jdcpqp9oFbyCPUT2-nrzrkgrXQOB0u7kd2K5A@mail.gmail.com>
	<CD6F48CC-02D0-4471-A1F7-252709D98315@bogus.com>
Message-ID: <50D6013D-9CE4-4121-9621-2296DE4FE63F@delong.com>

> 
> an alternative of course beyond fib compression by policy, is buying new linecards or routers, which does happen...
> 
> Not to many AS border routers are limited to 255k routes anymore, we've had and have surmounted this problem many times before, and so long as it doesn't happen too quickly planned obsolecence takes it's course. if you fit a line to the cidr (reports) in 2007/2008 you'll be buying new routers in 2012/2013.

Does anyone honestly believe that 8.3 will not lead to accelerated prefix lengthening?

When you take the central registry out of the reclaim/reissue process you virtually eliminate
all likelihood of any form of returned-block coalescence which was a relatively low probability
even with everything going through a centralized process.

When you combine this with the fact that the intent of the single-aggregate language has
been superseded by legal interpretation (legitimately, the phrase was poorly written) and
there is now pressure to simply eliminate the language instead of restoring it's intent, I
believe that things are only going to get worse.

Owen



From mueller at syr.edu  Sun Aug 21 13:26:56 2011
From: mueller at syr.edu (Milton L Mueller)
Date: Sun, 21 Aug 2011 13:26:56 -0400
Subject: [arin-ppml] [arin-council] Submitted to ARIN Consultation and
 Suggestion Process
In-Reply-To: <CAMDXq5OJP27wYPp+fqbRH9AFD9HWwpSnJX3ks_xx6hob3QdkXQ@mail.gmail.com>
References: <C581DB7E-0E92-4405-9081-4654EF5A1CF5@delong.com>
	<D16C03DC-BA59-4DE0-93B0-07D98F6331B9@queuefull.net>
	<E2E0CDF0-846E-4A28-8ECE-52228C5AF54E@delong.com>
	<26E168BC-8AC2-4DDA-AFF2-360A1B2976B4@queuefull.net>
	<C5DA0188-9E6F-437D-BC6E-585921322B79@delong.com>
	<CAMDXq5OJP27wYPp+fqbRH9AFD9HWwpSnJX3ks_xx6hob3QdkXQ@mail.gmail.com>
Message-ID: <75822E125BCB994F8446858C4B19F0D71754936FA2@SUEX07-MBX-04.ad.syr.edu>

I support the original suggestion that prefixes transferred under 8.3 should be made public. 
I think discussion of the merit of that idea is getting sidetracked by the completely extraneous issue of whether that information would be used to filter routes. Making transferred prefixes public does not in any way specify how or why people would use the information. If Owen wants to filter routes on that basis he can (and he could do so now), if others don't want to they needn't. The whole discussion of dropping routes is a distraction. 

Milton L. Mueller
Professor, Syracuse University School of Information Studies
Internet Governance Project
http://blog.internetgovernance.org 



> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Martin Hannigan
> Sent: Thursday, August 18, 2011 8:44 PM
> To: Benson Schliesser
> Cc: ARIN PPML
> Subject: Re: [arin-ppml] [arin-council] Submitted to ARIN Consultation
> and Suggestion Process
> 
> On Thu, Aug 18, 2011 at 8:04 PM, Owen DeLong <owen at delong.com> wrote:
> >
> 
> [ clip ]
> 
> > I'm suggesting that when it comes time to choose which routes to drop
> due to resource limitations, the most recent transfers might be the
> choice some people would prefer to make. (e.g. keep what has been
> working the longest working and let the suffering fall to those who
> joined the game most recently).
> >
> 
> 
> The above statement demonstrates a reason why we should discourage such
> a suggestion and make such a task difficult and  available to those who
> take the time to first become clued. It's already acknowledged that
> there is enough data out there to do it. If the transparency becomes
> insanely important. someone will develop a tool. I think we're at a
> stage of "good enough".
> 
> 
> Best,
> 
> -M<
> _______________________________________________
> 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  Sun Aug 21 15:27:07 2011
From: bill at herrin.us (William Herrin)
Date: Sun, 21 Aug 2011 15:27:07 -0400
Subject: [arin-ppml] Submitted to ARIN Consultation and Suggestion
	Process
In-Reply-To: <282F2FD0-389C-49C4-B479-85C66FF7E3DE@delong.com>
References: <C581DB7E-0E92-4405-9081-4654EF5A1CF5@delong.com>
	<D16C03DC-BA59-4DE0-93B0-07D98F6331B9@queuefull.net>
	<E2E0CDF0-846E-4A28-8ECE-52228C5AF54E@delong.com>
	<26E168BC-8AC2-4DDA-AFF2-360A1B2976B4@queuefull.net>
	<C5DA0188-9E6F-437D-BC6E-585921322B79@delong.com>
	<CAAAwwbVBFuX-3W-m4x+9D1mW49Bc-o4swbVxo3T3YFbMn9R99g@mail.gmail.com>
	<282F2FD0-389C-49C4-B479-85C66FF7E3DE@delong.com>
Message-ID: <CAP-guGW-Xf9p5BFUmLjtx5Eh+PA4YUj+=ASBs9MWuL-_KxxuQQ@mail.gmail.com>

On Fri, Aug 19, 2011 at 4:02 AM, Owen DeLong <owen at delong.com> wrote:
> I'm talking about the coming day when the transfer markets have
> sufficiently exploded the routing table that the DFZ providers are
> having to make route acceptance decisions.

Hi Owen,

That's unrealistic. Assuming the /24 barrier remains in place (and
there's no good reason to assume otherwise) the terminal size of the
IPv4 table will be well under the maximum that can be handled by a
cost-effective router.

The IPv6 policies (failing to standardize on specific prefix sizes
from fixed-prefix blocks) are far more likely to resulting in table
size problems than the IPv4 transfer policy. Without anything to
constrain it, 2^48 is enough more than 2^24 to be a problem for the
hardware.

Nevertheless, your original point is a strong one: Reporting transfers
which disaggregate existing blocks would "provide a valuable tool for
the community and the AC to evaluate the effectiveness and any
negative consequences from the transfer policy."  As a community we're
exploring uncharted territory with for-pay address-only transfers. It
seems like it would be appropriate to study them carefully and in
great detail for the first little while.

For that reason, I SUPPORT your suggestion.

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 joelja at bogus.com  Sun Aug 21 21:52:45 2011
From: joelja at bogus.com (Joel Jaeggli)
Date: Sun, 21 Aug 2011 18:52:45 -0700
Subject: [arin-ppml] [arin-council] Submitted to ARIN Consultation and
	Suggestion Process
In-Reply-To: <50D6013D-9CE4-4121-9621-2296DE4FE63F@delong.com>
References: <C581DB7E-0E92-4405-9081-4654EF5A1CF5@delong.com>
	<26E168BC-8AC2-4DDA-AFF2-360A1B2976B4@queuefull.net>
	<C5DA0188-9E6F-437D-BC6E-585921322B79@delong.com>
	<201108190053.16730.paul@redbarn.org>
	<44BCF1C8-B481-4D5A-B077-4DB156D929EC@delong.com>
	<CADricwqTTod-2jdcpqp9oFbyCPUT2-nrzrkgrXQOB0u7kd2K5A@mail.gmail.com>
	<CD6F48CC-02D0-4471-A1F7-252709D98315@bogus.com>
	<50D6013D-9CE4-4121-9621-2296DE4FE63F@delong.com>
Message-ID: <2C180F28-0F93-4E4A-B22F-9070C1EE2900@bogus.com>


On Aug 19, 2011, at 12:52 PM, Owen DeLong wrote:

>> 
>> an alternative of course beyond fib compression by policy, is buying new linecards or routers, which does happen...
>> 
>> Not to many AS border routers are limited to 255k routes anymore, we've had and have surmounted this problem many times before, and so long as it doesn't happen too quickly planned obsolecence takes it's course. if you fit a line to the cidr (reports) in 2007/2008 you'll be buying new routers in 2012/2013.
> 
> Does anyone honestly believe that 8.3 will not lead to accelerated prefix lengthening?

I'm really speaking to the mechanics, and not the specific outcome of the policy proposal.

But Accelerated compared to what? at some point we won't be allocating new ipv4 prefixes? The current set of inmates appear to have no trouble de-aggregating the prefixes they already have. Slicing and dicing them to allow new entrants will necessarily produce de-aggregation even if I or someone else involves the registry in the exercise.

> When you take the central registry out of the reclaim/reissue process you virtually eliminate
> all likelihood of any form of returned-block coalescence which was a relatively low probability
> even with everything going through a centralized process.

> When you combine this with the fact that the intent of the single-aggregate language has
> been superseded by legal interpretation (legitimately, the phrase was poorly written) and
> there is now pressure to simply eliminate the language instead of restoring it's intent, I
> believe that things are only going to get worse.
> 
> Owen
> 
> 



From joelja at bogus.com  Sun Aug 21 22:05:28 2011
From: joelja at bogus.com (Joel Jaeggli)
Date: Sun, 21 Aug 2011 19:05:28 -0700
Subject: [arin-ppml] [arin-council] Submitted to ARIN Consultation and
	Suggestion Process
In-Reply-To: <EA42F5E3-84CF-4144-B59A-57166F93638B@delong.com>
References: <C581DB7E-0E92-4405-9081-4654EF5A1CF5@delong.com>
	<26E168BC-8AC2-4DDA-AFF2-360A1B2976B4@queuefull.net>
	<C5DA0188-9E6F-437D-BC6E-585921322B79@delong.com>
	<201108190053.16730.paul@redbarn.org>
	<44BCF1C8-B481-4D5A-B077-4DB156D929EC@delong.com>
	<CADricwqTTod-2jdcpqp9oFbyCPUT2-nrzrkgrXQOB0u7kd2K5A@mail.gmail.com>
	<EA42F5E3-84CF-4144-B59A-57166F93638B@delong.com>
Message-ID: <CB5B84B1-7C44-44C7-8D23-251B57DB1F0A@bogus.com>


On Aug 19, 2011, at 12:43 PM, Owen DeLong wrote:
>> 	 	 	 	 	
>> AS6389  	3583	  231	  3352	  93.6%  	BELLSOUTH-NET-BLK - BellSouth.net Inc.
>> AS18566  	1912	  376	  1536	  80.3%  	COVAD - Covad Communications Co.
>> AS4766  	2498	  969	  1529	  61.2%  	KIXS-AS-KR Korea Telecom
>> AS22773  	1433	  106	  1327	  92.6%  	ASN-CXA-ALL-CCI-22773-RDC - Cox
>> Communications Inc.
>> AS4755  	1531	  223	  1308	  85.4%  	TATACOMM-AS TATA Communications
>> formerly VSNL is Leading ISP
> 
> Yep... That will forestall the situation for a little while if people actually
> do something about it.

At the cost of some minor potential for loss of connectivity and a loss of a lot of sanity I could probably glob those ~11k routes in my rib into ~2k routes in my fib. but to what end, I have 361k routes rather than 370k. something like 40% of the ASes are announcing one prefix so as far as I'm concerned they are maximally aggregated...

> 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 owen at delong.com  Mon Aug 22 03:42:10 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 22 Aug 2011 00:42:10 -0700
Subject: [arin-ppml] Submitted to ARIN Consultation and Suggestion
	Process
In-Reply-To: <CAP-guGW-Xf9p5BFUmLjtx5Eh+PA4YUj+=ASBs9MWuL-_KxxuQQ@mail.gmail.com>
References: <C581DB7E-0E92-4405-9081-4654EF5A1CF5@delong.com>
	<D16C03DC-BA59-4DE0-93B0-07D98F6331B9@queuefull.net>
	<E2E0CDF0-846E-4A28-8ECE-52228C5AF54E@delong.com>
	<26E168BC-8AC2-4DDA-AFF2-360A1B2976B4@queuefull.net>
	<C5DA0188-9E6F-437D-BC6E-585921322B79@delong.com>
	<CAAAwwbVBFuX-3W-m4x+9D1mW49Bc-o4swbVxo3T3YFbMn9R99g@mail.gmail.com>
	<282F2FD0-389C-49C4-B479-85C66FF7E3DE@delong.com>
	<CAP-guGW-Xf9p5BFUmLjtx5Eh+PA4YUj+=ASBs9MWuL-_KxxuQQ@mail.gmail.com>
Message-ID: <0A83FC7A-A531-41BB-A75F-9E6C34FD4AB7@delong.com>


On Aug 21, 2011, at 12:27 PM, William Herrin wrote:

> On Fri, Aug 19, 2011 at 4:02 AM, Owen DeLong <owen at delong.com> wrote:
>> I'm talking about the coming day when the transfer markets have
>> sufficiently exploded the routing table that the DFZ providers are
>> having to make route acceptance decisions.
> 
> Hi Owen,
> 
> That's unrealistic. Assuming the /24 barrier remains in place (and
> there's no good reason to assume otherwise) the terminal size of the
> IPv4 table will be well under the maximum that can be handled by a
> cost-effective router.
> 
By my count there are ~15,000,000 /24s in the usable unicast
IPv4 space. Please explain to me how the terminal size of the
15,000,000 route table will remain well under the 1,000,000
route maximum in a cost-effective router?

> The IPv6 policies (failing to standardize on specific prefix sizes
> from fixed-prefix blocks) are far more likely to resulting in table
> size problems than the IPv4 transfer policy. Without anything to
> constrain it, 2^48 is enough more than 2^24 to be a problem for the
> hardware.
> 

If there was any likelihood whatsoever of seeing 2^48 prefixes, sure.
The reality is that is massively unrealistic and the combination of
large provider aggregates (2011-3) and other constraints (there
aren't 2^48 end-sites to give /48s to in reality), etc. will prevent us
from getting anywhere near that.

> Nevertheless, your original point is a strong one: Reporting transfers
> which disaggregate existing blocks would "provide a valuable tool for
> the community and the AC to evaluate the effectiveness and any
> negative consequences from the transfer policy."  As a community we're
> exploring uncharted territory with for-pay address-only transfers. It
> seems like it would be appropriate to study them carefully and in
> great detail for the first little while.
> 

Agreed.

> For that reason, I SUPPORT your suggestion.
> 

Excellent. The good news is that it's useful for both purposes.

Owen

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

From owen at delong.com  Mon Aug 22 03:54:49 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 22 Aug 2011 00:54:49 -0700
Subject: [arin-ppml] [arin-council] Submitted to ARIN Consultation and
	Suggestion Process
In-Reply-To: <2C180F28-0F93-4E4A-B22F-9070C1EE2900@bogus.com>
References: <C581DB7E-0E92-4405-9081-4654EF5A1CF5@delong.com>
	<26E168BC-8AC2-4DDA-AFF2-360A1B2976B4@queuefull.net>
	<C5DA0188-9E6F-437D-BC6E-585921322B79@delong.com>
	<201108190053.16730.paul@redbarn.org>
	<44BCF1C8-B481-4D5A-B077-4DB156D929EC@delong.com>
	<CADricwqTTod-2jdcpqp9oFbyCPUT2-nrzrkgrXQOB0u7kd2K5A@mail.gmail.com>
	<CD6F48CC-02D0-4471-A1F7-252709D98315@bogus.com>
	<50D6013D-9CE4-4121-9621-2296DE4FE63F@delong.com>
	<2C180F28-0F93-4E4A-B22F-9070C1EE2900@bogus.com>
Message-ID: <ED56F430-5DF5-4B52-9034-EC423D1F6D72@delong.com>


On Aug 21, 2011, at 6:52 PM, Joel Jaeggli wrote:

> 
> On Aug 19, 2011, at 12:52 PM, Owen DeLong wrote:
> 
>>> 
>>> an alternative of course beyond fib compression by policy, is buying new linecards or routers, which does happen...
>>> 
>>> Not to many AS border routers are limited to 255k routes anymore, we've had and have surmounted this problem many times before, and so long as it doesn't happen too quickly planned obsolecence takes it's course. if you fit a line to the cidr (reports) in 2007/2008 you'll be buying new routers in 2012/2013.
>> 
>> Does anyone honestly believe that 8.3 will not lead to accelerated prefix lengthening?
> 
> I'm really speaking to the mechanics, and not the specific outcome of the policy proposal.
> 
> But Accelerated compared to what? at some point we won't be allocating new ipv4 prefixes? The current set of inmates appear to have no trouble de-aggregating the prefixes they already have. Slicing and dicing them to allow new entrants will necessarily produce de-aggregation even if I or someone else involves the registry in the exercise.
> 

Accelerated compared to what is happening today.

I believe the second half of your sentence already states that it will happen.

Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2105 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110822/78425b2e/attachment.p7s>

From joelja at bogus.com  Mon Aug 22 12:11:04 2011
From: joelja at bogus.com (Joel Jaeggli)
Date: Mon, 22 Aug 2011 09:11:04 -0700
Subject: [arin-ppml] Submitted to ARIN Consultation and Suggestion
	Process
In-Reply-To: <0A83FC7A-A531-41BB-A75F-9E6C34FD4AB7@delong.com>
References: <C581DB7E-0E92-4405-9081-4654EF5A1CF5@delong.com>
	<D16C03DC-BA59-4DE0-93B0-07D98F6331B9@queuefull.net>
	<E2E0CDF0-846E-4A28-8ECE-52228C5AF54E@delong.com>
	<26E168BC-8AC2-4DDA-AFF2-360A1B2976B4@queuefull.net>
	<C5DA0188-9E6F-437D-BC6E-585921322B79@delong.com>
	<CAAAwwbVBFuX-3W-m4x+9D1mW49Bc-o4swbVxo3T3YFbMn9R99g@mail.gmail.com>
	<282F2FD0-389C-49C4-B479-85C66FF7E3DE@delong.com>
	<CAP-guGW-Xf9p5BFUmLjtx5Eh+PA4YUj+=ASBs9MWuL-_KxxuQQ@mail.gmail.com>
	<0A83FC7A-A531-41BB-A75F-9E6C34FD4AB7@delong.com>
Message-ID: <12293AA8-CB10-403B-AD77-FB32322CAC83@bogus.com>


On Aug 22, 2011, at 12:42 AM, Owen DeLong wrote:
> On Aug 21, 2011, at 12:27 PM, William Herrin wrote:
>> 
>> That's unrealistic. Assuming the /24 barrier remains in place (and
>> there's no good reason to assume otherwise) the terminal size of the
>> IPv4 table will be well under the maximum that can be handled by a
>> cost-effective router.
>> 
> By my count there are ~15,000,000 /24s in the usable unicast
> IPv4 space. Please explain to me how the terminal size of the
> 15,000,000 route table will remain well under the 1,000,000
> route maximum in a cost-effective router?

A million route fib is "cost effective" at one point in time, after that, it's cheap. the question is when do you need a XX million routes fib, because you don't design or buy capacity you won't need...

From bill at herrin.us  Mon Aug 22 13:21:49 2011
From: bill at herrin.us (William Herrin)
Date: Mon, 22 Aug 2011 13:21:49 -0400
Subject: [arin-ppml] Submitted to ARIN Consultation and Suggestion
	Process
In-Reply-To: <0A83FC7A-A531-41BB-A75F-9E6C34FD4AB7@delong.com>
References: <C581DB7E-0E92-4405-9081-4654EF5A1CF5@delong.com>
	<D16C03DC-BA59-4DE0-93B0-07D98F6331B9@queuefull.net>
	<E2E0CDF0-846E-4A28-8ECE-52228C5AF54E@delong.com>
	<26E168BC-8AC2-4DDA-AFF2-360A1B2976B4@queuefull.net>
	<C5DA0188-9E6F-437D-BC6E-585921322B79@delong.com>
	<CAAAwwbVBFuX-3W-m4x+9D1mW49Bc-o4swbVxo3T3YFbMn9R99g@mail.gmail.com>
	<282F2FD0-389C-49C4-B479-85C66FF7E3DE@delong.com>
	<CAP-guGW-Xf9p5BFUmLjtx5Eh+PA4YUj+=ASBs9MWuL-_KxxuQQ@mail.gmail.com>
	<0A83FC7A-A531-41BB-A75F-9E6C34FD4AB7@delong.com>
Message-ID: <CAP-guGXkMQYCdYOHGtYWDzrBMg9QG_WfN_N9fBZ0kOOFq_+W5Q@mail.gmail.com>

On Mon, Aug 22, 2011 at 3:42 AM, Owen DeLong <owen at delong.com> wrote:
> On Aug 21, 2011, at 12:27 PM, William Herrin wrote:
>> On Fri, Aug 19, 2011 at 4:02 AM, Owen DeLong <owen at delong.com> wrote:
>>> I'm talking about the coming day when the transfer markets have
>>> sufficiently exploded the routing table that the DFZ providers are
>>> having to make route acceptance decisions.
>>
>> That's unrealistic. Assuming the /24 barrier remains in place (and
>> there's no good reason to assume otherwise) the terminal size of the
>> IPv4 table will be well under the maximum that can be handled by a
>> cost-effective router.
>>
> By my count there are ~15,000,000 /24s in the usable unicast
> IPv4 space. Please explain to me how the terminal size of the
> 15,000,000 route table will remain well under the 1,000,000
> route maximum in a cost-effective router?

Hi Owen,

1. There's shipping equipment that supports 2M routes and the
manufacturers have been capable of building routers that handle 10M
routes for several years now. They don't because nobody's asking for
them yet. I know this because (A) vendors C and J have each said so
and (B) the math works.

2. The number of unicast /24's in IPv4 is not the worst case terminal
size of the table. For one thing, there are overlaid routes (the /20
goes here a /23 inside it goes there and some /24's go a third place).
That increases the count. For another, even under worst case
assumptions you should expect a huge number of prefixes that nobody
needs to disaggregate to /24 or anywhere close. It's like subdividing
property -- some gets divided into 1/8th acre lots, but only some.
Most is usable as desired at much larger sizes and the next owner
wants all of it, not part. That reduces the count.

The worst case assumptions (the collapse of IPv6 and indefinite
continuation of IPv4) put the terminal size of the IPv4 table at no
worse than the 6M to 8M range... about 20 times larger than it is now
and well inside what the manufacturers were capable of building two
years ago.

While the BGP table size is currently compounding at about 25% per
year, that can't actually continue forever. It levels off somewhere
and that somewhere is well short of the theoretical maximum number of
/24's possible to express in a routing table.


> The reality is that is massively unrealistic and the combination of
> large provider aggregates (2011-3) and other constraints (there
> aren't 2^48 end-sites to give /48s to in reality), etc. will prevent us
> from getting anywhere near [2^48 IPv6 routes in the BGP table].

Indeed. The worst-case demand for global routes in the next 50 years
is only around 2^35 routes.

Back-pressure from the /24 barrier in IPv4 prevents this in IPv4 --
you may want a route but others will want a route more than you do,
driving the price of a /24 out of the range acceptable for your use.
Joe's Pizza, for example, won't spring for the at least $1000 a /24
will take.

In IPv6 the back-pressure is at the /48 barrier. Joe goes to ARIN as
part of a pizza consortium to get a /40 and then they all split it up
with individual /48's at around $50 each and a buck a year.

While a cost effective router can be built to handle 8M routes, no one
has figured out how to build the same router that can handle 4,000
times as many and are not expected to do so with BGP.



>> For that reason, I SUPPORT your suggestion.

> Excellent. The good news is that it's useful for both purposes.


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 info at arin.net  Tue Aug 23 14:46:50 2011
From: info at arin.net (ARIN)
Date: Tue, 23 Aug 2011 14:46:50 -0400
Subject: [arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIR transfers
Message-ID: <4E53F59A.4010803@arin.net>

ARIN-prop-156 Update 8.3 to allow inter-RIR transfers

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

The ARIN Advisory Council (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.

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.

Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html

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

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

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)

## * ##

ARIN-prop-156 Update 8.3 to allow inter-RIR transfers

Proposal Originator: Scott Leibrand

Date: 23 August 2011

Proposal type: Modify

Policy term: Permanent

Policy statement:

8.3. Transfers to Specified Recipients

In addition to transfers under section 8.2, IPv4 number resources may
be released to ARIN by the authorized resource holder, in whole or in
part, for transfer:

+ under RSA, to specified organizational recipient(s) within the ARIN
region that can demonstrate the need for such resources, in the exact
amount which they can justify under current ARIN policies.

+ to another RIR, for transfer to a specified recipient in that RIR's
service region who demonstrates plans to deploy the resources for the
justified purpose within 3 months, as long as the request meets the
policy requirements of both RIRs, and the recipient (and any
organizations to which they have transferred or reassigned space) can
show efficient utilization of all prior allocations, assignments, and
transfers according to the current policy requirements of both RIRs.


Rationale:

A number of RIRs already allow IPv4 address transfers within their
service regions.  Given that IPv4 address demand is concentrated in
certain rapidly growing regions,  whereas IPv4 addresses that can be
made available to supply that demand are concentrated in regions with
more historical IPv4 deployment, it would be most efficient for
addresses to be transferred from regions with more supply to regions
with more demand.  If this is not allowed, prices for IPv4 addresses
in high-demand regions will be higher, raising overall costs,
encouraging address holders to transfer addresses outside the RIR
system, and/or encouraging large corporations to acquire addresses in
regions with more supply and then use them in regions with more
demand.  It would be better for the overall Internet industry to allow
inter-RIR transfers to organizations with demonstrated need for
addressing for immediate deployment needs.

This policy text would be intended to replace draft policy 2011-1 ARIN
Inter-RIR Transfers.

Timetable for implementation:  Immediate



From mike at nationwideinc.com  Tue Aug 23 15:07:32 2011
From: mike at nationwideinc.com (Mike Burns)
Date: Tue, 23 Aug 2011 15:07:32 -0400
Subject: [arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIR
	transfers
References: <4E53F59A.4010803@arin.net>
Message-ID: <667141AF2AE74F33878F2A368C40B22B@mike>

Support, but I would support more with a 12-month justification and it would 
be better with no justification requirement at all.
This change will allow some Asian companies to participate in legitimate 
transfers with Whois updates, who would otherwise have to take the risks of 
an unbooked sale.
Would this policy be consistent with the ideas about regional registries 
that was discussed on the list earlier in reference to ICP-2?
Is this change in 8.3 an endrun around the concept of regionality?

Regards,

Mike Burns

----- Original Message ----- 
From: "ARIN" <info at arin.net>
To: <arin-ppml at arin.net>
Sent: Tuesday, August 23, 2011 2:46 PM
Subject: [arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIR transfers


> ARIN-prop-156 Update 8.3 to allow inter-RIR transfers
>
> ARIN received the following policy proposal and is posting it to the
> Public Policy Mailing List (PPML) in accordance with the Policy
> Development Process.
>
> The ARIN Advisory Council (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.
>
> 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.
>
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/policy/proposals/index.html
>
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
>
> Mailing list subscription information can be found
> at: https://www.arin.net/mailing_lists/
>
> Regards,
>
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
>
> ## * ##
>
> ARIN-prop-156 Update 8.3 to allow inter-RIR transfers
>
> Proposal Originator: Scott Leibrand
>
> Date: 23 August 2011
>
> Proposal type: Modify
>
> Policy term: Permanent
>
> Policy statement:
>
> 8.3. Transfers to Specified Recipients
>
> In addition to transfers under section 8.2, IPv4 number resources may
> be released to ARIN by the authorized resource holder, in whole or in
> part, for transfer:
>
> + under RSA, to specified organizational recipient(s) within the ARIN
> region that can demonstrate the need for such resources, in the exact
> amount which they can justify under current ARIN policies.
>
> + to another RIR, for transfer to a specified recipient in that RIR's
> service region who demonstrates plans to deploy the resources for the
> justified purpose within 3 months, as long as the request meets the
> policy requirements of both RIRs, and the recipient (and any
> organizations to which they have transferred or reassigned space) can
> show efficient utilization of all prior allocations, assignments, and
> transfers according to the current policy requirements of both RIRs.
>
>
> Rationale:
>
> A number of RIRs already allow IPv4 address transfers within their
> service regions.  Given that IPv4 address demand is concentrated in
> certain rapidly growing regions,  whereas IPv4 addresses that can be
> made available to supply that demand are concentrated in regions with
> more historical IPv4 deployment, it would be most efficient for
> addresses to be transferred from regions with more supply to regions
> with more demand.  If this is not allowed, prices for IPv4 addresses
> in high-demand regions will be higher, raising overall costs,
> encouraging address holders to transfer addresses outside the RIR
> system, and/or encouraging large corporations to acquire addresses in
> regions with more supply and then use them in regions with more
> demand.  It would be better for the overall Internet industry to allow
> inter-RIR transfers to organizations with demonstrated need for
> addressing for immediate deployment needs.
>
> This policy text would be intended to replace draft policy 2011-1 ARIN
> Inter-RIR Transfers.
>
> Timetable for implementation:  Immediate
>
> _______________________________________________
> 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 randy.whitney at verizon.com  Tue Aug 23 16:09:28 2011
From: randy.whitney at verizon.com (Randy Whitney)
Date: Tue, 23 Aug 2011 16:09:28 -0400
Subject: [arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIR
	transfers
In-Reply-To: <4E53F59A.4010803@arin.net>
References: <4E53F59A.4010803@arin.net>
Message-ID: <4E5408F8.9080401@verizon.com>

On 8/23/2011 2:46 PM, ARIN wrote:
> ARIN-prop-156 Update 8.3 to allow inter-RIR transfers
>
> ## * ##
>
> ARIN-prop-156 Update 8.3 to allow inter-RIR transfers
>
> Proposal Originator: Scott Leibrand
>
> Date: 23 August 2011
>
> Proposal type: Modify
>
> Policy term: Permanent
>
> Policy statement:
>
> 8.3. Transfers to Specified Recipients
>
> In addition to transfers under section 8.2, IPv4 number resources may
> be released to ARIN by the authorized resource holder, in whole or in
> part, for transfer:
>
> + under RSA, to specified organizational recipient(s) within the ARIN
> region that can demonstrate the need for such resources, in the exact
> amount which they can justify under current ARIN policies.

I agree with this point.

> + to another RIR, for transfer to a specified recipient in that RIR's
> service region who demonstrates plans to deploy the resources for the
> justified purpose within 3 months, as long as the request meets the
> policy requirements of both RIRs,

Perhaps I am just confused. If it is going to _another_ RIR, why does it
matter if it meets ARIN's policy requirements? How would you even apply
ARIN's Policies in this case?

> and the recipient (and any
> organizations to which they have transferred or reassigned space) can
> show efficient utilization of all prior allocations, assignments, and
> transfers according to the current policy requirements of both RIRs.

Similar to my previous point: if it is going to be transferred to
another RIR, then this statement either:
A/ Makes no sense, assuming recipient is not an ARIN member, or
B/ Could be construed as ARIN attempting to prevent the transfer or
otherwise interfere with another RIR's transfer approval process, since
the space is being transferred AWAY from the ARIN region.

If the wording was changed to "the destination RIR" I would support this
part of the extension as well.

> Rationale:
>
> A number of RIRs already allow IPv4 address transfers within their
> service regions.  Given that IPv4 address demand is concentrated in
> certain rapidly growing regions,  whereas IPv4 addresses that can be
> made available to supply that demand are concentrated in regions with
> more historical IPv4 deployment, it would be most efficient for
> addresses to be transferred from regions with more supply to regions
> with more demand.  If this is not allowed, prices for IPv4 addresses
> in high-demand regions will be higher, raising overall costs,
> encouraging address holders to transfer addresses outside the RIR
> system, and/or encouraging large corporations to acquire addresses in
> regions with more supply and then use them in regions with more
> demand.  It would be better for the overall Internet industry to allow
> inter-RIR transfers to organizations with demonstrated need for
> addressing for immediate deployment needs.

I agree with the Rationale, although there is no toothy way to enforce
RIR boundaries on Assigned Space, and large corporations would
potentially distribute their space anyhow, in some cases for valid
operational reasons.

>
> This policy text would be intended to replace draft policy 2011-1 ARIN
> Inter-RIR Transfers.
>
> Timetable for implementation:  Immediate
>

Regards,
Randy.



From pwilson at apnic.net  Tue Aug 23 17:25:39 2011
From: pwilson at apnic.net (Paul Wilson)
Date: Wed, 24 Aug 2011 07:25:39 +1000
Subject: [arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIR
	transfers
In-Reply-To: <4E53F59A.4010803@arin.net>
References: <4E53F59A.4010803@arin.net>
Message-ID: <D4C8DBC7-87B4-42E2-9CDB-836A8F4E6454@apnic.net>

I have some practical questions about this policy proposal.  

Is it proposed that ARIN staff would conduct a full need-based assessment of the each recipient, even in another region, including examination of all prior allocations?  

Has there been any consideration of the cost and practicality of this approach?  

Is it possible that a recipient would be asked to pay ARIN to cover the cost of this service?  

Would a registration services agreement be required with ARIN?


Thanks,

Paul Wilson.



On 24/08/2011, at 4:46 AM, ARIN wrote:

> ARIN-prop-156 Update 8.3 to allow inter-RIR transfers
> 
> ARIN received the following policy proposal and is posting it to the
> Public Policy Mailing List (PPML) in accordance with the Policy
> Development Process.
> 
> The ARIN Advisory Council (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.
> 
> 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.
> 
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/policy/proposals/index.html
> 
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
> 
> Mailing list subscription information can be found
> at: https://www.arin.net/mailing_lists/
> 
> Regards,
> 
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
> 
> ## * ##
> 
> ARIN-prop-156 Update 8.3 to allow inter-RIR transfers
> 
> Proposal Originator: Scott Leibrand
> 
> Date: 23 August 2011
> 
> Proposal type: Modify
> 
> Policy term: Permanent
> 
> Policy statement:
> 
> 8.3. Transfers to Specified Recipients
> 
> In addition to transfers under section 8.2, IPv4 number resources may
> be released to ARIN by the authorized resource holder, in whole or in
> part, for transfer:
> 
> + under RSA, to specified organizational recipient(s) within the ARIN
> region that can demonstrate the need for such resources, in the exact
> amount which they can justify under current ARIN policies.
> 
> + to another RIR, for transfer to a specified recipient in that RIR's
> service region who demonstrates plans to deploy the resources for the
> justified purpose within 3 months, as long as the request meets the
> policy requirements of both RIRs, and the recipient (and any
> organizations to which they have transferred or reassigned space) can
> show efficient utilization of all prior allocations, assignments, and
> transfers according to the current policy requirements of both RIRs.
> 
> 
> Rationale:
> 
> A number of RIRs already allow IPv4 address transfers within their
> service regions.  Given that IPv4 address demand is concentrated in
> certain rapidly growing regions,  whereas IPv4 addresses that can be
> made available to supply that demand are concentrated in regions with
> more historical IPv4 deployment, it would be most efficient for
> addresses to be transferred from regions with more supply to regions
> with more demand.  If this is not allowed, prices for IPv4 addresses
> in high-demand regions will be higher, raising overall costs,
> encouraging address holders to transfer addresses outside the RIR
> system, and/or encouraging large corporations to acquire addresses in
> regions with more supply and then use them in regions with more
> demand.  It would be better for the overall Internet industry to allow
> inter-RIR transfers to organizations with demonstrated need for
> addressing for immediate deployment needs.
> 
> This policy text would be intended to replace draft policy 2011-1 ARIN
> Inter-RIR Transfers.
> 
> Timetable for implementation:  Immediate
> 
> _______________________________________________
> 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/pkcs7-signature
Size: 1906 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110824/d53fb8b3/attachment.p7s>

From bill at herrin.us  Tue Aug 23 17:38:44 2011
From: bill at herrin.us (William Herrin)
Date: Tue, 23 Aug 2011 17:38:44 -0400
Subject: [arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIR
	transfers
In-Reply-To: <4E5408F8.9080401@verizon.com>
References: <4E53F59A.4010803@arin.net> <4E5408F8.9080401@verizon.com>
Message-ID: <CAP-guGXO3DHLN2cjuVmmFG6p-PBxH1BW7x+-N+MX08oR_wbk5A@mail.gmail.com>

Hi Randy,

On Tue, Aug 23, 2011 at 4:09 PM, Randy Whitney
<randy.whitney at verizon.com> wrote:
>> + to another RIR, for transfer to a specified recipient in that RIR's
>> service region who demonstrates plans to deploy the resources for the
>> justified purpose within 3 months, as long as the request meets the
>> policy requirements of both RIRs,
>
> Perhaps I am just confused. If it is going to _another_ RIR, why does it
> matter if it meets ARIN's policy requirements?

Because our policies define who's qualified to receive our addresses
and to the extent that our policies are more restrictive than those in
the receiving region, the recipient must meet our requirements before
the addresses can leave our control.


> How would you even apply
> ARIN's Policies in this case?

The exact same way we apply them to folks in the ARIN region.
Templates. Resource reviews. Registration fees. Sometimes audits.


>> and the recipient (and any
>> organizations to which they have transferred or reassigned space) can
>> show efficient utilization of all prior allocations, assignments, and
>> transfers according to the current policy requirements of both RIRs.
>
> Similar to my previous point: if it is going to be transferred to
> another RIR, then this statement either:
> A/ Makes no sense, assuming recipient is not an ARIN member, or
> B/ Could be construed as ARIN attempting to prevent the transfer or
> otherwise interfere with another RIR's transfer approval process, since
> the space is being transferred AWAY from the ARIN region.

If you want to acquire addresses from your region, you meet your
region's policies. If you want them from ARIN's region, you meet our
policies too.

What's the alternative? ARIN-region and out-region registrants would
be on unequal footing meeting the qualifications to receive an address
transfer from an ARIN-region registrant, potentially with ARIN-region
registrants having to meet a stricter standard.

I'm not sure what's confusing about that or how applying our policies
while the addresses are still our responsibility could _reasonably_ be
construed as interference.



On Tue, Aug 23, 2011 at 5:25 PM, Paul Wilson <pwilson at apnic.net> wrote:
> Is it proposed that ARIN staff would conduct a full
> need-based assessment of the each recipient, even
> in another region, including examination of all prior
> allocations?

Hi Paul,

If that's what ARIN region policies call for with address transfers.
Why would we allow other regions to port out our scarce addresses
using a less stringent standard than we apply to ourselves?


> Has there been any consideration of the cost
> and practicality of this approach?
> Is it possible that a recipient would be asked to
>pay ARIN to cover the cost of this service?

I should hope so, but fees aren't determined by the policy community.

> Would a registration services agreement be required with ARIN?

I would expect so, although it would become moot once the transfer was complete.

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  Tue Aug 23 18:33:02 2011
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Tue, 23 Aug 2011 15:33:02 -0700
Subject: [arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIR
	transfers
In-Reply-To: <D4C8DBC7-87B4-42E2-9CDB-836A8F4E6454@apnic.net>
References: <4E53F59A.4010803@arin.net>
	<D4C8DBC7-87B4-42E2-9CDB-836A8F4E6454@apnic.net>
Message-ID: <CAGkMwz7BWOGdM+s4-9odgrMLj+eCO9M2vFq7PTwq1pdhA8JMwA@mail.gmail.com>

On Tue, Aug 23, 2011 at 2:25 PM, Paul Wilson <pwilson at apnic.net> wrote:
> I have some practical questions about this policy proposal.

Certainly.  Many of those will be better answered by ARIN staff as
they do their Clarity and Understanding and later a full Staff
Assessment on the proposal, but I'll answer from an
intent-of-the-author perspective.

> Is it proposed that ARIN staff would conduct a full need-based assessment of the each recipient, even in another region, including examination of all prior allocations?

It is proposed that a needs assessment be performed for each request.
Whether that is performed by ARIN, by the recipient RIR, or some
combination of the two will be up to the RIRs to decide.  I would hope
that they would make use of existing documentation held by the
recipient RIR to minimize any duplication of effort.

> Has there been any consideration of the cost and practicality of this approach?

At this point my main consideration is whether we can figure out a way
to allow inter-RIR transfers at all.  If ARIN were to pass draft
policy 2011-1 and APNIC were to adopt a compatible needs-based
transfer policy, that would be one avenue.  But if not, then an
approach like the one proposed here seems to be the only way (within
the existing RIR system) to allow transfers from ARIN registrants to
members of the other RIRs with the highest demand.  I'm not sure I
like all the hoops I put in the policy, but they seem necessary in
light of the strong consensus in the ARIN region in favor of continued
needs-based allocation.

I trust that ARIN will work with any recipient RIRs to implement this
policy in the most cost-effective and practical way possible in light
of those requirements.

> Is it possible that a recipient would be asked to pay ARIN to cover the cost of this service?

For transfers within the ARIN region, I believe ARIN charges a
transfer fee.  They could choose to apply that same fee to transfers
leaving the region as well.

> Would a registration services agreement be required with ARIN?

This is probably a question for ARIN staff or counsel.  My
understanding is that an RSA is required on the recipient of 8.3
transfers today, but that they have recently updated procedures to
allow for an organization to release space for transfer without
signing an RSA.

My intent would be that an organization in another RIR's service
region receiving space via transfer under this policy would need to
have a registration or membership agreement with that RIR per that
RIR's policies and procedures, but not with ARIN.

-Scott

> On 24/08/2011, at 4:46 AM, ARIN wrote:
>
>> ARIN-prop-156 Update 8.3 to allow inter-RIR transfers
>>
>> ARIN received the following policy proposal and is posting it to the
>> Public Policy Mailing List (PPML) in accordance with the Policy
>> Development Process.
>>
>> The ARIN Advisory Council (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.
>>
>> 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.
>>
>> Draft Policies and Proposals under discussion can be found at:
>> https://www.arin.net/policy/proposals/index.html
>>
>> The ARIN Policy Development Process can be found at:
>> https://www.arin.net/policy/pdp.html
>>
>> Mailing list subscription information can be found
>> at: https://www.arin.net/mailing_lists/
>>
>> Regards,
>>
>> Communications and Member Services
>> American Registry for Internet Numbers (ARIN)
>>
>> ## * ##
>>
>> ARIN-prop-156 Update 8.3 to allow inter-RIR transfers
>>
>> Proposal Originator: Scott Leibrand
>>
>> Date: 23 August 2011
>>
>> Proposal type: Modify
>>
>> Policy term: Permanent
>>
>> Policy statement:
>>
>> 8.3. Transfers to Specified Recipients
>>
>> In addition to transfers under section 8.2, IPv4 number resources may
>> be released to ARIN by the authorized resource holder, in whole or in
>> part, for transfer:
>>
>> + under RSA, to specified organizational recipient(s) within the ARIN
>> region that can demonstrate the need for such resources, in the exact
>> amount which they can justify under current ARIN policies.
>>
>> + to another RIR, for transfer to a specified recipient in that RIR's
>> service region who demonstrates plans to deploy the resources for the
>> justified purpose within 3 months, as long as the request meets the
>> policy requirements of both RIRs, and the recipient (and any
>> organizations to which they have transferred or reassigned space) can
>> show efficient utilization of all prior allocations, assignments, and
>> transfers according to the current policy requirements of both RIRs.
>>
>>
>> Rationale:
>>
>> A number of RIRs already allow IPv4 address transfers within their
>> service regions. ?Given that IPv4 address demand is concentrated in
>> certain rapidly growing regions, ?whereas IPv4 addresses that can be
>> made available to supply that demand are concentrated in regions with
>> more historical IPv4 deployment, it would be most efficient for
>> addresses to be transferred from regions with more supply to regions
>> with more demand. ?If this is not allowed, prices for IPv4 addresses
>> in high-demand regions will be higher, raising overall costs,
>> encouraging address holders to transfer addresses outside the RIR
>> system, and/or encouraging large corporations to acquire addresses in
>> regions with more supply and then use them in regions with more
>> demand. ?It would be better for the overall Internet industry to allow
>> inter-RIR transfers to organizations with demonstrated need for
>> addressing for immediate deployment needs.
>>
>> This policy text would be intended to replace draft policy 2011-1 ARIN
>> Inter-RIR Transfers.
>>
>> Timetable for implementation: ?Immediate
>>
>> _______________________________________________
>> 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 randy.whitney at verizon.com  Tue Aug 23 19:21:53 2011
From: randy.whitney at verizon.com (Randy Whitney)
Date: Tue, 23 Aug 2011 19:21:53 -0400
Subject: [arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIR
	transfers
In-Reply-To: <CAP-guGXO3DHLN2cjuVmmFG6p-PBxH1BW7x+-N+MX08oR_wbk5A@mail.gmail.com>
References: <4E53F59A.4010803@arin.net> <4E5408F8.9080401@verizon.com>
	<CAP-guGXO3DHLN2cjuVmmFG6p-PBxH1BW7x+-N+MX08oR_wbk5A@mail.gmail.com>
Message-ID: <4E543611.9020505@verizon.com>

Hi William,

In general, if this proposal remains unaltered than I remain opposed to
the proposal. Specific points inline. I will not further the debate
after this.

On 8/23/2011 5:38 PM, William Herrin wrote:
> Hi Randy,
>
> On Tue, Aug 23, 2011 at 4:09 PM, Randy Whitney
> <randy.whitney at verizon.com>  wrote:
>>> + to another RIR, for transfer to a specified recipient in that RIR's
>>> service region who demonstrates plans to deploy the resources for the
>>> justified purpose within 3 months, as long as the request meets the
>>> policy requirements of both RIRs,
>>
>> Perhaps I am just confused. If it is going to _another_ RIR, why does it
>> matter if it meets ARIN's policy requirements?
>
> Because our policies define who's qualified to receive our addresses
> and to the extent that our policies are more restrictive than those in
> the receiving region, the recipient must meet our requirements before
> the addresses can leave our control.

First of all, this is a transfer to another Region which has
region-specific needs different in many cases from those in the ARIN
region. This specific sticking point also prevented APNIC from reaching
consensus and passing the corresponding policy due to numerous
objections from the community. Removing it allowed the policy to pass.
Look at this from the perspective on the party willing to transfer this
space in the proper way. With such a sizable amount of overhead, it
would be easier to allow said partner to "borrow" the space than than to
try to do things properly.

>
>> How would you even apply
>> ARIN's Policies in this case?
>
> The exact same way we apply them to folks in the ARIN region.
> Templates. Resource reviews. Registration fees. Sometimes audits.

Offeree is in effect transferring control away from ARIN to another RIR.
Your wording implies that ARIN places no trust in other RIRs to handle
and assign their own resources effectively, which is also the reason why
policies often result in 4+1/ARIN vs other RIRs. Adding a transfer fee
is acceptable. Attempting to enforcing ARIN's policy on another RIRs
registered organization is not realistic.

>>> and the recipient (and any
>>> organizations to which they have transferred or reassigned space) can
>>> show efficient utilization of all prior allocations, assignments, and
>>> transfers according to the current policy requirements of both RIRs.
>>
>> Similar to my previous point: if it is going to be transferred to
>> another RIR, then this statement either:
>> A/ Makes no sense, assuming recipient is not an ARIN member, or
>> B/ Could be construed as ARIN attempting to prevent the transfer or
>> otherwise interfere with another RIR's transfer approval process, since
>> the space is being transferred AWAY from the ARIN region.
>
> If you want to acquire addresses from your region, you meet your
> region's policies. If you want them from ARIN's region, you meet our
> policies too.

IMO, transfers are supposed to be about cooperation and trust. Enforcing
ARINs rules on other regions shows neither.

> What's the alternative? ARIN-region and out-region registrants would
> be on unequal footing meeting the qualifications to receive an address
> transfer from an ARIN-region registrant, potentially with ARIN-region
> registrants having to meet a stricter standard.

 From the perspective of Provider X with space he wishes to share with a
partner in African, Asia-Pac, Europe, or Latin America:

"Different Region, Different Needs. My ARIN-justified Space, My desire
to transfer it to a more needy partner in another RIR. Why should ARIN's
rules apply to RIR-X where the potential need to establish potential
address pools on more than two national boundaries exists? Aren't
RIR-X's allocation rules sufficient to assure that my resources are
properly and efficiently utilized? I'm offering to transfer the space to
my preferred partner in RIR-X, not add it to an address pool that can be
potentially assigned to my US competitor. In this case, I'd rather sit
on this justified IP space than to give it back to ARIN."

> I'm not sure what's confusing about that or how applying our policies
> while the addresses are still our responsibility could _reasonably_ be
> construed as interference.

See previous case.

> On Tue, Aug 23, 2011 at 5:25 PM, Paul Wilson<pwilson at apnic.net>  wrote:
>> Is it proposed that ARIN staff would conduct a full
>> need-based assessment of the each recipient, even
>> in another region, including examination of all prior
>> allocations?
>
> Hi Paul,
>
> If that's what ARIN region policies call for with address transfers.
> Why would we allow other regions to port out our scarce addresses
> using a less stringent standard than we apply to ourselves?
>
>
>> Has there been any consideration of the cost
>> and practicality of this approach?
>> Is it possible that a recipient would be asked to
>> pay ARIN to cover the cost of this service?
>
> I should hope so, but fees aren't determined by the policy community.
>
>> Would a registration services agreement be required with ARIN?
>
> I would expect so, although it would become moot once the transfer was complete.
>
> Regards,
> Bill Herrin

Since you chose to _also_ include your response to Paul in your
follow-up to my objection. This is perfect case-in-point: the standard
protectionist stance emphasizing that you personally do not trust other
RIRs to apply a fair determination of need to the transferred IP space.
Certainly not in the spirit of cooperation with other RIRs for the
greater good in sharing of sparse resources. But this is, of course,
just my opinion.

Regards,
Randy.



From scottleibrand at gmail.com  Tue Aug 23 20:30:09 2011
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Tue, 23 Aug 2011 17:30:09 -0700
Subject: [arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIR
	transfers
In-Reply-To: <4E543611.9020505@verizon.com>
References: <4E53F59A.4010803@arin.net> <4E5408F8.9080401@verizon.com>
	<CAP-guGXO3DHLN2cjuVmmFG6p-PBxH1BW7x+-N+MX08oR_wbk5A@mail.gmail.com>
	<4E543611.9020505@verizon.com>
Message-ID: <CAGkMwz4P+v5MtyFFBcr+q1YT3kjUWvAXXUPwueLcX9GON6DvyQ@mail.gmail.com>

On Tue, Aug 23, 2011 at 4:21 PM, Randy Whitney
<randy.whitney at verizon.com> wrote:
> Hi William,
>
> In general, if this proposal remains unaltered than I remain opposed to
> the proposal. Specific points inline. I will not further the debate
> after this.

Randy,

I just want to point out that at the moment, we are in a state of
complete autarky: no transfers between RIR regions are allowed (at
least within the RIR system).  The current wording of draft policy
ARIN-2011-1 would allow transfers only to regions whose transfer
policies are needs-based and compatible with ours, which at the moment
would exclude APNIC, where the biggest demand is.  This proposal would
at least allow transfers to any region willing to accept them, which
is more liberal than any other policy proposal I've seen so far.

So if you (and anyone else) dislike this proposal because it doesn't
go far enough, I would encourage you to suggest specific changes to
improve it, and/or to make an alternative proposal that you feel would
be better (and preferably that also has a chance of gaining
consensus).  But remember that an all-or-nothing stance quite often
gets you nothing.  That's why I'm taking an incremental approach here:
to help move us toward consensus on policy that is better than what we
have now.

> On 8/23/2011 5:38 PM, William Herrin wrote:
>>
>> On Tue, Aug 23, 2011 at 5:25 PM, Paul Wilson<pwilson at apnic.net> ?wrote:
>>>
>>> Is it proposed that ARIN staff would conduct a full
>>> need-based assessment of the each recipient, even
>>> in another region, including examination of all prior
>>> allocations?
>>
>> Hi Paul,
>>
>> If that's what ARIN region policies call for with address transfers.
>> Why would we allow other regions to port out our scarce addresses
>> using a less stringent standard than we apply to ourselves?
>>
>>
>>> Has there been any consideration of the cost
>>> and practicality of this approach?
>>> Is it possible that a recipient would be asked to
>>> pay ARIN to cover the cost of this service?
>>
>> I should hope so, but fees aren't determined by the policy community.
>>
>>> Would a registration services agreement be required with ARIN?
>>
>> I would expect so, although it would become moot once the transfer was
>> complete.
>>
>> Regards,
>> Bill Herrin
>
> Since you chose to _also_ include your response to Paul in your
> follow-up to my objection. This is perfect case-in-point: the standard
> protectionist stance emphasizing that you personally do not trust other
> RIRs to apply a fair determination of need to the transferred IP space.
> Certainly not in the spirit of cooperation with other RIRs for the
> greater good in sharing of sparse resources. But this is, of course,
> just my opinion.

FWIW, I personally don't support protectionism of any kind.  But to
extend the analogy, in this case I'm trying to pass policy analogous
to a trade agreement, and AFAICT the best way to do that is to
directly address some of the fears and concerns people have expressed
by dealing with them directly in ARIN policy.  Even the most liberal
"free trade" agreements usually end up with protections to address
various groups' concerns, so I'm not surprised that we have to do the
same thing to get consensus around inter-RIR transfer policy.

-Scott


From bill at herrin.us  Tue Aug 23 20:41:56 2011
From: bill at herrin.us (William Herrin)
Date: Tue, 23 Aug 2011 20:41:56 -0400
Subject: [arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIR
	transfers
In-Reply-To: <4E543611.9020505@verizon.com>
References: <4E53F59A.4010803@arin.net> <4E5408F8.9080401@verizon.com>
	<CAP-guGXO3DHLN2cjuVmmFG6p-PBxH1BW7x+-N+MX08oR_wbk5A@mail.gmail.com>
	<4E543611.9020505@verizon.com>
Message-ID: <CAP-guGUnDW_9+F2S3UCEkgn-Jkzb-rXRN4i6G=2b-DQ9Pu9yYA@mail.gmail.com>

On Tue, Aug 23, 2011 at 7:21 PM, Randy Whitney
<randy.whitney at verizon.com> wrote:
> Your wording implies that ARIN places no trust in other RIRs to handle
> and assign their own resources effectively

Randy,

It's not about trust, it's about fairness and mutual acceptance.

There are only so many IPv4 addresses to go around and simple fairness
demands that a registrant from ARIN's region have at least as ready
access to ARIN-managed addresses as a registrant from another region.
Fairness also demands that where another region has access to
ARIN-managed addresses, ARIN registrants have comparable access to
their addresses.

The folks in the ARIN region and the folks in the APNIC region don't
agree about what the criteria for receiving IP addresses should be.
Nor is that a recent thing: regional differences in determining the
best way to manage IP addresses was the original, core basis for
APNIC's creation.

So, if APNIC is going to have access to ARIN IP addresses, we'll need
a path that neither breaches basic fairness nor depends on both
regions agreeing on the exact criteria for allocating addresses.


This is such a path. We apply our policies on entry and exit, they
apply their policies on entry and exit, we both apply them with an
equal hand to both in and out-region registrants and we don't have to
agree. And no matter what the exact policies are, the registrant from
out region is never more advantaged in his access to the addresses
than the registrant from the home region.


Let me put it another way: free trade doesn't mean you can waltz in to
my country and sell anything you please however you please. It just
means that the law and regulation I apply to your activity is *the
same* as the law and regulation I apply to my own.

Protectionism only arises when I try to balance the scales of some
perceived wrong by insisting that because you're from another country
you have to follow *different* sales rules for your products than my
folks at home, typically something like paying a tariff to balance
your "unreasonable" low wages.

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  Tue Aug 23 20:48:12 2011
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Tue, 23 Aug 2011 17:48:12 -0700
Subject: [arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIR
	transfers
In-Reply-To: <667141AF2AE74F33878F2A368C40B22B@mike>
References: <4E53F59A.4010803@arin.net> <667141AF2AE74F33878F2A368C40B22B@mike>
Message-ID: <CAGkMwz5i03xw-nNsyrwBKUirCDws9bkPDxT-Q5UOMLYRQPfY_A@mail.gmail.com>

On Tue, Aug 23, 2011 at 12:07 PM, Mike Burns <mike at nationwideinc.com> wrote:
> Support, but I would support more with a 12-month justification and it would
> be better with no justification requirement at all.

Thanks.  I'd like to hear input from more folks on what this
requirement should look like.

> This change will allow some Asian companies to participate in legitimate
> transfers with Whois updates, who would otherwise have to take the risks of
> an unbooked sale.
> Would this policy be consistent with the ideas about regional registries
> that was discussed on the list earlier in reference to ICP-2?

Yes, because we're transferring the addresses (under certain
conditions) to another RIR for them to administer in their region.

> Is this change in 8.3 an endrun around the concept of regionality?

I don't believe so.

-Scott


> ----- Original Message ----- From: "ARIN" <info at arin.net>
> To: <arin-ppml at arin.net>
> Sent: Tuesday, August 23, 2011 2:46 PM
> Subject: [arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIR transfers
>
>
>> ARIN-prop-156 Update 8.3 to allow inter-RIR transfers
>>
>> ARIN received the following policy proposal and is posting it to the
>> Public Policy Mailing List (PPML) in accordance with the Policy
>> Development Process.
>>
>> The ARIN Advisory Council (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.
>>
>> 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.
>>
>> Draft Policies and Proposals under discussion can be found at:
>> https://www.arin.net/policy/proposals/index.html
>>
>> The ARIN Policy Development Process can be found at:
>> https://www.arin.net/policy/pdp.html
>>
>> Mailing list subscription information can be found
>> at: https://www.arin.net/mailing_lists/
>>
>> Regards,
>>
>> Communications and Member Services
>> American Registry for Internet Numbers (ARIN)
>>
>> ## * ##
>>
>> ARIN-prop-156 Update 8.3 to allow inter-RIR transfers
>>
>> Proposal Originator: Scott Leibrand
>>
>> Date: 23 August 2011
>>
>> Proposal type: Modify
>>
>> Policy term: Permanent
>>
>> Policy statement:
>>
>> 8.3. Transfers to Specified Recipients
>>
>> In addition to transfers under section 8.2, IPv4 number resources may
>> be released to ARIN by the authorized resource holder, in whole or in
>> part, for transfer:
>>
>> + under RSA, to specified organizational recipient(s) within the ARIN
>> region that can demonstrate the need for such resources, in the exact
>> amount which they can justify under current ARIN policies.
>>
>> + to another RIR, for transfer to a specified recipient in that RIR's
>> service region who demonstrates plans to deploy the resources for the
>> justified purpose within 3 months, as long as the request meets the
>> policy requirements of both RIRs, and the recipient (and any
>> organizations to which they have transferred or reassigned space) can
>> show efficient utilization of all prior allocations, assignments, and
>> transfers according to the current policy requirements of both RIRs.
>>
>>
>> Rationale:
>>
>> A number of RIRs already allow IPv4 address transfers within their
>> service regions. ?Given that IPv4 address demand is concentrated in
>> certain rapidly growing regions, ?whereas IPv4 addresses that can be
>> made available to supply that demand are concentrated in regions with
>> more historical IPv4 deployment, it would be most efficient for
>> addresses to be transferred from regions with more supply to regions
>> with more demand. ?If this is not allowed, prices for IPv4 addresses
>> in high-demand regions will be higher, raising overall costs,
>> encouraging address holders to transfer addresses outside the RIR
>> system, and/or encouraging large corporations to acquire addresses in
>> regions with more supply and then use them in regions with more
>> demand. ?It would be better for the overall Internet industry to allow
>> inter-RIR transfers to organizations with demonstrated need for
>> addressing for immediate deployment needs.
>>
>> This policy text would be intended to replace draft policy 2011-1 ARIN
>> Inter-RIR Transfers.
>>
>> Timetable for implementation: ?Immediate
>>
>> _______________________________________________
>> 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  Tue Aug 23 21:39:22 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 23 Aug 2011 18:39:22 -0700
Subject: [arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIR
	transfers
In-Reply-To: <4E543611.9020505@verizon.com>
References: <4E53F59A.4010803@arin.net> <4E5408F8.9080401@verizon.com>
	<CAP-guGXO3DHLN2cjuVmmFG6p-PBxH1BW7x+-N+MX08oR_wbk5A@mail.gmail.com>
	<4E543611.9020505@verizon.com>
Message-ID: <FECE33CC-6948-477E-8835-5E213E3B27A2@delong.com>

> 
> Offeree is in effect transferring control away from ARIN to another RIR.
> Your wording implies that ARIN places no trust in other RIRs to handle
> and assign their own resources effectively, which is also the reason why
> policies often result in 4+1/ARIN vs other RIRs. Adding a transfer fee
> is acceptable. Attempting to enforcing ARIN's policy on another RIRs
> registered organization is not realistic.
> 

I'll point out that in this case, it is quite literally a 4+1/APNIC vs other RIRs
where APNIC is the only RIR that abandoned needs basis. APNIC is also
considering Prop 096 at Busan which, if it reaches consensus, would restore
needs basis to the APNIC region.

Frankly, I view this as an attempt (however ill advised it might be) to bend
over backwards and facilitate transfers to the APNIC region in spite of the
fact that they have chosen to abandon needs-basis in their transfer policy.

I think it would be much better to pass 2011-1 even with the flaws that it
still contains and then leave it in the hands of the APNIC community to
determine whether they want to restore needs basis in order to be able
to transfer space in from other regions or not.

I very much hope that APNIC reaches consensus on Prop 096 and I encourage
anyone who is interested in policy in the APNIC region to join their PD WG
mailing list and support Proposal 096.

>>>> and the recipient (and any
>>>> organizations to which they have transferred or reassigned space) can
>>>> show efficient utilization of all prior allocations, assignments, and
>>>> transfers according to the current policy requirements of both RIRs.
>>> 
>>> Similar to my previous point: if it is going to be transferred to
>>> another RIR, then this statement either:
>>> A/ Makes no sense, assuming recipient is not an ARIN member, or
>>> B/ Could be construed as ARIN attempting to prevent the transfer or
>>> otherwise interfere with another RIR's transfer approval process, since
>>> the space is being transferred AWAY from the ARIN region.
>> 
>> If you want to acquire addresses from your region, you meet your
>> region's policies. If you want them from ARIN's region, you meet our
>> policies too.
> 
> IMO, transfers are supposed to be about cooperation and trust. Enforcing
> ARINs rules on other regions shows neither.
> 

This is not enforcing ARIN's rules on another region. This is enforcing
ARIN's rules on addresses under ARIN stewardship prior to releasing
them to a point outside of ARIN's stewardship.

>> What's the alternative? ARIN-region and out-region registrants would
>> be on unequal footing meeting the qualifications to receive an address
>> transfer from an ARIN-region registrant, potentially with ARIN-region
>> registrants having to meet a stricter standard.
> 
> From the perspective of Provider X with space he wishes to share with a
> partner in African, Asia-Pac, Europe, or Latin America:
> 
> "Different Region, Different Needs. My ARIN-justified Space, My desire
> to transfer it to a more needy partner in another RIR. Why should ARIN's
> rules apply to RIR-X where the potential need to establish potential
> address pools on more than two national boundaries exists? Aren't
> RIR-X's allocation rules sufficient to assure that my resources are
> properly and efficiently utilized? I'm offering to transfer the space to
> my preferred partner in RIR-X, not add it to an address pool that can be
> potentially assigned to my US competitor. In this case, I'd rather sit
> on this justified IP space than to give it back to ARIN."
> 

This is exactly why I think 2011-1 is a better alternative. In 2011-1,
we can enable transfers to any RIR in a trusting manner so long as they
maintain a needs-basis in managing all resources, whether initial issue
or transfer. APNIC stands alone as the only RIR that is currently ineligible
to receive transfers under 2011-1.

> Since you chose to _also_ include your response to Paul in your
> follow-up to my objection. This is perfect case-in-point: the standard
> protectionist stance emphasizing that you personally do not trust other
> RIRs to apply a fair determination of need to the transferred IP space.
> Certainly not in the spirit of cooperation with other RIRs for the
> greater good in sharing of sparse resources. But this is, of course,
> just my opinion.
> 

I think the issue here is that one RIR would not apply ANY determination
of need under their policies for transferred IP space. I believe that if
APNIC chose to apply a needs-basis, we would trust them to administer
that needs-basis fairly. However, since they have stated that they will
not apply ANY needs basis, how can we trust them to apply a needs
basis fairly?

Owen



From jcurran at arin.net  Tue Aug 23 23:13:11 2011
From: jcurran at arin.net (John Curran)
Date: Wed, 24 Aug 2011 03:13:11 +0000
Subject: [arin-ppml] ARIN-prop-156 Update 8.3 to allow
	inter-RIR	transfers
In-Reply-To: <D4C8DBC7-87B4-42E2-9CDB-836A8F4E6454@apnic.net>
References: <4E53F59A.4010803@arin.net>
	<D4C8DBC7-87B4-42E2-9CDB-836A8F4E6454@apnic.net>
Message-ID: <FE675BA8-DBF9-4105-9451-6ABCDD4D5499@arin.net>

On Aug 23, 2011, at 5:25 PM, Paul Wilson wrote:

> I have some practical questions about this policy proposal.  

Hi Paul!   (Welcome to the PPML discussion)

I will attempt to answer your questions (recognizing that a 
formal staff assessment is still to be done.)

> Is it proposed that ARIN staff would conduct a full need-based assessment of the each recipient, even in another region, including examination of all prior allocations?  

This is not specified in the policy proposal as specifically being 
done by ARIN or the recipient RIR, so it could be done by either.

> Has there been any consideration of the cost and practicality of this approach?  

Not by ARIN staff (yet)

The approach is unspecified at this time, making analysis of the 
cost and practicality rather difficult.  ARIN staff will have to 
specify how it would implement the policy proposal when preparing 
the staff assessment, but at this time is it quite unclear.

> Is it possible that a recipient would be asked to pay ARIN to cover the cost of this service?  

That is definitely possible, but quite suboptimal as it would require
ARIN to routine engage in financial transactions with parties outside
the service region.

> Would a registration services agreement be required with ARIN?

ARIN provides registration services in a specific geographic region
and hence a requirement to agreements for registration services with 
parties outside the region would also be quite suboptimal.

Without additional clarity (either in the policy proposal or filled in 
during the staff assessment), it is very uncertain how proposal-16
would be implemented.  This is in contrast to draft policy 2011-1, 
which when processing transfers would simply require ARIN to confirm 
the transfer with the recipient's RIR.

/John

John Curran
President and CEO
ARIN




From mike at nationwideinc.com  Wed Aug 24 09:54:25 2011
From: mike at nationwideinc.com (Mike Burns)
Date: Wed, 24 Aug 2011 09:54:25 -0400
Subject: [arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIR
	transfers
References: <4E53F59A.4010803@arin.net><667141AF2AE74F33878F2A368C40B22B@mike>
	<CAGkMwz5i03xw-nNsyrwBKUirCDws9bkPDxT-Q5UOMLYRQPfY_A@mail.gmail.com>
Message-ID: <9B7002B514644AC493E7AE344F23787A@mike>

I would like to point out that some of the comments relating to 156 involve 
issues of "fairness" in terms of applying less stringent standards to the 
proposed transfers than applied to ARIN members, and others involve issues 
of perceived ARIN bullying from its position of strength on this issue.

Both issues would dissolve, as would so many others, with the adoption of my 
proposal 151 to treat legacy and non-legacy addresses fairly by removing the 
outdated and unnecessary needs requirement on IPv4 transfers.

Given the situation, we are virtually mandating transfers (of legacy space 
at least) of address space outside the RIR system entirely.
The resultant irrelevance of Whois data will drive the acceptance of private 
registries.

In this article, 
http://techliberation.com/2011/08/15/trading-ipv4-addresses-starts-making-internet-elders-nervous/ 
,Prof. Mueller relates a conversation with the broker who handled the 
Microsoft/Nortel IPv4 sale.  That broker mentions a point which is entirely 
relevant to my proposal, which is the fact that of all the 38 (!) IP blocks 
included in the sale, not a single one had correct Whois data.

As IPv6 remains stillborn, IPv4 address values will increase.
As the values increase there will be conflict over ownership rights.
Those conflicts will be settled in court eventually, and Whois will come to 
be publicly displayed as erroneous and irrelevant.
Owners will demand a more reliable registration system to ensure their 
rights are recognized, and network operators will feel more protected by a 
registry which backs their entries with chain-of-custody documents.

By maintaining a needs requirement for transfers, we are on the path to a 
dramatic change in Internet governance, which we can avoid by refusing to 
continue policies which work in restraint of the free trading of IPv4 
addresses.

I applaud Scott's efforts to make a bad situation a little better, but 
suggest that the problems he addresses in his rationale would be mooted by 
acceptance of Prop 151.

I guess this is a thread hijack, but there is still time for expressions of 
support for 151 as it has not been abandoned.

Regards,
Mike




----- Original Message ----- 
From: "Scott Leibrand" <scottleibrand at gmail.com>
To: "Mike Burns" <mike at nationwideinc.com>
Cc: "ARIN" <info at arin.net>; <arin-ppml at arin.net>
Sent: Tuesday, August 23, 2011 8:48 PM
Subject: Re: [arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIR 
transfers


On Tue, Aug 23, 2011 at 12:07 PM, Mike Burns <mike at nationwideinc.com> wrote:
> Support, but I would support more with a 12-month justification and it 
> would
> be better with no justification requirement at all.

Thanks.  I'd like to hear input from more folks on what this
requirement should look like.

> This change will allow some Asian companies to participate in legitimate
> transfers with Whois updates, who would otherwise have to take the risks 
> of
> an unbooked sale.
> Would this policy be consistent with the ideas about regional registries
> that was discussed on the list earlier in reference to ICP-2?

Yes, because we're transferring the addresses (under certain
conditions) to another RIR for them to administer in their region.

> Is this change in 8.3 an endrun around the concept of regionality?

I don't believe so.

-Scott


> ----- Original Message ----- From: "ARIN" <info at arin.net>
> To: <arin-ppml at arin.net>
> Sent: Tuesday, August 23, 2011 2:46 PM
> Subject: [arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIR transfers
>
>
>> ARIN-prop-156 Update 8.3 to allow inter-RIR transfers
>>
>> ARIN received the following policy proposal and is posting it to the
>> Public Policy Mailing List (PPML) in accordance with the Policy
>> Development Process.
>>
>> The ARIN Advisory Council (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.
>>
>> 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.
>>
>> Draft Policies and Proposals under discussion can be found at:
>> https://www.arin.net/policy/proposals/index.html
>>
>> The ARIN Policy Development Process can be found at:
>> https://www.arin.net/policy/pdp.html
>>
>> Mailing list subscription information can be found
>> at: https://www.arin.net/mailing_lists/
>>
>> Regards,
>>
>> Communications and Member Services
>> American Registry for Internet Numbers (ARIN)
>>
>> ## * ##
>>
>> ARIN-prop-156 Update 8.3 to allow inter-RIR transfers
>>
>> Proposal Originator: Scott Leibrand
>>
>> Date: 23 August 2011
>>
>> Proposal type: Modify
>>
>> Policy term: Permanent
>>
>> Policy statement:
>>
>> 8.3. Transfers to Specified Recipients
>>
>> In addition to transfers under section 8.2, IPv4 number resources may
>> be released to ARIN by the authorized resource holder, in whole or in
>> part, for transfer:
>>
>> + under RSA, to specified organizational recipient(s) within the ARIN
>> region that can demonstrate the need for such resources, in the exact
>> amount which they can justify under current ARIN policies.
>>
>> + to another RIR, for transfer to a specified recipient in that RIR's
>> service region who demonstrates plans to deploy the resources for the
>> justified purpose within 3 months, as long as the request meets the
>> policy requirements of both RIRs, and the recipient (and any
>> organizations to which they have transferred or reassigned space) can
>> show efficient utilization of all prior allocations, assignments, and
>> transfers according to the current policy requirements of both RIRs.
>>
>>
>> Rationale:
>>
>> A number of RIRs already allow IPv4 address transfers within their
>> service regions. Given that IPv4 address demand is concentrated in
>> certain rapidly growing regions, whereas IPv4 addresses that can be
>> made available to supply that demand are concentrated in regions with
>> more historical IPv4 deployment, it would be most efficient for
>> addresses to be transferred from regions with more supply to regions
>> with more demand. If this is not allowed, prices for IPv4 addresses
>> in high-demand regions will be higher, raising overall costs,
>> encouraging address holders to transfer addresses outside the RIR
>> system, and/or encouraging large corporations to acquire addresses in
>> regions with more supply and then use them in regions with more
>> demand. It would be better for the overall Internet industry to allow
>> inter-RIR transfers to organizations with demonstrated need for
>> addressing for immediate deployment needs.
>>
>> This policy text would be intended to replace draft policy 2011-1 ARIN
>> Inter-RIR Transfers.
>>
>> Timetable for implementation: Immediate
>>
>> _______________________________________________
>> 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 mueller at syr.edu  Wed Aug 24 10:52:49 2011
From: mueller at syr.edu (Milton L Mueller)
Date: Wed, 24 Aug 2011 10:52:49 -0400
Subject: [arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIR
 transfers
Message-ID: <75822E125BCB994F8446858C4B19F0D7175496FF7E@SUEX07-MBX-04.ad.syr.edu>

Good questions from Paul, and useful answers from John. However, one should be willing to think outside the box and raise more fundamental questions about the long-term viability of a regional IR model, as a opposed to a more integrated global one.  The issues Herrin raised about reciprocity are pertinent. It also raises questions about the wisdom of trying to retain "needs assessments" in the current environment. Many (not all) of the complications associated with inter-regional transfers would go away if we simply did away with or dramatically simplified and harmonized the concept of needs assessments. 

Milton L. Mueller
Professor, Syracuse University School of Information Studies
Internet Governance Project
http://blog.internetgovernance.org 




> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of John Curran
> Sent: Tuesday, August 23, 2011 11:13 PM
> To: Paul Wilson
> Cc: arin-ppml at arin.net List
> Subject: Re: [arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIR
> transfers
> 
> On Aug 23, 2011, at 5:25 PM, Paul Wilson wrote:
> 
> > I have some practical questions about this policy proposal.
> 
> Hi Paul!   (Welcome to the PPML discussion)
> 
> I will attempt to answer your questions (recognizing that a
> formal staff assessment is still to be done.)
> 
> > Is it proposed that ARIN staff would conduct a full need-based assessment
> of the each recipient, even in another region, including examination of all
> prior allocations?
> 
> This is not specified in the policy proposal as specifically being
> done by ARIN or the recipient RIR, so it could be done by either.
> 
> > Has there been any consideration of the cost and practicality of this
> approach?
> 
> Not by ARIN staff (yet)
> 
> The approach is unspecified at this time, making analysis of the
> cost and practicality rather difficult.  ARIN staff will have to
> specify how it would implement the policy proposal when preparing
> the staff assessment, but at this time is it quite unclear.
> 
> > Is it possible that a recipient would be asked to pay ARIN to cover the cost
> of this service?
> 
> That is definitely possible, but quite suboptimal as it would require
> ARIN to routine engage in financial transactions with parties outside
> the service region.
> 
> > Would a registration services agreement be required with ARIN?
> 
> ARIN provides registration services in a specific geographic region
> and hence a requirement to agreements for registration services with
> parties outside the region would also be quite suboptimal.
> 
> Without additional clarity (either in the policy proposal or filled in
> during the staff assessment), it is very uncertain how proposal-16
> would be implemented.  This is in contrast to draft policy 2011-1,
> which when processing transfers would simply require ARIN to confirm
> the transfer with the recipient's RIR.
> 
> /John
> 
> John Curran
> President and CEO
> ARIN
> 
> 
> _______________________________________________
> 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 jcurran at arin.net  Wed Aug 24 11:55:36 2011
From: jcurran at arin.net (John Curran)
Date: Wed, 24 Aug 2011 15:55:36 +0000
Subject: [arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIR
 transfers
In-Reply-To: <9B7002B514644AC493E7AE344F23787A@mike>
References: <4E53F59A.4010803@arin.net> <667141AF2AE74F33878F2A368C40B22B@mike>
	<CAGkMwz5i03xw-nNsyrwBKUirCDws9bkPDxT-Q5UOMLYRQPfY_A@mail.gmail.com>
	<9B7002B514644AC493E7AE344F23787A@mike>
Message-ID: <2199CE33-4170-45BF-9292-C5D0B717DA1D@arin.net>

On Aug 24, 2011, at 9:54 AM, Mike Burns wrote:

> In this article, http://techliberation.com/2011/08/15/trading-ipv4-addresses-starts-making-internet-elders-nervous/ ,Prof. Mueller relates a conversation with the broker who handled the Microsoft/Nortel IPv4 sale.  That broker mentions a point which is entirely relevant to my proposal, which is the fact that of all the 38 (!) IP blocks included in the sale, not a single one had correct Whois data.

Mike -

If that was the case, it is because of failure of the registrants to 
update their records.  I will note the ARIN community has since 
directed ARIN to send POC Update messages to all resources holders, 
and that is underway now.  We are seeing very good response rates
for updates (as high as 36% response rate) but that does not help
for legacy resources that presently have no points-of-contact with 
valid contact information.

Having correct information in the Whois database is quite straight
forward for those who wish to do so, and I encourage the community 
to adopt policies that support accurate registration data.  Only
the community can decide if it is worthwhile to set aside other 
policy goals in the pursuit of having minimal criterial for ARIN 
to process requests (such as transfers).

FYI,
/John

John Curran
President and CEO
ARIN

p.s. Regarding the rest of Prof. Mueller's assertions in the referenced
article about "ARIN being worried", "ARIN being nervous", or protecting 
its position in the current Internet number registry system, those 
assertions are factually incorrect, as ARIN is on record in a public 
letter to ICANN indicating that it would welcome participation in 
discussions of the structure of the Internet number registry system.  
<http://www.icann.org/en/correspondence/curran-to-beckstrom-02mar11-en.pdf>
Prof. Mueller was well aware of the same, as I pointed it out while 
speaking on his GIGNET panel in May on the Internet number registry 
system.  

From rudi.daniel at gmail.com  Wed Aug 24 12:15:52 2011
From: rudi.daniel at gmail.com (Rudolph Daniel)
Date: Wed, 24 Aug 2011 12:15:52 -0400
Subject: [arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIR
	transfers
Message-ID: <CA+uaoiWhc=2CvET7peawusW+LAV8zcd2yff0z0GWQ-vDMoXUXg@mail.gmail.com>

This prop-156 ..I am trying to comprehend why we would be wanting to
transfer resources from ARIN to another "RIR's  member" when RIRs have the
potential to all have slightly different transfer policies?  Or are we
asking all RIRs to consider needs based policies akin to ARIN?

Is it not more effective to deal with transfers between RIRs  and leave the
respective RIR to deal with its own members.?
RD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110824/cdad8e82/attachment.htm>

From mike at nationwideinc.com  Wed Aug 24 12:23:47 2011
From: mike at nationwideinc.com (Mike Burns)
Date: Wed, 24 Aug 2011 12:23:47 -0400
Subject: [arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIR
	transfers
References: <4E53F59A.4010803@arin.net><667141AF2AE74F33878F2A368C40B22B@mike><CAGkMwz5i03xw-nNsyrwBKUirCDws9bkPDxT-Q5UOMLYRQPfY_
	A@mail.gmail.com><9B7002B514644AC493E7AE344F23787A@mike>
	<2199CE33-4170-45BF-9292-C5D0B717DA1D@arin.net>
Message-ID: <1A7F40CE99CC4D5ABE131B756F055AB1@mike>

>Mike -

>If that was the case, it is because of failure of the registrants to
>update their records.  I will note the ARIN community has since
>directed ARIN to send POC Update messages to all resources holders,
>and that is underway now.  We are seeing very good response rates
>for updates (as high as 36% response rate) but that does not help
>for legacy resources that presently have no points-of-contact with
>valid contact information.

>Having correct information in the Whois database is quite straight
>forward for those who wish to do so, and I encourage the community
>to adopt policies that support accurate registration data.  Only
>the community can decide if it is worthwhile to set aside other
>policy goals in the pursuit of having minimal criterial for ARIN
>to process requests (such as transfers).

>FYI,
>/John

Hi John,

Yes, I agree that only the community can determine whether the continuation 
of a needs-based policy based on the stewards' goals of conservation is 
appropriate for transfers which do not involve free pool addresses.

I disagree with your depiction of the stewards' choice as whether to "set 
aside" other policy goals. The only goal relevant here is the goal of 
conservation. I don't think recognizing that the goal of conservation will 
now be met by market forces is the same as setting it aside. It's more of a 
"sunsetting" than a setting aside.

That's a minor quibble, I appreciate your statement of support for the 
community adopting policies which support accurate registration data, which 
prop-151 is designed to do, and which Scott's prop-156 is designed to do.

RFC 2050 4.1 says Regional Registries provide registration services as its 
primary function.

Let's adopt policies which support our primary function, and receive the 
attendant benefits of global comity, parity between all address holders, and 
maintenance of existing self-governance.

Regards,

Mike 



From mueller at syr.edu  Wed Aug 24 12:52:05 2011
From: mueller at syr.edu (Milton L Mueller)
Date: Wed, 24 Aug 2011 12:52:05 -0400
Subject: [arin-ppml] ARIN-prop-156 Update 8.3 to allow
	inter-RIR	transfers
In-Reply-To: <9B7002B514644AC493E7AE344F23787A@mike>
References: <4E53F59A.4010803@arin.net><667141AF2AE74F33878F2A368C40B22B@mike>
	<CAGkMwz5i03xw-nNsyrwBKUirCDws9bkPDxT-Q5UOMLYRQPfY_A@mail.gmail.com>
	<9B7002B514644AC493E7AE344F23787A@mike>
Message-ID: <75822E125BCB994F8446858C4B19F0D7175496FF81@SUEX07-MBX-04.ad.syr.edu>

I support prop. 151, and agree with Burns' assertion that without relaxation of needs assessment for transfers we are driving v4 address blocks out of the RIR system.

> -----Original Message-----
> Both issues would dissolve, as would so many others, with the adoption of
> my proposal 151 to treat legacy and non-legacy addresses fairly by removing the
> outdated and unnecessary needs requirement on IPv4 transfers.
> 
> Given the situation, we are virtually mandating transfers (of legacy space
> at least) of address space outside the RIR system entirely.
> The resultant irrelevance of Whois data will drive the acceptance of private
> registries.
> 
> In this article,
> http://techliberation.com/2011/08/15/trading-ipv4-addresses-starts-making-
> internet-elders-nervous/
> ,Prof. Mueller relates a conversation with the broker who handled the
> Microsoft/Nortel IPv4 sale.  That broker mentions a point which is entirely
> relevant to my proposal, which is the fact that of all the 38 (!) IP blocks
> included in the sale, not a single one had correct Whois data.
> 
> As IPv6 remains stillborn, IPv4 address values will increase.
> As the values increase there will be conflict over ownership rights.
> Those conflicts will be settled in court eventually, and Whois will come to
> be publicly displayed as erroneous and irrelevant.
> Owners will demand a more reliable registration system to ensure their
> rights are recognized, and network operators will feel more protected by a
> registry which backs their entries with chain-of-custody documents.
> 
> By maintaining a needs requirement for transfers, we are on the path to a
> dramatic change in Internet governance, which we can avoid by refusing to
> continue policies which work in restraint of the free trading of IPv4
> addresses.
> 
> I applaud Scott's efforts to make a bad situation a little better, but
> suggest that the problems he addresses in his rationale would be mooted by
> acceptance of Prop 151.
> 
> I guess this is a thread hijack, but there is still time for expressions of
> support for 151 as it has not been abandoned.
> 
> Regards,
> Mike
> 
> 
> 
> 
> ----- Original Message -----
> From: "Scott Leibrand" <scottleibrand at gmail.com>
> To: "Mike Burns" <mike at nationwideinc.com>
> Cc: "ARIN" <info at arin.net>; <arin-ppml at arin.net>
> Sent: Tuesday, August 23, 2011 8:48 PM
> Subject: Re: [arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIR
> transfers
> 
> 
> On Tue, Aug 23, 2011 at 12:07 PM, Mike Burns <mike at nationwideinc.com>
> wrote:
> > Support, but I would support more with a 12-month justification and it
> > would
> > be better with no justification requirement at all.
> 
> Thanks.  I'd like to hear input from more folks on what this
> requirement should look like.
> 
> > This change will allow some Asian companies to participate in legitimate
> > transfers with Whois updates, who would otherwise have to take the risks
> > of
> > an unbooked sale.
> > Would this policy be consistent with the ideas about regional registries
> > that was discussed on the list earlier in reference to ICP-2?
> 
> Yes, because we're transferring the addresses (under certain
> conditions) to another RIR for them to administer in their region.
> 
> > Is this change in 8.3 an endrun around the concept of regionality?
> 
> I don't believe so.
> 
> -Scott
> 
> 
> > ----- Original Message ----- From: "ARIN" <info at arin.net>
> > To: <arin-ppml at arin.net>
> > Sent: Tuesday, August 23, 2011 2:46 PM
> > Subject: [arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIR transfers
> >
> >
> >> ARIN-prop-156 Update 8.3 to allow inter-RIR transfers
> >>
> >> ARIN received the following policy proposal and is posting it to the
> >> Public Policy Mailing List (PPML) in accordance with the Policy
> >> Development Process.
> >>
> >> The ARIN Advisory Council (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.
> >>
> >> 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.
> >>
> >> Draft Policies and Proposals under discussion can be found at:
> >> https://www.arin.net/policy/proposals/index.html
> >>
> >> The ARIN Policy Development Process can be found at:
> >> https://www.arin.net/policy/pdp.html
> >>
> >> Mailing list subscription information can be found
> >> at: https://www.arin.net/mailing_lists/
> >>
> >> Regards,
> >>
> >> Communications and Member Services
> >> American Registry for Internet Numbers (ARIN)
> >>
> >> ## * ##
> >>
> >> ARIN-prop-156 Update 8.3 to allow inter-RIR transfers
> >>
> >> Proposal Originator: Scott Leibrand
> >>
> >> Date: 23 August 2011
> >>
> >> Proposal type: Modify
> >>
> >> Policy term: Permanent
> >>
> >> Policy statement:
> >>
> >> 8.3. Transfers to Specified Recipients
> >>
> >> In addition to transfers under section 8.2, IPv4 number resources may
> >> be released to ARIN by the authorized resource holder, in whole or in
> >> part, for transfer:
> >>
> >> + under RSA, to specified organizational recipient(s) within the ARIN
> >> region that can demonstrate the need for such resources, in the exact
> >> amount which they can justify under current ARIN policies.
> >>
> >> + to another RIR, for transfer to a specified recipient in that RIR's
> >> service region who demonstrates plans to deploy the resources for the
> >> justified purpose within 3 months, as long as the request meets the
> >> policy requirements of both RIRs, and the recipient (and any
> >> organizations to which they have transferred or reassigned space) can
> >> show efficient utilization of all prior allocations, assignments, and
> >> transfers according to the current policy requirements of both RIRs.
> >>
> >>
> >> Rationale:
> >>
> >> A number of RIRs already allow IPv4 address transfers within their
> >> service regions. Given that IPv4 address demand is concentrated in
> >> certain rapidly growing regions, whereas IPv4 addresses that can be
> >> made available to supply that demand are concentrated in regions with
> >> more historical IPv4 deployment, it would be most efficient for
> >> addresses to be transferred from regions with more supply to regions
> >> with more demand. If this is not allowed, prices for IPv4 addresses
> >> in high-demand regions will be higher, raising overall costs,
> >> encouraging address holders to transfer addresses outside the RIR
> >> system, and/or encouraging large corporations to acquire addresses in
> >> regions with more supply and then use them in regions with more
> >> demand. It would be better for the overall Internet industry to allow
> >> inter-RIR transfers to organizations with demonstrated need for
> >> addressing for immediate deployment needs.
> >>
> >> This policy text would be intended to replace draft policy 2011-1 ARIN
> >> Inter-RIR Transfers.
> >>
> >> Timetable for implementation: Immediate
> >>
> >> _______________________________________________
> >> 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 owen at delong.com  Wed Aug 24 13:02:39 2011
From: owen at delong.com (Owen DeLong)
Date: Wed, 24 Aug 2011 10:02:39 -0700
Subject: [arin-ppml] Prop-151 -- Still a bad idea (was a thread hijack of
	prop-156)
In-Reply-To: <9B7002B514644AC493E7AE344F23787A@mike>
References: <4E53F59A.4010803@arin.net><667141AF2AE74F33878F2A368C40B22B@mike>
	<CAGkMwz5i03xw-nNsyrwBKUirCDws9bkPDxT-Q5UOMLYRQPfY_A@mail.gmail.com>
	<9B7002B514644AC493E7AE344F23787A@mike>
Message-ID: <A66CB2E1-4321-4D34-A2BE-783B302FF509@delong.com>


On Aug 24, 2011, at 6:54 AM, Mike Burns wrote:

> I would like to point out that some of the comments relating to 156 involve issues of "fairness" in terms of applying less stringent standards to the proposed transfers than applied to ARIN members, and others involve issues of perceived ARIN bullying from its position of strength on this issue.
> 
> Both issues would dissolve, as would so many others, with the adoption of my proposal 151 to treat legacy and non-legacy addresses fairly by removing the outdated and unnecessary needs requirement on IPv4 transfers.
> 

Needs-basis is neither outdated nor unnecessary. APNIC stands alone as the only RIR to abandon needs basis so far.

I do not believe that encouraging ARIN to follow suit improves the situation.

> Given the situation, we are virtually mandating transfers (of legacy space at least) of address space outside the RIR system entirely.
> The resultant irrelevance of Whois data will drive the acceptance of private registries.
> 

Not really, no. Will some of those occur? Perhaps. Probably even. They aren't without risk. I'm OK with that.

I don't believe that they will occur in large enough volume to render whois irrelevant and I am not convinced that private
registries would do anything other than further devolve the situation.

If you want an example of the chaos and dysfunction that ensues when you remove rational controls, just look at
the domain name system and it's devolution into anyone can have a TLD for the right price.

> In this article, http://techliberation.com/2011/08/15/trading-ipv4-addresses-starts-making-internet-elders-nervous/ ,Prof. Mueller relates a conversation with the broker who handled the Microsoft/Nortel IPv4 sale.  That broker mentions a point which is entirely relevant to my proposal, which is the fact that of all the 38 (!) IP blocks included in the sale, not a single one had correct Whois data.
> 

I don't see how the fact that the organization(s) failed to meet their obligations to maintain their registrations is relevant or makes any sort of case in favor of your proposal. The community sets rules. Organizations may or may not follow those rules. I don't see how the fact that some organization(s) failed to follow the rules is indicative that the rules should be eliminated.

That's like making the argument that because some people commit armed robbery, we should remove the laws against armed robbery. This makes no sense to me.

> As IPv6 remains stillborn, IPv4 address values will increase.

IPv6 was not, is not, and does not remain stillborn.

> As the values increase there will be conflict over ownership rights.
> Those conflicts will be settled in court eventually, and Whois will come to be publicly displayed as erroneous and irrelevant.

Do you have any evidence to support this claim?

Could whois be better? Yes. There are multiple efforts underway to improve the quality of data in whois and I have supported policies and suggestions to encourage ARIN to put more resources into improving the quality of data in whois.

However, the current error rate in whois is far from irrelevant and there is, frankly, absolutely no better alternative available at this time.

> Owners will demand a more reliable registration system to ensure their rights are recognized, and network operators will feel more protected by a registry which backs their entries with chain-of-custody documents.

First, IP addresses themselves are not property. The registration system is entirely reliable and registrants who work within it are guaranteed that their rights are recognized. This theory that integers can somehow was amusing to me until I started seeing some of the current software patent wars unfold. It does appear that the courts have become so dysfunctional that you could very well see a day when everyone has to pay someone a royalty every time they use a 5. However, at that point, we have much bigger problems than whois accuracy to contend with.

Until the courts become that much more dysfunctional than they already are, I think we should, instead, focus on the current reality. That is that any inaccuracies in whois are the result of resource holders failing to register their current data. The process for updating your data is relatively simple and painless. It costs nothing. As such, any resource holder who feels that their rights have been supplanted by whois inaccuracy has noone to blame but themselves.

> By maintaining a needs requirement for transfers, we are on the path to a dramatic change in Internet governance, which we can avoid by refusing to continue policies which work in restraint of the free trading of IPv4 addresses.
> 

Abandoning the needs basis would be a dramatic change in internet governance, so, I'm really not sure how you can claim that we can avoid a dramatic change in internet governance by making one.

> I applaud Scott's efforts to make a bad situation a little better, but suggest that the problems he addresses in his rationale would be mooted by acceptance of Prop 151.
> 

They'd also be mooted by adoption of APNIC Prop-096 which is, IMHO, a far better solution and would work well with 2011-1.

> I guess this is a thread hijack, but there is still time for expressions of support for 151 as it has not been abandoned.
> 

Yes, you are correct on both counts. Lots of time since neither of them is likely to be on the agenda for adoption in Philadelphia.

There is also time to support APNIC proposal 96 which is going up for discussion in Busan next week and time to support 2011-1 which will be up for adoption discussion in Philadelphia.

Owen

> Regards,
> Mike
> 
> 
> 
> 
> ----- Original Message ----- From: "Scott Leibrand" <scottleibrand at gmail.com>
> To: "Mike Burns" <mike at nationwideinc.com>
> Cc: "ARIN" <info at arin.net>; <arin-ppml at arin.net>
> Sent: Tuesday, August 23, 2011 8:48 PM
> Subject: Re: [arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIR transfers
> 
> 
> On Tue, Aug 23, 2011 at 12:07 PM, Mike Burns <mike at nationwideinc.com> wrote:
>> Support, but I would support more with a 12-month justification and it would
>> be better with no justification requirement at all.
> 
> Thanks.  I'd like to hear input from more folks on what this
> requirement should look like.
> 
>> This change will allow some Asian companies to participate in legitimate
>> transfers with Whois updates, who would otherwise have to take the risks of
>> an unbooked sale.
>> Would this policy be consistent with the ideas about regional registries
>> that was discussed on the list earlier in reference to ICP-2?
> 
> Yes, because we're transferring the addresses (under certain
> conditions) to another RIR for them to administer in their region.
> 
>> Is this change in 8.3 an endrun around the concept of regionality?
> 
> I don't believe so.
> 
> -Scott
> 
> 
>> ----- Original Message ----- From: "ARIN" <info at arin.net>
>> To: <arin-ppml at arin.net>
>> Sent: Tuesday, August 23, 2011 2:46 PM
>> Subject: [arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIR transfers
>> 
>> 
>>> ARIN-prop-156 Update 8.3 to allow inter-RIR transfers
>>> 
>>> ARIN received the following policy proposal and is posting it to the
>>> Public Policy Mailing List (PPML) in accordance with the Policy
>>> Development Process.
>>> 
>>> The ARIN Advisory Council (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.
>>> 
>>> 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.
>>> 
>>> Draft Policies and Proposals under discussion can be found at:
>>> https://www.arin.net/policy/proposals/index.html
>>> 
>>> The ARIN Policy Development Process can be found at:
>>> https://www.arin.net/policy/pdp.html
>>> 
>>> Mailing list subscription information can be found
>>> at: https://www.arin.net/mailing_lists/
>>> 
>>> Regards,
>>> 
>>> Communications and Member Services
>>> American Registry for Internet Numbers (ARIN)
>>> 
>>> ## * ##
>>> 
>>> ARIN-prop-156 Update 8.3 to allow inter-RIR transfers
>>> 
>>> Proposal Originator: Scott Leibrand
>>> 
>>> Date: 23 August 2011
>>> 
>>> Proposal type: Modify
>>> 
>>> Policy term: Permanent
>>> 
>>> Policy statement:
>>> 
>>> 8.3. Transfers to Specified Recipients
>>> 
>>> In addition to transfers under section 8.2, IPv4 number resources may
>>> be released to ARIN by the authorized resource holder, in whole or in
>>> part, for transfer:
>>> 
>>> + under RSA, to specified organizational recipient(s) within the ARIN
>>> region that can demonstrate the need for such resources, in the exact
>>> amount which they can justify under current ARIN policies.
>>> 
>>> + to another RIR, for transfer to a specified recipient in that RIR's
>>> service region who demonstrates plans to deploy the resources for the
>>> justified purpose within 3 months, as long as the request meets the
>>> policy requirements of both RIRs, and the recipient (and any
>>> organizations to which they have transferred or reassigned space) can
>>> show efficient utilization of all prior allocations, assignments, and
>>> transfers according to the current policy requirements of both RIRs.
>>> 
>>> 
>>> Rationale:
>>> 
>>> A number of RIRs already allow IPv4 address transfers within their
>>> service regions. Given that IPv4 address demand is concentrated in
>>> certain rapidly growing regions, whereas IPv4 addresses that can be
>>> made available to supply that demand are concentrated in regions with
>>> more historical IPv4 deployment, it would be most efficient for
>>> addresses to be transferred from regions with more supply to regions
>>> with more demand. If this is not allowed, prices for IPv4 addresses
>>> in high-demand regions will be higher, raising overall costs,
>>> encouraging address holders to transfer addresses outside the RIR
>>> system, and/or encouraging large corporations to acquire addresses in
>>> regions with more supply and then use them in regions with more
>>> demand. It would be better for the overall Internet industry to allow
>>> inter-RIR transfers to organizations with demonstrated need for
>>> addressing for immediate deployment needs.
>>> 
>>> This policy text would be intended to replace draft policy 2011-1 ARIN
>>> Inter-RIR Transfers.
>>> 
>>> Timetable for implementation: Immediate
>>> 
>>> _______________________________________________
>>> 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 dogwallah at gmail.com  Wed Aug 24 13:11:29 2011
From: dogwallah at gmail.com (McTim)
Date: Wed, 24 Aug 2011 20:11:29 +0300
Subject: [arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIR
	transfers
In-Reply-To: <75822E125BCB994F8446858C4B19F0D7175496FF81@SUEX07-MBX-04.ad.syr.edu>
References: <4E53F59A.4010803@arin.net> <667141AF2AE74F33878F2A368C40B22B@mike>
	<CAGkMwz5i03xw-nNsyrwBKUirCDws9bkPDxT-Q5UOMLYRQPfY_A@mail.gmail.com>
	<9B7002B514644AC493E7AE344F23787A@mike>
	<75822E125BCB994F8446858C4B19F0D7175496FF81@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <CACAaNxiywhfQo0wds9d0DV8ybR6n5+xQDF1_ju0hi8hQraSOxA@mail.gmail.com>

HI Milton,

On Wed, Aug 24, 2011 at 7:52 PM, Milton L Mueller <mueller at syr.edu> wrote:

> I support prop. 151, and agree with Burns' assertion that without
> relaxation of needs assessment for transfers we are driving v4 address
> blocks out of the RIR system.
>

My reading of your techliberation article suggests to me that you are in
favor of  "driving v4 address blocks out of the RIR system."

Perhaps I've missed something?

In terms of "thinking outside of the box" I'd be happy NOT to even entertain
the notion of inter-regional transfers.  If we want the v6 transition to
accelerate, there has got to be demand for v6.  If v4 is available, then
that dampens the need for v6, no?

-- 
Cheers,

McTim
"A name indicates what we seek. An address indicates where it is. A route
indicates how we get there."  Jon Postel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110824/dcb48157/attachment.htm>

From hannigan at gmail.com  Wed Aug 24 13:18:21 2011
From: hannigan at gmail.com (Martin Hannigan)
Date: Wed, 24 Aug 2011 13:18:21 -0400
Subject: [arin-ppml] Proposal 151 Was: Re: ARIN-prop-156 Update 8.3 to allow
 inter-RIR transfers
Message-ID: <CAMDXq5MZ35nUt_ruRtgYUmTg34u_Rfb35g4V2xFDGiUbRSgyqg@mail.gmail.com>

On Wed, Aug 24, 2011 at 12:52 PM, Milton L Mueller <mueller at syr.edu> wrote:
> I support prop. 151, and agree with Burns' assertion that without relaxation of needs assessment for transfers we are driving v4 address blocks out of the RIR system.
>


I'd like to state my conditional support for Proposition 151,
condition being completion of an up-to-date staff and legal review.

Best,

-M<


From scottleibrand at gmail.com  Wed Aug 24 13:38:47 2011
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Wed, 24 Aug 2011 10:38:47 -0700
Subject: [arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIR
	transfers
In-Reply-To: <CA+uaoiWhc=2CvET7peawusW+LAV8zcd2yff0z0GWQ-vDMoXUXg@mail.gmail.com>
References: <CA+uaoiWhc=2CvET7peawusW+LAV8zcd2yff0z0GWQ-vDMoXUXg@mail.gmail.com>
Message-ID: <CAGkMwz7F4zd9wm9dt5AYa9eR=XkL=dkXkedgPJ_ifPwC1yC8gg@mail.gmail.com>

On Wed, Aug 24, 2011 at 9:15 AM, Rudolph Daniel <rudi.daniel at gmail.com> wrote:
> This prop-156 ..I am trying to comprehend why we would be wanting to
> transfer resources from ARIN to another "RIR's? member" when RIRs have the
> potential to all have slightly different transfer policies?

Most RIRs now have transfer policies in place that allow addresses to
be transferred between organizations within the RIR's region.  That is
likely to result in a transfer market, where the prices are set by
supply of and demand for IPv4 space.  The ARIN region has a larger
amount of legacy address space than the other RIRs, and a relatively
mature market that is no longer growing at tremendous rates.  Other
regions, such as APNIC, have almost no legacy address space and are
still growing much faster.  Without some mechanism to allow address
space to be transferred between regions, prices for IPv4 addresses are
likely to be much higher in regions like APNIC than within the ARIN
region.  That will encourage organizations to transfer addresses from
ARIN to those other regions however they can, either by obtaining it
here and using it elsewhere, or by engaging in de facto transfers
outside the RIR system.  IMO we want to avoid that by allowing
inter-RIR transfers to occur within the RIR system.

> Or are we asking all RIRs to consider needs based policies akin to ARIN?

That is what draft policy ARIN-2011-1 asks.  APNIC will be considering
a proposal (prop-096) to reinstate needs basis for transfers at their
Busan meeting next week.  If prop-096 is adopted, I think ARIN-2011-1
would be adequate and ARIN-prop-156 would likely not be necessary.  If
not, then ARIN-2011-1 is a no-op (at least with respect to APNIC), and
ARIN-prop-156 would be needed.

> Is it not more effective to deal with transfers between RIRs? and leave the
> respective RIR to deal with its own members.?

That is the approach favored by ARIN-2011-9 Global Policy for post
exhaustion IPv4 allocation mechanisms by the IANA.  I support that
policy as well, but I think it will be insufficient, as organizations
holding valuable address space largely won't want to return it to ARIN
for redistribution to other regions.  They would be much more likely
to be willing to transfer the space to an APNIC member if they could
receive some form of compensation for doing so.

Hope that helps,
-Scott (speaking only for myself, as always)


From info at arin.net  Wed Aug 24 15:53:29 2011
From: info at arin.net (ARIN)
Date: Wed, 24 Aug 2011 15:53:29 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - August 2011
Message-ID: <4E5556B9.2080900@arin.net>

In accordance with the ARIN Policy Development Process, the ARIN 
Advisory Council (AC) held a meeting on 18 August 2011 and made 
decisions about several proposals.

The AC selected the following proposals as draft policies for adoption
discussion online and at the ARIN XXVIII Public Policy Meeting in
Philadelphia in October. The draft policies will be posted shortly to 
the PPML.

   ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation 
mechanisms by the IANA
   ARIN-prop-144 Remove Single Aggregate requirement from Specified Transfer
   ARIN-prop-146 Clarify Justified Need for Transfers
   ARIN-prop-147 Set Transfer Need to 24 months
   ARIN-prop-155 IPv4 Number Resources for Use Within Region

The following proposals were not selected as draft policies at this time:

   ARIN-prop-151 Limiting needs requirements for IPv4 Transfers
   ARIN-prop-153 Correct erroneous syntax in NRPM 8.3

The AC as a whole felt that the text of proposal 151 was not ready 
enough to move forward to draft policy. The AC is hoping to gain more 
input through the PPML and at the upcoming Public Policy Meeting.

Since ARIN-Prop-153 was in direct conflict with ARIN-Prop-144, which the
AC had already advanced to Draft Policy status and adoption discussion 
on PPML and at the next Public Policy Meeting in Philadelphia, the 
motion to select ARIN-Prop-153 as Draft Policy did not carry. Since 
there was no motion to abandon and in accordance with the ARIN Policy 
Development Process, ARIN-Prop-153 remains on the AC's docket.

The AC abandoned the following proposals:

   ARIN-prop-149 Improved Transparency for Directed Transfers
   ARIN-prop-152 RSA Modification Limits

The AC feels that proposal 149 belongs in the consultation and 
suggestion process as it is a recomendation to staff to publish a list 
and is not addressing policy. The author has been advised of the AC's 
abandon action and has already submitted this to the ARIN Consultation 
and Suggestion Process (ACSP).

The AC feels that based upon the Clarity and Understanding from
Staff, proposal 152 is inappropriate for the NRPM. The author has
been advised of the AC's abandon action.

The AC thanks the authors and the community for their continuing effort
and contributions to these and all other policy considerations.

The AC did not select proposals 151 and 153 as draft policies and 
abandoned proposals 149 and 152. Anyone dissatisfied with these 
decisions may initiate a petition. The petition to advance these 
proposals is the "Discussion Petition." The deadline to begin a petition 
is five business days after the AC's draft meeting minutes are 
published. Note that in order for a petition of any of the proposals to 
be considered successful for the upcoming ARIN XXVIII meeting, the 
petition must be concluded by 6 September 2011 in order to meet the 
requirement of posting as draft policy at least 35 days prior to the 
meeting. If you are considering petitioning, starting one earlier is 
better than later.

For more information on starting and participating in petitions, see PDP 
Petitions at:
https://www.arin.net/policy/pdp_petitions.html

Draft Policy and Proposal texts are available at:
https://www.arin.net/policy/proposals/index.html

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

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


From info at arin.net  Wed Aug 24 15:58:03 2011
From: info at arin.net (ARIN)
Date: Wed, 24 Aug 2011 15:58:03 -0400
Subject: [arin-ppml] Draft Policy 2011-9 (Global Proposal): Global Policy
 for post exhaustion IPv4 allocation mechanisms by the IANA
Message-ID: <4E5557CB.2040708@arin.net>

Draft Policy ARIN-2011-9 (Global Proposal)
Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA


On 18 August 2011 the ARIN Advisory Council (AC) selected "Global Policy 
for post exhaustion IPv4 allocation mechanisms by the IANA" as a  draft 
policy for adoption discussion on the PPML and at the Public Policy 
Meeting in Philadelphia in October.

The draft was developed by the AC from policy proposal "ARIN-prop-137 
Global Policy for post exhaustion IPv4 allocation mechanisms by the 
IANA." Per the Policy Development Process the AC submitted text to ARIN 
for a staff and legal assessment prior to its selection as a draft 
policy. Below the draft policy is the ARIN staff and legal assessment, 
followed by the text that was submitted by the AC.

Draft Policy ARIN-2011-9 is below and can be found at:
https://www.arin.net/policy/proposals/2011_9.html

You are encouraged to discuss Draft Policy 2011-9 on the PPML prior to
the October Public Policy Meeting. Both the discussion on the list and
at the meeting will be used by the ARIN Advisory Council to determine
the community consensus for adopting this as policy.

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

Draft Policies and Proposals 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 ARIN-2011-9 (Global Proposal)
Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA

Date: 24 August 2011

Policy statement:

The IANA shall establish a Recovered IPv4 Pool to be utilized post
RIR IPv4 exhaustion. The Recovered IPv4 Pool will initially contain
any fragments that may be left over in the IANA. It will also hold
any space returned to the IANA by any other means.
The Recovered IPv4 Pool will be administered by the IANA. It will
contain:
a. Any fragments left over in the IANA inventory after the last
/8s of IPv4 space are delegated to the RIRs

     The IANA inventory excludes "Special use IPv4 addresses" as
     defined in BCP 153 and any addresses allocated by the IANA
     for experimental use.

b. Any IPv4 space returned to the IANA by any means.
The Recovered IPv4 Pool will stay inactive until the first RIR has
less than a total of a /9 in its inventory of IPv4 address space.
When one of the RIRs declares it has less than a total of a /9 in
its inventory, the Recovered IPv4 pool will be declared active, and
IP addresses from the Recovered IPv4 Pool will be allocated as
follows:
a. Allocations from the IANA may begin once the pool is declared
active.
b. In each "IPv4 allocation period", each RIR will receive a
single "IPv4 allocation unit" from the IANA.
c. An "IPv4 allocation period" is defined as a 6-month period
following 1 March or 1 September in each year.
d. The IANA will calculate the size of the "IPv4 allocation unit"
at the following times:

     When the Recovered IPv4 Pool is first activated
     At the beginning of each IPv4 allocation period

To calculate the "IPv4 allocation unit" at these times, the
IANA will use the following formula:
IPv4 allocation unit = 1/5 of Recovered IPv4 pool,
rounded down to the next CIDR
(power-of-2) boundary.
No RIR may get more than this calculation used to determine
the IPv4 allocation unit even when they can justify a need for
it.
The minimum "IPv4 allocation unit" size will be a /24. If the
calculation used to determine the IPv4 allocation unit results
in a block smaller than a /24, the IANA will not distribute
any addresses in that IPv4 allocation period.
The IANA may make public announcements of IPv4 address
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:

The policy provides a mechanism for the ongoing distribution of
IPv4 address space, while removing the areas that have been
problematic in previous attemts at this proposal. The proposal:

- Permits regional variation in runout policy amongst RIRs to
be accounted for in the distribution of the Recovered IPv4 Pool

- Prevents the possibility of a single RIR being eligible to
be allocated the entire Recovered IPv4 Pool in the first
(and perhaps only) allocation period

- Removes two areas of policy that have failed to reach
agreement in previous attempts at this proposal:

- How addresses should be placed in the Recovered IPv4 Pool
- References to how transfers should or should not take
place

Timetable for implementation:

Once consensus has been reached in each of the 5 RIR regions, the
policy will be forwarded to ICANN for approval and then implemented
by the IANA.


#####


STAFF ASSESSMENT

ARIN STAFF ASSESSMENT

Proposal:  ARIN-prop-137 Global Policy for post exhaustion IPv4 
allocation mechanisms by the IANA

Date of Assessment: 18 August 2011

1.  Proposal Summary (Staff Understanding)

IANA issued the last /8s in February 2011. There is no global policy for 
IANA to allocate address space to the RIRs that is smaller than a /8. 
The proposal tells IANA to set up a recovered address space pool, accept 
returns by any means, and allocate address space to the RIRs in equal 
amounts, twice a year, minimum /24.

2. Comments

A. ARIN Staff Comments

?	This proposal would fill a policy gap.  It would allow the RIRs to 
return IPv4 address blocks smaller than a /8 to the IANA for equal 
redistribution amongst the RIRs.

B. ARIN General Counsel

This policy poses no significant legal risks and is a useful advancement.


3. Resource Impact

This policy would have minimal resource impact from an implementation 
aspect.  Since this is a global policy proposal it would be implemented 
after ratification by the ICANN Board. The following would be needed in 
order to implement:

?	Updated guidelines
?	Staff training

4. Proposal Text

ARIN-prop-137
Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA

Policy statement:

The IANA shall establish a Recovered IPv4 Pool to be utilized post
RIR IPv4 exhaustion. The Recovered IPv4 Pool will initially contain
any fragments that may be left over in the IANA. It will also hold
any space returned to the IANA by any other means.
The Recovered IPv4 Pool will be administered by the IANA. It will
contain:
a. Any fragments left over in the IANA inventory after the last
/8s of IPv4 space are delegated to the RIRs

     The IANA inventory excludes "Special use IPv4 addresses" as
     defined in BCP 153 and any addresses allocated by the IANA
     for experimental use.

b. Any IPv4 space returned to the IANA by any means.
The Recovered IPv4 Pool will stay inactive until the first RIR has
less than a total of a /9 in its inventory of IPv4 address space.
When one of the RIRs declares it has less than a total of a /9 in
its inventory, the Recovered IPv4 pool will be declared active, and
IP addresses from the Recovered IPv4 Pool will be allocated as
follows:
a. Allocations from the IANA may begin once the pool is declared
active.
b. In each "IPv4 allocation period", each RIR will receive a
single "IPv4 allocation unit" from the IANA.
c. An "IPv4 allocation period" is defined as a 6-month period
following 1 March or 1 September in each year.
d. The IANA will calculate the size of the "IPv4 allocation unit"
at the following times:

     When the Recovered IPv4 Pool is first activated
     At the beginning of each IPv4 allocation period

To calculate the "IPv4 allocation unit" at these times, the
IANA will use the following formula:
IPv4 allocation unit = 1/5 of Recovered IPv4 pool,
rounded down to the next CIDR
(power-of-2) boundary.
No RIR may get more than this calculation used to determine
the IPv4 allocation unit even when they can justify a need for
it.
The minimum "IPv4 allocation unit" size will be a /24. If the
calculation used to determine the IPv4 allocation unit results
in a block smaller than a /24, the IANA will not distribute
any addresses in that IPv4 allocation period.
The IANA may make public announcements of IPv4 address
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:

The policy provides a mechanism for the ongoing distribution of
IPv4 address space, while removing the areas that have been
problematic in previous attemts at this proposal. The proposal:

- Permits regional variation in runout policy amongst RIRs to
be accounted for in the distribution of the Recovered IPv4 Pool

- Prevents the possibility of a single RIR being eligible to
be allocated the entire Recovered IPv4 Pool in the first
(and perhaps only) allocation period

- Removes two areas of policy that have failed to reach
agreement in previous attempts at this proposal:

- How addresses should be placed in the Recovered IPv4 Pool
- References to how transfers should or should not take
place

Timetable for implementation:

Once consensus has been reached in each of the 5 RIR regions, the
policy will be forwarded to ICANN for approval and then implemented
by the IANA.


From info at arin.net  Wed Aug 24 15:58:17 2011
From: info at arin.net (ARIN)
Date: Wed, 24 Aug 2011 15:58:17 -0400
Subject: [arin-ppml] Draft Policy 2011-10: Remove Single Aggregate
 requirement from Specified Transfer
Message-ID: <4E5557D9.2080404@arin.net>

Draft Policy ARIN-2011-10
Remove Single Aggregate requirement from Specified Transfer


On 18 August 2011 the ARIN Advisory Council (AC) selected "Remove Single 
Aggregate requirement from Specified Transfer" as a  draft policy for 
adoption discussion on the PPML and at the Public Policy Meeting in 
Philadelphia in October.

The draft was developed by the AC from policy proposal "ARIN-prop-144 
Remove Single Aggregate requirement from Specified Transfer." Per the 
Policy Development Process the AC submitted text to ARIN for a staff and 
legal assessment prior to its selection as a draft policy. Below the 
draft policy is the ARIN staff and legal assessment, followed by the 
text that was submitted by the AC.

Draft Policy ARIN-2011-10 is below and can be found at:
https://www.arin.net/policy/proposals/2011_10.html

You are encouraged to discuss Draft Policy 2011-10 on the PPML prior to
the October Public Policy Meeting. Both the discussion on the list and
at the meeting will be used by the ARIN Advisory Council to determine
the community consensus for adopting this as policy.

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

Draft Policies and Proposals 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 ARIN-2011-10
Remove Single Aggregate requirement from Specified Transfer

Date: 24 August 2011

Policy statement:

Modify Section 8.3 as follows: Change "can demonstrate the need for such 
resources, as a single aggregate, in the exact amount which they can 
justify under current ARIN policies" to "can demonstrate the need for 
such resources in the amount which they can justify under current ARIN 
policies"

Rationale:

The "as a single aggregate" has been interpreted to apply only to 
"demonstrate the need" as opposed to the resources which may be received 
by ARIN staff. It is possible that the original intent was to require 
than each transfer be of a single aggregate.

HOWEVER, as multiple Section 8.3 transfers may be executed serially by a 
pair of entities which wish to use the specified transfer policy in 
order to transfer any number of blocks as long as there is needs 
justification for each, it simply saves the transferring entity, the 
recipient, AND ARIN paperwork to allow a transfer of multiple blocks to 
proceed as a single transfer.

Timetable for implementation: immediate


#####


ARIN STAFF ASSESSMENT

Proposal:  ARIN-prop-144 Remove Single Aggregate requirement from 
Specified Transfer
Date of Assessment: 18 August 2011

1.  Proposal Summary (Staff Understanding)

This proposed policy would remove the phrase, "as a single aggregate" 
from the existing NRPM 8.3 policy thus allowing the transfer of multiple 
prefixes during an 8.3 transfer.

2. Comments

A. ARIN Staff Comments

?	This would eliminate possible confusion and align the text with 
current implementation whereby transfers can involve multiple 
discontiguous IPv4 address ranges (in a single transaction with ARIN).

?	There are two or more proposals/draft policies that are trying to 
change 8.3. Need to make them work together. (see props 144,  151, 153).

B. ARIN General Counsel

Counsel affirmatively supports this suggested change. We do not see it 
as creating any additional legal liability. Given the myriad of factual 
situations that may arise, a single aggregate requirement could prove to 
be too rigid and could prohibit an overall good
policy result.


3. Resource Impact

This policy would have minimal resource impact from an implementation 
aspect.  It is estimated that implementation would occur within 3 months 
after ratification by the ARIN Board of Trustees. The following would be 
needed in order to implement:

?	Updated guidelines
?	Staff training

4. Proposal Text

ARIN-prop-144

Remove Single Aggregate requirement from Specified Transfer

Policy statement:

Modify Section 8.3 as follows: Change "can demonstrate the need for such 
resources, as a single aggregate, in the exact amount which they can 
justify under current ARIN policies" to "can demonstrate the need for 
such resources in the amount which they can justify under current ARIN 
policies"

Rationale:

The "as a single aggregate" has been interpreted to apply only to 
"demonstrate the need" as opposed to the resources which may be received 
by ARIN staff. It is possible that the original intent was to require 
than each transfer be of a single aggregate.
HOWEVER, as multiple Section 8.3 transfers may be executed serially by a 
pair of entities which wish to use the specified transfer policy in 
order to transfer any number of blocks as long as there is needs 
justification for each, it simply saves the transferring entity, the 
recipient, AND ARIN paperwork to allow a transfer of multiple blocks to 
proceed as a single transfer.

Timetable for implementation: immediate


From info at arin.net  Wed Aug 24 15:58:34 2011
From: info at arin.net (ARIN)
Date: Wed, 24 Aug 2011 15:58:34 -0400
Subject: [arin-ppml] Draft Policy 2011-11: Clarify Justified Need for
	Transfers
Message-ID: <4E5557EA.7060501@arin.net>

Draft Policy ARIN-2011-11
Clarify Justified Need for Transfers


On 18 August 2011 the ARIN Advisory Council (AC) selected "Clarify 
Justified Need for Transfers" as a  draft policy for adoption discussion 
on the PPML and at the Public Policy Meeting in Philadelphia in October.

The draft was developed by the AC from policy proposal "ARIN-prop-146 
Clarify Justified Need for Transfers." Per the Policy Development 
Process the AC submitted text to ARIN for a staff and legal assessment 
prior to its selection as a draft policy. Below the draft policy is the 
ARIN staff and legal assessment, followed by the text that was submitted 
by the AC.

Draft Policy ARIN-2011-11 is below and can be found at:
https://www.arin.net/policy/proposals/2011_11.html

You are encouraged to discuss Draft Policy 2011-11 on the PPML prior to
the October Public Policy Meeting. Both the discussion on the list and
at the meeting will be used by the ARIN Advisory Council to determine
the community consensus for adopting this as policy.

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

Draft Policies and Proposals 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 ARIN-2011-11
Clarify Justified Need for Transfers

Date: 24 August 2011

Policy statement:

Add to Section 8.3:

"...they can justify under current ARIN policies
showing how the addresses will be utilized within 12 months."

Remove from 4.2.4.4:

"This reduction does not apply to resources
received via section 8.3. An organization receiving a transfer under
section 8.3 may continue to request up to a 12-month supply of IP
addresses."

Rationale:

An organization which is not able to obtain its initial IPv4 address
assignment from ARIN post-runout would otherwise be limited to
purchasing only a 3-month supply (because the language in 4.2.4.4
regarding 8.3 transfers is not triggered).

An organization which has only recently received its first allocation
under the "last /8" criteria is also otherwise limited to purchasing
only a 3-month supply (because the language in 4.2.4.4 is again not
applicable).

There is also ambiguity if 4.2.2.1.3 is applied in that a transfer to
a new organization might only need to show need for a /20 (because that
is what is specifically called out) even though they are receiving a
much larger block.

Previous version of this proposal modified Section 8 to point at 4.2.4,
rather than the shorter and clearer modification to 8.3 now proposed.

There is also ambiguity with regard to transfers under 8.2 where the
receiving organization is a new organization... not at all clear how
"justified need" has been or should be determined, however this proposal
no longer addresses this.

Timetable for implementation: immediate


#####


ARIN STAFF ASSESSMENT

Proposal:  ARIN-prop-146 Clarify Justified Need for Transfers
Date of Assessment: 18 August 2011

1.  Proposal Summary (Staff Understanding)

This proposal would modify existing NRPM policy 8.3 to specifically 
state that all organizations can justify a 12 month supply of IPv4 
addresses.

Currently, the only reference to a timeframe for 8.3 transfers is 
contained in NRPM 4.2.2.4, Subscriber Members After One Year, which says 
that 8.3 transfers are exempt from the 3 month supply limitation that 
all other ISPs who are requesting additional IPv4 space must adhere to - 
?An organization receiving a transfer under section 8.3 may continue to 
request up to a 12-month supply of IP addresses.? This proposal would 
remove this reference and instead, add the 12 month language to the 
proper section of NRPM.


2.  Comments

A. ARIN Staff Comments
?	This proposal would still require an organization requesting an 8.3 
transfer to qualify for the space under current ARIN policies, but would 
exempt them from the 3 month supply limitations currently set forth in 
NRPM 4.2.1.4 ?Slow Start? and 4.2.2.1.3 ?Three Months? and instead allow 
them to qualify for a 12 month supply of IPv4 address space.
?	If this became policy, it would align well with NRPM 8.2 (Transfers 
due to M&A) since the staff uses a 12 month utilization window when 
analyzing these types of transfer requests.


B. ARIN General Counsel

This policy presents no significant legal issues.

3. Resource Impact

This policy would have minimal resource impact from an implementation 
aspect.  It is estimated that implementation would occur within 3 months 
after ratification by the ARIN Board of Trustees. The following would be 
needed in order to implement:

?	Updated guidelines
?	Staff training

4. Proposal Text

ARIN-prop-146
Clarify Justified Need for Transfers

Policy statement:

Add to Section 8.3 "...they can justify under current ARIN policies
showing how the addresses will be utilized within 12 months."

Remove from 4.2.4.4: "This reduction does not apply to resources
received via section 8.3. An organization receiving a transfer under
section 8.3 may continue to request up to a 12-month supply of IP
addresses."


Rationale:

An organization which is not able to obtain its initial IPv4 address
assignment from ARIN post-runout would otherwise be limited to
purchasing only a 3-month supply (because the language in 4.2.4.4
regarding 8.3 transfers is not triggered).

An organization which has only recently received its first allocation
under the "last /8" criteria is also otherwise limited to purchasing
only a 3-month supply (because the language in 4.2.4.4 is again not
applicable).

There is also ambiguity if 4.2.2.1.3 is applied in that a transfer to
a new organization might only need to show need for a /20 (because that
is what is specifically called out) even though they are receiving a
much larger block.

Previous version of this proposal modified Section 8 to point at 4.2.4,
rather than the shorter and clearer modification to 8.3 now proposed.

There is also ambiguity with regard to transfers under 8.2 where the
receiving organization is a new organization... not at all clear how
"justified need" has been or should be determined, however this proposal
no longer addresses this.

Timetable for implementation: immediate


From info at arin.net  Wed Aug 24 15:58:47 2011
From: info at arin.net (ARIN)
Date: Wed, 24 Aug 2011 15:58:47 -0400
Subject: [arin-ppml] Draft Policy 2011-12: Set Transfer Need to 24 months
Message-ID: <4E5557F7.8040304@arin.net>

Draft Policy ARIN-2011-12
Set Transfer Need to 24 months


On 18 August 2011 the ARIN Advisory Council (AC) selected "Set Transfer 
Need to 24 months" as a  draft policy for adoption discussion on the 
PPML and at the Public Policy Meeting in Philadelphia in October.

The draft was developed by the AC from policy proposal "ARIN-prop-147 
Set Transfer Need to 24 months." Per the Policy Development Process the 
AC submitted text to ARIN for a staff and legal assessment prior to its 
selection as a draft policy. Below the draft policy is the ARIN staff 
and legal assessment, followed by the text that was submitted by the AC.

Draft Policy ARIN-2011-12 is below and can be found at:
https://www.arin.net/policy/proposals/2011_12.html

You are encouraged to discuss Draft Policy 2011-12 on the PPML prior to
the October Public Policy Meeting. Both the discussion on the list and
at the meeting will be used by the ARIN Advisory Council to determine
the community consensus for adopting this as policy.

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

Draft Policies and Proposals 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 ARIN-2011-12
Set Transfer Need to 24 months

Date: 24 August 2011

Policy statement:

If ARIN-prop-146 passes, also modify "will be utilized within 12 months" 
to "will be utilized within 24 months"

Rationale:

Due to the complexity of the financial transaction that may be
involved and the associated budgeting on the part of the receiving
organization, 24 months is a more reasonable amount of forecast need to
allow to be fulfilled via the transfer process.

Potential benefit to address aggregation by allowing fewer larger
transfers sooner.

Change from previous version: uses the new language proposed in
ARIN-prop-146 rather than modifying 4.2.4.4. Also no longer modifies
4.2.4.4 to apply to section 8.2 transfers.

Timetable for implementation: immediate


#####


ARIN STAFF ASSESSMENT

Proposal:  ARIN-prop-147 Set Transfer Need to 24 months
Date of Assessment: 18 August 2011

1.  Proposal Summary (Staff Understanding)

This is a conditional policy proposal, germane only if prop-146 
eventually becomes ratified policy. This proposal would modify 
prop-146's changes to NRPM 8.3 to allow 8.3 requestors to show justified 
need for 8.3 transfers within a 24-month window, rather than the 
12-month window proposed by prop-146.

2. Comments

A. ARIN Staff Comments
?	This proposal would still require an organization requesting an 8.3 
transfer to qualify for the space under current ARIN policies, but would 
exempt them from the 3 month supply limitations currently set forth in 
NRPM 4.2.1.4 ?Slow Start? and 4.2.2.1.3 ?Three Months? and instead allow 
them to qualify for a 24 month supply of IPv4 address space.
?	This change would make the specified transfer policy fit more 
situations, at the risk that addresses may go to parties whose need does 
not actually materialize as expected based on their projected allocation 
rates.

B. ARIN General Counsel

ARIN counsel strongly supports the immediate extension of assessed need 
from 12 to 24 months for proposed transfers. It is clear the longer time 
period will appropriately facilitate legally simpler transactions by 
those who are seeking to follow ARIN's policies. It may also meet goals 
of allowing larger blocs to be transferred to meet the needs of a single 
entity.

3. Resource Impact

This policy would have minimal resource impact from an implementation 
aspect.  It is estimated that implementation would occur within 3 months 
after ratification by the ARIN Board of Trustees. The following would be 
needed in order to implement:

?	Updated guidelines
?	Staff training

4. Proposal Text

ARIN-prop-147
Set Transfer Need to 24 months

Policy statement:

If ARIN-prop-146 passes, also modify "will be utilized within 12 months" 
to "will be utilized within 24 months"

Rationale:

Due to the complexity of the financial transaction that may be
involved and the associated budgeting on the part of the receiving
organization, 24 months is a more reasonable amount of forecast need to
allow to be fulfilled via the transfer process.
Potential benefit to address aggregation by allowing fewer larger
transfers sooner.

Change from previous version: uses the new language proposed in
ARIN-prop-146 rather than modifying 4.2.4.4. Also no longer modifies
4.2.4.4 to apply to section 8.2 transfers.

Timetable for implementation: immediate


From info at arin.net  Wed Aug 24 15:59:00 2011
From: info at arin.net (ARIN)
Date: Wed, 24 Aug 2011 15:59:00 -0400
Subject: [arin-ppml] Draft Policy 2011-13: IPv4 Number Resources for Use
	Within Region
Message-ID: <4E555804.8000701@arin.net>

Draft Policy ARIN-2011-13
IPv4 Number Resources for Use Within Region


On 18 August 2011 the ARIN Advisory Council (AC) selected "IPv4 Number 
Resources for Use Within Region" as a  draft policy for adoption 
discussion on the PPML and at the Public Policy Meeting in Philadelphia 
in October.

The draft was developed by the AC from policy proposal "ARIN-prop-155 
IPv4 Number Resources for Use Within Region." Per the Policy Development 
Process the AC submitted text to ARIN for a staff and legal assessment 
prior to its selection as a draft policy. Below the draft policy is the 
ARIN staff and legal assessment, followed by the text that was submitted 
by the AC.

Draft Policy ARIN-2011-13 is below and can be found at:
https://www.arin.net/policy/proposals/2011_13.html

You are encouraged to discuss Draft Policy 2011-13 on the PPML prior to
the October Public Policy Meeting. Both the discussion on the list and
at the meeting will be used by the ARIN Advisory Council to determine
the community consensus for adopting this as policy.

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

Draft Policies and Proposals 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 ARIN-2011-13
IPv4 Number Resources for Use Within Region

Date: 24 August 2011

Policy statement:

Insert the following text in the NRPM:

4.2.1.7 - Presence within the ARIN region
These IPv4 addresses are issued solely for use in networks within the 
ARIN region. Organizations requesting IPv4 addresses from ARIN must 
provide documentation to demonstrate the addresses will be used to 
number customers/devices within the ARIN region and must agree to use 
the addresses solely for that purpose.  This requirement shall be 
binding only on number resources requested after its ratification by the 
ARIN Board of Trustees.

4.3.7 - Presence within the ARIN region
These IPv4 addresses are issued solely for use in networks within the 
ARIN region. Organizations requesting IPv4 addresses from ARIN must 
provide documentation to demonstrate the addresses will be used to 
number customers/devices within the ARIN region and must agree to use 
the addresses solely for that purpose.  This requirement shall be 
binding only on number resources requested after its ratification by the 
ARIN Board of Trustees.

Rationale:

ICANN's ICP-2 document established a framework for regional
Internet registries, each to serve a well-defined geographically
scoped constituency.

The various RIRs will exhaust their free-pools at different times.
This creates a situation in which requesting organizations attempt an
end-run on ICP-2 and the RIR framework by coming directly to ARIN for
space to use outside the ARIN region. In other cases, subsidiaries,
sister organizations located within the ARIN region, or global
organizations headquartered within the ARIN region have requested
space that is ultimately destined for use outside the ARIN region.
Failure to address this situation in a timely fashion will grant an
unfair advantage to large multinationals who will be able to "shop
around" requests for space and hasten RIR free pool runout in the ARIN
region.

Leaving this loophole unaddressed is incompatible with ARIN's
principle of stewardship.

This problem is not unique to ARIN. Similar proposals are under
consideration in the LACNIC and AfriNIC regions.

Timetable for implementation: Immediate


#####


ARIN STAFF ASSESSMENT

Proposal:  ARIN-prop-155 IPv4 Number Resources for Use Within Region
Date of Assessment: 18 August 2011

1.  Proposal Summary (Staff Understanding)

This policy makes clear that ARIN should provide address assignments and 
allocations to organizations that are for use solely within the ARIN region.

2. Comments

A. ARIN Staff Comments

?	ARIN staff has identified in a past policy experience report that ARIN 
is receiving an increasing number of requests where it is clear that the 
intended use is outside the region.  While the definition of a Regional 
Internet Registry in NRPM 2.2 supports the principle that ARIN issues 
space for use in the region, this is not clearly stated within existing 
policy.

?	This lack of criteria has caused confusion for both staff and 
customers alike.   Clear policy direction is needed, particularly now 
that IPv4 depletion is upon us, so that ARIN will issue space in a 
manner consistent with community expectations.

?	Staff notes that the proposed policy text is absolute in its phrasing, 
and while this appears to be appropriate for the policy intent, this 
staff evaluation does not include any specific assessment of the 
resources or efforts in enforcement post-issuance since the proposal 
does not address this aspect of the policy.

B. ARIN General Counsel

Directionally, counsel has no concern regarding a proposed ARIN policy 
intended to restrict the remaining allocations of IPV4 addresses within 
the ARIN service region.  However, this policy is rigid--it prohibits 
any use of such resources issues outside of the service region. Since a 
violation of the policy would justify revocation this aspect must be 
clearly evaluated.

3. Resource Impact

This policy would have minimal resource impact from an implementation 
aspect.  It is estimated that implementation would occur within 3 months 
after ratification by the ARIN Board of Trustees. The following would be 
needed in order to implement:

?	Updated guidelines
?	Staff training

4. Proposal Text

ARIN-prop-155
IPv4 Number Resources for Use Within Region

Policy statement:

Insert the following text in the NRPM:

4.2.1.7 - Presence within the ARIN region
These IPv4 addresses are issued solely for use in networks within the 
ARIN region. Organizations requesting IPv4 addresses from ARIN must 
provide documentation to demonstrate the addresses will be used to 
number customers/devices within the ARIN region and must agree to use 
the addresses solely for that purpose.  This requirement shall be 
binding only on number resources requested after its ratification by the 
ARIN Board of Trustees.

4.3.7 - Presence within the ARIN region
These IPv4 addresses are issued solely for use in networks within the 
ARIN region. Organizations requesting IPv4 addresses from ARIN must 
provide documentation to demonstrate the addresses will be used to 
number customers/devices within the ARIN region and must agree to use 
the addresses solely for that purpose.  This requirement shall be 
binding only on number resources requested after its ratification by the 
ARIN Board of Trustees.

Rationale:

ICANN's ICP-2 document established a framework for regional
Internet registries, each to serve a well-defined geographically
scoped constituency.

The various RIRs will exhaust their free-pools at different times.
This creates a situation in which requesting organizations attempt an
end-run on ICP-2 and the RIR framework by coming directly to ARIN for
space to use outside the ARIN region. In other cases, subsidiaries,
sister organizations located within the ARIN region, or global
organizations headquartered within the ARIN region have requested
space that is ultimately destined for use outside the ARIN region.
Failure to address this situation in a timely fashion will grant an
unfair advantage to large multinationals who will be able to "shop
around" requests for space and hasten RIR free pool runout in the ARIN
region.

Leaving this loophole unaddressed is incompatible with ARIN's
principle of stewardship.

This problem is not unique to ARIN. Similar proposals are under
consideration in the LACNIC and AfriNIC regions.

Timetable for implementation: Immediate


From mueller at syr.edu  Wed Aug 24 16:01:29 2011
From: mueller at syr.edu (Milton L Mueller)
Date: Wed, 24 Aug 2011 16:01:29 -0400
Subject: [arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIR
 transfers
In-Reply-To: <CACAaNxiywhfQo0wds9d0DV8ybR6n5+xQDF1_ju0hi8hQraSOxA@mail.gmail.com>
References: <4E53F59A.4010803@arin.net> <667141AF2AE74F33878F2A368C40B22B@mike>
	<CAGkMwz5i03xw-nNsyrwBKUirCDws9bkPDxT-Q5UOMLYRQPfY_A@mail.gmail.com>
	<9B7002B514644AC493E7AE344F23787A@mike>
	<75822E125BCB994F8446858C4B19F0D7175496FF81@SUEX07-MBX-04.ad.syr.edu>
	<CACAaNxiywhfQo0wds9d0DV8ybR6n5+xQDF1_ju0hi8hQraSOxA@mail.gmail.com>
Message-ID: <75822E125BCB994F8446858C4B19F0D7175496FF8D@SUEX07-MBX-04.ad.syr.edu>




My reading of your techliberation article suggests to me that you are in favor of  "driving v4 address blocks out of the RIR system."

Not at all, I am trying to save the RIRs from themselves.
(Wish me luck, my damsel in distress hates my guts and seems to prefer the company of the fire-breathing dragon. Occasionally I am tempted to let her burn...but I usually chivalry prevails)

In terms of "thinking outside of the box" I'd be happy NOT to even entertain the notion of inter-regional transfers.  If we want the v6 transition to accelerate, there has got to be demand for v6.  If v4 is available, then that dampens the need for v6, no?

See what I mean?

No, Tim, erecting an artificial brick wall in the road to v4 availability will not push people into v6, given that adopting v6 in the intermediate term also requires more v4 under the dual stack transition approach. Trying to prevent any inter-regional transfers would be one of the most effective strategies ever to drive blocks out of the RIR system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110824/2bbec8df/attachment.htm>

From rudi.daniel at gmail.com  Wed Aug 24 16:13:57 2011
From: rudi.daniel at gmail.com (Rudolph Daniel)
Date: Wed, 24 Aug 2011 16:13:57 -0400
Subject: [arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIR
	transfers
In-Reply-To: <CAGkMwz7F4zd9wm9dt5AYa9eR=XkL=dkXkedgPJ_ifPwC1yC8gg@mail.gmail.com>
References: <CA+uaoiWhc=2CvET7peawusW+LAV8zcd2yff0z0GWQ-vDMoXUXg@mail.gmail.com>
	<CAGkMwz7F4zd9wm9dt5AYa9eR=XkL=dkXkedgPJ_ifPwC1yC8gg@mail.gmail.com>
Message-ID: <CA+uaoiWd4Fb5H7H_0_Tx6mtQYUe449hiYYM=CR6hUfh+2BiiMg@mail.gmail.com>

Scott
>>That is the approach favored by ARIN-2011-9 Global Policy for post
>>exhaustion IPv4 allocation mechanisms by the IANA.  I support that
>>policy as well, but I think it will be insufficient, as organizations
>>holding valuable address space.......

And lets say a  multi national has legacy space in ARIN also does business
in (example) RIPE and decides it can profit from off- loading to another
party who is only present in RIPE or LACNIC ...
Present conditions allows the legacy space owner to leverage his presence
across RIRs to trade outside the RIR system?
Therefore pro-096 is basically a loophole closer?


RD


On Wed, Aug 24, 2011 at 1:38 PM, Scott Leibrand <scottleibrand at gmail.com>wrote:

> On Wed, Aug 24, 2011 at 9:15 AM, Rudolph Daniel <rudi.daniel at gmail.com>
> wrote:
> > This prop-156 ..I am trying to comprehend why we would be wanting to
> > transfer resources from ARIN to another "RIR's  member" when RIRs have
> the
> > potential to all have slightly different transfer policies?
>
> Most RIRs now have transfer policies in place that allow addresses to
> be transferred between organizations within the RIR's region.  That is
> likely to result in a transfer market, where the prices are set by
> supply of and demand for IPv4 space.  The ARIN region has a larger
> amount of legacy address space than the other RIRs, and a relatively
> mature market that is no longer growing at tremendous rates.  Other
> regions, such as APNIC, have almost no legacy address space and are
> still growing much faster.  Without some mechanism to allow address
> space to be transferred between regions, prices for IPv4 addresses are
> likely to be much higher in regions like APNIC than within the ARIN
> region.  That will encourage organizations to transfer addresses from
> ARIN to those other regions however they can, either by obtaining it
> here and using it elsewhere, or by engaging in de facto transfers
> outside the RIR system.  IMO we want to avoid that by allowing
> inter-RIR transfers to occur within the RIR system.
>
> > Or are we asking all RIRs to consider needs based policies akin to ARIN?
>
> That is what draft policy ARIN-2011-1 asks.  APNIC will be considering
> a proposal (prop-096) to reinstate needs basis for transfers at their
> Busan meeting next week.  If prop-096 is adopted, I think ARIN-2011-1
> would be adequate and ARIN-prop-156 would likely not be necessary.  If
> not, then ARIN-2011-1 is a no-op (at least with respect to APNIC), and
> ARIN-prop-156 would be needed.
>
> > Is it not more effective to deal with transfers between RIRs  and leave
> the
> > respective RIR to deal with its own members.?
>
> That is the approach favored by ARIN-2011-9 Global Policy for post
> exhaustion IPv4 allocation mechanisms by the IANA.  I support that
> policy as well, but I think it will be insufficient, as organizations
> holding valuable address space largely won't want to return it to ARIN
> for redistribution to other regions.  They would be much more likely
> to be willing to transfer the space to an APNIC member if they could
> receive some form of compensation for doing so.
>
> Hope that helps,
> -Scott (speaking only for myself, as always)
>



-- 

Rudi Daniel
*danielcharles consulting<http://www.facebook.com/pages/Kingstown-Saint-Vincent-and-the-Grenadines/DanielCharles/153611257984774>
**1-784 498 8277<http://www.facebook.com/pages/Kingstown-Saint-Vincent-and-the-Grenadines/DanielCharles/153611257984774>
*
*
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110824/2d85a47a/attachment.htm>

From scottleibrand at gmail.com  Wed Aug 24 16:18:26 2011
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Wed, 24 Aug 2011 13:18:26 -0700
Subject: [arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIR
	transfers
In-Reply-To: <CA+uaoiWd4Fb5H7H_0_Tx6mtQYUe449hiYYM=CR6hUfh+2BiiMg@mail.gmail.com>
References: <CA+uaoiWhc=2CvET7peawusW+LAV8zcd2yff0z0GWQ-vDMoXUXg@mail.gmail.com>
	<CAGkMwz7F4zd9wm9dt5AYa9eR=XkL=dkXkedgPJ_ifPwC1yC8gg@mail.gmail.com>
	<CA+uaoiWd4Fb5H7H_0_Tx6mtQYUe449hiYYM=CR6hUfh+2BiiMg@mail.gmail.com>
Message-ID: <CAGkMwz7PrzQyW6e5xp1BGsg-doOzVHTptJMBo+Q3F=VcE1Uu1w@mail.gmail.com>

On Wed, Aug 24, 2011 at 1:13 PM, Rudolph Daniel <rudi.daniel at gmail.com>wrote:

> Scott
>
> >>That is the approach favored by ARIN-2011-9 Global Policy for post
> >>exhaustion IPv4 allocation mechanisms by the IANA.  I support that
> >>policy as well, but I think it will be insufficient, as organizations
> >>holding valuable address space.......
>
> And lets say a  multi national has legacy space in ARIN also does business
> in (example) RIPE and decides it can profit from off- loading to another
> party who is only present in RIPE or LACNIC ...
> Present conditions allows the legacy space owner to leverage his presence
> across RIRs to trade outside the RIR system?
>

Not really.  At the moment, the legacy holder could not transfer those
addresses to the other party within the RIR system.  They'd have to
structure it as some sort of long-term lease, and then SWIP it to the other
party, or they'd have to go outside the RIR system completely to record the
transfer. (Which has a number of risks for both parties, and means WHOIS is
not kept up to date.)


> Therefore pro-096 is basically a loophole closer?
>

Are you referring to APNIC prop-096 (Maintaining demonstrated needs
requirement in transfer policy after the final /8 phase) or ARIN-prop-156
(Update 8.3 to allow inter-RIR transfers)?

-Scott


On Wed, Aug 24, 2011 at 1:38 PM, Scott Leibrand <scottleibrand at gmail.com>wrote:
>
>> On Wed, Aug 24, 2011 at 9:15 AM, Rudolph Daniel <rudi.daniel at gmail.com>
>> wrote:
>> > This prop-156 ..I am trying to comprehend why we would be wanting to
>> > transfer resources from ARIN to another "RIR's  member" when RIRs have
>> the
>> > potential to all have slightly different transfer policies?
>>
>> Most RIRs now have transfer policies in place that allow addresses to
>> be transferred between organizations within the RIR's region.  That is
>> likely to result in a transfer market, where the prices are set by
>> supply of and demand for IPv4 space.  The ARIN region has a larger
>> amount of legacy address space than the other RIRs, and a relatively
>> mature market that is no longer growing at tremendous rates.  Other
>> regions, such as APNIC, have almost no legacy address space and are
>> still growing much faster.  Without some mechanism to allow address
>> space to be transferred between regions, prices for IPv4 addresses are
>> likely to be much higher in regions like APNIC than within the ARIN
>> region.  That will encourage organizations to transfer addresses from
>> ARIN to those other regions however they can, either by obtaining it
>> here and using it elsewhere, or by engaging in de facto transfers
>> outside the RIR system.  IMO we want to avoid that by allowing
>> inter-RIR transfers to occur within the RIR system.
>>
>> > Or are we asking all RIRs to consider needs based policies akin to ARIN?
>>
>> That is what draft policy ARIN-2011-1 asks.  APNIC will be considering
>> a proposal (prop-096) to reinstate needs basis for transfers at their
>> Busan meeting next week.  If prop-096 is adopted, I think ARIN-2011-1
>> would be adequate and ARIN-prop-156 would likely not be necessary.  If
>> not, then ARIN-2011-1 is a no-op (at least with respect to APNIC), and
>> ARIN-prop-156 would be needed.
>>
>> > Is it not more effective to deal with transfers between RIRs  and leave
>> the
>> > respective RIR to deal with its own members.?
>>
>> That is the approach favored by ARIN-2011-9 Global Policy for post
>> exhaustion IPv4 allocation mechanisms by the IANA.  I support that
>> policy as well, but I think it will be insufficient, as organizations
>> holding valuable address space largely won't want to return it to ARIN
>> for redistribution to other regions.  They would be much more likely
>> to be willing to transfer the space to an APNIC member if they could
>> receive some form of compensation for doing so.
>>
>> Hope that helps,
>> -Scott (speaking only for myself, as always)
>>
>
>
>
> --
>
> Rudi Daniel
> *danielcharles consulting<http://www.facebook.com/pages/Kingstown-Saint-Vincent-and-the-Grenadines/DanielCharles/153611257984774>
> **1-784 498 8277<http://www.facebook.com/pages/Kingstown-Saint-Vincent-and-the-Grenadines/DanielCharles/153611257984774>
> *
> *
> *
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110824/67cecca9/attachment.htm>

From scottleibrand at gmail.com  Wed Aug 24 16:35:53 2011
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Wed, 24 Aug 2011 13:35:53 -0700
Subject: [arin-ppml] Advisory Council Meeting Results - August 2011
In-Reply-To: <4E5556B9.2080900@arin.net>
References: <4E5556B9.2080900@arin.net>
Message-ID: <CAGkMwz6qkz0+QKiadaEQGmv2Ef2=pULfK27+RwEbn95oDDRiTQ@mail.gmail.com>

On Wed, Aug 24, 2011 at 12:53 PM, ARIN <info at arin.net> wrote:
> In accordance with the ARIN Policy Development Process, the ARIN Advisory
> Council (AC) held a meeting on 18 August 2011 and made decisions about
> several proposals.

And here are my monthly comments.  As always, my opinions only, not
speaking for anyone else.

> The AC selected the following proposals as draft policies for adoption
> discussion online and at the ARIN XXVIII Public Policy Meeting in
> Philadelphia in October. The draft policies will be posted shortly to the
> PPML.
>
> ?ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation mechanisms
> by the IANA

I support this proposal.  IMO it is necessary to avoid stranding IPv4
space at the IANA.

> ?ARIN-prop-144 Remove Single Aggregate requirement from Specified Transfer

I support this proposal, because I feel it is important that our
transfer policy match up with organizations' actual needs.  I would
also support language that requires transfers be performed on the
minimum number of CIDR blocks or address ranges required to transfer
the correct amount of space.

> ?ARIN-prop-146 Clarify Justified Need for Transfers

I support this proposal.  I believe it is a very necessary
clarification and simplification of existing policy intent.

> ?ARIN-prop-147 Set Transfer Need to 24 months

I support this proposal.  Once IPv4 address needs are primarily being
met via transfers, I believe it is important to allow organizations to
meet more than a year's worth of need at a time.

> ?ARIN-prop-155 IPv4 Number Resources for Use Within Region

I oppose the current text, but voted to bring it to Philadelphia for
discussion, as I believe the issue is important, and that policy
clarity here might be beneficial.

> The following proposals were not selected as draft policies at this time:
>
> ?ARIN-prop-151 Limiting needs requirements for IPv4 Transfers
>
> The AC as a whole felt that the text of proposal 151 was not ready enough to
> move forward to draft policy. The AC is hoping to gain more input through
> the PPML and at the upcoming Public Policy Meeting.

I don't support the current text, but voted to bring it to
Philadelphia for discussion, as I believe it raises a number of issues
that we need community input on.  Obviously the majority of the AC
disagreed and felt it wasn't ready for discussion.

> ?ARIN-prop-153 Correct erroneous syntax in NRPM 8.3
>
> Since ARIN-Prop-153 was in direct conflict with ARIN-Prop-144, which the
> AC had already advanced to Draft Policy status and adoption discussion on
> PPML and at the next Public Policy Meeting in Philadelphia, the motion to
> select ARIN-Prop-153 as Draft Policy did not carry. Since there was no
> motion to abandon and in accordance with the ARIN Policy Development
> Process, ARIN-Prop-153 remains on the AC's docket.

I don't support this language, but felt it would be best to have this
proposal on the docket in Philadelphia as an alternative to
ARIN-Prop-144.  Obviously the majority of the AC disagreed.

> The AC abandoned the following proposals:
>
> ?ARIN-prop-149 Improved Transparency for Directed Transfers
>
> The AC feels that proposal 149 belongs in the consultation and suggestion
> process as it is a recommendation to staff to publish a list and is not
> addressing policy. The author has been advised of the AC's abandon action
> and has already submitted this to the ARIN Consultation and Suggestion
> Process (ACSP).

I don't feel strongly either way about which venue this should be discussed in.

> ?ARIN-prop-152 RSA Modification Limits
>
> The AC feels that based upon the Clarity and Understanding from
> Staff, proposal 152 is inappropriate for the NRPM. The author has
> been advised of the AC's abandon action.

Agreed.

> The AC thanks the authors and the community for their continuing effort
> and contributions to these and all other policy considerations.

And wholeheartedly agreed, as always!

-Scott


From owen at delong.com  Wed Aug 24 16:38:59 2011
From: owen at delong.com (Owen DeLong)
Date: Wed, 24 Aug 2011 13:38:59 -0700
Subject: [arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIR
	transfers
In-Reply-To: <75822E125BCB994F8446858C4B19F0D7175496FF8D@SUEX07-MBX-04.ad.syr.edu>
References: <4E53F59A.4010803@arin.net> <667141AF2AE74F33878F2A368C40B22B@mike>
	<CAGkMwz5i03xw-nNsyrwBKUirCDws9bkPDxT-Q5UOMLYRQPfY_A@mail.gmail.com>
	<9B7002B514644AC493E7AE344F23787A@mike>
	<75822E125BCB994F8446858C4B19F0D7175496FF81@SUEX07-MBX-04.ad.syr.edu>
	<CACAaNxiywhfQo0wds9d0DV8ybR6n5+xQDF1_ju0hi8hQraSOxA@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D7175496FF8D@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <5AE91434-0872-4C18-BC77-9EB0AD73E2BA@delong.com>


On Aug 24, 2011, at 1:01 PM, Milton L Mueller wrote:

>  
>  
>  
> My reading of your techliberation article suggests to me that you are in favor of  "driving v4 address blocks out of the RIR system."
>  
> Not at all, I am trying to save the RIRs from themselves.
> (Wish me luck, my damsel in distress hates my guts and seems to prefer the company of the fire-breathing dragon. Occasionally I am tempted to let her burn?but I usually chivalry prevails)
>  

Milton,

Believe it or not, not everyone who disagrees with you or does not share your extreme libertarian point of view on how things do or should work is in distress or in danger from a fire breathing dragon. In fact, to our perspective, the future you would create for us breathes much more fire than any we might embrace.

> In terms of "thinking outside of the box" I'd be happy NOT to even entertain the notion of inter-regional transfers.  If we want the v6 transition to accelerate, there has got to be demand for v6.  If v4 is available, then that dampens the need for v6, no?
>  
> See what I mean?
>  
> No, Tim, erecting an artificial brick wall in the road to v4 availability will not push people into v6, given that adopting v6 in the intermediate term also requires more v4 under the dual stack transition approach. Trying to prevent any inter-regional transfers would be one of the most effective strategies ever to drive blocks out of the RIR system.

If you dismantle the RIR system in the process of attempting to retain blocks within it, then, there is no RIR system left to contain the blocks. While this appears to be well in line with your actual goals (private registries, chaos, etc.), I don't consider it a desirable outcome.

Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110824/c7107cf7/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2105 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110824/c7107cf7/attachment.p7s>

From owen at delong.com  Wed Aug 24 16:41:06 2011
From: owen at delong.com (Owen DeLong)
Date: Wed, 24 Aug 2011 13:41:06 -0700
Subject: [arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIR
	transfers
In-Reply-To: <CA+uaoiWd4Fb5H7H_0_Tx6mtQYUe449hiYYM=CR6hUfh+2BiiMg@mail.gmail.com>
References: <CA+uaoiWhc=2CvET7peawusW+LAV8zcd2yff0z0GWQ-vDMoXUXg@mail.gmail.com>
	<CAGkMwz7F4zd9wm9dt5AYa9eR=XkL=dkXkedgPJ_ifPwC1yC8gg@mail.gmail.com>
	<CA+uaoiWd4Fb5H7H_0_Tx6mtQYUe449hiYYM=CR6hUfh+2BiiMg@mail.gmail.com>
Message-ID: <F02D98E6-3AD4-4722-9D83-8FAA0F0049F2@delong.com>


On Aug 24, 2011, at 1:13 PM, Rudolph Daniel wrote:

> Scott
> >>That is the approach favored by ARIN-2011-9 Global Policy for post
> >>exhaustion IPv4 allocation mechanisms by the IANA.  I support that
> >>policy as well, but I think it will be insufficient, as organizations
> >>holding valuable address space.......
> 
> And lets say a  multi national has legacy space in ARIN also does business in (example) RIPE and decides it can profit from off- loading to another party who is only present in RIPE or LACNIC ...
> Present conditions allows the legacy space owner to leverage his presence across RIRs to trade outside the RIR system?

No. The legacy space in question would be tied to one particular RIR.

> Therefore pro-096 is basically a loophole closer?
> 
> 
> RD
> 
> 
> On Wed, Aug 24, 2011 at 1:38 PM, Scott Leibrand <scottleibrand at gmail.com> wrote:
> On Wed, Aug 24, 2011 at 9:15 AM, Rudolph Daniel <rudi.daniel at gmail.com> wrote:
> > This prop-156 ..I am trying to comprehend why we would be wanting to
> > transfer resources from ARIN to another "RIR's  member" when RIRs have the
> > potential to all have slightly different transfer policies?
> 
> Most RIRs now have transfer policies in place that allow addresses to
> be transferred between organizations within the RIR's region.  That is
> likely to result in a transfer market, where the prices are set by
> supply of and demand for IPv4 space.  The ARIN region has a larger
> amount of legacy address space than the other RIRs, and a relatively
> mature market that is no longer growing at tremendous rates.  Other
> regions, such as APNIC, have almost no legacy address space and are
> still growing much faster.  Without some mechanism to allow address
> space to be transferred between regions, prices for IPv4 addresses are
> likely to be much higher in regions like APNIC than within the ARIN
> region.  That will encourage organizations to transfer addresses from
> ARIN to those other regions however they can, either by obtaining it
> here and using it elsewhere, or by engaging in de facto transfers
> outside the RIR system.  IMO we want to avoid that by allowing
> inter-RIR transfers to occur within the RIR system.
> 
> > Or are we asking all RIRs to consider needs based policies akin to ARIN?
> 
> That is what draft policy ARIN-2011-1 asks.  APNIC will be considering
> a proposal (prop-096) to reinstate needs basis for transfers at their
> Busan meeting next week.  If prop-096 is adopted, I think ARIN-2011-1
> would be adequate and ARIN-prop-156 would likely not be necessary.  If
> not, then ARIN-2011-1 is a no-op (at least with respect to APNIC), and
> ARIN-prop-156 would be needed.
> 
> > Is it not more effective to deal with transfers between RIRs  and leave the
> > respective RIR to deal with its own members.?
> 
> That is the approach favored by ARIN-2011-9 Global Policy for post
> exhaustion IPv4 allocation mechanisms by the IANA.  I support that
> policy as well, but I think it will be insufficient, as organizations
> holding valuable address space largely won't want to return it to ARIN
> for redistribution to other regions.  They would be much more likely
> to be willing to transfer the space to an APNIC member if they could
> receive some form of compensation for doing so.
> 
> Hope that helps,
> -Scott (speaking only for myself, as always)
> 
> 
> 
> -- 
> 
> Rudi Daniel
> danielcharles consulting
> 1-784 498 8277
> 
> 
> 
> _______________________________________________
> 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/20110824/c9d9ecca/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2105 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110824/c9d9ecca/attachment.p7s>

From jeffrey.lyon at blacklotus.net  Wed Aug 24 17:16:57 2011
From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon)
Date: Wed, 24 Aug 2011 17:16:57 -0400
Subject: [arin-ppml] Prop-151 -- Still a bad idea (was a thread hijack
	of prop-156)
In-Reply-To: <A66CB2E1-4321-4D34-A2BE-783B302FF509@delong.com>
References: <4E53F59A.4010803@arin.net> <667141AF2AE74F33878F2A368C40B22B@mike>
	<CAGkMwz5i03xw-nNsyrwBKUirCDws9bkPDxT-Q5UOMLYRQPfY_A@mail.gmail.com>
	<9B7002B514644AC493E7AE344F23787A@mike>
	<A66CB2E1-4321-4D34-A2BE-783B302FF509@delong.com>
Message-ID: <CACrmG8cW3YU2sAcBeGy-KhjNohwhesLPkK+2aYLd_redvSzAaQ@mail.gmail.com>

So APNIC has abandoned needs basis -- that's still ~18% of all
non-unicast space which is still fairly significant.

Jeff

On Wed, Aug 24, 2011 at 1:02 PM, Owen DeLong <owen at delong.com> wrote:
>
> On Aug 24, 2011, at 6:54 AM, Mike Burns wrote:
>
>> I would like to point out that some of the comments relating to 156 involve issues of "fairness" in terms of applying less stringent standards to the proposed transfers than applied to ARIN members, and others involve issues of perceived ARIN bullying from its position of strength on this issue.
>>
>> Both issues would dissolve, as would so many others, with the adoption of my proposal 151 to treat legacy and non-legacy addresses fairly by removing the outdated and unnecessary needs requirement on IPv4 transfers.
>>
>
> Needs-basis is neither outdated nor unnecessary. APNIC stands alone as the only RIR to abandon needs basis so far.
>
> I do not believe that encouraging ARIN to follow suit improves the situation.
>
>> Given the situation, we are virtually mandating transfers (of legacy space at least) of address space outside the RIR system entirely.
>> The resultant irrelevance of Whois data will drive the acceptance of private registries.
>>
>
> Not really, no. Will some of those occur? Perhaps. Probably even. They aren't without risk. I'm OK with that.
>
> I don't believe that they will occur in large enough volume to render whois irrelevant and I am not convinced that private
> registries would do anything other than further devolve the situation.
>
> If you want an example of the chaos and dysfunction that ensues when you remove rational controls, just look at
> the domain name system and it's devolution into anyone can have a TLD for the right price.
>
>> In this article, http://techliberation.com/2011/08/15/trading-ipv4-addresses-starts-making-internet-elders-nervous/ ,Prof. Mueller relates a conversation with the broker who handled the Microsoft/Nortel IPv4 sale. ?That broker mentions a point which is entirely relevant to my proposal, which is the fact that of all the 38 (!) IP blocks included in the sale, not a single one had correct Whois data.
>>
>
> I don't see how the fact that the organization(s) failed to meet their obligations to maintain their registrations is relevant or makes any sort of case in favor of your proposal. The community sets rules. Organizations may or may not follow those rules. I don't see how the fact that some organization(s) failed to follow the rules is indicative that the rules should be eliminated.
>
> That's like making the argument that because some people commit armed robbery, we should remove the laws against armed robbery. This makes no sense to me.
>
>> As IPv6 remains stillborn, IPv4 address values will increase.
>
> IPv6 was not, is not, and does not remain stillborn.
>
>> As the values increase there will be conflict over ownership rights.
>> Those conflicts will be settled in court eventually, and Whois will come to be publicly displayed as erroneous and irrelevant.
>
> Do you have any evidence to support this claim?
>
> Could whois be better? Yes. There are multiple efforts underway to improve the quality of data in whois and I have supported policies and suggestions to encourage ARIN to put more resources into improving the quality of data in whois.
>
> However, the current error rate in whois is far from irrelevant and there is, frankly, absolutely no better alternative available at this time.
>
>> Owners will demand a more reliable registration system to ensure their rights are recognized, and network operators will feel more protected by a registry which backs their entries with chain-of-custody documents.
>
> First, IP addresses themselves are not property. The registration system is entirely reliable and registrants who work within it are guaranteed that their rights are recognized. This theory that integers can somehow was amusing to me until I started seeing some of the current software patent wars unfold. It does appear that the courts have become so dysfunctional that you could very well see a day when everyone has to pay someone a royalty every time they use a 5. However, at that point, we have much bigger problems than whois accuracy to contend with.
>
> Until the courts become that much more dysfunctional than they already are, I think we should, instead, focus on the current reality. That is that any inaccuracies in whois are the result of resource holders failing to register their current data. The process for updating your data is relatively simple and painless. It costs nothing. As such, any resource holder who feels that their rights have been supplanted by whois inaccuracy has noone to blame but themselves.
>
>> By maintaining a needs requirement for transfers, we are on the path to a dramatic change in Internet governance, which we can avoid by refusing to continue policies which work in restraint of the free trading of IPv4 addresses.
>>
>
> Abandoning the needs basis would be a dramatic change in internet governance, so, I'm really not sure how you can claim that we can avoid a dramatic change in internet governance by making one.
>
>> I applaud Scott's efforts to make a bad situation a little better, but suggest that the problems he addresses in his rationale would be mooted by acceptance of Prop 151.
>>
>
> They'd also be mooted by adoption of APNIC Prop-096 which is, IMHO, a far better solution and would work well with 2011-1.
>
>> I guess this is a thread hijack, but there is still time for expressions of support for 151 as it has not been abandoned.
>>
>
> Yes, you are correct on both counts. Lots of time since neither of them is likely to be on the agenda for adoption in Philadelphia.
>
> There is also time to support APNIC proposal 96 which is going up for discussion in Busan next week and time to support 2011-1 which will be up for adoption discussion in Philadelphia.
>
> Owen
>
>> Regards,
>> Mike
>>
>>
>>
>>
>> ----- Original Message ----- From: "Scott Leibrand" <scottleibrand at gmail.com>
>> To: "Mike Burns" <mike at nationwideinc.com>
>> Cc: "ARIN" <info at arin.net>; <arin-ppml at arin.net>
>> Sent: Tuesday, August 23, 2011 8:48 PM
>> Subject: Re: [arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIR transfers
>>
>>
>> On Tue, Aug 23, 2011 at 12:07 PM, Mike Burns <mike at nationwideinc.com> wrote:
>>> Support, but I would support more with a 12-month justification and it would
>>> be better with no justification requirement at all.
>>
>> Thanks. ?I'd like to hear input from more folks on what this
>> requirement should look like.
>>
>>> This change will allow some Asian companies to participate in legitimate
>>> transfers with Whois updates, who would otherwise have to take the risks of
>>> an unbooked sale.
>>> Would this policy be consistent with the ideas about regional registries
>>> that was discussed on the list earlier in reference to ICP-2?
>>
>> Yes, because we're transferring the addresses (under certain
>> conditions) to another RIR for them to administer in their region.
>>
>>> Is this change in 8.3 an endrun around the concept of regionality?
>>
>> I don't believe so.
>>
>> -Scott
>>
>>
>>> ----- Original Message ----- From: "ARIN" <info at arin.net>
>>> To: <arin-ppml at arin.net>
>>> Sent: Tuesday, August 23, 2011 2:46 PM
>>> Subject: [arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIR transfers
>>>
>>>
>>>> ARIN-prop-156 Update 8.3 to allow inter-RIR transfers
>>>>
>>>> ARIN received the following policy proposal and is posting it to the
>>>> Public Policy Mailing List (PPML) in accordance with the Policy
>>>> Development Process.
>>>>
>>>> The ARIN Advisory Council (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.
>>>>
>>>> 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.
>>>>
>>>> Draft Policies and Proposals under discussion can be found at:
>>>> https://www.arin.net/policy/proposals/index.html
>>>>
>>>> The ARIN Policy Development Process can be found at:
>>>> https://www.arin.net/policy/pdp.html
>>>>
>>>> Mailing list subscription information can be found
>>>> at: https://www.arin.net/mailing_lists/
>>>>
>>>> Regards,
>>>>
>>>> Communications and Member Services
>>>> American Registry for Internet Numbers (ARIN)
>>>>
>>>> ## * ##
>>>>
>>>> ARIN-prop-156 Update 8.3 to allow inter-RIR transfers
>>>>
>>>> Proposal Originator: Scott Leibrand
>>>>
>>>> Date: 23 August 2011
>>>>
>>>> Proposal type: Modify
>>>>
>>>> Policy term: Permanent
>>>>
>>>> Policy statement:
>>>>
>>>> 8.3. Transfers to Specified Recipients
>>>>
>>>> In addition to transfers under section 8.2, IPv4 number resources may
>>>> be released to ARIN by the authorized resource holder, in whole or in
>>>> part, for transfer:
>>>>
>>>> + under RSA, to specified organizational recipient(s) within the ARIN
>>>> region that can demonstrate the need for such resources, in the exact
>>>> amount which they can justify under current ARIN policies.
>>>>
>>>> + to another RIR, for transfer to a specified recipient in that RIR's
>>>> service region who demonstrates plans to deploy the resources for the
>>>> justified purpose within 3 months, as long as the request meets the
>>>> policy requirements of both RIRs, and the recipient (and any
>>>> organizations to which they have transferred or reassigned space) can
>>>> show efficient utilization of all prior allocations, assignments, and
>>>> transfers according to the current policy requirements of both RIRs.
>>>>
>>>>
>>>> Rationale:
>>>>
>>>> A number of RIRs already allow IPv4 address transfers within their
>>>> service regions. Given that IPv4 address demand is concentrated in
>>>> certain rapidly growing regions, whereas IPv4 addresses that can be
>>>> made available to supply that demand are concentrated in regions with
>>>> more historical IPv4 deployment, it would be most efficient for
>>>> addresses to be transferred from regions with more supply to regions
>>>> with more demand. If this is not allowed, prices for IPv4 addresses
>>>> in high-demand regions will be higher, raising overall costs,
>>>> encouraging address holders to transfer addresses outside the RIR
>>>> system, and/or encouraging large corporations to acquire addresses in
>>>> regions with more supply and then use them in regions with more
>>>> demand. It would be better for the overall Internet industry to allow
>>>> inter-RIR transfers to organizations with demonstrated need for
>>>> addressing for immediate deployment needs.
>>>>
>>>> This policy text would be intended to replace draft policy 2011-1 ARIN
>>>> Inter-RIR Transfers.
>>>>
>>>> Timetable for implementation: Immediate
>>>>
>>>> _______________________________________________
>>>> 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.
>
> _______________________________________________
> 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.
>



-- 
Jeffrey Lyon, Leadership Team
jeffrey.lyon at blacklotus.net | http://www.blacklotus.net
Black Lotus Communications - AS32421
First and Leading in DDoS Protection Solutions


From pwilson at apnic.net  Wed Aug 24 19:43:32 2011
From: pwilson at apnic.net (Paul Wilson)
Date: Thu, 25 Aug 2011 09:43:32 +1000
Subject: [arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIR
	transfers
In-Reply-To: <CACAaNxiywhfQo0wds9d0DV8ybR6n5+xQDF1_ju0hi8hQraSOxA@mail.gmail.com>
References: <4E53F59A.4010803@arin.net> <667141AF2AE74F33878F2A368C40B22B@mike>
	<CAGkMwz5i03xw-nNsyrwBKUirCDws9bkPDxT-Q5UOMLYRQPfY_A@mail.gmail.com>
	<9B7002B514644AC493E7AE344F23787A@mike>
	<75822E125BCB994F8446858C4B19F0D7175496FF81@SUEX07-MBX-04.ad.syr.edu>
	<CACAaNxiywhfQo0wds9d0DV8ybR6n5+xQDF1_ju0hi8hQraSOxA@mail.gmail.com>
Message-ID: <7313B625-6CC5-475E-B0A7-B544FD8ED1EB@apnic.net>


On 25/08/2011, at 3:11 AM, McTim wrote:

> Perhaps I've missed something?
> 
> In terms of "thinking outside of the box" I'd be happy NOT to even entertain the notion of inter-regional transfers.  If we want the v6 transition to accelerate, there has got to be demand for v6.  If v4 is available, then that dampens the need for v6, no?

Tim,

I would point out two factors here that I believe are uncontroversial:

1. A smooth global IPv6 transition will rely on a critical mass of movement across the Internet;
2. No individual party is strongly motivated to move until they experience a shortage of IPv4 addresses.

At present APNIC can only allocate very small blocks of IPv4, under our "last /8" policy; while other regions have a remaining supply for normal allocations.  RIPE NCC may be in the same position later this year, but ARIN and others have supplies which may last for several years on current projections*.  As a result, the motivation for IPv6 is not evenly distributed, and the environment required for a smooth global IPv6 transition does not (yet) exist.

The availability of inter-regional IPv4 transfers will allow ongoing growth of IPv4 networks in the short term, but (more importantly in my opinion) it will serve to redistribute the motivation for IPv6 more evenly, with positive effect for the eventual IPv6 transition.  Without this, operators in the AP region will have no option but to build networks (some very large) using private IPv4 address space, CGNs and ALGs, and inefficient or partial global IPv6 connectivity.  This outcome I think is not in the best interest of anyone, or of the Internet as a whole.

Paul Wilson
APNIC.


* See http://www.potaroo.net/tools/ipv4/ (second chart)

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

From BillD at cait.wustl.edu  Wed Aug 24 23:06:34 2011
From: BillD at cait.wustl.edu (Bill Darte)
Date: Wed, 24 Aug 2011 22:06:34 -0500
Subject: [arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIRtransfers
References: <4E53F59A.4010803@arin.net> <667141AF2AE74F33878F2A368C40B22B@mike>
	<CAGkMwz5i03xw-nNsyrwBKUirCDws9bkPDxT-Q5UOMLYRQPfY_A@mail.gmail.com>
	<9B7002B514644AC493E7AE344F23787A@mike>
	<75822E125BCB994F8446858C4B19F0D7175496FF81@SUEX07-MBX-04.ad.syr.edu>
	<CACAaNxiywhfQo0wds9d0DV8ybR6n5+xQDF1_ju0hi8hQraSOxA@mail.gmail.com>
	<7313B625-6CC5-475E-B0A7-B544FD8ED1EB@apnic.net>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087915AC2@ex1.cait.wustl.edu>

Hi Paul,

Thanks Paul.... question...
Does the projections you point to for a long tailed ARIN runout include only existing free pool or is it considering the potential legacy returns that could be consumed only within the ARIN region assuming not Inter-RIR transfer capability?

Best,
bd


-----Original Message-----
From: arin-ppml-bounces at arin.net on behalf of Paul Wilson
Sent: Wed 8/24/2011 6:43 PM
To: McTim
Cc: ARIN PPML (ppml at arin.net)
Subject: Re: [arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIRtransfers
 

On 25/08/2011, at 3:11 AM, McTim wrote:

> Perhaps I've missed something?
> 
> In terms of "thinking outside of the box" I'd be happy NOT to even entertain the notion of inter-regional transfers.  If we want the v6 transition to accelerate, there has got to be demand for v6.  If v4 is available, then that dampens the need for v6, no?

Tim,

I would point out two factors here that I believe are uncontroversial:

1. A smooth global IPv6 transition will rely on a critical mass of movement across the Internet;
2. No individual party is strongly motivated to move until they experience a shortage of IPv4 addresses.

At present APNIC can only allocate very small blocks of IPv4, under our "last /8" policy; while other regions have a remaining supply for normal allocations.  RIPE NCC may be in the same position later this year, but ARIN and others have supplies which may last for several years on current projections*.  As a result, the motivation for IPv6 is not evenly distributed, and the environment required for a smooth global IPv6 transition does not (yet) exist.

The availability of inter-regional IPv4 transfers will allow ongoing growth of IPv4 networks in the short term, but (more importantly in my opinion) it will serve to redistribute the motivation for IPv6 more evenly, with positive effect for the eventual IPv6 transition.  Without this, operators in the AP region will have no option but to build networks (some very large) using private IPv4 address space, CGNs and ALGs, and inefficient or partial global IPv6 connectivity.  This outcome I think is not in the best interest of anyone, or of the Internet as a whole.

Paul Wilson
APNIC.


* See http://www.potaroo.net/tools/ipv4/ (second chart)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110824/7fa29ef3/attachment.htm>

From gih at apnic.net  Wed Aug 24 23:29:07 2011
From: gih at apnic.net (Geoff Huston)
Date: Thu, 25 Aug 2011 13:29:07 +1000
Subject: [arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIRtransfers
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D03087915AC2@ex1.cait.wustl.edu>
References: <4E53F59A.4010803@arin.net> <667141AF2AE74F33878F2A368C40B22B@mike>
	<CAGkMwz5i03xw-nNsyrwBKUirCDws9bkPDxT-Q5UOMLYRQPfY_A@mail.gmail.com>
	<9B7002B514644AC493E7AE344F23787A@mike>
	<75822E125BCB994F8446858C4B19F0D7175496FF81@SUEX07-MBX-04.ad.syr.edu>
	<CACAaNxiywhfQo0wds9d0DV8ybR6n5+xQDF1_ju0hi8hQraSOxA@mail.gmail.com>
	<7313B625-6CC5-475E-B0A7-B544FD8ED1EB@apnic.net>
	<EACF8B735E9CBA4B8BAF9E4165D03087915AC2@ex1.cait.wustl.edu>
Message-ID: <CC90B03B-7FB3-44AD-ABEA-88F6B0537934@apnic.net>

Hi Bill,

As you are asking about the projections on http://www.potaroo.net/tools/ipv4/ so I can answer that. The projections for exhaustion in that model assume NO further returns of address space, and only includes the existing free pool.

The model accumulates all available space, and attributes it to the RIR who has the administrative responsibility for that address block. The table of available space per RIR is reported on that report. The model then generates an allocation model using historical allocation data, and uses this allocation model to forward project consumption of the current pool of available space for each RIR.

regards,

  Geoff




On 25/08/2011, at 1:06 PM, Bill Darte wrote:

> Hi Paul,
> 
> Thanks Paul.... question...
> Does the projections you point to for a long tailed ARIN runout include only existing free pool or is it considering the potential legacy returns that could be consumed only within the ARIN region assuming not Inter-RIR transfer capability?
> 
> Best,
> bd



From BillD at cait.wustl.edu  Thu Aug 25 10:08:29 2011
From: BillD at cait.wustl.edu (Bill Darte)
Date: Thu, 25 Aug 2011 09:08:29 -0500
Subject: [arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIRtransfers
References: <4E53F59A.4010803@arin.net> <667141AF2AE74F33878F2A368C40B22B@mike>
	<CAGkMwz5i03xw-nNsyrwBKUirCDws9bkPDxT-Q5UOMLYRQPfY_A@mail.gmail.com>
	<9B7002B514644AC493E7AE344F23787A@mike>
	<75822E125BCB994F8446858C4B19F0D7175496FF81@SUEX07-MBX-04.ad.syr.edu>
	<CACAaNxiywhfQo0wds9d0DV8ybR6n5+xQDF1_ju0hi8hQraSOxA@mail.gmail.com>
	<7313B625-6CC5-475E-B0A7-B544FD8ED1EB@apnic.net>
	<EACF8B735E9CBA4B8BAF9E4165D03087915AC2@ex1.cait.wustl.edu>
	<CC90B03B-7FB3-44AD-ABEA-88F6B0537934@apnic.net>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087915AC6@ex1.cait.wustl.edu>

Thanks Geoff.
Thought that needed to be clear. Appreciate your support of the conversation.
bd


-----Original Message-----
From: Geoff Huston [mailto:gih at apnic.net]
Sent: Wed 8/24/2011 10:29 PM
To: Bill Darte
Cc: Paul Wilson; ARIN PPML
Subject: Re: [arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIRtransfers
 
Hi Bill,

As you are asking about the projections on http://www.potaroo.net/tools/ipv4/ so I can answer that. The projections for exhaustion in that model assume NO further returns of address space, and only includes the existing free pool.

The model accumulates all available space, and attributes it to the RIR who has the administrative responsibility for that address block. The table of available space per RIR is reported on that report. The model then generates an allocation model using historical allocation data, and uses this allocation model to forward project consumption of the current pool of available space for each RIR.

regards,

  Geoff




On 25/08/2011, at 1:06 PM, Bill Darte wrote:

> Hi Paul,
> 
> Thanks Paul.... question...
> Does the projections you point to for a long tailed ARIN runout include only existing free pool or is it considering the potential legacy returns that could be consumed only within the ARIN region assuming not Inter-RIR transfer capability?
> 
> Best,
> bd


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110825/1d9a67df/attachment.htm>

From BillD at cait.wustl.edu  Thu Aug 25 10:16:05 2011
From: BillD at cait.wustl.edu (Bill Darte)
Date: Thu, 25 Aug 2011 09:16:05 -0500
Subject: [arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIRtransfers
References: <4E53F59A.4010803@arin.net> <667141AF2AE74F33878F2A368C40B22B@mike>
	<CAGkMwz5i03xw-nNsyrwBKUirCDws9bkPDxT-Q5UOMLYRQPfY_A@mail.gmail.com>
	<9B7002B514644AC493E7AE344F23787A@mike>
	<75822E125BCB994F8446858C4B19F0D7175496FF81@SUEX07-MBX-04.ad.syr.edu>
	<CACAaNxiywhfQo0wds9d0DV8ybR6n5+xQDF1_ju0hi8hQraSOxA@mail.gmail.com>
	<7313B625-6CC5-475E-B0A7-B544FD8ED1EB@apnic.net>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087915AC7@ex1.cait.wustl.edu>

All,

I think that Paul's point is a very important perspective worth vetting as it goes to the heart of the role of RIR as stewards of their own resources and how they relate to the global community.

Inter-RIR transfers are a means to ensure that available resources go where they are needed. The debate within ARIN community has been...we need the resources we have..or will very soon, so no sense sharing with those who need them now outside of the region.
I believe that Paul's point is that this perspective is counterproductive to ARIN's interests in getting this community to move to IPv6. 

I think the valuation of keeping or sharing addresses should encompass the broadest set of benefits and costs.

Thoughts?

bd


-----Original Message-----
From: arin-ppml-bounces at arin.net on behalf of Paul Wilson
Sent: Wed 8/24/2011 6:43 PM
To: McTim
Cc: ARIN PPML (ppml at arin.net)
Subject: Re: [arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIRtransfers
 

On 25/08/2011, at 3:11 AM, McTim wrote:

> Perhaps I've missed something?
> 
> In terms of "thinking outside of the box" I'd be happy NOT to even entertain the notion of inter-regional transfers.  If we want the v6 transition to accelerate, there has got to be demand for v6.  If v4 is available, then that dampens the need for v6, no?

Tim,

I would point out two factors here that I believe are uncontroversial:

1. A smooth global IPv6 transition will rely on a critical mass of movement across the Internet;
2. No individual party is strongly motivated to move until they experience a shortage of IPv4 addresses.

At present APNIC can only allocate very small blocks of IPv4, under our "last /8" policy; while other regions have a remaining supply for normal allocations.  RIPE NCC may be in the same position later this year, but ARIN and others have supplies which may last for several years on current projections*.  As a result, the motivation for IPv6 is not evenly distributed, and the environment required for a smooth global IPv6 transition does not (yet) exist.

The availability of inter-regional IPv4 transfers will allow ongoing growth of IPv4 networks in the short term, but (more importantly in my opinion) it will serve to redistribute the motivation for IPv6 more evenly, with positive effect for the eventual IPv6 transition.  Without this, operators in the AP region will have no option but to build networks (some very large) using private IPv4 address space, CGNs and ALGs, and inefficient or partial global IPv6 connectivity.  This outcome I think is not in the best interest of anyone, or of the Internet as a whole.

Paul Wilson
APNIC.


* See http://www.potaroo.net/tools/ipv4/ (second chart)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110825/3a150387/attachment.htm>

From cengel at conxeo.com  Thu Aug 25 11:08:51 2011
From: cengel at conxeo.com (Chris Engel)
Date: Thu, 25 Aug 2011 11:08:51 -0400
Subject: [arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIRtransfers
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D03087915AC7@ex1.cait.wustl.edu>
References: <4E53F59A.4010803@arin.net> <667141AF2AE74F33878F2A368C40B22B@mike>
	<CAGkMwz5i03xw-nNsyrwBKUirCDws9bkPDxT-Q5UOMLYRQPfY_A@mail.gmail.com>
	<9B7002B514644AC493E7AE344F23787A@mike>
	<75822E125BCB994F8446858C4B19F0D7175496FF81@SUEX07-MBX-04.ad.syr.edu>
	<CACAaNxiywhfQo0wds9d0DV8ybR6n5+xQDF1_ju0hi8hQraSOxA@mail.gmail.com>
	<7313B625-6CC5-475E-B0A7-B544FD8ED1EB@apnic.net>
	<EACF8B735E9CBA4B8BAF9E4165D03087915AC7@ex1.cait.wustl.edu>
Message-ID: <F55FF9C4FDB76643AE0CEC06D0F5CEB30EBC290050@Skyhawk>

> 
> All,
> 
> I think that Paul's point is a very important perspective worth vetting as it
> goes to the heart of the role of RIR as stewards of their own resources and
> how they relate to the global community.
> 
> Inter-RIR transfers are a means to ensure that available resources go where
> they are needed. The debate within ARIN community has been...we need
> the resources we have..or will very soon, so no sense sharing with those who
> need them now outside of the region.
> I believe that Paul's point is that this perspective is counterproductive to
> ARIN's interests in getting this community to move to IPv6.
> 
> I think the valuation of keeping or sharing addresses should encompass the
> broadest set of benefits and costs.
> 
> Thoughts?
> 
> bd

Unless I'm mistaken, ARIN's mission is to steward efficient allocation of number resources in this region....not to promote the use of one IP protocol over another. Moving to IPv6 certainly solves the limited address space headache that ARIN faces.  It comes with a whole slew of headaches for people in other aspects of the IT game....but that's outside the scope of this discussion list, which is about address allocation. Point is, I can see why alot of folks in ARIN are looking forward to IPv6, as it solves a particular problem that is ARIN's main area of focus. However, that doesn't mean that it should consider "astro-turfing" stewardship of IPv4 resources in order to spur IPv6 transitions. The vibe I've gotten from reading between the lines in some of the posts here is that policy that purposefully spurs IPv4 runout faster should be promoted in order to get IPv6 adopted more quickly. That is very wrong headed thinking, in my opinion.

As long as IPv4 remains useful to some portion of the community in this region then ARIN should do whatever is within it's prevue to efficiently steward those number resources, REGARDLESS of what that means to the speed of IPv6 adoption.

At the same time, ARIN should work to make sure that any barriers that exist in it's policies that would retard IPv6 allocation are minimized. Frankly, I think it's done pretty much that. The headaches that are retarding IPv6 adoption, don't have very much to do with the ability to get an address allocation. They pretty much all boil down to implementation issues.

On point, I'm not really sure that ARIN should be promoting transfer of address space out of this region, at all, if there is a clear case to be made (which I think is self-evident) that there will be a need for those resources in this region. The only legitimate argument I can see is that the allocations have already been made to organizations. If there isn't a legitimate mechanism for transferring them to who they want, will they just bypass ARIN and go ahead and do it anyway...and what are the implications of that?



Christopher Engel 


From narten at us.ibm.com  Fri Aug 26 00:53:02 2011
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 26 Aug 2011 00:53:02 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201108260453.p7Q4r3Zi004538@rotala.raleigh.ibm.com>

Total of 58 messages in the last 7 days.
 
script run at: Fri Aug 26 00:53:02 EDT 2011
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 18.97% |   11 | 23.50% |   126419 | owen at delong.com
 12.07% |    7 | 12.36% |    66497 | info at arin.net
 10.34% |    6 | 11.14% |    59913 | scottleibrand at gmail.com
  6.90% |    4 |  7.18% |    38650 | mueller at syr.edu
  6.90% |    4 |  5.53% |    29729 | bill at herrin.us
  6.90% |    4 |  4.68% |    25181 | joelja at bogus.com
  5.17% |    3 |  5.54% |    29807 | billd at cait.wustl.edu
  5.17% |    3 |  4.99% |    26828 | mike at nationwideinc.com
  3.45% |    2 |  3.90% |    20962 | pwilson at apnic.net
  3.45% |    2 |  3.49% |    18769 | rudi.daniel at gmail.com
  3.45% |    2 |  3.36% |    18093 | randy.whitney at verizon.com
  3.45% |    2 |  2.36% |    12691 | jcurran at arin.net
  1.72% |    1 |  3.25% |    17502 | jeffrey.lyon at blacklotus.net
  1.72% |    1 |  1.96% |    10570 | bensons at queuefull.net
  1.72% |    1 |  1.34% |     7194 | dogwallah at gmail.com
  1.72% |    1 |  1.32% |     7125 | cengel at conxeo.com
  1.72% |    1 |  1.21% |     6534 | heather.skanks at gmail.com
  1.72% |    1 |  1.04% |     5583 | narten at us.ibm.com
  1.72% |    1 |  1.00% |     5373 | gih at apnic.net
  1.72% |    1 |  0.86% |     4636 | hannigan at gmail.com
--------+------+--------+----------+------------------------
100.00% |   58 |100.00% |   538056 | Total


From mike at nationwideinc.com  Mon Aug 29 11:19:56 2011
From: mike at nationwideinc.com (Mike Burns)
Date: Mon, 29 Aug 2011 11:19:56 -0400
Subject: [arin-ppml] An article of interest to the community....
Message-ID: <0619B23D3BCE492DA6BE1096EA3683C5@mike>

Hello all,

http://arstechnica.com/tech-policy/news/2011/08/the-case-for-a-free-market-in-ipv4-addresses.ars


I wonder if I can count Tim Berners Lee as supporting prop 151.

Regards,

Mike Burns

PS here's the counter-argument: http://arstechnica.com/tech-policy/news/2011/08/trading-ipv4-addresses-will-end-in-tears.ars


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110829/7ad0be5e/attachment.htm>

From mike at nationwideinc.com  Mon Aug 29 11:26:51 2011
From: mike at nationwideinc.com (Mike Burns)
Date: Mon, 29 Aug 2011 11:26:51 -0400
Subject: [arin-ppml] An article of interest to the community....
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
	<CAJNn=DOzasDxE3ZwEhjneZmXnkmBvaxQcjrJNWzC6Ubf7xNUNQ@mail.gmail.com>
Message-ID: <778B38DD067C47DE96A0AB38587C69C0@mike>

Lol.

Too bad!

Regards,
Mike

  ----- Original Message ----- 
  From: Jason Duerstock 
  To: Mike Burns 
  Cc: arin-ppml at arin.net 
  Sent: Monday, August 29, 2011 11:22 AM
  Subject: Re: [arin-ppml] An article of interest to the community....


  I don't think Timothy B. Lee and Tim Berners Lee are the same guy.


  Timothy B Lee's bio on the web site: http://arstechnica.com/author/timothy-b-lee/


  Jason


  On Mon, Aug 29, 2011 at 11:19 AM, Mike Burns <mike at nationwideinc.com> wrote:

    Hello all,

    http://arstechnica.com/tech-policy/news/2011/08/the-case-for-a-free-market-in-ipv4-addresses.ars


    I wonder if I can count Tim Berners Lee as supporting prop 151.

    Regards,

    Mike Burns

    PS here's the counter-argument: http://arstechnica.com/tech-policy/news/2011/08/trading-ipv4-addresses-will-end-in-tears.ars




    _______________________________________________
    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/20110829/14e65085/attachment.htm>

From paul at redbarn.org  Mon Aug 29 19:04:35 2011
From: paul at redbarn.org (Paul Vixie)
Date: Mon, 29 Aug 2011 23:04:35 +0000
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
Message-ID: <20110829230435.00005e6a@unknown>

On Mon, 29 Aug 2011 11:19:56 -0400
"Mike Burns" <mike at nationwideinc.com> wrote:

> http://arstechnica.com/tech-policy/news/2011/08/the-case-for-a-free-market-in-ipv4-addresses.ars

since this article referred to my recent op-ed piece in acm queue...

http://queue.acm.org/detail.cfm?id=2008216

...i've replied there as follows:

I think you've misunderstood ARIN's position. ARIN has a designated
transfer policy which allows for private trading in IPv4 number
resources. Potential sellers and buyers (and even brokers) can register
with ARIN to use our listing service, or they can meet up by way of
e-Bay. When it's time to consummate a transaction and register the
resources under the buyer's name, ARIN has a process for that. We did
this to ensure that IPv4 number resources would be maximally utilized
and so that the Whois records would remain accurate -- because this is
what the ARIN community decided via the public policy process. Some
have criticized ARIN's transfer policy because it requires that the
buyer demonstrate a short term need for the number resources they are
receiving, but the ARIN community chose to prevent its transfer policy
being used for hoarding and speculation so those complains might be
coming from potential hoarders and speculators.

Of greater interest to me is the question: "and then what?" That is,
let's imagine that ARIN's transfer policy becomes widely used and all
IPv4 number resources reach what the economists call their "highest and
best use". Would we simply stop growing the internet at that point? Or
would the value of these number resources continue to increase, with
people who can renumber into NAT clouds gradually and forever doing
that in order to free up address space for those whose network growth
is not compatible with NAT? To me that's an unattractive future because
we'll all be spending out time and energy learning how to traverse
multilayer NAT. So to me the need for a global transition to IPv6
remains inevitable no matter what happens in the IPv4 number resources
market. IPv4 is just too small no matter how efficiently the world
learns to use it. Perhaps some investors (and perhaps some speculators)
would be well served by lengthening the lifetime of IPv4 by a few more
years, but the bigger the IPv4 network gets the harder it will be to
pull it through the knothole of the IPv6 transition.

In summary, ARIN has a transfer policy and ARIN stands ready to record
the results of private party transactions in IPv4 numbering resources.
But the real game in the long run is deploying IPv6, not adding a few
years of life or a lot of layers of NAT to the IPv4 network. 
-- 
Paul Vixie


From jcurran at arin.net  Mon Aug 29 19:50:41 2011
From: jcurran at arin.net (John Curran)
Date: Mon, 29 Aug 2011 23:50:41 +0000
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
Message-ID: <5E67682D-0C12-4F33-959C-C6D1556D8D56@arin.net>

On Aug 29, 2011, at 11:19 AM, Mike Burns wrote:

http://arstechnica.com/tech-policy/news/2011/08/the-case-for-a-free-market-in-ipv4-addresses.ars

Mike -

  I also responded to Tim Lee's article in Ars Technica -

The most interesting part about this "article" is that Timothy Lee wrote it without speaking with us at ARIN (despite mentioning ARIN 18 times in the article...) I'll try to be brief in corrections:

First, ARIN doesn't "resist" a market in IP addresses. ARIN implements the policies developed by the Internet community in the region - anyone can participate in the process via mailing list and online remote participation at no cost. So, if you don't like the policies, it's best to go to www.arin.net/participate<http://www.arin.net/participate> and make yourself heard. In the case of being able to monetize IP addresses, ARIN has actually adopted policies which allow exactly that: via the Specified Transfer policy, a party may transfer addresses it doesn't need to a party which does need them. This policy was developed by the community and adopted so that little used IP address blocks won't remain unused, but will instead be put to productive use. If you go to ARIN's website (www.arin.net<http://www.arin.net/>), you will see buttons that say "Got IPv4 Addresses?", "Need More IPv4 Addresses?", and "Facilitating an IPv4 Transfer?" ARIN is doing everything possible to make the transfer process easy.

Second, the suggestion that "they're free to transfer them to whomever they choose, regardless of a needs assessment by ARIN" disregards the fact that a needs-assessment was performed, and that the actual sale order that was approved by the judge was actually modified to reflect ARIN's role as the registry and to require an agreement with ARIN.

ARIN doesn't support or oppose a "open" market; it simply executes the community-developed policies. As such, we cannot set aside the policy of requiring actual need to receive addresses than we can any other policy.

If you happen to be nascent speculator to the IPv4 address market, the requirement to actually needing the addresses for network infrastructure may seem unfair, but it is what the community decided. The requirement that network operators must need address space in order to receive it actually quite similar to how IPv4 address space has been handed out for decades, and Internet service providers are quite familiar with the process of qualifying to receive it.

Tim - If you actually want an interview for your next foray into this area, feel free to contact me:jcurran at arin.net<mailto:jcurran at arin.net> (alternatively, just ask Iljitsch; he knows what he's talking about here... :-)

FYI,
/John

John Curran
President and CEO
ARIN


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110829/3045d1d0/attachment.htm>

From mueller at syr.edu  Tue Aug 30 10:41:46 2011
From: mueller at syr.edu (Milton L Mueller)
Date: Tue, 30 Aug 2011 10:41:46 -0400
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <20110829230435.00005e6a@unknown>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
	<20110829230435.00005e6a@unknown>
Message-ID: <75822E125BCB994F8446858C4B19F0D7175496FFDD@SUEX07-MBX-04.ad.syr.edu>

> -----Original Message-----
> multilayer NAT. So to me the need for a global transition to IPv6
> remains inevitable no matter what happens in the IPv4 number resources
> market. IPv4 is just too small no matter how efficiently the world
> learns to use it. Perhaps some investors (and perhaps some speculators)
> would be well served by lengthening the lifetime of IPv4 by a few more
> years, 

These kinds of comments show a certain lack of sensitivity to the needs of actual network operators. Given the pace of the IPv6 transition, and the fact that even those who migrate must use some combination of NAT and IPv4 to remain compatible with most of the internet, we have no choice but to lengthen the lifetime of IPv4. 
No one knows how long that period will be. Do you? If you've received some divine illumination on that score, by all means publish it. If you are just evangelizing IPv6, spare us, we've heard it 100 times before. 

> but the bigger the IPv4 network gets the harder it will be to
> pull it through the knothole of the IPv6 transition.

Since IPv6 migration REQUIRES a larger IPv4 network during the dual stacking period of transition, this is a pretty "interesting" observation

> In summary, ARIN has a transfer policy and ARIN stands ready to record
> the results of private party transactions in IPv4 numbering resources.

That's good to hear. 



From cengel at conxeo.com  Tue Aug 30 11:51:39 2011
From: cengel at conxeo.com (Chris Engel)
Date: Tue, 30 Aug 2011 11:51:39 -0400
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <75822E125BCB994F8446858C4B19F0D7175496FFDD@SUEX07-MBX-04.ad.syr.edu>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
	<20110829230435.00005e6a@unknown>
	<75822E125BCB994F8446858C4B19F0D7175496FFDD@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <F55FF9C4FDB76643AE0CEC06D0F5CEB30EBC290055@Skyhawk>

> > multilayer NAT. So to me the need for a global transition to IPv6
> > remains inevitable no matter what happens in the IPv4 number resources
> > market. IPv4 is just too small no matter how efficiently the world
> > learns to use it. Perhaps some investors (and perhaps some speculators)
> > would be well served by lengthening the lifetime of IPv4 by a few more
> > years,
> 
> These kinds of comments show a certain lack of sensitivity to the needs of
> actual network operators. Given the pace of the IPv6 transition, and the fact
> that even those who migrate must use some combination of NAT and IPv4 to
> remain compatible with most of the internet, we have no choice but to
> lengthen the lifetime of IPv4.
> No one knows how long that period will be. Do you? If you've received some
> divine illumination on that score, by all means publish it. If you are just
> evangelizing IPv6, spare us, we've heard it 100 times before.
> 
> > but the bigger the IPv4 network gets the harder it will be to
> > pull it through the knothole of the IPv6 transition.
> 
> Since IPv6 migration REQUIRES a larger IPv4 network during the dual stacking
> period of transition, this is a pretty "interesting" observation
> 
> > In summary, ARIN has a transfer policy and ARIN stands ready to record
> > the results of private party transactions in IPv4 numbering resources.
> 
> That's good to hear.
> 

It's pretty clear that there are some here who evangelize on the virtues of IPv6. It's no surprise since the focus of the list is about address utilization and IPv6 does solve that problem admirably. For many of us who's engagement with IT is broader then just address utilization, IPv6 comes with a whole host of problems in other areas that make it undesirable. Which is why you have seen alot of hesitation in adoption of it. I think what you are observing here is a healthy dose of "Lets make it someone else's headache." Those who primarily aren't effected by the negatives IPv6 brings with it are hoping to see a stake driven through the heart of IPv4 so that v6 becomes more useful to them and they don't have to continue to deal with the headaches that limited address space under IPv4 (and some of the measures taken to extend it) cause them and can move on to an environment that is more beneficial to them. Those of us for whom IPv6 is a "crap-tastic" solution are hoping to extend the useful life of IPv4 as much as possible so we can avoid dealing with the problems IPv6 will bring (and hopefully find that some of those problems will be better addressed by the time we need to bring it on board). Also, of course, on both sides of the aisle you have people with monetary interests tied up in the issue, whether it's selling IPv6 solutions or hoping to invest in an IPv4 address market. So it goes.

I think that's the real disconnect. This list is primarily concerned with address resource policy. From the perspective of address policy, IPv6 is pretty much a no brainer as it DOES solve the resource shortage issue admirably. From almost every other perspective, IPv6 stinks on ice and for those of us who would have to deal the problems it presents, it's a no brainer to try to extend the useful life on IPv4 as much as possible.  


Chris Engel





From mike at nationwideinc.com  Tue Aug 30 12:01:14 2011
From: mike at nationwideinc.com (Mike Burns)
Date: Tue, 30 Aug 2011 12:01:14 -0400
Subject: [arin-ppml] An article of interest to the community....
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
	<20110829230435.00005e6a@unknown>
Message-ID: <8ED2D34B24014C23AA5F029110C39DD3@mike>

Hi Paul,

I'm an ARIN facilitator.
Can I run an auction today on eBay for address space?
If eBay requires a letter of approval from ARIN, will that be provided?

As to your issue about what happens after IPv4 is at its best and highest 
use, I have given this some thought over the years.
Have you considered that a robust trading market and CGN might buy us enough 
time to come up with some kind of backward compatible successor protocol to 
IPv4?
Proposals for these kind of solutions have been made in IETF but are 
routinely ignored.
To my mind there is room in the IPv4 header to expand the effective address 
space.
GGN does this effectively and largely transparently today using the 
additional room in the  port number part of the header.
Every TCP connection uses IP+port, and we have 65,000 ports per IPv4 
address.

The dual-stack transition is a failure, it is time to recognize that the 
lack of an economic motive for IPv6 created a situation where dual-stack was 
doomed.
John Curran was right back in 1994, it's time to recognize that now: 
http://tools.ietf.org/html/rfc1669

And we have gotten pretty darn good at traversing NAT already, despite the 
doomsayers.

It does not further your position to openly wonder whether those who 
"complain" are "hoarders and speculators".

Regards,
Mike Burns



----- Original Message ----- 
From: "Paul Vixie" <paul at redbarn.org>
To: <arin-ppml at arin.net>
Sent: Monday, August 29, 2011 7:04 PM
Subject: Re: [arin-ppml] An article of interest to the community....


> On Mon, 29 Aug 2011 11:19:56 -0400
> "Mike Burns" <mike at nationwideinc.com> wrote:
>
>> http://arstechnica.com/tech-policy/news/2011/08/the-case-for-a-free-market-in-ipv4-addresses.ars
>
> since this article referred to my recent op-ed piece in acm queue...
>
> http://queue.acm.org/detail.cfm?id=2008216
>
> ...i've replied there as follows:
>
> I think you've misunderstood ARIN's position. ARIN has a designated
> transfer policy which allows for private trading in IPv4 number
> resources. Potential sellers and buyers (and even brokers) can register
> with ARIN to use our listing service, or they can meet up by way of
> e-Bay. When it's time to consummate a transaction and register the
> resources under the buyer's name, ARIN has a process for that. We did
> this to ensure that IPv4 number resources would be maximally utilized
> and so that the Whois records would remain accurate -- because this is
> what the ARIN community decided via the public policy process. Some
> have criticized ARIN's transfer policy because it requires that the
> buyer demonstrate a short term need for the number resources they are
> receiving, but the ARIN community chose to prevent its transfer policy
> being used for hoarding and speculation so those complains might be
> coming from potential hoarders and speculators.
>
> Of greater interest to me is the question: "and then what?" That is,
> let's imagine that ARIN's transfer policy becomes widely used and all
> IPv4 number resources reach what the economists call their "highest and
> best use". Would we simply stop growing the internet at that point? Or
> would the value of these number resources continue to increase, with
> people who can renumber into NAT clouds gradually and forever doing
> that in order to free up address space for those whose network growth
> is not compatible with NAT? To me that's an unattractive future because
> we'll all be spending out time and energy learning how to traverse
> multilayer NAT. So to me the need for a global transition to IPv6
> remains inevitable no matter what happens in the IPv4 number resources
> market. IPv4 is just too small no matter how efficiently the world
> learns to use it. Perhaps some investors (and perhaps some speculators)
> would be well served by lengthening the lifetime of IPv4 by a few more
> years, but the bigger the IPv4 network gets the harder it will be to
> pull it through the knothole of the IPv6 transition.
>
> In summary, ARIN has a transfer policy and ARIN stands ready to record
> the results of private party transactions in IPv4 numbering resources.
> But the real game in the long run is deploying IPv6, not adding a few
> years of life or a lot of layers of NAT to the IPv4 network.
> -- 
> Paul Vixie
> _______________________________________________
> 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 jcurran at arin.net  Tue Aug 30 13:30:41 2011
From: jcurran at arin.net (John Curran)
Date: Tue, 30 Aug 2011 17:30:41 +0000
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <8ED2D34B24014C23AA5F029110C39DD3@mike>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
	<20110829230435.00005e6a@unknown>
	<8ED2D34B24014C23AA5F029110C39DD3@mike>
Message-ID: <9D5386A8-0B59-4ECC-9421-E8F848B0E87E@arin.net>

On Aug 30, 2011, at 12:01 PM, Mike Burns wrote:

> Hi Paul,

Mike -

I'll answer these, since the Board is not directly involved 
in day-to-day operations.

> I'm an ARIN facilitator.
> Can I run an auction today on eBay for address space?

Yes.

You should put note in the auction noting that bidders be 
eligible to receive the address space per ARIN policies. 
(If you do not, then bidders may have differing or uncertain 
expectations and that does not make for predictable outcomes.)

> If eBay requires a letter of approval from ARIN, will that be provided?

A letter of approval of what?  If any buyers wish to prequalify
(e.g. if you decide to make that a precondition to provide more
auction certainty) then you can readily confirm their status via 
the listing service.

Please do not hesitate to send me mail if you have any further
questions or need assistance in this process.

/John

John Curran
President and CEO
ARIN



From Lee at Dilkie.com  Tue Aug 30 15:19:58 2011
From: Lee at Dilkie.com (Lee Dilkie)
Date: Tue, 30 Aug 2011 15:19:58 -0400
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <8ED2D34B24014C23AA5F029110C39DD3@mike>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>	<20110829230435.00005e6a@unknown>
	<8ED2D34B24014C23AA5F029110C39DD3@mike>
Message-ID: <4E5D37DE.70805@Dilkie.com>


On 8/30/2011 12:01 PM, Mike Burns wrote:
> buy us enough time to come up with some kind of backward compatible
> successor protocol to IPv4? 

no such thing exists... you cannot magically increase the size of
addresses and be backwards compatible. Even NAT, which didn't touch the
size of an address, isn't backwards compatible and broke plenty of
protocols.

You want magic or divine intervention... it doesn't exist. Only plain
old hard work will get us to our mundane goals of moving to ipv6.
There's really nothing to be gained by wishing otherwise.

-lee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110830/44a2ca10/attachment.htm>

From mike at nationwideinc.com  Tue Aug 30 16:06:11 2011
From: mike at nationwideinc.com (Mike Burns)
Date: Tue, 30 Aug 2011 16:06:11 -0400
Subject: [arin-ppml] An article of interest to the community....
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>	<20110829230435.00005e6a@unknown>
	<8ED2D34B24014C23AA5F029110C39DD3@mike> <4E5D37DE.70805@Dilkie.com>
Message-ID: <4FA4451CBBCF41DC9D91AB7D5950B158@mike>

Hi Lee,


Old work and new work on this issue:

http://www.faqs.org/rfcs/rfc1710.html
http://tools.ietf.org/html/rfc6346
https://mice.cs.columbia.edu/getTechreport.php?techreportID=560

The market, left to its own devices, has selected NAT as the pseudo-protocol of choice to facilitate virtually transparent address sharing.
I think there is work undone which would extend NAT to allow customers to have control over even multi-layer NAT and would define clear paths for multi-NAT traversal.
I believe the IETF and the registries have thwarted development in these areas because they see, correctly, that IPv6 is a superior answer to problems of address shortage.

The problem is that IPv6 has no customer demand driving transition, and has thus languished. 

I am not saying that I have a replacement successor protocol to deliver to you, but I look hungrily at the 8 bits of port number space in the header and wonder whether it is possible to effectively multiply our current space by 256, which to me would provide ample headroom and still leave 256 potential ports per address.

And this is in answer to the question posed by Mr. Vixie, which postulated a no-option endpoint at IPv6.

If I had a magic wand to wave, I would wave it and turn the Internet to IPv6 overnight, I wouldn't wave it to create a half-way protocol extension.

But we have no magic wands to wave and exhaustion of the lingua franca staring us in the face.

Regards,

Mike






  ----- Original Message ----- 
  From: Lee Dilkie 
  To: Mike Burns 
  Cc: Paul Vixie ; arin-ppml at arin.net 
  Sent: Tuesday, August 30, 2011 3:19 PM
  Subject: Re: [arin-ppml] An article of interest to the community....



  On 8/30/2011 12:01 PM, Mike Burns wrote: 
    buy us enough time to come up with some kind of backward compatible successor protocol to IPv4? 

  no such thing exists... you cannot magically increase the size of addresses and be backwards compatible. Even NAT, which didn't touch the size of an address, isn't backwards compatible and broke plenty of protocols.

  You want magic or divine intervention... it doesn't exist. Only plain old hard work will get us to our mundane goals of moving to ipv6. There's really nothing to be gained by wishing otherwise.

  -lee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110830/4f726e5d/attachment.htm>

From Lee at Dilkie.com  Tue Aug 30 16:45:30 2011
From: Lee at Dilkie.com (Lee Dilkie)
Date: Tue, 30 Aug 2011 16:45:30 -0400
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <4FA4451CBBCF41DC9D91AB7D5950B158@mike>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>	<20110829230435.00005e6a@unknown>
	<8ED2D34B24014C23AA5F029110C39DD3@mike> <4E5D37DE.70805@Dilkie.com>
	<4FA4451CBBCF41DC9D91AB7D5950B158@mike>
Message-ID: <4E5D4BEA.4080505@Dilkie.com>


On 8/30/2011 4:06 PM, Mike Burns wrote:
> Hi Lee,
>  
>  
> Old work and new work on this issue:
>  
> http://www.faqs.org/rfcs/rfc1710.html
> http://tools.ietf.org/html/rfc6346
> https://mice.cs.columbia.edu/getTechreport.php?techreportID=560
>  
> The market, left to its own devices, has selected NAT as the
> pseudo-protocol of choice to facilitate virtually transparent address
> sharing.

NAT is not address sharing, it's address hiding and it totally
interferes with hosts that wish to "share" addresses.

> I think there is work undone which would extend NAT to allow customers
> to have control over even multi-layer NAT and would define clear paths
> for multi-NAT traversal.
> I believe the IETF and the registries have thwarted development in
> these areas because they see, correctly, that IPv6 is a superior
> answer to problems of address shortage.

and I agree with them, overlapping addressed hosts trying to communicate
with each other is problematic.

>  
> The problem is that IPv6 has no customer demand driving transition,
> and has thus languished.

yes, the problem is that there is no customer visible issue. it's a
technical one.

>  
> I am not saying that I have a replacement successor protocol to
> deliver to you, but I look hungrily at the 8 bits of port number space
> in the header and wonder whether it is possible to effectively
> multiply our current space by 256, which to me would provide ample
> headroom and still leave 256 potential ports per address.

there is no port number in the ipv4 header (or ipv6 for that matter).
The tcp and udp protocols have a 16 bit port in their headers but that's
of no use to ip.

>  
> And this is in answer to the question posed by Mr. Vixie, which
> postulated a no-option endpoint at IPv6.
>  
> If I had a magic wand to wave, I would wave it and turn the Internet
> to IPv6 overnight, I wouldn't wave it to create a half-way protocol
> extension.
>  
> But we have no magic wands to wave and exhaustion of the lingua franca
> staring us in the face.
>  
> Regards,
>  
> Mike
>  
>  

I'm in this for the long haul. There is no need to invent short-sighted
hacks to the addressing problem, just accept that it's going to take a
lot of work to do the right thing and changeout the underlying plumbing
of ip networks. It's not impossible and we've done it before, just need
to accept that it's the right thing to do and get on with the job.

-lee


>  
>  
>  
>  
>
>     ----- Original Message -----
>     *From:* Lee Dilkie <mailto:Lee at Dilkie.com>
>     *To:* Mike Burns <mailto:mike at nationwideinc.com>
>     *Cc:* Paul Vixie <mailto:paul at redbarn.org> ; arin-ppml at arin.net
>     <mailto:arin-ppml at arin.net>
>     *Sent:* Tuesday, August 30, 2011 3:19 PM
>     *Subject:* Re: [arin-ppml] An article of interest to the community....
>
>
>     On 8/30/2011 12:01 PM, Mike Burns wrote:
>>     buy us enough time to come up with some kind of backward
>>     compatible successor protocol to IPv4? 
>
>     no such thing exists... you cannot magically increase the size of
>     addresses and be backwards compatible. Even NAT, which didn't
>     touch the size of an address, isn't backwards compatible and broke
>     plenty of protocols.
>
>     You want magic or divine intervention... it doesn't exist. Only
>     plain old hard work will get us to our mundane goals of moving to
>     ipv6. There's really nothing to be gained by wishing otherwise.
>
>     -lee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110830/73c6992b/attachment.htm>

From info at arin.net  Tue Aug 30 17:38:28 2011
From: info at arin.net (ARIN)
Date: Tue, 30 Aug 2011 17:38:28 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - August 2011
In-Reply-To: <4E5556B9.2080900@arin.net>
References: <4E5556B9.2080900@arin.net>
Message-ID: <4E5D5854.60809@arin.net>

> The AC did not select proposals 151 and 153 as draft policies and
> abandoned proposals 149 and 152. Anyone dissatisfied with these
> decisions may initiate a petition. The petition to advance these
> proposals is the "Discussion Petition." The deadline to begin a
> petition is five business days after the AC's draft meeting minutes
> are published. Note that in order for a petition of any of the
> proposals to be considered successful for the upcoming ARIN XXVIII
> meeting, the petition must be concluded by 6 September 2011 in order
> to meet the requirement of posting as draft policy at least 35 days
> prior to the meeting. If you are considering petitioning, starting one
> earlier is better than later.

The deadline to begin petitions is 7 September 2011. Petitions that end 
successfully by 6 September 2011 will advance draft polices to the ARIN 
XXVIII meeting in Philadelphia. Should a petition end successfully after 
September 6, then the resulting draft policy will go to the ARIN XXIX 
meeting in April 2012.

The AC's draft minutes of their 18 August 2011 meeting are available at:
https://www.arin.net/about_us/ac/index.html

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


On 8/24/11 3:53 PM, ARIN wrote:
> In accordance with the ARIN Policy Development Process, the ARIN
> Advisory Council (AC) held a meeting on 18 August 2011 and made
> decisions about several proposals.
>
> The AC selected the following proposals as draft policies for adoption
> discussion online and at the ARIN XXVIII Public Policy Meeting in
> Philadelphia in October. The draft policies will be posted shortly to
> the PPML.
>
>   ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation
> mechanisms by the IANA
>   ARIN-prop-144 Remove Single Aggregate requirement from Specified
> Transfer
>   ARIN-prop-146 Clarify Justified Need for Transfers
>   ARIN-prop-147 Set Transfer Need to 24 months
>   ARIN-prop-155 IPv4 Number Resources for Use Within Region
>
> The following proposals were not selected as draft policies at this time:
>
>   ARIN-prop-151 Limiting needs requirements for IPv4 Transfers
>   ARIN-prop-153 Correct erroneous syntax in NRPM 8.3
>
> The AC as a whole felt that the text of proposal 151 was not ready
> enough to move forward to draft policy. The AC is hoping to gain more
> input through the PPML and at the upcoming Public Policy Meeting.
>
> Since ARIN-Prop-153 was in direct conflict with ARIN-Prop-144, which the
> AC had already advanced to Draft Policy status and adoption discussion
> on PPML and at the next Public Policy Meeting in Philadelphia, the
> motion to select ARIN-Prop-153 as Draft Policy did not carry. Since
> there was no motion to abandon and in accordance with the ARIN Policy
> Development Process, ARIN-Prop-153 remains on the AC's docket.
>
> The AC abandoned the following proposals:
>
>   ARIN-prop-149 Improved Transparency for Directed Transfers
>   ARIN-prop-152 RSA Modification Limits
>
> The AC feels that proposal 149 belongs in the consultation and
> suggestion process as it is a recomendation to staff to publish a list
> and is not addressing policy. The author has been advised of the AC's
> abandon action and has already submitted this to the ARIN Consultation
> and Suggestion Process (ACSP).
>
> The AC feels that based upon the Clarity and Understanding from
> Staff, proposal 152 is inappropriate for the NRPM. The author has
> been advised of the AC's abandon action.
>
> The AC thanks the authors and the community for their continuing effort
> and contributions to these and all other policy considerations.
>
> The AC did not select proposals 151 and 153 as draft policies and
> abandoned proposals 149 and 152. Anyone dissatisfied with these
> decisions may initiate a petition. The petition to advance these
> proposals is the "Discussion Petition." The deadline to begin a
> petition is five business days after the AC's draft meeting minutes
> are published. Note that in order for a petition of any of the
> proposals to be considered successful for the upcoming ARIN XXVIII
> meeting, the petition must be concluded by 6 September 2011 in order
> to meet the requirement of posting as draft policy at least 35 days
> prior to the meeting. If you are considering petitioning, starting one
> earlier is better than later.
>
> For more information on starting and participating in petitions, see
> PDP Petitions at:
> https://www.arin.net/policy/pdp_petitions.html
>
> Draft Policy and Proposal texts are available at:
> https://www.arin.net/policy/proposals/index.html
>
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
>
> Regards,
>
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)



From owen at delong.com  Tue Aug 30 17:57:53 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 30 Aug 2011 14:57:53 -0700
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <F55FF9C4FDB76643AE0CEC06D0F5CEB30EBC290055@Skyhawk>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
	<20110829230435.00005e6a@unknown>
	<75822E125BCB994F8446858C4B19F0D7175496FFDD@SUEX07-MBX-04.ad.syr.edu>
	<F55FF9C4FDB76643AE0CEC06D0F5CEB30EBC290055@Skyhawk>
Message-ID: <3909A0D9-BDB5-4727-9D49-9D8B798108FD@delong.com>


On Aug 30, 2011, at 8:51 AM, Chris Engel wrote:

>>> multilayer NAT. So to me the need for a global transition to IPv6
>>> remains inevitable no matter what happens in the IPv4 number resources
>>> market. IPv4 is just too small no matter how efficiently the world
>>> learns to use it. Perhaps some investors (and perhaps some speculators)
>>> would be well served by lengthening the lifetime of IPv4 by a few more
>>> years,
>> 
>> These kinds of comments show a certain lack of sensitivity to the needs of
>> actual network operators. Given the pace of the IPv6 transition, and the fact
>> that even those who migrate must use some combination of NAT and IPv4 to
>> remain compatible with most of the internet, we have no choice but to
>> lengthen the lifetime of IPv4.
>> No one knows how long that period will be. Do you? If you've received some
>> divine illumination on that score, by all means publish it. If you are just
>> evangelizing IPv6, spare us, we've heard it 100 times before.
>> 
>>> but the bigger the IPv4 network gets the harder it will be to
>>> pull it through the knothole of the IPv6 transition.
>> 
>> Since IPv6 migration REQUIRES a larger IPv4 network during the dual stacking
>> period of transition, this is a pretty "interesting" observation
>> 
>>> In summary, ARIN has a transfer policy and ARIN stands ready to record
>>> the results of private party transactions in IPv4 numbering resources.
>> 
>> That's good to hear.
>> 
> 
> It's pretty clear that there are some here who evangelize on the virtues of IPv6. It's no surprise since the focus of the list is about address utilization and IPv6 does solve that problem admirably. For many of us who's engagement with IT is broader then just address utilization, IPv6 comes with a whole host of problems in other areas that make it undesirable. Which is why you have seen alot of hesitation in adoption of it. I think what you are observing here is a healthy dose of "Lets make it

Not as undesirable as the coming devolution of IPv4...

The simple reality is that IPv6 really isn't significantly worse than IPv4 in any regard. Yes, there are areas where IPv6 will require some adaptation. Yes, there are some areas where IPv6 provides somewhat different feature sets which will require some changes to business practices. Yes, there are some new vulnerabilities in IPv6 (though there are also some IPv4 security vulnerabilities that are not present in IPv6). However, the simple reality is that the biggest single drawback to IPv6 is the cost of deployment in terms of time, staff training, human resources, and possibly hardware/software upgrades. The next biggest drawback is the number of vendors and systems that have failed to properly prepare and provide IPv6 capable solutions.

The good news is that the vendor problem space is actually shrinking pretty rapidly at this point.

> someone else's headache." Those who primarily aren't effected by the negatives IPv6 brings with it are hoping to see a stake driven through the heart of IPv4 so that v6 becomes more useful to them and they don't have to continue to deal with the headaches that limited address space under IPv4 (and some of the measures taken to extend it) cause them and can move on to an environment that is more beneficial to them. Those of us for whom IPv6 is a "crap-tastic" solution are hoping to exte
> nd the useful life of IPv4 as much as possible so we can avoid dealing with the problems IPv6 will bring (and hopefully find that some of those problems will be better addressed by the time we need to bring it on board). Also, of course, on both sides of the aisle you have people with monetary interests tied up in the issue, whether it's selling IPv6 solutions or hoping to invest in an IPv4 address market. So it goes.
> 

Perhaps, instead, those who see the coming degradation of IPv4 capabilities and the limitations, costs, damage, and dysfunction that will impose realize that we can either move forward with IPv6 and allow IPv4 to wane naturally with a viable alternative in place, or, we can continue on the present path and wait for the internet to suffer an explosive collision with the coming wall. I'm not trying to make it someone else's headache, I'm trying to help others arrive where I have already been. I already live a dual-stack life every day. It's been a relatively painless experience, actually.

Care to point out exactly what these huge detriments you see in IPv6 are? Why you say it is "crap-tastic"? What are these so-called problems IPv6 will bring?

It's not like we're trying to avoid addressing the negatives in IPv6, but, I really don't see anything that is bad enough to warrant your above characterization.

> I think that's the real disconnect. This list is primarily concerned with address resource policy. From the perspective of address policy, IPv6 is pretty much a no brainer as it DOES solve the resource shortage issue admirably. From almost every other perspective, IPv6 stinks on ice and for those of us who would have to deal the problems it presents, it's a no brainer to try to extend the useful life on IPv4 as much as possible.  
> 

Speaking as an end-user who is fortunate enough to have enough address space in both address families, I'd much rather have IPv6 than have to suffer through NAT, let alone the various forms of NAT++ that are coming (IVI, DS-Lite, 6RD, NAT64, NAT444, NAT4444, NAT44444444444..., etc.).

Owen

From owen at delong.com  Tue Aug 30 18:26:21 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 30 Aug 2011 15:26:21 -0700
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <4FA4451CBBCF41DC9D91AB7D5950B158@mike>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>	<20110829230435.00005e6a@unknown>
	<8ED2D34B24014C23AA5F029110C39DD3@mike> <4E5D37DE.70805@Dilkie.com>
	<4FA4451CBBCF41DC9D91AB7D5950B158@mike>
Message-ID: <052E07C4-F1DF-4D50-A7E5-7FDE56B0ED3C@delong.com>


On Aug 30, 2011, at 1:06 PM, Mike Burns wrote:

> Hi Lee,
>  
>  
> Old work and new work on this issue:
>  
> http://www.faqs.org/rfcs/rfc1710.html
> http://tools.ietf.org/html/rfc6346
> https://mice.cs.columbia.edu/getTechreport.php?techreportID=560
>  
> The market, left to its own devices, has selected NAT as the pseudo-protocol of choice to facilitate virtually transparent address sharing.

An excellent argument in support of the idea that markets left to their own devices do not necessarily make good choices.

> I think there is work undone which would extend NAT to allow customers to have control over even multi-layer NAT and would define clear paths for multi-NAT traversal.

There is work undone which could optimize torture techniques to inflict greater amounts of pain while still not causing death, too. I don't support such research. IMHO, there is a direct correlation between these two types of research.

> I believe the IETF and the registries have thwarted development in these areas because they see, correctly, that IPv6 is a superior answer to problems of address shortage.

I do not believe that the IETF or the registries have thwarted development in these areas. I believe that development in these areas has thwarted itself because when presented to the market of ideas and compared to IPv6, that particular market of ideas (the market of ideas instead of the market of $$ and current vested monetary interests) is a market that primarily consists of people who understand the problems in question and rightly chose IPv6 as a better solution. OTOH, those who do not understand the problem chose unperceived and not well understood damage to what they already know over a venture into the unknown. Such is the market of $$ where there is no requirement that the participants understand what they are buying.

>  
> The problem is that IPv6 has no customer demand driving transition, and has thus languished.

That is rapidly changing, actually.

And I believe that deployments of CGN will actually change it even more rapidly.

I think a bigger problem is that some organizations have spent far too much time and money "Promoting IPv6" and not nearly enough time just DEPLOYING IPv6.

Hurricane Electric is late to the party Promoting IPv6 because we spent our initial IPv6 investment on deploying IPv6 first. We focused on promoting after we had already deployed and implemented. Now we have again refocused on not only promoting, but, also helping others deploy.

>  
> I am not saying that I have a replacement successor protocol to deliver to you, but I look hungrily at the 8 bits of port number space in the header and wonder whether it is possible to effectively multiply our current space by 256, which to me would provide ample headroom and still leave 256 potential ports per address.

8 bits is not nearly enough. We're already at nearly that level of compression through existing NAT mechanisms and all you'd really be doing is moving around where the address compression occurs. Arguably you would be moving that address compression to a less functional place as well. You might gain a few efficiencies in the process, but, certainly not 256x.

>  
> And this is in answer to the question posed by Mr. Vixie, which postulated a no-option endpoint at IPv6.
>  
> If I had a magic wand to wave, I would wave it and turn the Internet to IPv6 overnight, I wouldn't wave it to create a half-way protocol extension.
>  
> But we have no magic wands to wave and exhaustion of the lingua franca staring us in the face.

Which is why we need to get over the idea of half solutions, implement the transition mechanisms we have where we must and deploy IPv6 everywhere as quickly as possible so that we can get on with the business of maintaining and improving a scalable end-to-end internet built on a protocol that has a future (IPv6) rather than continuing to try and breathe life into a protocol that, in reality, ran out of steam almost a decade ago.

Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110830/245d7e5a/attachment.htm>

From sethm at rollernet.us  Tue Aug 30 19:06:04 2011
From: sethm at rollernet.us (Seth Mattinen)
Date: Tue, 30 Aug 2011 16:06:04 -0700
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <4FA4451CBBCF41DC9D91AB7D5950B158@mike>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>	<20110829230435.00005e6a@unknown>
	<8ED2D34B24014C23AA5F029110C39DD3@mike> <4E5D37DE.70805@Dilkie.com>
	<4FA4451CBBCF41DC9D91AB7D5950B158@mike>
Message-ID: <4E5D6CDC.70509@rollernet.us>

On 8/30/11 1:06 PM, Mike Burns wrote:
>  
> The problem is that IPv6 has no customer demand driving transition, and
> has thus languished.
>  

Does anyone know what IPv6 demand in the APNIC region has been like
since they are on their last /8?

~Seth


From sethm at rollernet.us  Tue Aug 30 19:07:20 2011
From: sethm at rollernet.us (Seth Mattinen)
Date: Tue, 30 Aug 2011 16:07:20 -0700
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <9D5386A8-0B59-4ECC-9421-E8F848B0E87E@arin.net>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
	<20110829230435.00005e6a@unknown>
	<8ED2D34B24014C23AA5F029110C39DD3@mike>
	<9D5386A8-0B59-4ECC-9421-E8F848B0E87E@arin.net>
Message-ID: <4E5D6D28.7030703@rollernet.us>

On 8/30/11 10:30 AM, John Curran wrote:
> On Aug 30, 2011, at 12:01 PM, Mike Burns wrote:
> 
>> Hi Paul,
> 
> Mike -
> 
> I'll answer these, since the Board is not directly involved 
> in day-to-day operations.
> 
>> I'm an ARIN facilitator.
>> Can I run an auction today on eBay for address space?
> 
> Yes.
> 
> You should put note in the auction noting that bidders be 
> eligible to receive the address space per ARIN policies. 
> (If you do not, then bidders may have differing or uncertain 
> expectations and that does not make for predictable outcomes.)
> 

I.e. winning the auction does not guarantee they will actually qualify
for the space.

~Seth


From paul at redbarn.org  Tue Aug 30 20:48:17 2011
From: paul at redbarn.org (Paul Vixie)
Date: Wed, 31 Aug 2011 00:48:17 +0000
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <4FA4451CBBCF41DC9D91AB7D5950B158@mike>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
	<20110829230435.00005e6a@unknown>
	<8ED2D34B24014C23AA5F029110C39DD3@mike> <4E5D37DE.70805@Dilkie.com>
	<4FA4451CBBCF41DC9D91AB7D5950B158@mike>
Message-ID: <20110831004817.000005b3@unknown>

On Tue, 30 Aug 2011 16:06:11 -0400
"Mike Burns" <mike at nationwideinc.com> wrote:

> ...
> And this is in answer to the question posed by Mr. Vixie, which
> postulated a no-option endpoint at IPv6.

looking at that again:

On Tue, 30 Aug 2011 12:01:14 -0400
"Mike Burns" <mike at nationwideinc.com> wrote:

> ...
> As to your issue about what happens after IPv4 is at its best and
> highest use, I have given this some thought over the years.
> Have you considered that a robust trading market and CGN might buy us
> enough time to come up with some kind of backward compatible
> successor protocol to IPv4?

yes, i considered (and rejected) this approach back in the late 1990's.

> Proposals for these kind of solutions have been made in IETF but are 
> routinely ignored.

there are several reasons why this kind of solution is routinely
ignored when it comes up in the IETF or elsewhere.  first, because the
internet's initial success depended on a stateless core, and most of us
assume that to make traffic capacity scale with transistor density we
will have to continue keeping state out of the core.  the internet
core is packet based even if the web we've built atop the
internet appears to be virtual circuit based (tcp/80).  second, because
the transition from ipv4 to ipv6 is already very difficult and most of
us know that leaving basic design questions open would make the
transition even more difficult.  (we now know better ways to do secure
dns than the current dnssec design; we now know better ways to do
packet switched networking than the current ipv6 design; but we have to
stop designing and stop building at some point, not optimize forever
and get nothing.)

> To my mind there is room in the IPv4 header to expand the effective
> address space.
> GGN does this effectively and largely transparently today using the 
> additional room in the  port number part of the header.
> Every TCP connection uses IP+port, and we have 65,000 ports per IPv4 
> address.

if the internet were not older and larger than the web, then your
web-centric mental image as outlined above might be a realistic way
forward.  notwithstanding the fact that a lot of us build a lot of
services on top of tcp/80 since it's a fairly reliable serial channel
that works even in hotel rooms, the internet also has to support packet
based services that do not map well to virtual circuit style mechanisms
like tcp.

> The dual-stack transition is a failure, it is time to recognize that
> the lack of an economic motive for IPv6 created a situation where
> dual-stack was doomed.

disagreed.

> And we have gotten pretty darn good at traversing NAT already,
> despite the doomsayers.

also disagreed.  what "we've" done is hold back some kinds of
applications altogether because of NAT, and increase both the
development and operating costs of other applications because of NAT.
i am treating NAT as a transitory economy-wide externalized cost, not
as an inevitable part of the future of all IP networking.

> It does not further your position to openly wonder whether those who 
> "complain" are "hoarders and speculators".

noted.  however, the thing you're complaining about here isn't the
position i was describing.  if you only wanted to sell "web access"
rather than "internet access" then you can live with NAT and you'd have
no oar in the water wrt IPv6.
-- 
Paul Vixie


From jcurran at arin.net  Tue Aug 30 20:49:45 2011
From: jcurran at arin.net (John Curran)
Date: Wed, 31 Aug 2011 00:49:45 +0000
Subject: [arin-ppml] IP address auctions and managing uncertainty
In-Reply-To: <4E5D6D28.7030703@rollernet.us>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
	<20110829230435.00005e6a@unknown>
	<8ED2D34B24014C23AA5F029110C39DD3@mike>
	<9D5386A8-0B59-4ECC-9421-E8F848B0E87E@arin.net>
	<4E5D6D28.7030703@rollernet.us>
Message-ID: <AE9EC241-6063-4647-9212-A58792DAF775@arin.net>

On Aug 30, 2011, at 7:07 PM, Seth Mattinen wrote:
> 
> I.e. winning the auction does not guarantee they will actually qualify
> for the space.

For sake of clarity, let's run down the most common permutations
with respect to bidder qualification:

1) A party holding address space in the ARIN region decides to 
   list it on an auction site, and makes plain that the only 
   valid bidders are those _who have qualified_ to receive per 
   the policies in this region.  This would imply that they 
   will confirm bidders against ARIN's Specified Transfer
   Listing Service, and reject any bids from parties not 
   listed there. It's a fairly straight forward process to use 
   the specified transfer listing service for verification, 
   and not really possible to do otherwise (while ARIN has 
   no position, per se, on use of auctions or brokers to find
   address space for transfer, ARIN does need to provide the
   basic capabilities that only it can which enable others to 
   use and offer such services with certainty.)

2) A party holding address space in the ARIN region decides to 
   list it on an auction site, and makes plain that the only 
   valid bidders are those _who will meet the policies_ in the
   region.  This is less certain, since there's an implicit
   assumption that bidders will know that they're qualified
   and therefore that the transfer will complete.  Parties 
   need to prepared for that possibility that the bidder 
   cannot complete the transaction (which is commonly dealt 
   with in the online auction world by invalidating the bidder
   and asking the next bidder if they wish to step in, etc.)

3) A party holding address space in the ARIN region decides to
   list it on an auction site, and does not state anything with
   respect to qualifications of bidders as valid recipients.  
   There is exists a significant chance of expectation mismatch 
   between seller and bidder when it comes to requirements of 
   both parties in closing the transaction. Indeed, the seller 
   is likely to receive a question in the auction from me asking 
   if they could be more explicit in any manner with respect to 
   buyer requirements as well as an open invitation to contact 
   ARIN regarding such transfers. It remains possible that a 
   successful transfer will emerge from such a situation, but 
   I'm not aware of any taking place to date.

I hope that this helps clarify some of the possibilities with 
respect to the auctions and bidder qualifications.

FYI,
/John

John Curran
President and CEO
ARIN



From mysidia at gmail.com  Tue Aug 30 21:29:01 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Tue, 30 Aug 2011 20:29:01 -0500
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <75822E125BCB994F8446858C4B19F0D7175496FFDD@SUEX07-MBX-04.ad.syr.edu>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
	<20110829230435.00005e6a@unknown>
	<75822E125BCB994F8446858C4B19F0D7175496FFDD@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <CAAAwwbUfg5UiPyFtBzzgmD0+wEYf-_bmnMMOAp8dQDp7_DeACg@mail.gmail.com>

On Tue, Aug 30, 2011 at 9:41 AM, Milton L Mueller <mueller at syr.edu> wrote:
> These kinds of comments show a certain lack of sensitivity to the needs of actual network operators. Given the pace of the IPv6 transition,
Reality is even worse than he stated....  because he implied there is
a way to use "IPv4 more efficiently".

I would equate this to using up all the RAM in your computer and
deciding,  your applications  will need to utilize the available
memory more efficiently  (which means swapping pages to disk),
because NAT with IPv4, and dynamic addressing,  is  basically a
similar principal to a computer system using a page file,  so the same
bit of virtually addressed physical memory can be shared between many
processes.

The problem is you don't actually increase the amount of available
resource   -- swapping  seems to work very briefly,  but then your
working set exceeds the available resource    (E.g. the number of
public addressing you need)  exceeds  the available addressing.
And there will be a breaking point beyond which the system implodes.

The IPv4 analogy to system thrashing would be...    address churn,
NAT-related internet experience degradations, and routing table
explosion with increasing numbers of smaller and smaller allocations /
resources freed up to satisfy a _fraction_ of actual requests.

More importantly... this increased "efficiency of addressing"  is
actually an overall decrease of efficiency of the system.



There is mathematically no way to increase the total number of IP
addresses within the addressing of IPV4 protocol.   And the addresses
required for the network only increases.
Either the pace of IPv6 transition will rapidly accelerate,  OR the
pace of    introduction of new IPv4 networks will rapidly tend towards
zero.



--
-JH


From mike at nationwideinc.com  Tue Aug 30 21:31:15 2011
From: mike at nationwideinc.com (Mike Burns)
Date: Tue, 30 Aug 2011 21:31:15 -0400
Subject: [arin-ppml] An article of interest to the community....
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike><20110829230435.00005e6a@unknown><8ED2D34B24014C23AA5F029110C39DD3@mike>
	<4E5D37DE.70805@Dilkie.com><4FA4451CBBCF41DC9D91AB7D5950B158@mike>
	<20110831004817.000005b3@unknown>
Message-ID: <C3A66A6CC66D4911B318652D7152C4D4@video>

Hi Paul,

80 is not the only port.
Remember port 21's problem with port 20?
That screwed up Nat right from the getgo, but how long did it take for 
passive ftp to appear?
I use multi-level Nat every day and I manipulate ports which carry http, 
https, Radius, ftp, voip, vnc, Xbox, MagicJack, Netflix, Skype, etc, etc. 
Tcp and udp. Every day.
.
Rendezous servers allow for Nat traversal while at the same time providing 
access security. Stun and SIP work and UpNP also works.

I don't know how closely bound bandwidth growth is to Moore's Law, but the 
market has decided that including "state" in the form of  Nat is an 
acceptable practice. In fact Nat has been at the edges doing stateful stuff 
for 15 years, and Cisco and Juniper have big iron boxes for CGN.

The documents I posted earlier were written by people whose understanding of 
this issue is not limited to the crippled web-centric mindset you 
erroneously apply to me. Like your speculator commentary, it's an ad hominem 
which does not advance your position.

What applications is Nat holding back?

Regards,

Mike




----- Original Message ----- 
From: "Paul Vixie" <paul at redbarn.org>
To: <arin-ppml at arin.net>
Sent: Tuesday, August 30, 2011 8:48 PM
Subject: Re: [arin-ppml] An article of interest to the community....


> On Tue, 30 Aug 2011 16:06:11 -0400
> "Mike Burns" <mike at nationwideinc.com> wrote:
>
>> ...
>> And this is in answer to the question posed by Mr. Vixie, which
>> postulated a no-option endpoint at IPv6.
>
> looking at that again:
>
> On Tue, 30 Aug 2011 12:01:14 -0400
> "Mike Burns" <mike at nationwideinc.com> wrote:
>
>> ...
>> As to your issue about what happens after IPv4 is at its best and
>> highest use, I have given this some thought over the years.
>> Have you considered that a robust trading market and CGN might buy us
>> enough time to come up with some kind of backward compatible
>> successor protocol to IPv4?
>
> yes, i considered (and rejected) this approach back in the late 1990's.
>
>> Proposals for these kind of solutions have been made in IETF but are
>> routinely ignored.
>
> there are several reasons why this kind of solution is routinely
> ignored when it comes up in the IETF or elsewhere.  first, because the
> internet's initial success depended on a stateless core, and most of us
> assume that to make traffic capacity scale with transistor density we
> will have to continue keeping state out of the core.  the internet
> core is packet based even if the web we've built atop the
> internet appears to be virtual circuit based (tcp/80).  second, because
> the transition from ipv4 to ipv6 is already very difficult and most of
> us know that leaving basic design questions open would make the
> transition even more difficult.  (we now know better ways to do secure
> dns than the current dnssec design; we now know better ways to do
> packet switched networking than the current ipv6 design; but we have to
> stop designing and stop building at some point, not optimize forever
> and get nothing.)
>
>> To my mind there is room in the IPv4 header to expand the effective
>> address space.
>> GGN does this effectively and largely transparently today using the
>> additional room in the  port number part of the header.
>> Every TCP connection uses IP+port, and we have 65,000 ports per IPv4
>> address.
>
> if the internet were not older and larger than the web, then your
> web-centric mental image as outlined above might be a realistic way
> forward.  notwithstanding the fact that a lot of us build a lot of
> services on top of tcp/80 since it's a fairly reliable serial channel
> that works even in hotel rooms, the internet also has to support packet
> based services that do not map well to virtual circuit style mechanisms
> like tcp.
>
>> The dual-stack transition is a failure, it is time to recognize that
>> the lack of an economic motive for IPv6 created a situation where
>> dual-stack was doomed.
>
> disagreed.
>
>> And we have gotten pretty darn good at traversing NAT already,
>> despite the doomsayers.
>
> also disagreed.  what "we've" done is hold back some kinds of
> applications altogether because of NAT, and increase both the
> development and operating costs of other applications because of NAT.
> i am treating NAT as a transitory economy-wide externalized cost, not
> as an inevitable part of the future of all IP networking.
>
>> It does not further your position to openly wonder whether those who
>> "complain" are "hoarders and speculators".
>
> noted.  however, the thing you're complaining about here isn't the
> position i was describing.  if you only wanted to sell "web access"
> rather than "internet access" then you can live with NAT and you'd have
> no oar in the water wrt IPv6.
> -- 
> Paul Vixie
> _______________________________________________
> 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 mysidia at gmail.com  Tue Aug 30 21:41:30 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Tue, 30 Aug 2011 20:41:30 -0500
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <C3A66A6CC66D4911B318652D7152C4D4@video>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
	<20110829230435.00005e6a@unknown>
	<8ED2D34B24014C23AA5F029110C39DD3@mike> <4E5D37DE.70805@Dilkie.com>
	<4FA4451CBBCF41DC9D91AB7D5950B158@mike>
	<20110831004817.000005b3@unknown>
	<C3A66A6CC66D4911B318652D7152C4D4@video>
Message-ID: <CAAAwwbVXRLzs4CO_t5QaxNV_M-k4QP-iTUS+i799ATf9gp+kBw@mail.gmail.com>

On Tue, Aug 30, 2011 at 8:31 PM, Mike Burns <mike at nationwideinc.com> wrote:
> Hi Paul,
> 80 is not the only port.
> Remember port 21's problem with port 20?
> That screwed up Nat right from the getgo, but how long did it take for
> passive ftp to appear?

Bad example.  Years;  nearly 20 years after the introduction of the
FTP protocol,
and packet filters preceded it by years as well,  it  was solving a
problem that had been around
for quite a while.

RFC 1579  "Firewall friendly" passive mode FTP was introduced to cope
with  inbound packet filters.

And...  RFC1918 did not exist in 1994, there was no such thing as a
private IP address.
NAT had nothing to do with this.

http://www.ietf.org/rfc/rfc1579.txt


--
-JH


From Lee at dilkie.com  Tue Aug 30 22:18:36 2011
From: Lee at dilkie.com (Lee Dilkie)
Date: Tue, 30 Aug 2011 22:18:36 -0400
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <C3A66A6CC66D4911B318652D7152C4D4@video>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike><20110829230435.00005e6a@unknown><8ED2D34B24014C23AA5F029110C39DD3@mike>	<4E5D37DE.70805@Dilkie.com><4FA4451CBBCF41DC9D91AB7D5950B158@mike>	<20110831004817.000005b3@unknown>
	<C3A66A6CC66D4911B318652D7152C4D4@video>
Message-ID: <4E5D99FC.7000409@dilkie.com>


On 8/30/2011 9:31 PM, Mike Burns wrote:
> I use multi-level Nat every day and I manipulate ports which carry 
> http, https, Radius, ftp, voip, vnc, Xbox, MagicJack, Netflix, Skype, 
> etc, etc. Tcp and udp. Every day.

As do I. I develop SBC-type solutions to those problems. But I often 
think that it would be more fun and productive to work on something new 
that the world needs rather than spend my effort fixing protocols that 
were broken by NAT.

NAT has huge costs.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110830/792418f2/attachment.htm>

From paul at redbarn.org  Tue Aug 30 22:32:06 2011
From: paul at redbarn.org (Paul Vixie)
Date: Wed, 31 Aug 2011 02:32:06 +0000
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <C3A66A6CC66D4911B318652D7152C4D4@video>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
	<20110829230435.00005e6a@unknown>
	<8ED2D34B24014C23AA5F029110C39DD3@mike> <4E5D37DE.70805@Dilkie.com>
	<4FA4451CBBCF41DC9D91AB7D5950B158@mike>
	<20110831004817.000005b3@unknown>
	<C3A66A6CC66D4911B318652D7152C4D4@video>
Message-ID: <20110831023206.0000759e@unknown>

On Tue, 30 Aug 2011 21:31:15 -0400
"Mike Burns" <mike at nationwideinc.com> wrote:

> What applications is Nat holding back?

nat makes everything just a little bit harder.  we have some cisco voip
phones that can traverse nat and others that can't and we have to use
the right one in the right place.  that's a capital cost if we run out
of the kind we need, and an operational cost of keeping track of which
kind we actually need in which location, and how they have to be
configured.

the invisible hand of the market just isn't helping us in this case, so
we directly bear our share of the economy-wide externalized cost of NAT.
that does not appear to be a case where "the market has decided in
favour of NAT", it feels more like "the market has adopted NAT as a
barely functional band-aid."  and while one could argue that we're
holding back the growth of the internet by trying to use
non-NAT-compatible devices, the counter-argument is that various folk
are holding back the growth of the internet by using non-dual-stack
devices.  so what we have here is a divergence in the vision itself.

note that the ARIN community could make policies that favour the "IPv4
for a long time to come, let's use CGN and NAT to make it last until
something better than IPv6 comes along" model that you've described
here, in which case ARIN (both the organization and its board) would
follow those policies.  if this vision of the future appeals to you then
i encourage you to pursue it by following the Policy Development
Process.
-- 
Paul Vixie


From mueller at syr.edu  Tue Aug 30 23:11:37 2011
From: mueller at syr.edu (Milton L Mueller)
Date: Tue, 30 Aug 2011 23:11:37 -0400
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <20110831023206.0000759e@unknown>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
	<20110829230435.00005e6a@unknown>	<8ED2D34B24014C23AA5F029110C39DD3@mike>
	<4E5D37DE.70805@Dilkie.com>	<4FA4451CBBCF41DC9D91AB7D5950B158@mike>
	<20110831004817.000005b3@unknown>	<C3A66A6CC66D4911B318652D7152C4D4@video>
	<20110831023206.0000759e@unknown>
Message-ID: <75822E125BCB994F8446858C4B19F0D71754937061@SUEX07-MBX-04.ad.syr.edu>


> -----Original Message-----
> barely functional band-aid."  and while one could argue that we're
> holding back the growth of the internet by trying to use non-NAT-
> compatible devices, the counter-argument is that various folk are
> holding back the growth of the internet by using non-dual-stack devices.
> so what we have here is a divergence in the vision itself.

[Milton L Mueller] 
Once again I am forced to remind you that even those who use dual stack devices need IPv4 addresses. 
To get more of them, they can either trade for them or NAT or both. But invoking dual stack in no way obviates the need for additional IPv4 addresses for growing networks in the near term. Is there some reason why people persistently refuse to face this?

> note that the ARIN community could make policies that favour the "IPv4
> for a long time to come, let's use CGN and NAT to make it last until
> something better than IPv6 comes along" model that you've described

[Milton L Mueller] 
That may be a major source of the disagreement here. In my view "IPv4 for a long time to come" is not a "policy" that someone adopted or should adopt, it is simply a fact, a recognition of the way things are actually playing out. ARIN has correctly adopted a policy to permit v4 transfers because it has recognized that fact. The only issue is whether those policies are liberal enough. 

> here, in which case ARIN (both the organization and its board) would
> follow those policies.  if this vision of the future appeals to you then
> i encourage you to pursue it by following the Policy Development
> Process.

[Milton L Mueller] 
Network operators who are already delaying or avoiding IPv6 because of the extra time and costs associated with it are supposed to invest time in an ARIN PDP in order to validate a choice they can already make on their own? You _do_ need to get out more.






From owen at delong.com  Tue Aug 30 23:17:15 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 30 Aug 2011 20:17:15 -0700
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <C3A66A6CC66D4911B318652D7152C4D4@video>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike><20110829230435.00005e6a@unknown><8ED2D34B24014C23AA5F029110C39DD3@mike>
	<4E5D37DE.70805@Dilkie.com><4FA4451CBBCF41DC9D91AB7D5950B158@mike>
	<20110831004817.000005b3@unknown>
	<C3A66A6CC66D4911B318652D7152C4D4@video>
Message-ID: <A2749D34-F959-4154-AB90-55E2DF16BA1B@delong.com>


On Aug 30, 2011, at 6:31 PM, Mike Burns wrote:

> Hi Paul,
> 
> 80 is not the only port.
> Remember port 21's problem with port 20?
> That screwed up Nat right from the getgo, but how long did it take for passive ftp to appear?
> I use multi-level Nat every day and I manipulate ports which carry http, https, Radius, ftp, voip, vnc, Xbox, MagicJack, Netflix, Skype, etc, etc. Tcp and udp. Every day.
> .
> Rendezous servers allow for Nat traversal while at the same time providing access security. Stun and SIP work and UpNP also works.
> 

All of these things are true for a single layer of NAT to a limited extent.

Oh, and your claim that STUN works -- Uh, Geoff Huston yesterday presented statistics showing that it has roughly a 45% failure rate.

This all gets much much worse when you introduce any (let alone all) of the following:
	+	Multiple layers of NAT
	+	Carrier Operated NAT
	+	NAT on the server side of the connection (yes, this has been proposed)
	+	Overlapping addresses in different regions of the NAT process
	+	NATs which do not support uPNP or NAT-PMP

It may work in your particular limited circumstance for some subset of users and some subset of applications, but, that is not the whole internet and it isn't even a particularly good microcosm of the variety of applications (both existing and being prevented) that exist on the internet. NAT hampers many applications, increases the cost and code base of others and flat out prevents some from coming to realization.

> I don't know how closely bound bandwidth growth is to Moore's Law, but the market has decided that including "state" in the form of  Nat is an acceptable practice. In fact Nat has been at the edges doing stateful stuff for 15 years, and Cisco and Juniper have big iron boxes for CGN.
> 

State at the edge is very different from state in the core. The market lacks proper technical understanding of these concepts and also tends to lack foresight into the natural long-term results of it's short-term decisions. The market is fickle and short-sighted by definition. The market means that Cisco and Juniper will build whatever technology they believe they can sell. Many cable MSOs are implementing CGN, for example, not because they are trying to prolong the life of IPv4 or delay their IPv6 rollout, but, because they have a need to continue to support certain limited IPv4 functionality during the transition.

> The documents I posted earlier were written by people whose understanding of this issue is not limited to the crippled web-centric mindset you erroneously apply to me. Like your speculator commentary, it's an ad hominem which does not advance your position.
> 
> What applications is Nat holding back?
> 

Frankly, since they don't see the light of day due to the engineering constraints of NAT preventing their development, it is hard to speculate as to what they are. I know that development of new multiplayer games has been hampered and that NAT is oft lamented at GDCs. NAT also prevents innovation in the areas of subscriber self-publication of content, end-user run services, etc.

Further, while this isn't an example of an application being held back, GoToMyXX (GoToMyPC, BackToMyMac, GoToMeeting, etc.) are examples of applications that are basically unnecessary outside of NAT where simple end-to-end connectivity would obviate the need for these rendezvous services. While you and/or the market may consider these parasite applications to be a good thing that increases revenue for some group, as an end-user, I regard them as parasites sucking money out of what should simply be a basic part of network access simply due to artificial limitations imposed on that network by NAT.

Owen



From paul at redbarn.org  Tue Aug 30 23:27:45 2011
From: paul at redbarn.org (Paul Vixie)
Date: Wed, 31 Aug 2011 03:27:45 +0000
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <75822E125BCB994F8446858C4B19F0D71754937061@SUEX07-MBX-04.ad.syr.edu>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
	<20110829230435.00005e6a@unknown>
	<8ED2D34B24014C23AA5F029110C39DD3@mike> <4E5D37DE.70805@Dilkie.com>
	<4FA4451CBBCF41DC9D91AB7D5950B158@mike>
	<20110831004817.000005b3@unknown>
	<C3A66A6CC66D4911B318652D7152C4D4@video>
	<20110831023206.0000759e@unknown>
	<75822E125BCB994F8446858C4B19F0D71754937061@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <20110831032745.000030cd@unknown>

On Tue, 30 Aug 2011 23:11:37 -0400
Milton L Mueller <mueller at syr.edu> wrote:

> Once again I am forced to remind you that even those who use dual
> stack devices need IPv4 addresses. To get more of them, they can
> either trade for them or NAT or both. But invoking dual stack in no
> way obviates the need for additional IPv4 addresses for growing
> networks in the near term. Is there some reason why people
> persistently refuse to face this?

i didn't realize i was refusing to face that.  upon review i still
don't think i am refusing to face that.  ipv4 that's needed for dual
stack is still ipv4 that's needed (as opposed to ipv4 that's merely
wanted for some non-needs-based purpose which could include hoarding or
speculation).  i'm in favour of people who need ipv4 having access to
it and i consider the current ARIN transfer policy adequate to that.

however, the issue at hand here is subtly different.  ipv4 that's needed
for dual stack would be a transition tool which presumes native ipv6 as
an end state for some large part of (perhaps all of) the internet.
ipv4 that's needed in the "ipv4 only, for a long time, let's avoid
ipv6 and hope that something better comes along before we really can't
squeeze out any more ipv4 space" vision (to which i do not subscribe.)

> > note that the ARIN community could make policies that favour the
> > "IPv4 for a long time to come, let's use CGN and NAT to make it
> > last until something better than IPv6 comes along" model that
> > you've described
> 
> That may be a major source of the disagreement here. In my view "IPv4
> for a long time to come" is not a "policy" that someone adopted or
> should adopt, it is simply a fact, a recognition of the way things
> are actually playing out. ARIN has correctly adopted a policy to
> permit v4 transfers because it has recognized that fact. The only
> issue is whether those policies are liberal enough. 

i don't understand your disagreement since i'd said "policies that
favour the [ipv4 for a long time to come] model" and since the ARIN
community could drive toward liberalization of the transfer policy to
include non-needs-based recipients if that was the community's
consensus.

> > here, in which case ARIN (both the organization and its board) would
> > follow those policies.  if this vision of the future appeals to you
> > then i encourage you to pursue it by following the Policy
> > Development Process.
> 
> Network operators who are already delaying or avoiding IPv6 because
> of the extra time and costs associated with it are supposed to invest
> time in an ARIN PDP in order to validate a choice they can already
> make on their own? You _do_ need to get out more.

milton, this final paragraph of your message is quite edgy and almost
caused me to just hit delete rather than answering you.  a word to the
wise: please remain civil if you want dialogue rather than monologue.
-- 
Paul Vixie


From owen at delong.com  Tue Aug 30 23:27:51 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 30 Aug 2011 20:27:51 -0700
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <75822E125BCB994F8446858C4B19F0D71754937061@SUEX07-MBX-04.ad.syr.edu>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
	<20110829230435.00005e6a@unknown>	<8ED2D34B24014C23AA5F029110C39DD3@mike>
	<4E5D37DE.70805@Dilkie.com>	<4FA4451CBBCF41DC9D91AB7D5950B158@mike>
	<20110831004817.000005b3@unknown>	<C3A66A6CC66D4911B318652D7152C4D4@video>
	<20110831023206.0000759e@unknown>
	<75822E125BCB994F8446858C4B19F0D71754937061@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <C91E7A10-FAF4-4CFF-914F-BCDFD5787E40@delong.com>


On Aug 30, 2011, at 8:11 PM, Milton L Mueller wrote:

> 
>> -----Original Message-----
>> barely functional band-aid."  and while one could argue that we're
>> holding back the growth of the internet by trying to use non-NAT-
>> compatible devices, the counter-argument is that various folk are
>> holding back the growth of the internet by using non-dual-stack devices.
>> so what we have here is a divergence in the vision itself.
> 
> [Milton L Mueller] 
> Once again I am forced to remind you that even those who use dual stack devices need IPv4 addresses. 
> To get more of them, they can either trade for them or NAT or both. But invoking dual stack in no way obviates the need for additional IPv4 addresses for growing networks in the near term. Is there some reason why people persistently refuse to face this?
> 

You only need dual stack if you need IPv4. If everything currently IPv4 was
dual stacked, then, everything additional would only need IPv6. The
need for IPv4 for dual-stack is limited to those things that have IPv4 and
those things that need to reach IPv4 hosts that are not yet dual-stack.

In an ideal world, IPv4 hosts would have gone to dual stack before
we had an issue with no IPv4 addresses for new hosts joining the
network. Unfortunately because markets tend to be dysfunctional
in this regard and do not yield the best outcome in such cases, we
have arrived at an outcome where we will now be forced to deal with
kludges and workarounds until we arrive at a point where IPv6 is
the dominant and viable protocol.

>> note that the ARIN community could make policies that favour the "IPv4
>> for a long time to come, let's use CGN and NAT to make it last until
>> something better than IPv6 comes along" model that you've described
> 
> [Milton L Mueller] 
> That may be a major source of the disagreement here. In my view "IPv4 for a long time to come" is not a "policy" that someone adopted or should adopt, it is simply a fact, a recognition of the way things are actually playing out. ARIN has correctly adopted a policy to permit v4 transfers because it has recognized that fact. The only issue is whether those policies are liberal enough. 
> 

I am not convinced that things will play out that way at all. I think, instead,
that the immediate situation is not what things will look like in a year and
that as we begin to gain more experience with actual IPv4 runout and
actual deployment of CGN and other kludges, we will see increasing
pain in and cost of IPv4 as a bigger and bigger motivator to accelerate IPv6 
deployment. In other words, I believe the market will shift, but, that it will
shift late and that we aren't at that late point yet. There are those of us
trying to save the market from itself by encouraging earlier adoption
of IPv6.

>> here, in which case ARIN (both the organization and its board) would
>> follow those policies.  if this vision of the future appeals to you then
>> i encourage you to pursue it by following the Policy Development
>> Process.
> 
> [Milton L Mueller] 
> Network operators who are already delaying or avoiding IPv6 because of the extra time and costs associated with it are supposed to invest time in an ARIN PDP in order to validate a choice they can already make on their own? You _do_ need to get out more.
> 

They are welcome to continue their impersonation of ostriches if they
feel that is in their best interest. I don't think it is Paul who needs to get
out more.

Owen



From matthew at matthew.at  Tue Aug 30 23:53:14 2011
From: matthew at matthew.at (Matthew Kaufman)
Date: Wed, 31 Aug 2011 04:53:14 +0100
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <8ED2D34B24014C23AA5F029110C39DD3@mike>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
	<20110829230435.00005e6a@unknown>
	<8ED2D34B24014C23AA5F029110C39DD3@mike>
Message-ID: <B39F2B0D-A4B1-4CD1-B432-D3156C90D0AE@matthew.at>



On Aug 30, 2011, at 5:01 PM, "Mike Burns" <mike at nationwideinc.com> wrote:

> Hi Paul,
> 
> I'm an ARIN facilitator.
> Can I run an auction today on eBay for address space?

Sure you can. Of course the moment you do, that space is immediately suspected of being under-utilized and one would expect a Section 12 resource review to be in progress before the auction even closed. Particularly inconvenient if nobody meets your reserve.

I do wonder how much space we could free up in the region today if people could advertise it's availability without this threat, and yet I believe the odds of removing all resource review and reclamation via the PDP is pretty much a non-starter, so I'm not going to waste my time with a policy proposal.

Matthew Kaufman

Sent from my iPad

From matthew at matthew.at  Tue Aug 30 23:44:57 2011
From: matthew at matthew.at (Matthew Kaufman)
Date: Wed, 31 Aug 2011 04:44:57 +0100
Subject: [arin-ppml] IP address auctions and managing uncertainty
In-Reply-To: <AE9EC241-6063-4647-9212-A58792DAF775@arin.net>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
	<20110829230435.00005e6a@unknown>
	<8ED2D34B24014C23AA5F029110C39DD3@mike>
	<9D5386A8-0B59-4ECC-9421-E8F848B0E87E@arin.net>
	<4E5D6D28.7030703@rollernet.us>
	<AE9EC241-6063-4647-9212-A58792DAF775@arin.net>
Message-ID: <93F9E0F7-1F49-437A-87CD-E9EB33CB863B@matthew.at>



On Aug 31, 2011, at 1:49 AM, John Curran <jcurran at arin.net> wrote:

>  Indeed, the seller 
>   is likely to receive a question in the auction from me asking 
>   if they could be more explicit in any manner with respect to 
>   buyer requirements as well as an open invitation to contact 
>   ARIN regarding such transfers. 

When ARIN runs out of IPv4 and the transfer auctions really take off, I don't think this particular approach is going to scale very well.

Matthew Kaufman

Sent from my iPad

From matthew at matthew.at  Tue Aug 30 23:40:13 2011
From: matthew at matthew.at (Matthew Kaufman)
Date: Wed, 31 Aug 2011 04:40:13 +0100
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <A2749D34-F959-4154-AB90-55E2DF16BA1B@delong.com>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
	<20110829230435.00005e6a@unknown>
	<8ED2D34B24014C23AA5F029110C39DD3@mike> <4E5D37DE.70805@Dilkie.com>
	<4FA4451CBBCF41DC9D91AB7D5950B158@mike>
	<20110831004817.000005b3@unknown>
	<C3A66A6CC66D4911B318652D7152C4D4@video>
	<A2749D34-F959-4154-AB90-55E2DF16BA1B@delong.com>
Message-ID: <6D319CA6-4ADC-4D40-AB9D-C43092B79B24@matthew.at>

On Aug 31, 2011, at 4:17 AM, Owen DeLong <owen at delong.com> wrote:

> 
> 
>    +    NAT on the server side of the connection (yes, this has been proposed)
>   

You say this like it is some crazy idea, but of course nearly all large server farms with load balancers or even just stateful IPv4 firewalls work exactly this way and have for years.


Matthew Kaufman

Sent from my iPad



From jcurran at arin.net  Wed Aug 31 00:14:28 2011
From: jcurran at arin.net (John Curran)
Date: Wed, 31 Aug 2011 04:14:28 +0000
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <B39F2B0D-A4B1-4CD1-B432-D3156C90D0AE@matthew.at>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
	<20110829230435.00005e6a@unknown>
	<8ED2D34B24014C23AA5F029110C39DD3@mike>
	<B39F2B0D-A4B1-4CD1-B432-D3156C90D0AE@matthew.at>
Message-ID: <840D4C7B-87E0-4C8E-8AEE-211D0777A921@arin.net>

On Aug 30, 2011, at 11:53 PM, Matthew Kaufman wrote:

> On Aug 30, 2011, at 5:01 PM, "Mike Burns" <mike at nationwideinc.com> wrote:
> 
>> Hi Paul,
>> 
>> I'm an ARIN facilitator.
>> Can I run an auction today on eBay for address space?
> 
> Sure you can. Of course the moment you do, that space is immediately suspected of being under-utilized and one would expect a Section 12 resource review to be in progress before the auction even closed. Particularly inconvenient if nobody meets your reserve.

Matthew - 
 
   ARIN recognizes that the transfer policy is an approved
   method to bring resources back into community use; we do
   not initiate reclamation for lack of use against resources
   listed on incoming transfer requests, as this would run 
   contrary to the intent of the policy.
   
> I do wonder how much space we could free up in the region today if people could advertise it's availability without this threat, and yet I believe the odds of removing all resource review and reclamation via the PDP is pretty much a non-starter, so I'm not going to waste my time with a policy proposal.

   I'll also note that LRSA also includes specific language 
   which precludes reclamation for lack of use.  We also do
   not initiate reclamation for lack of use against parties
   when they begin the LRSA agreement process for similar
   reason.

   We do reclaim resources that are grossly underutilized 
   (often completely unused) if such cases are brought to 
   our attention and it does not appear that the address 
   space is going to be put to use by the resource holder 
   at all, e.g. address blocks which appear unused by all 
   signs and with completely unresponsive contacts.

FYI,
/John

John Curran
President and CEO
ARIN

   
 

From jcurran at arin.net  Wed Aug 31 00:19:33 2011
From: jcurran at arin.net (John Curran)
Date: Wed, 31 Aug 2011 04:19:33 +0000
Subject: [arin-ppml] IP address auctions and managing uncertainty
In-Reply-To: <93F9E0F7-1F49-437A-87CD-E9EB33CB863B@matthew.at>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
	<20110829230435.00005e6a@unknown>
	<8ED2D34B24014C23AA5F029110C39DD3@mike>
	<9D5386A8-0B59-4ECC-9421-E8F848B0E87E@arin.net>
	<4E5D6D28.7030703@rollernet.us>
	<AE9EC241-6063-4647-9212-A58792DAF775@arin.net>
	<93F9E0F7-1F49-437A-87CD-E9EB33CB863B@matthew.at>
Message-ID: <849BBABA-4621-417B-B87B-C3E234557E54@arin.net>

On Aug 30, 2011, at 11:44 PM, Matthew Kaufman wrote:

> On Aug 31, 2011, at 1:49 AM, John Curran <jcurran at arin.net> wrote:
> 
>> Indeed, the seller 
>>  is likely to receive a question in the auction from me asking 
>>  if they could be more explicit in any manner with respect to 
>>  buyer requirements as well as an open invitation to contact 
>>  ARIN regarding such transfers. 
> 
> When ARIN runs out of IPv4 and the transfer auctions really take off, I don't think this particular approach is going to scale very well.

Actually, most of the online auction sites are very good about handling 
various aspects of sales of restricted items and have well oiled processes 
for such which scale remarkably well, i.e. it does not appear that it will
be a problem at all.

FYI,
/John

John Curran
President and CEO
ARIN




From matthew at matthew.at  Wed Aug 31 00:33:05 2011
From: matthew at matthew.at (Matthew Kaufman)
Date: Wed, 31 Aug 2011 05:33:05 +0100
Subject: [arin-ppml] IP address auctions and managing uncertainty
In-Reply-To: <849BBABA-4621-417B-B87B-C3E234557E54@arin.net>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
	<20110829230435.00005e6a@unknown>
	<8ED2D34B24014C23AA5F029110C39DD3@mike>
	<9D5386A8-0B59-4ECC-9421-E8F848B0E87E@arin.net>
	<4E5D6D28.7030703@rollernet.us>
	<AE9EC241-6063-4647-9212-A58792DAF775@arin.net>
	<93F9E0F7-1F49-437A-87CD-E9EB33CB863B@matthew.at>
	<849BBABA-4621-417B-B87B-C3E234557E54@arin.net>
Message-ID: <BA9F4AE9-8329-44BC-970D-4ADB1763E3C0@matthew.at>



On Aug 31, 2011, at 5:19 AM, John Curran <jcurran at arin.net> wrote:

> On Aug 30, 2011, at 11:44 PM, Matthew Kaufman wrote:
> 
>> On Aug 31, 2011, at 1:49 AM, John Curran <jcurran at arin.net> wrote:
>> 
>>> Indeed, the seller 
>>> is likely to receive a question in the auction from me asking 
>>> if they could be more explicit in any manner with respect to 
>>> buyer requirements as well as an open invitation to contact 
>>> ARIN regarding such transfers. 
>> 
>> When ARIN runs out of IPv4 and the transfer auctions really take off, I don't think this particular approach is going to scale very well.
> 
> Actually, most of the online auction sites are very good about handling 
> various aspects of sales of restricted items and have well oiled processes 
> for such which scale remarkably well, i.e. it does not appear that it will
> be a problem at all.

Yes, the major auction sites can probably help with this, and of course if specialized address auction sites win out (which I personally doubt) then that's even easier. I'm just thinking that personal notes from you might take more hours than you have in a day :)



Matthew Kaufman

Sent from my iPad


> 
> FYI,
> /John
> 
> John Curran
> President and CEO
> ARIN
> 
> 


From matthew at matthew.at  Wed Aug 31 00:40:31 2011
From: matthew at matthew.at (Matthew Kaufman)
Date: Wed, 31 Aug 2011 05:40:31 +0100
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <840D4C7B-87E0-4C8E-8AEE-211D0777A921@arin.net>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
	<20110829230435.00005e6a@unknown>
	<8ED2D34B24014C23AA5F029110C39DD3@mike>
	<B39F2B0D-A4B1-4CD1-B432-D3156C90D0AE@matthew.at>
	<840D4C7B-87E0-4C8E-8AEE-211D0777A921@arin.net>
Message-ID: <C392E771-14E0-4FCC-A24B-153879FF4321@matthew.at>




On Aug 31, 2011, at 5:14 AM, John Curran <jcurran at arin.net> wrote:

> On Aug 30, 2011, at 11:53 PM, Matthew Kaufman wrote:
> 
>> On Aug 30, 2011, at 5:01 PM, "Mike Burns" <mike at nationwideinc.com> wrote:
>> 
>>> Hi Paul,
>>> 
>>> I'm an ARIN facilitator.
>>> Can I run an auction today on eBay for address space?
>> 
>> Sure you can. Of course the moment you do, that space is immediately suspected of being under-utilized and one would expect a Section 12 resource review to be in progress before the auction even closed. Particularly inconvenient if nobody meets your reserve.
> 
> Matthew - 
> 
>   ARIN recognizes that the transfer policy is an approved
>   method to bring resources back into community use; we do
>   not initiate reclamation for lack of use against resources
>   listed on incoming transfer requests, as this would run 
>   contrary to the intent of the policy.
> 

I'm aware that incoming transfer requests are exempt from the scrutiny, but there has certainly been discussion here (and elsewhere) in the past to the effect of "I saw someone trying to sell address block <X> and so clearly they're not using it and so I've reported this as an underutilized block."

Whether or not that has or would cause ARIN to act on such a report, I can't know (except for your statement below)

One could imagine that if a block is listed for sale today and stays listed for many months, it probably isn't being utilized that well, absent a good story about how when the sale goes through they'll use the funds to actually renumber out of it.

>> I do wonder how much space we could free up in the region today if people could advertise it's availability without this threat, and yet I believe the odds of removing all resource review and reclamation via the PDP is pretty much a non-starter, so I'm not going to waste my time with a policy proposal.
> 
>   I'll also note that LRSA also includes specific language 
>   which precludes reclamation for lack of use.  We also do
>   not initiate reclamation for lack of use against parties
>   when they begin the LRSA agreement process for similar
>   reason.

Indeed. One additional point for the LRSA.

> 
>   We do reclaim resources that are grossly underutilized 
>   (often completely unused) if such cases are brought to 
>   our attention and it does not appear that the address 
>   space is going to be put to use by the resource holder 
>   at all, e.g. address blocks which appear unused by all 
>   signs and with completely unresponsive contacts.

So it sounds from this like right now, a report like I mentioned above would not result in reclamation, as presumably the contacts would be reachable at the very least (hard to sell something if nobody can contact the seller)

But will the definition of underutilized change as ARIN's free pool dries up? Some in the community have certainly called for that.


Matthew Kaufman

Sent from my iPad
> 


From jcurran at arin.net  Wed Aug 31 00:57:01 2011
From: jcurran at arin.net (John Curran)
Date: Wed, 31 Aug 2011 04:57:01 +0000
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <C392E771-14E0-4FCC-A24B-153879FF4321@matthew.at>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
	<20110829230435.00005e6a@unknown>
	<8ED2D34B24014C23AA5F029110C39DD3@mike>
	<B39F2B0D-A4B1-4CD1-B432-D3156C90D0AE@matthew.at>
	<840D4C7B-87E0-4C8E-8AEE-211D0777A921@arin.net>
	<C392E771-14E0-4FCC-A24B-153879FF4321@matthew.at>
Message-ID: <76F80A9C-3B5A-478D-BA4F-FD92ABC793E0@arin.net>

On Aug 31, 2011, at 12:40 AM, Matthew Kaufman wrote:

> I'm aware that incoming transfer requests are exempt from the scrutiny, but there has certainly been discussion here (and elsewhere) in the past to the effect of "I saw someone trying to sell address block <X> and so clearly they're not using it and so I've reported this as an underutilized block."
> 
> Whether or not that has or would cause ARIN to act on such a report, I can't know (except for your statement below)

If the resources under an LRSA, then it's a non-issue.

> One could imagine that if a block is listed for sale today and stays listed for many months, it probably isn't being utilized that well, absent a good story about how when the sale goes through they'll use the funds to actually renumber out of it.

Alas, we're likely unable to do anything about that, as the
LRSA provides protection against reclamation for lack of use.
In theory, if it was resources under RSA then it would be 
possible (but one would want to avoid that at all costs as 
long as there is a valid contact and good faith efforts)  
That does raise the question of why (and to what end) we are
more flexible with LRSA holders than RSA holders, but I'll 
defer that discussion to the ARIN Philly meeting...

> So it sounds from this like right now, a report like I mentioned above would not result in reclamation, as presumably the contacts would be reachable at the very least (hard to sell something if nobody can contact the seller)
> 
> But will the definition of underutilized change as ARIN's free pool dries up? Some in the community have certainly called for that.

I believe that the community needs to consider carefully the
merits of reclamation of underutilized resources from otherwise
valid address holders, particularly given the tangible value 
that such resources have in the presence of a transfer market.

I expect there will be an opportunity to discuss these matters
in the upcoming ARIN meeting.

FYI,
/John

John Curran
President and CEO
ARIN



From owen at delong.com  Wed Aug 31 01:15:03 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 30 Aug 2011 22:15:03 -0700
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <6D319CA6-4ADC-4D40-AB9D-C43092B79B24@matthew.at>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
	<20110829230435.00005e6a@unknown>
	<8ED2D34B24014C23AA5F029110C39DD3@mike> <4E5D37DE.70805@Dilkie.com>
	<4FA4451CBBCF41DC9D91AB7D5950B158@mike>
	<20110831004817.000005b3@unknown>
	<C3A66A6CC66D4911B318652D7152C4D4@video>
	<A2749D34-F959-4154-AB90-55E2DF16BA1B@delong.com>
	<6D319CA6-4ADC-4D40-AB9D-C43092B79B24@matthew.at>
Message-ID: <B65E920F-6406-4F49-B947-E42CA46C3255@delong.com>


On Aug 30, 2011, at 8:40 PM, Matthew Kaufman wrote:

> On Aug 31, 2011, at 4:17 AM, Owen DeLong <owen at delong.com> wrote:
> 
>> 
>> 
>>   +    NAT on the server side of the connection (yes, this has been proposed)
>> 
> 
> You say this like it is some crazy idea, but of course nearly all large server farms with load balancers or even just stateful IPv4 firewalls work exactly this way and have for years.
> 

I'm talking about different sites being reached depending on:

	http://192.159.10.7:80
	http://192.159.10.7:81
	http://192.159.10.7:82
	...

It's that kind of NAT on the server side that does not appeal to me (DNS support
would require some effort, for example) and would be novel. That particular
mechanism has been proposed.

NAT for load balancing is an entirely different issue and actually the more
efficient load balancers actually use something that looks more like anycast
than like NAT.

No, stateful IPv4 firewalls do NOT necessarily change the address between
the front and the back or overload the port numbers for traffic destined for
servers behind them.

Owen



From owen at delong.com  Wed Aug 31 01:16:49 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 30 Aug 2011 22:16:49 -0700
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <B39F2B0D-A4B1-4CD1-B432-D3156C90D0AE@matthew.at>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
	<20110829230435.00005e6a@unknown>
	<8ED2D34B24014C23AA5F029110C39DD3@mike>
	<B39F2B0D-A4B1-4CD1-B432-D3156C90D0AE@matthew.at>
Message-ID: <4163ACB2-5247-4629-A5AC-DAC47A6F2852@delong.com>


On Aug 30, 2011, at 8:53 PM, Matthew Kaufman wrote:

> 
> 
> On Aug 30, 2011, at 5:01 PM, "Mike Burns" <mike at nationwideinc.com> wrote:
> 
>> Hi Paul,
>> 
>> I'm an ARIN facilitator.
>> Can I run an auction today on eBay for address space?
> 
> Sure you can. Of course the moment you do, that space is immediately suspected of being under-utilized and one would expect a Section 12 resource review to be in progress before the auction even closed. Particularly inconvenient if nobody meets your reserve.
> 

While auctioning your space is not an automatic free pass on section 12, I know that ARIN is
being extremely careful not to conduct arbitrary section 12 audits against people who merely
seek to auction their space.

> I do wonder how much space we could free up in the region today if people could advertise it's availability without this threat, and yet I believe the odds of removing all resource review and reclamation via the PDP is pretty much a non-starter, so I'm not going to waste my time with a policy proposal.
> 

You can advertise the space availability without that threat. Your post is a red herring.

Owen



From mike at nationwideinc.com  Wed Aug 31 12:00:12 2011
From: mike at nationwideinc.com (Mike Burns)
Date: Wed, 31 Aug 2011 12:00:12 -0400
Subject: [arin-ppml] An article of interest to the community....
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
	<20110829230435.00005e6a@unknown>
	<8ED2D34B24014C23AA5F029110C39DD3@mike>
	<B39F2B0D-A4B1-4CD1-B432-D3156C90D0AE@matthew.at>
	<840D4C7B-87E0-4C8E-8AEE-211D0777A921@arin.net>
	<C392E771-14E0-4FCC-A24B-153879FF4321@matthew.at>
Message-ID: <9D206214F8254469BEDB7FD85BF74F8C@mike>

>> I do wonder how much space we could free up in the region today if people 
>> could advertise it's availability without this threat, and yet I believe 
>> the odds of removing all resource review and reclamation via the PDP is 
>> pretty much a non-starter, so I'm not going to waste my time with a 
>> policy proposal.
>
>   I'll also note that LRSA also includes specific language
>   which precludes reclamation for lack of use.  We also do
>   not initiate reclamation for lack of use against parties
>   when they begin the LRSA agreement process for similar
>   reason.

>Indeed. One additional point for the LRSA.

>But will the definition of underutilized change as ARIN's free pool dries 
>up? Some in the community have certainly called for that.


>That does raise the question of why (and to what end) we are
>more flexible with LRSA holders than RSA holders, but I'll
>defer that discussion to the ARIN Philly meeting...


I would like to point out that Prop-151 addresses all of these issues, the 
imbalance between legacy and non-legacy, the danger of section 12 threats to 
trading, and the removal of resource review and reclamation from all address 
holders who have had their addresses for more than one year. Plus the issues 
of public auctions of space are more simple to navigate when ARIN restricts 
itself to booking legal transfers.

C'mon Matthew! All we need is some more visible support on this list for 
prop-151 and it will move from non-starter to starter!

Regards,

Mike







From owen at delong.com  Wed Aug 31 12:25:13 2011
From: owen at delong.com (Owen DeLong)
Date: Wed, 31 Aug 2011 09:25:13 -0700
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <9D206214F8254469BEDB7FD85BF74F8C@mike>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
	<20110829230435.00005e6a@unknown>
	<8ED2D34B24014C23AA5F029110C39DD3@mike>
	<B39F2B0D-A4B1-4CD1-B432-D3156C90D0AE@matthew.at>
	<840D4C7B-87E0-4C8E-8AEE-211D0777A921@arin.net>
	<C392E771-14E0-4FCC-A24B-153879FF4321@matthew.at>
	<9D206214F8254469BEDB7FD85BF74F8C@mike>
Message-ID: <C7DBD622-3B1E-44E9-A91E-19AA1D307A4F@delong.com>


On Aug 31, 2011, at 9:00 AM, Mike Burns wrote:

>>> I do wonder how much space we could free up in the region today if people could advertise it's availability without this threat, and yet I believe the odds of removing all resource review and reclamation via the PDP is pretty much a non-starter, so I'm not going to waste my time with a policy proposal.
>> 
>>  I'll also note that LRSA also includes specific language
>>  which precludes reclamation for lack of use.  We also do
>>  not initiate reclamation for lack of use against parties
>>  when they begin the LRSA agreement process for similar
>>  reason.
> 
>> Indeed. One additional point for the LRSA.
> 
>> But will the definition of underutilized change as ARIN's free pool dries up? Some in the community have certainly called for that.
> 
> 
>> That does raise the question of why (and to what end) we are
>> more flexible with LRSA holders than RSA holders, but I'll
>> defer that discussion to the ARIN Philly meeting...
> 
> 
> I would like to point out that Prop-151 addresses all of these issues, the imbalance between legacy and non-legacy, the danger of section 12 threats to trading, and the removal of resource review and reclamation from all address holders who have had their addresses for more than one year. Plus the issues of public auctions of space are more simple to navigate when ARIN restricts itself to booking legal transfers.
> 
I would not call abandoning all regulation of the market "addressing the issues". I would
call it abdicating responsibility.

Owen



From mike at nationwideinc.com  Wed Aug 31 12:42:48 2011
From: mike at nationwideinc.com (Mike Burns)
Date: Wed, 31 Aug 2011 12:42:48 -0400
Subject: [arin-ppml] An article of interest to the community....
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
	<20110829230435.00005e6a@unknown>
	<8ED2D34B24014C23AA5F029110C39DD3@mike>
	<B39F2B0D-A4B1-4CD1-B432-D3156C90D0AE@matthew.at>
	<840D4C7B-87E0-4C8E-8AEE-211D0777A921@arin.net>
	<C392E771-14E0-4FCC-A24B-153879FF4321@matthew.at>
	<9D206214F8254469BEDB7FD85BF74F8C@mike>
	<C7DBD622-3B1E-44E9-A91E-19AA1D307A4F@delong.com>
Message-ID: <61FD99DAA60E487CB7DA152DCFA07F03@mike>

Hi Owen,
>
>> I would like to point out that Prop-151 addresses all of these issues, 
>> the imbalance between legacy and non-legacy, the danger of section 12 
>> threats to trading, and the removal of resource review and reclamation 
>> from all address holders who have had their addresses for more than one 
>> year. Plus the issues of public auctions of space are more simple to 
>> navigate when ARIN restricts itself to booking legal transfers.
>
>I would not call abandoning all regulation of the market "addressing the 
>issues". I would
>call it abdicating responsibility.

>Owen

>From Prop-151:

The recipient entity must be a current ARIN account holder.

   - The recipient must sign an RSA with ARIN.

   - The recipient entity of the transferred resources will be subject
     to current ARIN policies. In particular, in any subsequent ARIN
     IPv4 address allocation request, the recipient will be required
     to account for the efficient utilization of all IPv4 address
     space held, including all transferred resources.

   - If the recipient has already received the equivalent of a /12
     of addresses in the prior 12 months, the recipient must
     demonstrate the need for additional resources in the exact amount
     which they can justify under current ARIN policies.



For some people who crave more regulation, I suppose fewer regulations is 
equal to abandoning all regulation.

Regards,
Mike



From owen at delong.com  Wed Aug 31 12:52:26 2011
From: owen at delong.com (Owen DeLong)
Date: Wed, 31 Aug 2011 09:52:26 -0700
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <61FD99DAA60E487CB7DA152DCFA07F03@mike>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
	<20110829230435.00005e6a@unknown>
	<8ED2D34B24014C23AA5F029110C39DD3@mike>
	<B39F2B0D-A4B1-4CD1-B432-D3156C90D0AE@matthew.at>
	<840D4C7B-87E0-4C8E-8AEE-211D0777A921@arin.net>
	<C392E771-14E0-4FCC-A24B-153879FF4321@matthew.at>
	<9D206214F8254469BEDB7FD85BF74F8C@mike>
	<C7DBD622-3B1E-44E9-A91E-19AA1D307A4F@delong.com>
	<61FD99DAA60E487CB7DA152DCFA07F03@mike>
Message-ID: <E6D2D0A4-E9DE-4572-B944-04EE94EA7E43@delong.com>


On Aug 31, 2011, at 9:42 AM, Mike Burns wrote:

> Hi Owen,
>> 
>>> I would like to point out that Prop-151 addresses all of these issues, the imbalance between legacy and non-legacy, the danger of section 12 threats to trading, and the removal of resource review and reclamation from all address holders who have had their addresses for more than one year. Plus the issues of public auctions of space are more simple to navigate when ARIN restricts itself to booking legal transfers.
>> 
>> I would not call abandoning all regulation of the market "addressing the issues". I would
>> call it abdicating responsibility.
> 
>> Owen
> 
>> From Prop-151:
> 
> The recipient entity must be a current ARIN account holder.
> 
>  - The recipient must sign an RSA with ARIN.
> 
>  - The recipient entity of the transferred resources will be subject
>    to current ARIN policies. In particular, in any subsequent ARIN
>    IPv4 address allocation request, the recipient will be required
>    to account for the efficient utilization of all IPv4 address
>    space held, including all transferred resources.
> 
>  - If the recipient has already received the equivalent of a /12
>    of addresses in the prior 12 months, the recipient must
>    demonstrate the need for additional resources in the exact amount
>    which they can justify under current ARIN policies.
> 
> 
> 
> For some people who crave more regulation, I suppose fewer regulations is equal to abandoning all regulation.
> 

If they are required to account for the efficient utilization of all IPv4 address space held, including all transferred resources, then, what is the point of removing the needs basis from the transfer? Why let them transfer it only to have it revoked later if they can't account for efficient utilization?

Owen



From sethm at rollernet.us  Wed Aug 31 14:18:26 2011
From: sethm at rollernet.us (Seth Mattinen)
Date: Wed, 31 Aug 2011 11:18:26 -0700
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <4163ACB2-5247-4629-A5AC-DAC47A6F2852@delong.com>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
	<20110829230435.00005e6a@unknown>
	<8ED2D34B24014C23AA5F029110C39DD3@mike>
	<B39F2B0D-A4B1-4CD1-B432-D3156C90D0AE@matthew.at>
	<4163ACB2-5247-4629-A5AC-DAC47A6F2852@delong.com>
Message-ID: <4E5E7AF2.4060900@rollernet.us>

On 8/30/11 10:16 PM, Owen DeLong wrote:
> 
> On Aug 30, 2011, at 8:53 PM, Matthew Kaufman wrote:
> 
>>
>>
>> On Aug 30, 2011, at 5:01 PM, "Mike Burns" <mike at nationwideinc.com> wrote:
>>
>>> Hi Paul,
>>>
>>> I'm an ARIN facilitator.
>>> Can I run an auction today on eBay for address space?
>>
>> Sure you can. Of course the moment you do, that space is immediately suspected of being under-utilized and one would expect a Section 12 resource review to be in progress before the auction even closed. Particularly inconvenient if nobody meets your reserve.
>>
> 
> While auctioning your space is not an automatic free pass on section 12, I know that ARIN is
> being extremely careful not to conduct arbitrary section 12 audits against people who merely
> seek to auction their space.
> 
>> I do wonder how much space we could free up in the region today if people could advertise it's availability without this threat, and yet I believe the odds of removing all resource review and reclamation via the PDP is pretty much a non-starter, so I'm not going to waste my time with a policy proposal.
>>
> 
> You can advertise the space availability without that threat. Your post is a red herring.
> 


If one is auctioning IPv4 address space, wouldn't it be safe to say it's
unused? Wouldn't (non-legacy) unused space normally just be returned to
ARIN?

~Seth



From scottleibrand at gmail.com  Wed Aug 31 14:28:26 2011
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Wed, 31 Aug 2011 11:28:26 -0700
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <4E5E7AF2.4060900@rollernet.us>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
	<20110829230435.00005e6a@unknown>
	<8ED2D34B24014C23AA5F029110C39DD3@mike>
	<B39F2B0D-A4B1-4CD1-B432-D3156C90D0AE@matthew.at>
	<4163ACB2-5247-4629-A5AC-DAC47A6F2852@delong.com>
	<4E5E7AF2.4060900@rollernet.us>
Message-ID: <CAGkMwz6E_vUFY3eukKv5ito7EAUjztAr-a5uYgsxLu2RBRsLLQ@mail.gmail.com>

On Wed, Aug 31, 2011 at 11:18 AM, Seth Mattinen <sethm at rollernet.us> wrote:
> On 8/30/11 10:16 PM, Owen DeLong wrote:
>>
>> On Aug 30, 2011, at 8:53 PM, Matthew Kaufman wrote:
>>
>>> On Aug 30, 2011, at 5:01 PM, "Mike Burns" <mike at nationwideinc.com> wrote:
>>>
>>>> I'm an ARIN facilitator.
>>>> Can I run an auction today on eBay for address space?


>> While auctioning your space is not an automatic free pass on section 12, I know that ARIN is
>> being extremely careful not to conduct arbitrary section 12 audits against people who merely
>> seek to auction their space.


> If one is auctioning IPv4 address space, wouldn't it be safe to say it's
> unused? Wouldn't (non-legacy) unused space normally just be returned to
> ARIN?
>
> ~Seth

You could auction off a block for delivery in 3 months, and then if
your reserve is met, use the auction proceeds to renumber out of it.

-Scott


From mueller at syr.edu  Wed Aug 31 15:04:18 2011
From: mueller at syr.edu (Milton L Mueller)
Date: Wed, 31 Aug 2011 15:04:18 -0400
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <20110831032745.000030cd@unknown>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
	<20110829230435.00005e6a@unknown>	<8ED2D34B24014C23AA5F029110C39DD3@mike>
	<4E5D37DE.70805@Dilkie.com>	<4FA4451CBBCF41DC9D91AB7D5950B158@mike>
	<20110831004817.000005b3@unknown>	<C3A66A6CC66D4911B318652D7152C4D4@video>
	<20110831023206.0000759e@unknown>
	<75822E125BCB994F8446858C4B19F0D71754937061@SUEX07-MBX-04.ad.syr.edu>
	<20110831032745.000030cd@unknown>
Message-ID: <75822E125BCB994F8446858C4B19F0D71754937076@SUEX07-MBX-04.ad.syr.edu>


> however, the issue at hand here is subtly different.  ipv4 that's needed
> for dual stack would be a transition tool which presumes native ipv6 as
> an end state for some large part of (perhaps all of) the internet.
> ipv4 that's needed in the "ipv4 only, for a long time, let's avoid
> ipv6 and hope that something better comes along before we really can't
> squeeze out any more ipv4 space" vision (to which i do not subscribe.)

[Milton L Mueller] I understand that distinction. I am actually in the "transition tool" camp in terms of what I would like to see happen. I think address abundance would be great. However, I don't have to pay for any upgrades or do the work. The people who do often are in the latter camp (see Chris Engel's comments) and can and will control their own behavior and investment decisions. 
 
> i don't understand your disagreement since i'd said "policies that
> favour the [ipv4 for a long time to come] model" and since the ARIN
> community could drive toward liberalization of the transfer policy to
> include non-needs-based recipients if that was the community's
> consensus.

[Milton L Mueller] My point was that the difference between our positions is not primarily a difference over policy. It is a difference between what we see as likely to happen in the next decade. To me, IPv4 for a "long time to come" (if long time = at least a decade) is a foregone conclusion. 

> > Network operators who are already delaying or avoiding IPv6 because of
> > the extra time and costs associated with it are supposed to invest
> > time in an ARIN PDP in order to validate a choice they can already
> > make on their own? You _do_ need to get out more.
> 
> milton, this final paragraph of your message is quite edgy and almost
> caused me to just hit delete rather than answering you.  a word to the
> wise: please remain civil if you want dialogue rather than monologue.

[Milton L Mueller] apologies. really. But I was baffled by what seemed to be the implication that network operators should somehow work the ARIN process in order to gain the right to NAT or stay on IPv4 - which they can already do without ARIN's permission. Thus your comment didn't make any sense. But now, I guess, from a careful reading of context, you mean that they should lobby for further liberalizing of ARIN's transfer process. 




From mike at nationwideinc.com  Wed Aug 31 15:29:56 2011
From: mike at nationwideinc.com (Mike Burns)
Date: Wed, 31 Aug 2011 15:29:56 -0400
Subject: [arin-ppml] An article of interest to the community....
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
	<20110829230435.00005e6a@unknown>
	<8ED2D34B24014C23AA5F029110C39DD3@mike>
	<B39F2B0D-A4B1-4CD1-B432-D3156C90D0AE@matthew.at>
	<840D4C7B-87E0-4C8E-8AEE-211D0777A921@arin.net>
	<C392E771-14E0-4FCC-A24B-153879FF4321@matthew.at>
	<9D206214F8254469BEDB7FD85BF74F8C@mike>
	<C7DBD622-3B1E-44E9-A91E-19AA1D307A4F@delong.com>
	<61FD99DAA60E487CB7DA152DCFA07F03@mike>
	<E6D2D0A4-E9DE-4572-B944-04EE94EA7E43@delong.com>
Message-ID: <57080CF3068944AB94427B5A195C9EBE@mike>

>> From Prop-151:
>
> The recipient entity must be a current ARIN account holder.
>
>  - The recipient must sign an RSA with ARIN.
>
>  - The recipient entity of the transferred resources will be subject
>    to current ARIN policies. In particular, in any subsequent ARIN
>    IPv4 address allocation request, the recipient will be required
>    to account for the efficient utilization of all IPv4 address
>    space held, including all transferred resources.
>
>  - If the recipient has already received the equivalent of a /12
>    of addresses in the prior 12 months, the recipient must
>    demonstrate the need for additional resources in the exact amount
>    which they can justify under current ARIN policies.
>
>
>
> For some people who crave more regulation, I suppose fewer regulations is 
> equal to abandoning all regulation.
>

If they are required to account for the efficient utilization of all IPv4 
address space held, including all transferred resources, then, what is the 
point of removing the needs basis from the transfer? Why let them transfer 
it only to have it revoked later if they can't account for efficient 
utilization?

Owen

Hi Owen,

The idea is that if you have purchased IP addresses through 8.3 that if you 
then go to ARIN for an allocation *from the free pool* that ARIN can use 
their existing allocation policies.
I have always seen a difference between free pool addresses and transferred 
addresses. I think proper stewardship of free pool addresses requires the 
kinds of justifications already present in policy.

So what I wanted was to protect the free pool addresses by ensuring ARIN 
could take into account all the addresses the entity owns. In other words if 
they go back to ARIN for more addresses, ARIN can ask them to first utilize 
the addresses they purchased in the transfer market. If they have utilized 
them to the normal amounts, ARIN can give them addresses from the free pool.

Anyway that was my intention and if it wasn't clear, that's an example of 
the continued work on the text of the proposal which the AC is suggesting, I 
suppose.
And I welcome any input on making that clearer.

I don't think there will be that much action on the transfer market until 
the free pool depletes, and not too much overlap where companies will engage 
BOTH in the transfer market and in free pool allocations.


Regards,
Mike




From gary.buhrmaster at gmail.com  Wed Aug 31 15:34:14 2011
From: gary.buhrmaster at gmail.com (Gary Buhrmaster)
Date: Wed, 31 Aug 2011 19:34:14 +0000
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <4E5E7AF2.4060900@rollernet.us>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
	<20110829230435.00005e6a@unknown>
	<8ED2D34B24014C23AA5F029110C39DD3@mike>
	<B39F2B0D-A4B1-4CD1-B432-D3156C90D0AE@matthew.at>
	<4163ACB2-5247-4629-A5AC-DAC47A6F2852@delong.com>
	<4E5E7AF2.4060900@rollernet.us>
Message-ID: <CAMfXtQyMXH4Mz747+MKsizFor0vseNMG-WHFqO0YZtntGRVrCw@mail.gmail.com>

On Wed, Aug 31, 2011 at 18:18, Seth Mattinen <sethm at rollernet.us> wrote:
...
> If one is auctioning IPv4 address space, wouldn't it be safe to say it's
> unused? Wouldn't (non-legacy) unused space normally just be returned to
> ARIN?

That is one possibility.  Another may be that you are
willing to invest the time/effort (money) to rearrange
your usage in exchange for fair compensation of
those effort (there are no doubt edge cases, but
for many, some internal renumbering, and updating
documentation, and changing filters, and changing
security trusts, is going to have to happen; those
are real costs).  "Fair" may, of course, also just be
a euphemistic way to say profit for some transactions
(cost plus profit).

Gary


From jcurran at arin.net  Wed Aug 31 15:58:10 2011
From: jcurran at arin.net (John Curran)
Date: Wed, 31 Aug 2011 19:58:10 +0000
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <4E5E7AF2.4060900@rollernet.us>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
	<20110829230435.00005e6a@unknown>
	<8ED2D34B24014C23AA5F029110C39DD3@mike>
	<B39F2B0D-A4B1-4CD1-B432-D3156C90D0AE@matthew.at>
	<4163ACB2-5247-4629-A5AC-DAC47A6F2852@delong.com>
	<4E5E7AF2.4060900@rollernet.us>
Message-ID: <BB616C4B-7CB0-406C-81B4-35204B396581@arin.net>

On Aug 31, 2011, at 2:18 PM, Seth Mattinen wrote:

> If one is auctioning IPv4 address space, wouldn't it be safe to say it's
> unused? Wouldn't (non-legacy) unused space normally just be returned to
> ARIN?

Seth - 
 
   Hypothetical Small College received a /16 from ARIN in order
   to put all their offices and dorms on the Internet in 1998.
  
   Recently, they've realized that they probably requested too 
   much space long ago, and have also not used in efficiently 
   (due to reserving significant fixed sized address blocks for 
   each and every building on campus.)  The good news is they've 
   figured  out how to overlap multiple address blocks on single 
   network segments (which they had to learn one the first huge
   building appeared), and have a plan which would let them redo
   the entire campus to fit in single /19 address block, or maybe
   an /18 total (with another /19 reserved for long-term growth. 

   Alas,  because of the renumbering involved, they'd need to 
   bring in a lot of help one weekend, and spend probably $25K
   to $50K getting it done. If they can somehow renumber, free 
   up the "extra" space, and end up another $150K to let them 
   buy a new 10gig core switch, then it's a big win overall...

   Is their space unused?  They can't possibly free it up 
   without first doing a significant amount of effort, but 
   they have every reason to list some portion of their IP
   block for auction (as long as they are clear about the
   timing on delivery.)

Thoughts?
/John

John Curran
President and CEO
ARIN

  
   


From joe at oregon.uoregon.edu  Wed Aug 31 16:41:33 2011
From: joe at oregon.uoregon.edu (Joe St Sauver)
Date: Wed, 31 Aug 2011 13:41:33 -0700 (PDT)
Subject: [arin-ppml] An article of interest to the community....
Message-ID: <11083113413295_933D@oregon.uoregon.edu>

John asked for thoughts on the scenario:

#   Hypothetical Small College received a /16 from ARIN in order
#   to put all their offices and dorms on the Internet in 1998.
#  
#   Recently, they've realized that they probably requested too 
#   much space long ago, and have also not used in efficiently 
#   (due to reserving significant fixed sized address blocks for 
#   each and every building on campus.)  The good news is they've 
#   figured  out how to overlap multiple address blocks on single 
#   network segments (which they had to learn one the first huge
#   building appeared), and have a plan which would let them redo
#   the entire campus to fit in single /19 address block, or maybe
#   an /18 total (with another /19 reserved for long-term growth. 

Distinguish two case:

-- the campus runs NAT/PAT, and uses private addresses internally
-- the campus uses public IP addresses throughout

I will assume that we're *not* talking about the first of those two
scenarios. In the case of sites using public IP addresses throughout, 
I'd argue that even a /19 could go pretty quickly, even for a 
relatively small institution (like a prototypical liberal arts college
with a few thousand students). 

The old days, when users had one device per person, are gone. These
days it is far more common to see multiple devices: laptop, smart 
phone, tablet, game console, TV digital VCR device, VoIP phone
device, etc., etc., etc. Some of those devices may be NAT'd by the
user, or run on private airgapped networks, but at least some of those 
devices may also move around. Giving them addresses via DHCP with 
moderately persistent lease times can result in even a single device 
(like a laptop) potentially tying up multiple addresses across multiple
subnets, at least for periods of time when the user is moving around. 

Sites also need to anticipate and cope with shifting peaking user loads.
For example, residence halls might be largely empty when classes are 
in session, while classroom buildings with large lecture halls might
need many IPs during that period of time; in the evening, the reverse
may be true. Nonetheless, DHCP pools need to be sized to accomodate
those peaking loads (and dynamically resizing those DHCP pools would 
likely be an exercise in folly, as would attempting to run an 
unsegmented "flat" network architecture). 

I'd also note that as sites move to smaller blocks, their ability to 
multihome and get those smaller aggregates announced and accepted will 
decrease. That may or may not also be a consideration for some sites. 

#   Is their space unused?  

For all the reasons described above, no, their space is not unused (or 
even "underutilized") in many cases (in my opinion). 

#   They can't possibly free it up 
#   without first doing a significant amount of effort, but 
#   they have every reason to list some portion of their IP
#   block for auction (as long as they are clear about the
#   timing on delivery.)

I don't think it's correct to say that they have "every reason to list
some portion of their IP address block for auction."

I'd characterize that as an ultimately self-defeating "auto-canibalistic"
"eating of one's seed corn" strategy, potentially prematurely disposing of 
an irreplaceable core asset in a way that's kin to selling "excess" real 
estate at a campus that is surrounded on all sides by other growing and 
long term tenants. Once an asset of that sort is gone, you're never going 
to be able to get it back, and by disposing of that asset you've just 
capped your ability to grow. Yes, you got some cash, but you paid for it 
in flexibility and long term options, and those may be major "expenses."

I'm delighted when people are altruistic, and do their best to return
community assets that they don't need, but I'm not surprised when people
act in economically rational ("selfish") ways that maximize their own
benefit to the potential detriment of the community.

For those users, the economically rational folks who ARE thinking about 
selling resources (rather than simply returning unneeded resources to 
ARIN for reuse), selling an asset such as "excess" IPv4 address space 
now, before the market has fully exhausted available resources and thus 
before market prices have had a chance to reach well 
understood/predictable levels, strikes me as a potentially unsound choice.
Put another way, "timing's everything" and I'm not sure now's the right
time if you're a wanna-be IPv4 address seller or broker. 

While it's possible that IPv6 will suddenly become universally deployed, 
and the market value of IPv4 addresses will slump, I don't think that's
a very likely scenario. I think that it's more likely that IPv4 address 
space will continue to become more scarce, continue to be in demand, 
and thus IPv4 addresses will continue to appreciate in value.

If ARIN wants to incent liquidity in the IPv4 address market space, I 
think it needs to address that (perceived) reality. That would imply 
convincing people that new sources of IPv4 address space will come on 
line soon, so that those who are currently holding excess assets (with 
an eye towared longer-term appreciation) decide to "move" those assets 
now, rather than waiting. 

While we all know that Class E IPv4 addresses cannot currently be 
usefully deployed, if there was movement to try to correct that, that's
the sort of thing that might incent some who are currently "holding 
onto" IPv4 address assets to move their "inventory" while there's
still a potential resale market. (And yes, I know, bringing on Class 
E addresses might not buy much more than eighteen months of breathing 
room, but sometimes even "small" perturbations can have large 
*perceptual* impacts to systems as complex as the potential resale 
market for IPv4 address space).

Alternatively, consider how cities make sure that real estate gets 
highest and best use: taxes. You could grow soybeans in Manhattan,
but if you tried, the taxes would kill you. Taxes are a potentially
important tool for signaling that soybeans work better in sparsely 
populated great plains, and skyscrapers are a higher and better use 
of limited real estate in the city. 

Currently, the "tax" imposed on IPv4 address space per year 
(https://www.arin.net/fees/fee_schedule.html) is arguably too low 
to motivate a resource holder to dispose of assets that aren't 
needed, and therefore aren't being put to highest-and-best 
productive use. Complicating that, at least some "assets" are 
"tax exempt," anyhow. :-;

All in all, it's a fascinating economic system and set of questions
to consider, I think.

Regards,

Joe

Disclaimer: all of the above is just my POV, and you'd have to be crazy
to rely on these thoughts for anything with potential economic or 
operational impacts. :-)


From mike at nationwideinc.com  Wed Aug 31 18:33:33 2011
From: mike at nationwideinc.com (Mike Burns)
Date: Wed, 31 Aug 2011 18:33:33 -0400
Subject: [arin-ppml] An article of interest to the community....
References: <11083113413295_933D@oregon.uoregon.edu>
Message-ID: <177341F67DB44A1489DBA1C553AD9BAF@video>

My hunch is that the small college would, in fact, be using NAT for all but 
server connections.
I think the rest of Joe's message below is bang on.
The decision all address holders will have to make is  how to properly time 
this market.
Sell too soon and you may not realize maximum value and be forced to buy 
back later at higher prices.
Sell too late and risk losing the opportunity to monetize these assets if 
IPv6 takes off.
Illiquidity in the market will disincentivize transactions as people hoard 
what they have for fear addresses cannot be easily replaced in the future.
A free market will reduce the FUD that is palpaple in the current "market".
Following the lead of Nortel, other bankrupt entitles like Circuit City and 
Borders are publicly selling legacy space out of bankruptcy courts.
We don't need to pretend that we are allowing these 8.3 "sales" as a form of 
remuneration to finance renumbering anymore, we should just admit openly 
that this is a potential profit opportunity, and address holders are like 
any other asset owners who have to make these sorts of decisions.
I think we could use more concrete protections from section 12 reviews of 
sellers than the bland assertions of the current leadership that such 
reviews will not happen. Lawyers for the sellers will want more than that, 
IMO.


Regards,
Mike Burns



----- Original Message ----- 
From: "Joe St Sauver" <joe at oregon.uoregon.edu>
To: <jcurran at arin.net>
Cc: <arin-ppml at arin.net>
Sent: Wednesday, August 31, 2011 4:41 PM
Subject: Re: [arin-ppml] An article of interest to the community....


> John asked for thoughts on the scenario:
>
> #   Hypothetical Small College received a /16 from ARIN in order
> #   to put all their offices and dorms on the Internet in 1998.
> #
> #   Recently, they've realized that they probably requested too
> #   much space long ago, and have also not used in efficiently
> #   (due to reserving significant fixed sized address blocks for
> #   each and every building on campus.)  The good news is they've
> #   figured  out how to overlap multiple address blocks on single
> #   network segments (which they had to learn one the first huge
> #   building appeared), and have a plan which would let them redo
> #   the entire campus to fit in single /19 address block, or maybe
> #   an /18 total (with another /19 reserved for long-term growth.
>
> Distinguish two case:
>
> -- the campus runs NAT/PAT, and uses private addresses internally
> -- the campus uses public IP addresses throughout
>
> I will assume that we're *not* talking about the first of those two
> scenarios. In the case of sites using public IP addresses throughout,
> I'd argue that even a /19 could go pretty quickly, even for a
> relatively small institution (like a prototypical liberal arts college
> with a few thousand students).
>
> The old days, when users had one device per person, are gone. These
> days it is far more common to see multiple devices: laptop, smart
> phone, tablet, game console, TV digital VCR device, VoIP phone
> device, etc., etc., etc. Some of those devices may be NAT'd by the
> user, or run on private airgapped networks, but at least some of those
> devices may also move around. Giving them addresses via DHCP with
> moderately persistent lease times can result in even a single device
> (like a laptop) potentially tying up multiple addresses across multiple
> subnets, at least for periods of time when the user is moving around.
>
> Sites also need to anticipate and cope with shifting peaking user loads.
> For example, residence halls might be largely empty when classes are
> in session, while classroom buildings with large lecture halls might
> need many IPs during that period of time; in the evening, the reverse
> may be true. Nonetheless, DHCP pools need to be sized to accomodate
> those peaking loads (and dynamically resizing those DHCP pools would
> likely be an exercise in folly, as would attempting to run an
> unsegmented "flat" network architecture).
>
> I'd also note that as sites move to smaller blocks, their ability to
> multihome and get those smaller aggregates announced and accepted will
> decrease. That may or may not also be a consideration for some sites.
>
> #   Is their space unused?
>
> For all the reasons described above, no, their space is not unused (or
> even "underutilized") in many cases (in my opinion).
>
> #   They can't possibly free it up
> #   without first doing a significant amount of effort, but
> #   they have every reason to list some portion of their IP
> #   block for auction (as long as they are clear about the
> #   timing on delivery.)
>
> I don't think it's correct to say that they have "every reason to list
> some portion of their IP address block for auction."
>
> I'd characterize that as an ultimately self-defeating "auto-canibalistic"
> "eating of one's seed corn" strategy, potentially prematurely disposing of
> an irreplaceable core asset in a way that's kin to selling "excess" real
> estate at a campus that is surrounded on all sides by other growing and
> long term tenants. Once an asset of that sort is gone, you're never going
> to be able to get it back, and by disposing of that asset you've just
> capped your ability to grow. Yes, you got some cash, but you paid for it
> in flexibility and long term options, and those may be major "expenses."
>
> I'm delighted when people are altruistic, and do their best to return
> community assets that they don't need, but I'm not surprised when people
> act in economically rational ("selfish") ways that maximize their own
> benefit to the potential detriment of the community.
>
> For those users, the economically rational folks who ARE thinking about
> selling resources (rather than simply returning unneeded resources to
> ARIN for reuse), selling an asset such as "excess" IPv4 address space
> now, before the market has fully exhausted available resources and thus
> before market prices have had a chance to reach well
> understood/predictable levels, strikes me as a potentially unsound choice.
> Put another way, "timing's everything" and I'm not sure now's the right
> time if you're a wanna-be IPv4 address seller or broker.
>
> While it's possible that IPv6 will suddenly become universally deployed,
> and the market value of IPv4 addresses will slump, I don't think that's
> a very likely scenario. I think that it's more likely that IPv4 address
> space will continue to become more scarce, continue to be in demand,
> and thus IPv4 addresses will continue to appreciate in value.
>
> If ARIN wants to incent liquidity in the IPv4 address market space, I
> think it needs to address that (perceived) reality. That would imply
> convincing people that new sources of IPv4 address space will come on
> line soon, so that those who are currently holding excess assets (with
> an eye towared longer-term appreciation) decide to "move" those assets
> now, rather than waiting.
>
> While we all know that Class E IPv4 addresses cannot currently be
> usefully deployed, if there was movement to try to correct that, that's
> the sort of thing that might incent some who are currently "holding
> onto" IPv4 address assets to move their "inventory" while there's
> still a potential resale market. (And yes, I know, bringing on Class
> E addresses might not buy much more than eighteen months of breathing
> room, but sometimes even "small" perturbations can have large
> *perceptual* impacts to systems as complex as the potential resale
> market for IPv4 address space).
>
> Alternatively, consider how cities make sure that real estate gets
> highest and best use: taxes. You could grow soybeans in Manhattan,
> but if you tried, the taxes would kill you. Taxes are a potentially
> important tool for signaling that soybeans work better in sparsely
> populated great plains, and skyscrapers are a higher and better use
> of limited real estate in the city.
>
> Currently, the "tax" imposed on IPv4 address space per year
> (https://www.arin.net/fees/fee_schedule.html) is arguably too low
> to motivate a resource holder to dispose of assets that aren't
> needed, and therefore aren't being put to highest-and-best
> productive use. Complicating that, at least some "assets" are
> "tax exempt," anyhow. :-;
>
> All in all, it's a fascinating economic system and set of questions
> to consider, I think.
>
> Regards,
>
> Joe
>
> Disclaimer: all of the above is just my POV, and you'd have to be crazy
> to rely on these thoughts for anything with potential economic or
> operational impacts. :-)
> _______________________________________________
> 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 jcurran at arin.net  Wed Aug 31 18:42:50 2011
From: jcurran at arin.net (John Curran)
Date: Wed, 31 Aug 2011 22:42:50 +0000
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <177341F67DB44A1489DBA1C553AD9BAF@video>
References: <11083113413295_933D@oregon.uoregon.edu>
	<177341F67DB44A1489DBA1C553AD9BAF@video>
Message-ID: <B3E16403-652D-4FB4-B10A-48A6A1E0A16A@arin.net>

On Aug 31, 2011, at 6:33 PM, Mike Burns wrote:

> I think we could use more concrete protections from section 12 reviews of sellers than the bland assertions of the current leadership that such reviews will not happen. Lawyers for the sellers will want more than that, IMO.

Mike - 

  Could you be specific regarding your suggestion?

  With respect to the LRSA, the language is already there 
  (10.b).  What additional protections do you propose?

/John

John Curran
President and CEO
ARIN



From sethm at rollernet.us  Wed Aug 31 18:53:16 2011
From: sethm at rollernet.us (Seth Mattinen)
Date: Wed, 31 Aug 2011 15:53:16 -0700
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <177341F67DB44A1489DBA1C553AD9BAF@video>
References: <11083113413295_933D@oregon.uoregon.edu>
	<177341F67DB44A1489DBA1C553AD9BAF@video>
Message-ID: <4E5EBB5C.9060308@rollernet.us>

On 8/31/11 3:33 PM, Mike Burns wrote:
> My hunch is that the small college would, in fact, be using NAT for all
> but server connections.

The school I went to used public space everywhere, including the dorms.
Although it's only around 18k students and 1k staff.


> I think we could use more concrete protections from section 12 reviews
> of sellers than the bland assertions of the current leadership that such
> reviews will not happen. Lawyers for the sellers will want more than
> that, IMO.
> 

I don't think sellers deserve any special protections just because
they're sellers. Simply return it to the free pool if it's a concern.
Although at this point "for the good of the community" is dying in favor
of "for the good of profit".

~Seth


From matthew at matthew.at  Wed Aug 31 19:15:03 2011
From: matthew at matthew.at (Matthew Kaufman)
Date: Thu, 01 Sep 2011 00:15:03 +0100
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <75822E125BCB994F8446858C4B19F0D71754937076@SUEX07-MBX-04.ad.syr.edu>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
	<20110829230435.00005e6a@unknown>	<8ED2D34B24014C23AA5F029110C39DD3@mike>
	<4E5D37DE.70805@Dilkie.com>	<4FA4451CBBCF41DC9D91AB7D5950B158@mike>
	<20110831004817.000005b3@unknown>	<C3A66A6CC66D4911B318652D7152C4D4@video>
	<20110831023206.0000759e@unknown>
	<75822E125BCB994F8446858C4B19F0D71754937061@SUEX07-MBX-04.ad.syr.edu>
	<20110831032745.000030cd@unknown>
	<75822E125BCB994F8446858C4B19F0D71754937076@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <4E5EC077.2010807@matthew.at>

On 8/31/11 8:04 PM, Milton L Mueller wrote:
> [Milton L Mueller] My point was that the difference between our 
> positions is not primarily a difference over policy. It is a 
> difference between what we see as likely to happen in the next decade. 
> To me, IPv4 for a "long time to come" (if long time = at least a 
> decade) is a foregone conclusion.

Which is an excellent reason to allow those who find IPv4 space 
available to purchase at least a year's worth, if not more, to mitigate 
the risk of running out and not finding more the next time around.

Matthew Kaufman


From owen at delong.com  Wed Aug 31 19:21:45 2011
From: owen at delong.com (Owen DeLong)
Date: Wed, 31 Aug 2011 16:21:45 -0700
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <75822E125BCB994F8446858C4B19F0D71754937076@SUEX07-MBX-04.ad.syr.edu>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
	<20110829230435.00005e6a@unknown>	<8ED2D34B24014C23AA5F029110C39DD3@mike>
	<4E5D37DE.70805@Dilkie.com>	<4FA4451CBBCF41DC9D91AB7D5950B158@mike>
	<20110831004817.000005b3@unknown>	<C3A66A6CC66D4911B318652D7152C4D4@video>
	<20110831023206.0000759e@unknown>
	<75822E125BCB994F8446858C4B19F0D71754937061@SUEX07-MBX-04.ad.syr.edu>
	<20110831032745.000030cd@unknown>
	<75822E125BCB994F8446858C4B19F0D71754937076@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <8BE8E13F-4F53-4A45-A65A-8045793438BA@delong.com>


On Aug 31, 2011, at 12:04 PM, Milton L Mueller wrote:

> 
>> however, the issue at hand here is subtly different.  ipv4 that's needed
>> for dual stack would be a transition tool which presumes native ipv6 as
>> an end state for some large part of (perhaps all of) the internet.
>> ipv4 that's needed in the "ipv4 only, for a long time, let's avoid
>> ipv6 and hope that something better comes along before we really can't
>> squeeze out any more ipv4 space" vision (to which i do not subscribe.)
> 
> [Milton L Mueller] I understand that distinction. I am actually in the "transition tool" camp in terms of what I would like to see happen. I think address abundance would be great. However, I don't have to pay for any upgrades or do the work. The people who do often are in the latter camp (see Chris Engel's comments) and can and will control their own behavior and investment decisions. 
> 

Absolutely. I just think that Chris underestimates what it is going to cost him to try and prolong the life of IPv4 and that as he begins to realize those costs, IPv6 will become radically more attractive in terms of cost/benefit ratio. Unfortunately, he probably will not realize this until he has wasted relatively vast sums of money on expensive equipment to try and keep IPv4 on life support when that money would have been better spent moving towards IPv6.

Such is the short-term thinking of a market.

>> i don't understand your disagreement since i'd said "policies that
>> favour the [ipv4 for a long time to come] model" and since the ARIN
>> community could drive toward liberalization of the transfer policy to
>> include non-needs-based recipients if that was the community's
>> consensus.
> 
> [Milton L Mueller] My point was that the difference between our positions is not primarily a difference over policy. It is a difference between what we see as likely to happen in the next decade. To me, IPv4 for a "long time to come" (if long time = at least a decade) is a foregone conclusion. 
> 

To me, "IPv4 for a long time" is what those who lack vision will likely invest in. Those who can look a little beyond the next 10Q will be able to see that "IPv4 while we have to and IPv6 as soon as possible" yields much better cost benefit ratios over the next few years, while yielding slight penalties for one or two quarters.

>>> Network operators who are already delaying or avoiding IPv6 because of
>>> the extra time and costs associated with it are supposed to invest
>>> time in an ARIN PDP in order to validate a choice they can already
>>> make on their own? You _do_ need to get out more.
>> 
>> milton, this final paragraph of your message is quite edgy and almost
>> caused me to just hit delete rather than answering you.  a word to the
>> wise: please remain civil if you want dialogue rather than monologue.
> 
> [Milton L Mueller] apologies. really. But I was baffled by what seemed to be the implication that network operators should somehow work the ARIN process in order to gain the right to NAT or stay on IPv4 - which they can already do without ARIN's permission. Thus your comment didn't make any sense. But now, I guess, from a careful reading of context, you mean that they should lobby for further liberalizing of ARIN's transfer process. 
> 

Network operators who want to NAT and stay on IPv4 with their existing resources can do so for free. Network operators who want policy optimized for their ability to continue to NAT and obtain additional IPv4 addresses from (some source I can't imagine), OTOH, will probably need to work to bend ARIN policy to that will.

Owen



From owen at delong.com  Wed Aug 31 19:26:53 2011
From: owen at delong.com (Owen DeLong)
Date: Wed, 31 Aug 2011 16:26:53 -0700
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <57080CF3068944AB94427B5A195C9EBE@mike>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
	<20110829230435.00005e6a@unknown>
	<8ED2D34B24014C23AA5F029110C39DD3@mike>
	<B39F2B0D-A4B1-4CD1-B432-D3156C90D0AE@matthew.at>
	<840D4C7B-87E0-4C8E-8AEE-211D0777A921@arin.net>
	<C392E771-14E0-4FCC-A24B-153879FF4321@matthew.at>
	<9D206214F8254469BEDB7FD85BF74F8C@mike>
	<C7DBD622-3B1E-44E9-A91E-19AA1D307A4F@delong.com>
	<61FD99DAA60E487CB7DA152DCFA07F03@mike>
	<E6D2D0A4-E9DE-4572-B944-04EE94EA7E43@delong.com>
	<57080CF3068944AB94427B5A195C9EBE@mike>
Message-ID: <77122433-B439-47F1-A945-9ECD2E573A25@delong.com>


On Aug 31, 2011, at 12:29 PM, Mike Burns wrote:

>>> From Prop-151:
>> 
>> The recipient entity must be a current ARIN account holder.
>> 
>> - The recipient must sign an RSA with ARIN.
>> 
>> - The recipient entity of the transferred resources will be subject
>>   to current ARIN policies. In particular, in any subsequent ARIN
>>   IPv4 address allocation request, the recipient will be required
>>   to account for the efficient utilization of all IPv4 address
>>   space held, including all transferred resources.
>> 
>> - If the recipient has already received the equivalent of a /12
>>   of addresses in the prior 12 months, the recipient must
>>   demonstrate the need for additional resources in the exact amount
>>   which they can justify under current ARIN policies.
>> 
>> 
>> 
>> For some people who crave more regulation, I suppose fewer regulations is equal to abandoning all regulation.
>> 
> 
> If they are required to account for the efficient utilization of all IPv4 address space held, including all transferred resources, then, what is the point of removing the needs basis from the transfer? Why let them transfer it only to have it revoked later if they can't account for efficient utilization?
> 
> Owen
> 
> Hi Owen,
> 
> The idea is that if you have purchased IP addresses through 8.3 that if you then go to ARIN for an allocation *from the free pool* that ARIN can use their existing allocation policies.
> I have always seen a difference between free pool addresses and transferred addresses. I think proper stewardship of free pool addresses requires the kinds of justifications already present in policy.
> 

You have a vivid imagination, IMHO. You are seeing a difference where, as near as I can tell, none exists.

By the way, APNIC reached consensus on proposal 096 yesterday, so, there is no longer ANY RIR which supports the abandonment of needs basis in transfers.

> So what I wanted was to protect the free pool addresses by ensuring ARIN could take into account all the addresses the entity owns. In other words if they go back to ARIN for more addresses, ARIN can ask them to first utilize the addresses they purchased in the transfer market. If they have utilized them to the normal amounts, ARIN can give them addresses from the free pool.
> 

Then you are NOT requiring the recipient of the transferred resources to be subject to current ARIN policies, in specific you must disable section 12 from affecting transferred resources to meet the statement you made above.

> Anyway that was my intention and if it wasn't clear, that's an example of the continued work on the text of the proposal which the AC is suggesting, I suppose.
> And I welcome any input on making that clearer.
> 

Your statements above distort the facts by ignoring certain details. As such, it was my intent to call attention to this misinformation. Sorry if I was not clear. You have, however, now clarified the details so that at least people can view this in the context of its actual effect. I am not accusing you of an intentional distortion of the facts. I think it was an honest oversight. Nonetheless, I think it is important to recognize that your policy does not allow us to have our cake and eat it too.

> I don't think there will be that much action on the transfer market until the free pool depletes, and not too much overlap where companies will engage BOTH in the transfer market and in free pool allocations.
> 

Correct. This is one of the primary reasons I feel it is vital to preserve needs-basis even after the free pool is depleted rather than have it become an automatic trigger for abandoning all regulation of the market just as the market gets going in earnest (which is, IMHO, the effect of your proposal).

Owen



From mysidia at gmail.com  Wed Aug 31 22:19:42 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Wed, 31 Aug 2011 21:19:42 -0500
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <CAGkMwz6E_vUFY3eukKv5ito7EAUjztAr-a5uYgsxLu2RBRsLLQ@mail.gmail.com>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
	<20110829230435.00005e6a@unknown>
	<8ED2D34B24014C23AA5F029110C39DD3@mike>
	<B39F2B0D-A4B1-4CD1-B432-D3156C90D0AE@matthew.at>
	<4163ACB2-5247-4629-A5AC-DAC47A6F2852@delong.com>
	<4E5E7AF2.4060900@rollernet.us>
	<CAGkMwz6E_vUFY3eukKv5ito7EAUjztAr-a5uYgsxLu2RBRsLLQ@mail.gmail.com>
Message-ID: <CAAAwwbWwEc4Twb5gk3cFgM_RtSKevM0i=p-uuRZsiPE0q1MAfw@mail.gmail.com>

On Wed, Aug 31, 2011 at 1:28 PM, Scott Leibrand <scottleibrand at gmail.com> wrote:
> You could auction off a block for delivery in 3 months, and then if
> your reserve is met, use the auction proceeds to renumber out of it.

How can you "auction off a block for delivery in 3 months,"   without
claiming property rights
in order to "sell" this property.....    Remember what the RSA  says,
the one that non-legacy
holders have to sign?


"
9. NO PROPERTY RIGHTS
Applicant acknowledges and agrees that the number resources are not
property (real, personal, or intellectual) and that Applicant does not
acquire any property rights in or to any number resources by virtue of
this Agreement or otherwise. Applicant further agrees that it will not
attempt, directly or indirectly, to obtain or assert any trademark,
service mark, copyright, or any other form of property rights in any
number resources in the United States or any other country.
"

--
-JH


From owen at delong.com  Wed Aug 31 22:26:30 2011
From: owen at delong.com (Owen DeLong)
Date: Wed, 31 Aug 2011 19:26:30 -0700
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <CAAAwwbWwEc4Twb5gk3cFgM_RtSKevM0i=p-uuRZsiPE0q1MAfw@mail.gmail.com>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
	<20110829230435.00005e6a@unknown>
	<8ED2D34B24014C23AA5F029110C39DD3@mike>
	<B39F2B0D-A4B1-4CD1-B432-D3156C90D0AE@matthew.at>
	<4163ACB2-5247-4629-A5AC-DAC47A6F2852@delong.com>
	<4E5E7AF2.4060900@rollernet.us>
	<CAGkMwz6E_vUFY3eukKv5ito7EAUjztAr-a5uYgsxLu2RBRsLLQ@mail.gmail.com>
	<CAAAwwbWwEc4Twb5gk3cFgM_RtSKevM0i=p-uuRZsiPE0q1MAfw@mail.gmail.com>
Message-ID: <31B2AF62-8BE1-4A3F-BEA0-97F78D867D35@delong.com>

You are not selling the addresses, you are selling the registration and
guaranteed uniqueness.

Owen

On Aug 31, 2011, at 7:19 PM, Jimmy Hess wrote:

> On Wed, Aug 31, 2011 at 1:28 PM, Scott Leibrand <scottleibrand at gmail.com> wrote:
>> You could auction off a block for delivery in 3 months, and then if
>> your reserve is met, use the auction proceeds to renumber out of it.
> 
> How can you "auction off a block for delivery in 3 months,"   without
> claiming property rights
> in order to "sell" this property.....    Remember what the RSA  says,
> the one that non-legacy
> holders have to sign?
> 
> 
> "
> 9. NO PROPERTY RIGHTS
> Applicant acknowledges and agrees that the number resources are not
> property (real, personal, or intellectual) and that Applicant does not
> acquire any property rights in or to any number resources by virtue of
> this Agreement or otherwise. Applicant further agrees that it will not
> attempt, directly or indirectly, to obtain or assert any trademark,
> service mark, copyright, or any other form of property rights in any
> number resources in the United States or any other country.
> "
> 
> --
> -JH
> _______________________________________________
> 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 jcurran at arin.net  Wed Aug 31 22:32:23 2011
From: jcurran at arin.net (John Curran)
Date: Thu, 1 Sep 2011 02:32:23 +0000
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <CAAAwwbWwEc4Twb5gk3cFgM_RtSKevM0i=p-uuRZsiPE0q1MAfw@mail.gmail.com>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
	<20110829230435.00005e6a@unknown>
	<8ED2D34B24014C23AA5F029110C39DD3@mike>
	<B39F2B0D-A4B1-4CD1-B432-D3156C90D0AE@matthew.at>
	<4163ACB2-5247-4629-A5AC-DAC47A6F2852@delong.com>
	<4E5E7AF2.4060900@rollernet.us>
	<CAGkMwz6E_vUFY3eukKv5ito7EAUjztAr-a5uYgsxLu2RBRsLLQ@mail.gmail.com>
	<CAAAwwbWwEc4Twb5gk3cFgM_RtSKevM0i=p-uuRZsiPE0q1MAfw@mail.gmail.com>
Message-ID: <F289CBDE-BA33-468E-8B57-7ABB460512AB@arin.net>

On Aug 31, 2011, at 10:19 PM, Jimmy Hess wrote:

> On Wed, Aug 31, 2011 at 1:28 PM, Scott Leibrand <scottleibrand at gmail.com> wrote:
>> You could auction off a block for delivery in 3 months, and then if
>> your reserve is met, use the auction proceeds to renumber out of it.
> 
> How can you "auction off a block for delivery in 3 months,"   without
> claiming property rights
> in order to "sell" this property.....    Remember what the RSA  says,
> the one that non-legacy
> holders have to sign?

Jimmy - 
 
   Nothing prevents a party from transferring their contractual rights
   to use of a particular number block (as long as its in accordance 
   with adopted policy.)   Go to www.arin.net, and click on the 
   "Got IPv4 Addresses?" link for details.

FYI,
/John

John Curran
President and CEO
ARIN




From xing.cernet at gmail.com  Wed Aug 31 22:38:08 2011
From: xing.cernet at gmail.com (Xing Li)
Date: Thu, 1 Sep 2011 10:38:08 +0800
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <3909A0D9-BDB5-4727-9D49-9D8B798108FD@delong.com>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
	<20110829230435.00005e6a@unknown>
	<75822E125BCB994F8446858C4B19F0D7175496FFDD@SUEX07-MBX-04.ad.syr.edu>
	<F55FF9C4FDB76643AE0CEC06D0F5CEB30EBC290055@Skyhawk>
	<3909A0D9-BDB5-4727-9D49-9D8B798108FD@delong.com>
Message-ID: <CAN3d7SHajc2HMWeSeSkO_ciuEsFO+95nNs1NsHamMJL0BqYZtA@mail.gmail.com>

I think that's the real disconnect. This list is primarily concerned with
address resource policy. From the perspective of address policy, IPv6 is
pretty much a no brainer as it DOES solve the resource shortage issue
admirably. From almost every other perspective, IPv6 stinks on ice and for
those of us who would have to deal the problems it presents, it's a no
brainer to try to extend the useful life on IPv4 as much as possible.

Speaking as an end-user who is fortunate enough to have enough address space
in both address families, I'd much rather have IPv6 than have to suffer
through NAT, let alone the various forms of NAT++ that are coming (IVI,
DS-Lite, 6RD, NAT64, NAT444, NAT4444, NAT44444444444..., etc.).


IVI and NAT64 are different from other kind of transition tools, since they
can make IPv6-only hosts communicate with the IPv4 Internet.  Our experience
indicates that IPv6-only hosts naturally achieve the IPv4/IPv6 transition.

Regards,

xing

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110901/7e750767/attachment.htm>

From owen at delong.com  Wed Aug 31 22:46:52 2011
From: owen at delong.com (Owen DeLong)
Date: Wed, 31 Aug 2011 19:46:52 -0700
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <4E5EED0C.4000701@cernet.edu.cn>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>	<20110829230435.00005e6a@unknown>	<75822E125BCB994F8446858C4B19F0D7175496FFDD@SUEX07-MBX-04.ad.syr.edu>	<F55FF9C4FDB76643AE0CEC06D0F5CEB30EBC290055@Skyhawk>
	<3909A0D9-BDB5-4727-9D49-9D8B798108FD@delong.com>
	<4E5EED0C.4000701@cernet.edu.cn>
Message-ID: <CC7A0EE4-989A-460D-BD51-B3EB2AB09704@delong.com>


On Aug 31, 2011, at 7:25 PM, Xing Li wrote:

> 
>>> I think that's the real disconnect. This list is primarily concerned with address resource policy. From the perspective of address policy, IPv6 is pretty much a no brainer as it DOES solve the resource shortage issue admirably. From almost every other perspective, IPv6 stinks on ice and for those of us who would have to deal the problems it presents, it's a no brainer to try to extend the useful life on IPv4 as much as possible.
>>> 
>> Speaking as an end-user who is fortunate enough to have enough address space in both address families, I'd much rather have IPv6 than have to suffer through NAT, let alone the various forms of NAT++ that are coming (IVI, DS-Lite, 6RD, NAT64, NAT444, NAT4444, NAT44444444444..., etc.).
> 
> IVI and NAT64 are different from other kind of transition tools, since they can make IPv6-only hosts communicate with the IPv4 Internet.  Our experience indicates that IPv6-only hosts naturally achieve the IPv4/IPv6 transition.
> 

I wasn't trying to dis any of the transition protocols and I certainly agree that IVI, NAT64, and DS-Lite offer better promise for a better long-term outcome than the others. My point was that other than native dual-stack leading to native IPv6, every thing else is going to suck for varying values of suck.

Owen



From hannigan at gmail.com  Wed Aug 31 23:22:15 2011
From: hannigan at gmail.com (Martin Hannigan)
Date: Wed, 31 Aug 2011 23:22:15 -0400
Subject: [arin-ppml] An article of interest to the community....
In-Reply-To: <CAAAwwbWwEc4Twb5gk3cFgM_RtSKevM0i=p-uuRZsiPE0q1MAfw@mail.gmail.com>
References: <0619B23D3BCE492DA6BE1096EA3683C5@mike>
	<20110829230435.00005e6a@unknown>
	<8ED2D34B24014C23AA5F029110C39DD3@mike>
	<B39F2B0D-A4B1-4CD1-B432-D3156C90D0AE@matthew.at>
	<4163ACB2-5247-4629-A5AC-DAC47A6F2852@delong.com>
	<4E5E7AF2.4060900@rollernet.us>
	<CAGkMwz6E_vUFY3eukKv5ito7EAUjztAr-a5uYgsxLu2RBRsLLQ@mail.gmail.com>
	<CAAAwwbWwEc4Twb5gk3cFgM_RtSKevM0i=p-uuRZsiPE0q1MAfw@mail.gmail.com>
Message-ID: <CAMDXq5NMO-WNVvpQ9hNECR9XbRq4UJ2SXkiyfRQZjRa+HhicBA@mail.gmail.com>

On Wed, Aug 31, 2011 at 10:19 PM, Jimmy Hess <mysidia at gmail.com> wrote:
> On Wed, Aug 31, 2011 at 1:28 PM, Scott Leibrand <scottleibrand at gmail.com> wrote:
>> You could auction off a block for delivery in 3 months, and then if
>> your reserve is met, use the auction proceeds to renumber out of it.
>
> How can you "auction off a block for delivery in 3 months," ? without
> claiming property rights
> in order to "sell" this property..... ? ?Remember what the RSA ?says,
> the one that non-legacy
> holders have to sign?
>
>
> "
> 9. NO PROPERTY RIGHTS
> Applicant acknowledges and agrees that the number resources are not
> property (real, personal, or intellectual) and that Applicant does not
> acquire any property rights in or to any number resources by virtue of
> this Agreement or otherwise. Applicant further agrees that it will not
> attempt, directly or indirectly, to obtain or assert any trademark,
> service mark, copyright, or any other form of property rights in any
> number resources in the United States or any other country.
> "
>

How does this apply to legacy holders who haven't signed any agreement
with ARIN or better yet, those who have signed a modified agreement?

Use your favorite search engine and take a look at "call option".


Best,

-M<