From andrew.dul at quark.net  Mon Feb  3 10:56:01 2014
From: andrew.dul at quark.net (Andrew Dul)
Date: Mon, 03 Feb 2014 07:56:01 -0800
Subject: [arin-ppml] Draft Policy ARIN-2014-5: Remove 7.2 Lame
	Delegations
In-Reply-To: <CAP-guGXtXJ=wCi1PO2gxDapeCX1srLEm-L6=UYpk=fb_5S_SmQ@mail.gmail.com>
References: <52E91DCC.1070206@arin.net>
	<CAP-guGXtXJ=wCi1PO2gxDapeCX1srLEm-L6=UYpk=fb_5S_SmQ@mail.gmail.com>
Message-ID: <52EFBC11.5050404@quark.net>

On 1/29/2014 4:18 PM, William Herrin wrote:
> On Wed, Jan 29, 2014 at 10:27 AM, ARIN <info at arin.net> wrote:
>> On 24 January 2014 the ARIN Advisory Council (AC) accepted "ARIN-prop-197
>> Remove 7.2 Lame Delegations" as a Draft Policy.
>>
>> ARIN will actively identify lame DNS name server(s) for reverse address
>> delegations associated with address blocks allocated, assigned or
>> administered by ARIN. Upon identification of a lame delegation, ARIN shall
>> attempt to contact the POC for that resource and resolve the issue. If,
>> following due diligence, ARIN is unable to resolve the lame delegation, ARIN
>> will update the Whois database records resulting in the removal of lame
>> servers.
> Howdy,
>
> Two decades of software improvements later, is there a *technical*
> need for ARIN to take any action at all with respect to lame
> delegations? Any stable DNS resolver has to deal with routine lame
> delegations in the forward DNS anyway.
>
> On a related note, does anyone actually make use of section 7.1,
> allowing an organization with less than a /16 to have ARIN handle all
> its RDNS rather than delegating it? How does that work? What are the
> mechanics involved in a registrant having ARIN set and change RDNS PTR
> records for him?
>
> I'm wondering if there's a good reason to keep any part of section 7 at all.
>
> Regards,
> Bill Herrin
>
It would be helpful for this discussion if ARIN staff could produce a
brief statement on the current state of how this section has been
implemented within ARIN's operational procedures.  I assume some of this
will come later with the staff assessment, but a limited response might
be helpful for the community to understand how this change would effect
ARIN's current operational procedures.

Thanks,
Andrew




From andrew.dul at quark.net  Mon Feb  3 10:51:23 2014
From: andrew.dul at quark.net (Andrew Dul)
Date: Mon, 03 Feb 2014 07:51:23 -0800
Subject: [arin-ppml] Draft Policy ARIN-2014-6: Remove 7.1
In-Reply-To: <52E91DE0.2010004@arin.net>
References: <52E91DE0.2010004@arin.net>
Message-ID: <52EFBAFB.8040002@quark.net>


> Draft Policy ARIN-2014-6
> Remove 7.1
>
> Date: 29 January 2014
>
> Problem Statement:
>
> 7.1 attempts to assert rules on rDNS management at ARIN. It fails to
> do so because it only addresses in-addr.arpa (missing equally
> important rules in ip6.arpa). It's also not based on any RFC; it's an
> arbitrary decision made by ARIN technical staff. We should remove this
> text from policy, as it represents operational practice rather than
> ARIN number policy.
>
> Policy statement:
>
> Remove 7.1
>
> Comments:
> a.Timetable for implementation: Immediate
> b.Anything else:
>
> 7.1. Maintaining IN-ADDRs
>
> All ISPs receiving one or more distinct /16 CIDR blocks of IP
> addresses from ARIN will be responsible for maintaining all
> IN-ADDR.ARPA domain records for their respective customers. For blocks
> smaller than /16, and for the segment of larger blocks  smaller than
> /16, ARIN can maintain IN-ADDRs.
>

At this time I'm opposed to this policy.  While I agree this text is out
of date and probably should be updated.  I don't necessarily agree that
the section should just be removed.  Reverse DNS is an important part of
the services that ARIN provides to address holders.  I believe that it
is wholly appropriate for the NRMP to contain a section describing how
ARIN should implement rDNS services to address holders.

Andrew


From info at arin.net  Mon Feb  3 13:09:20 2014
From: info at arin.net (ARIN)
Date: Mon, 03 Feb 2014 13:09:20 -0500
Subject: [arin-ppml] Recommended Draft Policy ARIN-2013-8: Subsequent
 Allocations for New Multiple Discrete Networks
Message-ID: <52EFDB50.7030604@arin.net>

Recommended Draft Policy ARIN-2013-8
Subsequent Allocations for New Multiple Discrete Networks

On 24 January 2014 the ARIN Advisory Council (AC) recommended 
ARIN-2013-8 for adoption, making it a Recommended Draft Policy.

Draft Policy ARIN-2013-8 is below and can be found at:
https://www.arin.net/policy/proposals/2013_8.html

You are encouraged to discuss Draft Policy 2013-8 on the PPML prior to
the upcoming Public Policy Consultation. 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,

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


## * ##


Recommended Draft Policy ARIN-2013-8
Subsequent Allocations for New Multiple Discrete Networks

Date: 29 January 2014

AC's assessment of conformance with the Principles of Internet Number 
Resource Policy:

"Subsequent Allocations for Additional Discrete Network Sites This 
policy enables fair and impartial number resource administration by 
documenting the current practice regarding allocations for additional 
discrete network sites.  The ARIN staff has been following a procedure 
that has not been documented until now.  By documenting this process the 
community has clear understanding of how to get address space for 
additional network sites.

This is a technically sound proposal that has been in practice for some 
time.  It had just not been documented.

This proposal has received several notes of support on the PPML and to 
date has received no negative feedback."

Problem Statement:

During the ARIN 32 PPM, ARIN staff noted in the Policy Implementation
and Experience Report that the current Multiple Discrete Network Policy
(MDN) does not contain criteria for new sites of an existing MDN customer.

Current ARIN practice is to use the Immediate Need policy (NRPM 4.2.1.6).

This policy proposal seeks to add NRPM text to clarify criteria for new
sites of existing MDN customers.

Policy statement:

IPv4:

Add the following statement to section 4.5.4.

Upon verification that the organization has already obtained
connectivity at its new discrete network site, the new networks shall be
allocated the minimum allocation size under section 4.2.1.5 unless the
organization can demonstrate additional need using the immediate need
criteria (4.2.1.6).

IPv6:

Add an additional reference to section 6.11.5.b such that it references
both the initial allocation and subsequent allocation sections of the
IPv6 LIR policy.

"Each network will be judged against the existing utilization criteria
specified in 6.5.2 and 6.5.3 as if it were a separate organization..."

Comments:
a. Timetable for implementation: immediate
b. This policy is being proposed based upon the Policy Implementation
& Experience Report from ARIN 32.

https://www.arin.net/participate/meetings/reports/ARIN_32/PDF/thursday/nobile-policy.pdf
c: Older versions of the MDN policy did contain new network criteria.
This criteria appears to have been dropped during subsequent
rewrites of the MDN policy. "The organization must not allocate a CIDR
block larger than the current minimum assignment
size of the RIR (currently /20 for ARIN) to a new network."
(https://www.arin.net/policy/archive/nrpm_20041015.pdf)



##########

ARIN Staff and Legal Assessment

Date of Assessment: 15 January 2014

1. Proposal Summary (Staff Understanding)

This proposal adds definitive criteria to existing policy NRPM 4.5 
"Multiple Discrete Networks" and NRPM 6.11" IPv6 Multiple Discrete 
Networks" to assist staff and the community in determining allocation 
sizes for the new sites of existing MDN customers.

2. Comments
A. ARIN Staff Comments

This proposal is the result of an ARIN staff policy experience report in 
which it was noted that no criteria existed for the new sites of an 
existing MDN customer.

     This proposal adds that much needed/missing criteria and is 
consistent with current staff practice.
         Must provide evidence of connectivity at the new site
         Clearly states that new sites will receive ARIN?s minimum 
published allocation size and if this isn?t sufficient, must qualify 
under the immediate need policy (NRPM 4.2.1.6).
         Adds to the IPv6 MDN policy do that it includes both initial 
and subsequent allocation criteria.

         B. ARIN General Counsel

Does not appear to create legal risk.

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

Problem Statement:
During the ARIN 32 PPM, ARIN staff noted in the Policy Implementation 
and Experience Report that the current Multiple Discrete Network Policy 
(MDN) does not contain criteria for new sites of an existing MDN customer.
Current ARIN practice is to use the Immediate Need policy (NRPM 4.2.1.6).
This policy proposal seeks to add NRPM text to clarify criteria for new 
sites of existing MDN customers.

Policy Statement:
IPv4:
Add the following statement to section 4.5.4.
Upon verification that the organization has already obtained 
connectivity at its new discrete network site, the new networks shall be 
allocated the minimum allocation size under section 4.2.1.5 unless the 
organization can demonstrate additional need using the immediate need 
criteria (4.2.1.6).
IPv6:
Add an additional reference to section 6.11.5.b such that it references 
both the initial allocation and subsequent allocation sections of the 
IPv6 LIR policy.
"Each network will be judged against the existing utilization criteria 
specified in 6.5.2 and 6.5.3 as if it were a separate organization..."

Comments:
a. Timetable for implementation: immediate
b. This policy is being proposed based upon the Policy Implementation & 
Experience Report from ARIN 32.
https://www.arin.net/participate/meetings/reports/ARIN_32/PDF/thursday/nobile-policy.pdf
c: Older versions of the MDN policy did contain new network criteria. 
This criteria appears to have been dropped during subsequent rewrites of 
the MDN policy. "The organization must not allocate a CIDR block larger 
than the current minimum assignment size of the RIR (currently /20 for 
ARIN) to a new network." 
(https://www.arin.net/policy/archive/nrpm_20041015.pdf)


From jcurran at arin.net  Mon Feb  3 14:37:40 2014
From: jcurran at arin.net (John Curran)
Date: Mon, 3 Feb 2014 19:37:40 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-5: Remove 7.2
	Lame	Delegations
In-Reply-To: <52EFBC11.5050404@quark.net>
References: <52E91DCC.1070206@arin.net>
	<CAP-guGXtXJ=wCi1PO2gxDapeCX1srLEm-L6=UYpk=fb_5S_SmQ@mail.gmail.com>
	<52EFBC11.5050404@quark.net>
Message-ID: <D56F3A23-02D2-40E3-8D43-B9AC2F583550@arin.net>

On Feb 3, 2014, at 7:56 AM, Andrew Dul <andrew.dul at quark.net> wrote:

> It would be helpful for this discussion if ARIN staff could produce a
> brief statement on the current state of how this section has been
> implemented within ARIN's operational procedures.  I assume some of this
> will come later with the staff assessment, but a limited response might
> be helpful for the community to understand how this change would effect
> ARIN's current operational procedures.

Acknowledged - We will do so for community review asap.

Thanks!
/John

John Curran
President and CEO
ARIN




From andrew.dul at quark.net  Wed Feb  5 18:36:36 2014
From: andrew.dul at quark.net (Andrew Dul)
Date: Wed, 05 Feb 2014 15:36:36 -0800
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
 Allocation Conservation Update
In-Reply-To: <52E91DF0.9040909@arin.net>
References: <52E91DF0.9040909@arin.net>
Message-ID: <52F2CB04.20905@quark.net>

Hello,

This draft policy will be discussed next week at the nanog PPC, in
addition we welcome feedback on this draft on PPML.  Specifically if you
could comment on the following two points it would be appreciated.

Thanks,
Andrew


Does the community support raising the minimum requirement for IXPs from
2 to 3?


Does the community believe that additional clarity is needed to define
if an IXP uses the end-user or ISP fee schedule?



On 1/29/2014 7:27 AM, ARIN wrote:
>
>
>
> ## * ##
>
>
> Draft Policy ARIN-2014-7
> Section 4.4 Micro Allocation Conservation Update
>
> Date: 29 January 2014
>
> Problem Statement:
>
> Two networks interconnecting are private peers. Three could be
> considered an IXP. In light of exhaustion and the low reserve
> available to CI _and_ the significant growth of IXP's in North
> America, it is prudent to insure that there are minimum criteria that
> are sensible in order to not waste address space on an activity that
> is delineated by a minimum allocation vs. a /30. The barrier to entry
> remains low regardless.
>
> Policy statement:
>
> Change the following paragraph in Section 4.4 from:
>
> Exchange point operators must provide justification for the
> allocation, including: connection policy, location, other participants
> (minimum of two total), ASN, and contact information. ISPs and other
> organizations receiving these micro-allocations will be charged under
> the ISP fee schedule, while end-users will be charged under the fee
> schedule for end-users. This policy does not preclude exchange point
> operators from requesting address space under other policies.
>
> To:
>
> Exchange point operators must provide justification for the
> allocation, including: connection policy, location, other participants
> (minimum of three total), ASN, and contact information. IXP's formed
> as non profits will be considered end user organizations. All others
> will be considered ISPs.
>
> Comments:
> a.Timetable for implementation:
> b.Anything else:
> _______________________________________________
> 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/20140205/229cc2c7/attachment.htm>

From mueller at syr.edu  Thu Feb  6 09:41:38 2014
From: mueller at syr.edu (Milton L Mueller)
Date: Thu, 6 Feb 2014 14:41:38 +0000
Subject: [arin-ppml] support for 2014-1 (out of region use)
Message-ID: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>

Draft policy 2014-1 attempts to solve a problem left over from last year. During 2013 there was a round of policy proposals attempting to tie ARIN allocations more closely to usage in the region. They failed to gain consensus because they would have interfered with trans-regional networks in undesirable ways. Yet, current policy is still ambiguous on the issue of out of region use of ARIN registered resources. This proposal attempts to clear up that ambiguity in a way that avoids harmful effects on transnational or trans-regional network operators. The gist of the idea is to allow out of region use for organizations eligible for ARIN resources, but also provide policy authorization for ARIN to charge fees to verify the identity or usage of applicants outside the region. I think this approach provides the most flexibility while addressing the only real problems that have been cited for out of region use (verification issues).

You can see the proposal in full here: https://www.arin.net/policy/proposals/2014_1.html
Appreciate reading your comments about this.


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


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

From farmer at umn.edu  Thu Feb  6 11:36:03 2014
From: farmer at umn.edu (David Farmer)
Date: Thu, 06 Feb 2014 10:36:03 -0600
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
 Allocation Conservation Update
In-Reply-To: <52F2CB04.20905@quark.net>
References: <52E91DF0.9040909@arin.net> <52F2CB04.20905@quark.net>
Message-ID: <52F3B9F3.5040706@umn.edu>

On 2/5/14, 17:36 , Andrew Dul wrote:
> Hello,
>
> This draft policy will be discussed next week at the nanog PPC, in
> addition we welcome feedback on this draft on PPML.  Specifically if you
> could comment on the following two points it would be appreciated.
>
> Thanks,
> Andrew
>
>
> Does the community support raising the minimum requirement for IXPs from
> 2 to 3?

I support the change from a two participants to a three participant 
standard to qualify as an Internet Exchange Point (IXP).

To date the risk created by allowing the minimum of two participates for 
an IXP has been extremely low, as the motivation for abuse was also 
extremely low.  However, as we proceed through run-out of the general 
IPv4 free pool the motivations for abuse will increase dramatically. 
Raising the standard to three participants to qualify as an IXP seems 
like a prudent precaution to ensure that the reservation for IXPs, and 
other critical infrastructure that was made in ARIN-2011-4, is protected 
to ensure availability of resources for legitimate IXPs in the future.

There will be some impact on the start-up of some IXPs, this is 
unfortunate.  However, the three participant standard is not completely 
unreasonable, given the potential for increased abuse of the two 
participant standard.

> Does the community believe that additional clarity is needed to define
> if an IXP uses the end-user or ISP fee schedule?

I believe both the old language and the new language regarding this 
issue should be stricken, this is an ARIN business issue, not a policy 
issue.  I have no problem with such a recommendation being included in 
the comments section, outside the policy text itself.  I support the 
general concept it represents, but it is just not a policy issue in my 
opinion.

Thanks.

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


From SRyerse at eclipse-networks.com  Thu Feb  6 11:58:28 2014
From: SRyerse at eclipse-networks.com (Steven Ryerse)
Date: Thu, 6 Feb 2014 16:58:28 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4
 MicroAllocation Conservation Update
In-Reply-To: <52F3B9F3.5040706@umn.edu>
References: <52E91DF0.9040909@arin.net>
	<52F2CB04.20905@quark.net>,<52F3B9F3.5040706@umn.edu>
Message-ID: <2747433E-ABC1-4E07-98BC-CEB067A60300@eclipse-networks.com>

It appears to me that this has been working fine with 2 so I see no need to increase the requirement to 3. 
-1

Sent from my iPhone

> On Feb 6, 2014, at 11:36 AM, "David Farmer" <farmer at umn.edu> wrote:
> 
>> On 2/5/14, 17:36 , Andrew Dul wrote:
>> Hello,
>> 
>> This draft policy will be discussed next week at the nanog PPC, in
>> addition we welcome feedback on this draft on PPML.  Specifically if you
>> could comment on the following two points it would be appreciated.
>> 
>> Thanks,
>> Andrew
>> 
>> 
>> Does the community support raising the minimum requirement for IXPs from
>> 2 to 3?
> 
> I support the change from a two participants to a three participant standard to qualify as an Internet Exchange Point (IXP).
> 
> To date the risk created by allowing the minimum of two participates for an IXP has been extremely low, as the motivation for abuse was also extremely low.  However, as we proceed through run-out of the general IPv4 free pool the motivations for abuse will increase dramatically. Raising the standard to three participants to qualify as an IXP seems like a prudent precaution to ensure that the reservation for IXPs, and other critical infrastructure that was made in ARIN-2011-4, is protected to ensure availability of resources for legitimate IXPs in the future.
> 
> There will be some impact on the start-up of some IXPs, this is unfortunate.  However, the three participant standard is not completely unreasonable, given the potential for increased abuse of the two participant standard.
> 
>> Does the community believe that additional clarity is needed to define
>> if an IXP uses the end-user or ISP fee schedule?
> 
> I believe both the old language and the new language regarding this issue should be stricken, this is an ARIN business issue, not a policy issue.  I have no problem with such a recommendation being included in the comments section, outside the policy text itself.  I support the general concept it represents, but it is just not a policy issue in my opinion.
> 
> Thanks.
> 
> -- 
> ================================================
> David Farmer               Email: farmer at umn.edu
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE     Phone: 1-612-626-0815
> Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
> ================================================
> _______________________________________________
> 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 gary.buhrmaster at gmail.com  Thu Feb  6 12:02:54 2014
From: gary.buhrmaster at gmail.com (Gary Buhrmaster)
Date: Thu, 6 Feb 2014 17:02:54 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
 Allocation Conservation Update
In-Reply-To: <52F3B9F3.5040706@umn.edu>
References: <52E91DF0.9040909@arin.net> <52F2CB04.20905@quark.net>
	<52F3B9F3.5040706@umn.edu>
Message-ID: <CAMfXtQw7evPhGROJYCpYg+4NYRTzdWROhthKmh3TDgzggsU3CQ@mail.gmail.com>

On Thu, Feb 6, 2014 at 4:36 PM, David Farmer <farmer at umn.edu> wrote:
> On 2/5/14, 17:36 , Andrew Dul wrote:
....
>> Does the community support raising the minimum requirement for IXPs from
>> 2 to 3?
>
>
> I support the change from a two participants to a three participant standard
> to qualify as an Internet Exchange Point (IXP).

I agree with David's conclusion and reasoning.

....
>> Does the community believe that additional clarity is needed to define
>> if an IXP uses the end-user or ISP fee schedule?
>
>
> I believe both the old language and the new language regarding this issue
> should be stricken, this is an ARIN business issue, not a policy issue.  I
> have no problem with such a recommendation being included in the comments
> section, outside the policy text itself.  I support the general concept it
> represents, but it is just not a policy issue in my opinion.

I agree with David's conclusion and reasoning.


To follow up on this point a bit, I certainly understand the desire
of non-profit organizations to reduce their overhead costs, and
the reality of ISP fees being a barrier to entry for smaller orgs.
However, if the greater ARIN community believes non-profits
deserve a break in pricing, there should be an entirely new
category created for non-profits, meaning there would be
end-users, ISPs, and now non-profits.  That would allow there to
be a different set of rates created for this new category should
the membership agree.  Deciding exactly how one qualifies
(IRS qualification in the US?), and how big such organizations
can be (before they no longer qualified for the category) would
be an interesting discussion.


From springer at inlandnet.com  Thu Feb  6 12:26:35 2014
From: springer at inlandnet.com (John Springer)
Date: Thu, 6 Feb 2014 09:26:35 -0800 (PST)
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
 Allocation Conservation Update
In-Reply-To: <52F3B9F3.5040706@umn.edu>
References: <52E91DF0.9040909@arin.net> <52F2CB04.20905@quark.net>
	<52F3B9F3.5040706@umn.edu>
Message-ID: <alpine.BSF.2.00.1402060904340.72878@mail.inlandnet.com>

Comments inline.

On Thu, 6 Feb 2014, David Farmer wrote:

> On 2/5/14, 17:36 , Andrew Dul wrote:
>> Hello,
>> 
>> This draft policy will be discussed next week at the nanog PPC, in
>> addition we welcome feedback on this draft on PPML.  Specifically if you
>> could comment on the following two points it would be appreciated.
>> 
>> Thanks,
>> Andrew
>> 
>> 
>> Does the community support raising the minimum requirement for IXPs from
>> 2 to 3?
>
> I support the change from a two participants to a three participant standard 
> to qualify as an Internet Exchange Point (IXP).
>
> To date the risk created by allowing the minimum of two participates for an 
> IXP has been extremely low, as the motivation for abuse was also extremely 
> low.  However, as we proceed through run-out of the general IPv4 free pool 
> the motivations for abuse will increase dramatically. Raising the standard to 
> three participants to qualify as an IXP seems like a prudent precaution to 
> ensure that the reservation for IXPs, and other critical infrastructure that 
> was made in ARIN-2011-4, is protected to ensure availability of resources for 
> legitimate IXPs in the future.
>
> There will be some impact on the start-up of some IXPs, this is unfortunate. 
> However, the three participant standard is not completely unreasonable, given 
> the potential for increased abuse of the two participant standard.

The Open-IX community has had some discussions of this very subject. 
Perhaps the author or other members of the Open-IX Board can summarize on 
this specific matter. I believe the Open-IX community has settled on 3 as 
the way forward. I am OK with that.

>> Does the community believe that additional clarity is needed to define
>> if an IXP uses the end-user or ISP fee schedule?
>
> I believe both the old language and the new language regarding this issue 
> should be stricken, this is an ARIN business issue, not a policy issue.  I 
> have no problem with such a recommendation being included in the comments 
> section, outside the policy text itself.  I support the general concept it 
> represents, but it is just not a policy issue in my opinion.

many pluses to the paragraph immediately preceeding. I feel that this is a 
direct modification of the fee structure via policy, and therefore do not 
support the draft policy as written.

John Springer


> Thanks.
>
> -- 
> ================================================
> David Farmer               Email: farmer at umn.edu
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE     Phone: 1-612-626-0815
> Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
> ================================================
> _______________________________________________
> 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 David.Huberman at microsoft.com  Thu Feb  6 13:40:55 2014
From: David.Huberman at microsoft.com (David Huberman)
Date: Thu, 6 Feb 2014 18:40:55 +0000
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>
Message-ID: <0a573e7e5ec24a34bba99c20501e6e5f@DM2PR03MB398.namprd03.prod.outlook.com>

Thank you, Milton, for bringing this thread up.

I've reviewed 2014-1 and thought about it carefully.  I am against this proposal.  I'll try and organize my thoughts, though they come from a few different angles.

Text: https://www.arin.net/policy/proposals/2014_1.html

1) I'm against the specific 2014-1 language because I think it is almost entirely no-op.  

In general, I want NRPM to be brief, concise, and prescriptive.  "You qualify by doing X.  You don't qualify because of Y. You must show A, B, C."  We need less fluffy text in NRPM so that it is a more accessible and polished Policy document, imho.  In this case, only paragraph X.1 is operational.  It formally lays out just a few steps that ARIN already has available to it.  But these aren't the only tools ARIN has to verify request data, and I'm not convinced that having these specific bullet points in Policy helps the community or ARIN staff in any meaningful way.

Put more straight forwardly:  ARIN staff already have these mechanisms available to them, and this policy text will not change the request process materially.

2) The PPML community has reviewed similar proposals twice, in my recollection.   There was a draft limiting out-of-region use discussed in Philadelphia. The community vocally was against it, and clearly told ARIN staff to keep doing what they were already doing. There was also a draft limiting out-of-region use discussed in Phoenix.  The community was again vocally against it, and clearly told the ARIN staff that this isn't a policy area they wish to discuss.

3) At the same time, the staff are continuing to report that there are significant problems from out-of-region requestors abusing the policies.  If you disagree with the PPML community (and I do - I think this is a serious issue that cries for Policy changes), then we need to draft text that significantly and materially helps ARIN staff fight fraud from out-of-region requestors.  

With regards,
David

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Milton L Mueller
Sent: Thursday, February 6, 2014 6:42 AM
To: ARIN PPML (ppml at arin.net)
Subject: [arin-ppml] support for 2014-1 (out of region use)

Draft policy 2014-1 attempts to solve a problem left over from last year. During 2013 there was a round of policy proposals attempting to tie ARIN allocations more closely to usage in the region. They failed to gain consensus because they would have interfered with trans-regional networks in undesirable ways. Yet, current policy is still ambiguous on the issue of out of region use of ARIN registered resources. This proposal attempts to clear up that ambiguity in a way that avoids harmful effects on transnational or trans-regional network operators. The gist of the idea is to allow out of region use for organizations eligible for ARIN resources, but also provide policy authorization for ARIN to charge fees to verify the identity or usage of applicants outside the region. I think this approach provides the most flexibility while addressing the only real problems that have been cited for out of region use (verification issues). 

You can see the proposal in full here: https://www.arin.net/policy/proposals/2014_1.html
Appreciate reading your comments about this.


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




From springer at inlandnet.com  Thu Feb  6 14:27:59 2014
From: springer at inlandnet.com (John Springer)
Date: Thu, 6 Feb 2014 11:27:59 -0800 (PST)
Subject: [arin-ppml] Draft Policy ARIN-2014-4: REMOVE 4.2.5 WEB HOSTING
 POLICY
In-Reply-To: <52F3B9F3.5040706@umn.edu>
References: <52E91DF0.9040909@arin.net> <52F2CB04.20905@quark.net>
	<52F3B9F3.5040706@umn.edu>
Message-ID: <alpine.BSF.2.00.1402060932140.72878@mail.inlandnet.com>

Greetings PPML readers,

Draft Policy ARIN-2014-4: REMOVE 4.2.5 WEB HOSTING POLICY will be 
discussed next week during the Public Policy Consultation at NANOG 60 in 
Atlanta. This Consultation will take place on Tuesday from 9:30AM to 
13:00PM in the Augusta Room.

Comments are invited and welcome both here and there. The text of 
the Draft Policy is below my comments, which follow.

Comments (and questions) from me:

Firstly, do you support or oppose Draft Policy 2014-4?

This Draft Policy is functionally identical to the last bullet item of 
Draft Policy 2013-7 - NRPM 4 (IPv4) policy cleanup, which also will be 
presented next week. The author of this Draft Policy is aware of this 
overlap and "would like it submitted and considered entirely separately". 
One aspect of this situation is that the precursors of 2013-7 have 
attracted energetic comment. Adoption of 2014-4 separately would decouple 
this issue (2014-4) from the other parts of 2013-7 and its adoption or 
rejection. What do you think?

While the policy text of both proposals is functionally identical ("Remove 
section 4.2.5 Web Hosting Policy" in 2013-7 and "Remove section 4.2.5" in 
2014-4), the problem statements differ. 2013-7 says, "Since ARIN received 
its last /8, by IANA implementing section 10.4.2.2, this is now a 
distinction without a difference." 2014-4 says "Section 4.2.5 is 
technology-specific language that is not current with modern network 
operation needs and practices. We should remove it to make NRPM clearer." 
Both appear to be correct and sufficient. Which do you prefer and why? If 
neither, and you support 2014-4, can you please suggest text? Since both 
are Draft Policy, an opportunity exists for the AC to amend the problem 
statements so the two are congruent.

It has been suggested that this Draft Policy is without operational 
impact, being purely a house cleaning matter. Do you agree? If not, what 
operational relevance do you see?

Thank you for your consideration of this matter.

John Springer

From: ARIN (info at arin.net)
Date: Wed Jan 29 10:26:51 EST 2014

On 24 January 2014 the ARIN Advisory Council (AC) accepted
"ARIN-prop-196 Remove 4.2.5 Web Hosting Policy" as a Draft Policy.

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

You are encouraged to discuss the merits and your concerns of Draft
Policy 2014-4 on the Public Policy Mailing List.

The AC will evaluate the discussion in order to assess the conformance
of this draft policy with ARIN's Principles of Internet Number Resource
Policy as stated in the PDP. Specifically, these principles are:

   * Enabling Fair and Impartial Number Resource Administration
   * Technically Sound
   * Supported by the Community

The ARIN Policy Development Process (PDP) 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,

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


## * ##


Draft Policy ARIN-2014-4
Remove 4.2.5 Web Hosting Policy

Date: 29 January 2014

Problem Statement:

Section 4.2.5 is technology-specific language that is not current with
modern network operation needs and practices. We should remove it to
make NRPM clearer.

Policy statement:

Remove section 4.2.5.

Comments:
a.Timetable for implementation: Immediate
b.Anything else:


From stillwaxin at gmail.com  Thu Feb  6 14:45:12 2014
From: stillwaxin at gmail.com (Michael Still)
Date: Thu, 6 Feb 2014 14:45:12 -0500
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
 Allocation Conservation Update
In-Reply-To: <alpine.BSF.2.00.1402060904340.72878@mail.inlandnet.com>
References: <52E91DF0.9040909@arin.net> <52F2CB04.20905@quark.net>
	<52F3B9F3.5040706@umn.edu>
	<alpine.BSF.2.00.1402060904340.72878@mail.inlandnet.com>
Message-ID: <CAPDTRigg96qkZAVPTM-rnjuoyoXN27qWQzijVUoeAGF+wZSyKQ@mail.gmail.com>

On Thu, Feb 6, 2014 at 12:26 PM, John Springer <springer at inlandnet.com> wrote:
> Comments inline.
>
>
> On Thu, 6 Feb 2014, David Farmer wrote:
>
>> On 2/5/14, 17:36 , Andrew Dul wrote:
>>>
>>> Hello,
>>>
>>> This draft policy will be discussed next week at the nanog PPC, in
>>> addition we welcome feedback on this draft on PPML.  Specifically if you
>>> could comment on the following two points it would be appreciated.
>>>
>>> Thanks,
>>> Andrew
>>>
>>>
>>> Does the community support raising the minimum requirement for IXPs from
>>> 2 to 3?
>>
>>
>> I support the change from a two participants to a three participant
>> standard to qualify as an Internet Exchange Point (IXP).
>>
>> To date the risk created by allowing the minimum of two participates for
>> an IXP has been extremely low, as the motivation for abuse was also
>> extremely low.  However, as we proceed through run-out of the general IPv4
>> free pool the motivations for abuse will increase dramatically. Raising the
>> standard to three participants to qualify as an IXP seems like a prudent
>> precaution to ensure that the reservation for IXPs, and other critical
>> infrastructure that was made in ARIN-2011-4, is protected to ensure
>> availability of resources for legitimate IXPs in the future.
>>
>> There will be some impact on the start-up of some IXPs, this is
>> unfortunate. However, the three participant standard is not completely
>> unreasonable, given the potential for increased abuse of the two participant
>> standard.
>
>
> The Open-IX community has had some discussions of this very subject. Perhaps
> the author or other members of the Open-IX Board can summarize on this
> specific matter. I believe the Open-IX community has settled on 3 as the way
> forward. I am OK with that.
>
>
>>> Does the community believe that additional clarity is needed to define
>>> if an IXP uses the end-user or ISP fee schedule?
>>
>>
>> I believe both the old language and the new language regarding this issue
>> should be stricken, this is an ARIN business issue, not a policy issue.  I
>> have no problem with such a recommendation being included in the comments
>> section, outside the policy text itself.  I support the general concept it
>> represents, but it is just not a policy issue in my opinion.
>
>
> many pluses to the paragraph immediately preceeding. I feel that this is a
> direct modification of the fee structure via policy, and therefore do not
> support the draft policy as written.
>
> John Springer
>

Not really responding to you, you just happened to be the last in the thread..

Perhaps we should look at tackling some of our dwindling number
resources issues in a different perspective.  Have we considered
updating the policy to only issue prefix sizes which are reasonable in
the first place?  What makes just setting up an IXP be enough to issue
a /24?  What if this IXP is in a market in which there will never be
more than 126 participants?  Or worse much less?  Should these IXPs be
given /24s when a much smaller allocation may be all that's needed?
Or should every IXP have to start small and as their participation
increases they be issued new space to move into?

I believe the argument for global prefix visibility of IXP space has
been largely discussed and consensus is that this space does not and
should not be globally reachable voiding any perceived need for a /24
I believe.

>
>
>> Thanks.
>>
>> --
>> ================================================
>> David Farmer               Email: farmer at umn.edu
>> Office of Information Technology
>> University of Minnesota
>> 2218 University Ave SE     Phone: 1-612-626-0815
>> Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
>> ================================================
>> _______________________________________________
>> 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.



-- 
[stillwaxin at gmail.com ~]$ cat .signature
cat: .signature: No such file or directory
[stillwaxin at gmail.com ~]$


From springer at inlandnet.com  Thu Feb  6 15:08:30 2014
From: springer at inlandnet.com (John Springer)
Date: Thu, 6 Feb 2014 12:08:30 -0800 (PST)
Subject: [arin-ppml] Draft Policy ARIN-2014-4: REMOVE 4.2.5 WEB HOSTING
 POLICY
In-Reply-To: <alpine.BSF.2.00.1402060932140.72878@mail.inlandnet.com>
References: <52E91DF0.9040909@arin.net> <52F2CB04.20905@quark.net>
	<52F3B9F3.5040706@umn.edu>
	<alpine.BSF.2.00.1402060932140.72878@mail.inlandnet.com>
Message-ID: <alpine.BSF.2.00.1402061206110.72878@mail.inlandnet.com>

Correction:

On Thu, 6 Feb 2014, John Springer wrote:

> Greetings PPML readers,
>
> Draft Policy ARIN-2014-4: REMOVE 4.2.5 WEB HOSTING POLICY will be discussed 
> next week during the Public Policy Consultation at NANOG 60 in Atlanta. This 
> Consultation will take place on Tuesday from 9:30AM to 13:00PM in the Augusta 
> Room.
>
> Comments are invited and welcome both here and there. The text of the Draft 
> Policy is below my comments, which follow.
>
> Comments (and questions) from me:
>
> Firstly, do you support or oppose Draft Policy 2014-4?
>
> This Draft Policy is functionally identical to the last bullet item of Draft 
> Policy 2013-7 - NRPM 4 (IPv4) policy cleanup, which also will be presented 
> next week. The author of this Draft Policy is aware of this overlap and 
> "would like it submitted and considered entirely separately". One aspect of 
> this situation is that the precursors of 2013-7 have attracted energetic 
> comment. Adoption of 2014-4 separately would decouple this issue (2014-4) 
> from the other parts of 2013-7 and its adoption or rejection. What do you 
> think?
>
> While the policy text of both proposals is functionally identical ("Remove 
> section 4.2.5 Web Hosting Policy" in 2013-7 and "Remove section 4.2.5" in 
> 2014-4), the problem statements differ. 2013-7 says, "Since ARIN received its 
> last /8, by IANA implementing section 10.4.2.2, this is now a distinction 
> without a difference."

The correct problem statement for 2013-7 is "This information-gathering 
policy has been in place for a decade now with no resulting policy 
changes, and is no longer needed in light of IPv4 runout."

> 2014-4 says "Section 4.2.5 is technology-specific 
> language that is not current with modern network operation needs and 
> practices. We should remove it to make NRPM clearer." Both appear to be 
> correct and sufficient. Which do you prefer and why? If neither, and you 
> support 2014-4, can you please suggest text? Since both are Draft Policy, an 
> opportunity exists for the AC to amend the problem statements so the two are 
> congruent.
>
> It has been suggested that this Draft Policy is without operational impact, 
> being purely a house cleaning matter. Do you agree? If not, what operational 
> relevance do you see?
>
> Thank you for your consideration of this matter.
>
> John Springer
>
> From: ARIN (info at arin.net)
> Date: Wed Jan 29 10:26:51 EST 2014
>
> On 24 January 2014 the ARIN Advisory Council (AC) accepted
> "ARIN-prop-196 Remove 4.2.5 Web Hosting Policy" as a Draft Policy.
>
> Draft Policy ARIN-2014-4 is below and can be found at:
> https://www.arin.net/policy/proposals/2014_4.html
>
> You are encouraged to discuss the merits and your concerns of Draft
> Policy 2014-4 on the Public Policy Mailing List.
>
> The AC will evaluate the discussion in order to assess the conformance
> of this draft policy with ARIN's Principles of Internet Number Resource
> Policy as stated in the PDP. Specifically, these principles are:
>
>  * Enabling Fair and Impartial Number Resource Administration
>  * Technically Sound
>  * Supported by the Community
>
> The ARIN Policy Development Process (PDP) 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,
>
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Draft Policy ARIN-2014-4
> Remove 4.2.5 Web Hosting Policy
>
> Date: 29 January 2014
>
> Problem Statement:
>
> Section 4.2.5 is technology-specific language that is not current with
> modern network operation needs and practices. We should remove it to
> make NRPM clearer.
>
> Policy statement:
>
> Remove section 4.2.5.
>
> Comments:
> a.Timetable for implementation: Immediate
> b.Anything else:
> _______________________________________________
> 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 rudi.daniel at gmail.com  Thu Feb  6 15:35:31 2014
From: rudi.daniel at gmail.com (Rudolph Daniel)
Date: Thu, 6 Feb 2014 16:35:31 -0400
Subject: [arin-ppml] ARIN-PPML 2014-7
In-Reply-To: <CA+uaoiUQYUfGRRw7mWR57AHbm5hF3MKgwzZQDKP4ACc0xmcfoA@mail.gmail.com>
References: <CA+uaoiVOKrtby=myXRNBCmxn++c+56a7rmjOxmMmB3RAJW22qQ@mail.gmail.com>
	<CAP-guGXYMHqy-pMmWYR=KhcyhxCizGdyMxzw6CnZ0PKVtP6VJg@mail.gmail.com>
	<CA+uaoiUQYUfGRRw7mWR57AHbm5hF3MKgwzZQDKP4ACc0xmcfoA@mail.gmail.com>
Message-ID: <CA+uaoiU_tUFBShi5TTa8R2wevUjUiwpEKR=r_1=BK1L3o4Vz4Q@mail.gmail.com>

I do not support the change from 2 to 3 for end user ixp s.
See my earlier remarks.
Does ARIN have good evidence of abuse of the current situation?

Rudi Daniel
(information technologist)
784 430 9235
On Feb 6, 2014 1:07 PM, <arin-ppml-request at arin.net> wrote:

> Ok.William...thanks for that...was not too sure.
>
> RD
>
>
> On Fri, Jan 31, 2014 at 1:34 PM, William Herrin <bill at herrin.us> wrote:
>
>> On Fri, Jan 31, 2014 at 8:05 AM, Rudolph Daniel <rudi.daniel at gmail.com>
>> wrote:
>> > In the small Caribbean states, although there seems to be
>> > policy to implement IXP s, many are still not getting the buy
>> > in from existing ISP s ...so it is possible that an IXP could
>> > get off the ground with 2 and once up and running, others
>> > will join in.
>>
>> Hi Rudi,
>>
>> There aren't many use cases in which renumbering is genuinely trivial.
>> Three nodes in a BGP exchange is one of them.
>>
>> Regards,
>> Bill Herrin
>>
>>
>>
>> --
>> William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
>> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
>> Falls Church, VA 22042-3004
>>
>
>
>
> --
>
> Rudi Daniel
>
> *danielcharles consulting
> <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/20140206/5bda9c61/attachment.htm>

From hannigan at gmail.com  Thu Feb  6 15:40:41 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Thu, 6 Feb 2014 15:40:41 -0500
Subject: [arin-ppml] ARIN-PPML 2014-7
In-Reply-To: <CA+uaoiU_tUFBShi5TTa8R2wevUjUiwpEKR=r_1=BK1L3o4Vz4Q@mail.gmail.com>
References: <CA+uaoiVOKrtby=myXRNBCmxn++c+56a7rmjOxmMmB3RAJW22qQ@mail.gmail.com>
	<CAP-guGXYMHqy-pMmWYR=KhcyhxCizGdyMxzw6CnZ0PKVtP6VJg@mail.gmail.com>
	<CA+uaoiUQYUfGRRw7mWR57AHbm5hF3MKgwzZQDKP4ACc0xmcfoA@mail.gmail.com>
	<CA+uaoiU_tUFBShi5TTa8R2wevUjUiwpEKR=r_1=BK1L3o4Vz4Q@mail.gmail.com>
Message-ID: <CAMDXq5O+iqWtdpzSZqMc=At7M=PecVUJNU+-VfsNVj00M=YVmw@mail.gmail.com>

Rudi,

Do you have any evidence of real harm?

Best,

Martin



On Thursday, February 6, 2014, Rudolph Daniel <rudi.daniel at gmail.com> wrote:

> I do not support the change from 2 to 3 for end user ixp s.
> See my earlier remarks.
> Does ARIN have good evidence of abuse of the current situation?
>
> Rudi Daniel
> (information technologist)
> 784 430 9235
> On Feb 6, 2014 1:07 PM, <arin-ppml-request at arin.net<javascript:_e(%7B%7D,'cvml','arin-ppml-request at arin.net');>>
> wrote:
>
>> Ok.William...thanks for that...was not too sure.
>>
>> RD
>>
>>
>> On Fri, Jan 31, 2014 at 1:34 PM, William Herrin <bill at herrin.us<javascript:_e(%7B%7D,'cvml','bill at herrin.us');>
>> > wrote:
>>
>>> On Fri, Jan 31, 2014 at 8:05 AM, Rudolph Daniel <rudi.daniel at gmail.com<javascript:_e(%7B%7D,'cvml','rudi.daniel at gmail.com');>>
>>> wrote:
>>> > In the small Caribbean states, although there seems to be
>>> > policy to implement IXP s, many are still not getting the buy
>>> > in from existing ISP s ...so it is possible that an IXP could
>>> > get off the ground with 2 and once up and running, others
>>> > will join in.
>>>
>>> Hi Rudi,
>>>
>>> There aren't many use cases in which renumbering is genuinely trivial.
>>> Three nodes in a BGP exchange is one of them.
>>>
>>> Regards,
>>> Bill Herrin
>>>
>>>
>>>
>>> --
>>> William D. Herrin ................ herrin at dirtside.com<javascript:_e(%7B%7D,'cvml','herrin at dirtside.com');>
>>> bill at herrin.us <javascript:_e(%7B%7D,'cvml','bill at herrin.us');>
>>> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
>>> Falls Church, VA 22042-3004
>>>
>>
>>
>>
>> --
>>
>> Rudi Daniel
>>
>> *danielcharles consulting
>> <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/20140206/58512337/attachment.htm>

From rudi.daniel at gmail.com  Thu Feb  6 15:41:00 2014
From: rudi.daniel at gmail.com (Rudolph Daniel)
Date: Thu, 6 Feb 2014 16:41:00 -0400
Subject: [arin-ppml] ARIN-2014-4
Message-ID: <CA+uaoiX54NSv11FWwGnZnyZHv251EPYLSyAdVZk4OWcVmVzWhg@mail.gmail.com>

I am in support of draft 2014-4.

Rudi Daniel
(information technologist)
784 430 9235
On Feb 6, 2014 4:11 PM, <arin-ppml-request at arin.net> wrote:

> Send ARIN-PPML mailing list submissions to
>         arin-ppml at arin.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://lists.arin.net/mailman/listinfo/arin-ppml
> or, via email, send a message with subject or body 'help' to
>         arin-ppml-request at arin.net
>
> You can reach the person managing the list at
>         arin-ppml-owner at arin.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ARIN-PPML digest..."
>
>
> Today's Topics:
>
>    1. Re: Draft Policy ARIN-2014-7: Section 4.4 Micro Allocation
>       Conservation Update (John Springer)
>    2. Re: support for 2014-1 (out of region use) (David Huberman)
>    3. Re: Draft Policy ARIN-2014-4: REMOVE 4.2.5 WEB HOSTING POLICY
>       (John Springer)
>    4. Re: Draft Policy ARIN-2014-7: Section 4.4 Micro Allocation
>       Conservation Update (Michael Still)
>    5. Re: Draft Policy ARIN-2014-4: REMOVE 4.2.5 WEB HOSTING POLICY
>       (John Springer)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 6 Feb 2014 09:26:35 -0800 (PST)
> From: John Springer <springer at inlandnet.com>
> To: David Farmer <farmer at umn.edu>
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
>         Allocation Conservation Update
> Message-ID: <alpine.BSF.2.00.1402060904340.72878 at mail.inlandnet.com>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
> Comments inline.
>
> On Thu, 6 Feb 2014, David Farmer wrote:
>
> > On 2/5/14, 17:36 , Andrew Dul wrote:
> >> Hello,
> >>
> >> This draft policy will be discussed next week at the nanog PPC, in
> >> addition we welcome feedback on this draft on PPML.  Specifically if you
> >> could comment on the following two points it would be appreciated.
> >>
> >> Thanks,
> >> Andrew
> >>
> >>
> >> Does the community support raising the minimum requirement for IXPs from
> >> 2 to 3?
> >
> > I support the change from a two participants to a three participant
> standard
> > to qualify as an Internet Exchange Point (IXP).
> >
> > To date the risk created by allowing the minimum of two participates for
> an
> > IXP has been extremely low, as the motivation for abuse was also
> extremely
> > low.  However, as we proceed through run-out of the general IPv4 free
> pool
> > the motivations for abuse will increase dramatically. Raising the
> standard to
> > three participants to qualify as an IXP seems like a prudent precaution
> to
> > ensure that the reservation for IXPs, and other critical infrastructure
> that
> > was made in ARIN-2011-4, is protected to ensure availability of
> resources for
> > legitimate IXPs in the future.
> >
> > There will be some impact on the start-up of some IXPs, this is
> unfortunate.
> > However, the three participant standard is not completely unreasonable,
> given
> > the potential for increased abuse of the two participant standard.
>
> The Open-IX community has had some discussions of this very subject.
> Perhaps the author or other members of the Open-IX Board can summarize on
> this specific matter. I believe the Open-IX community has settled on 3 as
> the way forward. I am OK with that.
>
> >> Does the community believe that additional clarity is needed to define
> >> if an IXP uses the end-user or ISP fee schedule?
> >
> > I believe both the old language and the new language regarding this issue
> > should be stricken, this is an ARIN business issue, not a policy issue.
>  I
> > have no problem with such a recommendation being included in the comments
> > section, outside the policy text itself.  I support the general concept
> it
> > represents, but it is just not a policy issue in my opinion.
>
> many pluses to the paragraph immediately preceeding. I feel that this is a
> direct modification of the fee structure via policy, and therefore do not
> support the draft policy as written.
>
> John Springer
>
>
> > Thanks.
> >
> > --
> > ================================================
> > David Farmer               Email: farmer at umn.edu
> > Office of Information Technology
> > University of Minnesota
> > 2218 University Ave SE     Phone: 1-612-626-0815
> > Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
> > ================================================
> > _______________________________________________
> > 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.
> >
> >
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 6 Feb 2014 18:40:55 +0000
> From: David Huberman <David.Huberman at microsoft.com>
> To: "ARIN PPML (ppml at arin.net)" <ppml at arin.net>
> Subject: Re: [arin-ppml] support for 2014-1 (out of region use)
> Message-ID:
>         <
> 0a573e7e5ec24a34bba99c20501e6e5f at DM2PR03MB398.namprd03.prod.outlook.com>
>
> Content-Type: text/plain; charset="us-ascii"
>
> Thank you, Milton, for bringing this thread up.
>
> I've reviewed 2014-1 and thought about it carefully.  I am against this
> proposal.  I'll try and organize my thoughts, though they come from a few
> different angles.
>
> Text: https://www.arin.net/policy/proposals/2014_1.html
>
> 1) I'm against the specific 2014-1 language because I think it is almost
> entirely no-op.
>
> In general, I want NRPM to be brief, concise, and prescriptive.  "You
> qualify by doing X.  You don't qualify because of Y. You must show A, B,
> C."  We need less fluffy text in NRPM so that it is a more accessible and
> polished Policy document, imho.  In this case, only paragraph X.1 is
> operational.  It formally lays out just a few steps that ARIN already has
> available to it.  But these aren't the only tools ARIN has to verify
> request data, and I'm not convinced that having these specific bullet
> points in Policy helps the community or ARIN staff in any meaningful way.
>
> Put more straight forwardly:  ARIN staff already have these mechanisms
> available to them, and this policy text will not change the request process
> materially.
>
> 2) The PPML community has reviewed similar proposals twice, in my
> recollection.   There was a draft limiting out-of-region use discussed in
> Philadelphia. The community vocally was against it, and clearly told ARIN
> staff to keep doing what they were already doing. There was also a draft
> limiting out-of-region use discussed in Phoenix.  The community was again
> vocally against it, and clearly told the ARIN staff that this isn't a
> policy area they wish to discuss.
>
> 3) At the same time, the staff are continuing to report that there are
> significant problems from out-of-region requestors abusing the policies.
>  If you disagree with the PPML community (and I do - I think this is a
> serious issue that cries for Policy changes), then we need to draft text
> that significantly and materially helps ARIN staff fight fraud from
> out-of-region requestors.
>
> With regards,
> David
>
> David R Huberman
> Microsoft Corporation
> Senior IT/OPS Program Manager (GFS)
>
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Milton L Mueller
> Sent: Thursday, February 6, 2014 6:42 AM
> To: ARIN PPML (ppml at arin.net)
> Subject: [arin-ppml] support for 2014-1 (out of region use)
>
> Draft policy 2014-1 attempts to solve a problem left over from last year.
> During 2013 there was a round of policy proposals attempting to tie ARIN
> allocations more closely to usage in the region. They failed to gain
> consensus because they would have interfered with trans-regional networks
> in undesirable ways. Yet, current policy is still ambiguous on the issue of
> out of region use of ARIN registered resources. This proposal attempts to
> clear up that ambiguity in a way that avoids harmful effects on
> transnational or trans-regional network operators. The gist of the idea is
> to allow out of region use for organizations eligible for ARIN resources,
> but also provide policy authorization for ARIN to charge fees to verify the
> identity or usage of applicants outside the region. I think this approach
> provides the most flexibility while addressing the only real problems that
> have been cited for out of region use (verification issues).
>
> You can see the proposal in full here:
> https://www.arin.net/policy/proposals/2014_1.html
> Appreciate reading your comments about this.
>
>
> Milton L Mueller
> Professor, Syracuse University School of Information Studies
> Internet Governance Project
> http://internetgovernance.org
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 6 Feb 2014 11:27:59 -0800 (PST)
> From: John Springer <springer at inlandnet.com>
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-4: REMOVE 4.2.5 WEB
>         HOSTING POLICY
> Message-ID: <alpine.BSF.2.00.1402060932140.72878 at mail.inlandnet.com>
> Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
>
> Greetings PPML readers,
>
> Draft Policy ARIN-2014-4: REMOVE 4.2.5 WEB HOSTING POLICY will be
> discussed next week during the Public Policy Consultation at NANOG 60 in
> Atlanta. This Consultation will take place on Tuesday from 9:30AM to
> 13:00PM in the Augusta Room.
>
> Comments are invited and welcome both here and there. The text of
> the Draft Policy is below my comments, which follow.
>
> Comments (and questions) from me:
>
> Firstly, do you support or oppose Draft Policy 2014-4?
>
> This Draft Policy is functionally identical to the last bullet item of
> Draft Policy 2013-7 - NRPM 4 (IPv4) policy cleanup, which also will be
> presented next week. The author of this Draft Policy is aware of this
> overlap and "would like it submitted and considered entirely separately".
> One aspect of this situation is that the precursors of 2013-7 have
> attracted energetic comment. Adoption of 2014-4 separately would decouple
> this issue (2014-4) from the other parts of 2013-7 and its adoption or
> rejection. What do you think?
>
> While the policy text of both proposals is functionally identical ("Remove
> section 4.2.5 Web Hosting Policy" in 2013-7 and "Remove section 4.2.5" in
> 2014-4), the problem statements differ. 2013-7 says, "Since ARIN received
> its last /8, by IANA implementing section 10.4.2.2, this is now a
> distinction without a difference." 2014-4 says "Section 4.2.5 is
> technology-specific language that is not current with modern network
> operation needs and practices. We should remove it to make NRPM clearer."
> Both appear to be correct and sufficient. Which do you prefer and why? If
> neither, and you support 2014-4, can you please suggest text? Since both
> are Draft Policy, an opportunity exists for the AC to amend the problem
> statements so the two are congruent.
>
> It has been suggested that this Draft Policy is without operational
> impact, being purely a house cleaning matter. Do you agree? If not, what
> operational relevance do you see?
>
> Thank you for your consideration of this matter.
>
> John Springer
>
> From: ARIN (info at arin.net)
> Date: Wed Jan 29 10:26:51 EST 2014
>
> On 24 January 2014 the ARIN Advisory Council (AC) accepted
> "ARIN-prop-196 Remove 4.2.5 Web Hosting Policy" as a Draft Policy.
>
> Draft Policy ARIN-2014-4 is below and can be found at:
> https://www.arin.net/policy/proposals/2014_4.html
>
> You are encouraged to discuss the merits and your concerns of Draft
> Policy 2014-4 on the Public Policy Mailing List.
>
> The AC will evaluate the discussion in order to assess the conformance
> of this draft policy with ARIN's Principles of Internet Number Resource
> Policy as stated in the PDP. Specifically, these principles are:
>
>    * Enabling Fair and Impartial Number Resource Administration
>    * Technically Sound
>    * Supported by the Community
>
> The ARIN Policy Development Process (PDP) 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,
>
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Draft Policy ARIN-2014-4
> Remove 4.2.5 Web Hosting Policy
>
> Date: 29 January 2014
>
> Problem Statement:
>
> Section 4.2.5 is technology-specific language that is not current with
> modern network operation needs and practices. We should remove it to
> make NRPM clearer.
>
> Policy statement:
>
> Remove section 4.2.5.
>
> Comments:
> a.Timetable for implementation: Immediate
> b.Anything else:
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 6 Feb 2014 14:45:12 -0500
> From: Michael Still <stillwaxin at gmail.com>
> To: John Springer <springer at inlandnet.com>
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
>         Allocation Conservation Update
> Message-ID:
>         <
> CAPDTRigg96qkZAVPTM-rnjuoyoXN27qWQzijVUoeAGF+wZSyKQ at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Thu, Feb 6, 2014 at 12:26 PM, John Springer <springer at inlandnet.com>
> wrote:
> > Comments inline.
> >
> >
> > On Thu, 6 Feb 2014, David Farmer wrote:
> >
> >> On 2/5/14, 17:36 , Andrew Dul wrote:
> >>>
> >>> Hello,
> >>>
> >>> This draft policy will be discussed next week at the nanog PPC, in
> >>> addition we welcome feedback on this draft on PPML.  Specifically if
> you
> >>> could comment on the following two points it would be appreciated.
> >>>
> >>> Thanks,
> >>> Andrew
> >>>
> >>>
> >>> Does the community support raising the minimum requirement for IXPs
> from
> >>> 2 to 3?
> >>
> >>
> >> I support the change from a two participants to a three participant
> >> standard to qualify as an Internet Exchange Point (IXP).
> >>
> >> To date the risk created by allowing the minimum of two participates for
> >> an IXP has been extremely low, as the motivation for abuse was also
> >> extremely low.  However, as we proceed through run-out of the general
> IPv4
> >> free pool the motivations for abuse will increase dramatically. Raising
> the
> >> standard to three participants to qualify as an IXP seems like a prudent
> >> precaution to ensure that the reservation for IXPs, and other critical
> >> infrastructure that was made in ARIN-2011-4, is protected to ensure
> >> availability of resources for legitimate IXPs in the future.
> >>
> >> There will be some impact on the start-up of some IXPs, this is
> >> unfortunate. However, the three participant standard is not completely
> >> unreasonable, given the potential for increased abuse of the two
> participant
> >> standard.
> >
> >
> > The Open-IX community has had some discussions of this very subject.
> Perhaps
> > the author or other members of the Open-IX Board can summarize on this
> > specific matter. I believe the Open-IX community has settled on 3 as the
> way
> > forward. I am OK with that.
> >
> >
> >>> Does the community believe that additional clarity is needed to define
> >>> if an IXP uses the end-user or ISP fee schedule?
> >>
> >>
> >> I believe both the old language and the new language regarding this
> issue
> >> should be stricken, this is an ARIN business issue, not a policy issue.
>  I
> >> have no problem with such a recommendation being included in the
> comments
> >> section, outside the policy text itself.  I support the general concept
> it
> >> represents, but it is just not a policy issue in my opinion.
> >
> >
> > many pluses to the paragraph immediately preceeding. I feel that this is
> a
> > direct modification of the fee structure via policy, and therefore do not
> > support the draft policy as written.
> >
> > John Springer
> >
>
> Not really responding to you, you just happened to be the last in the
> thread..
>
> Perhaps we should look at tackling some of our dwindling number
> resources issues in a different perspective.  Have we considered
> updating the policy to only issue prefix sizes which are reasonable in
> the first place?  What makes just setting up an IXP be enough to issue
> a /24?  What if this IXP is in a market in which there will never be
> more than 126 participants?  Or worse much less?  Should these IXPs be
> given /24s when a much smaller allocation may be all that's needed?
> Or should every IXP have to start small and as their participation
> increases they be issued new space to move into?
>
> I believe the argument for global prefix visibility of IXP space has
> been largely discussed and consensus is that this space does not and
> should not be globally reachable voiding any perceived need for a /24
> I believe.
>
> >
> >
> >> Thanks.
> >>
> >> --
> >> ================================================
> >> David Farmer               Email: farmer at umn.edu
> >> Office of Information Technology
> >> University of Minnesota
> >> 2218 University Ave SE     Phone: 1-612-626-0815
> >> Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
> >> ================================================
> >> _______________________________________________
> >> 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.
>
>
>
> --
> [stillwaxin at gmail.com ~]$ cat .signature
> cat: .signature: No such file or directory
> [stillwaxin at gmail.com ~]$
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 6 Feb 2014 12:08:30 -0800 (PST)
> From: John Springer <springer at inlandnet.com>
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-4: REMOVE 4.2.5 WEB
>         HOSTING POLICY
> Message-ID: <alpine.BSF.2.00.1402061206110.72878 at mail.inlandnet.com>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
> Correction:
>
> On Thu, 6 Feb 2014, John Springer wrote:
>
> > Greetings PPML readers,
> >
> > Draft Policy ARIN-2014-4: REMOVE 4.2.5 WEB HOSTING POLICY will be
> discussed
> > next week during the Public Policy Consultation at NANOG 60 in Atlanta.
> This
> > Consultation will take place on Tuesday from 9:30AM to 13:00PM in the
> Augusta
> > Room.
> >
> > Comments are invited and welcome both here and there. The text of the
> Draft
> > Policy is below my comments, which follow.
> >
> > Comments (and questions) from me:
> >
> > Firstly, do you support or oppose Draft Policy 2014-4?
> >
> > This Draft Policy is functionally identical to the last bullet item of
> Draft
> > Policy 2013-7 - NRPM 4 (IPv4) policy cleanup, which also will be
> presented
> > next week. The author of this Draft Policy is aware of this overlap and
> > "would like it submitted and considered entirely separately". One aspect
> of
> > this situation is that the precursors of 2013-7 have attracted energetic
> > comment. Adoption of 2014-4 separately would decouple this issue (2014-4)
> > from the other parts of 2013-7 and its adoption or rejection. What do you
> > think?
> >
> > While the policy text of both proposals is functionally identical
> ("Remove
> > section 4.2.5 Web Hosting Policy" in 2013-7 and "Remove section 4.2.5" in
> > 2014-4), the problem statements differ. 2013-7 says, "Since ARIN
> received its
> > last /8, by IANA implementing section 10.4.2.2, this is now a distinction
> > without a difference."
>
> The correct problem statement for 2013-7 is "This information-gathering
> policy has been in place for a decade now with no resulting policy
> changes, and is no longer needed in light of IPv4 runout."
>
> > 2014-4 says "Section 4.2.5 is technology-specific
> > language that is not current with modern network operation needs and
> > practices. We should remove it to make NRPM clearer." Both appear to be
> > correct and sufficient. Which do you prefer and why? If neither, and you
> > support 2014-4, can you please suggest text? Since both are Draft
> Policy, an
> > opportunity exists for the AC to amend the problem statements so the two
> are
> > congruent.
> >
> > It has been suggested that this Draft Policy is without operational
> impact,
> > being purely a house cleaning matter. Do you agree? If not, what
> operational
> > relevance do you see?
> >
> > Thank you for your consideration of this matter.
> >
> > John Springer
> >
> > From: ARIN (info at arin.net)
> > Date: Wed Jan 29 10:26:51 EST 2014
> >
> > On 24 January 2014 the ARIN Advisory Council (AC) accepted
> > "ARIN-prop-196 Remove 4.2.5 Web Hosting Policy" as a Draft Policy.
> >
> > Draft Policy ARIN-2014-4 is below and can be found at:
> > https://www.arin.net/policy/proposals/2014_4.html
> >
> > You are encouraged to discuss the merits and your concerns of Draft
> > Policy 2014-4 on the Public Policy Mailing List.
> >
> > The AC will evaluate the discussion in order to assess the conformance
> > of this draft policy with ARIN's Principles of Internet Number Resource
> > Policy as stated in the PDP. Specifically, these principles are:
> >
> >  * Enabling Fair and Impartial Number Resource Administration
> >  * Technically Sound
> >  * Supported by the Community
> >
> > The ARIN Policy Development Process (PDP) 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,
> >
> > Communications and Member Services
> > American Registry for Internet Numbers (ARIN)
> >
> >
> > ## * ##
> >
> >
> > Draft Policy ARIN-2014-4
> > Remove 4.2.5 Web Hosting Policy
> >
> > Date: 29 January 2014
> >
> > Problem Statement:
> >
> > Section 4.2.5 is technology-specific language that is not current with
> > modern network operation needs and practices. We should remove it to
> > make NRPM clearer.
> >
> > Policy statement:
> >
> > Remove section 4.2.5.
> >
> > Comments:
> > a.Timetable for implementation: Immediate
> > b.Anything else:
> > _______________________________________________
> > 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.
> >
> >
>
>
> ------------------------------
>
> _______________________________________________
> ARIN-PPML mailing list
> ARIN-PPML at arin.net
> http://lists.arin.net/mailman/listinfo/arin-ppml
>
> End of ARIN-PPML Digest, Vol 104, Issue 3
> *****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140206/2733ac7e/attachment.htm>

From cja at daydream.com  Thu Feb  6 15:51:55 2014
From: cja at daydream.com (CJ Aronson)
Date: Thu, 6 Feb 2014 13:51:55 -0700
Subject: [arin-ppml] ARIN-PPML 2014-7
In-Reply-To: <CAMDXq5O+iqWtdpzSZqMc=At7M=PecVUJNU+-VfsNVj00M=YVmw@mail.gmail.com>
References: <CA+uaoiVOKrtby=myXRNBCmxn++c+56a7rmjOxmMmB3RAJW22qQ@mail.gmail.com>
	<CAP-guGXYMHqy-pMmWYR=KhcyhxCizGdyMxzw6CnZ0PKVtP6VJg@mail.gmail.com>
	<CA+uaoiUQYUfGRRw7mWR57AHbm5hF3MKgwzZQDKP4ACc0xmcfoA@mail.gmail.com>
	<CA+uaoiU_tUFBShi5TTa8R2wevUjUiwpEKR=r_1=BK1L3o4Vz4Q@mail.gmail.com>
	<CAMDXq5O+iqWtdpzSZqMc=At7M=PecVUJNU+-VfsNVj00M=YVmw@mail.gmail.com>
Message-ID: <CAC6JZKTZA_9uC6WOspcuHyoCtSqGRnWB-gwLYtr8aGJPNCR1qw@mail.gmail.com>

Martin

Do you have any real evidence of real harm being caused by it being two
instead of three?

Thanks!
-----Cathy


On Thu, Feb 6, 2014 at 1:40 PM, Martin Hannigan <hannigan at gmail.com> wrote:

> Rudi,
>
> Do you have any evidence of real harm?
>
> Best,
>
> Martin
>
>
>
> On Thursday, February 6, 2014, Rudolph Daniel <rudi.daniel at gmail.com>
> wrote:
>
>> I do not support the change from 2 to 3 for end user ixp s.
>> See my earlier remarks.
>> Does ARIN have good evidence of abuse of the current situation?
>>
>> Rudi Daniel
>> (information technologist)
>> 784 430 9235
>> On Feb 6, 2014 1:07 PM, <arin-ppml-request at arin.net> wrote:
>>
>>> Ok.William...thanks for that...was not too sure.
>>>
>>> RD
>>>
>>>
>>> On Fri, Jan 31, 2014 at 1:34 PM, William Herrin <bill at herrin.us> wrote:
>>>
>>>> On Fri, Jan 31, 2014 at 8:05 AM, Rudolph Daniel <rudi.daniel at gmail.com>
>>>> wrote:
>>>> > In the small Caribbean states, although there seems to be
>>>> > policy to implement IXP s, many are still not getting the buy
>>>> > in from existing ISP s ...so it is possible that an IXP could
>>>> > get off the ground with 2 and once up and running, others
>>>> > will join in.
>>>>
>>>> Hi Rudi,
>>>>
>>>> There aren't many use cases in which renumbering is genuinely trivial.
>>>> Three nodes in a BGP exchange is one of them.
>>>>
>>>> Regards,
>>>> Bill Herrin
>>>>
>>>>
>>>>
>>>> --
>>>> William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
>>>> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
>>>> Falls Church, VA 22042-3004
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> Rudi Daniel
>>>
>>> *danielcharles consulting
>>> <http://www.facebook.com/pages/Kingstown-Saint-Vincent-and-the-Grenadines/DanielCharles/153611257984774>*
>>>
>>>
>>>
> _______________________________________________
> 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/20140206/8e849a66/attachment.htm>

From rudi.daniel at gmail.com  Thu Feb  6 15:51:26 2014
From: rudi.daniel at gmail.com (Rudolph Daniel)
Date: Thu, 6 Feb 2014 16:51:26 -0400
Subject: [arin-ppml] Fwd: Re:  ARIN-PPML 2014-7
In-Reply-To: <CA+uaoiXHvCfXkQKMqcbF0LG8G+1wrtZVTbLz25OacCKZVuHGdg@mail.gmail.com>
References: <CA+uaoiVOKrtby=myXRNBCmxn++c+56a7rmjOxmMmB3RAJW22qQ@mail.gmail.com>
	<CAP-guGXYMHqy-pMmWYR=KhcyhxCizGdyMxzw6CnZ0PKVtP6VJg@mail.gmail.com>
	<CA+uaoiUQYUfGRRw7mWR57AHbm5hF3MKgwzZQDKP4ACc0xmcfoA@mail.gmail.com>
	<CA+uaoiU_tUFBShi5TTa8R2wevUjUiwpEKR=r_1=BK1L3o4Vz4Q@mail.gmail.com>
	<CAMDXq5O+iqWtdpzSZqMc=At7M=PecVUJNU+-VfsNVj00M=YVmw@mail.gmail.com>
	<CA+uaoiXHvCfXkQKMqcbF0LG8G+1wrtZVTbLz25OacCKZVuHGdg@mail.gmail.com>
Message-ID: <CA+uaoiX70a71F5WOYTmz+m_r-S+G29ryKrRWPFJvVGsY3Cb1nA@mail.gmail.com>

Rudi Daniel
(information technologist)
784 430 9235
---------- Forwarded message ----------
From: "Rudolph Daniel" <rudi.daniel at gmail.com>
Date: Feb 6, 2014 4:50 PM
Subject: Re: [arin-ppml] ARIN-PPML 2014-7
To: "Martin Hannigan" <hannigan at gmail.com>
Cc:

I am aware that on small states like the Caribbean, it has been difficult
to get support for ixp from ISP s who had a monopoly before deregulation,
and many small states still have just one or two ISP s.
I think Woody @pch has had some experience of conditions here in the
English speaking Caribbean, so if he believes that the conditions are now
better, then I will go with that....but I have not seen any appreciable
change so far.

Rudi Daniel
(information technologist)
784 430 9235
On Feb 6, 2014 4:40 PM, "Martin Hannigan" <hannigan at gmail.com> wrote:

> Rudi,
>
> Do you have any evidence of real harm?
>
> Best,
>
> Martin
>
>
>
> On Thursday, February 6, 2014, Rudolph Daniel <rudi.daniel at gmail.com>
> wrote:
>
>> I do not support the change from 2 to 3 for end user ixp s.
>> See my earlier remarks.
>> Does ARIN have good evidence of abuse of the current situation?
>>
>> Rudi Daniel
>> (information technologist)
>> 784 430 9235
>> On Feb 6, 2014 1:07 PM, <arin-ppml-request at arin.net> wrote:
>>
>>> Ok.William...thanks for that...was not too sure.
>>>
>>> RD
>>>
>>>
>>> On Fri, Jan 31, 2014 at 1:34 PM, William Herrin <bill at herrin.us> wrote:
>>>
>>>> On Fri, Jan 31, 2014 at 8:05 AM, Rudolph Daniel <rudi.daniel at gmail.com>
>>>> wrote:
>>>> > In the small Caribbean states, although there seems to be
>>>> > policy to implement IXP s, many are still not getting the buy
>>>> > in from existing ISP s ...so it is possible that an IXP could
>>>> > get off the ground with 2 and once up and running, others
>>>> > will join in.
>>>>
>>>> Hi Rudi,
>>>>
>>>> There aren't many use cases in which renumbering is genuinely trivial.
>>>> Three nodes in a BGP exchange is one of them.
>>>>
>>>> Regards,
>>>> Bill Herrin
>>>>
>>>>
>>>>
>>>> --
>>>> William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
>>>> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
>>>> Falls Church, VA 22042-3004
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> Rudi Daniel
>>>
>>> *danielcharles consulting
>>> <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/20140206/16583efe/attachment.htm>

From hannigan at gmail.com  Thu Feb  6 15:15:20 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Thu, 6 Feb 2014 15:15:20 -0500
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <0a573e7e5ec24a34bba99c20501e6e5f@DM2PR03MB398.namprd03.prod.outlook.com>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>
	<0a573e7e5ec24a34bba99c20501e6e5f@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <CAMDXq5Mxq4dFX4O++h3fyDLCW-fziFTFSAvg9pFyjya3PN9g4Q@mail.gmail.com>

We don't need the staff experience to know that ARIN already
has the resources needed to validate request data. It's a business
administration problem, not a policy problem anyhow.  Im not clear why this
is even in the proposal.

Not in favor, remove text re: point 1 below, revisit points 2/3 per below.

Best,

Marty, (Jackson's at RTC 4:30! )



On Thursday, February 6, 2014, David Huberman <David.Huberman at microsoft.com>
wrote:

> Thank you, Milton, for bringing this thread up.
>
> I've reviewed 2014-1 and thought about it carefully.  I am against this
> proposal.  I'll try and organize my thoughts, though they come from a few
> different angles.
>
> Text: https://www.arin.net/policy/proposals/2014_1.html
>
> 1) I'm against the specific 2014-1 language because I think it is almost
> entirely no-op.
>
> In general, I want NRPM to be brief, concise, and prescriptive.  "You
> qualify by doing X.  You don't qualify because of Y. You must show A, B,
> C."  We need less fluffy text in NRPM so that it is a more accessible and
> polished Policy document, imho.  In this case, only paragraph X.1 is
> operational.  It formally lays out just a few steps that ARIN already has
> available to it.  But these aren't the only tools ARIN has to verify
> request data, and I'm not convinced that having these specific bullet
> points in Policy helps the community or ARIN staff in any meaningful way.
>
> Put more straight forwardly:  ARIN staff already have these mechanisms
> available to them, and this policy text will not change the request process
> materially.
>
> 2) The PPML community has reviewed similar proposals twice, in my
> recollection.   There was a draft limiting out-of-region use discussed in
> Philadelphia. The community vocally was against it, and clearly told ARIN
> staff to keep doing what they were already doing. There was also a draft
> limiting out-of-region use discussed in Phoenix.  The community was again
> vocally against it, and clearly told the ARIN staff that this isn't a
> policy area they wish to discuss.
>
> 3) At the same time, the staff are continuing to report that there are
> significant problems from out-of-region requestors abusing the policies.
>  If you disagree with the PPML community (and I do - I think this is a
> serious issue that cries for Policy changes), then we need to draft text
> that significantly and materially helps ARIN staff fight fraud from
> out-of-region requestors.
>
> With regards,
> David
>
> David R Huberman
> Microsoft Corporation
> Senior IT/OPS Program Manager (GFS)
>
> From: arin-ppml-bounces at arin.net <javascript:;> [mailto:
> arin-ppml-bounces at arin.net <javascript:;>] On Behalf Of Milton L Mueller
> Sent: Thursday, February 6, 2014 6:42 AM
> To: ARIN PPML (ppml at arin.net <javascript:;>)
> Subject: [arin-ppml] support for 2014-1 (out of region use)
>
> Draft policy 2014-1 attempts to solve a problem left over from last year.
> During 2013 there was a round of policy proposals attempting to tie ARIN
> allocations more closely to usage in the region. They failed to gain
> consensus because they would have interfered with trans-regional networks
> in undesirable ways. Yet, current policy is still ambiguous on the issue of
> out of region use of ARIN registered resources. This proposal attempts to
> clear up that ambiguity in a way that avoids harmful effects on
> transnational or trans-regional network operators. The gist of the idea is
> to allow out of region use for organizations eligible for ARIN resources,
> but also provide policy authorization for ARIN to charge fees to verify the
> identity or usage of applicants outside the region. I think this approach
> provides the most flexibility while addressing the only real problems that
> have been cited for out of region use (verification issues).
>
> You can see the proposal in full here:
> https://www.arin.net/policy/proposals/2014_1.html
> Appreciate reading your comments about this.
>
>
> Milton L Mueller
> Professor, Syracuse University School of Information Studies
> Internet Governance Project
> http://internetgovernance.org
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net <javascript:;>).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net <javascript:;> if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140206/7648532f/attachment.htm>

From hannigan at gmail.com  Thu Feb  6 15:34:33 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Thu, 6 Feb 2014 15:34:33 -0500
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
 Allocation Conservation Update
In-Reply-To: <CAPDTRigg96qkZAVPTM-rnjuoyoXN27qWQzijVUoeAGF+wZSyKQ@mail.gmail.com>
References: <52E91DF0.9040909@arin.net> <52F2CB04.20905@quark.net>
	<52F3B9F3.5040706@umn.edu>
	<alpine.BSF.2.00.1402060904340.72878@mail.inlandnet.com>
	<CAPDTRigg96qkZAVPTM-rnjuoyoXN27qWQzijVUoeAGF+wZSyKQ@mail.gmail.com>
Message-ID: <CAMDXq5MgJXm+06pr+nNH3voJDmKO0iMLHqFp2P7COcWBs91FxA@mail.gmail.com>

I'm the author of this proposal as well as supporting it.

I don't have an objection to removing fee related language (which was
already there) as long as ARIN isn't classifying exchanges as ISP's. They
aren't.

I find the below comment re allocation size is "interesting", but not
related to this proposal.

JS is correct, the Open-IX community did discuss and agree that three makes
an IXP.

Best,

Marty


On Thursday, February 6, 2014, Michael Still <stillwaxin at gmail.com> wrote:

> On Thu, Feb 6, 2014 at 12:26 PM, John Springer <springer at inlandnet.com<javascript:;>>
> wrote:
> > Comments inline.
> >
> >
> > On Thu, 6 Feb 2014, David Farmer wrote:
> >
> >> On 2/5/14, 17:36 , Andrew Dul wrote:
> >>>
> >>> Hello,
> >>>
> >>> This draft policy will be discussed next week at the nanog PPC, in
> >>> addition we welcome feedback on this draft on PPML.  Specifically if
> you
> >>> could comment on the following two points it would be appreciated.
> >>>
> >>> Thanks,
> >>> Andrew
> >>>
> >>>
> >>> Does the community support raising the minimum requirement for IXPs
> from
> >>> 2 to 3?
> >>
> >>
> >> I support the change from a two participants to a three participant
> >> standard to qualify as an Internet Exchange Point (IXP).
> >>
> >> To date the risk created by allowing the minimum of two participates for
> >> an IXP has been extremely low, as the motivation for abuse was also
> >> extremely low.  However, as we proceed through run-out of the general
> IPv4
> >> free pool the motivations for abuse will increase dramatically. Raising
> the
> >> standard to three participants to qualify as an IXP seems like a prudent
> >> precaution to ensure that the reservation for IXPs, and other critical
> >> infrastructure that was made in ARIN-2011-4, is protected to ensure
> >> availability of resources for legitimate IXPs in the future.
> >>
> >> There will be some impact on the start-up of some IXPs, this is
> >> unfortunate. However, the three participant standard is not completely
> >> unreasonable, given the potential for increased abuse of the two
> participant
> >> standard.
> >
> >
> > The Open-IX community has had some discussions of this very subject.
> Perhaps
> > the author or other members of the Open-IX Board can summarize on this
> > specific matter. I believe the Open-IX community has settled on 3 as the
> way
> > forward. I am OK with that.
> >
> >
> >>> Does the community believe that additional clarity is needed to define
> >>> if an IXP uses the end-user or ISP fee schedule?
> >>
> >>
> >> I believe both the old language and the new language regarding this
> issue
> >> should be stricken, this is an ARIN business issue, not a policy issue.
>  I
> >> have no problem with such a recommendation being included in the
> comments
> >> section, outside the policy text itself.  I support the general concept
> it
> >> represents, but it is just not a policy issue in my opinion.
> >
> >
> > many pluses to the paragraph immediately preceeding. I feel that this is
> a
> > direct modification of the fee structure via policy, and therefore do not
> > support the draft policy as written.
> >
> > John Springer
> >
>
> Not really responding to you, you just happened to be the last in the
> thread..
>
> Perhaps we should look at tackling some of our dwindling number
> resources issues in a different perspective.  Have we considered
> updating the policy to only issue prefix sizes which are reasonable in
> the first place?  What makes just setting up an IXP be enough to issue
> a /24?  What if this IXP is in a market in which there will never be
> more than 126 participants?  Or worse much less?  Should these IXPs be
> given /24s when a much smaller allocation may be all that's needed?
> Or should every IXP have to start small and as their participation
> increases they be issued new space to move into?
>
> I believe the argument for global prefix visibility of IXP space has
> been largely discussed and consensus is that this space does not and
> should not be globally reachable voiding any perceived need for a /24
> I believe.
>
> >
> >
> >> Thanks.
> >>
> >> --
> >> ================================================
> >> David Farmer               Email: farmer at umn.edu <javascript:;>
> >> Office of Information Technology
> >> University of Minnesota
> >> 2218 University Ave SE     Phone: 1-612-626-0815
> >> Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
> >> ================================================
> >> _______________________________________________
> >> PPML
> >> You are receiving this message because you are subscribed to
> >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net <javascript:;>
> ).
> >> Unsubscribe or manage your mailing list subscription at:
> >> http://lists.arin.net/mailman/listinfo/arin-ppml
> >> Please contact info at arin.net <javascript:;> 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 <javascript:;>).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net <javascript:;> if you experience any
> issues.
>
>
>
> --
> [stillwaxin at gmail.com <javascript:;> ~]$ cat .signature
> cat: .signature: No such file or directory
> [stillwaxin at gmail.com <javascript:;> ~]$
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net <javascript:;>).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net <javascript:;> if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140206/30928be0/attachment.htm>

From hannigan at gmail.com  Thu Feb  6 16:18:03 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Thu, 6 Feb 2014 16:18:03 -0500
Subject: [arin-ppml] ARIN-PPML 2014-7
In-Reply-To: <CAC6JZKTZA_9uC6WOspcuHyoCtSqGRnWB-gwLYtr8aGJPNCR1qw@mail.gmail.com>
References: <CA+uaoiVOKrtby=myXRNBCmxn++c+56a7rmjOxmMmB3RAJW22qQ@mail.gmail.com>
	<CAP-guGXYMHqy-pMmWYR=KhcyhxCizGdyMxzw6CnZ0PKVtP6VJg@mail.gmail.com>
	<CA+uaoiUQYUfGRRw7mWR57AHbm5hF3MKgwzZQDKP4ACc0xmcfoA@mail.gmail.com>
	<CA+uaoiU_tUFBShi5TTa8R2wevUjUiwpEKR=r_1=BK1L3o4Vz4Q@mail.gmail.com>
	<CAMDXq5O+iqWtdpzSZqMc=At7M=PecVUJNU+-VfsNVj00M=YVmw@mail.gmail.com>
	<CAC6JZKTZA_9uC6WOspcuHyoCtSqGRnWB-gwLYtr8aGJPNCR1qw@mail.gmail.com>
Message-ID: <CAMDXq5PkV1DhKKtDymTFz6jfss=xNVxLgq0-gbizAcmN55y=Fg@mail.gmail.com>

The policy proposal and comments in support clearly articulate the pros and
cons.

Best,

Martin


On Thursday, February 6, 2014, CJ Aronson <cja at daydream.com> wrote:

> Martin
>
> Do you have any real evidence of real harm being caused by it being two
> instead of three?
>
> Thanks!
> -----Cathy
>
>
> On Thu, Feb 6, 2014 at 1:40 PM, Martin Hannigan <hannigan at gmail.com<javascript:_e(%7B%7D,'cvml','hannigan at gmail.com');>
> > wrote:
>
>> Rudi,
>>
>> Do you have any evidence of real harm?
>>
>> Best,
>>
>> Martin
>>
>>
>>
>> On Thursday, February 6, 2014, Rudolph Daniel <rudi.daniel at gmail.com<javascript:_e(%7B%7D,'cvml','rudi.daniel at gmail.com');>>
>> wrote:
>>
>>> I do not support the change from 2 to 3 for end user ixp s.
>>> See my earlier remarks.
>>> Does ARIN have good evidence of abuse of the current situation?
>>>
>>> Rudi Daniel
>>> (information technologist)
>>> 784 430 9235
>>> On Feb 6, 2014 1:07 PM, <arin-ppml-request at arin.net> wrote:
>>>
>>>> Ok.William...thanks for that...was not too sure.
>>>>
>>>> RD
>>>>
>>>>
>>>> On Fri, Jan 31, 2014 at 1:34 PM, William Herrin <bill at herrin.us> wrote:
>>>>
>>>>> On Fri, Jan 31, 2014 at 8:05 AM, Rudolph Daniel <rudi.daniel at gmail.com>
>>>>> wrote:
>>>>> > In the small Caribbean states, although there seems to be
>>>>> > policy to implement IXP s, many are still not getting the buy
>>>>> > in from existing ISP s ...so it is possible that an IXP could
>>>>> > get off the ground with 2 and once up and running, others
>>>>> > will join in.
>>>>>
>>>>> Hi Rudi,
>>>>>
>>>>> There aren't many use cases in which renumbering is genuinely trivial.
>>>>> Three nodes in a BGP exchange is one of them.
>>>>>
>>>>> Regards,
>>>>> Bill Herrin
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
>>>>> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
>>>>> Falls Church, VA 22042-3004
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Rudi Daniel
>>>>
>>>> *danielcharles consulting
>>>> <http://www.facebook.com/pages/Kingstown-Saint-Vincent-and-the-Grenadines/DanielCharles/153611257984774>*
>>>>
>>>>
>>>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<javascript:_e(%7B%7D,'cvml','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<javascript:_e(%7B%7D,'cvml','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/20140206/a40c7c8f/attachment.htm>

From ipgoddess.arin at gmail.com  Thu Feb  6 18:49:18 2014
From: ipgoddess.arin at gmail.com (Stacy Hughes)
Date: Thu, 6 Feb 2014 15:49:18 -0800
Subject: [arin-ppml] Draft Policy ARIN-2014-6: Remove 7.1
In-Reply-To: <52EFBAFB.8040002@quark.net>
References: <52E91DE0.2010004@arin.net> <52EFBAFB.8040002@quark.net>
Message-ID: <2D28268C-700B-4812-818D-DF2800EE2FD1@gmail.com>

Hi All,
Way to come out swinging!
Anyone else?  The gauntlet has been thrown, and we sure need your feedback.

Personally I support this draft policy as written.
Stacy
On Feb 3, 2014, at 7:51 AM, Andrew Dul <andrew.dul at quark.net> wrote:

>> 
>> Draft Policy ARIN-2014-6
>> Remove 7.1
>> 
>> Date: 29 January 2014
>> 
>> Problem Statement:
>> 
>> 7.1 attempts to assert rules on rDNS management at ARIN. It fails to
>> do so because it only addresses in-addr.arpa (missing equally
>> important rules in ip6.arpa). It's also not based on any RFC; it's an
>> arbitrary decision made by ARIN technical staff. We should remove this
>> text from policy, as it represents operational practice rather than
>> ARIN number policy.
>> 
>> Policy statement:
>> 
>> Remove 7.1
>> 
>> Comments:
>> a.Timetable for implementation: Immediate
>> b.Anything else:
>> 
>> 7.1. Maintaining IN-ADDRs
>> 
>> All ISPs receiving one or more distinct /16 CIDR blocks of IP
>> addresses from ARIN will be responsible for maintaining all
>> IN-ADDR.ARPA domain records for their respective customers. For blocks
>> smaller than /16, and for the segment of larger blocks  smaller than
>> /16, ARIN can maintain IN-ADDRs.
>> 
> 
> At this time I'm opposed to this policy.  While I agree this text is out
> of date and probably should be updated.  I don't necessarily agree that
> the section should just be removed.  Reverse DNS is an important part of
> the services that ARIN provides to address holders.  I believe that it
> is wholly appropriate for the NRMP to contain a section describing how
> ARIN should implement rDNS services to address holders.
> 
> Andrew
> _______________________________________________
> 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/20140206/65786100/attachment.htm>

From farmer at umn.edu  Thu Feb  6 19:31:03 2014
From: farmer at umn.edu (David Farmer)
Date: Thu, 06 Feb 2014 18:31:03 -0600
Subject: [arin-ppml] ARIN-PPML 2014-7
In-Reply-To: <CAC6JZKTZA_9uC6WOspcuHyoCtSqGRnWB-gwLYtr8aGJPNCR1qw@mail.gmail.com>
References: <CA+uaoiVOKrtby=myXRNBCmxn++c+56a7rmjOxmMmB3RAJW22qQ@mail.gmail.com>	<CAP-guGXYMHqy-pMmWYR=KhcyhxCizGdyMxzw6CnZ0PKVtP6VJg@mail.gmail.com>	<CA+uaoiUQYUfGRRw7mWR57AHbm5hF3MKgwzZQDKP4ACc0xmcfoA@mail.gmail.com>	<CA+uaoiU_tUFBShi5TTa8R2wevUjUiwpEKR=r_1=BK1L3o4Vz4Q@mail.gmail.com>	<CAMDXq5O+iqWtdpzSZqMc=At7M=PecVUJNU+-VfsNVj00M=YVmw@mail.gmail.com>
	<CAC6JZKTZA_9uC6WOspcuHyoCtSqGRnWB-gwLYtr8aGJPNCR1qw@mail.gmail.com>
Message-ID: <52F42947.1010107@umn.edu>

There is no evidence of real harm for either side of this argument, 
there can't be.  The two participant rule is currently in place, and 
there is no motivation for abusing the two participant rule just yet. 
Since its not been instantiated yet, there is no way the three 
participant rule could have harmed anyone, and any abuse of the two 
participant rule isn't going to happen until run-out of the general ARIN 
IPv4 free pool.  So, there is no way to decide this one based on real 
evidence, and it is hyperbole to even ask for such evidence from either 
side.

I feel I provided a good argument for the proposal and Rudi provided an 
equally good argument against the proposal.  If there are arguments for 
or against that haven't been provided, please provide them for the rest 
of community to consider.

There seems to be a clear potential for abuse of the two participant 
rule after run-out of the general ARIN IPv4 free pool.  Also, there 
seems to be a clear potential that changing to three participants will 
make it more difficult for some IXPs to get going.

This is clearly a judgement call, I think both arguments have merit and 
both have faults.  I think it is fine to come down on either side of 
this question.  But, let's try to limit the acrimony and the hyperbole, 
the AC needs a clear reading from the community and those things don't help.

Thanks.


On 2/6/14, 14:51 , CJ Aronson wrote:
> Martin
>
> Do you have any real evidence of real harm being caused by it being two
> instead of three?
>
> Thanks!
> -----Cathy
>
>
> On Thu, Feb 6, 2014 at 1:40 PM, Martin Hannigan <hannigan at gmail.com
> <mailto:hannigan at gmail.com>> wrote:
>
>     Rudi,
>
>     Do you have any evidence of real harm?
>
>     Best,
>
>     Martin


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


From owen at delong.com  Thu Feb  6 21:27:34 2014
From: owen at delong.com (Owen DeLong)
Date: Thu, 6 Feb 2014 18:27:34 -0800
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
	Allocation Conservation Update
In-Reply-To: <52F3B9F3.5040706@umn.edu>
References: <52E91DF0.9040909@arin.net> <52F2CB04.20905@quark.net>
	<52F3B9F3.5040706@umn.edu>
Message-ID: <6C8DE21A-F09B-4F4A-A5A7-28F9FE7CCDB9@delong.com>


On Feb 6, 2014, at 8:36 AM, David Farmer <farmer at umn.edu> wrote:

> On 2/5/14, 17:36 , Andrew Dul wrote:
>> Hello,
>> 
>> This draft policy will be discussed next week at the nanog PPC, in
>> addition we welcome feedback on this draft on PPML.  Specifically if you
>> could comment on the following two points it would be appreciated.
>> 
>> Thanks,
>> Andrew
>> 
>> 
>> Does the community support raising the minimum requirement for IXPs from
>> 2 to 3?
> 
> I support the change from a two participants to a three participant standard to qualify as an Internet Exchange Point (IXP).
> 
> To date the risk created by allowing the minimum of two participates for an IXP has been extremely low, as the motivation for abuse was also extremely low.  However, as we proceed through run-out of the general IPv4 free pool the motivations for abuse will increase dramatically. Raising the standard to three participants to qualify as an IXP seems like a prudent precaution to ensure that the reservation for IXPs, and other critical infrastructure that was made in ARIN-2011-4, is protected to ensure availability of resources for legitimate IXPs in the future.
> 
> There will be some impact on the start-up of some IXPs, this is unfortunate.  However, the three participant standard is not completely unreasonable, given the potential for increased abuse of the two participant standard.
> 

I oppose the change. Anyone inclined to abuse a two participant standard can easily create or obtain a 3rd participant for said purpose. This is literally a case of change for the sake of change. No, a 3 participant minimum is not an unreasonable standard. However, since it does have some negative impact and is utterly unlikely to be at all effective in deterring abuse, I see no benefit to the change.

Owen



From mysidia at gmail.com  Thu Feb  6 20:01:09 2014
From: mysidia at gmail.com (Jimmy Hess)
Date: Thu, 6 Feb 2014 19:01:09 -0600
Subject: [arin-ppml] Draft Policy ARIN-2014-6: Remove 7.1
In-Reply-To: <52EFBAFB.8040002@quark.net>
References: <52E91DE0.2010004@arin.net> <52EFBAFB.8040002@quark.net>
Message-ID: <CAAAwwbXZ34b1gb7EQTAqx3pRTCGt3yGOMv1iBycg4ShuFDhhSw@mail.gmail.com>

On Mon, Feb 3, 2014 at 9:51 AM, Andrew Dul <andrew.dul at quark.net> wrote:

>
> At this time I'm opposed to this policy.  While I agree this text is out
> of date and probably should be updated.  I don't necessarily agree that
> the section should just be removed.  Reverse DNS is an important part of


I am in agreement, and oppose the policy as written; the section should not
be removed.


The section explains when it is the resource-holder's responsibility to
maintain IN-ADDR's, and also: when ARIN may host the IN-ADDRs.

It just needs some minor tweaking to include and distinguish between IPv6
and IPv4 IN-ADDRs



> Andrew
>
--
-JH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140206/6a1b7012/attachment.htm>

From owen at delong.com  Thu Feb  6 23:03:00 2014
From: owen at delong.com (Owen DeLong)
Date: Thu, 6 Feb 2014 20:03:00 -0800
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
	Allocation Conservation Update
In-Reply-To: <CAPDTRigg96qkZAVPTM-rnjuoyoXN27qWQzijVUoeAGF+wZSyKQ@mail.gmail.com>
References: <52E91DF0.9040909@arin.net> <52F2CB04.20905@quark.net>
	<52F3B9F3.5040706@umn.edu>
	<alpine.BSF.2.00.1402060904340.72878@mail.inlandnet.com>
	<CAPDTRigg96qkZAVPTM-rnjuoyoXN27qWQzijVUoeAGF+wZSyKQ@mail.gmail.com>
Message-ID: <DD14D223-39DE-4F1A-B5F2-1ECCB4D256FD@delong.com>

> 
> Not really responding to you, you just happened to be the last in the thread..
> 
> Perhaps we should look at tackling some of our dwindling number
> resources issues in a different perspective.  Have we considered
> updating the policy to only issue prefix sizes which are reasonable in
> the first place?  What makes just setting up an IXP be enough to issue
> a /24?  What if this IXP is in a market in which there will never be
> more than 126 participants?  Or worse much less?  Should these IXPs be
> given /24s when a much smaller allocation may be all that's needed?
> Or should every IXP have to start small and as their participation
> increases they be issued new space to move into?
> 
> I believe the argument for global prefix visibility of IXP space has
> been largely discussed and consensus is that this space does not and
> should not be globally reachable voiding any perceived need for a /24
> I believe.

While such an optimization might be possible, I would argue that the potential
benefit is not sufficient to justify the effort.

Let?s assume a total ARIN region deployment of 25,000 IXPs. Further let?s
assume that roughly 1/4 of them fit your criteria of no potential for more than
126 participants. Let?s bound the smallest practical IXP at a /26 (62 participants).

Best case, if all of the ~6,250 participants could fit in /26s, you would save
6,250*3/4 = 4,687.5 /24s. Rounding that down (for numerical convenience
to 4096, that?s a total savings of a single /12.

In reality, the actual savings are virtually guaranteed to be much much less,
probably more like 1 or maybe 2 digits of /24s.

It?s time to realize that attempts to forestall the runout of IPv4 are futile and
stop optimizing the packing of the deck chairs.

Owen




From rudi.daniel at gmail.com  Thu Feb  6 23:30:02 2014
From: rudi.daniel at gmail.com (Rudolph Daniel)
Date: Fri, 7 Feb 2014 00:30:02 -0400
Subject: [arin-ppml] ARIN-PPML 2014-7
In-Reply-To: <52F42947.1010107@umn.edu>
References: <CA+uaoiVOKrtby=myXRNBCmxn++c+56a7rmjOxmMmB3RAJW22qQ@mail.gmail.com>
	<CAP-guGXYMHqy-pMmWYR=KhcyhxCizGdyMxzw6CnZ0PKVtP6VJg@mail.gmail.com>
	<CA+uaoiUQYUfGRRw7mWR57AHbm5hF3MKgwzZQDKP4ACc0xmcfoA@mail.gmail.com>
	<CA+uaoiU_tUFBShi5TTa8R2wevUjUiwpEKR=r_1=BK1L3o4Vz4Q@mail.gmail.com>
	<CAMDXq5O+iqWtdpzSZqMc=At7M=PecVUJNU+-VfsNVj00M=YVmw@mail.gmail.com>
	<CAC6JZKTZA_9uC6WOspcuHyoCtSqGRnWB-gwLYtr8aGJPNCR1qw@mail.gmail.com>
	<52F42947.1010107@umn.edu>
Message-ID: <CA+uaoiXmpPgQYRh+eCt+j22LUjs=yfKyQg1hA91-1kLThj3u5A@mail.gmail.com>

"There seems to be a clear potential for abuse of the two participant rule
after run-out of the general ARIN IPv4 free pool.  Also, there seems to be
a clear potential that changing to three participants will make it more
difficult for some IXPs to get going"

The potential for abuse mentioned to occur after runout is an indication
that something may need to change.
Raising the bar to 3 is intended to prevent the abuse?
I really can't see that being any more effective than what is currently the
the form.
Regards

Rudi Daniel
(information technologist)
784 430 9235
On Feb 6, 2014 8:31 PM, "David Farmer" <farmer at umn.edu> wrote:

> There is no evidence of real harm for either side of this argument, there
> can't be.  The two participant rule is currently in place, and there is no
> motivation for abusing the two participant rule just yet. Since its not
> been instantiated yet, there is no way the three participant rule could
> have harmed anyone, and any abuse of the two participant rule isn't going
> to happen until run-out of the general ARIN IPv4 free pool.  So, there is
> no way to decide this one based on real evidence, and it is hyperbole to
> even ask for such evidence from either side.
>
> I feel I provided a good argument for the proposal and Rudi provided an
> equally good argument against the proposal.  If there are arguments for or
> against that haven't been provided, please provide them for the rest of
> community to consider.
>
> There seems to be a clear potential for abuse of the two participant rule
> after run-out of the general ARIN IPv4 free pool.  Also, there seems to be
> a clear potential that changing to three participants will make it more
> difficult for some IXPs to get going.
>
> This is clearly a judgement call, I think both arguments have merit and
> both have faults.  I think it is fine to come down on either side of this
> question.  But, let's try to limit the acrimony and the hyperbole, the AC
> needs a clear reading from the community and those things don't help.
>
> Thanks.
>
>
> On 2/6/14, 14:51 , CJ Aronson wrote:
>
>> Martin
>>
>> Do you have any real evidence of real harm being caused by it being two
>> instead of three?
>>
>> Thanks!
>> -----Cathy
>>
>>
>> On Thu, Feb 6, 2014 at 1:40 PM, Martin Hannigan <hannigan at gmail.com
>> <mailto:hannigan at gmail.com>> wrote:
>>
>>     Rudi,
>>
>>     Do you have any evidence of real harm?
>>
>>     Best,
>>
>>     Martin
>>
>
>
> --
> ================================================
> David Farmer               Email: farmer at umn.edu
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE     Phone: 1-612-626-0815
> Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
> ================================================
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140207/8d3bcc92/attachment.htm>

From narten at us.ibm.com  Fri Feb  7 00:53:02 2014
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 07 Feb 2014 00:53:02 -0500
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201402070553.s175r28g004482@rotala.raleigh.ibm.com>

Total of 34 messages in the last 7 days.
 
script run at: Fri Feb  7 00:53:02 EST 2014
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 14.71% |    5 | 32.39% |   147952 | rudi.daniel at gmail.com
 14.71% |    5 | 15.12% |    69061 | hannigan at gmail.com
  8.82% |    3 |  5.66% |    25862 | andrew.dul at quark.net
  8.82% |    3 |  5.44% |    24858 | springer at inlandnet.com
  8.82% |    3 |  4.24% |    19371 | owen at delong.com
  2.94% |    1 |  8.28% |    37805 | scottleibrand at gmail.com
  5.88% |    2 |  3.67% |    16785 | farmer at umn.edu
  2.94% |    1 |  4.79% |    21902 | ipgoddess.arin at gmail.com
  2.94% |    1 |  2.77% |    12639 | cja at daydream.com
  2.94% |    1 |  2.41% |    10996 | info at arin.net
  2.94% |    1 |  2.26% |    10302 | mueller at syr.edu
  2.94% |    1 |  2.15% |     9801 | stillwaxin at gmail.com
  2.94% |    1 |  2.04% |     9304 | david.huberman at microsoft.com
  2.94% |    1 |  1.66% |     7577 | mysidia at gmail.com
  2.94% |    1 |  1.65% |     7551 | sryerse at eclipse-networks.com
  2.94% |    1 |  1.49% |     6821 | gary.buhrmaster at gmail.com
  2.94% |    1 |  1.47% |     6699 | narten at us.ibm.com
  2.94% |    1 |  1.28% |     5847 | bill at herrin.us
  2.94% |    1 |  1.24% |     5679 | jcurran at arin.net
--------+------+--------+----------+------------------------
100.00% |   34 |100.00% |   456812 | Total



From ppml at rs.seastrom.com  Fri Feb  7 06:50:57 2014
From: ppml at rs.seastrom.com (Rob Seastrom)
Date: Fri, 07 Feb 2014 06:50:57 -0500
Subject: [arin-ppml] Draft Policy ARIN-2014-6: Remove 7.1
In-Reply-To: <CAAAwwbXZ34b1gb7EQTAqx3pRTCGt3yGOMv1iBycg4ShuFDhhSw@mail.gmail.com>
	(Jimmy Hess's message of "Thu, 6 Feb 2014 19:01:09 -0600")
References: <52E91DE0.2010004@arin.net> <52EFBAFB.8040002@quark.net>
	<CAAAwwbXZ34b1gb7EQTAqx3pRTCGt3yGOMv1iBycg4ShuFDhhSw@mail.gmail.com>
Message-ID: <86txcb3zvi.fsf@valhalla.seastrom.com>


Jimmy Hess <mysidia at gmail.com> writes:

> I am in agreement, and oppose the policy as written; the section
> should not be removed.
>
> The section explains when it is the resource-holder's responsibility to
> maintain IN-ADDR's, and also: when ARIN may host the IN-ADDRs.
>
> It just needs some minor tweaking to include and distinguish between IPv6 and
> IPv4 IN-ADDRs

Hi Jimmy,

There are a lot of important functions that ARIN performs that are not
codified in the NRPM.  For instance, bulk dumps of WHOIS and the
requirement for annual validation of POCs is in the NRPM, but the
technical details of how ARIN is to run a WHOIS server are not.

The NRPM does not say anything about ip6.arpa, yet somehow it works fine.

Could you provide some thoughts to back up why it ought to stay?

Speaking as secondary shepherd for the proposal, we value your input.

Thanks,

-r




From mysidia at gmail.com  Fri Feb  7 07:33:23 2014
From: mysidia at gmail.com (Jimmy Hess)
Date: Fri, 7 Feb 2014 06:33:23 -0600
Subject: [arin-ppml] Draft Policy ARIN-2014-6: Remove 7.1
In-Reply-To: <86txcb3zvi.fsf@valhalla.seastrom.com>
References: <52E91DE0.2010004@arin.net> <52EFBAFB.8040002@quark.net>
	<CAAAwwbXZ34b1gb7EQTAqx3pRTCGt3yGOMv1iBycg4ShuFDhhSw@mail.gmail.com>
	<86txcb3zvi.fsf@valhalla.seastrom.com>
Message-ID: <CAAAwwbWMVNFUkmqSfoHH+bnDq7yH8xP6xrAVAUDQyamnz9OFDQ@mail.gmail.com>

On Fri, Feb 7, 2014 at 5:50 AM, Rob Seastrom <ppml at rs.seastrom.com> wrote:
>
>  Jimmy Hess <mysidia at gmail.com> writes:
> > I am in agreement, and oppose the policy as written; the section
> > should not be removed.
> Hi Jimmy, There are a lot of important functions that ARIN performs that
> are not codified in the NRPM.  For instance, bulk dumps of WHOIS and
> the requirement for annual validation of POCs is in the NRPM, but the
> technical details of how ARIN is to run a WHOIS server are not.
>

Yes;   however,  a statement about some responsibility for the IN-ADDRs is
not a mere technical detail of some extra service from ARIN. The reverse
allocations go hand-in-hand with an allocation itself and are absolutely
vital  ---  these details are probably more important for resource holders
than WHOIS technical details.

The number policy should make it clear where the resource holder has a
responsibility to maintain these, and what kind of structure for the DNS
services the resource holder will need to provide their customers' reverse
DNS.

The NRPM  _does_  specify similar details about WHOIS;
although it does not specify how resource holders are to actually operate
their RWhois servers,  we have things such as:

"4.2.3.7.1. Reassignment Information
Each IPv4 assignment containing a /29 or more addresses shall be registered
in the WHOIS directory via SWIP or a distributed service"



> The NRPM does not say anything about ip6.arpa, yet somehow it works fine.
>
> Could you provide some thoughts to back up why it ought to stay?
>
> Speaking as secondary shepherd for the proposal, we value your input.
>
> Thanks,
>
> -r
>
>
>


-- 
-JH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140207/bce87a7c/attachment.htm>

From mysidia at gmail.com  Fri Feb  7 08:21:04 2014
From: mysidia at gmail.com (Jimmy Hess)
Date: Fri, 7 Feb 2014 07:21:04 -0600
Subject: [arin-ppml] ARIN-PPML 2014-7
In-Reply-To: <52F42947.1010107@umn.edu>
References: <CA+uaoiVOKrtby=myXRNBCmxn++c+56a7rmjOxmMmB3RAJW22qQ@mail.gmail.com>
	<CAP-guGXYMHqy-pMmWYR=KhcyhxCizGdyMxzw6CnZ0PKVtP6VJg@mail.gmail.com>
	<CA+uaoiUQYUfGRRw7mWR57AHbm5hF3MKgwzZQDKP4ACc0xmcfoA@mail.gmail.com>
	<CA+uaoiU_tUFBShi5TTa8R2wevUjUiwpEKR=r_1=BK1L3o4Vz4Q@mail.gmail.com>
	<CAMDXq5O+iqWtdpzSZqMc=At7M=PecVUJNU+-VfsNVj00M=YVmw@mail.gmail.com>
	<CAC6JZKTZA_9uC6WOspcuHyoCtSqGRnWB-gwLYtr8aGJPNCR1qw@mail.gmail.com>
	<52F42947.1010107@umn.edu>
Message-ID: <CAAAwwbU1tLcdzxFbOZKo4j+m8rvTTZfwWxEYZ-7k-NTwd=ErBQ@mail.gmail.com>

On Thu, Feb 6, 2014 at 6:31 PM, David Farmer <farmer at umn.edu> wrote:

> There seems to be a clear potential for abuse of the two participant rule
> after run-out of the general ARIN IPv4 free pool.  Also, there seems to be
> a clear potential that changing to three participants will make it more
> difficult for some IXPs to get going.
>

Agreed, and I would favor the 3 participant rule against the 2 participant
rule.   It would be hard indeed, to start an Exchange later; if all the
reserved resources were allocated to  2-participant "exchanges".
The burden should not be obscenely high, for a new Exchange to sign up at
least 3 participants.

As I see it:  ARIN's job after exhaustion, is to try to allocate IP address
resources required today,  not to facilitate the anticipated expansion via
IXPs  that would today be just expensive two-member peering arrangements
structured as a 2 member IXP in order to qualify for some extra /22 or so.


My other observation is:   An Exchange with only two current participants
is not really an Exchange,  but a private peering -- regardless of the
theory of possible additional participants in the future.

While it is ARIN policy not to recover addresses solely due to lack of use,
 PERHAPS   it should be different for IXP  and critical
infrastructure/immediate need  microallocations  under 4.4,   or 4.10.

E.g.   Required notification when the number of verifiable
actively-interconnected Exchange participants drops below 2,

Or, when some or all of the microallocation is no longer being used in the
manner that justified its allocation for Critical Infrastructure:

With possible  required return and renumber requirement  solely due to
non-use.


Thanks.
>
--
-JH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140207/b6cce90b/attachment.htm>

From billdarte at gmail.com  Fri Feb  7 10:23:51 2014
From: billdarte at gmail.com (Bill Darte)
Date: Fri, 7 Feb 2014 09:23:51 -0600
Subject: [arin-ppml] Draft Policy 2014-2 Improving 8.4 Anti-Flip Language
Message-ID: <CAMApp36ZEguadbZzhKNjJQY_ks_zxAvDFwH_rTtPRhOezd6e_w@mail.gmail.com>

Hello,

As policy shepherd for DP-2014-2, I am interested in comments about the
problem statement, need and efficacy of language drafted.  I have included
current information below.  A statement of support or opposition and brief
reasoning would be most helpful, but also suggestions on improvement are
also welcomed if you feel this draft moves our region in a positive
direction, but currently misses the mark.  Thanks!

*Problem Statement:*
*Current NRPM Language*: "Source entities within the ARIN region must not
have received a transfer, allocation, or assignment of IPv4 number
resources from ARIN for the 12 months prior to the approval of a transfer
request. This restriction does not include M&A transfers."

This prevents anyone who receives BLOCK A in 2014 from transferring to
another RIR a different block, BLOCK B, which was issued 5, 10, 15, 20
years ago. In my company, we needed to move a legacy block being used in
Asia over to APNIC. But because we had gotten a new block in 2013, we were
prevented from moving the old block to a different RIR.

*Proposed Language Modification: (Draft Policy statement) Change undelined*
Source entities within the ARIN region must not have received a transfer,
allocation, or assignment of IPv4 number resources from ARIN for the 12
months prior to the approval of a transfer request. This restriction does
not include M&A transfers. *Restrictions related to recent receipt of
blocks shall not apply to inter-RIR transfers within the same organization
and its subsidiaries.*

One comment has suggested that the clause '*and its subsidiaries*' opens
opportunity for abuse.......another comment attempting to mitigate this
possibility suggested the clause be modified as....'and its
subsidiaries *providing
network services*'

Thank you for sharing your insights and for being part of the ARIN open,
bottom up, policy development process.

Bill Darte
ARIN Advisory Council
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140207/6bbce11f/attachment.htm>

From bross at pobox.com  Fri Feb  7 10:05:44 2014
From: bross at pobox.com (Brandon Ross)
Date: Fri, 7 Feb 2014 10:05:44 -0500 (EST)
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
 Allocation Conservation Update
In-Reply-To: <6C8DE21A-F09B-4F4A-A5A7-28F9FE7CCDB9@delong.com>
References: <52E91DF0.9040909@arin.net> <52F2CB04.20905@quark.net>
	<52F3B9F3.5040706@umn.edu>
	<6C8DE21A-F09B-4F4A-A5A7-28F9FE7CCDB9@delong.com>
Message-ID: <alpine.OSX.2.02.1402071003480.5486@brugal.local>

On Thu, 6 Feb 2014, Owen DeLong wrote:

> I oppose the change. Anyone inclined to abuse a two participant standard 
> can easily create or obtain a 3rd participant for said purpose. This is 
> literally a case of change for the sake of change. No, a 3 participant 
> minimum is not an unreasonable standard. However, since it does have 
> some negative impact and is utterly unlikely to be at all effective in 
> deterring abuse, I see no benefit to the change.

I agree with Owen on all points and oppose the policy change.  Most 
importantly, this policy change significantly raises the bar for a 
legitimate IXP to get started while doing nothing effective to prevent what 
is, effectively, a tiny amount of potential abuse.

-- 
Brandon Ross                                      Yahoo & AIM:  BrandonNRoss
+1-404-635-6667                                                ICQ:  2269442
                                                          Skype:  brandonross
Schedule a meeting:  http://www.doodle.com/bross


From rudi.daniel at gmail.com  Fri Feb  7 11:58:12 2014
From: rudi.daniel at gmail.com (Rudolph Daniel)
Date: Fri, 7 Feb 2014 12:58:12 -0400
Subject: [arin-ppml] ARIN-PPML 2014-7
In-Reply-To: <CAAAwwbU1tLcdzxFbOZKo4j+m8rvTTZfwWxEYZ-7k-NTwd=ErBQ@mail.gmail.com>
References: <CA+uaoiVOKrtby=myXRNBCmxn++c+56a7rmjOxmMmB3RAJW22qQ@mail.gmail.com>
	<CAP-guGXYMHqy-pMmWYR=KhcyhxCizGdyMxzw6CnZ0PKVtP6VJg@mail.gmail.com>
	<CA+uaoiUQYUfGRRw7mWR57AHbm5hF3MKgwzZQDKP4ACc0xmcfoA@mail.gmail.com>
	<CA+uaoiU_tUFBShi5TTa8R2wevUjUiwpEKR=r_1=BK1L3o4Vz4Q@mail.gmail.com>
	<CAMDXq5O+iqWtdpzSZqMc=At7M=PecVUJNU+-VfsNVj00M=YVmw@mail.gmail.com>
	<CAC6JZKTZA_9uC6WOspcuHyoCtSqGRnWB-gwLYtr8aGJPNCR1qw@mail.gmail.com>
	<52F42947.1010107@umn.edu>
	<CAAAwwbU1tLcdzxFbOZKo4j+m8rvTTZfwWxEYZ-7k-NTwd=ErBQ@mail.gmail.com>
Message-ID: <CA+uaoiWfjg5oMLvFh6XQX3Fh+_t3-hrkS9meG+JK1eiGFJpz7w@mail.gmail.com>

Hi
I am clear on what you are saying sir, and in 95% or more of the ARIN
region, I do not see any issues, but we have either an ixp with two
participants or you are designated an private & ISP...
I am suggesting that the stated potential for abuse of the "two" rule may
also be present in the three rule where the three rule can conceivably be
used to withhold support in some small developing states for sake of some
commercial competitive advantage.
Granted North America is looking towards a significant increase of ixp
s...so too are non North American ARIN countries who are still on a steep
deployment learning curve.

The burden may not be obscenely high, OK, but the focus for change  to 3
has been set @"potential for abuse", and the scarcity of resources;
however, currently,
 "This policy does not preclude exchange point operators from requesting
address space under other policies."
Rudi Daniel
(information technologist)
784 430 9235
On Thu, Feb 6, 2014 at 6:31 PM, David Farmer <farmer at umn.edu> wrote:

> There seems to be a clear potential for abuse of the two participant rule
> after run-out of the general ARIN IPv4 free pool.  Also, there seems to be
> a clear potential that changing to three participants will make it more
> difficult for some IXPs to get going.
>

Agreed, and I would favor the 3 participant rule against the 2 participant
rule.   It would be hard indeed, to start an Exchange later; if all the
reserved resources were allocated to  2-participant "exchanges".
The burden should not be obscenely high, for a new Exchange to sign up at
least 3 participants.

As I see it:  ARIN's job after exhaustion, is to try to allocate IP address
resources required today,  not to facilitate the anticipated expansion via
IXPs  that would today be just expensive two-member peering arrangements
structured as a 2 member IXP in order to qualify for some extra /22 or so.


My other observation is:   An Exchange with only two current participants
is not really an Exchange,  but a private peering -- regardless of the
theory of possible additional participants in the future.

While it is ARIN policy not to recover addresses solely due to lack of use,
 PERHAPS   it should be different for IXP  and critical
infrastructure/immediate need  microallocations  under 4.4,   or 4.10.

E.g.   Required notification when the number of verifiable
actively-interconnected Exchange participants drops below 2,

Or, when some or all of the microallocation is no longer being used in the
manner that justified its allocation for Critical Infrastructure:

With possible  required return and renumber requirement  solely due to
non-use.


Thanks.
>
--
-JH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140207/f8461986/attachment.htm>

From mueller at syr.edu  Fri Feb  7 16:34:56 2014
From: mueller at syr.edu (Milton L Mueller)
Date: Fri, 7 Feb 2014 21:34:56 +0000
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <0a573e7e5ec24a34bba99c20501e6e5f@DM2PR03MB398.namprd03.prod.outlook.com>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>
	<0a573e7e5ec24a34bba99c20501e6e5f@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <2fb97b02499741889d0b96fb40586780@EX13-MBX-13.ad.syr.edu>

David,

>Thank you, Milton, for bringing this thread up.

Likewise, happy to see you commenting on this draft policy. 

While couched as opposition your post agrees with the problem statement that "Earlier work on this issue has explored several options to restrict or otherwise limit out of region use. None of these options have gained consensus within the community." So there is no basis for opposition there. 

I would conclude, however, that you do _not_ agree with the problem statement that "Current policy neither clearly forbids nor clearly permits out of region use of ARIN registered resources." You seem to believe that it is already permitted, which makes the proposal a no-op. Is that right?

>I want NRPM to be brief, concise, and prescriptive.  
>"You qualify by doing X.  You don't qualify because of Y. You must show A, B, C." 

In my view, the key sections of 2014-1 meet those criteria. Section X says "ARIN registered resources may be used outside the ARIN service region and such use is valid justification for additional resources." Sections X.2, X.3 and X.4 establish clear, unambigious definitions of what is not considered to be out of region use for the purposes of the policy. 

Your second argument is that the staff already has all the tools it needs to do what is in section X.1. This is not something the staff report said to us in its assessment, however, so I would discount that. 

You main argument, therefore is that "out-of-region requestors [are] abusing the policies" and  "we need to draft text that significantly and materially helps ARIN staff fight fraud from out-of-region requestors." Apparently you think the authorization to engage external entities to help with verification does not address that. Can you explain why? 




From bill at herrin.us  Fri Feb  7 17:49:08 2014
From: bill at herrin.us (William Herrin)
Date: Fri, 7 Feb 2014 17:49:08 -0500
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>
Message-ID: <CAP-guGWz6R8d1qM3B_eP1Ned9DVQC0XWtSht8VFZ3hWeZt6NAA@mail.gmail.com>

On Thu, Feb 6, 2014 at 9:41 AM, Milton L Mueller <mueller at syr.edu> wrote:
> Draft policy 2014-1 attempts to solve a problem left over from last year.

Howdy,

As I understood the staff problem, it was that out-region
organizations were creating in-region straw-man companies to register
addresses for use outside the region. During the discussion this
turned in to a more general referendum on whether ARIN should be
supplying addresses to the world or just to its region.

If I had my druthers, the policy would be simply this:

"ARIN prohibits any use of ARIN-assigned number resources which is:
(A) wholly and unambiguously within another RIR's region and
(B) more than incidental to an ARIN-region infrastructure."

It's concise, it's clean, and it says everything that should be said
on the subject.


I don't know if it's wise or unwise to have REGIONAL internet
registries, but so long as we do I think it inappropriate for one
region to UNILATERALLY serve as a registry to the world.


For better or for worse, I was shouted down. Many of the voting folks
here have broadly deployed ARIN addresses throughout their
multinational infrastructure and don't care to be scolded for it.
Others have used straw man companies in their own operations to
overcome the intersection of their internal bureaucracy and the arcane
strictures of the NRPM. They'd just as soon not have ARIN staff look
any closer. And let's not forget that a goodly fraction of the folks
who show up at ARIN meetings primarily represent out-region interests
in the first place.

What really gets my goat is the rationalizations I've seen put forth
for why so-and-so's out-region use is legit. Waah. I can't possibly
make my allocation pools match my customers' installation addresses.
Waah. I don't want to have to deal with RIPE for my European
infrastructure. Boo frickin' hoo. Man up and admit that the reason you
don't want this policy is that you've knowingly been doing things
wrong for the last decade plus, and you don't want to have to change.

Once you've admitted it, add another sentence to the brief suggested policy:

"ARIN number resources in use outside the region upon enaction of this
policy are grandfathered until recovered from their then-current
assignment."

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 bill at herrin.us  Fri Feb  7 19:01:10 2014
From: bill at herrin.us (William Herrin)
Date: Fri, 7 Feb 2014 19:01:10 -0500
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <CAMApp35yEX=rqaz1uVEy6E1KdZSfQcF9tNypXj3DzNRE10cpmA@mail.gmail.com>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>
	<CAP-guGWz6R8d1qM3B_eP1Ned9DVQC0XWtSht8VFZ3hWeZt6NAA@mail.gmail.com>
	<CAMApp35yEX=rqaz1uVEy6E1KdZSfQcF9tNypXj3DzNRE10cpmA@mail.gmail.com>
Message-ID: <CAP-guGX9sft2hVj10DRt5c7bQn8hEDa_PGGPErAnUAmurSs4NQ@mail.gmail.com>

On Fri, Feb 7, 2014 at 6:08 PM, Bill Darte <billdarte at gmail.com> wrote:
> Bill said..."ARIN prohibits any use of ARIN-assigned number resources which
> is:
>
> (A) wholly and unambiguously within another RIR's region and
> (B) more than incidental to an ARIN-region infrastructure."
>
> I think much of our earlier (and unsuccessful) effort was to codify what
> 'incidental' meant and a metric which was suitable for recognizing the
> threshold....

Hi Bill,

Incidental means... incidental. Small. A minor or negligible part of
the whole. The plain English understanding is satisfactory; it doesn't
need to be further codified.

If there's any realistic doubt as to whether a registrant's total
out-region use of ARIN addresses is merely incidental to their
in-region infrastructure then it almost certainly is incidental. This
is consistent with how ARIN staff interpret the rest of the NRPM. And
if you're not sure whether your use is incidental, it's an excellent
time to move to the near side of the gray zone.

The debate to define "incidental" was unsuccessful because it was
absurd. I was flabbergasted by the suggestion that an 80% out-region
use ("plurality" in region) could be merely incidental. That anyone
could advance such a notion beggars belief.

Also, bear in mind that "incidental" is part B. Part A lets you put
addresses on your ptp link from Seattle to Tokyo. It lets you put
addresses on the cruise ship. It lets you put addresses on that LEO
satellite orbiting every two hours. You don't fall in to part B until
your 10,000 employee US-based company wants to network its 50-person
offices in Tokyo, Paris and Cairo. Or the thousand-person office in
London to which ARIN should say, "Whoa! Time you talked to RIPE."

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From farmer at umn.edu  Fri Feb  7 19:40:11 2014
From: farmer at umn.edu (David Farmer)
Date: Fri, 07 Feb 2014 18:40:11 -0600
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <CAP-guGWz6R8d1qM3B_eP1Ned9DVQC0XWtSht8VFZ3hWeZt6NAA@mail.gmail.com>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>
	<CAP-guGWz6R8d1qM3B_eP1Ned9DVQC0XWtSht8VFZ3hWeZt6NAA@mail.gmail.com>
Message-ID: <52F57CEB.1040909@umn.edu>

On 2/7/14, 16:49 , William Herrin wrote:
> On Thu, Feb 6, 2014 at 9:41 AM, Milton L Mueller <mueller at syr.edu> wrote:
...

> If I had my druthers, the policy would be simply this:
>
> "ARIN prohibits any use of ARIN-assigned number resources which is:
> (A) wholly and unambiguously within another RIR's region and
> (B) more than incidental to an ARIN-region infrastructure."
>
> It's concise, it's clean, and it says everything that should be said
> on the subject.

Personally I'd be fine with this for IPv4, however this would put many 
currently operating networks in violation of policy.  How do you resolve 
that?  what about legacy space? Do you want them to transfer the 
resources they are currently using out of region to the other RIRs as 
appropriate?  Then we will run into the issues surrounding ARIN-2014-2.

Now IPv6, this means multinational companies will need separate 
allocations from each RIR that they function within that RIR's region. 
It will be common for most multinational companies to need 3 or 4 
separate allocations then, that will bloat the IPv6 route table.  In 
IPv6 we are trying to minimize the number of non-aggregatable prefixes 
allocated, that is why we are doing sparse allocation for IPv6.

I suppose, you could allow big allocation from one RIR, and then hove 
them transfer part to the other RIRs, but if you do that why not just 
allow it to be registered at the allocating RIR and be done with it.

It's a nice simple statement, but it doesn't work.

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


From mysidia at gmail.com  Fri Feb  7 19:46:40 2014
From: mysidia at gmail.com (Jimmy Hess)
Date: Fri, 7 Feb 2014 18:46:40 -0600
Subject: [arin-ppml] Draft Policy ARIN-2014-3: Remove 8.2 and 8.3 and
 8.4 Minimum IPv4 Block Size Requirements
In-Reply-To: <52E91DAA.9090307@arin.net>
References: <52E91DAA.9090307@arin.net>
Message-ID: <CAAAwwbVvALyX=pQq0vVMg2TmvZKC+PDTbU+S4ZH+HJEkSWy4EQ@mail.gmail.com>

On Wed, Jan 29, 2014 at 9:26 AM, ARIN <info at arin.net> wrote:

> On 24 January 2014 the ARIN Advisory Council (AC) accepted "ARIN-prop-195
> Remove 8.2 and 8.3 and 8.4 Minimum IPv4 Block Size Requirements" as a Draft
> Policy.
>

I oppose prop 195 as written,  because  (1) it is unnecessary.

(2) This is yet another IPv4-focused policy.   At this point, ARIN should
be essentially looking at IPv6 policies policies only,  and not make
changes that could adversly further affect IPv4 runout in problematic ways.

(3) Free pools are not yet exhausted,  so interest in 8.3 transfers cannot
yet be regarded or observed in any terms ---  let alone to show that
 "available /24s and longer" are inadequate,

(4) IPv6 is likely to be adopted more heavily,  obviating the usefulness of
any attempts to increase the number of  resource transfers occuring.

(5) Prefixes of /24 and larger will most likely be available over specified
transfer,
and  (4)  Allowing attempts to fragment /24s in IPv4  do not significantly
delay exhaustion of IPv4, but instead is a potential source of a great deal
of pain.

(6)
 Disagree with   "allowing networks to move blocks around as they see fit".
   The manner "in which some networks see fit"  is not necessarily a good
thing  for the level of global routing table bloat.

(7)
A problem is:  as long as routes for these prefixes would hypothetically be
accepted,
the networks who "see fit to move smaller blocks around and fragment /24s
into small chunks  to sell off IP by IP"  are not bearing the cost of their
actions ---  other ARIN members would be  essentially  forced  to bear
costs.

Ultimately resulting in greater unpredictability, whether a prefix received
by allocation or transfer could successfully be routed globally.

Lack of a minimum would potentially see some networks splitting off large
numbers of "surplus"  /25 or /26 prefixes,   and  some small networks
accreting 3 or 4  of these  transfer blocks over a small timeframe,  rather
than a slightly higher costing /24;   thereby, increasing global routing
table fragmentation.

(8)
And I would say that at this point, the /24  minimum is not an arbitrary
minimum.
By de-facto standard,  no longer prefix is permissible  to be announced.



>
> Policy statement:
> Remove all instances in 8.2, 8.3, and 8.4 which set a minimum transfer
> size of a /24.
>
-- 
-JH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140207/c62f5241/attachment.htm>

From bill at herrin.us  Fri Feb  7 19:18:50 2014
From: bill at herrin.us (William Herrin)
Date: Fri, 7 Feb 2014 19:18:50 -0500
Subject: [arin-ppml] ARIN-PPML 2014-7
In-Reply-To: <52F42947.1010107@umn.edu>
References: <CA+uaoiVOKrtby=myXRNBCmxn++c+56a7rmjOxmMmB3RAJW22qQ@mail.gmail.com>
	<CAP-guGXYMHqy-pMmWYR=KhcyhxCizGdyMxzw6CnZ0PKVtP6VJg@mail.gmail.com>
	<CA+uaoiUQYUfGRRw7mWR57AHbm5hF3MKgwzZQDKP4ACc0xmcfoA@mail.gmail.com>
	<CA+uaoiU_tUFBShi5TTa8R2wevUjUiwpEKR=r_1=BK1L3o4Vz4Q@mail.gmail.com>
	<CAMDXq5O+iqWtdpzSZqMc=At7M=PecVUJNU+-VfsNVj00M=YVmw@mail.gmail.com>
	<CAC6JZKTZA_9uC6WOspcuHyoCtSqGRnWB-gwLYtr8aGJPNCR1qw@mail.gmail.com>
	<52F42947.1010107@umn.edu>
Message-ID: <CAP-guGUb2oQVxAt3KBW7aDNuB38c3bUCgFYaHUcJeiNRaX1XCg@mail.gmail.com>

On Thu, Feb 6, 2014 at 7:31 PM, David Farmer <farmer at umn.edu> wrote:
> So, there is no
> way to decide this one based on real evidence, and it is hyperbole to even
> ask for such evidence from either side.

Agreed.

> If there are arguments for or
> against that haven't been provided, please provide them for the rest of
> community to consider.

Simply this: given the address shortage, I propose that requests to
suspend or reduce the everyday rules for minimum use of the assigned
block(s) be met with a simple test: is this something which would work
today with PA addresses and you can trivially renumber when you grow?

Web servers are hard to renumber. It takes a long time for all the
open web browsers to get the message. Mail servers are hard to
renumber. When they suddenly appear on a new address, all manner of
spam filtering issues pop up.

Two or three or even five BGP peers are NOT hard to renumber. Only the
other peers care and you can easilyuse old and new addresses
simultaneously during transition. Use a /29 from one of the
participants and pay ARIN a visit when it's full.

It's not abuse I'm worried about. Abusers will coax the documentation
to say what ARIN expects to hear. And if busted for fraud they'll get
what's coming to them. My issue is with the unrecoverable addresses
when the perfectly honest "IXP" fails to grow from two participants.

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 mysidia at gmail.com  Fri Feb  7 20:13:00 2014
From: mysidia at gmail.com (Jimmy Hess)
Date: Fri, 7 Feb 2014 19:13:00 -0600
Subject: [arin-ppml] ARIN-PPML 2014-7
In-Reply-To: <CAP-guGUb2oQVxAt3KBW7aDNuB38c3bUCgFYaHUcJeiNRaX1XCg@mail.gmail.com>
References: <CA+uaoiVOKrtby=myXRNBCmxn++c+56a7rmjOxmMmB3RAJW22qQ@mail.gmail.com>
	<CAP-guGXYMHqy-pMmWYR=KhcyhxCizGdyMxzw6CnZ0PKVtP6VJg@mail.gmail.com>
	<CA+uaoiUQYUfGRRw7mWR57AHbm5hF3MKgwzZQDKP4ACc0xmcfoA@mail.gmail.com>
	<CA+uaoiU_tUFBShi5TTa8R2wevUjUiwpEKR=r_1=BK1L3o4Vz4Q@mail.gmail.com>
	<CAMDXq5O+iqWtdpzSZqMc=At7M=PecVUJNU+-VfsNVj00M=YVmw@mail.gmail.com>
	<CAC6JZKTZA_9uC6WOspcuHyoCtSqGRnWB-gwLYtr8aGJPNCR1qw@mail.gmail.com>
	<52F42947.1010107@umn.edu>
	<CAP-guGUb2oQVxAt3KBW7aDNuB38c3bUCgFYaHUcJeiNRaX1XCg@mail.gmail.com>
Message-ID: <CAAAwwbV5SOEmTHm5SZw2LNJMQuc7OYtEuDFO3RrJeW-dyK4Qcw@mail.gmail.com>

On Fri, Feb 7, 2014 at 6:18 PM, William Herrin <bill at herrin.us> wrote:
[snip]

Agreed.   Also agree that IXPs with only a handful of participants are a
very easy low-cost renumbering scenario.
Why should the bar be as low as two or 3 participants?

Why not make the required number  at least 9 or 10 participants minimum,
 with actual documentation for 4 or 5,  before a whole /24 is warranted?


It's not abuse I'm worried about. Abusers will coax the documentation
> to say what ARIN expects to hear. And if busted for fraud they'll get
> what's coming to them. My issue is with the unrecoverable addresses
> when the perfectly honest "IXP" fails to grow from two participants.
>
> Regards,
> Bill Herrin
>

--
-JH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140207/9468b4dd/attachment.htm>

From billdarte at gmail.com  Fri Feb  7 18:08:58 2014
From: billdarte at gmail.com (Bill Darte)
Date: Fri, 7 Feb 2014 17:08:58 -0600
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <CAP-guGWz6R8d1qM3B_eP1Ned9DVQC0XWtSht8VFZ3hWeZt6NAA@mail.gmail.com>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>
	<CAP-guGWz6R8d1qM3B_eP1Ned9DVQC0XWtSht8VFZ3hWeZt6NAA@mail.gmail.com>
Message-ID: <CAMApp35yEX=rqaz1uVEy6E1KdZSfQcF9tNypXj3DzNRE10cpmA@mail.gmail.com>

Bill said..."ARIN prohibits any use of ARIN-assigned number resources which
is:
(A) wholly and unambiguously within another RIR's region and
(B) more than incidental to an ARIN-region infrastructure."

I think much of our earlier (and unsuccessful) effort was to codify what
'incidental' meant and a metric which was suitable for recognizing the
threshold....

bd


On Fri, Feb 7, 2014 at 4:49 PM, William Herrin <bill at herrin.us> wrote:

> On Thu, Feb 6, 2014 at 9:41 AM, Milton L Mueller <mueller at syr.edu> wrote:
> > Draft policy 2014-1 attempts to solve a problem left over from last year.
>
> Howdy,
>
> As I understood the staff problem, it was that out-region
> organizations were creating in-region straw-man companies to register
> addresses for use outside the region. During the discussion this
> turned in to a more general referendum on whether ARIN should be
> supplying addresses to the world or just to its region.
>
> If I had my druthers, the policy would be simply this:
>
> "ARIN prohibits any use of ARIN-assigned number resources which is:
> (A) wholly and unambiguously within another RIR's region and
> (B) more than incidental to an ARIN-region infrastructure."
>
> It's concise, it's clean, and it says everything that should be said
> on the subject.
>
>
> I don't know if it's wise or unwise to have REGIONAL internet
> registries, but so long as we do I think it inappropriate for one
> region to UNILATERALLY serve as a registry to the world.
>
>
> For better or for worse, I was shouted down. Many of the voting folks
> here have broadly deployed ARIN addresses throughout their
> multinational infrastructure and don't care to be scolded for it.
> Others have used straw man companies in their own operations to
> overcome the intersection of their internal bureaucracy and the arcane
> strictures of the NRPM. They'd just as soon not have ARIN staff look
> any closer. And let's not forget that a goodly fraction of the folks
> who show up at ARIN meetings primarily represent out-region interests
> in the first place.
>
> What really gets my goat is the rationalizations I've seen put forth
> for why so-and-so's out-region use is legit. Waah. I can't possibly
> make my allocation pools match my customers' installation addresses.
> Waah. I don't want to have to deal with RIPE for my European
> infrastructure. Boo frickin' hoo. Man up and admit that the reason you
> don't want this policy is that you've knowingly been doing things
> wrong for the last decade plus, and you don't want to have to change.
>
> Once you've admitted it, add another sentence to the brief suggested
> policy:
>
> "ARIN number resources in use outside the region upon enaction of this
> policy are grandfathered until recovered from their then-current
> assignment."
>
> 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
> _______________________________________________
> 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/20140207/6ba6b2b9/attachment.htm>

From bill at herrin.us  Fri Feb  7 23:58:26 2014
From: bill at herrin.us (William Herrin)
Date: Fri, 7 Feb 2014 23:58:26 -0500
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <52F57CEB.1040909@umn.edu>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>
	<CAP-guGWz6R8d1qM3B_eP1Ned9DVQC0XWtSht8VFZ3hWeZt6NAA@mail.gmail.com>
	<52F57CEB.1040909@umn.edu>
Message-ID: <CAP-guGWDH7i5MpjoDApqedwCitKRFGnD+-dtAoYPQF+e2wU7Ng@mail.gmail.com>

On Fri, Feb 7, 2014 at 7:40 PM, David Farmer <farmer at umn.edu> wrote:
> On 2/7/14, 16:49 , William Herrin wrote:
>> If I had my druthers, the policy would be simply this:
>>
>> "ARIN prohibits any use of ARIN-assigned number resources which is:
>> (A) wholly and unambiguously within another RIR's region and
>> (B) more than incidental to an ARIN-region infrastructure."
>>
>> It's concise, it's clean, and it says everything that should be said
>> on the subject.
>
>
> Personally I'd be fine with this for IPv4, however this would put many
> currently operating networks in violation of policy.  How do you resolve
> that?

Howdy,

You pulled a TLDR on me. Like I said at the end of the message: after
you admit that the reason you (the general you, not you specifically)
don't want this policy is that you've knowingly been doing things
wrong for the last decade plus, you add the following sentence to the
still concise policy.

"ARIN number resources in use outside the region upon enaction of this
policy are grandfathered until recovered from their then-current
assignment."


> Now IPv6, this means multinational companies will need separate allocations
> from each RIR that they function within that RIR's region. It will be common
> for most multinational companies to need 3 or 4 separate allocations then,
> that will bloat the IPv6 route table.  In IPv6 we are trying to minimize the
> number of non-aggregatable prefixes allocated, that is why we are doing
> sparse allocation for IPv6.

You make a good point. I'd be satisfied limiting it to "IPv4
addresses" instead of "number resources."

Will you be drafting a global policy to the effect that registrants
are encouraged to get their entire IPv6 allocation from their single
home registry? Once again, it isn't appropriate for a regional
registry to act unilaterally in this regard.

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 bill at herrin.us  Sat Feb  8 00:10:16 2014
From: bill at herrin.us (William Herrin)
Date: Sat, 8 Feb 2014 00:10:16 -0500
Subject: [arin-ppml] ARIN-PPML 2014-7
In-Reply-To: <CAAAwwbV5SOEmTHm5SZw2LNJMQuc7OYtEuDFO3RrJeW-dyK4Qcw@mail.gmail.com>
References: <CA+uaoiVOKrtby=myXRNBCmxn++c+56a7rmjOxmMmB3RAJW22qQ@mail.gmail.com>
	<CAP-guGXYMHqy-pMmWYR=KhcyhxCizGdyMxzw6CnZ0PKVtP6VJg@mail.gmail.com>
	<CA+uaoiUQYUfGRRw7mWR57AHbm5hF3MKgwzZQDKP4ACc0xmcfoA@mail.gmail.com>
	<CA+uaoiU_tUFBShi5TTa8R2wevUjUiwpEKR=r_1=BK1L3o4Vz4Q@mail.gmail.com>
	<CAMDXq5O+iqWtdpzSZqMc=At7M=PecVUJNU+-VfsNVj00M=YVmw@mail.gmail.com>
	<CAC6JZKTZA_9uC6WOspcuHyoCtSqGRnWB-gwLYtr8aGJPNCR1qw@mail.gmail.com>
	<52F42947.1010107@umn.edu>
	<CAP-guGUb2oQVxAt3KBW7aDNuB38c3bUCgFYaHUcJeiNRaX1XCg@mail.gmail.com>
	<CAAAwwbV5SOEmTHm5SZw2LNJMQuc7OYtEuDFO3RrJeW-dyK4Qcw@mail.gmail.com>
Message-ID: <CAP-guGWk8XoBocV9T7zrXjeArfiHN8VyX6CN2W5OUxZgCS1jaQ@mail.gmail.com>

On Fri, Feb 7, 2014 at 8:13 PM, Jimmy Hess <mysidia at gmail.com> wrote:
> Agreed.   Also agree that IXPs with only a handful of participants are a
> very easy low-cost renumbering scenario.
> Why should the bar be as low as two or 3 participants?
>
> Why not make the required number  at least 9 or 10 participants minimum,
> with actual documentation for 4 or 5,  before a whole /24 is warranted?

Hi Jimmy,

Personally, I like the number 5. Here's why:

A) I've participated in a couple of IXPs that were more wishful
thinking than reality. By the time an IXP has 5 participants, it's no
longer wishful thinking. I'm no longer concerned that it may fail to
grow, stranding a bunch of otherwise usable addresses.

B) 5 participants plus the IXP's route server fits just so into a /29

C) When it comes time to renumber, the more participants involved, the
more of a PITA it becomes. A handful is not too bad, but coordinating
the action of a dozen folks starts to get messy.

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 george.herbert at gmail.com  Sat Feb  8 00:22:55 2014
From: george.herbert at gmail.com (George Herbert)
Date: Fri, 7 Feb 2014 21:22:55 -0800
Subject: [arin-ppml] ARIN-PPML 2014-7
In-Reply-To: <CAP-guGWk8XoBocV9T7zrXjeArfiHN8VyX6CN2W5OUxZgCS1jaQ@mail.gmail.com>
References: <CA+uaoiVOKrtby=myXRNBCmxn++c+56a7rmjOxmMmB3RAJW22qQ@mail.gmail.com>
	<CAP-guGXYMHqy-pMmWYR=KhcyhxCizGdyMxzw6CnZ0PKVtP6VJg@mail.gmail.com>
	<CA+uaoiUQYUfGRRw7mWR57AHbm5hF3MKgwzZQDKP4ACc0xmcfoA@mail.gmail.com>
	<CA+uaoiU_tUFBShi5TTa8R2wevUjUiwpEKR=r_1=BK1L3o4Vz4Q@mail.gmail.com>
	<CAMDXq5O+iqWtdpzSZqMc=At7M=PecVUJNU+-VfsNVj00M=YVmw@mail.gmail.com>
	<CAC6JZKTZA_9uC6WOspcuHyoCtSqGRnWB-gwLYtr8aGJPNCR1qw@mail.gmail.com>
	<52F42947.1010107@umn.edu>
	<CAP-guGUb2oQVxAt3KBW7aDNuB38c3bUCgFYaHUcJeiNRaX1XCg@mail.gmail.com>
	<CAAAwwbV5SOEmTHm5SZw2LNJMQuc7OYtEuDFO3RrJeW-dyK4Qcw@mail.gmail.com>
	<CAP-guGWk8XoBocV9T7zrXjeArfiHN8VyX6CN2W5OUxZgCS1jaQ@mail.gmail.com>
Message-ID: <CAK__Kzt531FeKNErzt7dSvRKmjkVT6tUXZ=y+K8ckU7ykNFq-Q@mail.gmail.com>

This is approaching a Shrubbery.

I oppose 2014-7; no clear need has been documented for any change, and the
discussion is clearly demonstrating the risks in trying to overthink where
we draw lines like this.


On Fri, Feb 7, 2014 at 9:10 PM, William Herrin <bill at herrin.us> wrote:

> On Fri, Feb 7, 2014 at 8:13 PM, Jimmy Hess <mysidia at gmail.com> wrote:
> > Agreed.   Also agree that IXPs with only a handful of participants are a
> > very easy low-cost renumbering scenario.
> > Why should the bar be as low as two or 3 participants?
> >
> > Why not make the required number  at least 9 or 10 participants minimum,
> > with actual documentation for 4 or 5,  before a whole /24 is warranted?
>
> Hi Jimmy,
>
> Personally, I like the number 5. Here's why:
>
> A) I've participated in a couple of IXPs that were more wishful
> thinking than reality. By the time an IXP has 5 participants, it's no
> longer wishful thinking. I'm no longer concerned that it may fail to
> grow, stranding a bunch of otherwise usable addresses.
>
> B) 5 participants plus the IXP's route server fits just so into a /29
>
> C) When it comes time to renumber, the more participants involved, the
> more of a PITA it becomes. A handful is not too bad, but coordinating
> the action of a dozen folks starts to get messy.
>
> 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
> _______________________________________________
> 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.
>



-- 
-george william herbert
george.herbert at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140207/16d96d99/attachment.htm>

From hannigan at gmail.com  Fri Feb  7 21:07:53 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Fri, 7 Feb 2014 21:07:53 -0500
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy Internet Resource
	Holders
Message-ID: <CAMDXq5Ng_r7QoYo45-rREHKCUbmQMDxyEmbYJWCMGqpQZ35=1w@mail.gmail.com>

RIPE-605 is now policy in the RIPE region.

1. Provides registry services to legacy holders without contractual
requirement

2. Excludes legacy holders from RIPE policy purview, past-present-future

3. Can revert a legacy block under contract back to a non-contract state

4. Reversion concept = "real property"

This is certainly one way to insure an accurate registry.

See RIPE-605 here: http://bit.ly/MzbmZ1

Best,

-M<
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140207/ce957ad7/attachment.htm>

From jeffrey.lyon at blacklotus.net  Sat Feb  8 03:11:46 2014
From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon)
Date: Sat, 8 Feb 2014 17:11:46 +0900
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <CAP-guGWDH7i5MpjoDApqedwCitKRFGnD+-dtAoYPQF+e2wU7Ng@mail.gmail.com>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>
	<CAP-guGWz6R8d1qM3B_eP1Ned9DVQC0XWtSht8VFZ3hWeZt6NAA@mail.gmail.com>
	<52F57CEB.1040909@umn.edu>
	<CAP-guGWDH7i5MpjoDApqedwCitKRFGnD+-dtAoYPQF+e2wU7Ng@mail.gmail.com>
Message-ID: <CACrmG8fvLSt482B3joL2+CZT4L9FFuVzfy59+_gchXmds6VScQ@mail.gmail.com>

I recently had to submit two requests, one to ARIN and one to RIPE
because of an expansion that involved an Amsterdam POP. It would have
been really nice to be able to just break off a /22 or /23 for that
location and not have to deal with RIPE.

Thanks, Jeff

On Sat, Feb 8, 2014 at 1:58 PM, William Herrin <bill at herrin.us> wrote:
> On Fri, Feb 7, 2014 at 7:40 PM, David Farmer <farmer at umn.edu> wrote:
>> On 2/7/14, 16:49 , William Herrin wrote:
>>> If I had my druthers, the policy would be simply this:
>>>
>>> "ARIN prohibits any use of ARIN-assigned number resources which is:
>>> (A) wholly and unambiguously within another RIR's region and
>>> (B) more than incidental to an ARIN-region infrastructure."
>>>
>>> It's concise, it's clean, and it says everything that should be said
>>> on the subject.
>>
>>
>> Personally I'd be fine with this for IPv4, however this would put many
>> currently operating networks in violation of policy.  How do you resolve
>> that?
>
> Howdy,
>
> You pulled a TLDR on me. Like I said at the end of the message: after
> you admit that the reason you (the general you, not you specifically)
> don't want this policy is that you've knowingly been doing things
> wrong for the last decade plus, you add the following sentence to the
> still concise policy.
>
> "ARIN number resources in use outside the region upon enaction of this
> policy are grandfathered until recovered from their then-current
> assignment."
>
>
>> Now IPv6, this means multinational companies will need separate allocations
>> from each RIR that they function within that RIR's region. It will be common
>> for most multinational companies to need 3 or 4 separate allocations then,
>> that will bloat the IPv6 route table.  In IPv6 we are trying to minimize the
>> number of non-aggregatable prefixes allocated, that is why we are doing
>> sparse allocation for IPv6.
>
> You make a good point. I'd be satisfied limiting it to "IPv4
> addresses" instead of "number resources."
>
> Will you be drafting a global policy to the effect that registrants
> are encouraged to get their entire IPv6 allocation from their single
> home registry? Once again, it isn't appropriate for a regional
> registry to act unilaterally in this regard.
>
> 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
> _______________________________________________
> 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 A. Lyon, CISSP-ISSMP
Founder, Black Lotus Communications
mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net


From hannigan at gmail.com  Sat Feb  8 01:17:06 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Sat, 8 Feb 2014 01:17:06 -0500
Subject: [arin-ppml] ARIN-PPML 2014-7
In-Reply-To: <CAK__Kzt531FeKNErzt7dSvRKmjkVT6tUXZ=y+K8ckU7ykNFq-Q@mail.gmail.com>
References: <CA+uaoiVOKrtby=myXRNBCmxn++c+56a7rmjOxmMmB3RAJW22qQ@mail.gmail.com>
	<CAP-guGXYMHqy-pMmWYR=KhcyhxCizGdyMxzw6CnZ0PKVtP6VJg@mail.gmail.com>
	<CA+uaoiUQYUfGRRw7mWR57AHbm5hF3MKgwzZQDKP4ACc0xmcfoA@mail.gmail.com>
	<CA+uaoiU_tUFBShi5TTa8R2wevUjUiwpEKR=r_1=BK1L3o4Vz4Q@mail.gmail.com>
	<CAMDXq5O+iqWtdpzSZqMc=At7M=PecVUJNU+-VfsNVj00M=YVmw@mail.gmail.com>
	<CAC6JZKTZA_9uC6WOspcuHyoCtSqGRnWB-gwLYtr8aGJPNCR1qw@mail.gmail.com>
	<52F42947.1010107@umn.edu>
	<CAP-guGUb2oQVxAt3KBW7aDNuB38c3bUCgFYaHUcJeiNRaX1XCg@mail.gmail.com>
	<CAAAwwbV5SOEmTHm5SZw2LNJMQuc7OYtEuDFO3RrJeW-dyK4Qcw@mail.gmail.com>
	<CAP-guGWk8XoBocV9T7zrXjeArfiHN8VyX6CN2W5OUxZgCS1jaQ@mail.gmail.com>
	<CAK__Kzt531FeKNErzt7dSvRKmjkVT6tUXZ=y+K8ckU7ykNFq-Q@mail.gmail.com>
Message-ID: <CAMDXq5OFsMs9SvKUjSLW+d+RbVpu71vayxgKmYab3ZJL8LVPkA@mail.gmail.com>

Not really. It's a simple proposal being under thought to some extent as
well. I suggested we up the number of participants, nothing more. The rest
of the discussion is interesting, but not relevant to the proposal itself.

One alternative is an update to Section 12 and a mandate that ARIN audit
IXP's after 1 year (and audit all of them now) and if found to still have
only two participants, revoke their leased resources. Much easier to start
out with a point to point and an easy renumbering into shot at success.
Otherwise, we're building petri dishes to watch spam and viruses swap back
and forth, wasting number resources and money; many of these ill fated
expeditions are tax payer funded.

See www.ix.pr


Best,

-M<




On Sat, Feb 8, 2014 at 12:22 AM, George Herbert <george.herbert at gmail.com>wrote:

> This is approaching a Shrubbery.
>
> I oppose 2014-7; no clear need has been documented for any change, and the
> discussion is clearly demonstrating the risks in trying to overthink where
> we draw lines like this.
>
>
> On Fri, Feb 7, 2014 at 9:10 PM, William Herrin <bill at herrin.us> wrote:
>
>> On Fri, Feb 7, 2014 at 8:13 PM, Jimmy Hess <mysidia at gmail.com> wrote:
>> > Agreed.   Also agree that IXPs with only a handful of participants are a
>> > very easy low-cost renumbering scenario.
>> > Why should the bar be as low as two or 3 participants?
>> >
>> > Why not make the required number  at least 9 or 10 participants minimum,
>> > with actual documentation for 4 or 5,  before a whole /24 is warranted?
>>
>> Hi Jimmy,
>>
>> Personally, I like the number 5. Here's why:
>>
>> A) I've participated in a couple of IXPs that were more wishful
>> thinking than reality. By the time an IXP has 5 participants, it's no
>> longer wishful thinking. I'm no longer concerned that it may fail to
>> grow, stranding a bunch of otherwise usable addresses.
>>
>> B) 5 participants plus the IXP's route server fits just so into a /29
>>
>> C) When it comes time to renumber, the more participants involved, the
>> more of a PITA it becomes. A handful is not too bad, but coordinating
>> the action of a dozen folks starts to get messy.
>>
>> 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
>> _______________________________________________
>> 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.
>>
>
>
>
> --
> -george william herbert
> george.herbert at gmail.com
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140208/d98a3c9a/attachment.htm>

From bill at herrin.us  Sat Feb  8 09:19:59 2014
From: bill at herrin.us (William Herrin)
Date: Sat, 8 Feb 2014 09:19:59 -0500
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <CACrmG8fvLSt482B3joL2+CZT4L9FFuVzfy59+_gchXmds6VScQ@mail.gmail.com>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>
	<CAP-guGWz6R8d1qM3B_eP1Ned9DVQC0XWtSht8VFZ3hWeZt6NAA@mail.gmail.com>
	<52F57CEB.1040909@umn.edu>
	<CAP-guGWDH7i5MpjoDApqedwCitKRFGnD+-dtAoYPQF+e2wU7Ng@mail.gmail.com>
	<CACrmG8fvLSt482B3joL2+CZT4L9FFuVzfy59+_gchXmds6VScQ@mail.gmail.com>
Message-ID: <CAP-guGVu4FMJ=CJVS3WHe02nhCrm8+MqAU28boMJyn3Hx4s2xA@mail.gmail.com>

On Sat, Feb 8, 2014 at 3:11 AM, Jeffrey Lyon
<jeffrey.lyon at blacklotus.net> wrote:
> I recently had to submit two requests, one to ARIN and one to RIPE
> because of an expansion that involved an Amsterdam POP. It would have
> been really nice to be able to just break off a /22 or /23 for that
> location and not have to deal with RIPE.

Hi Jeffrey,

In the general sense, I'm fine with that approach. However, I'm very
much against ARIN pursuing it unilaterally and I'm very much against
registry shopping.

If we want to manage addresses this way, we should first endeavor to
pass a globally coordinated policy to the effect that multiregional
organizations should solicit the registry in their headquarters'
region for all registry-direct number resources rather than soliciting
the registry that serves the region where the resources are employed.

Regards,
Bill Herrin

-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From owen at delong.com  Sat Feb  8 22:40:10 2014
From: owen at delong.com (Owen DeLong)
Date: Sat, 8 Feb 2014 19:40:10 -0800
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy Internet
	Resource Holders
In-Reply-To: <CAMDXq5Ng_r7QoYo45-rREHKCUbmQMDxyEmbYJWCMGqpQZ35=1w@mail.gmail.com>
References: <CAMDXq5Ng_r7QoYo45-rREHKCUbmQMDxyEmbYJWCMGqpQZ35=1w@mail.gmail.com>
Message-ID: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>

I'm sure it insures something. I'm not sure an accurate registry is what it insures.

Owen

On Feb 7, 2014, at 18:07 , Martin Hannigan <hannigan at gmail.com> wrote:

> 
> RIPE-605 is now policy in the RIPE region.
> 
> 1. Provides registry services to legacy holders without contractual requirement
> 
> 2. Excludes legacy holders from RIPE policy purview, past-present-future
> 
> 3. Can revert a legacy block under contract back to a non-contract state 
> 
> 4. Reversion concept = "real property"
> 
> This is certainly one way to insure an accurate registry.
> 
> See RIPE-605 here: http://bit.ly/MzbmZ1
> 
> 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.

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

From mueller at syr.edu  Sun Feb  9 10:18:06 2014
From: mueller at syr.edu (Milton L Mueller)
Date: Sun, 9 Feb 2014 15:18:06 +0000
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <CAP-guGX9sft2hVj10DRt5c7bQn8hEDa_PGGPErAnUAmurSs4NQ@mail.gmail.com>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>
	<CAP-guGWz6R8d1qM3B_eP1Ned9DVQC0XWtSht8VFZ3hWeZt6NAA@mail.gmail.com>
	<CAMApp35yEX=rqaz1uVEy6E1KdZSfQcF9tNypXj3DzNRE10cpmA@mail.gmail.com>
	<CAP-guGX9sft2hVj10DRt5c7bQn8hEDa_PGGPErAnUAmurSs4NQ@mail.gmail.com>
Message-ID: <d9f49429488b4f5a97b180b699fb89d0@EX13-MBX-13.ad.syr.edu>

Bill, 
What's missing from your argument is a reason why regional exclusivity in the allocation of address blocks is a desirable thing. In other words, when you accuse trans-regional networks of "doing things wrong" I challenge you to support that charge with any basis in ARIN policy that makes what they were doing unambiguously wrong.  

Historically, RIRs were not created to enforce regional or territorial exclusivity on a huge number of interconnected networks that are often transregional. They were created to ease access to the allocation process and to facilitate local participation in policy making. If I am distributing widgets and I set up a regional distribution center in Northern Virginia and another in Syracuse, the purpose is to make it easier for people in NoVA and Syracuse to get addresses - NOT to prevent someone who has a network in both places or in other parts of the country from getting widgets from either place. 

To be sure, the creation of regional allocation structures creates selfish incentives on the part of certain people in regions who want to protect their access to resources to the exclusion of people in other regions who might need them as much or more, but I do not see any support for that incentive in either the letter or the spirit of ARIN policy. 

--MM

-----Original Message-----
From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of William Herrin
Sent: Friday, February 7, 2014 7:01 PM
To: Bill Darte
Cc: Milton L Mueller; ARIN PPML (ppml at arin.net)
Subject: Re: [arin-ppml] support for 2014-1 (out of region use)

On Fri, Feb 7, 2014 at 6:08 PM, Bill Darte <billdarte at gmail.com> wrote:
> Bill said..."ARIN prohibits any use of ARIN-assigned number resources 
> which
> is:
>
> (A) wholly and unambiguously within another RIR's region and
> (B) more than incidental to an ARIN-region infrastructure."
>
> I think much of our earlier (and unsuccessful) effort was to codify 
> what 'incidental' meant and a metric which was suitable for 
> recognizing the threshold....

Hi Bill,

Incidental means... incidental. Small. A minor or negligible part of the whole. The plain English understanding is satisfactory; it doesn't need to be further codified.

If there's any realistic doubt as to whether a registrant's total out-region use of ARIN addresses is merely incidental to their in-region infrastructure then it almost certainly is incidental. This is consistent with how ARIN staff interpret the rest of the NRPM. And if you're not sure whether your use is incidental, it's an excellent time to move to the near side of the gray zone.

The debate to define "incidental" was unsuccessful because it was absurd. I was flabbergasted by the suggestion that an 80% out-region use ("plurality" in region) could be merely incidental. That anyone could advance such a notion beggars belief.

Also, bear in mind that "incidental" is part B. Part A lets you put addresses on your ptp link from Seattle to Tokyo. It lets you put addresses on the cruise ship. It lets you put addresses on that LEO satellite orbiting every two hours. You don't fall in to part B until your 10,000 employee US-based company wants to network its 50-person offices in Tokyo, Paris and Cairo. Or the thousand-person office in London to which ARIN should say, "Whoa! Time you talked to RIPE."

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 jcurran at arin.net  Sun Feb  9 13:05:20 2014
From: jcurran at arin.net (John Curran)
Date: Sun, 9 Feb 2014 18:05:20 +0000
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <d9f49429488b4f5a97b180b699fb89d0@EX13-MBX-13.ad.syr.edu>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>
	<CAP-guGWz6R8d1qM3B_eP1Ned9DVQC0XWtSht8VFZ3hWeZt6NAA@mail.gmail.com>
	<CAMApp35yEX=rqaz1uVEy6E1KdZSfQcF9tNypXj3DzNRE10cpmA@mail.gmail.com>
	<CAP-guGX9sft2hVj10DRt5c7bQn8hEDa_PGGPErAnUAmurSs4NQ@mail.gmail.com>
	<d9f49429488b4f5a97b180b699fb89d0@EX13-MBX-13.ad.syr.edu>
Message-ID: <345D24FC-F3EC-47F4-8C95-E82426E32FD9@arin.net>

On Feb 9, 2014, at 10:18 AM, Milton L Mueller <mueller at syr.edu> wrote:

> Bill, 
> What's missing from your argument is a reason why regional exclusivity in the allocation of address blocks is a desirable thing. In other words, when you accuse trans-regional networks of "doing things wrong" I challenge you to support that charge with any basis in ARIN policy that makes what they were doing unambiguously wrong.  
> 
> Historically, RIRs were not created to enforce regional or territorial exclusivity on a huge number of interconnected networks that are often transregional. They were created to ease access to the allocation process and to facilitate local participation in policy making. 

That is correct.  Per RFC 7020 ("The Internet Numbers Registry System") - 

 "In order to promote distribution of the Internet number resource
  registration function, RFC 1366 proposed delegating responsibility
  to regional bodies.  (Note: RFC 1366 was replaced by RFC 1466,
  which was replaced by RFC 2050.)  These bodies became known as the
  Regional Internet Registries (RIRs)."

In fact, RFC 1366 was the implementation of an IAB/FNC policy change 
which is documented in RFC 1174, noting the need for international 
delegation of these functions to keep up with rapid growth -

  "With the rapid escalation of the number of networks in the Internet
   and its concurrent internationalization, it is timely to consider
   further delegation of assignment and registration authority on an
   international basis. "

FYI,
/John

John Curran
President and CEO
ARIN



From matthew at matthew.at  Sun Feb  9 14:07:49 2014
From: matthew at matthew.at (Matthew Kaufman)
Date: Sun, 09 Feb 2014 11:07:49 -0800
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <CAP-guGX9sft2hVj10DRt5c7bQn8hEDa_PGGPErAnUAmurSs4NQ@mail.gmail.com>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>	<CAP-guGWz6R8d1qM3B_eP1Ned9DVQC0XWtSht8VFZ3hWeZt6NAA@mail.gmail.com>	<CAMApp35yEX=rqaz1uVEy6E1KdZSfQcF9tNypXj3DzNRE10cpmA@mail.gmail.com>
	<CAP-guGX9sft2hVj10DRt5c7bQn8hEDa_PGGPErAnUAmurSs4NQ@mail.gmail.com>
Message-ID: <52F7D205.4010800@matthew.at>


On 2/7/14, 4:01 PM, William Herrin wrote:
> ...You don't fall in to part B until your 10,000 employee US-based 
> company wants to network its 50-person offices in Tokyo, Paris and 
> Cairo. Or the thousand-person office in London to which ARIN should 
> say, "Whoa! Time you talked to RIPE." Regards, Bill Herrin 

And if the 1000-person office in London has no local egress to the 
Internet and is instead getting all connectivity over the circuit they 
have going back to HQ in Virginia, the company in Virginia should be 
going to RIPE and getting a second block of address space (instead of 
using a larger aggregate that it received from ARIN that it can 
advertise as a single route) for the London office why, exactly?

It can't possibly be for some technical reason, and we know that the 
RIRs were set up to make things easier, not to hoard addresses within 
certain regions, so what is it that makes going to RIPE the right answer 
in this case?

Matthew Kaufman


From hannigan at gmail.com  Sun Feb  9 21:44:50 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Sun, 9 Feb 2014 21:44:50 -0500
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy Internet
	Resource Holders
In-Reply-To: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
References: <CAMDXq5Ng_r7QoYo45-rREHKCUbmQMDxyEmbYJWCMGqpQZ35=1w@mail.gmail.com>
	<AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
Message-ID: <CAMDXq5Ma1Hq0YOVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com>

What's next? RIR competition? :-)

On Saturday, February 8, 2014, Owen DeLong <owen at delong.com> wrote:

> I'm sure it insures something. I'm not sure an accurate registry is what
> it insures.
>
> Owen
>
> On Feb 7, 2014, at 18:07 , Martin Hannigan <hannigan at gmail.com<javascript:_e(%7B%7D,'cvml','hannigan at gmail.com');>>
> wrote:
>
>
> RIPE-605 is now policy in the RIPE region.
>
> 1. Provides registry services to legacy holders without contractual
> requirement
>
> 2. Excludes legacy holders from RIPE policy purview, past-present-future
>
> 3. Can revert a legacy block under contract back to a non-contract state
>
> 4. Reversion concept = "real property"
>
> This is certainly one way to insure an accurate registry.
>
> See RIPE-605 here: http://bit.ly/MzbmZ1
>
> Best,
>
> -M<
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<javascript:_e(%7B%7D,'cvml','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<javascript:_e(%7B%7D,'cvml','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/20140209/aace384c/attachment.htm>

From SRyerse at eclipse-networks.com  Sun Feb  9 23:00:19 2014
From: SRyerse at eclipse-networks.com (Steven Ryerse)
Date: Mon, 10 Feb 2014 04:00:19 +0000
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy
	InternetResource	 Holders
In-Reply-To: <CAMDXq5Ma1Hq0YOVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com>
References: <CAMDXq5Ng_r7QoYo45-rREHKCUbmQMDxyEmbYJWCMGqpQZ35=1w@mail.gmail.
	com><AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
	<CAMDXq5Ma1Hq0YOVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com>
Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com>

My Opinion:  I think their policy acknowledges reality and embraces it!  Their policy obviously PROMOTES the Internet which is what the RIRs were created to do in the first place.  It is time for the ARIN community to do something similar, and it is time for removing all of the needs testing to qualify for ARIN resources - as needs testing does the exact OPPOSITE of PROMOTING the Internet.

Steven Ryerse
President
100 Ashford Center North, Suite 110, Atlanta, GA  30338
www.eclipse-networks.com
770.656.1460 - Cell
770.399.9099- Office

[Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc.
        Conquering Complex Networks?

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Martin Hannigan
Sent: Sunday, February 09, 2014 9:45 PM
To: Owen DeLong
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] FYI -- RIPE-605 Services to Legacy InternetResource Holders

What's next? RIR competition? :-)

On Saturday, February 8, 2014, Owen DeLong <owen at delong.com<mailto:owen at delong.com>> wrote:
I'm sure it insures something. I'm not sure an accurate registry is what it insures.

Owen

On Feb 7, 2014, at 18:07 , Martin Hannigan <hannigan at gmail.com<javascript:_e(%7B%7D,'cvml','hannigan at gmail.com');>> wrote:



RIPE-605 is now policy in the RIPE region.
1. Provides registry services to legacy holders without contractual requirement
2. Excludes legacy holders from RIPE policy purview, past-present-future
3. Can revert a legacy block under contract back to a non-contract state
4. Reversion concept = "real property"
This is certainly one way to insure an accurate registry.
See RIPE-605 here: http://bit.ly/MzbmZ1
Best,
-M<
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<javascript:_e(%7B%7D,'cvml','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<javascript:_e(%7B%7D,'cvml','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/20140210/2a171a16/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 1468 bytes
Desc: image001.jpg
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140210/2a171a16/attachment.jpg>

From matthew at matthew.at  Sun Feb  9 23:04:14 2014
From: matthew at matthew.at (Matthew Kaufman)
Date: Sun, 09 Feb 2014 20:04:14 -0800
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <CAP-guGVu4FMJ=CJVS3WHe02nhCrm8+MqAU28boMJyn3Hx4s2xA@mail.gmail.com>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>	<CAP-guGWz6R8d1qM3B_eP1Ned9DVQC0XWtSht8VFZ3hWeZt6NAA@mail.gmail.com>	<52F57CEB.1040909@umn.edu>	<CAP-guGWDH7i5MpjoDApqedwCitKRFGnD+-dtAoYPQF+e2wU7Ng@mail.gmail.com>	<CACrmG8fvLSt482B3joL2+CZT4L9FFuVzfy59+_gchXmds6VScQ@mail.gmail.com>
	<CAP-guGVu4FMJ=CJVS3WHe02nhCrm8+MqAU28boMJyn3Hx4s2xA@mail.gmail.com>
Message-ID: <52F84FBE.3060607@matthew.at>

On 2/8/2014 6:19 AM, William Herrin wrote:
> If we want to manage addresses this way, we should first endeavor to 
> pass a globally coordinated policy to the effect that multiregional 
> organizations should solicit the registry in their headquarters' 
> region for all registry-direct number resources rather than soliciting 
> the registry that serves the region where the resources are employed.

I have a better idea:

For IPv4, realize that really really soon, this isn't going to matter.

For IPv6, realize that it almost never matters.

I have no problem with someone getting a nice big IPv6 block from one 
convenient local RIR, and then splitting it up across their 
multinational organization however they see fit. If they plan well, they 
*never* come back to *any* RIR for address space.

Meanwhile, why are we still discussing IPv4 policy at all?

Matthew Kaufman



From SRyerse at eclipse-networks.com  Sun Feb  9 23:26:28 2014
From: SRyerse at eclipse-networks.com (Steven Ryerse)
Date: Mon, 10 Feb 2014 04:26:28 +0000
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <52F84FBE.3060607@matthew.at>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>	<CAP-g
	uGWz6R8d1qM3B_eP1Ned9DVQC0XWtSht8VFZ3hWeZt6NAA@mail.gmail.com>	<52F57CEB.10
	40909@umn.edu>	<CAP-guGWDH7i5MpjoDApqedwCitKRFGnD+-dtAoYPQF+e2wU7Ng@mail.gm
	ail.com>	<CACrmG8fvLSt482B3joL2+CZT4L9FFuVzfy59+_gchXmds6VScQ@mail.gmail.co
	m><CAP-guGVu4FMJ=CJVS3WHe02nhCrm8+MqAU28boMJyn3Hx4s2xA@mail.gmail.com>
	<52F84FBE.3060607@matthew.at>
Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12014C027125@ENI-MAIL.eclipse-networks.com>

+1


Steven Ryerse
President
100 Ashford Center North, Suite 110, Atlanta, GA? 30338
www.eclipse-networks.com
770.656.1460 - Cell
770.399.9099- Office

? Eclipse Networks, Inc.
             ??????? Conquering Complex Networks?
             
-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Matthew Kaufman
Sent: Sunday, February 09, 2014 11:04 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] support for 2014-1 (out of region use)

On 2/8/2014 6:19 AM, William Herrin wrote:
> If we want to manage addresses this way, we should first endeavor to 
> pass a globally coordinated policy to the effect that multiregional 
> organizations should solicit the registry in their headquarters'
> region for all registry-direct number resources rather than soliciting 
> the registry that serves the region where the resources are employed.

I have a better idea:

For IPv4, realize that really really soon, this isn't going to matter.

For IPv6, realize that it almost never matters.

I have no problem with someone getting a nice big IPv6 block from one convenient local RIR, and then splitting it up across their multinational organization however they see fit. If they plan well, they
*never* come back to *any* RIR for address space.

Meanwhile, why are we still discussing IPv4 policy at all?

Matthew Kaufman

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

From bill at herrin.us  Sun Feb  9 23:37:02 2014
From: bill at herrin.us (William Herrin)
Date: Sun, 9 Feb 2014 23:37:02 -0500
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <52F84FBE.3060607@matthew.at>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>
	<CAP-guGWz6R8d1qM3B_eP1Ned9DVQC0XWtSht8VFZ3hWeZt6NAA@mail.gmail.com>
	<52F57CEB.1040909@umn.edu>
	<CAP-guGWDH7i5MpjoDApqedwCitKRFGnD+-dtAoYPQF+e2wU7Ng@mail.gmail.com>
	<CACrmG8fvLSt482B3joL2+CZT4L9FFuVzfy59+_gchXmds6VScQ@mail.gmail.com>
	<CAP-guGVu4FMJ=CJVS3WHe02nhCrm8+MqAU28boMJyn3Hx4s2xA@mail.gmail.com>
	<52F84FBE.3060607@matthew.at>
Message-ID: <CAP-guGVhU4jH3Vrd2cZZMEeWnmv-9zt4RMgbG_+TSMpLqVg3Qg@mail.gmail.com>

On Sun, Feb 9, 2014 at 11:04 PM, Matthew Kaufman <matthew at matthew.at> wrote:
> On 2/8/2014 6:19 AM, William Herrin wrote:
>> If we want to manage addresses this way, we should first endeavor to pass
>> a globally coordinated policy to the effect that multiregional organizations
>> should solicit the registry in their headquarters' region for all
>> registry-direct number resources rather than soliciting the registry that
>> serves the region where the resources are employed.
>
>
> I have a better idea:
>
> For IPv4, realize that really really soon, this isn't going to matter.

Howdy,

Windows had primacy for more than a decade before folks stopped using
DOS programs. Do you not recall all the workarounds getting DOS games
to work in Windows 98 and later windows XP? IPv6 doesn't even have
primacy yet. Reports of IPv4's death are premature.


> For IPv6, realize that it almost never matters.

The intersection between registry allocation policy and ISP filtering
policy is still working itself out. Moreover, unlike IPv4, changes in
the layer 4 protocols could yet yield major shifts in how addresses
are managed. Don't be so quick to declare what does or does not
matter.


> I have no problem with someone getting a nice big IPv6 block from one
> convenient local RIR, and then splitting it up across their multinational
> organization however they see fit. If they plan well, they *never* come back
> to *any* RIR for address space.

I predict that last sentence turns out to be a pipe dream. If I'm
wrong, look me up in 10 years and I'll buy you lunch.

As for the rest, I would support a global policy to the effect that
organizations should deal exclusively with their home (headquarters)
registries for IPv6 allocations. I DO NOT want to see ARIN going it
alone here, and I DO NOT want to see registry shopping.

Allowing multinationals to registry-shop is a form of cross-subsidy.
As you know, cross-subsidy is one of the foundations of monopoly. If
the multinational can acquire addresses from the most convenient
registry, he gains an anticompetitive advantage over his smaller,
local competitor who may only deal with the registry in his region.
What makes this truly evil is that the regulatory regime from the RIRs
is not money-driven. The registry's rules may prevent the competitor
from matching the multinational's address offerings at any price.

So, I am totally against any policy regime which makes it practical
for a multinational organization to registry-shop for his addresses.
Either everybody should be able to get addresses from any registry,
regardless of geography and nationality, or only one registry should
be a legitimate source for a give use of addresses.

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  Mon Feb 10 09:03:55 2014
From: info at arin.net (ARIN)
Date: Mon, 10 Feb 2014 09:03:55 -0500
Subject: [arin-ppml] ARIN Customer Satisfaction Survey Now Open
Message-ID: <52F8DC4B.2000004@arin.net>

 From 10 - 21 February, ARIN will be conducting a customer satisfaction 
survey to determine the current level of customer satisfaction with ARIN 
services and inform a path forward to make future improvements.

Working together with a marketing research firm, Rockbridge Associates, 
we have developed a survey that will help us assess our performance in 
all areas of the organization, including Engineering, Registration and 
Financial Services, Policy Development, and Communications.

The survey should only take around 15 minutes to complete and is 
available at: https://www.arin.net/customersurvey

We will be randomly selecting winners to receive a Nexus 7 tablet during 
the survey period. If you would like to participate, please provide your 
name and an email address on the final page of the survey. This 
information will only be used for the purposes of randomly selecting and 
contacting survey prize winners. The names of winners will be announced.

Your feedback is important to us, and we value your time to help ARIN 
improve services to you.

Regards,

Richard Jimmerson
Chief Information Officer
American Registry for Internet Numbers (ARIN)


*Note: This message has been posted to the arin-announce, ppml, and 
arin-tech-discuss mailing lists. If subscribed to multiple lists, you 
may see duplicate messages.


From cb.list6 at gmail.com  Mon Feb 10 09:21:24 2014
From: cb.list6 at gmail.com (Cb B)
Date: Mon, 10 Feb 2014 06:21:24 -0800
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <52F84FBE.3060607@matthew.at>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>
	<CAP-guGWz6R8d1qM3B_eP1Ned9DVQC0XWtSht8VFZ3hWeZt6NAA@mail.gmail.com>
	<52F57CEB.1040909@umn.edu>
	<CAP-guGWDH7i5MpjoDApqedwCitKRFGnD+-dtAoYPQF+e2wU7Ng@mail.gmail.com>
	<CACrmG8fvLSt482B3joL2+CZT4L9FFuVzfy59+_gchXmds6VScQ@mail.gmail.com>
	<CAP-guGVu4FMJ=CJVS3WHe02nhCrm8+MqAU28boMJyn3Hx4s2xA@mail.gmail.com>
	<52F84FBE.3060607@matthew.at>
Message-ID: <CAD6AjGT0dU37c4zseWxM2TCVG093+qvzqSdsoTYjVmjLPQsTWg@mail.gmail.com>

On Feb 9, 2014 8:05 PM, "Matthew Kaufman" <matthew at matthew.at> wrote:
>
> On 2/8/2014 6:19 AM, William Herrin wrote:
>>
>> If we want to manage addresses this way, we should first endeavor to
pass a globally coordinated policy to the effect that multiregional
organizations should solicit the registry in their headquarters' region for
all registry-direct number resources rather than soliciting the registry
that serves the region where the resources are employed.
>
>
> I have a better idea:
>
> For IPv4, realize that really really soon, this isn't going to matter.
>
> For IPv6, realize that it almost never matters.
>
> I have no problem with someone getting a nice big IPv6 block from one
convenient local RIR, and then splitting it up across their multinational
organization however they see fit. If they plan well, they *never* come
back to *any* RIR for address space.
>
> Meanwhile, why are we still discussing IPv4 policy at all?
>
> Matthew Kaufman
>
>

100% agree with Matthew on both points.

CB

> _______________________________________________
> 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/20140210/cfee862f/attachment.htm>

From jeffrey.lyon at blacklotus.net  Mon Feb 10 09:32:18 2014
From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon)
Date: Mon, 10 Feb 2014 23:32:18 +0900
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <CAD6AjGT0dU37c4zseWxM2TCVG093+qvzqSdsoTYjVmjLPQsTWg@mail.gmail.com>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>
	<CAP-guGWz6R8d1qM3B_eP1Ned9DVQC0XWtSht8VFZ3hWeZt6NAA@mail.gmail.com>
	<52F57CEB.1040909@umn.edu>
	<CAP-guGWDH7i5MpjoDApqedwCitKRFGnD+-dtAoYPQF+e2wU7Ng@mail.gmail.com>
	<CACrmG8fvLSt482B3joL2+CZT4L9FFuVzfy59+_gchXmds6VScQ@mail.gmail.com>
	<CAP-guGVu4FMJ=CJVS3WHe02nhCrm8+MqAU28boMJyn3Hx4s2xA@mail.gmail.com>
	<52F84FBE.3060607@matthew.at>
	<CAD6AjGT0dU37c4zseWxM2TCVG093+qvzqSdsoTYjVmjLPQsTWg@mail.gmail.com>
Message-ID: <CACrmG8dpSK05Tkhi_xsMBLj+4sVPNpGbo-1aHH54sq9iFCQKPQ@mail.gmail.com>

We should be able to use ARIN space out of region so long as we have a
primary nexus in the ARIN region.

Thanks, Jeff

On Mon, Feb 10, 2014 at 11:21 PM, Cb B <cb.list6 at gmail.com> wrote:
>
> On Feb 9, 2014 8:05 PM, "Matthew Kaufman" <matthew at matthew.at> wrote:
>>
>> On 2/8/2014 6:19 AM, William Herrin wrote:
>>>
>>> If we want to manage addresses this way, we should first endeavor to pass
>>> a globally coordinated policy to the effect that multiregional organizations
>>> should solicit the registry in their headquarters' region for all
>>> registry-direct number resources rather than soliciting the registry that
>>> serves the region where the resources are employed.
>>
>>
>> I have a better idea:
>>
>> For IPv4, realize that really really soon, this isn't going to matter.
>>
>> For IPv6, realize that it almost never matters.
>>
>> I have no problem with someone getting a nice big IPv6 block from one
>> convenient local RIR, and then splitting it up across their multinational
>> organization however they see fit. If they plan well, they *never* come back
>> to *any* RIR for address space.
>>
>> Meanwhile, why are we still discussing IPv4 policy at all?
>>
>> Matthew Kaufman
>>
>>
>
> 100% agree with Matthew on both points.
>
> CB
>
>> _______________________________________________
>> 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 A. Lyon, CISSP-ISSMP
Founder, Black Lotus Communications
mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net


From farmer at umn.edu  Mon Feb 10 10:02:13 2014
From: farmer at umn.edu (David Farmer)
Date: Mon, 10 Feb 2014 09:02:13 -0600
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <CAP-guGWDH7i5MpjoDApqedwCitKRFGnD+-dtAoYPQF+e2wU7Ng@mail.gmail.com>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>
	<CAP-guGWz6R8d1qM3B_eP1Ned9DVQC0XWtSht8VFZ3hWeZt6NAA@mail.gmail.com>
	<52F57CEB.1040909@umn.edu>
	<CAP-guGWDH7i5MpjoDApqedwCitKRFGnD+-dtAoYPQF+e2wU7Ng@mail.gmail.com>
Message-ID: <52F8E9F5.7040202@umn.edu>

On 2/7/14, 22:58 , William Herrin wrote:
> On Fri, Feb 7, 2014 at 7:40 PM, David Farmer <farmer at umn.edu> wrote:
...
> Howdy,
>
> You pulled a TLDR on me. Like I said at the end of the message: after
> you admit that the reason you (the general you, not you specifically)
> don't want this policy is that you've knowingly been doing things
> wrong for the last decade plus, you add the following sentence to the
> still concise policy.

How do you justify saying they've been doing anything wrong? Nothing in 
policy says that its wrong.  The only thing in policy, says is ARIN's 
primary role is issuing resources for use within the region.  So that 
means out of region use is a secondary role in my opinion.  The only 
justification for any regional limitation I can theoretically come up 
with, is that the stress on the system created by uneven IPv4 run-out 
among the RIRs is creating a temporary conflict between these primary 
and secondary roles, and only for the remaining IPv4 free pool 
resources.  And to be honest, I'm not sure that is really sufficient 
justification to change the rules, or that any change can be effective 
to prevent the problems created by the uneven run-out among the RIRs.

> "ARIN number resources in use outside the region upon enaction of this
> policy are grandfathered until recovered from their then-current
> assignment."

I think if we are to make any restrictions, they should apply only to 
new IPv4 resources from the free pool and not be retroactively applied 
to old resources even if they are recovered in the future, or for any 
transferred resources.  But, I'm still not convinced any restrictions 
are needed or justified even because of IPv4 run-out, and I'm even less 
convinced they can be effective without significant collateral damage.

We (globally) created a run-out scheme that was going to be uneven. 
There was at least one rejected proposal that tried to even out the 
run-out across the RIRs.  Unfortunately, I think we just need to live 
with the consequences of our actions, or inaction in this case.

>> Now IPv6, this means multinational companies will need separate allocations
>> from each RIR that they function within that RIR's region. It will be common
>> for most multinational companies to need 3 or 4 separate allocations then,
>> that will bloat the IPv6 route table.  In IPv6 we are trying to minimize the
>> number of non-aggregatable prefixes allocated, that is why we are doing
>> sparse allocation for IPv6.
>
> You make a good point. I'd be satisfied limiting it to "IPv4
> addresses" instead of "number resources."
>
> Will you be drafting a global policy to the effect that registrants
> are encouraged to get their entire IPv6 allocation from their single
> home registry? Once again, it isn't appropriate for a regional
> registry to act unilaterally in this regard.

It's not unilateral action, its been the norm all along.  The RIR system 
is intended to be facilitatory, not restrictive.  AfriNIC and LACNIC 
have diverged from the norm by putting in place regional use 
restrictions.  I'm not saying there wasn't reasons, or that they did 
anything wrong, but that was not the norm previously.

Please read what Geoff Huston say at the NANOG 59 PPC, toward the end of 
the following section;

https://www.arin.net/participate/meetings/reports/ppc_nanog59/ppc_transcript.html#anchor_4 


As the problem statement says, I think the real problem is that policy 
is ambiguous on the subject of out of region use.  Which means there are 
some in the community that think out of region use is outside the rules, 
as you seem to think.  Then others think it is perfectly normal and has 
always been allowed, because its never been disallowed in policy.  I 
think we need to clarify that out of region use was always intended to 
be allowed by policy.

Thanks.

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


From info at arin.net  Mon Feb 10 10:15:04 2014
From: info at arin.net (ARIN)
Date: Mon, 10 Feb 2014 10:15:04 -0500
Subject: [arin-ppml] ARIN PPC Agenda for NANOG 60 Now Available
Message-ID: <52F8ECF8.4080707@arin.net>

Don't forget to mark your calendar and join us for ARIN's Public Policy 
Consultation (PPC), which will be held during NANOG 60 in Atlanta, 
Georgia on Tuesday, 11 February 2014, from 9:30 - 1:00 PM. The policy 
consultation is part of ARIN's Policy Development Process, and it is an 
open public discussion of Internet number resource policy.

Registered NANOG 60 attendees do not need to register to participate in 
this session. ARIN welcomes members of the NANOG community who will not 
be in Atlanta to register as remote participants.

If you plan to attend and are not registered for NANOG you must register 
for the ARIN PPC at the https://www.arin.net/ppcregister

There is no registration fee for this half-day ARIN session, and it does 
not provide you entry to any other NANOG programming or social events.

Current policy proposals up for discussion at this meeting are:

     Recommended Draft Policy ARIN-2013-8: Subsequent Allocations for 
New Multiple Discrete Networks
     Draft Policy ARIN-2013-7: NRPM 4 (IPv4) Policy Cleanup
     Draft Policy ARIN-2014-1: Out of Region Use
     Draft Policy ARIN-2014-2: Improving 8.4 Anti-Flip Language
     Draft Policy ARIN-2014-3: Remove 8.2 and 8.3 and 8.4 Minimum IPv4 
Block Size Requirements
     Draft Policy ARIN-2014-4: Remove 4.2.5 Web Hosting Policy
     Draft Policy ARIN-2014-5: Remove 7.2 Lame Delegations
     Draft Policy ARIN-2014-6: Remove 7.1 (Maintaining IN-ADDRs)
     Draft Policy ARIN-2014-7: Section 4.4 Micro Allocation Conservation 
Update
     Proposals (193, 199 and 201)

That first item is a Recommended Draft Policy; the ARIN Advisory Council 
recommends it as fair and technically sound policy. The Drafts and 
Proposals are works in progress. Text available at: 
https://www.arin.net/policy/proposals/ or in the PPC Discussion Guide: 
https://www.arin.net/ppcnanog60

ARIN will offer a webcast, live transcript, and Jabber chat options for 
remote participants. Registered remote participants can submit comments 
and questions to the discussions during the meeting. Register to attend 
in person or remotely today!

Regards,

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




From ajs at anvilwalrusden.com  Mon Feb 10 10:30:34 2014
From: ajs at anvilwalrusden.com (Andrew Sullivan)
Date: Mon, 10 Feb 2014 10:30:34 -0500
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <52F8E9F5.7040202@umn.edu>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>
	<CAP-guGWz6R8d1qM3B_eP1Ned9DVQC0XWtSht8VFZ3hWeZt6NAA@mail.gmail.com>
	<52F57CEB.1040909@umn.edu>
	<CAP-guGWDH7i5MpjoDApqedwCitKRFGnD+-dtAoYPQF+e2wU7Ng@mail.gmail.com>
	<52F8E9F5.7040202@umn.edu>
Message-ID: <20140210153034.GF23819@mx1.yitter.info>

On Mon, Feb 10, 2014 at 09:02:13AM -0600, David Farmer wrote:

> We (globally) created a run-out scheme that was going to be uneven.
> There was at least one rejected proposal that tried to even out the
> run-out across the RIRs.  Unfortunately, I think we just need to
> live with the consequences of our actions, or inaction in this case.

> As the problem statement says, I think the real problem is that
> policy is ambiguous on the subject of out of region use.  Which
> means there are some in the community that think out of region use
> is outside the rules, as you seem to think.  Then others think it is
> perfectly normal and has always been allowed, because its never been
> disallowed in policy.  I think we need to clarify that out of region
> use was always intended to be allowed by policy.

I am normally loathe to say "+1", but I have to agree very strongly
with the above.  The impulse to try to do something here is
well-intended but badly misguided.  It will have negative side effects
as one tries to write exceptional exceptions for the exceptionally
exceptional case.  The reason clich?s are clich? is that they express
a truth, and in this case the clich?, "Hard cases make bad law,"
applies.  New policies, if they are to be adopted, ought to reinforce
the historically permissive stance ARIN has taken.

Will that have the consequence that some will come "out of region" and
incorporate for convenience and try to corner the market on the
remaining IPv4?  Yes.  The idea that ARIN can make a policy that will
successfully stanch the well-known problems of speculation and gaming
in commodity markets during scarcity and without doing incidental
damage is, I think, too ambitious.

Best regards,

Andrew (I work for Dyn.  The above remarks may not reflect their
opinion.)

-- 
Andrew Sullivan
ajs at anvilwalrusden.com


From jcurran at arin.net  Mon Feb 10 10:51:15 2014
From: jcurran at arin.net (John Curran)
Date: Mon, 10 Feb 2014 15:51:15 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-5: Remove 7.2 Lame	
	Delegations
In-Reply-To: <52EFBC11.5050404@quark.net>
References: <52E91DCC.1070206@arin.net>
	<CAP-guGXtXJ=wCi1PO2gxDapeCX1srLEm-L6=UYpk=fb_5S_SmQ@mail.gmail.com>
	<52EFBC11.5050404@quark.net>
Message-ID: <224E04F8-3DA6-4A82-9F3A-F8B8016C5BB5@arin.net>

On Feb 3, 2014, at 10:56 AM, Andrew Dul <andrew.dul at quark.net> wrote:

> It would be helpful for this discussion if ARIN staff could produce a
> brief statement on the current state of how this section has been
> implemented within ARIN's operational procedures.  I assume some of this
> will come later with the staff assessment, but a limited response might
> be helpful for the community to understand how this change would effect
> ARIN's current operational procedures.

Andrew - 
 
  Short answer: The policy change would sustain current operational practices

  When we switched over to per-zone DNS management, we ran into significant 
  issues with lame detection and remediation, including the appropriate 
  definition of a 'lame' dns server and potential risk of removing 
  misconfigured but working reverse DNS servers in some cases. As a result 
  of these issues, we suspended lame testing and Mark Kosters reported on
  them in the "Lame Testing" Report at the ARIN 24 meeting in October 2009 

<https://www.arin.net/participate/meetings/reports/ARIN_XXIV/PDF/wednesday/lame.pdf>

  We are prepared to reinstate lame DNS reverse testing, marking, and 
  potentially even removal of "lame" name servers from the whois records 
  if the community can provide more specific guidance on lame definition.
  
Thanks!
/John

John Curran
President and CEO
ARIN





From matthew at matthew.at  Mon Feb 10 12:05:56 2014
From: matthew at matthew.at (Matthew Kaufman)
Date: Mon, 10 Feb 2014 09:05:56 -0800
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <CAP-guGVhU4jH3Vrd2cZZMEeWnmv-9zt4RMgbG_+TSMpLqVg3Qg@mail.gmail.com>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>
	<CAP-guGWz6R8d1qM3B_eP1Ned9DVQC0XWtSht8VFZ3hWeZt6NAA@mail.gmail.com>
	<52F57CEB.1040909@umn.edu>
	<CAP-guGWDH7i5MpjoDApqedwCitKRFGnD+-dtAoYPQF+e2wU7Ng@mail.gmail.com>
	<CACrmG8fvLSt482B3joL2+CZT4L9FFuVzfy59+_gchXmds6VScQ@mail.gmail.com>
	<CAP-guGVu4FMJ=CJVS3WHe02nhCrm8+MqAU28boMJyn3Hx4s2xA@mail.gmail.com>
	<52F84FBE.3060607@matthew.at>
	<CAP-guGVhU4jH3Vrd2cZZMEeWnmv-9zt4RMgbG_+TSMpLqVg3Qg@mail.gmail.com>
Message-ID: <52F906F4.8090601@matthew.at>


On 2/9/14, 8:37 PM, William Herrin wrote:
> On Sun, Feb 9, 2014 at 11:04 PM, Matthew Kaufman <matthew at matthew.at> wrote:
>> On 2/8/2014 6:19 AM, William Herrin wrote:
>>> If we want to manage addresses this way, we should first endeavor to pass
>>> a globally coordinated policy to the effect that multiregional organizations
>>> should solicit the registry in their headquarters' region for all
>>> registry-direct number resources rather than soliciting the registry that
>>> serves the region where the resources are employed.
>>
>> I have a better idea:
>>
>> For IPv4, realize that really really soon, this isn't going to matter.
> Howdy,
>
> Windows had primacy for more than a decade before folks stopped using
> DOS programs. Do you not recall all the workarounds getting DOS games
> to work in Windows 98 and later windows XP? IPv6 doesn't even have
> primacy yet. Reports of IPv4's death are premature.

I'm not talking about when IPv4 isn't used any more. I'm talking about 
when ARIN stops handing out IPv4 addresses to people who ask nicely for 
them. That's going to happen in a year or so, best case. Maybe sooner.

Or are you supposing that we're somehow going to constrain the IPv4 
transfer market to keep addresses from "leaving the region" as well?

>
>
>> For IPv6, realize that it almost never matters.
> The intersection between registry allocation policy and ISP filtering
> policy is still working itself out. Moreover, unlike IPv4, changes in
> the layer 4 protocols could yet yield major shifts in how addresses
> are managed. Don't be so quick to declare what does or does not
> matter.
>
>
>> I have no problem with someone getting a nice big IPv6 block from one
>> convenient local RIR, and then splitting it up across their multinational
>> organization however they see fit. If they plan well, they *never* come back
>> to *any* RIR for address space.
> I predict that last sentence turns out to be a pipe dream. If I'm
> wrong, look me up in 10 years and I'll buy you lunch.
>
> As for the rest, I would support a global policy to the effect that
> organizations should deal exclusively with their home (headquarters)
> registries for IPv6 allocations. I DO NOT want to see ARIN going it
> alone here, and I DO NOT want to see registry shopping.
>
> Allowing multinationals to registry-shop is a form of cross-subsidy.
> As you know, cross-subsidy is one of the foundations of monopoly. If
> the multinational can acquire addresses from the most convenient
> registry, he gains an anticompetitive advantage over his smaller,
> local competitor who may only deal with the registry in his region.

For IPv6, how will this matter? Do you really think that some region 
will have wildly more permissive policies that some multinational can 
take advantage of in a way that a local competitor can not? I see the 
point with IPv4, what with some RIRs not able to assign addresses at 
all, but that's not what we're talking about here.

> What makes this truly evil is that the regulatory regime from the RIRs
> is not money-driven. The registry's rules may prevent the competitor
> from matching the multinational's address offerings at any price.
>
> So, I am totally against any policy regime which makes it practical
> for a multinational organization to registry-shop for his addresses.
> Either everybody should be able to get addresses from any registry,
> regardless of geography and nationality, or only one registry should
> be a legitimate source for a give use of addresses.

Well, it sure seemed like a good idea when it was set up this way. If 
only someone could have predicted that we would run out in different 
places at different times, this could have been avoided (for the IPv4 case)

Matthew Kaufman



From ajs at anvilwalrusden.com  Mon Feb 10 12:19:40 2014
From: ajs at anvilwalrusden.com (Andrew Sullivan)
Date: Mon, 10 Feb 2014 12:19:40 -0500
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <CAGkMwz5frXKeoht57YqY01CRFbW+KhLx4urY63_0sSaxTJBQDw@mail.gmail.com>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>
	<CAP-guGWz6R8d1qM3B_eP1Ned9DVQC0XWtSht8VFZ3hWeZt6NAA@mail.gmail.com>
	<52F57CEB.1040909@umn.edu>
	<CAP-guGWDH7i5MpjoDApqedwCitKRFGnD+-dtAoYPQF+e2wU7Ng@mail.gmail.com>
	<52F8E9F5.7040202@umn.edu> <20140210153034.GF23819@mx1.yitter.info>
	<CAGkMwz5frXKeoht57YqY01CRFbW+KhLx4urY63_0sSaxTJBQDw@mail.gmail.com>
Message-ID: <20140210171940.GR23819@mx1.yitter.info>

On Mon, Feb 10, 2014 at 08:53:43AM -0800, Scott Leibrand wrote:

> So are you in favor of or opposed to 2014-1

I'm opposed to it, because I just don't buy that it will actually
solve any problem.  The existing policy neither forbids nor denies out
of region use.  This proposal tries to codify things, but I don't see
why that's necessary.

In other words, I guess I don't really believe the problem statement.
I suppose if I did, 2014-1 is all right.  I wish I did have
suggestions for how to improve it.  It's actually the fact that I
don't that makes me nervous: I suspect nobody understands the full
implications of X.2-X.4 in every case, and I therefore believe that
we'll run into some unpleasant surprise later.

Best regards,

A

-- 
Andrew Sullivan
ajs at anvilwalrusden.com


From farmer at umn.edu  Mon Feb 10 12:40:47 2014
From: farmer at umn.edu (David Farmer)
Date: Mon, 10 Feb 2014 11:40:47 -0600
Subject: [arin-ppml] Qualifications to receive resources (was: support
 for 2014-1 (out of region use))
In-Reply-To: <CACrmG8dpSK05Tkhi_xsMBLj+4sVPNpGbo-1aHH54sq9iFCQKPQ@mail.gmail.com>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>	<CAP-guGWz6R8d1qM3B_eP1Ned9DVQC0XWtSht8VFZ3hWeZt6NAA@mail.gmail.com>	<52F57CEB.1040909@umn.edu>	<CAP-guGWDH7i5MpjoDApqedwCitKRFGnD+-dtAoYPQF+e2wU7Ng@mail.gmail.com>	<CACrmG8fvLSt482B3joL2+CZT4L9FFuVzfy59+_gchXmds6VScQ@mail.gmail.com>	<CAP-guGVu4FMJ=CJVS3WHe02nhCrm8+MqAU28boMJyn3Hx4s2xA@mail.gmail.com>	<52F84FBE.3060607@matthew.at>	<CAD6AjGT0dU37c4zseWxM2TCVG093+qvzqSdsoTYjVmjLPQsTWg@mail.gmail.com>
	<CACrmG8dpSK05Tkhi_xsMBLj+4sVPNpGbo-1aHH54sq9iFCQKPQ@mail.gmail.com>
Message-ID: <52F90F1F.3010609@umn.edu>

On 2/10/14, 08:32 , Jeffrey Lyon wrote:
> We should be able to use ARIN space out of region so long as we have a
> primary nexus in the ARIN region.
>
> Thanks, Jeff

Yes,

We need to think about who should be eligible to receive resources from 
ARIN, and what that nexus should be to receive resources.

I think there are two part to the nexus;

1. Legal Presence - current operational practice is legally formed 
within the region.

2. Technical/Operational Presence - this is not currently well defined 
in policy or operational practice.

But, I'll note we currently have initial allocation policies that you 
need to meet in order to qualify to receive an allocation.  What if we 
constrained these initial allocation requirements to be from within the 
ARIN region?

This would define a minimum Technical/Operational Presence needed within 
the region, that is the same amount within the region, for both ARIN 
region only networks and trans-regional networks.

Currently, trans-regional networks have a theoretical advantage over 
ARIN region only networks, the trans-regional networks can qualify to 
get resources with a smaller or no foot print within the region.

This change seems like a reasonably fair way to ensue everyone getting 
resources from ARIN qualifies to receive resources using the same 
resource footprint within the ARIN Region.  Essentially, out of region 
need can only be considered for a larger than minimum initial allocation 
or for subsequent allocations.

You could maybe even require that the minimum allocation must be support 
by in region need and out of region need can only be considered for a 
larger than minimum allocation for initial or subsequent allocations. 
This would ensure there is some minimum need within the ARIN region for 
all allocations.  I'm my opinion, this is consistent with the idea that 
ARIN's primary role is allocating resources for use within the ARIN 
region, but there is still a secondary role for allocating resources for 
out of region use as well.

What do people think of these concepts?

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


From mueller at syr.edu  Mon Feb 10 12:47:51 2014
From: mueller at syr.edu (Milton L Mueller)
Date: Mon, 10 Feb 2014 17:47:51 +0000
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <52F84FBE.3060607@matthew.at>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>
	<CAP-guGWz6R8d1qM3B_eP1Ned9DVQC0XWtSht8VFZ3hWeZt6NAA@mail.gmail.com>
	<52F57CEB.1040909@umn.edu>
	<CAP-guGWDH7i5MpjoDApqedwCitKRFGnD+-dtAoYPQF+e2wU7Ng@mail.gmail.com>
	<CACrmG8fvLSt482B3joL2+CZT4L9FFuVzfy59+_gchXmds6VScQ@mail.gmail.com>
	<CAP-guGVu4FMJ=CJVS3WHe02nhCrm8+MqAU28boMJyn3Hx4s2xA@mail.gmail.com>
	<52F84FBE.3060607@matthew.at>
Message-ID: <a470be19314d41d381322431a83a3678@EX13-MBX-13.ad.syr.edu>



-----Original Message-----

> Meanwhile, why are we still discussing IPv4 policy at all?

Because the transfer market for Ipv4 is going to be around for at least another 10 years.



From mueller at syr.edu  Mon Feb 10 12:50:27 2014
From: mueller at syr.edu (Milton L Mueller)
Date: Mon, 10 Feb 2014 17:50:27 +0000
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <20140210153034.GF23819@mx1.yitter.info>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>
	<CAP-guGWz6R8d1qM3B_eP1Ned9DVQC0XWtSht8VFZ3hWeZt6NAA@mail.gmail.com>
	<52F57CEB.1040909@umn.edu>
	<CAP-guGWDH7i5MpjoDApqedwCitKRFGnD+-dtAoYPQF+e2wU7Ng@mail.gmail.com>
	<52F8E9F5.7040202@umn.edu> <20140210153034.GF23819@mx1.yitter.info>
Message-ID: <d5218efc16074f97a596f069a493312d@EX13-MBX-13.ad.syr.edu>



-----Original Message-----
>New policies, if they are to be adopted, ought to reinforce the historically permissive stance ARIN has taken.

Doesn't 2014-1 do that? 


From mueller at syr.edu  Mon Feb 10 12:55:18 2014
From: mueller at syr.edu (Milton L Mueller)
Date: Mon, 10 Feb 2014 17:55:18 +0000
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <20140210171940.GR23819@mx1.yitter.info>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>
	<CAP-guGWz6R8d1qM3B_eP1Ned9DVQC0XWtSht8VFZ3hWeZt6NAA@mail.gmail.com>
	<52F57CEB.1040909@umn.edu>
	<CAP-guGWDH7i5MpjoDApqedwCitKRFGnD+-dtAoYPQF+e2wU7Ng@mail.gmail.com>
	<52F8E9F5.7040202@umn.edu> <20140210153034.GF23819@mx1.yitter.info>
	<CAGkMwz5frXKeoht57YqY01CRFbW+KhLx4urY63_0sSaxTJBQDw@mail.gmail.com>
	<20140210171940.GR23819@mx1.yitter.info>
Message-ID: <61acdc4c94f7439c9c34e3eed1d1a2a4@EX13-MBX-13.ad.syr.edu>



-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Andrew Sullivan
Sent: Monday, February 10, 2014 12:20 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] support for 2014-1 (out of region use)

Scott:
>> So are you in favor of or opposed to 2014-1

Andrew S.:
>I'm opposed to it, because I just don't buy that it will actually solve 
>any problem.  The existing policy neither forbids nor denies out of 
>region use.  This proposal tries to codify things, but I don't see why that's necessary.
> In other words, I guess I don't really believe the problem statement.
> I suppose if I did, 2014-1 is all right.  

Color me confused. Wearing my AC shepherd hat, and trying to keep track of opposition/support for this proposal, I saw you "agree very strongly" with David Farmer's assertion that 

> As the problem statement says, I think the real problem is that policy 
> is ambiguous on the subject of out of region use.  Which means there 
> are some in the community that think out of region use is outside the 
> rules, as you seem to think.  Then others think it is perfectly normal 
> and has always been allowed, because its never been disallowed in 
> policy.  I think we need to clarify that out of region use was always 
> intended to be allowed by policy.

Let me repeat Scott's question in a different way: David Farmer says "we need to clarify that our of region use was always intended to be allowed by policy" and you agreed very strongly with him, and 2014-1 does that. Are you still maintaining that you are opposed to 2014-1? 





From matthew at matthew.at  Mon Feb 10 13:07:12 2014
From: matthew at matthew.at (Matthew Kaufman)
Date: Mon, 10 Feb 2014 10:07:12 -0800
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <a470be19314d41d381322431a83a3678@EX13-MBX-13.ad.syr.edu>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>	<CAP-guGWz6R8d1qM3B_eP1Ned9DVQC0XWtSht8VFZ3hWeZt6NAA@mail.gmail.com>	<52F57CEB.1040909@umn.edu>	<CAP-guGWDH7i5MpjoDApqedwCitKRFGnD+-dtAoYPQF+e2wU7Ng@mail.gmail.com>	<CACrmG8fvLSt482B3joL2+CZT4L9FFuVzfy59+_gchXmds6VScQ@mail.gmail.com>	<CAP-guGVu4FMJ=CJVS3WHe02nhCrm8+MqAU28boMJyn3Hx4s2xA@mail.gmail.com>	<52F84FBE.3060607@matthew.at>
	<a470be19314d41d381322431a83a3678@EX13-MBX-13.ad.syr.edu>
Message-ID: <52F91550.2020101@matthew.at>

On 2/10/2014 9:47 AM, Milton L Mueller wrote:
>
> -----Original Message-----
>
>> Meanwhile, why are we still discussing IPv4 policy at all?
> Because the transfer market for Ipv4 is going to be around for at least another 10 years.
>

And how will this policy impact the transfer market?

Matthew Kaufman


From ajs at anvilwalrusden.com  Mon Feb 10 13:16:30 2014
From: ajs at anvilwalrusden.com (Andrew Sullivan)
Date: Mon, 10 Feb 2014 13:16:30 -0500
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <61acdc4c94f7439c9c34e3eed1d1a2a4@EX13-MBX-13.ad.syr.edu>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>
	<CAP-guGWz6R8d1qM3B_eP1Ned9DVQC0XWtSht8VFZ3hWeZt6NAA@mail.gmail.com>
	<52F57CEB.1040909@umn.edu>
	<CAP-guGWDH7i5MpjoDApqedwCitKRFGnD+-dtAoYPQF+e2wU7Ng@mail.gmail.com>
	<52F8E9F5.7040202@umn.edu> <20140210153034.GF23819@mx1.yitter.info>
	<CAGkMwz5frXKeoht57YqY01CRFbW+KhLx4urY63_0sSaxTJBQDw@mail.gmail.com>
	<20140210171940.GR23819@mx1.yitter.info>
	<61acdc4c94f7439c9c34e3eed1d1a2a4@EX13-MBX-13.ad.syr.edu>
Message-ID: <20140210181629.GS23819@mx1.yitter.info>

On Mon, Feb 10, 2014 at 05:55:18PM +0000, Milton L Mueller wrote:
> 
> Let me repeat Scott's question in a different way: David Farmer says "we need to clarify that our of region use was always intended to be allowed by policy" and you agreed very strongly with him, and 2014-1 does that. Are you still maintaining that you are opposed to 2014-1? 
> 

I should have trimmed that last sentence, actually.  (I apologise for
being so careless.  I'm unusually obtuse today, which is saying
something).  The main thing that I wanted to agree with was that the
historic policies were ambiguous and that anyone who thinks they're
going to fix that with a lot of tight controls is mistaken, so we have
to live with the consequences.

To me, this new proposal is worse than doing nothing.  I prefer it
over previously-floated alternatives (which seemed to me to be
attempting to create a new policy that was never there).  So, if a
policy is going to be adopted, I can stand this, but I don't think any
policy is actually needed here.

Best regards,

Andrew

-- 
Andrew Sullivan
ajs at anvilwalrusden.com


From scottleibrand at gmail.com  Mon Feb 10 13:28:39 2014
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Mon, 10 Feb 2014 10:28:39 -0800
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <52F91550.2020101@matthew.at>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>
	<CAP-guGWz6R8d1qM3B_eP1Ned9DVQC0XWtSht8VFZ3hWeZt6NAA@mail.gmail.com>
	<52F57CEB.1040909@umn.edu>
	<CAP-guGWDH7i5MpjoDApqedwCitKRFGnD+-dtAoYPQF+e2wU7Ng@mail.gmail.com>
	<CACrmG8fvLSt482B3joL2+CZT4L9FFuVzfy59+_gchXmds6VScQ@mail.gmail.com>
	<CAP-guGVu4FMJ=CJVS3WHe02nhCrm8+MqAU28boMJyn3Hx4s2xA@mail.gmail.com>
	<52F84FBE.3060607@matthew.at>
	<a470be19314d41d381322431a83a3678@EX13-MBX-13.ad.syr.edu>
	<52F91550.2020101@matthew.at>
Message-ID: <CAGkMwz66ECowngvTkOdBHu9bd9+kZosJiaaD7U6ccKZAg4iaQA@mail.gmail.com>

(As long as ARIN transfer policy requires justified need according to the
same requirements as for new allocations from the free pool...)

This change would clarify/codify that organizations with out-of-region
network needs are allowed to register transfers in the ARIN database.  It
would mean that organizations could choose between an inter-RIR transfer
(if allowed in their region), or obtaining an intra-ARIN transfer and using
(some of) it out of the ARIN region.

If that sounds problematic to any of you, you should consider why previous
efforts to disallow out-of-region use of ARIN addresses have failed to gain
consensus.  You should also address the fact that such out-of-region use is
de facto allowed today.

-Scott


On Mon, Feb 10, 2014 at 10:07 AM, Matthew Kaufman <matthew at matthew.at>wrote:

> On 2/10/2014 9:47 AM, Milton L Mueller wrote:
>
>>
>> -----Original Message-----
>>
>>  Meanwhile, why are we still discussing IPv4 policy at all?
>>>
>> Because the transfer market for Ipv4 is going to be around for at least
>> another 10 years.
>>
>>
> And how will this policy impact the transfer market?
>
> Matthew Kaufman
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140210/9b2dc547/attachment.htm>

From cgrundemann at gmail.com  Mon Feb 10 14:13:23 2014
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Mon, 10 Feb 2014 12:13:23 -0700
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy InternetResource
	Holders
In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
	<CAMDXq5Ma1Hq0YOVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com>
Message-ID: <CAC1-dtn5GDate1PZ6ke538B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com>

On Sun, Feb 9, 2014 at 9:00 PM, Steven Ryerse
<SRyerse at eclipse-networks.com>wrote:

>  My Opinion:  I think their policy acknowledges reality and embraces it!
> Their policy obviously PROMOTES the Internet which is what the RIRs were
> created to do in the first place.  It is time for the ARIN community to do
> something similar, and it is time for removing all of the needs testing to
> qualify for ARIN resources - as needs testing does the exact OPPOSITE of
> PROMOTING the Internet.
>

Hi Steve,

I don't follow you here. Maybe you can explain how giving Internet
addresses to people who need them to connect to the Internet is the
opposite of promoting the Internet?

Also, the RIRs, and ARIN in particular, were not created to "promote the
Internet" necessarily (although I do find that a laudable cause) - their
primary purpose is to _support the Internet_ by acting as stewards of the
Internet numbers in their region (something that should be remembered in
any argument about needs testing). ;-)

https://www.arin.net/announcements/2012/20121012_mission.html : "ARIN, a
nonprofit member-based organization, supports the operation of the Internet
through the management of Internet number resources throughout its service
region; coordinates the development of policies by the community for the
management of Internet Protocol number resources; and advances the Internet
through informational outreach."

Cheers,
~Chris


>
> *Steven Ryerse*
>
> *President*
>
> *100 Ashford Center North, Suite 110, Atlanta, GA  30338*
>
> *www.eclipse-networks.com <http://www.eclipse-networks.com>*
>
> *770.656.1460 <770.656.1460> - Cell*
>
> *770.399.9099 <770.399.9099>- Office*
>
>
>
> [image: Description: Description: Eclipse Networks Logo_small.png]? Eclipse
> Networks, Inc.
>
>         Conquering Complex Networks?
>
>
>
> *From:* arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] *On
> Behalf Of *Martin Hannigan
> *Sent:* Sunday, February 09, 2014 9:45 PM
> *To:* Owen DeLong
> *Cc:* arin-ppml at arin.net
> *Subject:* Re: [arin-ppml] FYI -- RIPE-605 Services to Legacy
> InternetResource Holders
>
>
>
> What's next? RIR competition? :-)
>
> On Saturday, February 8, 2014, Owen DeLong <owen at delong.com> wrote:
>
>  I'm sure it insures something. I'm not sure an accurate registry is what
> it insures.
>
>
>
> Owen
>
>
>
> On Feb 7, 2014, at 18:07 , Martin Hannigan <hannigan at gmail.com> wrote:
>
>
>
>
>
> RIPE-605 is now policy in the RIPE region.
>
> 1. Provides registry services to legacy holders without contractual
> requirement
>
> 2. Excludes legacy holders from RIPE policy purview, past-present-future
>
> 3. Can revert a legacy block under contract back to a non-contract state
>
> 4. Reversion concept = "real property"
>
> This is certainly one way to insure an accurate registry.
>
> See RIPE-605 here: http://bit.ly/MzbmZ1
>
> 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.
>
>
>
>
> _______________________________________________
> 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
http://chrisgrundemann.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140210/757e0962/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 1468 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140210/757e0962/attachment.jpg>

From bill at herrin.us  Mon Feb 10 11:28:56 2014
From: bill at herrin.us (William Herrin)
Date: Mon, 10 Feb 2014 11:28:56 -0500
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <52F8E9F5.7040202@umn.edu>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>
	<CAP-guGWz6R8d1qM3B_eP1Ned9DVQC0XWtSht8VFZ3hWeZt6NAA@mail.gmail.com>
	<52F57CEB.1040909@umn.edu>
	<CAP-guGWDH7i5MpjoDApqedwCitKRFGnD+-dtAoYPQF+e2wU7Ng@mail.gmail.com>
	<52F8E9F5.7040202@umn.edu>
Message-ID: <CAP-guGXgjnd=W6W8Bif=P0bC1HZdbGhRtpD84=yECCd9zEOrbA@mail.gmail.com>

On Mon, Feb 10, 2014 at 10:02 AM, David Farmer <farmer at umn.edu> wrote:
> On 2/7/14, 22:58 , William Herrin wrote:
>> You pulled a TLDR on me. Like I said at the end of the message: after
>> you admit that the reason you (the general you, not you specifically)
>> don't want this policy is that you've knowingly been doing things
>> wrong for the last decade plus, you add the following sentence to the
>> still concise policy.
>
>
> How do you justify saying they've been doing anything wrong? Nothing in
> policy says that its wrong.  The only thing in policy, says is ARIN's
> primary role is issuing resources for use within the region.

Hi David,

Asked and answered. I'm also very comfortable declaring spam as
"wrong," even the stuff that isn't outright illegal.

When one competitor has greater regulatory access to resources than
another, you set the stage for anti-competitive practices. When that
extra access is used to ease one's burden to a competitor's detriment,
it's wrong. Quintessentially unfair. Whether or not it's against the
letter of the rules.

The address shortage has exacerbated the problem and it isn't likely
to wane on its own for the remainder of IPv4's useful lifespan.

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 george.herbert at gmail.com  Mon Feb 10 15:23:40 2014
From: george.herbert at gmail.com (George Herbert)
Date: Mon, 10 Feb 2014 12:23:40 -0800
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <CAP-guGXgjnd=W6W8Bif=P0bC1HZdbGhRtpD84=yECCd9zEOrbA@mail.gmail.com>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>
	<CAP-guGWz6R8d1qM3B_eP1Ned9DVQC0XWtSht8VFZ3hWeZt6NAA@mail.gmail.com>
	<52F57CEB.1040909@umn.edu>
	<CAP-guGWDH7i5MpjoDApqedwCitKRFGnD+-dtAoYPQF+e2wU7Ng@mail.gmail.com>
	<52F8E9F5.7040202@umn.edu>
	<CAP-guGXgjnd=W6W8Bif=P0bC1HZdbGhRtpD84=yECCd9zEOrbA@mail.gmail.com>
Message-ID: <CAK__KzvR2w9wWbMsM6NbgNV6wborvMuFDCjssit-9JaJ5F-7aQ@mail.gmail.com>

No, not asked and answered.

You have not established that the community interpreted the policy, or "the
right thing to do", as you are attempting to assert here and with the
proposed policy change.  Given the pushback, it is evident that the exact
opposite is true.  Most people seem to want more explanation of why the
existing situation is in fact a problem, or disagree with your assertion
that it is.

You don't have to convince you; you have to convince US.



On Mon, Feb 10, 2014 at 8:28 AM, William Herrin <bill at herrin.us> wrote:

> On Mon, Feb 10, 2014 at 10:02 AM, David Farmer <farmer at umn.edu> wrote:
> > On 2/7/14, 22:58 , William Herrin wrote:
> >> You pulled a TLDR on me. Like I said at the end of the message: after
> >> you admit that the reason you (the general you, not you specifically)
> >> don't want this policy is that you've knowingly been doing things
> >> wrong for the last decade plus, you add the following sentence to the
> >> still concise policy.
> >
> >
> > How do you justify saying they've been doing anything wrong? Nothing in
> > policy says that its wrong.  The only thing in policy, says is ARIN's
> > primary role is issuing resources for use within the region.
>
> Hi David,
>
> Asked and answered. I'm also very comfortable declaring spam as
> "wrong," even the stuff that isn't outright illegal.
>
> When one competitor has greater regulatory access to resources than
> another, you set the stage for anti-competitive practices. When that
> extra access is used to ease one's burden to a competitor's detriment,
> it's wrong. Quintessentially unfair. Whether or not it's against the
> letter of the rules.
>
> The address shortage has exacerbated the problem and it isn't likely
> to wane on its own for the remainder of IPv4's useful lifespan.
>
> 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
> _______________________________________________
> 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.
>



-- 
-george william herbert
george.herbert at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140210/84e181c0/attachment.htm>

From farmer at umn.edu  Mon Feb 10 16:08:57 2014
From: farmer at umn.edu (David Farmer)
Date: Mon, 10 Feb 2014 15:08:57 -0600
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <20140210181629.GS23819@mx1.yitter.info>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>	<CAP-guGWz6R8d1qM3B_eP1Ned9DVQC0XWtSht8VFZ3hWeZt6NAA@mail.gmail.com>	<52F57CEB.1040909@umn.edu>	<CAP-guGWDH7i5MpjoDApqedwCitKRFGnD+-dtAoYPQF+e2wU7Ng@mail.gmail.com>	<52F8E9F5.7040202@umn.edu>
	<20140210153034.GF23819@mx1.yitter.info>	<CAGkMwz5frXKeoht57YqY01CRFbW+KhLx4urY63_0sSaxTJBQDw@mail.gmail.com>	<20140210171940.GR23819@mx1.yitter.info>	<61acdc4c94f7439c9c34e3eed1d1a2a4@EX13-MBX-13.ad.syr.edu>
	<20140210181629.GS23819@mx1.yitter.info>
Message-ID: <52F93FE9.3090906@umn.edu>

On 2/10/14, 12:16 , Andrew Sullivan wrote:
> On Mon, Feb 10, 2014 at 05:55:18PM +0000, Milton L Mueller wrote:
>>
>> Let me repeat Scott's question in a different way: David Farmer says "we need to clarify that our of region use was always intended to be allowed by policy" and you agreed very strongly with him, and 2014-1 does that. Are you still maintaining that you are opposed to 2014-1?
>>
>
> I should have trimmed that last sentence, actually.  (I apologise for
> being so careless.  I'm unusually obtuse today, which is saying
> something).  The main thing that I wanted to agree with was that the
> historic policies were ambiguous and that anyone who thinks they're
> going to fix that with a lot of tight controls is mistaken, so we have
> to live with the consequences.
>
> To me, this new proposal is worse than doing nothing.  I prefer it
> over previously-floated alternatives (which seemed to me to be
> attempting to create a new policy that was never there).  So, if a
> policy is going to be adopted, I can stand this, but I don't think any
> policy is actually needed here.

Andrew,

If we were only considering IPv4, I would very much agree with you, 
"move along, there's no problem worth solving here".

However, we also have IPv6 to consider as well.  I feel there actually 
is a problem worth solving here for IPv6.  Hopefully, everyone is busy, 
or soon will be, deploying their IPv6 networks, some of those networks 
will have a global reach.  Many people are under, what I think is, a 
misconception that you MUST get IPv6 resources from all five RIRs to 
deploy a global IPv6 network.  While I don't want to tell anyone they 
CAN NOT get resources from all five RIRs, if they wish.  I very much 
don't want them to do that just because of a misconception that they CAN 
NOT get there global resources from one Primary RIR, if they wish.

For an example of what I'm talking about, see the following, jump to 
time stamp 1:34:20 for the specific conversation;
http://new.livestream.com/internetsociety/INETDenver2013

So, I believe this is a problem we can and should solve now, before the 
vast majority of enterprises deploy their IPv6 networks, especially 
large international enterprises.  Preventing unnecessary bloat of the 
IPv6 routing table, solely because of a policy misconception, seems 
worthy of action in my opinion.  This is something we can fix now and if 
we wait until later it may not be, like it mostly is mostly too late for 
IPv4 now.

My personal motivations for working on this issue has been IPv6.  The 
problem is as soon as you touch this issue everybody assumes its all 
about IPv4.  However, for me this is much more about the future of IPv6, 
which is something I hope everyone agrees is worth doing something 
about.  I believe if we really think out of region use is permitted we 
need to clear up this ambiguity and clearly permit out region use at 
least for IPv6.  Otherwise, we need to be clear it is not permitted at 
least for IPv6.  Leaving this issue ambiguous for another generation of 
technology, is just asking for similar problem with IPv6 in a decade or two.

Now, if you think a simpler out of region policy would be better, I'd be 
fine with that.  Much of the complexity comes from the assumption this 
is about IPv4.  Also, if you think it would be better to deal with this 
only for IPv6, I'd be fine with that too.  However, if we fix the issue 
for IPv6 only, I'm concerned in contrast it only exacerbates the issues 
for IPv4.

Recommendations anyone?

Thanks.

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


From David.Huberman at microsoft.com  Mon Feb 10 16:31:48 2014
From: David.Huberman at microsoft.com (David Huberman)
Date: Mon, 10 Feb 2014 21:31:48 +0000
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <2fb97b02499741889d0b96fb40586780@EX13-MBX-13.ad.syr.edu>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>
	<0a573e7e5ec24a34bba99c20501e6e5f@DM2PR03MB398.namprd03.prod.outlook.com>
	<2fb97b02499741889d0b96fb40586780@EX13-MBX-13.ad.syr.edu>
Message-ID: <d362165238df4f659b9d63dbdc8b1b2a@DM2PR03MB398.namprd03.prod.outlook.com>

Hello Milton,

> While couched as opposition your post agrees with the problem statement that "Earlier work on this issue has
>  explored several options to restrict or otherwise limit out of region use. None of these options have gained 
> consensus within the community." So there is no basis for opposition there. 

Correct.

>  I would conclude, however, that you do _not_ agree with the problem statement that "Current policy neither 
> clearly forbids nor clearly permits out of region use of ARIN registered resources." You seem to believe that it
> is already permitted, which makes the proposal a no-op. Is that right?

Not quite.  

The truth of the matter is that ARIN has operated for a very long time under a rule discussed many times between the RIRs' RS staff:

"The block must be routed from equipment within the RIR's region".  

Often times that's just anchoring the least specific.   It was a very solid rule which gave international backbone operators the flexibility to use the RIR they wanted for their needs, because they anchored routes everywhere.

If a content provider doesn't run an international backbone, and that content provider has its customers and equipment in, say, Malaysia, then they would generally be unable to obtain space from ARIN.  The answer from ARIN for such a request would be, "No - got see APNIC or a local IR".

What changed was a year or two ago, some companies got pretty clever.  They actually moved their routers to datacenters on the NA west coast, and used layer 2 tunneling to get everything back to the Asian east coast. All of their customers are in Asia, and they only have a shell company set up in California for the purposes of receiving space from ARIN.

The problem was compounded by two factors:
1) Some of these content providers were really, really large. China, for example, is a really big place.  So the IP needs were larger than all but 1 or 2 ARIN customers.
2) Some of these requests were fraudulent.  Provide fraud when dealing with operations from a wholly different culture has proven to be exceedingly difficult and, honestly, beyond ARIN's considerable expertise.

This was the point at which the staff started bringing this to the PDP fora.  It started in 2011 in Philadelphia, more serious alarms were raised in Arizona, and those alarms continue today.

The community has been consistently deaf to these concerns.  Responses range from:
- I don't care; RIRs should just give space to operators who need them (region-agnostic)
to 
- I don't care; I can't wait for IPv4 to run out.

To some of us, these responses were disappointing.  I can appreciate the argument that the "Regional" part of Regional Internet Registries may now be past is usefulness.  But the argument has been very hard for me to swallow because there's just so much bad faith requesting going on, and it's almost all from extra-ARIN regions.

This is what staff has been trying to tell you (the PP community), and this is what you (the PP community) seem to say, "so what?" to.

[snip]

> Your second argument is that the staff already has all the tools it needs to do what is in section X.1. 
> This is not something the staff report said to us in its assessment, however, so I would discount that. 

You can discount it, but I respectfully say I'm right :)  I did do this, on the front lines, for 10 years, and Leslie and I developed ALL of the fraud protocols. 

> You main argument, therefore is that "out-of-region requestors [are] abusing the policies" and  "we need to 
> draft text that significantly and materially helps ARIN staff fight fraud from out-of-region requestors."
>  Apparently you think the authorization to engage external entities to help with verification does not 
> address that. Can you explain why? 

I feel like I have in my first response.  X.1 is no-op because nothing changes.  Staff already can and do conduct 
these types of activities when investigating fraud.  They may not have "engaged outside entities" to help with
investigation, but they've always had that purview (that is, with parties who would be under attorney-client 
privilege). 

Best regards,
David

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)


From David.Huberman at microsoft.com  Mon Feb 10 16:50:19 2014
From: David.Huberman at microsoft.com (David Huberman)
Date: Mon, 10 Feb 2014 21:50:19 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-3: Remove 8.2 and 8.3 and
 8.4 Minimum IPv4 Block Size Requirements
In-Reply-To: <CAAAwwbVvALyX=pQq0vVMg2TmvZKC+PDTbU+S4ZH+HJEkSWy4EQ@mail.gmail.com>
References: <52E91DAA.9090307@arin.net>
	<CAAAwwbVvALyX=pQq0vVMg2TmvZKC+PDTbU+S4ZH+HJEkSWy4EQ@mail.gmail.com>
Message-ID: <8ba8f0112c1e41408f7d32d8d8f729a8@DM2PR03MB398.namprd03.prod.outlook.com>

I am the author and I support this policy.

Jimmy, I'd like to respond to your points:

> (1) it is unnecessary.

Obviously, I disagree :)  I think it is a forward looking policy, asking the PPML to remove an arbitrary minimum barrier which is the purview of network operators, not address policy.  I run AS8075 (well, Vijay does - I work for Vijay) and only I get to say what size prefixes I will, and will not, export to my peers.  The IETF and the engineering community have never given that authority to ARIN

I characterize it as "forward looking" because it is removing an arbitrary barrier to success for later in the 8.3 and 8.4 transfer market lifetimes.


> (2) This is yet another IPv4-focused policy. ? At this point, ARIN should be essentially looking at IPv6 policies policies only, ?and not make changes that could adversly further affect IPv4 runout in problematic ways.

You're wrong here, sorry.  This policy only affects text in 8.2, 8.3, and 8.4, which are transfer sections.   Transfers are going to be the only significant work that the Registry does in the foreseeable future, so it's very relevant to tomorrow's ARIN.


> (3) Free pools are not yet exhausted, ?so interest in 8.3 transfers cannot yet be regarded or observed in any terms --- ?let alone to show that ?"available /24s and longer" are inadequate,

In the world today, 8.3 transfers are very active.  Hundreds of blocks are changing hands every year.  That's almost as many allocations and assignments as ARIN gives out annually.  While I agree that sub-/24 blocks aren't quite relevant today, I strongly disagree they won't be relevant tomorrow.  


> (4) IPv6 is likely to be adopted more heavily, ?obviating the usefulness of any attempts to increase the number of ?resource transfers occuring.

Strongly disagree.  Despite the best efforts of fine engineers like Owen DeLong and his excellent employer Hurricane Electric, IPv6 is already a legacy protocol, and adoption is very very slow.  Moreover, the number of IPv4-only networks dwarfs the number of IPv6-capable networks by a factor of a few million to one.    I do not believe IPv6 will ever reach even 50% deployment in this world.  That's just an opinion, but I'm trying to back up my disagreement with your assertion.


> (5) Prefixes of /24 and larger will most likely be available over specified transfer, and ?(4) ?Allowing attempts to fragment /24s in IPv4 ?do not significantly delay exhaustion of IPv4, but 
> instead is a potential source of a great deal of pain.
and
> (6) Disagree with   "allowing networks to move blocks around as they see fit".    The manner "in which some networks see fit"  is not necessarily a good thing  for the level of global routing 
> table bloat.

This isn't 1995 or even 2005 anymore. We have over 400,000 routes in the DFZ and large network routing tables are in the millions.  10,000 or even 100,000 sub-/24 route announcements isn't going to stop BGP from converging.

> (7) A problem is: ?as long as routes for these prefixes would hypothetically be accepted, the networks who "see fit to move smaller blocks around and fragment /24s into 
> small chunks ?to sell off IP by IP" ?are not bearing the cost of their actions --- ?other ARIN members would be ?essentially ?forced ?to bear costs.

That's not the purview of ARIN.  It is up to each individual network operator to decide what routes she will, or will not, accept.

> (8) And I would say that at this point, the /24 ?minimum is not an arbitrary minimum. By de-facto standard, ?no longer prefix is permissible ?to be announced.

Strongly disagree.  As Bill Manning always said, an operator will route whatever I pay them to route.




From scottleibrand at gmail.com  Mon Feb 10 11:53:43 2014
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Mon, 10 Feb 2014 08:53:43 -0800
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <20140210153034.GF23819@mx1.yitter.info>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>
	<CAP-guGWz6R8d1qM3B_eP1Ned9DVQC0XWtSht8VFZ3hWeZt6NAA@mail.gmail.com>
	<52F57CEB.1040909@umn.edu>
	<CAP-guGWDH7i5MpjoDApqedwCitKRFGnD+-dtAoYPQF+e2wU7Ng@mail.gmail.com>
	<52F8E9F5.7040202@umn.edu> <20140210153034.GF23819@mx1.yitter.info>
Message-ID: <CAGkMwz5frXKeoht57YqY01CRFbW+KhLx4urY63_0sSaxTJBQDw@mail.gmail.com>

Andrew,

So are you in favor of or opposed to 2014-1, which explicitly permits
out-of-region use?  It sounds like you're opposed to efforts to "do
something here" that restricts allocations based on region.  Since you
think "policies, if they are to be adopted, ought to reinforce the
historically permissive stance ARIN has taken", do you favor 2014-1 as
written?  Or do you have any suggestions for how to improve it?

Thanks,
Scott


On Mon, Feb 10, 2014 at 7:30 AM, Andrew Sullivan <ajs at anvilwalrusden.com>wrote:

> On Mon, Feb 10, 2014 at 09:02:13AM -0600, David Farmer wrote:
>
> > We (globally) created a run-out scheme that was going to be uneven.
> > There was at least one rejected proposal that tried to even out the
> > run-out across the RIRs.  Unfortunately, I think we just need to
> > live with the consequences of our actions, or inaction in this case.
>
> > As the problem statement says, I think the real problem is that
> > policy is ambiguous on the subject of out of region use.  Which
> > means there are some in the community that think out of region use
> > is outside the rules, as you seem to think.  Then others think it is
> > perfectly normal and has always been allowed, because its never been
> > disallowed in policy.  I think we need to clarify that out of region
> > use was always intended to be allowed by policy.
>
> I am normally loathe to say "+1", but I have to agree very strongly
> with the above.  The impulse to try to do something here is
> well-intended but badly misguided.  It will have negative side effects
> as one tries to write exceptional exceptions for the exceptionally
> exceptional case.  The reason clich?s are clich? is that they express
> a truth, and in this case the clich?, "Hard cases make bad law,"
> applies.  New policies, if they are to be adopted, ought to reinforce
> the historically permissive stance ARIN has taken.
>
> Will that have the consequence that some will come "out of region" and
> incorporate for convenience and try to corner the market on the
> remaining IPv4?  Yes.  The idea that ARIN can make a policy that will
> successfully stanch the well-known problems of speculation and gaming
> in commodity markets during scarcity and without doing incidental
> damage is, I think, too ambitious.
>
> Best regards,
>
> Andrew (I work for Dyn.  The above remarks may not reflect their
> opinion.)
>
> --
> Andrew Sullivan
> ajs at anvilwalrusden.com
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140210/003796ec/attachment.htm>

From farmer at umn.edu  Mon Feb 10 17:56:46 2014
From: farmer at umn.edu (David Farmer)
Date: Mon, 10 Feb 2014 16:56:46 -0600
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <d362165238df4f659b9d63dbdc8b1b2a@DM2PR03MB398.namprd03.prod.outlook.com>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>	<0a573e7e5ec24a34bba99c20501e6e5f@DM2PR03MB398.namprd03.prod.outlook.com>	<2fb97b02499741889d0b96fb40586780@EX13-MBX-13.ad.syr.edu>
	<d362165238df4f659b9d63dbdc8b1b2a@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <52F9592E.6070203@umn.edu>

On 2/10/14, 15:31 , David Huberman wrote:

>> Your second argument is that the staff already has all the tools it needs to do what is in section X.1.
>> This is not something the staff report said to us in its assessment, however, so I would discount that.
>
> You can discount it, but I respectfully say I'm right :)  I did do this, on the front lines, for 10 years, and Leslie and I developed ALL of the fraud protocols.
>
>> You main argument, therefore is that "out-of-region requestors [are] abusing the policies" and  "we need to
>> draft text that significantly and materially helps ARIN staff fight fraud from out-of-region requestors."
>>   Apparently you think the authorization to engage external entities to help with verification does not
>> address that. Can you explain why?
>
> I feel like I have in my first response.  X.1 is no-op because nothing changes.  Staff already can and do conduct
> these types of activities when investigating fraud.  They may not have "engaged outside entities" to help with
> investigation, but they've always had that purview (that is, with parties who would be under attorney-client
> privilege).

For the most part I agree x.1 is basically a no-op, if you are assuming 
that out of region use has been permitted all along.  However, not 
everyone makes that assumption.  If you make the opposite assumption, 
that out of region use has never been permitted, then it absolutely 
isn't a no-op, its a major policy shift.

In my opinion, the reason we can't make any headway on dealing with the 
issues staff has reported is the ambiguity of the status of out of 
region use has to begin with.  Hence the problem statement put forward.

Their are those that seem to oppose any acknowledgment of out of region 
use all together.  And there solution to staff's issue is deny all out 
of region use.  On the other side, we have those refuse to acknowledge 
there can and should be any limits on out of region use.  Mix in those 
that think we shouldn't be doing anything about IPv4 policy at all. 
Then we have a quagmire that is worse than the transfer policy issues 
several years ago.

Personally, I think we have to clarify out of region use before we can 
come to any rational policy discussion that deals with the issue staff 
has raised.  Again, hence the problem statement put forward.


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


From jeffrey.lyon at blacklotus.net  Mon Feb 10 18:06:16 2014
From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon)
Date: Tue, 11 Feb 2014 08:06:16 +0900
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <52F9592E.6070203@umn.edu>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>
	<0a573e7e5ec24a34bba99c20501e6e5f@DM2PR03MB398.namprd03.prod.outlook.com>
	<2fb97b02499741889d0b96fb40586780@EX13-MBX-13.ad.syr.edu>
	<d362165238df4f659b9d63dbdc8b1b2a@DM2PR03MB398.namprd03.prod.outlook.com>
	<52F9592E.6070203@umn.edu>
Message-ID: <CACrmG8ftkG8XUNy07X5OJ=YyAS=DCiTq4mNOtdkJGRiz3H9FBw@mail.gmail.com>

David,

I am not referencing policy, but the auto-template ARIN sent me during
our last resource request explicitly stated no out of region use which
forced us to register as RIPE LIR for a single out of country POP.

Thanks, Jeff

On Tue, Feb 11, 2014 at 7:56 AM, David Farmer <farmer at umn.edu> wrote:
> On 2/10/14, 15:31 , David Huberman wrote:
>
>>> Your second argument is that the staff already has all the tools it needs
>>> to do what is in section X.1.
>>> This is not something the staff report said to us in its assessment,
>>> however, so I would discount that.
>>
>>
>> You can discount it, but I respectfully say I'm right :)  I did do this,
>> on the front lines, for 10 years, and Leslie and I developed ALL of the
>> fraud protocols.
>>
>>> You main argument, therefore is that "out-of-region requestors [are]
>>> abusing the policies" and  "we need to
>>> draft text that significantly and materially helps ARIN staff fight fraud
>>> from out-of-region requestors."
>>>   Apparently you think the authorization to engage external entities to
>>> help with verification does not
>>> address that. Can you explain why?
>>
>>
>> I feel like I have in my first response.  X.1 is no-op because nothing
>> changes.  Staff already can and do conduct
>> these types of activities when investigating fraud.  They may not have
>> "engaged outside entities" to help with
>> investigation, but they've always had that purview (that is, with parties
>> who would be under attorney-client
>> privilege).
>
>
> For the most part I agree x.1 is basically a no-op, if you are assuming that
> out of region use has been permitted all along.  However, not everyone makes
> that assumption.  If you make the opposite assumption, that out of region
> use has never been permitted, then it absolutely isn't a no-op, its a major
> policy shift.
>
> In my opinion, the reason we can't make any headway on dealing with the
> issues staff has reported is the ambiguity of the status of out of region
> use has to begin with.  Hence the problem statement put forward.
>
> Their are those that seem to oppose any acknowledgment of out of region use
> all together.  And there solution to staff's issue is deny all out of region
> use.  On the other side, we have those refuse to acknowledge there can and
> should be any limits on out of region use.  Mix in those that think we
> shouldn't be doing anything about IPv4 policy at all. Then we have a
> quagmire that is worse than the transfer policy issues several years ago.
>
> Personally, I think we have to clarify out of region use before we can come
> to any rational policy discussion that deals with the issue staff has
> raised.  Again, hence the problem statement put forward.
>
>
> --
> ================================================
> David Farmer               Email: farmer at umn.edu
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE     Phone: 1-612-626-0815
> Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
> ================================================
>
> _______________________________________________
> 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 A. Lyon, CISSP-ISSMP
Founder, Black Lotus Communications
mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net


From David.Huberman at microsoft.com  Mon Feb 10 18:12:08 2014
From: David.Huberman at microsoft.com (David Huberman)
Date: Mon, 10 Feb 2014 23:12:08 +0000
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <CACrmG8ftkG8XUNy07X5OJ=YyAS=DCiTq4mNOtdkJGRiz3H9FBw@mail.gmail.com>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>
	<0a573e7e5ec24a34bba99c20501e6e5f@DM2PR03MB398.namprd03.prod.outlook.com>
	<2fb97b02499741889d0b96fb40586780@EX13-MBX-13.ad.syr.edu>
	<d362165238df4f659b9d63dbdc8b1b2a@DM2PR03MB398.namprd03.prod.outlook.com>
	<52F9592E.6070203@umn.edu>
	<CACrmG8ftkG8XUNy07X5OJ=YyAS=DCiTq4mNOtdkJGRiz3H9FBw@mail.gmail.com>
Message-ID: <7a2643d1e93846768df0b820cf72d7ea@DM2PR03MB398.namprd03.prod.outlook.com>

Yep.  The traditional anti-RIR shopping rule is unpublished.  It's a common sense rule that the RIRs applied for many years to deal with RIR shoppers and to deal with international backbones.  Once APNIC ran out, however, chaos entered into the equation.  Hence where I believe we are today.

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)

-----Original Message-----
From: jeffrey.lyon at gmail.com [mailto:jeffrey.lyon at gmail.com] On Behalf Of Jeffrey Lyon
Sent: Monday, February 10, 2014 3:06 PM
To: David Farmer
Cc: David Huberman; Milton L Mueller; ARIN PPML (ppml at arin.net)
Subject: Re: [arin-ppml] support for 2014-1 (out of region use)

David,

I am not referencing policy, but the auto-template ARIN sent me during our last resource request explicitly stated no out of region use which forced us to register as RIPE LIR for a single out of country POP.

Thanks, Jeff

On Tue, Feb 11, 2014 at 7:56 AM, David Farmer <farmer at umn.edu> wrote:
> On 2/10/14, 15:31 , David Huberman wrote:
>
>>> Your second argument is that the staff already has all the tools it 
>>> needs to do what is in section X.1.
>>> This is not something the staff report said to us in its assessment, 
>>> however, so I would discount that.
>>
>>
>> You can discount it, but I respectfully say I'm right :)  I did do 
>> this, on the front lines, for 10 years, and Leslie and I developed 
>> ALL of the fraud protocols.
>>
>>> You main argument, therefore is that "out-of-region requestors [are] 
>>> abusing the policies" and  "we need to draft text that significantly 
>>> and materially helps ARIN staff fight fraud from out-of-region 
>>> requestors."
>>>   Apparently you think the authorization to engage external entities 
>>> to help with verification does not address that. Can you explain 
>>> why?
>>
>>
>> I feel like I have in my first response.  X.1 is no-op because 
>> nothing changes.  Staff already can and do conduct these types of 
>> activities when investigating fraud.  They may not have "engaged 
>> outside entities" to help with investigation, but they've always had 
>> that purview (that is, with parties who would be under 
>> attorney-client privilege).
>
>
> For the most part I agree x.1 is basically a no-op, if you are 
> assuming that out of region use has been permitted all along.  
> However, not everyone makes that assumption.  If you make the opposite 
> assumption, that out of region use has never been permitted, then it 
> absolutely isn't a no-op, its a major policy shift.
>
> In my opinion, the reason we can't make any headway on dealing with 
> the issues staff has reported is the ambiguity of the status of out of 
> region use has to begin with.  Hence the problem statement put forward.
>
> Their are those that seem to oppose any acknowledgment of out of 
> region use all together.  And there solution to staff's issue is deny 
> all out of region use.  On the other side, we have those refuse to 
> acknowledge there can and should be any limits on out of region use.  
> Mix in those that think we shouldn't be doing anything about IPv4 
> policy at all. Then we have a quagmire that is worse than the transfer policy issues several years ago.
>
> Personally, I think we have to clarify out of region use before we can 
> come to any rational policy discussion that deals with the issue staff 
> has raised.  Again, hence the problem statement put forward.
>
>
> --
> ================================================
> David Farmer               Email: farmer at umn.edu
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE     Phone: 1-612-626-0815
> Minneapolis, MN 55414-3029  Cell: 1-612-812-9952 
> ================================================
>
> _______________________________________________
> 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 A. Lyon, CISSP-ISSMP
Founder, Black Lotus Communications
mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net


From bill at herrin.us  Mon Feb 10 17:22:10 2014
From: bill at herrin.us (William Herrin)
Date: Mon, 10 Feb 2014 17:22:10 -0500
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <CAK__KzvR2w9wWbMsM6NbgNV6wborvMuFDCjssit-9JaJ5F-7aQ@mail.gmail.com>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>
	<CAP-guGWz6R8d1qM3B_eP1Ned9DVQC0XWtSht8VFZ3hWeZt6NAA@mail.gmail.com>
	<52F57CEB.1040909@umn.edu>
	<CAP-guGWDH7i5MpjoDApqedwCitKRFGnD+-dtAoYPQF+e2wU7Ng@mail.gmail.com>
	<52F8E9F5.7040202@umn.edu>
	<CAP-guGXgjnd=W6W8Bif=P0bC1HZdbGhRtpD84=yECCd9zEOrbA@mail.gmail.com>
	<CAK__KzvR2w9wWbMsM6NbgNV6wborvMuFDCjssit-9JaJ5F-7aQ@mail.gmail.com>
Message-ID: <CAP-guGXHYucomS-eUU8zboKYEnHQFhNSE=C8AQg3qKie4Darag@mail.gmail.com>

On Mon, Feb 10, 2014 at 3:23 PM, George Herbert
<george.herbert at gmail.com> wrote:
> You have not established that the community interpreted the policy, or "the
> right thing to do", as you are attempting to assert here and with the
> proposed policy change.

Hi George,

I haven't even attempted to establish that "the community" considers
out-region use of resources abusive. Why would I? I'd have better luck
convincing politicians that survey and political robocalls are
abusive.

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 jcurran at arin.net  Mon Feb 10 18:31:40 2014
From: jcurran at arin.net (John Curran)
Date: Mon, 10 Feb 2014 23:31:40 +0000
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <CACrmG8ftkG8XUNy07X5OJ=YyAS=DCiTq4mNOtdkJGRiz3H9FBw@mail.gmail.com>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>
	<0a573e7e5ec24a34bba99c20501e6e5f@DM2PR03MB398.namprd03.prod.outlook.com>
	<2fb97b02499741889d0b96fb40586780@EX13-MBX-13.ad.syr.edu>
	<d362165238df4f659b9d63dbdc8b1b2a@DM2PR03MB398.namprd03.prod.outlook.com>
	<52F9592E.6070203@umn.edu>
	<CACrmG8ftkG8XUNy07X5OJ=YyAS=DCiTq4mNOtdkJGRiz3H9FBw@mail.gmail.com>
Message-ID: <DF26F0E7-035F-4E4E-98F5-06D41C58FA96@arin.net>

On Feb 10, 2014, at 6:06 PM, Jeffrey Lyon <jeffrey.lyon at blacklotus.net> wrote:
> ...
> I am not referencing policy, but the auto-template ARIN sent me during
> our last resource request explicitly stated no out of region use which
> forced us to register as RIPE LIR for a single out of country POP.

As ARIN's primary role includes management and issuance of number resources
_within our region_ (NRPM 2.2), this is reflected in the request template
that you received.  The language is potentially overly strident, and I will
note that was our intent to update the template language once the community 
had a chance to clarify its intent (ref: attached ppml email from 6 October
2013 to the ppml mailing list)

At this point, it would appear to best to hold off on any template changes
until after the April meeting and discussion of Draft Policy 2014-1.

Thanks!
/John 

John Curran
President and CEO
ARIN

===

> From: John Curran <jcurran at arin.net>
> Subject: Re: [arin-ppml] Out-of-region overreaction?
> Date: October 6, 2013 at 12:07:53 AM EDT
> To: Frank Bulk <frnkblk at iname.com>
> Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
> 
> On Oct 4, 2013, at 1:31 PM, Frank Bulk <frnkblk at iname.com> wrote:
> 
>> If I could be so bold, I'd suggest ARIN to use language something along
>> these lines in their communications:
>> 
>> 	Please reply and verify that you will be using 
>> 	the requested number resources primarily within the 
>> 	ARIN region and announcing the majority of routing prefixes
>> 	of the requested space from within the ARIN region. 
>> 	In accordance with section 2.2 of the NRPM, ARIN issues 
>> 	number resources within its region. 
> 
> Frank - 
> 
>  We're happy to review the wording of the communications (and will
>  do so upon disposition of Draft Policy ARIN-2013-6.)
> 
> Thanks!
> /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 farmer at umn.edu  Mon Feb 10 19:10:26 2014
From: farmer at umn.edu (David Farmer)
Date: Mon, 10 Feb 2014 18:10:26 -0600
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <DF26F0E7-035F-4E4E-98F5-06D41C58FA96@arin.net>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>	<0a573e7e5ec24a34bba99c20501e6e5f@DM2PR03MB398.namprd03.prod.outlook.com>	<2fb97b02499741889d0b96fb40586780@EX13-MBX-13.ad.syr.edu>	<d362165238df4f659b9d63dbdc8b1b2a@DM2PR03MB398.namprd03.prod.outlook.com>	<52F9592E.6070203@umn.edu>	<CACrmG8ftkG8XUNy07X5OJ=YyAS=DCiTq4mNOtdkJGRiz3H9FBw@mail.gmail.com>
	<DF26F0E7-035F-4E4E-98F5-06D41C58FA96@arin.net>
Message-ID: <52F96A72.1030402@umn.edu>

On 2/10/14, 17:31 , John Curran wrote:
> As ARIN's primary role includes management and issuance of number resources
> _within our region_ (NRPM 2.2), this is reflected in the request template
> that you received.  The language is potentially overly strident, and I will
> note that was our intent to update the template language once the community
> had a chance to clarify its intent (ref: attached ppml email from 6 October
> 2013 to the ppml mailing list)
>
> At this point, it would appear to best to hold off on any template changes
> until after the April meeting and discussion of Draft Policy 2014-1.
>
> Thanks!
> /John
>
> John Curran
> President and CEO
> ARIN

John,

Thanks for that reminder.

One small clarification, is this wording change applicable only to IPv4 
requests or to both IPv4 and IPv6 requests?



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


From gary.buhrmaster at gmail.com  Mon Feb 10 19:05:16 2014
From: gary.buhrmaster at gmail.com (Gary Buhrmaster)
Date: Tue, 11 Feb 2014 00:05:16 +0000
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <52F9592E.6070203@umn.edu>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>
	<0a573e7e5ec24a34bba99c20501e6e5f@DM2PR03MB398.namprd03.prod.outlook.com>
	<2fb97b02499741889d0b96fb40586780@EX13-MBX-13.ad.syr.edu>
	<d362165238df4f659b9d63dbdc8b1b2a@DM2PR03MB398.namprd03.prod.outlook.com>
	<52F9592E.6070203@umn.edu>
Message-ID: <CAMfXtQwGnpY7M-2TerrNGRUcGVnzmfJTv5+FnxPfSbE-qg8pDA@mail.gmail.com>

On Mon, Feb 10, 2014 at 10:56 PM, David Farmer <farmer at umn.edu> wrote:
....
> Personally, I think we have to clarify out of region use before we can come
> to any rational policy discussion that deals with the issue staff has
> raised.  Again, hence the problem statement put forward.

And due to that inability to come to any clear (to me) consensus
on whether more than incidental out-of-region use is acceptable
is the reason I feel that I have to oppose 2014-1 as written, as it
codifies in policy what is not clear (to me) is anywhere near a
consensus in the community.

In practice, I think that means that the current use of ARIN
as a RIR of last resort will continue by some.  That is also
a bad result.

I believe I have stated before that I believe that at least a
plurality of resources should be used in the region of the
RIR that provides them.  I am not in favor of ARIN becoming
yet again the one registry to rule them all, no matter what
ring we might forge for John.

Gary


From jcurran at arin.net  Mon Feb 10 19:17:46 2014
From: jcurran at arin.net (John Curran)
Date: Tue, 11 Feb 2014 00:17:46 +0000
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <52F96A72.1030402@umn.edu>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>
	<0a573e7e5ec24a34bba99c20501e6e5f@DM2PR03MB398.namprd03.prod.outlook.com>
	<2fb97b02499741889d0b96fb40586780@EX13-MBX-13.ad.syr.edu>
	<d362165238df4f659b9d63dbdc8b1b2a@DM2PR03MB398.namprd03.prod.outlook.com>
	<52F9592E.6070203@umn.edu>
	<CACrmG8ftkG8XUNy07X5OJ=YyAS=DCiTq4mNOtdkJGRiz3H9FBw@mail.gmail.com>
	<DF26F0E7-035F-4E4E-98F5-06D41C58FA96@arin.net>
	<52F96A72.1030402@umn.edu>
Message-ID: <9A3CB4BD-51AD-4C60-AE69-0E1FE290C3D1@arin.net>

On Feb 10, 2014, at 7:10 PM, David Farmer <farmer at umn.edu> wrote:

> On 2/10/14, 17:31 , John Curran wrote:
>> As ARIN's primary role includes management and issuance of number resources
>> _within our region_ (NRPM 2.2), this is reflected in the request template
>> that you received.  The language is potentially overly strident, and I will
>> note that was our intent to update the template language once the community
>> had a chance to clarify its intent (ref: attached ppml email from 6 October
>> 2013 to the ppml mailing list)
>> 
>> At this point, it would appear to best to hold off on any template changes
>> until after the April meeting and discussion of Draft Policy 2014-1.
>> 
>> Thanks!
>> /John
>> 
>> John Curran
>> President and CEO
>> ARIN
> 
> John,
> 
> Thanks for that reminder.
> 
> One small clarification, is this wording change applicable only to IPv4 requests or to both IPv4 and IPv6 requests?

David - 
 
  Unless otherwise directed by the community, we would update both templates to 
  indicate that we issue number resources for use in the region.  I believe that
  "no out of region use" is overly strident and hence we will remove that since
  it is not clearly called out in policy (and this all presumes that we do not 
  receive more specific guidance from the community in these matters by that time)

Thanks!
/John

John Curran
President and CEO
ARIN



From mysidia at gmail.com  Mon Feb 10 20:31:39 2014
From: mysidia at gmail.com (Jimmy Hess)
Date: Mon, 10 Feb 2014 19:31:39 -0600
Subject: [arin-ppml] Draft Policy ARIN-2014-3: Remove 8.2 and 8.3 and
 8.4 Minimum IPv4 Block Size Requirements
In-Reply-To: <8ba8f0112c1e41408f7d32d8d8f729a8@DM2PR03MB398.namprd03.prod.outlook.com>
References: <52E91DAA.9090307@arin.net>
	<CAAAwwbVvALyX=pQq0vVMg2TmvZKC+PDTbU+S4ZH+HJEkSWy4EQ@mail.gmail.com>
	<8ba8f0112c1e41408f7d32d8d8f729a8@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <CAAAwwbV7t9hQG_CHjjMayR0UL7Ap=QHJkrkLRoLDToF2KUFyXw@mail.gmail.com>

On Mon, Feb 10, 2014 at 3:50 PM, David Huberman <
David.Huberman at microsoft.com> wrote:

> I am the author and I support this policy.  Jimmy, I'd like to respond to
> your points:
>


> Obviously, I disagree :)  I think it is a forward looking policy, asking
> the PPML to remove an arbitrary minimum barrier which is the purview of
> network operators, not


Hi.   The choice of announced prefix size is not entirely within the
purview of network operators.     IN FACT;   whatever address size of an
 allocation  ARIN chooses to allow to be created,  may tend to be highly
"coercive",    network operators may have little ability to refuse the
prefix,  once ARIN deems it legitimate.

The minimum size of a block allocated or transferred is well within the
purview of ARIN address policy,  and a major factor causing the minimum to
be  /24  instead of /32   IS hierarchical addressing,   aggregation,  AND
 also  routable prefix size.

Routing considerations DO have a legitimate affect on RIR addressing
policy.  Which is not entirely within the purview of network operators.

However, the ARIN RIR community itself  INCLUDES network operators.
 The establishment of a minimum allocation and transfer unit, is well
within ARIN's stewardship responsibilities.


> what size prefixes I will, and will not, export to my peers.  The IETF and
> the engineering community have never given that authority to ARIN
>

ARIN policy has the authoritiy to determine what address block sizes that
ARIN issues.
Restricting allocations smaller than a /24 services legitimate stewardship
requirements.

I characterize it as "forward looking" because it is removing an arbitrary
> barrier to success for later in the 8.3 and 8.4 transfer market lifetimes.
>

Requirement that blocks contain a reasonable minimum number of addresses,
so that routes can be aggregated, is not an arbitrary barrier --- it is a
reasonable barrier, that any responsible internet registry,  fulfilling its
 address stewardship requirements,  would have a minimum size for
allocations, transfers, etc.


> You're wrong here, sorry.  This policy only affects text in 8.2, 8.3, and
> 8.4, which are transfer sections.   Transfers are going to be the only
> significant work that the Registry does in the foreseeable future, so it's
> very relevant to tomorrow's ARIN.
>

IPv6 related transfers and allocations yes.   IPv4 is not particularly
relevant to tomorrow's ARIN.


> In the world today, 8.3 transfers are very active.  Hundreds of blocks are
> changing hands every year.  That's almost as many allocations and
> assignments as ARIN gives


Yes....  mere  _hundreds_  every year,   compared to _tens of thousands_
 of  new delegations.     The fact is;  the true lack of  interest in
transfers,  Versus IPv6 allocation, will have unknowns until  20000+
delegations CAN'T happen every year, anymore.


> (4) IPv6 is likely to be adopted more heavily,  obviating the usefulness
> of any attempts to increase the number of  resource transfers occuring.
>
> Strongly disagree.  Despite the best efforts of fine engineers like Owen
> DeLong and his excellent employer Hurricane Electric, IPv6 is already a
> legacy protocol, and

adoption is very very slow.  Moreover, the number of IPv4-only networks
> dwarfs the


All signs point to  the claim of V6 adoption being slow, as completely,
utterly incorrect.

"IPv6 is a legacy protocol"  is certainly a new one.


> (6) Disagree with   "allowing networks to move blocks around as they see
> fit".    The manner "in which some networks see fit"  is not necessarily a
> good thing  for the level of global routing
>
> This isn't 1995 or even 2005 anymore. We have over 400,000 routes in the
> DFZ and large network routing tables are in the millions.  10,000 or even
> 100,000 sub-/24 route announcements isn't going to stop BGP from converging.
>

"100,000" extra sub  /24 announcements, is a dramatic underestimate of what
is likely to happen,   if  there are  a large number of sub-/24  transfers.

Not that 10 to 100K extra routes is anything to sneeze at either.



> > (7) A problem is:  as long as routes for these prefixes would
> hypothetically be accepted, the networks who "see fit to move smaller
> blocks around and fragment /24s into
> > small chunks  to sell off IP by IP"  are not bearing the cost of their
> actions ---  other ARIN members would be  essentially  forced  to bear
> costs.
>
> That's not the purview of ARIN.  It is up to each individual network
> operator to decide what routes she will, or will not, accept.
>

No, the effect of any policy changes on routing considerations' and
potential network stability are definitely within the full purview of ARIN.



> > (8) And I would say that at this point, the /24  minimum is not an
> arbitrary minimum. By de-facto standard,  no longer prefix is permissible
>  to be announced.
>
> Strongly disagree.  As Bill Manning always said, an operator will route
> whatever I pay them to route.
>



-- 
-JH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140210/4890dea8/attachment.htm>

From SRyerse at eclipse-networks.com  Mon Feb 10 21:20:37 2014
From: SRyerse at eclipse-networks.com (Steven Ryerse)
Date: Tue, 11 Feb 2014 02:20:37 +0000
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <d362165238df4f659b9d63dbdc8b1b2a@DM2PR03MB398.namprd03.prod.outlook.com>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu><0a573e
	7e5ec24a34bba99c20501e6e5f@DM2PR03MB398.namprd03.prod.outlook.com><2fb97b02499741889d0b96fb40586780@EX13-MBX-13.ad.syr.edu>,
	<d362165238df4f659b9d63dbdc8b1b2a@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <D7528E36-9FF3-4406-9940-87925421E8BF@eclipse-networks.com>

This is interesting. So you have explained what is happening very well.  The rule that has been followed requiring blocks to be routed from routers within RIR makes logical sense as well. 

So are you concluding, that by honoring the router must be within ARIN region rule - but tunneling the traffic to another region, they are complying with the letter but breaking the spirit of the rule?  

Is the reason why you care when others appear not to care (as you pointed out) that you are worried that ARIN will run out of ipv4 faster if this keeps happening?  (Do you think this is an issue on ipv6 as well?)

Finally since the routers are physically  located in the ARIN region, is there an organization such as a data center or Internet provider, etc. that might be benefitting financially or otherwise - having the owner of these routers as a customer or similar beneficial relationship?

Sent from my iPhone

> On Feb 10, 2014, at 4:32 PM, "David Huberman" <David.Huberman at microsoft.com> wrote:
> 
> Hello Milton,
> 
>> While couched as opposition your post agrees with the problem statement that "Earlier work on this issue has
>> explored several options to restrict or otherwise limit out of region use. None of these options have gained 
>> consensus within the community." So there is no basis for opposition there.
> 
> Correct.
> 
>> I would conclude, however, that you do _not_ agree with the problem statement that "Current policy neither 
>> clearly forbids nor clearly permits out of region use of ARIN registered resources." You seem to believe that it
>> is already permitted, which makes the proposal a no-op. Is that right?
> 
> Not quite.  
> 
> The truth of the matter is that ARIN has operated for a very long time under a rule discussed many times between the RIRs' RS staff:
> 
> "The block must be routed from equipment within the RIR's region".  
> 
> Often times that's just anchoring the least specific.   It was a very solid rule which gave international backbone operators the flexibility to use the RIR they wanted for their needs, because they anchored routes everywhere.
> 
> If a content provider doesn't run an international backbone, and that content provider has its customers and equipment in, say, Malaysia, then they would generally be unable to obtain space from ARIN.  The answer from ARIN for such a request would be, "No - got see APNIC or a local IR".
> 
> What changed was a year or two ago, some companies got pretty clever.  They actually moved their routers to datacenters on the NA west coast, and used layer 2 tunneling to get everything back to the Asian east coast. All of their customers are in Asia, and they only have a shell company set up in California for the purposes of receiving space from ARIN.
> 
> The problem was compounded by two factors:
> 1) Some of these content providers were really, really large. China, for example, is a really big place.  So the IP needs were larger than all but 1 or 2 ARIN customers.
> 2) Some of these requests were fraudulent.  Provide fraud when dealing with operations from a wholly different culture has proven to be exceedingly difficult and, honestly, beyond ARIN's considerable expertise.
> 
> This was the point at which the staff started bringing this to the PDP fora.  It started in 2011 in Philadelphia, more serious alarms were raised in Arizona, and those alarms continue today.
> 
> The community has been consistently deaf to these concerns.  Responses range from:
> - I don't care; RIRs should just give space to operators who need them (region-agnostic)
> to 
> - I don't care; I can't wait for IPv4 to run out.
> 
> To some of us, these responses were disappointing.  I can appreciate the argument that the "Regional" part of Regional Internet Registries may now be past is usefulness.  But the argument has been very hard for me to swallow because there's just so much bad faith requesting going on, and it's almost all from extra-ARIN regions.
> 
> This is what staff has been trying to tell you (the PP community), and this is what you (the PP community) seem to say, "so what?" to.
> 
> [snip]
> 
>> Your second argument is that the staff already has all the tools it needs to do what is in section X.1. 
>> This is not something the staff report said to us in its assessment, however, so I would discount that.
> 
> You can discount it, but I respectfully say I'm right :)  I did do this, on the front lines, for 10 years, and Leslie and I developed ALL of the fraud protocols. 
> 
>> You main argument, therefore is that "out-of-region requestors [are] abusing the policies" and  "we need to 
>> draft text that significantly and materially helps ARIN staff fight fraud from out-of-region requestors."
>> Apparently you think the authorization to engage external entities to help with verification does not 
>> address that. Can you explain why?
> 
> I feel like I have in my first response.  X.1 is no-op because nothing changes.  Staff already can and do conduct 
> these types of activities when investigating fraud.  They may not have "engaged outside entities" to help with
> investigation, but they've always had that purview (that is, with parties who would be under attorney-client 
> privilege). 
> 
> Best regards,
> David
> 
> David R Huberman
> Microsoft Corporation
> Senior IT/OPS Program Manager (GFS)
> _______________________________________________
> 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 David.Huberman at microsoft.com  Mon Feb 10 22:10:29 2014
From: David.Huberman at microsoft.com (David Huberman)
Date: Tue, 11 Feb 2014 03:10:29 +0000
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <D7528E36-9FF3-4406-9940-87925421E8BF@eclipse-networks.com>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu><0a573e
	7e5ec24a34bba99c20501e6e5f@DM2PR03MB398.namprd03.prod.outlook.com><2fb97b02499741889d0b96fb40586780@EX13-MBX-13.ad.syr.edu>,
	<d362165238df4f659b9d63dbdc8b1b2a@DM2PR03MB398.namprd03.prod.outlook.com>,
	<D7528E36-9FF3-4406-9940-87925421E8BF@eclipse-networks.com>
Message-ID: <f2c1ca59b0d246cd83c273592ba4e654@DM2PR03MB398.namprd03.prod.outlook.com>

Hiya Steven,

You asked:

> So are you concluding, that by honoring the router must be within ARIN region rule - but tunneling the traffic to another region, they are complying with the letter but breaking the spirit of the rule?

Yes.  I like uniform rule sets, and if we're going to have RIRs, then we should have RIRs.  While we have RIRs, the rules should apply to everyone.  What makes this worse is it's very hard for staff to tell the difference between a legitimate network operator who just needs IPs for their huge customer base, and a scammer who claims a huge customer base but is just using trickery to get blocks from ARIN to profit off of.  If the scammers were small in IP use, I wouldn't care so much.  But they're not.  They're taking /12s and then turning around to big companies and saying, "Here, buy this from me!".


> Is the reason why you care when others appear not to care (as you pointed out) that you are worried that ARIN will run out of ipv4 faster if this keeps happening?  (Do you think this is an issue on ipv6 as well?)

I don't care about run-out so much because the transfer market neatly takes care of that.  Need space right now?  Go see Peter Thimmesch or Sandra Brown or Mike Burns or the hedgies at Kalorama.

I care about the rules being followed and the scammers being stopped.  I was at ARIN for 10 years.  It's hard to turn off my "anti-fraud" attitude.  

This situation creates artificial scarcity.  AT&T is going to get one less /12 because of it.  Akamai or a cableco or whatever other large consumer of addresses at ARIN is going to get one less allocation.  Because we're quickly giving away what's left to a mix of scammers and networks whose customers are wholly extra-ARIN.  Idealistically, I rail against that.


> Finally since the routers are physically  located in the ARIN region, is there an organization such as a data center or Internet provider, etc. that might be benefitting financially or otherwise - having the owner of these routers as a customer or similar 
> beneficial relationship?

Yes, I think so.  If the Asian provider buys racks in XYZ datacenter, then the facility and all inter-networking services the company buys in the datacenter all benefit from this.  It's good for them.  A policy change that disallowed these companies to qualify for space from ARIN would negatively effect these DCs.

/david



Sent from my iPhone

> On Feb 10, 2014, at 4:32 PM, "David Huberman" <David.Huberman at microsoft.com> wrote:
>
> Hello Milton,
>
>> While couched as opposition your post agrees with the problem statement that "Earlier work on this issue has
>> explored several options to restrict or otherwise limit out of region use. None of these options have gained
>> consensus within the community." So there is no basis for opposition there.
>
> Correct.
>
>> I would conclude, however, that you do _not_ agree with the problem statement that "Current policy neither
>> clearly forbids nor clearly permits out of region use of ARIN registered resources." You seem to believe that it
>> is already permitted, which makes the proposal a no-op. Is that right?
>
> Not quite.
>
> The truth of the matter is that ARIN has operated for a very long time under a rule discussed many times between the RIRs' RS staff:
>
> "The block must be routed from equipment within the RIR's region".
>
> Often times that's just anchoring the least specific.   It was a very solid rule which gave international backbone operators the flexibility to use the RIR they wanted for their needs, because they anchored routes everywhere.
>
> If a content provider doesn't run an international backbone, and that content provider has its customers and equipment in, say, Malaysia, then they would generally be unable to obtain space from ARIN.  The answer from ARIN for such a request would be, "No - got see APNIC or a local IR".
>
> What changed was a year or two ago, some companies got pretty clever.  They actually moved their routers to datacenters on the NA west coast, and used layer 2 tunneling to get everything back to the Asian east coast. All of their customers are in Asia, and they only have a shell company set up in California for the purposes of receiving space from ARIN.
>
> The problem was compounded by two factors:
> 1) Some of these content providers were really, really large. China, for example, is a really big place.  So the IP needs were larger than all but 1 or 2 ARIN customers.
> 2) Some of these requests were fraudulent.  Provide fraud when dealing with operations from a wholly different culture has proven to be exceedingly difficult and, honestly, beyond ARIN's considerable expertise.
>
> This was the point at which the staff started bringing this to the PDP fora.  It started in 2011 in Philadelphia, more serious alarms were raised in Arizona, and those alarms continue today.
>
> The community has been consistently deaf to these concerns.  Responses range from:
> - I don't care; RIRs should just give space to operators who need them (region-agnostic)
> to
> - I don't care; I can't wait for IPv4 to run out.
>
> To some of us, these responses were disappointing.  I can appreciate the argument that the "Regional" part of Regional Internet Registries may now be past is usefulness.  But the argument has been very hard for me to swallow because there's just so much bad faith requesting going on, and it's almost all from extra-ARIN regions.
>
> This is what staff has been trying to tell you (the PP community), and this is what you (the PP community) seem to say, "so what?" to.
>
> [snip]
>
>> Your second argument is that the staff already has all the tools it needs to do what is in section X.1.
>> This is not something the staff report said to us in its assessment, however, so I would discount that.
>
> You can discount it, but I respectfully say I'm right :)  I did do this, on the front lines, for 10 years, and Leslie and I developed ALL of the fraud protocols.
>
>> You main argument, therefore is that "out-of-region requestors [are] abusing the policies" and  "we need to
>> draft text that significantly and materially helps ARIN staff fight fraud from out-of-region requestors."
>> Apparently you think the authorization to engage external entities to help with verification does not
>> address that. Can you explain why?
>
> I feel like I have in my first response.  X.1 is no-op because nothing changes.  Staff already can and do conduct
> these types of activities when investigating fraud.  They may not have "engaged outside entities" to help with
> investigation, but they've always had that purview (that is, with parties who would be under attorney-client
> privilege).
>
> Best regards,
> David
>
> David R Huberman
> Microsoft Corporation
> Senior IT/OPS Program Manager (GFS)
> _______________________________________________
> 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 Feb 11 07:55:18 2014
From: owen at delong.com (Owen DeLong)
Date: Tue, 11 Feb 2014 04:55:18 -0800
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <CAP-guGVhU4jH3Vrd2cZZMEeWnmv-9zt4RMgbG_+TSMpLqVg3Qg@mail.gmail.com>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>
	<CAP-guGWz6R8d1qM3B_eP1Ned9DVQC0XWtSht8VFZ3hWeZt6NAA@mail.gmail.com>
	<52F57CEB.1040909@umn.edu>
	<CAP-guGWDH7i5MpjoDApqedwCitKRFGnD+-dtAoYPQF+e2wU7Ng@mail.gmail.com>
	<CACrmG8fvLSt482B3joL2+CZT4L9FFuVzfy59+_gchXmds6VScQ@mail.gmail.com>
	<CAP-guGVu4FMJ=CJVS3WHe02nhCrm8+MqAU28boMJyn3Hx4s2xA@mail.gmail.com>
	<52F84FBE.3060607@matthew.at>
	<CAP-guGVhU4jH3Vrd2cZZMEeWnmv-9zt4RMgbG_+TSMpLqVg3Qg@mail.gmail.com>
Message-ID: <3153DA4A-B9BB-4EE8-855E-D5891F3685D0@delong.com>


On Feb 9, 2014, at 20:37 , William Herrin <bill at herrin.us> wrote:

> On Sun, Feb 9, 2014 at 11:04 PM, Matthew Kaufman <matthew at matthew.at> wrote:
>> On 2/8/2014 6:19 AM, William Herrin wrote:
>>> If we want to manage addresses this way, we should first endeavor to pass
>>> a globally coordinated policy to the effect that multiregional organizations
>>> should solicit the registry in their headquarters' region for all
>>> registry-direct number resources rather than soliciting the registry that
>>> serves the region where the resources are employed.
>> 
>> 
>> I have a better idea:
>> 
>> For IPv4, realize that really really soon, this isn't going to matter.
> 
> Howdy,
> 
> Windows had primacy for more than a decade before folks stopped using
> DOS programs. Do you not recall all the workarounds getting DOS games
> to work in Windows 98 and later windows XP? IPv6 doesn't even have
> primacy yet. Reports of IPv4's death are premature.

I thought windows _WAS_ a DOS program... It seems to be very good at denying service in my experience.

Kidding aside, in reality, IPv4 from an ARIN policy perspective is mostly about managing the free pool. Really soon, that's not going to matter as there won't be a free pool to manage. The rest is going to be several years of keeping people from getting too crazy rearranging the deck chairs. While you can argue that IPv6 hasn't yet achieved primacy, I think this transition will go much faster than the DOS->Windows transition. A more apt comparison would be how long was it between when IPv4 gained primacy over IPX vs. IPX virtually disappearing from the corporate environment.

IPv4 has been on increasing degrees of life support and extreme measures for close to 20 years now. Those extreme measures have a non-linear increase in cost coming in the next several years.

I'm happy to report that my mother, who is about as technical as the average 75+ year old accountant is now using IPv6 at home and has reported an improved internet experience. (It's not clear how much of this is from IPv6 vs. how much comes from replacing the buggy modem provided by TWC with the Motorola modem I spec'd for her, but I digress.)

>> I have no problem with someone getting a nice big IPv6 block from one
>> convenient local RIR, and then splitting it up across their multinational
>> organization however they see fit. If they plan well, they *never* come back
>> to *any* RIR for address space.
> 
> I predict that last sentence turns out to be a pipe dream. If I'm
> wrong, look me up in 10 years and I'll buy you lunch.

That's certainly what is happening with HE's network. Though we do have
resources from APNIC for use in Asia, this is largely to deal with certain
carrier biases in that region. Throughout Europe and North America, we are
using our ARIN prefixes. (We have 2 only because we outgrew our initial /32).

Owen




From owen at delong.com  Tue Feb 11 08:01:44 2014
From: owen at delong.com (Owen DeLong)
Date: Tue, 11 Feb 2014 05:01:44 -0800
Subject: [arin-ppml] support for 2014-1 (out of region use)
In-Reply-To: <20140210171940.GR23819@mx1.yitter.info>
References: <43ba21c40d43471283c69d1ae2c8fd2d@EX13-MBX-13.ad.syr.edu>
	<CAP-guGWz6R8d1qM3B_eP1Ned9DVQC0XWtSht8VFZ3hWeZt6NAA@mail.gmail.com>
	<52F57CEB.1040909@umn.edu>
	<CAP-guGWDH7i5MpjoDApqedwCitKRFGnD+-dtAoYPQF+e2wU7Ng@mail.gmail.com>
	<52F8E9F5.7040202@umn.edu> <20140210153034.GF23819@mx1.yitter.info>
	<CAGkMwz5frXKeoht57YqY01CRFbW+KhLx4urY63_0sSaxTJBQDw@mail.gmail.com>
	<20140210171940.GR23819@mx1.yitter.info>
Message-ID: <FCE3CD2F-BD73-4D20-A5F1-232D24E729D5@delong.com>


On Feb 10, 2014, at 09:19 , Andrew Sullivan <ajs at anvilwalrusden.com> wrote:

> On Mon, Feb 10, 2014 at 08:53:43AM -0800, Scott Leibrand wrote:
> 
>> So are you in favor of or opposed to 2014-1
> 
> I'm opposed to it, because I just don't buy that it will actually
> solve any problem.  The existing policy neither forbids nor denies out
> of region use.  This proposal tries to codify things, but I don't see
> why that's necessary.
> 
Staff's current implementation of policy certainly makes it more difficult for an organization based in the ARIN region to get resources for their out-of-region portions of their network. Currently you have to be able to justify everything you need with in-region usage. If you can do that, then using the "remainder" out of region seems to be tolerated/permitted/allowed (not really sure which term best fits). But if you need 11 /48s in the ARIN region and 8 /48s in the rest of the world, ARIN is going to give you a /44, not a /40 and suggest that you get your space for the other regions from those RIRs.

I believe 2014-1 attempts to correct that problem while still attempting to satisfy some of the more vocal opponents to out-of-region usage. I would much rather see a clean proposal that allows out-of-region usage by organizations with significant nexus in the ARIN region and a prohibition on double-dipping, but the community does not seem to support doing so at this time.

Owen




From drc at virtualized.org  Tue Feb 11 12:10:59 2014
From: drc at virtualized.org (David Conrad)
Date: Tue, 11 Feb 2014 12:10:59 -0500
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy InternetResource
	Holders
In-Reply-To: <CAC1-dtn5GDate1PZ6ke538B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
	<CAMDXq5Ma1Hq0YOVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com>
	<CAC1-dtn5GDate1PZ6ke538B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com>
Message-ID: <E12D1B9F-8457-4AED-952D-158B0F9F9568@virtualized.org>

Chris,

On Feb 10, 2014, at 2:13 PM, Chris Grundemann <cgrundemann at gmail.com> wrote:
> Also, the RIRs, and ARIN in particular, were not created to "promote the Internet" necessarily (although I do find that a laudable cause)

True.

> - their primary purpose is to _support the Internet_ by acting as stewards of the Internet numbers in their region (something that should be remembered in any argument about needs testing). ;-)

Not really.  RFC 1366, section 2.0: 

     "The major reason to distribute the registration function is that the
   Internet serves a more diverse global population than it did at its
   inception.  This means that registries which are located in distinct
   geographic areas may be better able to serve the local community in
   terms of language and local customs."

The primary role was service to the community in language/culture. Being a "steward" of the address space (whatever that means) was a (much) later addition that I don't believe is universal across all RIRs.

IMHO, RIPE got it exactly right (from the abstract of RIPE-605):

"The importance of maintaining accurate records in the RIPE database is recognised as the NCC's principal task. "

(well, ok, they spelled recognized wrong :))

Needs testing, in and of itself, is not the issue.  What is at issue is what ARIN does when a transfer occurs (and they have, do, and will occur) outside of "justified" need.  As a _registry_, I believe ARIN's role (as with IANA and all other RIRs) is to maintain accurate records.

Regards,
-drc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140211/d95380a5/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140211/d95380a5/attachment.sig>

From heather.skanks at gmail.com  Tue Feb 11 12:13:06 2014
From: heather.skanks at gmail.com (Heather Schiller)
Date: Tue, 11 Feb 2014 12:13:06 -0500
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
 Allocation Conservation Update
In-Reply-To: <alpine.OSX.2.02.1402071003480.5486@brugal.local>
References: <52E91DF0.9040909@arin.net> <52F2CB04.20905@quark.net>
	<52F3B9F3.5040706@umn.edu>
	<6C8DE21A-F09B-4F4A-A5A7-28F9FE7CCDB9@delong.com>
	<alpine.OSX.2.02.1402071003480.5486@brugal.local>
Message-ID: <CADricwotP+t_n=fUrk=SQerBNsMqBUGP-V_GuVWd8=RpHUNGcA@mail.gmail.com>

I oppose the policy as written.

I don't have an opinion on the 2 vs 3, though I see it as such a small
change and given the total number of CI IX assignments (66 over how many
years?) it won't significantly change anything.

I am opposed to the policy because of this line " IXP's formed as non
profits will be considered end user organizations. All others will be
considered ISPs."

 This statement will impact the overwhelming majority of Critical
Infrastructure assignment holders, the majority of which are not IX's.  The
goal of attempting  preservation should be done by how the allocation is
justified, not how much the entity is billed.   111 of the CI allocations
are not to IX's.  Of the 66 IX allocations it is nearly split between end
users and ISP's.





On Fri, Feb 7, 2014 at 10:05 AM, Brandon Ross <bross at pobox.com> wrote:

> On Thu, 6 Feb 2014, Owen DeLong wrote:
>
>  I oppose the change. Anyone inclined to abuse a two participant standard
>> can easily create or obtain a 3rd participant for said purpose. This is
>> literally a case of change for the sake of change. No, a 3 participant
>> minimum is not an unreasonable standard. However, since it does have some
>> negative impact and is utterly unlikely to be at all effective in deterring
>> abuse, I see no benefit to the change.
>>
>
> I agree with Owen on all points and oppose the policy change.  Most
> importantly, this policy change significantly raises the bar for a
> legitimate IXP to get started while doing nothing effective to prevent what
> is, effectively, a tiny amount of potential abuse.
>
> --
> Brandon Ross                                      Yahoo & AIM:
>  BrandonNRoss
> +1-404-635-6667                                                ICQ:
>  2269442
>                                                          Skype:
>  brandonross
> Schedule a meeting:  http://www.doodle.com/bross
>
> _______________________________________________
> 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/20140211/230c6cbd/attachment.htm>

From springer at inlandnet.com  Tue Feb 11 12:25:59 2014
From: springer at inlandnet.com (John Springer)
Date: Tue, 11 Feb 2014 09:25:59 -0800 (PST)
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
 Allocation Conservation Update
In-Reply-To: <CADricwotP+t_n=fUrk=SQerBNsMqBUGP-V_GuVWd8=RpHUNGcA@mail.gmail.com>
References: <52E91DF0.9040909@arin.net> <52F2CB04.20905@quark.net>
	<52F3B9F3.5040706@umn.edu>
	<6C8DE21A-F09B-4F4A-A5A7-28F9FE7CCDB9@delong.com>
	<alpine.OSX.2.02.1402071003480.5486@brugal.local>
	<CADricwotP+t_n=fUrk=SQerBNsMqBUGP-V_GuVWd8=RpHUNGcA@mail.gmail.com>
Message-ID: <alpine.BSF.2.00.1402110924270.35879@mail.inlandnet.com>

Opposed as written.

Agree with the following reasoning. I am OK with the 2 -> 3 change.

John Springer

On Tue, 11 Feb 2014, Heather Schiller wrote:

> I oppose the policy as written.
> I don't have an opinion on the 2 vs 3, though I see it as such a small change and given the total number of CI IX assignments (66 over
> how many years?) it won't significantly change anything.?
> 
> I am opposed to the policy because of this line "?IXP's formed as non profits will be considered end user organizations. All others will
> be considered ISPs."
> 
> ?This statement will impact the overwhelming majority of Critical Infrastructure assignment holders, the majority of which are not IX's.
> ?The goal of attempting ?preservation should be done by how the allocation is justified, not how much the entity is billed. ? 111 of the
> CI allocations are not to IX's. ?Of the 66 IX allocations it is nearly split between end users and ISP's. ?
> 
> 
> 
> 
> 
> On Fri, Feb 7, 2014 at 10:05 AM, Brandon Ross <bross at pobox.com> wrote:
>       On Thu, 6 Feb 2014, Owen DeLong wrote:
>
>             I oppose the change. Anyone inclined to abuse a two participant standard can easily create or obtain a 3rd
>             participant for said purpose. This is literally a case of change for the sake of change. No, a 3 participant
>             minimum is not an unreasonable standard. However, since it does have some negative impact and is utterly
>             unlikely to be at all effective in deterring abuse, I see no benefit to the change.
> 
> 
> I agree with Owen on all points and oppose the policy change. ?Most importantly, this policy change significantly raises the bar
> for a legitimate IXP to get started while doing nothing effective to prevent what is, effectively, a tiny amount of potential
> abuse.
> 
> --
> Brandon Ross ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Yahoo & AIM: ?BrandonNRoss
> +1-404-635-6667? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ICQ: ?2269442
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Skype: ?brandonross
> Schedule a meeting: ?http://www.doodle.com/bross
> _______________________________________________
> 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 hannigan at gmail.com  Tue Feb 11 12:38:45 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Tue, 11 Feb 2014 12:38:45 -0500
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
 Allocation Conservation Update
In-Reply-To: <alpine.BSF.2.00.1402110924270.35879@mail.inlandnet.com>
References: <52E91DF0.9040909@arin.net> <52F2CB04.20905@quark.net>
	<52F3B9F3.5040706@umn.edu>
	<6C8DE21A-F09B-4F4A-A5A7-28F9FE7CCDB9@delong.com>
	<alpine.OSX.2.02.1402071003480.5486@brugal.local>
	<CADricwotP+t_n=fUrk=SQerBNsMqBUGP-V_GuVWd8=RpHUNGcA@mail.gmail.com>
	<alpine.BSF.2.00.1402110924270.35879@mail.inlandnet.com>
Message-ID: <CAMDXq5Mz_hsFAn4Qj4t5XW8an5s1BFoJznhvNDSUhSdw91UrJA@mail.gmail.com>

Support. I wrote what appears to be "the offending language" in order to
clean up vague, unclear language already memorialized in the existing
policy.

To wit:

"ISPs and other organizations receiving these micro-allocations will be
charged under the ISP fee schedule, while end-users will be charged under
the fee schedule for end-users. This policy does not preclude exchange
point operators from requesting address space under other policies."

I support removal of this and the proposed language related to defining the
fee structure. The rest of the proposal is not about abuse, it's about
conservation and helping infrastructure to grow _and_ succeed in the ARIN
region. A distinction does not need to be made between one area of the
region or another. I am in support of the change from two to three, or
more.


Best,

-M<






On Tue, Feb 11, 2014 at 12:25 PM, John Springer <springer at inlandnet.com>wrote:

> Opposed as written.
>
> Agree with the following reasoning. I am OK with the 2 -> 3 change.
>
> John Springer
>
>
> On Tue, 11 Feb 2014, Heather Schiller wrote:
>
>  I oppose the policy as written.
>> I don't have an opinion on the 2 vs 3, though I see it as such a small
>> change and given the total number of CI IX assignments (66 over
>> how many years?) it won't significantly change anything.
>>
>> I am opposed to the policy because of this line " IXP's formed as non
>> profits will be considered end user organizations. All others will
>> be considered ISPs."
>>
>>  This statement will impact the overwhelming majority of Critical
>> Infrastructure assignment holders, the majority of which are not IX's.
>>  The goal of attempting  preservation should be done by how the
>> allocation is justified, not how much the entity is billed.   111 of the
>> CI allocations are not to IX's.  Of the 66 IX allocations it is nearly
>> split between end users and ISP's.
>>
>>
>>
>>
>>
>> On Fri, Feb 7, 2014 at 10:05 AM, Brandon Ross <bross at pobox.com> wrote:
>>       On Thu, 6 Feb 2014, Owen DeLong wrote:
>>
>>             I oppose the change. Anyone inclined to abuse a two
>> participant standard can easily create or obtain a 3rd
>>             participant for said purpose. This is literally a case of
>> change for the sake of change. No, a 3 participant
>>             minimum is not an unreasonable standard. However, since it
>> does have some negative impact and is utterly
>>             unlikely to be at all effective in deterring abuse, I see no
>> benefit to the change.
>>
>>
>> I agree with Owen on all points and oppose the policy change.  Most
>> importantly, this policy change significantly raises the bar
>> for a legitimate IXP to get started while doing nothing effective to
>> prevent what is, effectively, a tiny amount of potential
>> abuse.
>>
>> --
>> Brandon Ross                                      Yahoo & AIM:
>>  BrandonNRoss
>> +1-404-635-6667                                                ICQ:
>>  2269442
>>                                                          Skype:
>>  brandonross
>> Schedule a meeting:  http://www.doodle.com/bross
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
>>
>>
>>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140211/b031b2d1/attachment.htm>

From bill at herrin.us  Tue Feb 11 13:22:10 2014
From: bill at herrin.us (William Herrin)
Date: Tue, 11 Feb 2014 13:22:10 -0500
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
 Allocation Conservation Update
In-Reply-To: <CADricwotP+t_n=fUrk=SQerBNsMqBUGP-V_GuVWd8=RpHUNGcA@mail.gmail.com>
References: <52E91DF0.9040909@arin.net> <52F2CB04.20905@quark.net>
	<52F3B9F3.5040706@umn.edu>
	<6C8DE21A-F09B-4F4A-A5A7-28F9FE7CCDB9@delong.com>
	<alpine.OSX.2.02.1402071003480.5486@brugal.local>
	<CADricwotP+t_n=fUrk=SQerBNsMqBUGP-V_GuVWd8=RpHUNGcA@mail.gmail.com>
Message-ID: <CAP-guGX==kexCVuy_iXQAS3EGA7rgqvbXU+UixwCdn=FRoWpwg@mail.gmail.com>

On Tue, Feb 11, 2014 at 12:13 PM, Heather Schiller
<heather.skanks at gmail.com> wrote:
> I am opposed to the policy because of this line " IXP's formed as non
> profits will be considered end user organizations. All others will be
> considered ISPs."
>
>  This statement will impact the overwhelming majority of Critical
> Infrastructure assignment holders, the majority of which are not IX's.  The
> goal of attempting  preservation should be done by how the allocation is
> justified, not how much the entity is billed.   111 of the CI allocations
> are not to IX's.  Of the 66 IX allocations it is nearly split between end
> users and ISP's.

Hi Heather,

Read it in context. The draft replaces only one of five paragraphs in
section 4.4. The paragraph replaced and its replacement address only
IXPs, not other providers of critical infrastructure.

https://www.arin.net/policy/nrpm.html#four4

Nevertheless, would your objection be solved if "All others" was
replaced with "All other IXPs"?

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From owen at delong.com  Tue Feb 11 17:12:49 2014
From: owen at delong.com (Owen DeLong)
Date: Tue, 11 Feb 2014 14:12:49 -0800
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy InternetResource
	Holders
In-Reply-To: <E12D1B9F-8457-4AED-952D-158B0F9F9568@virtualized.org>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
	<CAMDXq5Ma1Hq0YOVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com>
	<CAC1-dtn5GDate1PZ6ke538B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com>
	<E12D1B9F-8457-4AED-952D-158B0F9F9568@virtualized.org>
Message-ID: <D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com>

> "The importance of maintaining accurate records in the RIPE database is recognised as the NCC's principal task. "
> 
> (well, ok, they spelled recognized wrong :))

No, they spelled it the way the British do instead of the Americans.

This shouldn't be a surprise, given that Europe, in general, considers British to be "proper English" and American to be a bastardization of the British language.

Indeed, it kind of goes towards your point about differences in language, culture, timezones, etc. that the RIRs were created to serve. One could even say that spelling it the way you expected would be a violation of what you referred to as the primary reason for regionalizing the IR functions.

> Needs testing, in and of itself, is not the issue.  What is at issue is what ARIN does when a transfer occurs (and they have, do, and will occur) outside of "justified" need.  As a _registry_, I believe ARIN's role (as with IANA and all other RIRs) is to maintain accurate records.

You've made your position clear. The majority of the ARIN community does not appear to agree with you. Can you provide any evidence to support your claim that they "have, do, and will occur outside of justified need"?

So far, this is a popular refrain among those that seek to eliminate the stewardship role from the RIRs, but I have yet to see anyone present hard evidence that a significant amount of this has, does, or will occur.

Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140211/7449382a/attachment.htm>

From jcurran at arin.net  Tue Feb 11 18:39:08 2014
From: jcurran at arin.net (John Curran)
Date: Tue, 11 Feb 2014 23:39:08 +0000
Subject: [arin-ppml] Circumvention and operational usefulness of the
 registry (was: Re FYI -- RIPE-605 Services to Legacy Internet Resource
 Holders)
In-Reply-To: <D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
	<CAMDXq5Ma1Hq0YOVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com>
	<CAC1-dtn5GDate1PZ6ke538B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com>
	<E12D1B9F-8457-4AED-952D-158B0F9F9568@virtualized.org>
	<D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com>
Message-ID: <5535B744-736A-4E49-B5D1-6690D30C47E9@arin.net>

On Feb 11, 2014, at 5:12 PM, Owen DeLong <owen at delong.com<mailto:owen at delong.com>> wrote:
(drc)
Needs testing, in and of itself, is not the issue.  What is at issue is what ARIN does when a transfer occurs (and they have, do, and will occur) outside of "justified" need.  As a _registry_, I believe ARIN's role (as with IANA and all other RIRs) is to maintain accurate records.

You've made your position clear. The majority of the ARIN community does not appear to agree with you. Can you provide any evidence to support your claim that they "have, do, and will occur outside of justified need"?

So far, this is a popular refrain among those that seek to eliminate the stewardship role from the RIRs, but I have yet to see anyone present hard evidence that a significant amount of this has, does, or will occur.

Owen -

   I'll agree in principle with your point that transfers are not occurring outside
   of ARIN policy, but then must note that David's fundamental concern is still
   quite real.

   There is a single global Internet number registry system, and it is administered
   by the 5 RIRs and the IANA.  Each address block is associated with a single
   unique party.  An "IP address block" is, for all practical purposes, the rights
   that come association of a unique party with an entry in the registry.

   As I have said before, if someone thinks that they've obtained rights to an
   address block, but we can't transfer them in the registry due to lack of
   compliance with policy, then it's questionable whether they have obtained
   anything of value since the original address holder will still hold the rights.

   However, this does not prevent parties from effectively transferring control
   via any number of interesting gyrations (suballocation/lease to another party
   via nominal "services" relationship, locking up future right of transfer without
   affecting registration today, extreme corporate restructuring and M&A work,
   etc.)   There is ample desire by some to transfer regardless of ARIN policy,
   it is only going to increase with IPv4 free pool depletion, and there are
   practical limits to the ability to create and enforce policy to counteract
   such efforts.

   Even though I believe that ARIN maintains a technically accurate registry
   despite these gyrations, those circumventions that do occur deprive the
   community of the expected operational benefits being able to readily reach
   the user of the address space.  Ergo, David's fundamental concern remains
   valid, in that the combination of ARIN's adherence to community-developed
   policy plus the economic activities of a few will result in a registry which is
   less operationally useful, despite its recording of the legally correct parties.

   So, while I strongly disagree that transfers have occurred outside of policy,
   there are certainly cases where parties have gained effective beneficial use
   of address blocks, with potentially impact to the operational registry benefits
   as a result.   The community remains in control of this tradeoff, and has to
   date indicated that the benefits of the need-based transfer policy are worth
   both the procedural implications in transfer processing as well as a technically
   accurate but less operationally helpful registry.

FYI,
/John

John Curran
President and CEO
ARIN


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

From drc at virtualized.org  Tue Feb 11 19:29:25 2014
From: drc at virtualized.org (David Conrad)
Date: Tue, 11 Feb 2014 19:29:25 -0500
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy InternetResource
	Holders
In-Reply-To: <D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
	<CAMDXq5Ma1Hq0YOVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com>
	<CAC1-dtn5GDate1PZ6ke538B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com>
	<E12D1B9F-8457-4AED-952D-158B0F9F9568@virtualized.org>
	<D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com>
Message-ID: <CAFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org>

Owen,

On Feb 11, 2014, at 5:12 PM, Owen DeLong <owen at delong.com> wrote:
>> "The importance of maintaining accurate records in the RIPE database is recognised as the NCC's principal task. "
>> (well, ok, they spelled recognized wrong :))
> No, they spelled it the way the British do instead of the Americans.

It was, of course, a joke, as suggested by the ":)" characters.

>> Needs testing, in and of itself, is not the issue.  What is at issue is what ARIN does when a transfer occurs (and they have, do, and will occur) outside of "justified" need.  As a _registry_, I believe ARIN's role (as with IANA and all other RIRs) is to maintain accurate records.
> You've made your position clear. The majority of the ARIN community does not appear to agree with you.

For some definition of a particular subset of the "ARIN community", it may be true that accuracy of registration information is secondary to imposing policy dictates.  I suspect, however, that for the vast majority of actual users of registration information that it is NOT the case.

This might be an interesting topic for an ARIN survey.

I'm curious: do you personally believe that accuracy of registration data is secondary to imposing policy dictates?

> Can you provide any evidence to support your claim that they "have, do, and will occur outside of justified need"?

Of course not.  

Hint: according to current policy, such use of address space would be grounds for ARIN to "revoke" that address space.

I'd be surprised if you actually believe that folks are not fabricating justifications to get around the ARIN "justified need" requirements,

Regards,
-drc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140211/88ee30ce/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140211/88ee30ce/attachment.sig>

From jcurran at arin.net  Tue Feb 11 19:51:22 2014
From: jcurran at arin.net (John Curran)
Date: Wed, 12 Feb 2014 00:51:22 +0000
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy InternetResource
 Holders
In-Reply-To: <CAFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
	<CAMDXq5Ma1Hq0YOVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com>
	<CAC1-dtn5GDate1PZ6ke538B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com>
	<E12D1B9F-8457-4AED-952D-158B0F9F9568@virtualized.org>
	<D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com>
	<CAFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org>
Message-ID: <A3F38861-2AC3-43B3-9EBF-35D48A9F7E34@corp.arin.net>

On Feb 11, 2014, at 5:29 PM, David Conrad <drc at virtualized.org> wrote:
> 
> I'm curious: do you personally believe that accuracy of registration data is secondary to imposing policy dictates?

David -

To be clear, the registration data is accurate, in that it reflects the party which has the 
rights to the address block.  It is possible that some other party is using the block (just
as with ISPs who provide pieces of their address space to their customers to use), but 
that does not mean that their registration is inaccurate.

FYI,
/John

John Curran
President and CEO
ARIN




From owen at delong.com  Tue Feb 11 20:24:12 2014
From: owen at delong.com (Owen DeLong)
Date: Tue, 11 Feb 2014 17:24:12 -0800
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy InternetResource
	Holders
In-Reply-To: <CAFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
	<CAMDXq5Ma1Hq0YOVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com>
	<CAC1-dtn5GDate1PZ6ke538B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com>
	<E12D1B9F-8457-4AED-952D-158B0F9F9568@virtualized.org>
	<D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com>
	<CAFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org>
Message-ID: <DE753550-BC29-4B00-BCAA-B59B1B58E4A2@delong.com>


On Feb 11, 2014, at 4:29 PM, David Conrad <drc at virtualized.org> wrote:

> Owen,
> 
> On Feb 11, 2014, at 5:12 PM, Owen DeLong <owen at delong.com> wrote:
>>> "The importance of maintaining accurate records in the RIPE database is recognised as the NCC's principal task. "
>>> (well, ok, they spelled recognized wrong :))
>> No, they spelled it the way the British do instead of the Americans.
> 
> It was, of course, a joke, as suggested by the ":)" characters.
> 
>>> Needs testing, in and of itself, is not the issue.  What is at issue is what ARIN does when a transfer occurs (and they have, do, and will occur) outside of "justified" need.  As a _registry_, I believe ARIN's role (as with IANA and all other RIRs) is to maintain accurate records.
>> You've made your position clear. The majority of the ARIN community does not appear to agree with you.
> 
> For some definition of a particular subset of the "ARIN community", it may be true that accuracy of registration information is secondary to imposing policy dictates.  I suspect, however, that for the vast majority of actual users of registration information that it is NOT the case.
> 
> This might be an interesting topic for an ARIN survey.
> 
> I'm curious: do you personally believe that accuracy of registration data is secondary to imposing policy dictates?

I would argue that the data is accurate. The use of addresses by unregistered entities is a secondary problem.

Do you have suggestions for improving our abilities to prevent such misuse by unregistered entities?

In short, no, I do not believe that the fact that some people will commit bank robbery is a reason to legalize the robbing of banks in the hopes that such people will not attempt to conceal their identities.

>> Can you provide any evidence to support your claim that they "have, do, and will occur outside of justified need"?
> 
> Of course not.  
> 
> Hint: according to current policy, such use of address space would be grounds for ARIN to "revoke" that address space.
> 
> I'd be surprised if you actually believe that folks are not fabricating justifications to get around the ARIN "justified need" requirements,

I believe that in any system of laws, rules, regulations, etc. there are going to be those that attempt to circumvent them.

I do not believe that removing the regulations is an effective tactic to reduce the anonymity of those parties.

Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140211/9a5aee0b/attachment.htm>

From jcurran at arin.net  Tue Feb 11 21:31:48 2014
From: jcurran at arin.net (John Curran)
Date: Wed, 12 Feb 2014 02:31:48 +0000
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy InternetResource
 Holders
In-Reply-To: <CAFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
	<CAMDXq5Ma1Hq0YOVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com>
	<CAC1-dtn5GDate1PZ6ke538B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com>
	<E12D1B9F-8457-4AED-952D-158B0F9F9568@virtualized.org>
	<D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com>
	<CAFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org>
Message-ID: <2D503821-1ABB-411A-9C49-F6EC7A54E460@corp.arin.net>

On Feb 11, 2014, at 5:29 PM, David Conrad <drc at virtualized.org> wrote:

> For some definition of a particular subset of the "ARIN community", it may be true that accuracy of registration information is secondary to imposing policy dictates.  I suspect, however, that for the vast majority of actual users of registration information that it is NOT the case.
> 
> This might be an interesting topic for an ARIN survey.

David - 

To paraphrase with slightly more neutral language -  "It might be interesting to survey 
the ARIN community regarding the prioritization of needs-based transfers vs operational 
usefulness of registry data."

Is that approximation close enough to your request?

/John




From drc at virtualized.org  Wed Feb 12 11:34:02 2014
From: drc at virtualized.org (David Conrad)
Date: Wed, 12 Feb 2014 11:34:02 -0500
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy InternetResource
	Holders
In-Reply-To: <2D503821-1ABB-411A-9C49-F6EC7A54E460@corp.arin.net>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
	<CAMDXq5Ma1Hq0YOVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com>
	<CAC1-dtn5GDate1PZ6ke538B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com>
	<E12D1B9F-8457-4AED-952D-158B0F9F9568@virtualized.org>
	<D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com>
	<CAFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org>
	<2D503821-1ABB-411A-9C49-F6EC7A54E460@corp.arin.net>
Message-ID: <CD1B0373-BD30-499B-AA54-12029035AB48@virtualized.org>

John,

On Feb 11, 2014, at 9:31 PM, John Curran <jcurran at arin.net> wrote:
> To paraphrase with slightly more neutral language -  "It might be interesting to survey 
> the ARIN community regarding the prioritization of needs-based transfers vs operational 
> usefulness of registry data."
> 
> Is that approximation close enough to your request?

Not really.

I feel it's more than simply a question of needs-based transfer. It goes to the question of the basic function of ARIN. There is a (I believe small) contingent who attend ARIN meetings that appear to believe that the registration database is an appropriate weapon to enforce policy. In my view, this goes against the very reason for an Internet registry. The RIPE statement is quite clear and succinct:

"The importance of maintaining accurate records in the RIPE database is recognised as the NCC's principal task."

It might be an interest survey question to see if the people who respond to ARIN surveys agree with a similar statement applied to ARIN:

"The importance of maintaining accurate records in the ARIN database is recognized as ARIN's principal task."

Regards,
-drc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140212/e619904c/attachment.sig>

From jcurran at arin.net  Wed Feb 12 13:13:04 2014
From: jcurran at arin.net (John Curran)
Date: Wed, 12 Feb 2014 18:13:04 +0000
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy InternetResource
 Holders
In-Reply-To: <CD1B0373-BD30-499B-AA54-12029035AB48@virtualized.org>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
	<CAMDXq5Ma1Hq0YOVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com>
	<CAC1-dtn5GDate1PZ6ke538B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com>
	<E12D1B9F-8457-4AED-952D-158B0F9F9568@virtualized.org>
	<D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com>
	<CAFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org>
	<2D503821-1ABB-411A-9C49-F6EC7A54E460@corp.arin.net>
	<CD1B0373-BD30-499B-AA54-12029035AB48@virtualized.org>
Message-ID: <CB47563D-65ED-493D-B2BD-ECB87FD4EF07@arin.net>

On Feb 12, 2014, at 9:34 AM, David Conrad <drc at virtualized.org> wrote:
> On Feb 11, 2014, at 9:31 PM, John Curran <jcurran at arin.net> wrote:
>> To paraphrase with slightly more neutral language -  "It might be interesting to survey 
>> the ARIN community regarding the prioritization of needs-based transfers vs operational 
>> usefulness of registry data."
>> 
>> Is that approximation close enough to your request?
> 
> Not really.
> ...
> It might be an interest survey question to see if the people who respond to ARIN surveys agree with a similar statement applied to ARIN:
> 
> "The importance of maintaining accurate records in the ARIN database is recognized as ARIN's principal task."

Alas, your very clear formulation won't be very informative, 
since the registry is accurate even after a denied transfer
(just as occurs with denied transfer of an auto or property
with it doesn't meet those registry requirements - the fact
that you've driving it around doesn't actually make it yours)

Hence, my suggestion to make such a survey more specific with
respect to prioritization of needs-based transfers vs operational 
usefulness of registry data.

/John

John Curran
President and CEO
ARIN




From bill at herrin.us  Wed Feb 12 12:11:13 2014
From: bill at herrin.us (William Herrin)
Date: Wed, 12 Feb 2014 12:11:13 -0500
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy InternetResource
	Holders
In-Reply-To: <CAFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
	<CAMDXq5Ma1Hq0YOVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com>
	<CAC1-dtn5GDate1PZ6ke538B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com>
	<E12D1B9F-8457-4AED-952D-158B0F9F9568@virtualized.org>
	<D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com>
	<CAFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org>
Message-ID: <CAP-guGW8g39v_O=nV=svR5hWpdr7HK+wPanHCJd=t08A8DwyXQ@mail.gmail.com>

On Tue, Feb 11, 2014 at 7:29 PM, David Conrad <drc at virtualized.org> wrote:
>> Can you provide any evidence to support your claim that they "have, do, and
>> will occur outside of justified need"?
>
> Of course not.
>
> Hint: according to current policy, such use of address space would be
> grounds for ARIN to "revoke" that address space.

Hi David,

That's not strictly true. Under current policy and practice, you must
have used the addresses in the manner you documented to justify
receiving them. Once you have done so, and can document that you did,
the addresses can no longer be revoked. You can redeploy them to other
uses and they still can't be revoked.

You can even set yourself up as a no-rules registry assigning those
addresses to others with complete disregard for ARIN policy and some
relatively minor technical caveats. There was no fraud in the original
justification and no requirement that they be re-justified. The
addresses still can't be revoked.

Once out of compliance, that particular legal entity can no longer
receive new allocations from ARIN. But that never was much of an
obstruction.

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 lee at dilkie.com  Wed Feb 12 13:32:30 2014
From: lee at dilkie.com (Lee Dilkie)
Date: Wed, 12 Feb 2014 13:32:30 -0500
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy InternetResource
 Holders
In-Reply-To: <CB47563D-65ED-493D-B2BD-ECB87FD4EF07@arin.net>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>	<CAMDXq5Ma1Hq0YOVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com>	<5B9E90747FA2974D91A54FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com>	<CAC1-dtn5GDate1PZ6ke538B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com>	<E12D1B9F-8457-4AED-952D-158B0F9F9568@virtualized.org>	<D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com>	<CAFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org>	<2D503821-1ABB-411A-9C49-F6EC7A54E460@corp.arin.net>	<CD1B0373-BD30-499B-AA54-12029035AB48@virtualized.org>
	<CB47563D-65ED-493D-B2BD-ECB87FD4EF07@arin.net>
Message-ID: <52FBBE3E.9060700@dilkie.com>


On 2/12/2014 1:13 PM, John Curran wrote:
> Alas, your very clear formulation won't be very informative, 
> since the registry is accurate even after a denied transfer
> (just as occurs with denied transfer of an auto or property
> with it doesn't meet those registry requirements - the fact
> that you've driving it around doesn't actually make it yours)

it does matter if there was no official transfer and a bank robbery is
committed with your car. (and for the sake of fun, you died a year
before the crime)

The authorities very much DO want to know where to look and would like
to have accurate registration records... "Accurate" in this case can be
construed as "reflecting reality".

-lee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140212/5007168a/attachment.htm>

From jcurran at arin.net  Wed Feb 12 14:44:22 2014
From: jcurran at arin.net (John Curran)
Date: Wed, 12 Feb 2014 19:44:22 +0000
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy InternetResource
 Holders
In-Reply-To: <52FBBE3E.9060700@dilkie.com>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
	<CAMDXq5Ma1Hq0YOVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com>
	<CAC1-dtn5GDate1PZ6ke538B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com>
	<E12D1B9F-8457-4AED-952D-158B0F9F9568@virtualized.org>
	<D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com>
	<CAFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org>
	<2D503821-1ABB-411A-9C49-F6EC7A54E460@corp.arin.net>
	<CD1B0373-BD30-499B-AA54-12029035AB48@virtualized.org>
	<CB47563D-65ED-493D-B2BD-ECB87FD4EF07@arin.net>
	<52FBBE3E.9060700@dilkie.com>
Message-ID: <0746AB32-3156-401B-8503-88E8665960F5@arin.net>

On Feb 12, 2014, at 11:32 AM, Lee Dilkie <Lee at Dilkie.com> wrote:
> 
> The authorities very much DO want to know where to look and would like to have accurate registration records... "Accurate" in this case can be construed as "reflecting reality".

Lee - 

That is very much the case (the desire for accurate records), but it actually proves the 
point in that the authorities still don't transfer your registration to the thief in possession 
simply to better "reflect reality".

/John

John Curran
President and CEO
ARIN

From lee at dilkie.com  Wed Feb 12 17:59:36 2014
From: lee at dilkie.com (Lee Dilkie)
Date: Wed, 12 Feb 2014 17:59:36 -0500
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy InternetResource
 Holders
In-Reply-To: <0746AB32-3156-401B-8503-88E8665960F5@arin.net>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
	<CAMDXq5Ma1Hq0YOVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com>
	<CAC1-dtn5GDate1PZ6ke538B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com>
	<E12D1B9F-8457-4AED-952D-158B0F9F9568@virtualized.org>
	<D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com>
	<CAFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org>
	<2D503821-1ABB-411A-9C49-F6EC7A54E460@corp.arin.net>
	<CD1B0373-BD30-499B-AA54-12029035AB48@virtualized.org>
	<CB47563D-65ED-493D-B2BD-ECB87FD4EF07@arin.net>
	<52FBBE3E.9060700@dilkie.com>
	<0746AB32-3156-401B-8503-88E8665960F5@arin.net>
Message-ID: <52FBFCD8.1040303@dilkie.com>


On 2/12/2014 14:44, John Curran wrote:
> On Feb 12, 2014, at 11:32 AM, Lee Dilkie <Lee at Dilkie.com> wrote:
>> The authorities very much DO want to know where to look and would like to have accurate registration records... "Accurate" in this case can be construed as "reflecting reality".
> Lee - 
>
> That is very much the case (the desire for accurate records), but it actually proves the 
> point in that the authorities still don't transfer your registration to the thief in possession 
> simply to better "reflect reality".
>
> /John
>
> John Curran
> President and CEO
> ARIN

Not really sure you got my point... There is no "needs" test for me to
transfer ownership of my car to you and the province cannot step in and
stop it, they are only interested in keeping their records straight....
so they know who to send the bill to every year (and so the police have
accurate records for those speed cameras).

As, I think is being suggested, ARIN should be doing as it's primary
mission.

-lee

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

From lar at mwtcorp.net  Wed Feb 12 18:23:14 2014
From: lar at mwtcorp.net (lar at mwtcorp.net)
Date: Wed, 12 Feb 2014 16:23:14 -0700
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy InternetResource
	Holders
In-Reply-To: <52FBFCD8.1040303@dilkie.com>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
	<CAMDXq5Ma1Hq0YOVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com>
	<CAC1-dtn5GDate1PZ6ke538B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com>
	<E12D1B9F-8457-4AED-952D-158B0F9F9568@virtualized.org>
	<D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com>
	<CAFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org>
	<2D503821-1ABB-411A-9C49-F6EC7A54E460@corp.arin.net>
	<CD1B0373-BD30-499B-AA54-12029035AB48@virtualized.org>
	<CB47563D-65ED-493D-B2BD-ECB87FD4EF07@arin.net>
	<52FBBE3E.9060700@dilkie.com>
	<0746AB32-3156-401B-8503-88E8665960F5@arin.net>
	<52FBFCD8.1040303@dilkie.com>
Message-ID: <web-3505606@be1.mail.trib.com>

On Wed, 12 Feb 2014 17:59:36 -0500
  Lee Dilkie <lee at dilkie.com> wrote:
> 
> On 2/12/2014 14:44, John Curran wrote:
>> On Feb 12, 2014, at 11:32 AM, Lee Dilkie <Lee at Dilkie.com> wrote:
>>> The authorities very much DO want to know where to look and would like to 
>>>have accurate registration records... "Accurate" in this case can be 
>>>construed as "reflecting reality".
>> Lee - 
>>
>> That is very much the case (the desire for accurate records), but it 
>>actually proves the 
>> point in that the authorities still don't transfer your registration to the 
>>thief in possession 
>> simply to better "reflect reality".

Do you think that IF there was a physical limit to be number of cars in the
country, AND we were approaching that limit AND there existed a small number
of VERY LARGE taxicab companies, would a needs test be instituted? How about
for people that already have cars? How about people that have several? I 
expect
the debate would get complicated, as this one has over the last few years.


>>
>> /John
>>
>> John Curran
>> President and CEO
>> ARIN
> 
> Not really sure you got my point... There is no "needs" test for me to
> transfer ownership of my car to you and the province cannot step in and
> stop it, they are only interested in keeping their records straight....
> so they know who to send the bill to every year (and so the police have
> accurate records for those speed cameras).
> 
> As, I think is being suggested, ARIN should be doing as it's primary
> mission.
> 
> -lee
> 

Larry Ash
Network Administrator
Mountain West Telephone
123 W 1st St.
Casper, WY 82601
Office 307 233-8387


From woody at pch.net  Wed Feb 12 18:32:20 2014
From: woody at pch.net (Bill Woodcock)
Date: Wed, 12 Feb 2014 15:32:20 -0800
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy InternetResource
	Holders
In-Reply-To: <52FBFCD8.1040303@dilkie.com>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
	<CAMDXq5Ma1Hq0YOVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com>
	<CAC1-dtn5GDate1PZ6ke538B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com>
	<E12D1B9F-8457-4AED-952D-158B0F9F9568@virtualized.org>
	<D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com>
	<CAFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org>
	<2D503821-1ABB-411A-9C49-F6EC7A54E460@corp.arin.net>
	<CD1B0373-BD30-499B-AA54-12029035AB48@virtualized.org>
	<CB47563D-65ED-493D-B2BD-ECB87FD4EF07@arin.net>
	<52FBBE3E.9060700@dilkie.com>
	<0746AB32-3156-401B-8503-88E8665960F5@arin.net>
	<52FBFCD8.1040303@dilkie.com>
Message-ID: <186C13A2-ED2B-46D7-A90B-1B00A438F7D2@pch.net>

That's because your car isn't a scarce public resource. I think you'd find a different situation altogether if you tried to sell a radio station license to someone who wasn't prepared to accept the responsibilities of the license. 

    
                -Bill


> On Feb 12, 2014, at 15:00, "Lee Dilkie" <lee at dilkie.com> wrote:
> 
> 
>> On 2/12/2014 14:44, John Curran wrote:
>>> On Feb 12, 2014, at 11:32 AM, Lee Dilkie <Lee at Dilkie.com> wrote:
>>> The authorities very much DO want to know where to look and would like to have accurate registration records... "Accurate" in this case can be construed as "reflecting reality".
>> Lee - 
>> 
>> That is very much the case (the desire for accurate records), but it actually proves the 
>> point in that the authorities still don't transfer your registration to the thief in possession 
>> simply to better "reflect reality".
>> 
>> /John
>> 
>> John Curran
>> President and CEO
>> ARIN
> 
> Not really sure you got my point... There is no "needs" test for me to transfer ownership of my car to you and the province cannot step in and stop it, they are only interested in keeping their records straight.... so they know who to send the bill to every year (and so the police have accurate records for those speed cameras).
> 
> As, I think is being suggested, ARIN should be doing as it's primary mission.
> 
> -lee
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140212/c4fbc8fd/attachment.htm>

From jcurran at arin.net  Wed Feb 12 18:46:23 2014
From: jcurran at arin.net (John Curran)
Date: Wed, 12 Feb 2014 23:46:23 +0000
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy InternetResource
 Holders
In-Reply-To: <52FBFCD8.1040303@dilkie.com>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
	<CAMDXq5Ma1Hq0YOVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com>
	<CAC1-dtn5GDate1PZ6ke538B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com>
	<E12D1B9F-8457-4AED-952D-158B0F9F9568@virtualized.org>
	<D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com>
	<CAFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org>
	<2D503821-1ABB-411A-9C49-F6EC7A54E460@corp.arin.net>
	<CD1B0373-BD30-499B-AA54-12029035AB48@virtualized.org>
	<CB47563D-65ED-493D-B2BD-ECB87FD4EF07@arin.net>
	<52FBBE3E.9060700@dilkie.com>
	<0746AB32-3156-401B-8503-88E8665960F5@arin.net>
	<52FBFCD8.1040303@dilkie.com>
Message-ID: <FA2E5D83-3D61-4DD4-8C40-548F2C5C5104@arin.net>

> Not really sure you got my point... There is no "needs" test for me to transfer ownership of my car to you and the province cannot step in and stop it, they are only interested in keeping their records straight.... 

Lee -

    There are still requirements (even if nominal) if you hope 
    to transfer title, and if you don't meet them then your car 
    is not sold.  The records at the registry remain accurate
    in either case.

     This is why I suggested that the comparison be specifically 
     with respect to needs assessment if you want to ask a clear 
     question.

> As, I think is being suggested, ARIN should be doing as it's primary mission.
 
   ARIN is keeping an accurate registry - that's why some people 
   are unable to complete their desired transfers.  You probably
   need to be a little clearer and specifically note that it is more
   than accuracy you seek; it is also easier transfers w/o needs-
   assessment 

Thanks!
/John

John Curran
President and CEO
ARIN

From lee at dilkie.com  Wed Feb 12 18:47:42 2014
From: lee at dilkie.com (Lee Dilkie)
Date: Wed, 12 Feb 2014 18:47:42 -0500
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy InternetResource
 Holders
In-Reply-To: <186C13A2-ED2B-46D7-A90B-1B00A438F7D2@pch.net>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
	<CAMDXq5Ma1Hq0YOVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com>
	<CAC1-dtn5GDate1PZ6ke538B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com>
	<E12D1B9F-8457-4AED-952D-158B0F9F9568@virtualized.org>
	<D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com>
	<CAFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org>
	<2D503821-1ABB-411A-9C49-F6EC7A54E460@corp.arin.net>
	<CD1B0373-BD30-499B-AA54-12029035AB48@virtualized.org>
	<CB47563D-65ED-493D-B2BD-ECB87FD4EF07@arin.net>
	<52FBBE3E.9060700@dilkie.com>
	<0746AB32-3156-401B-8503-88E8665960F5@arin.net>
	<52FBFCD8.1040303@dilkie.com>
	<186C13A2-ED2B-46D7-A90B-1B00A438F7D2@pch.net>
Message-ID: <52FC081E.7010306@dilkie.com>

:)

I also omitted to mention that the DMV considers the car as having two
parts... the ownership, which they won't interfere with and want
accurate registration... and the license portion, which they will ensure
doesn't get passed to someone who doesn't quality...

of course that breaks down as ARIN isn't in the routing business, the
DMV is.


;)

-lee

On 2/12/2014 18:32, Bill Woodcock wrote:
> That's because your car isn't a scarce public resource. I think you'd
> find a different situation altogether if you tried to sell a radio
> station license to someone who wasn't prepared to accept the
> responsibilities of the license. 
>
>     
>                 -Bill
>
>
> On Feb 12, 2014, at 15:00, "Lee Dilkie" <lee at dilkie.com
> <mailto:lee at dilkie.com>> wrote:
>
>>
>> On 2/12/2014 14:44, John Curran wrote:
>>> On Feb 12, 2014, at 11:32 AM, Lee Dilkie <Lee at Dilkie.com> wrote:
>>>> The authorities very much DO want to know where to look and would like to have accurate registration records... "Accurate" in this case can be construed as "reflecting reality".
>>> Lee - 
>>>
>>> That is very much the case (the desire for accurate records), but it actually proves the 
>>> point in that the authorities still don't transfer your registration to the thief in possession 
>>> simply to better "reflect reality".
>>>
>>> /John
>>>
>>> John Curran
>>> President and CEO
>>> ARIN
>>
>> Not really sure you got my point... There is no "needs" test for me
>> to transfer ownership of my car to you and the province cannot step
>> in and stop it, they are only interested in keeping their records
>> straight.... so they know who to send the bill to every year (and so
>> the police have accurate records for those speed cameras).
>>
>> As, I think is being suggested, ARIN should be doing as it's primary
>> mission.
>>
>> -lee
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net
>> <mailto:ARIN-PPML at arin.net>).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net <mailto:info at arin.net> if you experience
>> any issues.

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

From drc at virtualized.org  Wed Feb 12 20:43:00 2014
From: drc at virtualized.org (David Conrad)
Date: Wed, 12 Feb 2014 20:43:00 -0500
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy InternetResource
	Holders
In-Reply-To: <CB47563D-65ED-493D-B2BD-ECB87FD4EF07@arin.net>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
	<CAMDXq5Ma1Hq0YOVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com>
	<CAC1-dtn5GDate1PZ6ke538B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com>
	<E12D1B9F-8457-4AED-952D-158B0F9F9568@virtualized.org>
	<D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com>
	<CAFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org>
	<2D503821-1ABB-411A-9C49-F6EC7A54E460@corp.arin.net>
	<CD1B0373-BD30-499B-AA54-12029035AB48@virtualized.org>
	<CB47563D-65ED-493D-B2BD-ECB87FD4EF07@arin.net>
Message-ID: <5D25514F-2881-47A8-BBE9-045577D8747D@virtualized.org>

John,

On Feb 12, 2014, at 1:13 PM, John Curran <jcurran at arin.net> wrote:
>> "The importance of maintaining accurate records in the ARIN database is recognized as ARIN's principal task."
> Alas, your very clear formulation won't be very informative, 
> since the registry is accurate even after a denied transfer

You appear to be assuming that if ARIN denies the transfer, the transfer doesn't occur.

Do you really believe that?

> Hence, my suggestion to make such a survey more specific with
> respect to prioritization of needs-based transfers vs operational 
> usefulness of registry data.


Again, for me, the issue isn't about needs-based transfer per se, it's more general than that.  Needs-based constraints on transfer in the context of legacy addresses is a post facto imposition of policy on resource holders who have no contractual obligation to abide by (or even knowledge of) that policy. Failure to accurately record a transfer between mutually agreeable parties does not necessarily result in that transfer not taking place but it does result in the database being degraded if the transfer does occur.  To me, this is a failure in the primary activity of an Internet registry. If anyone in ARIN community believes that as the IPv4 free pool is exhausted that ARIN (the organization) will be able to stand in the way of the organizations most interested in obtaining address space and the folks that want to sell it to them, you have a different view of desperation than I do.

Perhaps the right answer would be if ARIN renames itself to the American Policy Forum for Internet Numbers and the registry function (which, as I understand it takes a fraction of ARIN's budget) gets spun off into its own non-profit (501c(3) instead of c(6)) organization. 

And by the way, continuing to try to associate transfers between mutually agreeable parties as theft or illegal activity isn't really helping the conversation. 

Regards,
-drc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140212/40a98b70/attachment.sig>

From matthew at matthew.at  Thu Feb 13 00:09:16 2014
From: matthew at matthew.at (Matthew Kaufman)
Date: Wed, 12 Feb 2014 21:09:16 -0800
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy InternetResource
 Holders
In-Reply-To: <5D25514F-2881-47A8-BBE9-045577D8747D@virtualized.org>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>	<CAMDXq5Ma1Hq0YOVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com>	<5B9E90747FA2974D91A54FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com>	<CAC1-dtn5GDate1PZ6ke538B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com>	<E12D1B9F-8457-4AED-952D-158B0F9F9568@virtualized.org>	<D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com>	<CAFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org>	<2D503821-1ABB-411A-9C49-F6EC7A54E460@corp.arin.net>	<CD1B0373-BD30-499B-AA54-12029035AB48@virtualized.org>	<CB47563D-65ED-493D-B2BD-ECB87FD4EF07@arin.net>
	<5D25514F-2881-47A8-BBE9-045577D8747D@virtualized.org>
Message-ID: <52FC537C.6020902@matthew.at>


On 2/12/14, 5:43 PM, David Conrad wrote:
> And by the way, continuing to try to associate transfers between 
> mutually agreeable parties as theft or illegal activity isn't really 
> helping the conversation.

+1. Especially when the transfers involve addresses for which no RSA has 
been signed. Either ARIN should stop maintaining a registry of 
pre-ARIN-assigned no-RSA-associated addresses altogether, or ensure that 
such a registry is relatively accurate.

I understand that ARIN *can* decide to pretend that it somehow prevents 
the transfers from happening by refusing to record changes in 
"ownership" that are done outside of policy (and certainly has the right 
to refuse to record the changes, what with there being no agreement with 
the parties and all), but I don't see how that furthers the goal of 
maintaining an accurate registry, which I presume is why ARIN includes 
legacy addresses in its registry at all.

Matthew Kaufman


From matthew at matthew.at  Thu Feb 13 00:14:04 2014
From: matthew at matthew.at (Matthew Kaufman)
Date: Wed, 12 Feb 2014 21:14:04 -0800
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy InternetResource
 Holders
In-Reply-To: <FA2E5D83-3D61-4DD4-8C40-548F2C5C5104@arin.net>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>	<CAMDXq5Ma1Hq0YOVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com>	<5B9E90747FA2974D91A54FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com>	<CAC1-dtn5GDate1PZ6ke538B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com>	<E12D1B9F-8457-4AED-952D-158B0F9F9568@virtualized.org>	<D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com>	<CAFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org>	<2D503821-1ABB-411A-9C49-F6EC7A54E460@corp.arin.net>	<CD1B0373-BD30-499B-AA54-12029035AB48@virtualized.org>	<CB47563D-65ED-493D-B2BD-ECB87FD4EF07@arin.net>	<52FBBE3E.9060700@dilkie.com>	<0746AB32-3156-401B-8503-88E8665960F5@arin.net>	<52FBFCD8.1040303@dilkie.com>
	<FA2E5D83-3D61-4DD4-8C40-548F2C5C5104@arin.net>
Message-ID: <52FC549C.8070604@matthew.at>


On 2/12/14, 3:46 PM, John Curran wrote:
> ARIN is keeping an accurate registry - that's why some people are 
> unable to complete their desired transfers.

Yes, for some definition of "complete". For other definitions, like "the 
recipient is able to route traffic to the addresses and assign those 
addresses to hosts and use those addresses for connectivity to the 
global Internet", "completing" a transfer is actually quite easy.

So then the question is... what good is a registry that "accurately" 
reflects that those transfers never happened to the people who might 
actually ever look in the registry? And I assume people *do* look, 
otherwise there wouldn't be a need to maintain a *public* registry at 
all, would there?

Matthew Kaufman



From hannigan at gmail.com  Wed Feb 12 23:46:47 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Wed, 12 Feb 2014 23:46:47 -0500
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy Internet
	Resource Holders
Message-ID: <CAMDXq5M2V3D_k4AZ3B3wwvCFBpbGfPYdJursM-QZyvxi4mgXjw@mail.gmail.com>

I have a dumb question.

Does 605 mean addresses are now property? Or only in some regions?

Best,

Marty



On Wednesday, February 12, 2014, David Conrad <drc at virtualized.org> wrote:

> John,
>
> On Feb 12, 2014, at 1:13 PM, John Curran <jcurran at arin.net <javascript:;>>
> wrote:
> >> "The importance of maintaining accurate records in the ARIN database is
> recognized as ARIN's principal task."
> > Alas, your very clear formulation won't be very informative,
> > since the registry is accurate even after a denied transfer
>
> You appear to be assuming that if ARIN denies the transfer, the transfer
> doesn't occur.
>
> Do you really believe that?
>
> > Hence, my suggestion to make such a survey more specific with
> > respect to prioritization of needs-based transfers vs operational
> > usefulness of registry data.
>
>
> Again, for me, the issue isn't about needs-based transfer per se, it's
> more general than that.  Needs-based constraints on transfer in the context
> of legacy addresses is a post facto imposition of policy on resource
> holders who have no contractual obligation to abide by (or even knowledge
> of) that policy. Failure to accurately record a transfer between mutually
> agreeable parties does not necessarily result in that transfer not taking
> place but it does result in the database being degraded if the transfer
> does occur.  To me, this is a failure in the primary activity of an
> Internet registry. If anyone in ARIN community believes that as the IPv4
> free pool is exhausted that ARIN (the organization) will be able to stand
> in the way of the organizations most interested in obtaining address space
> and the folks that want to sell it to them, you have a different view of
> desperation than I do.
>
> Perhaps the right answer would be if ARIN renames itself to the American
> Policy Forum for Internet Numbers and the registry function (which, as I
> understand it takes a fraction of ARIN's budget) gets spun off into its own
> non-profit (501c(3) instead of c(6)) organization.
>
> And by the way, continuing to try to associate transfers between mutually
> agreeable parties as theft or illegal activity isn't really helping the
> conversation.
>
> Regards,
> -drc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140212/3f652077/attachment.htm>

From jcurran at arin.net  Thu Feb 13 03:24:51 2014
From: jcurran at arin.net (John Curran)
Date: Thu, 13 Feb 2014 08:24:51 +0000
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy InternetResource
 Holders
In-Reply-To: <5D25514F-2881-47A8-BBE9-045577D8747D@virtualized.org>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
	<CAMDXq5Ma1Hq0YOVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com>
	<CAC1-dtn5GDate1PZ6ke538B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com>
	<E12D1B9F-8457-4AED-952D-158B0F9F9568@virtualized.org>
	<D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com>
	<CAFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org>
	<2D503821-1ABB-411A-9C49-F6EC7A54E460@corp.arin.net>
	<CD1B0373-BD30-499B-AA54-12029035AB48@virtualized.org>
	<CB47563D-65ED-493D-B2BD-ECB87FD4EF07@arin.net>
	<5D25514F-2881-47A8-BBE9-045577D8747D@virtualized.org>
Message-ID: <687DFF93-4C22-4A48-BA74-9736DA95B609@arin.net>

On Feb 12, 2014, at 6:43 PM, David Conrad <drc at virtualized.org> wrote:

> You appear to be assuming that if ARIN denies the transfer, the transfer doesn't occur.

Correct.

>> Hence, my suggestion to make such a survey more specific with
>> respect to prioritization of needs-based transfers vs operational 
>> usefulness of registry data.
> 
> Again, for me, the issue isn't about needs-based transfer per se, it's more general than that.  Needs-based constraints on transfer in the context of legacy addresses is a post facto imposition of policy on resource holders who have no contractual obligation to abide by (or even knowledge of) that policy.

David - 
 
  I'm sorry - you are mischaracterizing the needs-based transfer 
  policy as a "post facto imposition of policy" by ARIN.  The needs-
  based requirement for transfers existed before ARIN; the ARIN 
  community has only been sustaining the existing practice:

  RFC 2050 (November 1996) is fairly clear on this matter - 

  "   7.  The transfer of IP addresses from one party to another must be
       approved by the regional registries.  The party trying to obtain
       the IP address must meet the same criteria as if they were
       requesting an IP address directly from the IR."

  Since you were a coauthor of RFC2050, perhaps you can explain 
  what is supposed to happen when the approval described above 
  does not occur?

Thanks!
/John

John Curran
President and CEO
ARIN




  



From jcurran at arin.net  Thu Feb 13 04:41:25 2014
From: jcurran at arin.net (John Curran)
Date: Thu, 13 Feb 2014 09:41:25 +0000
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy
	Internet	Resource Holders
In-Reply-To: <CAMDXq5M2V3D_k4AZ3B3wwvCFBpbGfPYdJursM-QZyvxi4mgXjw@mail.gmail.com>
References: <CAMDXq5M2V3D_k4AZ3B3wwvCFBpbGfPYdJursM-QZyvxi4mgXjw@mail.gmail.com>
Message-ID: <97A592DE-F624-4BE3-A369-BA1A1CE75D58@arin.net>

On Feb 12, 2014, at 9:46 PM, Martin Hannigan <hannigan at gmail.com> wrote:

> I have a dumb question. 
> 
> Does 605 mean addresses are now property? Or only in some regions? 

It would be best to ask RIPE about interpretation of their policies.

Thanks!
/John

John Curran
President and CEO
ARIN




From jcurran at arin.net  Thu Feb 13 04:45:18 2014
From: jcurran at arin.net (John Curran)
Date: Thu, 13 Feb 2014 09:45:18 +0000
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy InternetResource
 Holders
In-Reply-To: <52FC549C.8070604@matthew.at>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
	<CAMDXq5Ma1Hq0YOVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com>
	<CAC1-dtn5GDate1PZ6ke538B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com>
	<E12D1B9F-8457-4AED-952D-158B0F9F9568@virtualized.org>
	<D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com>
	<CAFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org>
	<2D503821-1ABB-411A-9C49-F6EC7A54E460@corp.arin.net>
	<CD1B0373-BD30-499B-AA54-12029035AB48@virtualized.org>
	<CB47563D-65ED-493D-B2BD-ECB87FD4EF07@arin.net>
	<52FBBE3E.9060700@dilkie.com>
	<0746AB32-3156-401B-8503-88E8665960F5@arin.net>
	<52FBFCD8.1040303@dilkie.com>
	<FA2E5D83-3D61-4DD4-8C40-548F2C5C5104@arin.net>
	<52FC549C.8070604@matthew.at>
Message-ID: <C6182AD4-31A0-4CB5-A4FA-8B2C2A07BF02@corp.arin.net>

> On Feb 12, 2014, at 10:14 PM, Matthew Kaufman <matthew at matthew.at> wrote:
> 
> So then the question is... what good is a registry that "accurately" reflects that those transfers never happened to the people who might actually ever look in the registry? 

Excellent question - note that the same situation occurs 
with service providers who don't update Whois to reflect 
sub-assignments...   Ideally, the operational contacts 
are still responsive even though the block is being used 
by other parties who are not the address holder.

/John

John Curran
President and CEO
ARIN




From jcurran at arin.net  Thu Feb 13 05:00:30 2014
From: jcurran at arin.net (John Curran)
Date: Thu, 13 Feb 2014 10:00:30 +0000
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy InternetResource
 Holders
In-Reply-To: <52FC537C.6020902@matthew.at>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
	<CAMDXq5Ma1Hq0YOVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com>
	<CAC1-dtn5GDate1PZ6ke538B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com>
	<E12D1B9F-8457-4AED-952D-158B0F9F9568@virtualized.org>
	<D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com>
	<CAFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org>
	<2D503821-1ABB-411A-9C49-F6EC7A54E460@corp.arin.net>
	<CD1B0373-BD30-499B-AA54-12029035AB48@virtualized.org>
	<CB47563D-65ED-493D-B2BD-ECB87FD4EF07@arin.net>
	<5D25514F-2881-47A8-BBE9-045577D8747D@virtualized.org>
	<52FC537C.6020902@matthew.at>
Message-ID: <4B32C6FA-2FC0-4721-8AF2-20D1E31844BF@arin.net>

On Feb 12, 2014, at 10:09 PM, Matthew Kaufman <matthew at matthew.at> wrote:

> +1. Especially when the transfers involve addresses for which no RSA has been signed. Either ARIN should stop maintaining a registry of pre-ARIN-assigned no-RSA-associated addresses altogether, or ensure that such a registry is relatively accurate.

Refer to my email to David - the needs-based transfer policy was established in
the Internet Registry system before ARIN's formation.

FYI,
/John

John Curran
President and CEO
ARIN



From drc at virtualized.org  Thu Feb 13 11:18:12 2014
From: drc at virtualized.org (David Conrad)
Date: Thu, 13 Feb 2014 11:18:12 -0500
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy InternetResource
	Holders
In-Reply-To: <687DFF93-4C22-4A48-BA74-9736DA95B609@arin.net>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
	<CAMDXq5Ma1Hq0YOVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com>
	<CAC1-dtn5GDate1PZ6ke538B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com>
	<E12D1B9F-8457-4AED-952D-158B0F9F9568@virtualized.org>
	<D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com>
	<CAFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org>
	<2D503821-1ABB-411A-9C49-F6EC7A54E460@corp.arin.net>
	<CD1B0373-BD30-499B-AA54-12029035AB48@virtualized.org>
	<CB47563D-65ED-493D-B2BD-ECB87FD4EF07@arin.net>
	<5D25514F-2881-47A8-BBE9-045577D8747D@virtualized.org>
	<687DFF93-4C22-4A48-BA74-9736DA95B609@arin.net>
Message-ID: <6DDFCA18-A609-471E-AFF8-23FD1BCDFC35@virtualized.org>

John,

On Feb 13, 2014, at 3:24 AM, John Curran <jcurran at arin.net> wrote:
> On Feb 12, 2014, at 6:43 PM, David Conrad <drc at virtualized.org> wrote:
>> You appear to be assuming that if ARIN denies the transfer, the transfer doesn't occur.
> Correct.

Just as passing laws that bans buying/selling guns does not eliminate the traffic in guns, I suspect your view does not actually correspond to reality.

Unfortunately, your view pretty much guarantees the ultimate irrelevance of ARIN's registration database for the purposes for which it was created. Fortunately, it appears there is at least one other RIR that has stated it will actually provide registry services. I suspect there will be others.

>  Since you were a coauthor of RFC2050, perhaps you can explain 
>  what is supposed to happen when the approval described above 
>  does not occur?

Oddly, 2050 is silent on that. I suspect that silence might be because at least one of the authors recognized the inadvisability of imposing conditions that would defeat the primary purpose of the registry system and put that system at odds with the community it was trying to serve, something that would be a bad idea particularly since it provides its services at the discretion and whim of that community.

While it was ancient history, I seem to recall some discussion among my co-authors along the lines that it would be appropriate to refuse new allocations due to policy non-conformance since those addresses would, by definition, be non-operational, but that refusing to update the registration database for operational addresses would have the dual negative effect of damaging that database at the same time as implicitly encouraging misuse of address space since such misuse couldn't be tracked back to the misusers.

Of course, if you want to play the ancient history game, I might point out that most of the address allocations in question occurred prior to 2050 and ask you for the explicit policy document that disallows execution of a registry's primary function for those addresses or, since you're so fond of treating 2050 as sacred text, how is it you can quote 4.7, but choose to ignore the very first sentence of 4.1?

However, to be honest, I'm not that interested in playing the ancient history game -- I find the whole exercise pointless and boring. I am, however, interested in what policy changes you believe it will take to get ARIN to accurately reflect reality in its registry database. What's it going to take?

Regards,
-drc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140213/9bd5fc72/attachment.sig>

From drc at virtualized.org  Thu Feb 13 11:20:04 2014
From: drc at virtualized.org (David Conrad)
Date: Thu, 13 Feb 2014 11:20:04 -0500
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy Internet
	Resource Holders
In-Reply-To: <CAMDXq5Mc6x8tpsEH2ge4fihGM=y5+HPPOz8LA9kJNFh0aZu7xw@mail.gmail.com>
References: <CAMDXq5M2V3D_k4AZ3B3wwvCFBpbGfPYdJursM-QZyvxi4mgXjw@mail.gmail.com>
	<97A592DE-F624-4BE3-A369-BA1A1CE75D58@arin.net>
	<CAMDXq5Mc6x8tpsEH2ge4fihGM=y5+HPPOz8LA9kJNFh0aZu7xw@mail.gmail.com>
Message-ID: <A582722D-C1D0-4758-A8D7-25631B2B97F9@virtualized.org>

On Feb 13, 2014, at 10:47 AM, Martin Hannigan <hannigan at gmail.com> wrote:
> I will, but how can RIR's have legacy related policy like this be inconsistent across regions? I would argue its likely that it requires matching to sone extent here. 
> 
> How would people feel about pushing 605 as a "globally coordinated" policy?

I actually think it should be a real global policy.

Regards,
-drc


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140213/9bcd935e/attachment.sig>

From hannigan at gmail.com  Thu Feb 13 11:29:55 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Thu, 13 Feb 2014 11:29:55 -0500
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy Internet
	Resource Holders
In-Reply-To: <A582722D-C1D0-4758-A8D7-25631B2B97F9@virtualized.org>
References: <CAMDXq5M2V3D_k4AZ3B3wwvCFBpbGfPYdJursM-QZyvxi4mgXjw@mail.gmail.com>
	<97A592DE-F624-4BE3-A369-BA1A1CE75D58@arin.net>
	<CAMDXq5Mc6x8tpsEH2ge4fihGM=y5+HPPOz8LA9kJNFh0aZu7xw@mail.gmail.com>
	<A582722D-C1D0-4758-A8D7-25631B2B97F9@virtualized.org>
Message-ID: <CAMDXq5PZzUMpZ27=qD-CM8SW8TqVfBG0x3P5_LrB9gvUdCZRrw@mail.gmail.com>

On Thu, Feb 13, 2014 at 11:20 AM, David Conrad <drc at virtualized.org> wrote:

> On Feb 13, 2014, at 10:47 AM, Martin Hannigan <hannigan at gmail.com> wrote:
> > I will, but how can RIR's have legacy related policy like this be
> inconsistent across regions? I would argue its likely that it requires
> matching to sone extent here.
> >
> > How would people feel about pushing 605 as a "globally coordinated"
> policy?
>
> I actually think it should be a real global policy.
>
>

The ASO global policy process takes too long and if a single RIR objects or
introduces a procedural anomaly it pretty much blows itself up. Maybe
neither is the answer.  The ARIN region could adopt a 605 like policy and
go through the global process afterwards if it even mattered at that point.

Best,

-M<
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140213/5b643418/attachment.htm>

From jcurran at arin.net  Thu Feb 13 11:58:59 2014
From: jcurran at arin.net (John Curran)
Date: Thu, 13 Feb 2014 16:58:59 +0000
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy InternetResource
 Holders
In-Reply-To: <6DDFCA18-A609-471E-AFF8-23FD1BCDFC35@virtualized.org>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
	<CAMDXq5Ma1Hq0YOVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com>
	<CAC1-dtn5GDate1PZ6ke538B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com>
	<E12D1B9F-8457-4AED-952D-158B0F9F9568@virtualized.org>
	<D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com>
	<CAFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org>
	<2D503821-1ABB-411A-9C49-F6EC7A54E460@corp.arin.net>
	<CD1B0373-BD30-499B-AA54-12029035AB48@virtualized.org>
	<CB47563D-65ED-493D-B2BD-ECB87FD4EF07@arin.net>
	<5D25514F-2881-47A8-BBE9-045577D8747D@virtualized.org>
	<687DFF93-4C22-4A48-BA74-9736DA95B609@arin.net>
	<6DDFCA18-A609-471E-AFF8-23FD1BCDFC35@virtualized.org>
Message-ID: <2AE523C2-B9DF-4401-8B7E-C135AE394931@arin.net>

On Feb 13, 2014, at 9:18 AM, David Conrad <drc at virtualized.org> wrote:
> 
>> Since you were a coauthor of RFC2050, perhaps you can explain 
>> what is supposed to happen when the approval described above 
>> does not occur?
> 
> Oddly, 2050 is silent on that.

Would you expect that a transfer in 1997 would have been put in the 
registry despite the lack of approval?  It certainly wouldn't have 
been accurate to do so, since the address block would still be held
by the original party, or does "approval" have some non-standard 
meaning in this context?  

> Of course, if you want to play the ancient history game, I might point out that most of the address allocations in question occurred prior to 2050 and ask you for the explicit policy document that disallows execution of a registry's primary function for those addresses or, since you're so fond of treating 2050 as sacred text, how is it you can quote 4.7, but choose to ignore the very first sentence of 4.1?

I believe the first sentence of RFC 2050 section 4.1 is very important,
and am not ignoring it in the least - 

"  1.  Regional Registries provide registration services as its
       primary function.  "

Registry services are the primary function; and this means that (using any 
plain reading of RFC 2050) the transfer of IP addresses from one party to
another was only to happen in the registry if the receiving party meets the 
needs-based criteria.  Processing transfers per policy is maintaining an 
accurate registry.

You may not like the need-based transfer policy, and it may not deter 'off 
book' usage of address blocks, but the party listed as the address holder 
still has control of the address block in the registry and hence is accurate.

Finally, I don't consider RFC 2050 sacred text, and hence why I supported its 
recent update as RFC 7020.  I only raised it because you asserted _ARIN_ created 
the needs-based transfer policy after the fact, which obviously isn't correct.

> However, to be honest, I'm not that interested in playing the ancient history game -- I find the whole exercise pointless and boring. I am, however, interested in what policy changes you believe it will take to get ARIN to accurately reflect reality in its registry database. What's it going to take?

I have been attempting to follow up on your suggestion to poll the 
community, but we seem to have reached an impasse because ARIN is
keeping the registry accurate and your formulation would suggest 
otherwise. Hence, my attempt at a more balanced phrasing, i.e. that 
we should "survey the ARIN community regarding the prioritization of 
needs-based transfers vs operational usefulness of registry data."
If we can come up with acceptable language, we'll figure out how to 
poll the ARIN community on this topic.

Thanks!
/John

John Curran
President and CEO
ARIN





 



From hannigan at gmail.com  Thu Feb 13 12:07:14 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Thu, 13 Feb 2014 12:07:14 -0500
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy InternetResource
	Holders
In-Reply-To: <2AE523C2-B9DF-4401-8B7E-C135AE394931@arin.net>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
	<CAMDXq5Ma1Hq0YOVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com>
	<CAC1-dtn5GDate1PZ6ke538B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com>
	<E12D1B9F-8457-4AED-952D-158B0F9F9568@virtualized.org>
	<D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com>
	<CAFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org>
	<2D503821-1ABB-411A-9C49-F6EC7A54E460@corp.arin.net>
	<CD1B0373-BD30-499B-AA54-12029035AB48@virtualized.org>
	<CB47563D-65ED-493D-B2BD-ECB87FD4EF07@arin.net>
	<5D25514F-2881-47A8-BBE9-045577D8747D@virtualized.org>
	<687DFF93-4C22-4A48-BA74-9736DA95B609@arin.net>
	<6DDFCA18-A609-471E-AFF8-23FD1BCDFC35@virtualized.org>
	<2AE523C2-B9DF-4401-8B7E-C135AE394931@arin.net>
Message-ID: <CAMDXq5PtAh3ovEsUYbkYW1aTa+3CxuDcP7pQK1KLD=X3t4DkKw@mail.gmail.com>

On Thu, Feb 13, 2014 at 11:58 AM, John Curran <jcurran at arin.net> wrote:

> On Feb 13, 2014, at 9:18 AM, David Conrad <drc at virtualized.org> wrote:
>

[ clip ]


>
> > However, to be honest, I'm not that interested in playing the ancient
> history game -- I find the whole exercise pointless and boring. I am,
> however, interested in what policy changes you believe it will take to get
> ARIN to accurately reflect reality in its registry database. What's it
> going to take?
>
> I have been attempting to follow up on your suggestion to poll the
> community, but we seem to have reached an impasse because ARIN is
> keeping the registry accurate and your formulation would suggest
> otherwise. Hence, my attempt at a more balanced phrasing, i.e. that
> we should "survey the ARIN community regarding the prioritization of
> needs-based transfers vs operational usefulness of registry data."
> If we can come up with acceptable language, we'll figure out how to
> poll the ARIN community on this topic.
>
>
>

How about polling resource holders instead? A much larger audience.

Best,

-M<
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140213/d85e6c81/attachment.htm>

From jcurran at arin.net  Thu Feb 13 12:40:27 2014
From: jcurran at arin.net (John Curran)
Date: Thu, 13 Feb 2014 17:40:27 +0000
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy InternetResource
 Holders
In-Reply-To: <CAMDXq5PtAh3ovEsUYbkYW1aTa+3CxuDcP7pQK1KLD=X3t4DkKw@mail.gmail.com>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
	<CAMDXq5Ma1Hq0YOVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com>
	<CAC1-dtn5GDate1PZ6ke538B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com>
	<E12D1B9F-8457-4AED-952D-158B0F9F9568@virtualized.org>
	<D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com>
	<CAFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org>
	<2D503821-1ABB-411A-9C49-F6EC7A54E460@corp.arin.net>
	<CD1B0373-BD30-499B-AA54-12029035AB48@virtualized.org>
	<CB47563D-65ED-493D-B2BD-ECB87FD4EF07@arin.net>
	<5D25514F-2881-47A8-BBE9-045577D8747D@virtualized.org>
	<687DFF93-4C22-4A48-BA74-9736DA95B609@arin.net>
	<6DDFCA18-A609-471E-AFF8-23FD1BCDFC35@virtualized.org>
	<2AE523C2-B9DF-4401-8B7E-C135AE394931@arin.net>
	<CAMDXq5PtAh3ovEsUYbkYW1aTa+3CxuDcP7pQK1KLD=X3t4DkKw@mail.gmail.com>
Message-ID: <1D4C803F-D7B4-4A7F-B643-FA5126BA577F@arin.net>

On Feb 13, 2014, at 10:07 AM, Martin Hannigan <hannigan at gmail.com<mailto:hannigan at gmail.com>> wrote:

On Thu, Feb 13, 2014 at 11:58 AM, John Curran <jcurran at arin.net<mailto:jcurran at arin.net>> wrote:
On Feb 13, 2014, at 9:18 AM, David Conrad <drc at virtualized.org<mailto:drc at virtualized.org>> wrote:

[ clip ]


> However, to be honest, I'm not that interested in playing the ancient history game -- I find the whole exercise pointless and boring. I am, however, interested in what policy changes you believe it will take to get ARIN to accurately reflect reality in its registry database. What's it going to take?

I have been attempting to follow up on your suggestion to poll the
community, but we seem to have reached an impasse because ARIN is
keeping the registry accurate and your formulation would suggest
otherwise. Hence, my attempt at a more balanced phrasing, i.e. that
we should "survey the ARIN community regarding the prioritization of
needs-based transfers vs operational usefulness of registry data."
If we can come up with acceptable language, we'll figure out how to
poll the ARIN community on this topic.


How about polling resource holders instead? A much larger audience.

It's possible, although we also need to always use caution when reaching
out via the Whois contact information, since there is significant variation in
what folks think of as "spam", even if related to the registry itself.

One possibility is to poll 'known' resource holders; this is a community which
is greater than ARIN Members, in that it includes those who have an ARIN
online account for managing their resources (note that legacy address holders
can get such accounts and update contact info without entry into an RSA/LRSA)

In this manner, we can be certain to get an actual known population, but still
making it possible for any resource holder to participate.

Thoughts?
/John





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140213/20006e1d/attachment.htm>

From hannigan at gmail.com  Thu Feb 13 14:34:26 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Thu, 13 Feb 2014 14:34:26 -0500
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy InternetResource
	Holders
In-Reply-To: <1D4C803F-D7B4-4A7F-B643-FA5126BA577F@arin.net>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
	<CAMDXq5Ma1Hq0YOVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com>
	<CAC1-dtn5GDate1PZ6ke538B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com>
	<E12D1B9F-8457-4AED-952D-158B0F9F9568@virtualized.org>
	<D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com>
	<CAFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org>
	<2D503821-1ABB-411A-9C49-F6EC7A54E460@corp.arin.net>
	<CD1B0373-BD30-499B-AA54-12029035AB48@virtualized.org>
	<CB47563D-65ED-493D-B2BD-ECB87FD4EF07@arin.net>
	<5D25514F-2881-47A8-BBE9-045577D8747D@virtualized.org>
	<687DFF93-4C22-4A48-BA74-9736DA95B609@arin.net>
	<6DDFCA18-A609-471E-AFF8-23FD1BCDFC35@virtualized.org>
	<2AE523C2-B9DF-4401-8B7E-C135AE394931@arin.net>
	<CAMDXq5PtAh3ovEsUYbkYW1aTa+3CxuDcP7pQK1KLD=X3t4DkKw@mail.gmail.com>
	<1D4C803F-D7B4-4A7F-B643-FA5126BA577F@arin.net>
Message-ID: <CAMDXq5N0ZPph9tRJDe_E7qskbhAspCNdQhmFacuOw=h9kbAKtA@mail.gmail.com>

On Thu, Feb 13, 2014 at 12:40 PM, John Curran <jcurran at arin.net> wrote:

>  On Feb 13, 2014, at 10:07 AM, Martin Hannigan <hannigan at gmail.com> wrote:
>
>  On Thu, Feb 13, 2014 at 11:58 AM, John Curran <jcurran at arin.net> wrote:
>
>> On Feb 13, 2014, at 9:18 AM, David Conrad <drc at virtualized.org> wrote:
>>
>
>  [ clip ]
>
>
>>
>> > However, to be honest, I'm not that interested in playing the ancient
>> history game -- I find the whole exercise pointless and boring. I am,
>> however, interested in what policy changes you believe it will take to get
>> ARIN to accurately reflect reality in its registry database. What's it
>> going to take?
>>
>>  I have been attempting to follow up on your suggestion to poll the
>> community, but we seem to have reached an impasse because ARIN is
>> keeping the registry accurate and your formulation would suggest
>> otherwise. Hence, my attempt at a more balanced phrasing, i.e. that
>> we should "survey the ARIN community regarding the prioritization of
>> needs-based transfers vs operational usefulness of registry data."
>>  If we can come up with acceptable language, we'll figure out how to
>> poll the ARIN community on this topic.
>>
>>
>  How about polling resource holders instead? A much larger audience.
>
>
>  It's possible, although we also need to always use caution when reaching
> out via the Whois contact information, since there is significant
> variation in
> what folks think of as "spam", even if related to the registry itself.
>
>
>

Thinking about it further, a poll would be more tail chasing.

David's question above is probably the best one in this thread. You guys
can have at it.

Best,

-M<
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140213/1617c62d/attachment.htm>

From hannigan at gmail.com  Thu Feb 13 10:47:13 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Thu, 13 Feb 2014 10:47:13 -0500
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy Internet
	Resource Holders
In-Reply-To: <97A592DE-F624-4BE3-A369-BA1A1CE75D58@arin.net>
References: <CAMDXq5M2V3D_k4AZ3B3wwvCFBpbGfPYdJursM-QZyvxi4mgXjw@mail.gmail.com>
	<97A592DE-F624-4BE3-A369-BA1A1CE75D58@arin.net>
Message-ID: <CAMDXq5Mc6x8tpsEH2ge4fihGM=y5+HPPOz8LA9kJNFh0aZu7xw@mail.gmail.com>

I will, but how can RIR's have legacy related policy like this be
inconsistent across regions? I would argue its likely that it requires
matching to sone extent here.

How would people feel about pushing 605 as a "globally coordinated" policy?

Best,

Martin



On Thursday, February 13, 2014, John Curran <jcurran at arin.net> wrote:

> On Feb 12, 2014, at 9:46 PM, Martin Hannigan <hannigan at gmail.com<javascript:;>>
> wrote:
>
> > I have a dumb question.
> >
> > Does 605 mean addresses are now property? Or only in some regions?
>
> It would be best to ask RIPE about interpretation of their policies.
>
> Thanks!
> /John
>
> John Curran
> President and CEO
> ARIN
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140213/df8416d0/attachment.htm>

From jcurran at arin.net  Thu Feb 13 15:07:42 2014
From: jcurran at arin.net (John Curran)
Date: Thu, 13 Feb 2014 20:07:42 +0000
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy Internet
	Resource Holders
In-Reply-To: <CAMDXq5Mc6x8tpsEH2ge4fihGM=y5+HPPOz8LA9kJNFh0aZu7xw@mail.gmail.com>
References: <CAMDXq5M2V3D_k4AZ3B3wwvCFBpbGfPYdJursM-QZyvxi4mgXjw@mail.gmail.com>
	<97A592DE-F624-4BE3-A369-BA1A1CE75D58@arin.net>
	<CAMDXq5Mc6x8tpsEH2ge4fihGM=y5+HPPOz8LA9kJNFh0aZu7xw@mail.gmail.com>
Message-ID: <AA7713C8-AEB5-4259-B613-A18B5E1B5E42@arin.net>

On Feb 13, 2014, at 8:47 AM, Martin Hannigan <hannigan at gmail.com> wrote:

> I will, but how can RIR's have legacy related policy like this be inconsistent across regions? I would argue its likely that it requires matching to sone extent here. 
> 
> How would people feel about pushing 605 as a "globally coordinated" policy?

I do not know how the community will assess the merits of such a policy proposal,
but regarding the specific approach, I will note that there are several different aspects
of RIPE-605, and it may be more productive to work on consecutively on globally
coordinated proposals for groups of aspects than as an "omnibus" proposal which 
changes all of them at once.

The approach is clearly up to you and the community - my observation is purely based 
on pragmatics as I see them with respect to globally coordinated policies.

FYI,
/John

John Curran
President and CEO
ARIN





From owen at delong.com  Thu Feb 13 16:42:33 2014
From: owen at delong.com (Owen DeLong)
Date: Thu, 13 Feb 2014 13:42:33 -0800
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy InternetResource
	Holders
In-Reply-To: <FA2E5D83-3D61-4DD4-8C40-548F2C5C5104@arin.net>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
	<CAMDXq5Ma1Hq0YOVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com>
	<CAC1-dtn5GDate1PZ6ke538B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com>
	<E12D1B9F-8457-4AED-952D-158B0F9F9568@virtualized.org>
	<D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com>
	<CAFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org>
	<2D503821-1ABB-411A-9C49-F6EC7A54E460@corp.arin.net>
	<CD1B0373-BD30-499B-AA54-12029035AB48@virtualized.org>
	<CB47563D-65ED-493D-B2BD-ECB87FD4EF07@arin.net>
	<52FBBE3E.9060700@dilkie.com>
	<0746AB32-3156-401B-8503-88E8665960F5@arin.net>
	<52FBFCD8.1040303@dilkie.com>
	<FA2E5D83-3D61-4DD4-8C40-548F2C5C5104@arin.net>
Message-ID: <1D68DE04-BC2E-4295-A310-9CB5B438C743@delong.com>


On Feb 12, 2014, at 3:46 PM, John Curran <jcurran at arin.net> wrote:

>> Not really sure you got my point... There is no "needs" test for me to transfer ownership of my car to you and the province cannot step in and stop it, they are only interested in keeping their records straight.... 
> 
> Lee -
> 
>    There are still requirements (even if nominal) if you hope 
>    to transfer title, and if you don't meet them then your car 
>    is not sold.  The records at the registry remain accurate
>    in either case.
> 
Indeed, at least in California, there are two separate registry transactions?

1.	The registrant relinquishes title. This is done by submitting the filled out
	?transfer? portion of the original title (?pink slip?).

2.	The new owner is expected to submit the paperwork to complete the
	transfer of registration and title.

The first transaction covers the previous owner in case of the second not being
completed.

Owen



From owen at delong.com  Thu Feb 13 16:51:14 2014
From: owen at delong.com (Owen DeLong)
Date: Thu, 13 Feb 2014 13:51:14 -0800
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy InternetResource
	Holders
In-Reply-To: <5D25514F-2881-47A8-BBE9-045577D8747D@virtualized.org>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
	<CAMDXq5Ma1Hq0YOVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com>
	<CAC1-dtn5GDate1PZ6ke538B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com>
	<E12D1B9F-8457-4AED-952D-158B0F9F9568@virtualized.org>
	<D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com>
	<CAFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org>
	<2D503821-1ABB-411A-9C49-F6EC7A54E460@corp.arin.net>
	<CD1B0373-BD30-499B-AA54-12029035AB48@virtualized.org>
	<CB47563D-65ED-493D-B2BD-ECB87FD4EF07@arin.net>
	<5D25514F-2881-47A8-BBE9-045577D8747D@virtualized.org>
Message-ID: <42E3550B-9BA4-48F7-A65F-239B2B9D4C27@delong.com>


On Feb 12, 2014, at 5:43 PM, David Conrad <drc at virtualized.org> wrote:

> John,
> 
> On Feb 12, 2014, at 1:13 PM, John Curran <jcurran at arin.net> wrote:
>>> "The importance of maintaining accurate records in the ARIN database is recognized as ARIN's principal task."
>> Alas, your very clear formulation won't be very informative, 
>> since the registry is accurate even after a denied transfer
> 
> You appear to be assuming that if ARIN denies the transfer, the transfer doesn't occur.
> 
> Do you really believe that?
> 

By definition, that is true as far as the transfer of the registration.

However, I believe at this point you and John are talking about two different things.

You are talking about the transfer of the use of the numbers as IP addresses routed on the internet.

John is talking about the transfer of the registration of the addresses within the RIR system.

Yes, the two can happen independently of one another.

You are arguing (if I understand correctly) that when the transfer of usage occurs without the transfer of registration, that is a bad thing and you believe that there should be no limits on the transfer of registration in order to prevent this dichotomy from developing.

I don?t happen to agree with your position. As noted in earlier threads, transfers of the use of number resources which occur contrary to registry party are unable to be registered.

Owen



From owen at delong.com  Thu Feb 13 16:58:58 2014
From: owen at delong.com (Owen DeLong)
Date: Thu, 13 Feb 2014 13:58:58 -0800
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy InternetResource
	Holders
In-Reply-To: <52FC537C.6020902@matthew.at>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>	<CAMDXq5Ma1Hq0YOVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com>	<5B9E90747FA2974D91A54FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com>	<CAC1-dtn5GDate1PZ6ke538B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com>	<E12D1B9F-8457-4AED-952D-158B0F9F9568@virtualized.org>	<D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com>	<CAFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org>	<2D503821-1ABB-411A-9C49-F6EC7A54E460@corp.arin.net>	<CD1B0373-BD30-499B-AA54-12029035AB48@virtualized.org>	<CB47563D-65ED-493D-B2BD-ECB87FD4EF07@arin.net>
	<5D25514F-2881-47A8-BBE9-045577D8747D@virtualized.org>
	<52FC537C.6020902@matthew.at>
Message-ID: <5CE7C27F-79CE-4ABB-AFB3-A06F47D1F2E8@delong.com>


On Feb 12, 2014, at 9:09 PM, Matthew Kaufman <matthew at matthew.at> wrote:

> 
> On 2/12/14, 5:43 PM, David Conrad wrote:
>> And by the way, continuing to try to associate transfers between mutually agreeable parties as theft or illegal activity isn't really helping the conversation.
> 
> +1. Especially when the transfers involve addresses for which no RSA has been signed. Either ARIN should stop maintaining a registry of pre-ARIN-assigned no-RSA-associated addresses altogether, or ensure that such a registry is relatively accurate.
> 

Fair enough? Would you consider the sale of alcohol to a minor a more apt metaphor for the attempt to transfer resources registered to one party to another party which is ineligible to receive them under policy?

The registry is accurate. ARIN policy does apply to legacy resources, 

> I understand that ARIN *can* decide to pretend that it somehow prevents the transfers from happening by refusing to record changes in "ownership" that are done outside of policy (and certainly has the right to refuse to record the changes, what with there being no agreement with the parties and all), but I don't see how that furthers the goal of maintaining an accurate registry, which I presume is why ARIN includes legacy addresses in its registry at all.

I would argue that framing ARIN refusing to record transfers attempted in circumvention of policy as ?pretending that it can prevent them? as being equally counterproductive to the theft analogies.

Owen



From Timothy.S.Morizot at irs.gov  Thu Feb 13 17:05:15 2014
From: Timothy.S.Morizot at irs.gov (Morizot Timothy S)
Date: Thu, 13 Feb 2014 22:05:15 +0000
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy
	InternetResource	Holders
In-Reply-To: <1D68DE04-BC2E-4295-A310-9CB5B438C743@delong.com>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
	<CAMDXq5Ma1Hq0YOVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com>
	<CAC1-dtn5GDate1PZ6ke538B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com>
	<E12D1B9F-8457-4AED-952D-158B0F9F9568@virtualized.org>
	<D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com>
	<CAFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org>
	<2D503821-1ABB-411A-9C49-F6EC7A54E460@corp.arin.net>
	<CD1B0373-BD30-499B-AA54-12029035AB48@virtualized.org>
	<CB47563D-65ED-493D-B2BD-ECB87FD4EF07@arin.net>
	<52FBBE3E.9060700@dilkie.com>
	<0746AB32-3156-401B-8503-88E8665960F5@arin.net>
	<52FBFCD8.1040303@dilkie.com>
	<FA2E5D83-3D61-4DD4-8C40-548F2C5C5104@arin.net>
	<1D68DE04-BC2E-4295-A310-9CB5B438C743@delong.com>
Message-ID: <968C470DAC25FB419E0159952F28F0C06A7335B3@MEM0200CP3XF01.ds.irsnet.gov>

On Feb 12, 2014, at 3:46 PM, John Curran <jcurran at arin.net> wrote:

>> Not really sure you got my point... There is no "needs" test for me to transfer ownership of my car to you and the province cannot step in and stop it, they are only interested in keeping their records straight.... 
> 
> Lee -
> 
>    There are still requirements (even if nominal) if you hope 
>    to transfer title, and if you don't meet them then your car 
>    is not sold.  The records at the registry remain accurate
>    in either case.
> 

Hmmm. I'll also note that transfer of title for a car you own is not the best analogy. Even when we obtained our legacy allocations back in the early 90s, they weren't "sold" to us. They remained an Internet number resource allocated to us for our use. So the better analogy would perhaps be trying to transfer a car lease you currently hold to another person. (It's definitely still a flawed analogy, but possibly better than the title transfer analogy.)

Scott



From SRyerse at eclipse-networks.com  Thu Feb 13 17:08:00 2014
From: SRyerse at eclipse-networks.com (Steven Ryerse)
Date: Thu, 13 Feb 2014 22:08:00 +0000
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy
 InternetResourceHolders
In-Reply-To: <42E3550B-9BA4-48F7-A65F-239B2B9D4C27@delong.com>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com><CAMDXq5Ma1Hq0Y
	OVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com><5B9E90747FA2974D91A54
	FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com><CAC1-dtn5GDate1PZ6ke53
	8B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com><E12D1B9F-8457-4AED-952D-158B0
	F9F9568@virtualized.org><D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com><C
	AFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org><2D503821-1ABB-411A-9C4
	9-F6EC7A54E460@corp.arin.net><CD1B0373-BD30-499B-AA54-12029035AB48@virtuali
	zed.org><CB47563D-65ED-493D-B2BD-ECB87FD4EF07@arin.net><5D25514F-2881-47A8-BBE9-045577D8747D@virtualized.org>
	<42E3550B-9BA4-48F7-A65F-239B2B9D4C27@delong.com>
Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12014C03376E@ENI-MAIL.eclipse-networks.com>

The problem with your California analogy of course is that even though the car (i.e. Legacy Block) might have been titled in California originally (i.e. NSF), the sales transaction might have happened in another state or even another country (i.e. private transaction completely outside ARIN) and California can't say after the fact that they won't recognize the sale of the car as the car was sold legally and therefore California can't somehow void or disavow the transaction.  

Maybe the NSF or congress could void those Legacy transactions but ARIN doesn't have the legal authority to void them or declare them somehow to be invalid.  

I think that the new RIPE policy is acknowledging this reality and I think ARIN adopting the same identical policy makes sense because it would allow the coming together of Legacy holders and ARIN allocations holders which I think is in everyone's interest.

Note that I would expect ARIN to be able to request and receive proof of a completed transaction before they update their database with the new information.  

Steven L Ryerse
President
100 Ashford Center North, Suite 110, Atlanta, GA? 30338
770.656.1460 - Cell
770.399.9099 - Office
770.392-0076 - Fax

? Eclipse Networks, Inc.
             ??????? Conquering Complex Networks?

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong
Sent: Thursday, February 13, 2014 4:51 PM
To: David Conrad
Cc: John Curran; arin-ppml at arin.net
Subject: Re: [arin-ppml] FYI -- RIPE-605 Services to Legacy InternetResourceHolders


On Feb 12, 2014, at 5:43 PM, David Conrad <drc at virtualized.org> wrote:

> John,
> 
> On Feb 12, 2014, at 1:13 PM, John Curran <jcurran at arin.net> wrote:
>>> "The importance of maintaining accurate records in the ARIN database is recognized as ARIN's principal task."
>> Alas, your very clear formulation won't be very informative, since 
>> the registry is accurate even after a denied transfer
> 
> You appear to be assuming that if ARIN denies the transfer, the transfer doesn't occur.
> 
> Do you really believe that?
> 

By definition, that is true as far as the transfer of the registration.

However, I believe at this point you and John are talking about two different things.

You are talking about the transfer of the use of the numbers as IP addresses routed on the internet.

John is talking about the transfer of the registration of the addresses within the RIR system.

Yes, the two can happen independently of one another.

You are arguing (if I understand correctly) that when the transfer of usage occurs without the transfer of registration, that is a bad thing and you believe that there should be no limits on the transfer of registration in order to prevent this dichotomy from developing.

I don?t happen to agree with your position. As noted in earlier threads, transfers of the use of number resources which occur contrary to registry party are unable to be registered.

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 Timothy.S.Morizot at irs.gov  Thu Feb 13 17:24:07 2014
From: Timothy.S.Morizot at irs.gov (Morizot Timothy S)
Date: Thu, 13 Feb 2014 22:24:07 +0000
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy
 InternetResourceHolders
In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12014C03376E@ENI-MAIL.eclipse-networks.com>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com><CAMDXq5Ma1Hq0Y
	OVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com><5B9E90747FA2974D91A54
	FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com><CAC1-dtn5GDate1PZ6ke53
	8B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com><E12D1B9F-8457-4AED-952D-158B0
	F9F9568@virtualized.org><D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com><C
	AFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org><2D503821-1ABB-411A-9C4
	9-F6EC7A54E460@corp.arin.net><CD1B0373-BD30-499B-AA54-12029035AB48@virtuali
	zed.org><CB47563D-65ED-493D-B2BD-ECB87FD4EF07@arin.net><5D25514F-2881-47A8-BBE9-045577D8747D@virtualized.org>
	<42E3550B-9BA4-48F7-A65F-239B2B9D4C27@delong.com>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C03376E@ENI-MAIL.eclipse-networks.com>
Message-ID: <968C470DAC25FB419E0159952F28F0C06A7335D8@MEM0200CP3XF01.ds.irsnet.gov>

Steven L Ryerse wrote:
>I think that the new RIPE policy is acknowledging this reality and I think ARIN adopting
>the same identical policy makes sense because it would allow the coming together of
>Legacy holders and ARIN allocations holders which I think is in everyone's interest.
>
>Note that I would expect ARIN to be able to request and receive proof of a
>completed transaction before they update their database with the new information.  

Interesting. So you believe it's in the interest of those of us who have signed RSAs and LRSAs to subsidize (through our annual fees) those who want free registry services even though they refuse to adhere to the number resource policy in our region. That policy, in part, requires that the recipient of a legacy resource transfer, who  by definition cannot be a legacy allocation recipient, sign an RSA and contribute toward the cost of providing those registry services.

That's an interesting perspective, but I'm not sure I agree. ARIN can't really control use and advertisement of resources, but if someone who isn't a pre-ARIN legacy recipient expects to receive registry services, I'm okay with requiring them to sign an RSA and pay for those services.

Scott


From jcurran at arin.net  Thu Feb 13 17:55:08 2014
From: jcurran at arin.net (John Curran)
Date: Thu, 13 Feb 2014 22:55:08 +0000
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy	InternetResource
 Holders
In-Reply-To: <968C470DAC25FB419E0159952F28F0C06A7335B3@MEM0200CP3XF01.ds.irsnet.gov>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
	<CAMDXq5Ma1Hq0YOVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com>
	<CAC1-dtn5GDate1PZ6ke538B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com>
	<E12D1B9F-8457-4AED-952D-158B0F9F9568@virtualized.org>
	<D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com>
	<CAFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org>
	<2D503821-1ABB-411A-9C49-F6EC7A54E460@corp.arin.net>
	<CD1B0373-BD30-499B-AA54-12029035AB48@virtualized.org>
	<CB47563D-65ED-493D-B2BD-ECB87FD4EF07@arin.net>
	<52FBBE3E.9060700@dilkie.com>
	<0746AB32-3156-401B-8503-88E8665960F5@arin.net>
	<52FBFCD8.1040303@dilkie.com>
	<FA2E5D83-3D61-4DD4-8C40-548F2C5C5104@arin.net>
	<1D68DE04-BC2E-4295-A310-9CB5B438C743@delong.com>
	<968C470DAC25FB419E0159952F28F0C06A7335B3@MEM0200CP3XF01.ds.irsnet.gov>
Message-ID: <255C06D3-F5B0-4ADE-A5B9-1D05AA6D0654@arin.net>

On Feb 13, 2014, at 3:05 PM, Morizot Timothy S <Timothy.S.Morizot at irs.gov> wrote:
> Hmmm. I'll also note that transfer of title for a car you own is not the best analogy. Even when we obtained our legacy allocations back in the early 90s, they weren't "sold" to us. They remained an Internet number resource allocated to us for our use. So the better analogy would perhaps be trying to transfer a car lease you currently hold to another person. (It's definitely still a flawed analogy, but possibly better than the title transfer analogy.)

Several folks have noted that these analogies are all imperfect, and 
it's even worse than described when it comes IP address blocks issued
because they are unique only because of the fact that they were issued
out of a particular registry.

You can use any number you wish in your routers, and you can even run 
your own registry and coordinate unique [within your registry] block 
assignments (and there was at least one industries that did this for
their own private VPN-like connectivity among suppliers), but what 
someone refers to as their IP address block is actually their "IP 
address block assignment" from the Internet Registry system, i.e. one 
particular coordinated registry intended for general purpose IP 
assignments of global scope.

This means that the registration in the registry is actually the only
tangible entity involved here; i.e. back to analogies, there is no car 
at all - just the registration.  References that imply your "IP address 
block" is a license for use on the global Internet is clearly specious, 
since those routers are operated by others who never granted such rights.
Aside from the uniqueness provided by the registration entry and rights 
to same, it's hard to see what folks are trying to "sell"...

FYI,
/John
 
John Curran
President and CEO
ARIN



From jcurran at arin.net  Thu Feb 13 18:00:29 2014
From: jcurran at arin.net (John Curran)
Date: Thu, 13 Feb 2014 23:00:29 +0000
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy
 InternetResourceHolders
In-Reply-To: <968C470DAC25FB419E0159952F28F0C06A7335D8@MEM0200CP3XF01.ds.irsnet.gov>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
	<"CAMDXq5Ma1Hq0Y OVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ"@mail.gmail.com>
	<"5B9E90747FA2974D91A54
	FCFA1B8AD12014C027054"@ENI-MAIL.eclipse-networks.com>
	<"CAC1-dtn5GDate1PZ6ke53 8B-utR5YvBS6cPet3fY=a7X7v=xoA"@mail.gmail.com>
	<"E12D1B9F-8457-4AED-952D-158B0 F9F9568"@virtualized.org>
	<D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com> <"C
	AFBC610-D7BE-4078-964A-C08C1C1853F0"@virtualized.org>
	<"2D503821-1ABB-411A-9C4 9-F6EC7A54E460"@corp.arin.net>
	<CD1B0373-BD30-499B-AA54-12029035AB48@virtuali> <zed.org@mac.com>
	<CB47563D-65ED-493D-B2BD-ECB87FD4EF07@arin.net>
	<5D25514F-2881-47A8-BBE9-045577D8747D@virtualized.org>
	<42E3550B-9BA4-48F7-A65F-239B2B9D4C27@delong.com>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C03376E@ENI-MAIL.eclipse-networks.com>
	<968C470DAC25FB419E0159952F28F0C06A7335D8@MEM0200CP3XF01.ds.irsnet.gov>
Message-ID: <618EE847-054F-4F7C-8487-5D822592DC07@arin.net>

On Feb 13, 2014, at 3:24 PM, Morizot Timothy S <Timothy.S.Morizot at irs.gov> wrote:

> Interesting. So you believe it's in the interest of those of us who have signed RSAs and LRSAs to subsidize (through our annual fees) those who want free registry services even though they refuse to adhere to the number resource policy in our region. That policy, in part, requires that the recipient of a legacy resource transfer, who  by definition cannot be a legacy allocation recipient, sign an RSA and contribute toward the cost of providing those registry services.
> 
> That's an interesting perspective, but I'm not sure I agree. ARIN can't really control use and advertisement of resources, but if someone who isn't a pre-ARIN legacy recipient expects to receive registry services, I'm okay with requiring them to sign an RSA and pay for those services.

Just FYI - the ARIN Board of Trustees has consistently indicated that ARIN should
provide the same basic services to legacy resource holders without charge, so that 
they may make use of the number resources with minimal effort.   We do encourage 
them to enter into an LRSA both to share in costs and receive clear contractual 
rights, but there is no obligation for them to do in order to continue to receive
registry systems (and this is similar to the RIPE 605 section re "No Relationship")

/John

John Curran
President and CEO
ARIN





From farmer at umn.edu  Thu Feb 13 18:11:46 2014
From: farmer at umn.edu (David Farmer)
Date: Thu, 13 Feb 2014 17:11:46 -0600
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy
	InternetResourceHolders
In-Reply-To: <968C470DAC25FB419E0159952F28F0C06A7335D8@MEM0200CP3XF01.ds.irsnet.gov>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com><CAMDXq5Ma1Hq0Y	OVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com><5B9E90747FA2974D91A54	FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com><CAC1-dtn5GDate1PZ6ke53	8B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com><E12D1B9F-8457-4AED-952D-158B0	F9F9568@virtualized.org><D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com><C	AFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org><2D503821-1ABB-411A-9C4	9-F6EC7A54E460@corp.arin.net><CD1B0373-BD30-499B-AA54-12029035AB48@virtuali	zed.org><CB47563D-65ED-493D-B2BD-ECB87FD4EF07@arin.net><5D25514F-2881-47A8-BBE9-045577D8747D@virtualized.org>	<42E3550B-9BA4-48F7-A65F-239B2B9D4C27@delong.com>	<5B9E90747FA2974D91A54FCFA1B8AD12014C03376E@ENI-MAIL.eclipse-networks.com>
	<968C470DAC25FB419E0159952F28F0C06A7335D8@MEM0200CP3XF01.ds.irsnet.gov>
Message-ID: <52FD5132.6050701@umn.edu>

On 2/13/14, 16:24 , Morizot Timothy S wrote:
> Steven L Ryerse wrote:
>> I think that the new RIPE policy is acknowledging this reality and I think ARIN adopting
>> the same identical policy makes sense because it would allow the coming together of
>> Legacy holders and ARIN allocations holders which I think is in everyone's interest.
>>
>> Note that I would expect ARIN to be able to request and receive proof of a
>> completed transaction before they update their database with the new information.
>
> Interesting. So you believe it's in the interest of those of us who have signed RSAs and LRSAs to subsidize (through our annual fees) those who want free registry services even though they refuse to adhere to the number resource policy in our region. That policy, in part, requires that the recipient of a legacy resource transfer, who  by definition cannot be a legacy allocation recipient, sign an RSA and contribute toward the cost of providing those registry services.
>
> That's an interesting perspective, but I'm not sure I agree. ARIN can't really control use and advertisement of resources, but if someone who isn't a pre-ARIN legacy recipient expects to receive registry services, I'm okay with requiring them to sign an RSA and pay for those services.
>
> Scott

This is actually becoming an interesting discussion, and I don't 
necessarily want to squelch it.  Also, I thank Marty for bringing this 
change of RIPE policy to our community's attention.

However, I want to remind everyone we have nine Draft Policies of our 
own on the ARIN policy docket, they were discussed at the NANOG-PPC this 
week.  But, the AC can always use more feedback.  So, please remember to 
take some time to review and comment on the Draft Policies on the ARIN 
policy docket, especially if we did not get your feedback during the 
NANOG-PPC this week.

There is only two short months before ARIN 33 in Chicago, and the AC 
needs to lock down text for any Recommended Draft Policies 30 days 
before the meeting.  So we need your feedback real soon now.

Thanks.

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


From owen at delong.com  Thu Feb 13 18:13:23 2014
From: owen at delong.com (Owen DeLong)
Date: Thu, 13 Feb 2014 15:13:23 -0800
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy InternetResource
	Holders
In-Reply-To: <CAMDXq5PtAh3ovEsUYbkYW1aTa+3CxuDcP7pQK1KLD=X3t4DkKw@mail.gmail.com>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
	<CAMDXq5Ma1Hq0YOVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com>
	<CAC1-dtn5GDate1PZ6ke538B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com>
	<E12D1B9F-8457-4AED-952D-158B0F9F9568@virtualized.org>
	<D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com>
	<CAFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org>
	<2D503821-1ABB-411A-9C49-F6EC7A54E460@corp.arin.net>
	<CD1B0373-BD30-499B-AA54-12029035AB48@virtualized.org>
	<CB47563D-65ED-493D-B2BD-ECB87FD4EF07@arin.net>
	<5D25514F-2881-47A8-BBE9-045577D8747D@virtualized.org>
	<687DFF93-4C22-4A48-BA74-9736DA95B609@arin.net>
	<6DDFCA18-A609-471E-AFF8-23FD1BCDFC35@virtualized.org>
	<2AE523C2-B9DF-4401-8B7E-C135AE394931@arin.net>
	<CAMDXq5PtAh3ovEsUYbkYW1aTa+3CxuDcP7pQK1KLD=X3t4DkKw@mail.gmail.com>
Message-ID: <7AB65681-B68C-4597-BA9F-861C502CAF8F@delong.com>


On Feb 13, 2014, at 9:07 AM, Martin Hannigan <hannigan at gmail.com> wrote:

> 
> 
> On Thu, Feb 13, 2014 at 11:58 AM, John Curran <jcurran at arin.net> wrote:
> On Feb 13, 2014, at 9:18 AM, David Conrad <drc at virtualized.org> wrote:
> 
> [ clip ]
>  
> 
> > However, to be honest, I'm not that interested in playing the ancient history game -- I find the whole exercise pointless and boring. I am, however, interested in what policy changes you believe it will take to get ARIN to accurately reflect reality in its registry database. What's it going to take?
> 
> I have been attempting to follow up on your suggestion to poll the
> community, but we seem to have reached an impasse because ARIN is
> keeping the registry accurate and your formulation would suggest
> otherwise. Hence, my attempt at a more balanced phrasing, i.e. that
> we should "survey the ARIN community regarding the prioritization of
> needs-based transfers vs operational usefulness of registry data."
> If we can come up with acceptable language, we'll figure out how to
> poll the ARIN community on this topic.
> 
> 
> 
> 
> How about polling resource holders instead? A much larger audience.
> 

Not sure how you figure that?

ARIN Community: Anyone with an email address who wishes to participate.
Resource Holders: Anyone with an object registered in the ARIN database.

While it is true that the latter is a larger group, in reality, the poll would effectively involve only the ?Resource holders who choose to participate?, which I would argue is a subset of ?those with an email address who wish to participate?.

Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140213/331faa5c/attachment.htm>

From hannigan at gmail.com  Thu Feb 13 18:18:08 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Thu, 13 Feb 2014 18:18:08 -0500
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy
	InternetResourceHolders
In-Reply-To: <52FD5132.6050701@umn.edu>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
	<D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com>
	<CB47563D-65ED-493D-B2BD-ECB87FD4EF07@arin.net>
	<5D25514F-2881-47A8-BBE9-045577D8747D@virtualized.org>
	<42E3550B-9BA4-48F7-A65F-239B2B9D4C27@delong.com>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C03376E@ENI-MAIL.eclipse-networks.com>
	<968C470DAC25FB419E0159952F28F0C06A7335D8@MEM0200CP3XF01.ds.irsnet.gov>
	<52FD5132.6050701@umn.edu>
Message-ID: <CAMDXq5NKn-Ut6BoKgDpEiMKMVJWzVMQs2tjaDt2rvMag69LWSw@mail.gmail.com>

On Thu, Feb 13, 2014 at 6:11 PM, David Farmer <farmer at umn.edu> wrote:

> On 2/13/14, 16:24 , Morizot Timothy S wrote:
>
>> Steven L Ryerse wrote:
>>
>>> I think that the new RIPE policy is acknowledging this reality and I
>>> think ARIN adopting
>>> the same identical policy makes sense because it would allow the coming
>>> together of
>>> Legacy holders and ARIN allocations holders which I think is in
>>> everyone's interest.
>>>
>>> Note that I would expect ARIN to be able to request and receive proof of
>>> a
>>> completed transaction before they update their database with the new
>>> information.
>>>
>>
>> Interesting. So you believe it's in the interest of those of us who have
>> signed RSAs and LRSAs to subsidize (through our annual fees) those who want
>> free registry services even though they refuse to adhere to the number
>> resource policy in our region. That policy, in part, requires that the
>> recipient of a legacy resource transfer, who  by definition cannot be a
>> legacy allocation recipient, sign an RSA and contribute toward the cost of
>> providing those registry services.
>>
>> That's an interesting perspective, but I'm not sure I agree. ARIN can't
>> really control use and advertisement of resources, but if someone who isn't
>> a pre-ARIN legacy recipient expects to receive registry services, I'm okay
>> with requiring them to sign an RSA and pay for those services.
>>
>> Scott
>>
>
> This is actually becoming an interesting discussion, and I don't
> necessarily want to squelch it.  Also, I thank Marty for bringing this
> change of RIPE policy to our community's attention.
>

You're welcome.


>
> However, I want to remind everyone we have nine Draft Policies of our own
> on the ARIN policy docket, they were discussed at the NANOG-PPC this week.
>  But, the AC can always use more feedback.  So, please remember to take
> some time to review and comment on the Draft Policies on the ARIN policy
> docket, especially if we did not get your feedback during the NANOG-PPC
> this week.
>

Which to be honest, is embarrassing. Almost all of them were focused on
moving deck chairs with respect to IPv4 and competing for who could write a
better proposal. It was like watching dueling banjos for the most part.

But I did also suggest that we might want to adopt something like RIPE-605
since this thread is likely to conclude "game over" with respect to the
arguments around property and rights.


> There is only two short months before ARIN 33 in Chicago, and the AC needs
> to lock down text for any Recommended Draft Policies 30 days before the
> meeting.  So we need your feedback real soon now.
>


I plan to submit a modified version of 605 RSN.

Best,

-M<
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140213/a320a6c0/attachment.htm>

From Timothy.S.Morizot at irs.gov  Thu Feb 13 18:35:51 2014
From: Timothy.S.Morizot at irs.gov (Morizot Timothy S)
Date: Thu, 13 Feb 2014 23:35:51 +0000
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy
 InternetResourceHolders
In-Reply-To: <618EE847-054F-4F7C-8487-5D822592DC07@arin.net>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
	<"CAMDXq5Ma1Hq0Y OVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ"@mail.gmail.com>
	<"5B9E90747FA2974D91A54
	FCFA1B8AD12014C027054"@ENI-MAIL.eclipse-networks.com>
	<"CAC1-dtn5GDate1PZ6ke53 8B-utR5YvBS6cPet3fY=a7X7v=xoA"@mail.gmail.com>
	<"E12D1B9F-8457-4AED-952D-158B0 F9F9568"@virtualized.org>
	<D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com> <"C
	AFBC610-D7BE-4078-964A-C08C1C1853F0"@virtualized.org>
	<"2D503821-1ABB-411A-9C4 9-F6EC7A54E460"@corp.arin.net>
	<CD1B0373-BD30-499B-AA54-12029035AB48@virtuali> <zed.org@mac.com>
	<CB47563D-65ED-493D-B2BD-ECB87FD4EF07@arin.net>
	<5D25514F-2881-47A8-BBE9-045577D8747D@virtualized.org>
	<42E3550B-9BA4-48F7-A65F-239B2B9D4C27@delong.com>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C03376E@ENI-MAIL.eclipse-networks.com>
	<968C470DAC25FB419E0159952F28F0C06A7335D8@MEM0200CP3XF01.ds.irsnet.gov>
	<618EE847-054F-4F7C-8487-5D822592DC07@arin.net>
Message-ID: <968C470DAC25FB419E0159952F28F0C06A733799@MEM0200CP3XF01.ds.irsnet.gov>

John Curran wrote:
>Just FYI - the ARIN Board of Trustees has consistently indicated that ARIN should
>provide the same basic services to legacy resource holders without charge, so that 
>they may make use of the number resources with minimal effort.   We do encourage 
>them to enter into an LRSA both to share in costs and receive clear contractual 
>rights, but there is no obligation for them to do in order to continue to receive
>registry systems (and this is similar to the RIPE 605 section re "No Relationship")

Yes, and I agree with and support that approach. We received registry services for years under that provision before signing an LRSA. That was mostly due to inattention and a lack of awareness. I'm not even sure when the LRSA option was developed. I absolutely support providing registry services to actual legacy resource holders whether or not they've signed a resource agreement.

My point was that someone receiving a new allocation now, even if it's a transfer from a legacy resource holder, is not a legacy resource holder. Only the original holder (or whatever entity the legal chain of acquisition and merger indicates is the descendant of that original holder in some cases) can be considered the legacy  holder. At least, I've always understood that the legacy definition is associated with the holder because they received the allocation prior to the formation of ARIN. Someone who obtains an allocation of number resources now, whether from the free pool or the transfer market, is not a legacy holder. I don't agree with providing free basic registry services to that group. I view their refusal to enter into an agreement with ARIN as a decision to utilize the numbers without registering them directly. They may have an agreement with the registered legacy holder that the legacy resource holder will not announce the numbers but that's a private two-party agreement and not an agreement with the registrar. And if they expect direct registry services or believe they need it, then caveat emptor would seem to apply.

Scott
 


From SRyerse at eclipse-networks.com  Thu Feb 13 18:49:20 2014
From: SRyerse at eclipse-networks.com (Steven Ryerse)
Date: Thu, 13 Feb 2014 23:49:20 +0000
Subject: [arin-ppml] FYI -- RIPE-605 Services to
 LegacyInternetResourceHolders
In-Reply-To: <968C470DAC25FB419E0159952F28F0C06A7335D8@MEM0200CP3XF01.ds.irsnet.gov>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com><CAMDXq5Ma1Hq0Y
	OVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com><5B9E90747FA2974D91A54
	FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com><CAC1-dtn5GDate1PZ6ke53
	8B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com><E12D1B9F-8457-4AED-952D-158B0
	F9F9568@virtualized.org><D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com><C
	AFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org><2D503821-1ABB-411A-9C4
	9-F6EC7A54E460@corp.arin.net><CD1B0373-BD30-499B-AA54-12029035AB48@virtuali
	zed.org><CB47563D-65ED-493D-B2BD-ECB87FD4EF07@arin.net><5D25514F-2881-47A8-
	BBE9-045577D8747D@virtualized.org><42E3550B-9BA4-48F7-A65F-239B2B9D4C27@del
	ong.com><5B9E90747FA2974D91A54FCFA1B8AD12014C03376E@ENI-MAIL.eclipse-networks.com>
	<968C470DAC25FB419E0159952F28F0C06A7335D8@MEM0200CP3XF01.ds.irsnet.gov>
Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12014C033D0A@ENI-MAIL.eclipse-networks.com>

I understand your concern and even share it to a point but we need to deal with real life, and real life is that it is pretty unlikely to get all of the original /8 and other large block legacy holders to sign contracts with ARIN (not to mention the small legacy block holders).  

Do you really think that ALL of the AT&Ts & Verizons and Fords - not to mention the DOD - and all of the other fortune 1000 companies that hold large legacy blocks are going to sign agreements. 

No one can force them to and no one should try and force them.  This goes for the thousands of organizations that got Class C blocks as well.  Real life is that they all exist and ARIN has no direct legal authority over them.  

It is just time to stop playing like these legacy holders don't exist and bring them into the community without requiring them to do anything and I think the RIP 605 does just that.  My two cents.  

Steven L Ryerse
President
100 Ashford Center North, Suite 110, Atlanta, GA? 30338
770.656.1460 - Cell
770.399.9099 - Office
770.392-0076 - Fax

? Eclipse Networks, Inc.
             ??????? Conquering Complex Networks?

-----Original Message-----
From: Morizot Timothy S [mailto:Timothy.S.Morizot at irs.gov] 
Sent: Thursday, February 13, 2014 5:24 PM
To: Steven Ryerse; 'Owen DeLong'; David Conrad
Cc: John Curran; arin-ppml at arin.net
Subject: RE: [arin-ppml] FYI -- RIPE-605 Services to LegacyInternetResourceHolders

Steven L Ryerse wrote:
>I think that the new RIPE policy is acknowledging this reality and I 
>think ARIN adopting the same identical policy makes sense because it 
>would allow the coming together of Legacy holders and ARIN allocations holders which I think is in everyone's interest.
>
>Note that I would expect ARIN to be able to request and receive proof 
>of a completed transaction before they update their database with the new information.

Interesting. So you believe it's in the interest of those of us who have signed RSAs and LRSAs to subsidize (through our annual fees) those who want free registry services even though they refuse to adhere to the number resource policy in our region. That policy, in part, requires that the recipient of a legacy resource transfer, who  by definition cannot be a legacy allocation recipient, sign an RSA and contribute toward the cost of providing those registry services.

That's an interesting perspective, but I'm not sure I agree. ARIN can't really control use and advertisement of resources, but if someone who isn't a pre-ARIN legacy recipient expects to receive registry services, I'm okay with requiring them to sign an RSA and pay for those services.

Scott


From jcurran at arin.net  Thu Feb 13 19:11:21 2014
From: jcurran at arin.net (John Curran)
Date: Fri, 14 Feb 2014 00:11:21 +0000
Subject: [arin-ppml] FYI -- RIPE-605 Services to
 LegacyInternetResourceHolders
In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12014C033D0A@ENI-MAIL.eclipse-networks.com>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
	<"CAMDXq5Ma1Hq0Y OVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ"@mail.gmail.com>
	<"5B9E90747FA2974D91A54
	FCFA1B8AD12014C027054"@ENI-MAIL.eclipse-networks.com>
	<"CAC1-dtn5GDate1PZ6ke53 8B-utR5YvBS6cPet3fY=a7X7v=xoA"@mail.gmail.com>
	<"E12D1B9F-8457-4AED-952D-158B0 F9F9568"@virtualized.org>
	<D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com> <"C
	AFBC610-D7BE-4078-964A-C08C1C1853F0"@virtualized.org>
	<"2D503821-1ABB-411A-9C4 9-F6EC7A54E460"@corp.arin.net>
	<CD1B0373-BD30-499B-AA54-12029035AB48@virtuali> <zed.org@mac.com>
	<CB47563D-65ED-493D-B2BD-ECB87FD4EF07@arin.net> <"5D25514F-2881-47A8-
	BBE9-045577D8747D"@virtualized.org>
	<42E3550B-9BA4-48F7-A65F-239B2B9D4C27@del> <ong.com@mac.com>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C03376E@ENI-MAIL.eclipse-networks.com>
	<968C470DAC25FB419E0159952F28F0C06A7335D8@MEM0200CP3XF01.ds.irsnet.gov>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C033D0A@ENI-MAIL.eclipse-networks.com>
Message-ID: <A10D22C3-391B-41B4-8522-2865167F1EC8@arin.net>

On Feb 13, 2014, at 4:49 PM, Steven Ryerse <SRyerse at eclipse-networks.com> wrote:

> I understand your concern and even share it to a point but we need to deal with real life, and real life is that it is pretty unlikely to get all of the original /8 and other large block legacy holders to sign contracts with ARIN (not to mention the small legacy block holders).  
> 
> Do you really think that ALL of the AT&Ts & Verizons and Fords - not to mention the DOD - and all of the other fortune 1000 companies that hold large legacy blocks are going to sign agreements. 

There's no reason for them to enter into an agreement with ARIN unless 
they wish to, either to support their share of the costs or to gain the 
benefit of having a defined contractual relationship.

And you should note that quite a bit of that address space is effectively 
coming into the system as the result of transfers per NRPM 8.3, and that 
includes increasingly pieces from /8 blocks.   Transfer statistics are 
available here: <https://www.arin.net/knowledge/statistics/transfers.html>

> No one can force them to and no one should try and force them.

ARIN doesn't.  We require compliance with the community policies if they 
wish to transfer their block, but otherwise they continue to receive the
existing services relatively undisturbed.

> This goes for the thousands of organizations that got Class C blocks as well.  Real life is that they all exist and ARIN has no direct legal authority over them.

Steve - ARIN has all of the authority it needs with respect to the address 
blocks in question, as they are simply entries in the registry; a registry
which we were formed to administer according to community-developed policy.
  
Thanks!
/John

John Curran
President and CEO
ARIN



From narten at us.ibm.com  Fri Feb 14 00:53:01 2014
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 14 Feb 2014 00:53:01 -0500
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201402140553.s1E5r2Ws026210@rotala.raleigh.ibm.com>

Total of 119 messages in the last 7 days.
 
script run at: Fri Feb 14 00:53:01 EST 2014
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 16.81% |   20 | 13.88% |   144993 | jcurran at arin.net
  8.40% |   10 | 10.07% |   105190 | hannigan at gmail.com
  9.24% |   11 |  7.42% |    77522 | bill at herrin.us
  7.56% |    9 |  7.67% |    80077 | owen at delong.com
  5.88% |    7 |  6.09% |    63594 | farmer at umn.edu
  5.04% |    6 |  5.37% |    56088 | drc at virtualized.org
  4.20% |    5 |  5.59% |    58403 | mysidia at gmail.com
  4.20% |    5 |  5.48% |    57215 | sryerse at eclipse-networks.com
  5.04% |    6 |  3.51% |    36664 | matthew at matthew.at
  3.36% |    4 |  4.23% |    44160 | david.huberman at microsoft.com
  4.20% |    5 |  3.30% |    34434 | mueller at syr.edu
  2.52% |    3 |  2.87% |    29963 | lee at dilkie.com
  2.52% |    3 |  2.40% |    25065 | jeffrey.lyon at blacklotus.net
  2.52% |    3 |  2.25% |    23530 | timothy.s.morizot at irs.gov
  2.52% |    3 |  1.73% |    18104 | ajs at anvilwalrusden.com
  1.68% |    2 |  2.33% |    24342 | billdarte at gmail.com
  1.68% |    2 |  2.22% |    23140 | scottleibrand at gmail.com
  1.68% |    2 |  2.21% |    23046 | george.herbert at gmail.com
  0.84% |    1 |  2.14% |    22307 | cgrundemann at gmail.com
  1.68% |    2 |  1.15% |    12019 | info at arin.net
  0.84% |    1 |  1.20% |    12528 | rudi.daniel at gmail.com
  0.84% |    1 |  1.18% |    12310 | heather.skanks at gmail.com
  0.84% |    1 |  0.97% |    10165 | woody at pch.net
  0.84% |    1 |  0.89% |     9258 | cb.list6 at gmail.com
  0.84% |    1 |  0.76% |     7977 | springer at inlandnet.com
  0.84% |    1 |  0.69% |     7169 | narten at us.ibm.com
  0.84% |    1 |  0.66% |     6895 | bross at pobox.com
  0.84% |    1 |  0.63% |     6541 | lar at mwtcorp.net
  0.84% |    1 |  0.60% |     6295 | gary.buhrmaster at gmail.com
  0.84% |    1 |  0.51% |     5373 | ppml at rs.seastrom.com
--------+------+--------+----------+------------------------
100.00% |  119 |100.00% |  1044367 | Total



From Keith at jcc.com  Sat Feb 15 10:04:24 2014
From: Keith at jcc.com (Keith W. Hare)
Date: Sat, 15 Feb 2014 10:04:24 -0500
Subject: [arin-ppml] FYI -- RIPE-605 Services to
 LegacyInternetResourceHolders
In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12014C033D0A@ENI-MAIL.eclipse-networks.com>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com><CAMDXq5Ma1Hq0Y
	OVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com><5B9E90747FA2974D91A54
	FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com><CAC1-dtn5GDate1PZ6ke53
	8B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com><E12D1B9F-8457-4AED-952D-158B0
	F9F9568@virtualized.org><D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com><C
	AFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org><2D503821-1ABB-411A-9C4
	9-F6EC7A54E460@corp.arin.net><CD1B0373-BD30-499B-AA54-12029035AB48@virtuali
	zed.org><CB47563D-65ED-493D-B2BD-ECB87FD4EF07@arin.net><5D25514F-2881-47A8-
	BBE9-045577D8747D@virtualized.org><42E3550B-9BA4-48F7-A65F-239B2B9D4C27@del
	ong.com><5B9E90747FA2974D91A54FCFA1B8AD12014C03376E@ENI-MAIL.eclipse-networks.com>
	<968C470DAC25FB419E0159952F28F0C06A7335D8@MEM0200CP3XF01.ds.irsnet.gov>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C033D0A@ENI-MAIL.eclipse-networks.com>
Message-ID: <62D20B771F8F9C4EA8AEE574FF3869624DC57A28F0@mercury.jcc.com>





-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Steven Ryerse
Sent: Thursday, February 13, 2014 6:49 PM
To: 'Morizot Timothy S'
Cc: John Curran; arin-ppml at arin.net
Subject: Re: [arin-ppml] FYI -- RIPE-605 Services to LegacyInternetResourceHolders



I understand your concern and even share it to a point but we need to deal with real life, and real life is that it is pretty unlikely to get all of the original /8 and other large block legacy holders to sign contracts with ARIN (not to mention the small legacy block holders).





Looking at the Legacy Registration Agreement Statistics on https://www.arin.net/knowledge/statistics/legacy.html, a fair number of small legacy block holders HAVE signed the Legacy RSA.



Keith



______________________________________________________________

Keith W. Hare                     JCC Consulting, Inc.
keith at jcc.com<mailto:keith at jcc.com>                     600 Newark Granville Road
Phone: +1 740-587-0157            P.O. Box 381
Fax:   +1 740-587-0163            Granville, Ohio 43023
http://www.jcc.com<http://www.jcc.com/>                USA
______________________________________________________________



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140215/9c1f8bbe/attachment.htm>

From SRyerse at eclipse-networks.com  Sat Feb 15 10:10:42 2014
From: SRyerse at eclipse-networks.com (Steven Ryerse)
Date: Sat, 15 Feb 2014 15:10:42 +0000
Subject: [arin-ppml] FYI -- RIPE-605 Services
 toLegacyInternetResourceHolders
In-Reply-To: <62D20B771F8F9C4EA8AEE574FF3869624DC57A28F0@mercury.jcc.com>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com><CAMDXq5Ma1Hq0Y
	OVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com><5B9E90747FA2974D91A54
	FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com><CAC1-dtn5GDate1PZ6ke53
	8B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com><E12D1B9F-8457-4AED-952D-158B0
	F9F9568@virtualized.org><D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com><C
	AFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org><2D503821-1ABB-411A-9C4
	9-F6EC7A54E460@corp.arin.net><CD1B0373-BD30-499B-AA54-12029035AB48@virtuali
	zed.org><CB47563D-65ED-493D-B2BD-ECB87FD4EF07@arin.net><5D25514F-2881-47A8-
	BBE9-045577D8747D@virtualized.org><42E3550B-9BA4-48F7-A65F-239B2B9D4C27@del
	ong.com><5B9E90747FA2974D91A54FCFA1B8AD12014C03376E@ENI-MAIL.eclipse-networ
	ks.com><968C470DAC25FB419E0159952F28F0C06A7335D8@MEM0200CP3XF01.ds.irsnet.g
	ov><5B9E90747FA2974D91A54FCFA1B8AD12014C033D0A@ENI-MAIL.eclipse-networks.com>,
	<62D20B771F8F9C4EA8AEE574FF3869624DC57A28F0@mercury.jcc.com>
Message-ID: <5CD5589D-7F6A-4885-970E-69B414461106@eclipse-networks.com>

But real life is that short of congress acting, unless you have 100% of all the large block holders it will never happen. Therefore the prudent action is to accept reality.  Ripe 605 does just that.

Sent from my iPhone

On Feb 15, 2014, at 10:04 AM, "Keith W. Hare" <Keith at jcc.com<mailto:Keith at jcc.com>> wrote:






-----Original Message-----
From: arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Steven Ryerse
Sent: Thursday, February 13, 2014 6:49 PM
To: 'Morizot Timothy S'
Cc: John Curran; arin-ppml at arin.net<mailto:arin-ppml at arin.net>
Subject: Re: [arin-ppml] FYI -- RIPE-605 Services to LegacyInternetResourceHolders



I understand your concern and even share it to a point but we need to deal with real life, and real life is that it is pretty unlikely to get all of the original /8 and other large block legacy holders to sign contracts with ARIN (not to mention the small legacy block holders).





Looking at the Legacy Registration Agreement Statistics on https://www.arin.net/knowledge/statistics/legacy.html, a fair number of small legacy block holders HAVE signed the Legacy RSA.



Keith



______________________________________________________________

Keith W. Hare                     JCC Consulting, Inc.
keith at jcc.com<mailto:keith at jcc.com>                     600 Newark Granville Road
Phone: +1 740-587-0157            P.O. Box 381
Fax:   +1 740-587-0163            Granville, Ohio 43023
http://www.jcc.com<http://www.jcc.com/>                USA
______________________________________________________________



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

From hannigan at gmail.com  Sat Feb 15 10:13:02 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Sat, 15 Feb 2014 10:13:02 -0500
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
 Allocation Conservation Update
In-Reply-To: <CAP-guGX==kexCVuy_iXQAS3EGA7rgqvbXU+UixwCdn=FRoWpwg@mail.gmail.com>
References: <52E91DF0.9040909@arin.net> <52F2CB04.20905@quark.net>
	<52F3B9F3.5040706@umn.edu>
	<6C8DE21A-F09B-4F4A-A5A7-28F9FE7CCDB9@delong.com>
	<alpine.OSX.2.02.1402071003480.5486@brugal.local>
	<CADricwotP+t_n=fUrk=SQerBNsMqBUGP-V_GuVWd8=RpHUNGcA@mail.gmail.com>
	<CAP-guGX==kexCVuy_iXQAS3EGA7rgqvbXU+UixwCdn=FRoWpwg@mail.gmail.com>
Message-ID: <CAMDXq5MdLYoGMcu46KQr-LzyhYW=WOPuj6u3JJAQMGnh+yJF4Q@mail.gmail.com>

Following up from the PPC held at the NANOG in the Icepocalypse 2014
(Atlanta). There was support for this proposal, minus the administrative
language around fee class. As I had mentioned, removal of that language
makes sense. It was a cleanup of language that had already existed, there
may be an unintended consequence of removal. I'm sure the AC will figure
something out.

I did a spot check of 206.223.122-142 nets and found that I could validate
2 out of 20 to be in compliance with 4.4 policy. One was a test network
with a few personal machines on it, 206.223.132.0/24 (dis-aggregate of an
assigned /22) http://bgp.he.net/net/206.223.132.0/24#_dns and one that
appeared to be a defunct IXP block that was formerly associated with
PacBell, but now with another, PCH. I found one transferred to LACNIC (
206.223.124.0/24). I can't verify it's usage either.

The overall states were a) assigned to defunct entities, b) not used to
policy, c) participants < 2 > N Yrs, d) former use well known, later use
unknown.

That's not to say that these or more aren't actually valid. YMMV.

Best,

-M<




On Tue, Feb 11, 2014 at 1:22 PM, William Herrin <bill at herrin.us> wrote:

> On Tue, Feb 11, 2014 at 12:13 PM, Heather Schiller
> <heather.skanks at gmail.com> wrote:
> > I am opposed to the policy because of this line " IXP's formed as non
> > profits will be considered end user organizations. All others will be
> > considered ISPs."
> >
> >  This statement will impact the overwhelming majority of Critical
> > Infrastructure assignment holders, the majority of which are not IX's.
>  The
> > goal of attempting  preservation should be done by how the allocation is
> > justified, not how much the entity is billed.   111 of the CI allocations
> > are not to IX's.  Of the 66 IX allocations it is nearly split between end
> > users and ISP's.
>
> Hi Heather,
>
> Read it in context. The draft replaces only one of five paragraphs in
> section 4.4. The paragraph replaced and its replacement address only
> IXPs, not other providers of critical infrastructure.
>
> https://www.arin.net/policy/nrpm.html#four4
>
> Nevertheless, would your objection be solved if "All others" was
> replaced with "All other IXPs"?
>
> 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
> _______________________________________________
> 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/20140215/3b9d7c1c/attachment.htm>

From jcurran at arin.net  Sat Feb 15 12:33:11 2014
From: jcurran at arin.net (John Curran)
Date: Sat, 15 Feb 2014 17:33:11 +0000
Subject: [arin-ppml] FYI -- RIPE-605 Services
 toLegacyInternetResourceHolders
In-Reply-To: <5CD5589D-7F6A-4885-970E-69B414461106@eclipse-networks.com>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
	<"CAMDXq5Ma1Hq0Y OVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ"@mail.gmail.com>
	<"5B9E90747FA2974D91A54
	FCFA1B8AD12014C027054"@ENI-MAIL.eclipse-networks.com>
	<"CAC1-dtn5GDate1PZ6ke53 8B-utR5YvBS6cPet3fY=a7X7v=xoA"@mail.gmail.com>
	<"E12D1B9F-8457-4AED-952D-158B0 F9F9568"@virtualized.org>
	<D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com> <"C
	AFBC610-D7BE-4078-964A-C08C1C1853F0"@virtualized.org>
	<"2D503821-1ABB-411A-9C4 9-F6EC7A54E460"@corp.arin.net>
	<CD1B0373-BD30-499B-AA54-12029035AB48@virtuali> <zed.org@mac.com>
	<CB47563D-65ED-493D-B2BD-ECB87FD4EF07@arin.net> <"5D25514F-2881-47A8-
	BBE9-045577D8747D"@virtualized.org>
	<42E3550B-9BA4-48F7-A65F-239B2B9D4C27@del> <ong.com@mac.com>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C03376E@ENI-MAIL.eclipse-networ>
	<ks.com@mac.com>
	<968C470DAC25FB419E0159952F28F0C06A7335D8@MEM0200CP3XF01.ds.irsnet.g>
	<ov@mac.com>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C033D0A@ENI-MAIL.eclipse-networks.com>
	<62D20B771F8F9C4EA8AEE574FF3869624DC57A28F0@mercury.jcc.com>
	<5CD5589D-7F6A-4885-970E-69B414461106@eclipse-networks.com>
Message-ID: <3B229D25-300F-480E-AF3C-1C40F5D1ECC7@arin.net>

On Feb 15, 2014, at 10:10 AM, Steven Ryerse <SRyerse at eclipse-networks.com<mailto:SRyerse at eclipse-networks.com>> wrote:

But real life is that short of congress acting, unless you have 100% of all the large block holders it will never happen. Therefore the prudent action is to accept reality.  Ripe 605 does just that.

Steve -

    It is quite likely that normal market dynamics over time will result in many of
    the underutilized address blocks being transferred and ending up under an
    agreement (in ARIN or another region) - that's precisely what Keith was
    noting in his posting.

    Furthermore, 100% is not necessary and may not be desired by some parties,
    since many legacy address holders probably just want to have their registration
    services and be otherwise undisturbed.  Note that Ripe-605 doesn't actually
    change anything in that respect, in fact, it parallels ARIN's existing practices
    for those without formal agreement -

>From <http://www.ripe.net/ripe/docs/ripe-605> -

"2.6 No relationship
      In case no formal relationship has been established in support of a particular legacy resource, the RIPE NCC

? will continue to provide any registry service element already provided in support of each Legacy Internet Resource involved;
? will have no obligation to begin to provide any registry service element not already provided in support of a particular Legacy Internet Resource, even in case the service element is provided in support of any other Legacy Internet Resource held by the same or another Resource Holder;
? and may update the related entries in the RIPE Database from time to time to correspond to the current actual situation."

    It would be most helpful if you could fully explain the problem you are trying to
    solve, and then which section of RIPE 605 addresses it.   Simply indicating that
    it is prudent (because of lack of 100% LRSA adoption) does not explain why.

Thanks!
/John

John Curran
President and CEO
ARIN



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

From hannigan at gmail.com  Sat Feb 15 15:15:48 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Sat, 15 Feb 2014 15:15:48 -0500
Subject: [arin-ppml] Proposal 204 Submitted, Registry Accuracy Proposal
Message-ID: <CAMDXq5POOHsz=gpMZqLVVPTE86w0hJp51+an=qS3fLTY0BwKXw@mail.gmail.com>

Submitted here:

https://www.arin.net/policy/proposals/ARIN_prop_203_orig.html

I believe that we need to make a few more changes before the AC meeting to
insure that all of the i's are dotted and t's are crossed. I didn't realize
that ARIN no longer posts notice that a proposal has been submitted.

In rummaging through the new PDP as a result, I see a few things are
different. It looks like Part 2 is relevant for submissions and getting to
the "evaluation" stage which I would believe to be at the next scheduled AC
call?

Up until then, it also appears that  Part Two Section 1 "The assigned AC
members and ARIN staff will work with the originator as described below to
prepare the Policy Proposal for evaluation by the AC." is a catch all to
insure that there are no problems in reaching Part Two Section 2, unless of
course the author of a proposal doesn't respond to the shepherds.

There are some other slightly confusing process in the PDP around problem
statements, existing policy and the like which I imagine are determined to
exist or not exist through the process in Part Two Section1 is carried out.

John? Do I have the process correct?


Best,

-M<
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140215/9eb2af66/attachment.htm>

From jcurran at arin.net  Sat Feb 15 16:54:08 2014
From: jcurran at arin.net (John Curran)
Date: Sat, 15 Feb 2014 21:54:08 +0000
Subject: [arin-ppml] Proposal 204 Submitted, Registry Accuracy Proposal
In-Reply-To: <CAMDXq5POOHsz=gpMZqLVVPTE86w0hJp51+an=qS3fLTY0BwKXw@mail.gmail.com>
References: <CAMDXq5POOHsz=gpMZqLVVPTE86w0hJp51+an=qS3fLTY0BwKXw@mail.gmail.com>
Message-ID: <5D46946D-2D9C-4851-946D-BD8706E5E2CF@arin.net>

On Feb 15, 2014, at 3:15 PM, Martin Hannigan <hannigan at gmail.com<mailto:hannigan at gmail.com>> wrote:

Submitted here:

https://www.arin.net/policy/proposals/ARIN_prop_203_orig.html

I believe that we need to make a few more changes before the AC meeting to insure that all of the i's are dotted and t's are crossed. I didn't realize that ARIN no longer posts notice that a proposal has been submitted.

In rummaging through the new PDP as a result, I see a few things are different. It looks like Part 2 is relevant for submissions and getting to the "evaluation" stage which I would believe to be at the next scheduled AC call?

Up until then, it also appears that  Part Two Section 1 "The assigned AC members and ARIN staff will work with the originator as described below to prepare the Policy Proposal for evaluation by the AC." is a catch all to insure that there are no problems in reaching Part Two Section 2, unless of course the author of a proposal doesn't respond to the shepherds.

There are some other slightly confusing process in the PDP around problem statements, existing policy and the like which I imagine are determined to exist or not exist through the process in Part Two Section1 is carried out.

John? Do I have the process correct?

At a high-level, a policy proposal remains such until the AC confirms that it is
within scope of the Policy Development Process and contains a clear statement
of the problem and suggested changes to number resource policy text to address
the problem.

Policy proposals that are determined by the AC to lack clarity are remanded back
to the originator along with an explanation of the areas needing improvements in
clarity. The proposal originator revises the Policy Proposal based on the feedback
received, and again offers the revised Policy Proposal for evaluation by the AC.

Once the policy proposal is clear and in scope, then it gets posted to the PPML
as a Draft Policy (policy proposals that have not been accepted as a Draft Policy
after 60 days may also be petitioned to Draft Policy status)

Top priority at this point is a clear in-scope problem statement and suggested
changes to existing policy text.   I will note that the policy development process
is used for number resource policy and not ARIN business practices or services;
the latter should be submitted to the ARIN consultation and suggestion process
as they come under the fiduciary responsibilities of the ARIN Board of Trustees.

Thanks!
/John

John Curran
President and CEO
ARIN



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140215/5b2a6b2d/attachment.htm>

From hannigan at gmail.com  Sat Feb 15 18:24:08 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Sat, 15 Feb 2014 18:24:08 -0500
Subject: [arin-ppml] Proposal 204 Submitted, Registry Accuracy Proposal
In-Reply-To: <5D46946D-2D9C-4851-946D-BD8706E5E2CF@arin.net>
References: <CAMDXq5POOHsz=gpMZqLVVPTE86w0hJp51+an=qS3fLTY0BwKXw@mail.gmail.com>
	<5D46946D-2D9C-4851-946D-BD8706E5E2CF@arin.net>
Message-ID: <CAMDXq5NY-hCPpEyLZOZcanr1VzvgSBcXBMADKjkuCnONLqEutQ@mail.gmail.com>

On Sat, Feb 15, 2014 at 4:54 PM, John Curran <jcurran at arin.net> wrote:
> On Feb 15, 2014, at 3:15 PM, Martin Hannigan <hannigan at gmail.com> wrote:
>
> Submitted here:
>
> https://www.arin.net/policy/proposals/ARIN_prop_203_orig.html
>
> I believe that we need to make a few more changes before the AC meeting to
> insure that all of the i's are dotted and t's are crossed. I didn't realize
> that ARIN no longer posts notice that a proposal has been submitted.
>
> In rummaging through the new PDP as a result, I see a few things are
> different. It looks like Part 2 is relevant for submissions and getting to
> the "evaluation" stage which I would believe to be at the next scheduled AC
> call?
>
> Up until then, it also appears that  Part Two Section 1 "The assigned AC
> members and ARIN staff will work with the originator as described below to
> prepare the Policy Proposal for evaluation by the AC." is a catch all to
> insure that there are no problems in reaching Part Two Section 2, unless of
> course the author of a proposal doesn't respond to the shepherds.
>
> There are some other slightly confusing process in the PDP around problem
> statements, existing policy and the like which I imagine are determined to
> exist or not exist through the process in Part Two Section1 is carried out.
>
> John? Do I have the process correct?
>
>
> At a high-level, a policy proposal remains such until the AC confirms that
> it is
> within scope of the Policy Development Process and contains a clear
> statement
> of the problem and suggested changes to number resource policy text to
> address
> the problem.

Thanks.



> Policy proposals that are determined by the AC to lack clarity are remanded
> back
> to the originator along with an explanation of the areas needing
> improvements in
> clarity. The proposal originator revises the Policy Proposal based on the
> feedback
> received, and again offers the revised Policy Proposal for evaluation by the
> AC.


So my intepretation of Part 2 Section 1 is correct then?



>
> Once the policy proposal is clear and in scope, then it gets posted to the
> PPML
> as a Draft Policy (policy proposals that have not been accepted as a Draft
> Policy
> after 60 days may also be petitioned to Draft Policy status)
>
> Top priority at this point is a clear in-scope problem statement and
> suggested
> changes to existing policy text.

Thanks. I'll double check that.

>I will note that the policy development
> process
> is used for number resource policy and not ARIN business practices or
> services;
> the latter should be submitted to the ARIN consultation and suggestion
> process
> as they come under the fiduciary responsibilities of the ARIN Board of
> Trustees.


I think it belongs in policy. I left the section numbers alone since I
would leave where in the NRPM it might go  (as it has been
historically) up to "you".

I agree, should try and separate business practice from desired policy
implications. I'm not totally clear if that's the case here, but I
would imagine the AC could accomplish that if they wanted to.

Best,

-M<


From jcurran at arin.net  Sun Feb 16 11:26:47 2014
From: jcurran at arin.net (John Curran)
Date: Sun, 16 Feb 2014 16:26:47 +0000
Subject: [arin-ppml] Proposal 204 Submitted, Registry Accuracy Proposal
In-Reply-To: <CAMDXq5NY-hCPpEyLZOZcanr1VzvgSBcXBMADKjkuCnONLqEutQ@mail.gmail.com>
References: <CAMDXq5POOHsz=gpMZqLVVPTE86w0hJp51+an=qS3fLTY0BwKXw@mail.gmail.com>
	<5D46946D-2D9C-4851-946D-BD8706E5E2CF@arin.net>
	<CAMDXq5NY-hCPpEyLZOZcanr1VzvgSBcXBMADKjkuCnONLqEutQ@mail.gmail.com>
Message-ID: <ED7C61F2-A0C1-495A-8A93-6DF19BBB4724@arin.net>

On Feb 15, 2014, at 6:24 PM, Martin Hannigan <hannigan at gmail.com> wrote:

> On Sat, Feb 15, 2014 at 4:54 PM, John Curran <jcurran at arin.net> wrote:
>> Policy proposals that are determined by the AC to lack clarity are remanded
>> back
>> to the originator along with an explanation of the areas needing
>> improvements in
>> clarity. The proposal originator revises the Policy Proposal based on the
>> feedback
>> received, and again offers the revised Policy Proposal for evaluation by the
>> AC.
> 
> So my intepretation of Part 2 Section 1 is correct then?

Yes - In a world of cooperative authors, I would expect that every meaningful 
policy proposal would become a well-composed draft policy that goes to the
community for further consideration. 

>> Once the policy proposal is clear and in scope, then it gets posted to the
>> PPML
>> as a Draft Policy (policy proposals that have not been accepted as a Draft
>> Policy
>> after 60 days may also be petitioned to Draft Policy status)
>> 
>> Top priority at this point is a clear in-scope problem statement and
>> suggested
>> changes to existing policy text.
> 
> Thanks. I'll double check that.

You (and the AC shepherds assigned) can take any approach desired; I have
spent some time looking over the proposal and have a suggestions on one 
possible below that you may want to consider (or discard) as you prefer.

>> I will note that the policy development
>> process
>> is used for number resource policy and not ARIN business practices or
>> services;
>> the latter should be submitted to the ARIN consultation and suggestion
>> process
>> as they come under the fiduciary responsibilities of the ARIN Board of
>> Trustees.
> 
> I think it belongs in policy. I left the section numbers alone since I
> would leave where in the NRPM it might go  (as it has been
> historically) up to "you".
> 
> I agree, should try and separate business practice from desired policy
> implications. I'm not totally clear if that's the case here, but I
> would imagine the AC could accomplish that if they wanted to.

There's quite a bit of material in the proposal, but I think that two major points 
(which could be considered issues with policy rather than services or contractual 
matters) are the applicability of policy to legacy number resources and the default 
relationship of the registry to legacy resource holders; a problem statement that 
current policy is unclear with respect to applicability to legacy resources would 
be accurate and provide a basis for adding policy text accordingly.  

For reference, ARIN presently applies number resource policy to legacy resource 
holders and provides receive basic registration services (including the ability 
to update their contact information, DNS servers etc.) without charge.  Proposal 
text which clarifies and/or revises these positions could make for excellent 
discussion among the community and ultimately make for more understandable policy 
text in the NRPM regarding legacy number resources.  (This is not to say that the
other aspects of the policy proposal are not important, only that they may make 
good follow-on policy or ARIN suggestions once the more basic legacy resource 
matters are settled in the NRPM.)

In the end, it's up to you (aided by the assigned AC shepherds) to come up with 
Draft Policy text; I am also available to assist at any point if so desired.

Thanks again for raising this important topic!
/John

John Curran
President and CEO
ARIN




From drc at virtualized.org  Mon Feb 17 01:39:08 2014
From: drc at virtualized.org (David Conrad)
Date: Sun, 16 Feb 2014 22:39:08 -0800
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy InternetResource
	Holders
In-Reply-To: <2AE523C2-B9DF-4401-8B7E-C135AE394931@arin.net>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
	<CAMDXq5Ma1Hq0YOVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com>
	<CAC1-dtn5GDate1PZ6ke538B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com>
	<E12D1B9F-8457-4AED-952D-158B0F9F9568@virtualized.org>
	<D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com>
	<CAFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org>
	<2D503821-1ABB-411A-9C49-F6EC7A54E460@corp.arin.net>
	<CD1B0373-BD30-499B-AA54-12029035AB48@virtualized.org>
	<CB47563D-65ED-493D-B2BD-ECB87FD4EF07@arin.net>
	<5D25514F-2881-47A8-BBE9-045577D8747D@virtualized.org>
	<687DFF93-4C22-4A48-BA74-9736DA95B609@arin.net>
	<6DDFCA18-A609-471E-AFF8-23FD1BCDFC35@virtualized.org>
	<2AE523C2-B9DF-4401-8B7E-C135AE394931@arin.net>
Message-ID: <54F4D62A-407E-4B4C-B69F-D115C66DB0EE@virtualized.org>

[Sorry for the delayed response -- travel headaches and recovery]

John,

On Feb 13, 2014, at 8:58 AM, John Curran <jcurran at arin.net> wrote:
>> Oddly, 2050 is silent on that.
> Would you expect that a transfer in 1997 would have been put in the 
> registry despite the lack of approval?  

Yes.  You might want to re-read the section my message that you conveniently edited out.

> You may not like the need-based transfer policy, and it may not deter 'off 
> book' usage of address blocks, but the party listed as the address holder 
> still has control of the address block in the registry and hence is accurate.

"You keep using that word. I do not think it means what you think it means." -- Inigo Montoya

The whole point of contention here is in fact that the party listed does _not_ have control of the address space -- it was transferred. The intent of the registration database is to help troubleshoot network problems including abuse. By not recording a transfer, ARIN is intentionally making it hard if not impossible to track down the actual operator of the address space, thereby failing the basic test of providing a registration database.

> I have been attempting to follow up on your suggestion to poll the 
> community, but we seem to have reached an impasse because ARIN is
> keeping the registry accurate and your formulation would suggest 
> otherwise.

By refusing to accurately record transfers of address space, ARIN is _NOT_ keeping the registry accurate. ARIN is using the registration database as a weapon to try to enforce policy. This is not the role of a registry. 

A far more appropriate course of action would be for ARIN to record the transfer but mark it "outside of policy" or somesuch so members of the community could choose what they wished to do when they encounter such records. Sticking your fingers in your ears and singing "la la la the database is accurate because we won't recognize transfers la la la" is not helping anything.

Regards,
-drc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140216/950b1d48/attachment.sig>

From jcurran at arin.net  Mon Feb 17 06:48:38 2014
From: jcurran at arin.net (John Curran)
Date: Mon, 17 Feb 2014 11:48:38 +0000
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy InternetResource
 Holders
In-Reply-To: <54F4D62A-407E-4B4C-B69F-D115C66DB0EE@virtualized.org>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
	<CAMDXq5Ma1Hq0YOVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com>
	<CAC1-dtn5GDate1PZ6ke538B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com>
	<E12D1B9F-8457-4AED-952D-158B0F9F9568@virtualized.org>
	<D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com>
	<CAFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org>
	<2D503821-1ABB-411A-9C49-F6EC7A54E460@corp.arin.net>
	<CD1B0373-BD30-499B-AA54-12029035AB48@virtualized.org>
	<CB47563D-65ED-493D-B2BD-ECB87FD4EF07@arin.net>
	<5D25514F-2881-47A8-BBE9-045577D8747D@virtualized.org>
	<687DFF93-4C22-4A48-BA74-9736DA95B609@arin.net>
	<6DDFCA18-A609-471E-AFF8-23FD1BCDFC35@virtualized.org>
	<2AE523C2-B9DF-4401-8B7E-C135AE394931@arin.net>
	<54F4D62A-407E-4B4C-B69F-D115C66DB0EE@virtualized.org>
Message-ID: <D59CF2AC-5E33-43B4-BB5B-F02ED5C8B89E@arin.net>

On Feb 17, 2014, at 1:39 AM, David Conrad <drc at virtualized.org> wrote:

> The whole point of contention here is in fact that the party listed does _not_ have control of the address space -- it was transferred. The intent of the registration database is to help troubleshoot network problems including abuse. By not recording a transfer, ARIN is intentionally making it hard if not impossible to track down the actual operator of the address space, thereby failing the basic test of providing a registration database.

David - 
 
  The operational impact is actually the consequence of the service
  provider who makes use of address space which is assigned to another;
  it's not materially different than attempts at IP block hijacking 
  that we see from time to time.   

  If the registry is to be operated without any policy on transfers,
  that is indeed possible, but again that should be decided by the 
  community. Note - this is not unique to ARIN; LACNIC applies policies 
  to IPv4 transfers, APNIC applies policies to transfers (e.g. requiring 
  the recipient to be an APNIC member)... Are you suggesting that the
  very existence of registry policies are contrary to being an RIR, in 
  that they may result in an operator using space not registered and 
  thus hinder operations?

  If this had only been made clear by the authors of RFC 2050, we could 
  have saved more than a decade of policy working group meetings in every 
  region... Can you explain why you now believe that RIRs are not entitled 
  to operate their registries in accordance with community-developed policy?  
  Why doesn't the APNIC community have the right to require a recipient
  to be an APNIC member, or the LACNIC community the right to set a /24
  minimum block size on recipients?  In any of these cases, a rejection
  of a transfer request results in the same scenario you describe above;
  suggesting that all of the RIRs are failing your new "basic test" of 
  providing a registration database.

/John

John Curran
President and CEO
ARIN

  

From jcurran at arin.net  Mon Feb 17 08:38:36 2014
From: jcurran at arin.net (John Curran)
Date: Mon, 17 Feb 2014 13:38:36 +0000
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy InternetResource
 Holders
In-Reply-To: <D59CF2AC-5E33-43B4-BB5B-F02ED5C8B89E@arin.net>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
	<CAMDXq5Ma1Hq0YOVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com>
	<CAC1-dtn5GDate1PZ6ke538B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com>
	<E12D1B9F-8457-4AED-952D-158B0F9F9568@virtualized.org>
	<D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com>
	<CAFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org>
	<2D503821-1ABB-411A-9C49-F6EC7A54E460@corp.arin.net>
	<CD1B0373-BD30-499B-AA54-12029035AB48@virtualized.org>
	<CB47563D-65ED-493D-B2BD-ECB87FD4EF07@arin.net>
	<5D25514F-2881-47A8-BBE9-045577D8747D@virtualized.org>
	<687DFF93-4C22-4A48-BA74-9736DA95B609@arin.net>
	<6DDFCA18-A609-471E-AFF8-23FD1BCDFC35@virtualized.org>
	<2AE523C2-B9DF-4401-8B7E-C135AE394931@arin.net>
	<54F4D62A-407E-4B4C-B69F-D115C66DB0EE@virtualized.org>
	<D59CF2AC-5E33-43B4-BB5B-F02ED5C8B89E@arin.net>
Message-ID: <B1DC8083-C8AD-4A0E-B852-9E75F2B5ED5A@arin.net>

On Feb 17, 2014, at 6:48 AM, John Curran <jcurran at arin.net> wrote:

> If the registry is to be operated without any policy on transfers,
> that is indeed possible, but again that should be decided by the 
> community. Note - this is not unique to ARIN; LACNIC applies policies 
> to IPv4 transfers, APNIC applies policies to transfers (e.g. requiring 
> the recipient to be an APNIC member)... Are you suggesting that the
> very existence of registry policies are contrary to being an RIR, in 
> that they may result in an operator using space not registered and 
> thus hinder operations?
> 
> If this had only been made clear by the authors of RFC 2050, we could 
> have saved more than a decade of policy working group meetings in every 
> region... Can you explain why you now believe that RIRs are not entitled 
> to operate their registries in accordance with community-developed policy?  
> Why doesn't the APNIC community have the right to require a recipient
> to be an APNIC member, or the LACNIC community the right to set a /24
> minimum block size on recipients?  In any of these cases, a rejection
> of a transfer request results in the same scenario you describe above;
> suggesting that all of the RIRs are failing your new "basic test" of 
> providing a registration database.

David - 

It occurred to me that the above post might be seen as too critical of 
your position, and I apologize as that was not my intent... My goal was
simply to get a clearer statement of your position.

Are you saying that the RIRs should not be establishing any policy 
on legacy address holders?  (Note, both the LACNIC and APNIC cases
above specifically apply to legacy address holders)

Are you saying that the RIRs can establish policy on legacy address
holders, but it should be solely voluntary for compliance, and in the
end RIRs should register transfers regardless of circumstances (e.g.
to a non-existing entity, or of a single /32, etc.)

Or is it that RIRs should only be making allocation policy, and not 
be placing any policy constraints (or only the minimal necessary 
constraints) in the case of transfers?

Thanks!
/John

John Curran
President and CEO
ARIN






From drc at virtualized.org  Mon Feb 17 11:17:08 2014
From: drc at virtualized.org (David Conrad)
Date: Mon, 17 Feb 2014 08:17:08 -0800
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy InternetResource
	Holders
In-Reply-To: <D59CF2AC-5E33-43B4-BB5B-F02ED5C8B89E@arin.net>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
	<CAMDXq5Ma1Hq0YOVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com>
	<CAC1-dtn5GDate1PZ6ke538B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com>
	<E12D1B9F-8457-4AED-952D-158B0F9F9568@virtualized.org>
	<D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com>
	<CAFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org>
	<2D503821-1ABB-411A-9C49-F6EC7A54E460@corp.arin.net>
	<CD1B0373-BD30-499B-AA54-12029035AB48@virtualized.org>
	<CB47563D-65ED-493D-B2BD-ECB87FD4EF07@arin.net>
	<5D25514F-2881-47A8-BBE9-045577D8747D@virtualized.org>
	<687DFF93-4C22-4A48-BA74-9736DA95B609@arin.net>
	<6DDFCA18-A609-471E-AFF8-23FD1BCDFC35@virtualized.org>
	<2AE523C2-B9DF-4401-8B7E-C135AE394931@arin.net>
	<54F4D62A-407E-4B4C-B69F-D115C66DB0EE@virtualized.org>
	<D59CF2AC-5E33-43B4-BB5B-F02ED5C8B89E@arin.net>
Message-ID: <00C02670-9513-464A-8834-2C584F34F84E@virtualized.org>

John,

On Feb 17, 2014, at 3:48 AM, John Curran <jcurran at arin.net> wrote:
>  The operational impact is actually the consequence of the service
>  provider who makes use of address space which is assigned to another;
>  it's not materially different than attempts at IP block hijacking 
>  that we see from time to time.   

It is worrisome that you do not see a "material differen[ce]" between theft actionable by real live law enforcement and a mutually agreeable exchange of resources allocated at a time when no explicit policy constraints declared such exchange forbidden.

>  If the registry is to be operated without any policy on transfers,
>  that is indeed possible, but again that should be decided by the 
>  community.

Red herring. I've said before this isn't about registry policy. This is about not damaging the registration database.

>  If this had only been made clear by the authors of RFC 2050, we could 
>  have saved more than a decade of policy working group meetings in every 
>  region...

See, this is why I object to treating 2050 as sacred text.

It was a "best current practice" in 1996. It addressed specific concerns the registries had and documented registry operation at that time. It was not ever intended to answer all questions about how Internet address registries should be operated for all time. It was a snapshot intended to explain to people who interacted with the registries what we were doing, how, and why. In 1996.

Now will you stop referring to it?

> Can you explain why you now believe that RIRs are not entitled 
>  to operate their registries in accordance with community-developed policy?  

Strawman: ignored.

> Are you saying that the RIRs should not be establishing any policy 
> on legacy address holders?

No. I'm saying any registry policy must not damage the accuracy of the registration database.  The registration database is NOT a weapon to be used by ARIN (or other RIRs) at their discretion. It is a global cooperative construct used by network operators and others for operational purposes beyond the limited scope of ARIN's (or other RIR's) particular needs.

> Are you saying that the RIRs can establish policy on legacy address
> holders, but it should be solely voluntary for compliance,

Hint: RIR policy IS voluntary.

> and in the
> end RIRs should register transfers regardless of circumstances (e.g.
> to a non-existing entity, or of a single /32, etc.)

John, try to remember back to when you operated actual networks. When someone was abusing your network, you could look up that address in the Whois database of "the NIC", call them up and ask them to stop. As a network operator, your needs of the registration database were to identify the actual user of the network at that time for operational purposes.  Not who was originally allocated the network originally. Not what some folks in Chantilly VA thought was appropriate to be in the registration database about that network. The actual user of the network at the time your network was being abused.

In this light, registering a transfer
- to a non-existent entity DOES NOT improve/maintain accuracy, hence no.
- of a single /32 DOES improve/maintain accuracy, hence yes.

Pretending that the registration database is accurate because it only contains information that is acceptable by arbitrary policy at a particular point in time means that the network operator you would NOT be able to rely on the registration database for the purpose it was intended. 

What then, from a network operator's perspective, is the point of the registration database?

> Or is it that RIRs should only be making allocation policy, and not 
> be placing any policy constraints (or only the minimal necessary 
> constraints) in the case of transfers?

Once more with feeling: this isn't about policy (transfer or otherwise).  It is about registration database accuracy. 

Regards,
-drc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140217/8b6f2876/attachment.sig>

From jcurran at arin.net  Mon Feb 17 11:55:50 2014
From: jcurran at arin.net (John Curran)
Date: Mon, 17 Feb 2014 16:55:50 +0000
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy InternetResource
 Holders
In-Reply-To: <00C02670-9513-464A-8834-2C584F34F84E@virtualized.org>
References: <AF9AD683-2D9C-4EBC-8080-A24C0AF658CF@delong.com>
	<CAMDXq5Ma1Hq0YOVJ=JSAE1nU5cURvBWH0hQBZQPYdhkZEEowMQ@mail.gmail.com>
	<5B9E90747FA2974D91A54FCFA1B8AD12014C027054@ENI-MAIL.eclipse-networks.com>
	<CAC1-dtn5GDate1PZ6ke538B-utR5YvBS6cPet3fY=a7X7v=xoA@mail.gmail.com>
	<E12D1B9F-8457-4AED-952D-158B0F9F9568@virtualized.org>
	<D41365AA-106D-4D68-B3EB-AA1647B54910@delong.com>
	<CAFBC610-D7BE-4078-964A-C08C1C1853F0@virtualized.org>
	<2D503821-1ABB-411A-9C49-F6EC7A54E460@corp.arin.net>
	<CD1B0373-BD30-499B-AA54-12029035AB48@virtualized.org>
	<CB47563D-65ED-493D-B2BD-ECB87FD4EF07@arin.net>
	<5D25514F-2881-47A8-BBE9-045577D8747D@virtualized.org>
	<687DFF93-4C22-4A48-BA74-9736DA95B609@arin.net>
	<6DDFCA18-A609-471E-AFF8-23FD1BCDFC35@virtualized.org>
	<2AE523C2-B9DF-4401-8B7E-C135AE394931@arin.net>
	<54F4D62A-407E-4B4C-B69F-D115C66DB0EE@virtualized.org>
	<D59CF2AC-5E33-43B4-BB5B-F02ED5C8B89E@arin.net>
	<00C02670-9513-464A-8834-2C584F34F84E@virtualized.org>
Message-ID: <ADB1E72B-631C-4A80-82F7-72FABFCB00DB@arin.net>

On Feb 17, 2014, at 11:17 AM, David Conrad <drc at virtualized.org> wrote:
> 
>> Are you saying that the RIRs should not be establishing any policy 
>> on legacy address holders?
> 
> No. I'm saying any registry policy must not damage the accuracy of the registration database.  The registration database is NOT a weapon to be used by ARIN (or other RIRs) at their discretion. It is a global cooperative construct used by network operators and others for operational purposes beyond the limited scope of ARIN's (or other RIR's) particular needs.
> ...
> In this light, registering a transfer
> - to a non-existent entity DOES NOT improve/maintain accuracy, hence no.
> - of a single /32 DOES improve/maintain accuracy, hence yes.

David - 

  The above is helpful in understanding your position.  I would presume
  that there is no other constraints that you believe are valid for the
  recipient of a transfer?  (e.g. valid contact information, actual legal
  existence as opposed to someone's pet cat, some form of membership or
  service agreement with the registry?) 

>> Or is it that RIRs should only be making allocation policy, and not 
>> be placing any policy constraints (or only the minimal necessary 
>> constraints) in the case of transfers?
> 
> Once more with feeling: this isn't about policy (transfer or otherwise).  It is about registration database accuracy. 

  The conundrum being that it is today possible (as has been throughout RIR 
  system history) to have policy that inhibits "accuracy" (as you use make 
  use of the term); examples include the requirement for the recipient to be   
  a member of a registry (APNIC), minimum transfer sizes (LACNIC, ARIN), etc.

  Your particular perspective of how this "should" work might make a good 
  framework for a globally coordinated registry update policy; effectively 
  stating that address holders may make updates to their number resource 
  registrations, including subdivision thereof to multiple parties, to any 
  new assignee/recipient without restriction.  I do not know how such a 
  policy would fare in each of the regions, but it would at least reflect
  how you believe that the registry system should work in the present age.

Thanks!
/John

John Curran
President and CEO
ARIN




From mlindsey at lb3law.com  Mon Feb 17 14:53:54 2014
From: mlindsey at lb3law.com (Lindsey, Marc)
Date: Mon, 17 Feb 2014 19:53:54 +0000
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy Internet Resource
	Holders
Message-ID: <cb24b94beb454acea335aaa5d73118d4@BN1PR07MB022.namprd07.prod.outlook.com>

I advise several large legacy block holders.  Some of them signed the LRSA, but many have not.  For them, the burdens imposed by the LRSA outweigh the benefits.   Some on the PPML have suggested that off-contract legacy holders don't sign up with ARIN because they want to be free-riders.  But the fees (and the avoidance of the fees) are not a factor in their LRSA decision.

Based on my experience working with legacy block holders, I believe adopting a policy substantially similar to RIPE 605 (ARIN prop 203) would go a long way in harmonizing the interests of the ARIN community with the community of legacy holders that do not have formal relationships with ARIN.

ARIN's absolute control over additional allocations of "free" IPv4 numbers in its region has served as the primary policy enforcement mechanism.  This carrot really only works on recipients that need more IPv4 numbers, and then only as long as ARIN has free numbers to give out.  It doesn't directly influence the behavior of many legacy block holders when they convey their spare numbers.   Legacy holders are a major source of future IPv4 number distributions, and their relevance to the broader ARIN community will become more prominent as ARIN's IPv4 free pool reaches depletion.

In the secondary market context, ARIN now relies on its ability to withhold registry database updates as the primary means to extend enforcement of its current policies into private transactions between parties conveying beneficial use of IPv4 numbers.  This, however, is a weak enforcement tool. Two parties can convey beneficial use of IPv4 numbers in lawful commercial transactions without updating ARIN's registry database.  But IPv4 number conveyances not recorded in the registry system produces very undesirable results - the "reality" in the registry database will not reflect operational reality, as David Conrad and others have pointed out in several posts.

Buyers and sellers would prefer to document their conveyances in a reliable and accurate public registry, but not if the contingencies and conditions materially and adversely affect their commercial arrangement.  RIPE 605/ ARIN prop 203 recognizes this reality.  With a little tweaking, adopting it would go a long way in minimizing the disincentives now facing legacy holders (and entities that want to acquire their numbers) when contemplating whether updating the registry database is worth the risk of subjecting their transactions to ARIN's approval process.

Marc Lindsey
Levine, Blaszak, Block & Boothby, LLP
2001 L Street, NW Suite 900
Washington, DC 20036
Office: (202) 857-2564
Mobile: (202) 491-3230
Email: mlindsey at lb3law.com<mailto:mlindsey at lb3law.com>
Website: www.lb3law.com<http://www.lb3law.com>

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

From jcurran at arin.net  Mon Feb 17 15:46:45 2014
From: jcurran at arin.net (John Curran)
Date: Mon, 17 Feb 2014 20:46:45 +0000
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy Internet
 Resource Holders
In-Reply-To: <cb24b94beb454acea335aaa5d73118d4@BN1PR07MB022.namprd07.prod.outlook.com>
References: <cb24b94beb454acea335aaa5d73118d4@BN1PR07MB022.namprd07.prod.outlook.com>
Message-ID: <15DCF692-6994-4A6E-AD44-C60E11D77D75@corp.arin.net>

On Feb 17, 2014, at 2:53 PM, Lindsey, Marc <mlindsey at lb3law.com<mailto:mlindsey at lb3law.com>> wrote:

I advise several large legacy block holders.  Some of them signed the LRSA, but many have not.  For them, the burdens imposed by the LRSA outweigh the benefits.   Some on the PPML have suggested that off-contract legacy holders don?t sign up with ARIN because they want to be free-riders.  But the fees (and the avoidance of the fees) are not a factor in their LRSA decision.

Based on my experience working with legacy block holders, I believe adopting a policy substantially similar to RIPE 605 (ARIN prop 203) would go a long way in harmonizing the interests of the ARIN community with the community of legacy holders that do not have formal relationships with ARIN.

Marc -

  As noted earlier, RIPE 605 covers quite a bit of ground; could you be
  more specific about what specific policy changes you are seeking?

Thanks!
/John

John Curran
President and CEO
ARIN


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140217/676d6527/attachment.htm>

From snoble at sonn.com  Mon Feb 17 16:08:04 2014
From: snoble at sonn.com (Steve Noble)
Date: Mon, 17 Feb 2014 13:08:04 -0800
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy Internet
 Resource Holders
In-Reply-To: <cb24b94beb454acea335aaa5d73118d4@BN1PR07MB022.namprd07.prod.outlook.com>
References: <cb24b94beb454acea335aaa5d73118d4@BN1PR07MB022.namprd07.prod.outlook.com>
Message-ID: <53027A34.5000303@sonn.com>

As a holder of both legacy and non-legacy ARIN objects, I have been 
subject to ARIN's registry update blocks on _non-legacy_ objects that I 
rightfully control and use.  I spent years (6 I believe) fighting with 
ARIN to update the information on one of my ASNs while ARIN continued to 
bill me for a 'service' which they did not provide.  ARIN's 
unwillingness to update the database to have correct contact information 
is not only an undesirable effect of their policies, but also an 
indication of ARIN's lack of concern about having correct information in 
the database.

  As a consumer, I see no value to the service that ARIN provides. I pay 
ARIN's fees only to keep ARIN from giving the AS that I use to someone 
else and causing an administrative issue to become an operational issue.

> Lindsey, Marc <mailto:mlindsey at lb3law.com>
> February 17, 2014 at 11:53 AM
>
> I advise several large legacy block holders.  Some of them signed the 
> LRSA, but many have not.  For them, the burdens imposed by the LRSA 
> outweigh the benefits.   Some on the PPML have suggested that 
> off-contract legacy holders don't sign up with ARIN because they want 
> to be free-riders.  But the fees (and the avoidance of the fees) are 
> not a factor in their LRSA decision.
>
> Based on my experience working with legacy block holders, I believe 
> adopting a policy substantially similar to RIPE 605 (ARIN prop 203) 
> would go a long way in harmonizing the interests of the ARIN community 
> with the community of legacy holders that do not have formal 
> relationships with ARIN.
>
> ARIN's absolute control over additional allocations of "free" IPv4 
> numbers in its region has served as the primary policy enforcement 
> mechanism.  This carrot really only works on recipients that need more 
> IPv4 numbers, and then only as long as ARIN has free numbers to give 
> out.  It doesn't directly influence the behavior of many legacy block 
> holders when they convey their spare numbers.   Legacy holders are a 
> major source of future IPv4 number distributions, and their relevance 
> to the broader ARIN community will become more prominent as ARIN's 
> IPv4 free pool reaches depletion.
>
> In the secondary market context, ARIN now relies on its ability to 
> withhold registry database updates as the primary means to extend 
> enforcement of its current policies into private transactions between 
> parties conveying beneficial use of IPv4 numbers.  This, however, is a 
> weak enforcement tool. Two parties can convey beneficial use of IPv4 
> numbers in lawful commercial transactions without updating ARIN's 
> registry database.  But IPv4 number conveyances not recorded in the 
> registry system produces very undesirable results -- the "reality" in 
> the registry database will not reflect operational reality, as David 
> Conrad and others have pointed out in several posts.
>
> Buyers and sellers would prefer to document their conveyances in a 
> reliable and accurate public registry, but not if the contingencies 
> and conditions materially and adversely affect their commercial 
> arrangement.  RIPE 605/ ARIN prop 203 recognizes this reality.  With a 
> little tweaking, adopting it would go a long way in minimizing the 
> disincentives now facing legacy holders (and entities that want to 
> acquire their numbers) when contemplating whether updating the 
> registry database is worth the risk of subjecting their transactions 
> to ARIN's approval process.
>
> *Marc Lindsey*
> Levine, Blaszak, Block & Boothby, LLP
> 2001 L Street, NW Suite 900
> Washington, DC 20036
> /Office:/ (202) 857-2564
> /Mobile:/ (202) 491-3230
> /Email:/ mlindsey at lb3law.com <mailto:mlindsey at lb3law.com>
> Website: www.lb3law.com <http://www.lb3law.com>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140217/f55eec4f/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140217/f55eec4f/attachment.jpg>

From jcurran at arin.net  Mon Feb 17 17:02:36 2014
From: jcurran at arin.net (John Curran)
Date: Mon, 17 Feb 2014 22:02:36 +0000
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy Internet
 Resource Holders
In-Reply-To: <53027A34.5000303@sonn.com>
References: <cb24b94beb454acea335aaa5d73118d4@BN1PR07MB022.namprd07.prod.outlook.com>
	<53027A34.5000303@sonn.com>
Message-ID: <15A4C5D7-1EAE-4FB5-BF18-5D1BE44F4103@arin.net>

On Feb 17, 2014, at 4:08 PM, Steve Noble <snoble at sonn.com<mailto:snoble at sonn.com>> wrote:

As a holder of both legacy and non-legacy ARIN objects, I have been subject to ARIN's registry update blocks on _non-legacy_ objects that I rightfully control and use.

Steve -

  I'll be the first to admit you suffered needlessly, and appreciate your diligence in
  pursuing the correction with ARIN (as it led to us finding an end case for ASN-
  only resource records.)    For those who might not remember the issue,  read
   <http://lists.arin.net/pipermail/arin-ppml/2012-September/026100.html>
  At this time, you should not longer have any problem updating your ASN records,
  and I will apologize again that we did not recognize the issue as a fallout from our
  migration any sooner than we did.

Thanks,
/John

John Curran
President and CEO
ARIN


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140217/5096bc3a/attachment.htm>

From scottleibrand at gmail.com  Mon Feb 17 16:36:14 2014
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Mon, 17 Feb 2014 13:36:14 -0800
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy Internet
	Resource Holders
In-Reply-To: <cb24b94beb454acea335aaa5d73118d4@BN1PR07MB022.namprd07.prod.outlook.com>
References: <cb24b94beb454acea335aaa5d73118d4@BN1PR07MB022.namprd07.prod.outlook.com>
Message-ID: <F5A17F76-8EC8-42AC-BD88-22EB1E06C3F7@gmail.com>

Marc,

Good input, thanks. Can you expand a bit on which aspects of the LRSA some of your clients find burdensome, and which aspects of RIPE 605 they find preferable? As we (and particularly the AC shepherds) work with the proposal originator on getting a clear problem statement and then figuring out which parts of prop-203 are in scope for the PDP (and which parts should be submitted through the ACSP), it would be good to have your perspective on what aspects of the RIPE policy would be most helpful for making sure that transfers from non-RSA address holders get properly recorded. 

Thanks,
Scott

> On Feb 17, 2014, at 11:53 AM, "Lindsey, Marc" <mlindsey at lb3law.com> wrote:
> 
> I advise several large legacy block holders.  Some of them signed the LRSA, but many have not.  For them, the burdens imposed by the LRSA outweigh the benefits.   Some on the PPML have suggested that off-contract legacy holders don?t sign up with ARIN because they want to be free-riders.  But the fees (and the avoidance of the fees) are not a factor in their LRSA decision. 
>  
> Based on my experience working with legacy block holders, I believe adopting a policy substantially similar to RIPE 605 (ARIN prop 203) would go a long way in harmonizing the interests of the ARIN community with the community of legacy  holders that do not have formal relationships with ARIN.
>          
> ARIN?s absolute control over additional allocations of ?free? IPv4 numbers in its region has served as the primary policy enforcement mechanism.  This carrot really only works on recipients that need more IPv4 numbers, and then only as long as ARIN has free numbers to give out.  It doesn?t directly influence the behavior of many legacy block holders when they convey their spare numbers.   Legacy holders are a major source of future IPv4 number distributions, and their relevance to the broader ARIN community will become more prominent as ARIN?s IPv4 free pool reaches depletion.  
>  
> In the secondary market context, ARIN now relies on its ability to withhold registry database updates as the primary means to extend enforcement of its current policies into private transactions between parties conveying beneficial use  of IPv4 numbers.  This, however, is a weak enforcement tool. Two parties can convey beneficial use of IPv4 numbers in lawful commercial transactions without updating ARIN?s registry database.  But IPv4 number conveyances not recorded in the registry system produces very undesirable results ? the ?reality? in the registry database will not reflect operational reality, as David Conrad and others have pointed out in several posts.     
>  
> Buyers and sellers would prefer to document their conveyances in a reliable and accurate public registry, but not if the contingencies and conditions materially and adversely affect their commercial arrangement.  RIPE 605/ ARIN prop 203 recognizes this reality.  With a little tweaking, adopting it would go a long way in minimizing the disincentives now facing legacy holders (and entities that want to acquire their numbers) when contemplating whether updating the registry database is worth the risk of subjecting their transactions to ARIN?s approval process. 
>  
> Marc Lindsey
> Levine, Blaszak, Block & Boothby, LLP
> 2001 L Street, NW Suite 900
> Washington, DC 20036
> Office: (202) 857-2564
> Mobile: (202) 491-3230
> Email: mlindsey at lb3law.com
> Website: www.lb3law.com
>  
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140217/073549b8/attachment.htm>

From hannigan at gmail.com  Mon Feb 17 19:44:30 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Mon, 17 Feb 2014 19:44:30 -0500
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy Internet
	Resource Holders
In-Reply-To: <F5A17F76-8EC8-42AC-BD88-22EB1E06C3F7@gmail.com>
References: <cb24b94beb454acea335aaa5d73118d4@BN1PR07MB022.namprd07.prod.outlook.com>
	<F5A17F76-8EC8-42AC-BD88-22EB1E06C3F7@gmail.com>
Message-ID: <CAMDXq5P-VH83pk-OVYMxwSxMSUs+XZpQKhG+dicfnoBQmLz-cg@mail.gmail.com>

Who are the shepherds and should I expect to hear from them with plenty of
time available prior to the next AC meeting to make potential initial
adjustments?

Best,

Martin



On Monday, February 17, 2014, Scott Leibrand <scottleibrand at gmail.com>
wrote:

> Marc,
>
> Good input, thanks. Can you expand a bit on which aspects of the LRSA some
> of your clients find burdensome, and which aspects of RIPE 605 they find
> preferable? As we (and particularly the AC shepherds) work with the
> proposal originator on getting a clear problem statement and then figuring
> out which parts of prop-203 are in scope for the PDP (and which parts
> should be submitted through the ACSP), it would be good to have your
> perspective on what aspects of the RIPE policy would be most helpful for
> making sure that transfers from non-RSA address holders get properly
> recorded.
>
> Thanks,
> Scott
>
> On Feb 17, 2014, at 11:53 AM, "Lindsey, Marc" <mlindsey at lb3law.com<javascript:_e(%7B%7D,'cvml','mlindsey at lb3law.com');>>
> wrote:
>
>  I advise several large legacy block holders.  Some of them signed the
> LRSA, but many have not.  For them, the burdens imposed by the LRSA
> outweigh the benefits.   Some on the PPML have suggested that off-contract
> legacy holders don't sign up with ARIN because they want to be
> free-riders.  But the fees (and the avoidance of the fees) are not a factor
> in their LRSA decision.
>
>
>
> Based on my experience working with legacy block holders, I believe
> adopting a policy substantially similar to RIPE 605 (ARIN prop 203) would
> go a long way in harmonizing the interests of the ARIN community with the
> community of legacy holders that do not have formal relationships with
> ARIN.
>
>
>
> ARIN's absolute control over additional allocations of "free" IPv4 numbers
> in its region has served as the primary policy enforcement mechanism.  This
> carrot really only works on recipients that need more IPv4 numbers, and
> then only as long as ARIN has free numbers to give out.  It doesn't
> directly influence the behavior of many legacy block holders when they
> convey their spare numbers.   Legacy holders are a major source of future
> IPv4 number distributions, and their relevance to the broader ARIN
> community will become more prominent as ARIN's IPv4 free pool reaches
> depletion.
>
>
>
> In the secondary market context, ARIN now relies on its ability to
> withhold registry database updates as the primary means to extend
> enforcement of its current policies into private transactions between
> parties conveying beneficial use of IPv4 numbers.  This, however, is a weak
> enforcement tool. Two parties can convey beneficial use of IPv4 numbers in
> lawful commercial transactions without updating ARIN's registry database.
> But IPv4 number conveyances not recorded in the registry system produces
> very undesirable results - the "reality" in the registry database will not
> reflect operational reality, as David Conrad and others have pointed out in
> several posts.
>
>
>
> Buyers and sellers would prefer to document their conveyances in a
> reliable and accurate public registry, but not if the contingencies and
> conditions materially and adversely affect their commercial arrangement.
> RIPE 605/ ARIN prop 203 recognizes this reality.  With a little tweaking,
> adopting it would go a long way in minimizing the disincentives now facing
> legacy holders (and entities that want to acquire their numbers) when
> contemplating whether updating the registry database is worth the risk of
> subjecting their transactions to ARIN's approval process.
>
>
>
> *Marc Lindsey*
> Levine, Blaszak, Block & Boothby, LLP
> 2001 L Street, NW Suite 900
> Washington, DC 20036
> *Office:* (202) 857-2564
> *Mobile:* (202) 491-3230
> *Email:* mlindsey at lb3law.com<javascript:_e(%7B%7D,'cvml','mlindsey at lb3law.com');>
> Website: www.lb3law.com
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<javascript:_e(%7B%7D,'cvml','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<javascript:_e(%7B%7D,'cvml','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/20140217/85816f8c/attachment.htm>

From john.sweeting at twcable.com  Mon Feb 17 20:20:47 2014
From: john.sweeting at twcable.com (Sweeting, John)
Date: Mon, 17 Feb 2014 20:20:47 -0500
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy
	Internet	Resource Holders
In-Reply-To: <CAMDXq5P-VH83pk-OVYMxwSxMSUs+XZpQKhG+dicfnoBQmLz-cg@mail.gmail.com>
References: <cb24b94beb454acea335aaa5d73118d4@BN1PR07MB022.namprd07.prod.outlook.com>
	<F5A17F76-8EC8-42AC-BD88-22EB1E06C3F7@gmail.com>
	<CAMDXq5P-VH83pk-OVYMxwSxMSUs+XZpQKhG+dicfnoBQmLz-cg@mail.gmail.com>
Message-ID: <95C45CD4-BA41-4E2C-B959-523F1B7E208C@twcable.com>

The shepherds will be notified in the morning. Our next meeting is this Thursday so most likely not but we'll see. They should initially reach out to to tomorrow, I will notify you as soon as they accept the appointment. Thanks.

Sent from my iPhone

On Feb 17, 2014, at 7:52 PM, "Martin Hannigan" <hannigan at gmail.com<mailto:hannigan at gmail.com>> wrote:


Who are the shepherds and should I expect to hear from them with plenty of time available prior to the next AC meeting to make potential initial adjustments?

Best,

Martin



On Monday, February 17, 2014, Scott Leibrand <scottleibrand at gmail.com<mailto:scottleibrand at gmail.com>> wrote:
Marc,

Good input, thanks. Can you expand a bit on which aspects of the LRSA some of your clients find burdensome, and which aspects of RIPE 605 they find preferable? As we (and particularly the AC shepherds) work with the proposal originator on getting a clear problem statement and then figuring out which parts of prop-203 are in scope for the PDP (and which parts should be submitted through the ACSP), it would be good to have your perspective on what aspects of the RIPE policy would be most helpful for making sure that transfers from non-RSA address holders get properly recorded.

Thanks,
Scott

On Feb 17, 2014, at 11:53 AM, "Lindsey, Marc" <mlindsey at lb3law.com<javascript:_e(%7B%7D,'cvml','mlindsey at lb3law.com');>> wrote:

I advise several large legacy block holders.  Some of them signed the LRSA, but many have not.  For them, the burdens imposed by the LRSA outweigh the benefits.   Some on the PPML have suggested that off-contract legacy holders don?t sign up with ARIN because they want to be free-riders.  But the fees (and the avoidance of the fees) are not a factor in their LRSA decision.

Based on my experience working with legacy block holders, I believe adopting a policy substantially similar to RIPE 605 (ARIN prop 203) would go a long way in harmonizing the interests of the ARIN community with the community of legacy holders that do not have formal relationships with ARIN.

ARIN?s absolute control over additional allocations of ?free? IPv4 numbers in its region has served as the primary policy enforcement mechanism.  This carrot really only works on recipients that need more IPv4 numbers, and then only as long as ARIN has free numbers to give out.  It doesn?t directly influence the behavior of many legacy block holders when they convey their spare numbers.   Legacy holders are a major source of future IPv4 number distributions, and their relevance to the broader ARIN community will become more prominent as ARIN?s IPv4 free pool reaches depletion.

In the secondary market context, ARIN now relies on its ability to withhold registry database updates as the primary means to extend enforcement of its current policies into private transactions between parties conveying beneficial use of IPv4 numbers.  This, however, is a weak enforcement tool. Two parties can convey beneficial use of IPv4 numbers in lawful commercial transactions without updating ARIN?s registry database.  But IPv4 number conveyances not recorded in the registry system produces very undesirable results ? the ?reality? in the registry database will not reflect operational reality, as David Conrad and others have pointed out in several posts.

Buyers and sellers would prefer to document their conveyances in a reliable and accurate public registry, but not if the contingencies and conditions materially and adversely affect their commercial arrangement.  RIPE 605/ ARIN prop 203 recognizes this reality.  With a little tweaking, adopting it would go a long way in minimizing the disincentives now facing legacy holders (and entities that want to acquire their numbers) when contemplating whether updating the registry database is worth the risk of subjecting their transactions to ARIN?s approval process.

Marc Lindsey
Levine, Blaszak, Block & Boothby, LLP
2001 L Street, NW Suite 900
Washington, DC 20036
Office: (202) 857-2564
Mobile: (202) 491-3230
Email: mlindsey at lb3law.com<javascript:_e(%7B%7D,'cvml','mlindsey at lb3law.com');>
Website: www.lb3law.com<http://www.lb3law.com>

_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<javascript:_e(%7B%7D,'cvml','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<javascript:_e(%7B%7D,'cvml','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<mailto:ARIN-PPML at arin.net>).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net<mailto:info at arin.net> if you experience any issues.

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140217/62517f97/attachment.htm>

From john.sweeting at twcable.com  Mon Feb 17 20:32:20 2014
From: john.sweeting at twcable.com (Sweeting, John)
Date: Mon, 17 Feb 2014 20:32:20 -0500
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy
	Internet	Resource Holders
In-Reply-To: <CAMDXq5P-VH83pk-OVYMxwSxMSUs+XZpQKhG+dicfnoBQmLz-cg@mail.gmail.com>
References: <cb24b94beb454acea335aaa5d73118d4@BN1PR07MB022.namprd07.prod.outlook.com>
	<F5A17F76-8EC8-42AC-BD88-22EB1E06C3F7@gmail.com>
	<CAMDXq5P-VH83pk-OVYMxwSxMSUs+XZpQKhG+dicfnoBQmLz-cg@mail.gmail.com>
Message-ID: <07555295-0A95-4EB5-BC99-E53726775B56@twcable.com>

Since I just received confirmation from the Primary I can now let you know it will be Kevin as primary and Bill D as secondary. They will be reaching out to you ASAP. Please let me know if there is anything else I can do at this time. Thanks again

-john

Sent from my iPhone

On Feb 17, 2014, at 7:52 PM, "Martin Hannigan" <hannigan at gmail.com<mailto:hannigan at gmail.com>> wrote:


Who are the shepherds and should I expect to hear from them with plenty of time available prior to the next AC meeting to make potential initial adjustments?

Best,

Martin



On Monday, February 17, 2014, Scott Leibrand <scottleibrand at gmail.com<mailto:scottleibrand at gmail.com>> wrote:
Marc,

Good input, thanks. Can you expand a bit on which aspects of the LRSA some of your clients find burdensome, and which aspects of RIPE 605 they find preferable? As we (and particularly the AC shepherds) work with the proposal originator on getting a clear problem statement and then figuring out which parts of prop-203 are in scope for the PDP (and which parts should be submitted through the ACSP), it would be good to have your perspective on what aspects of the RIPE policy would be most helpful for making sure that transfers from non-RSA address holders get properly recorded.

Thanks,
Scott

On Feb 17, 2014, at 11:53 AM, "Lindsey, Marc" <mlindsey at lb3law.com<javascript:_e(%7B%7D,'cvml','mlindsey at lb3law.com');>> wrote:

I advise several large legacy block holders.  Some of them signed the LRSA, but many have not.  For them, the burdens imposed by the LRSA outweigh the benefits.   Some on the PPML have suggested that off-contract legacy holders don?t sign up with ARIN because they want to be free-riders.  But the fees (and the avoidance of the fees) are not a factor in their LRSA decision.

Based on my experience working with legacy block holders, I believe adopting a policy substantially similar to RIPE 605 (ARIN prop 203) would go a long way in harmonizing the interests of the ARIN community with the community of legacy holders that do not have formal relationships with ARIN.

ARIN?s absolute control over additional allocations of ?free? IPv4 numbers in its region has served as the primary policy enforcement mechanism.  This carrot really only works on recipients that need more IPv4 numbers, and then only as long as ARIN has free numbers to give out.  It doesn?t directly influence the behavior of many legacy block holders when they convey their spare numbers.   Legacy holders are a major source of future IPv4 number distributions, and their relevance to the broader ARIN community will become more prominent as ARIN?s IPv4 free pool reaches depletion.

In the secondary market context, ARIN now relies on its ability to withhold registry database updates as the primary means to extend enforcement of its current policies into private transactions between parties conveying beneficial use of IPv4 numbers.  This, however, is a weak enforcement tool. Two parties can convey beneficial use of IPv4 numbers in lawful commercial transactions without updating ARIN?s registry database.  But IPv4 number conveyances not recorded in the registry system produces very undesirable results ? the ?reality? in the registry database will not reflect operational reality, as David Conrad and others have pointed out in several posts.

Buyers and sellers would prefer to document their conveyances in a reliable and accurate public registry, but not if the contingencies and conditions materially and adversely affect their commercial arrangement.  RIPE 605/ ARIN prop 203 recognizes this reality.  With a little tweaking, adopting it would go a long way in minimizing the disincentives now facing legacy holders (and entities that want to acquire their numbers) when contemplating whether updating the registry database is worth the risk of subjecting their transactions to ARIN?s approval process.

Marc Lindsey
Levine, Blaszak, Block & Boothby, LLP
2001 L Street, NW Suite 900
Washington, DC 20036
Office: (202) 857-2564
Mobile: (202) 491-3230
Email: mlindsey at lb3law.com<javascript:_e(%7B%7D,'cvml','mlindsey at lb3law.com');>
Website: www.lb3law.com<http://www.lb3law.com>

_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<javascript:_e(%7B%7D,'cvml','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<javascript:_e(%7B%7D,'cvml','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<mailto:ARIN-PPML at arin.net>).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net<mailto:info at arin.net> if you experience any issues.

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140217/113b3982/attachment.htm>

From snoble at sonn.com  Mon Feb 17 20:59:47 2014
From: snoble at sonn.com (Steve Noble)
Date: Mon, 17 Feb 2014 17:59:47 -0800
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy Internet
 Resource Holders
In-Reply-To: <15A4C5D7-1EAE-4FB5-BF18-5D1BE44F4103@arin.net>
References: <cb24b94beb454acea335aaa5d73118d4@BN1PR07MB022.namprd07.prod.outlook.com>
	<53027A34.5000303@sonn.com>
	<15A4C5D7-1EAE-4FB5-BF18-5D1BE44F4103@arin.net>
Message-ID: <5302BE93.1020001@sonn.com>

Hi John,

You were the one who eventually did fix the issue and I do appreciate that.

I don't believe that ARIN today will treat anyone differently than they 
treated me, as the behavior is based on the rules and regulations that 
ARIN runs under.  The bar is set too high to allow objects to be 
updated, especially if they have not been updated in a long time.

I've been around long enough to know a number of resources/objects be it 
legacy IP assignments or legacy AS numbers that are in use today but 
still reflect old data.  I believe it would be foolhardy to even attempt 
to correct the information as it would only cause excess paperwork, 
wasted time, management sign-offs, possible loss of the resource or worse.

Until there is a change in ARIN's behavior that allows for the 
acceptance of historical artifacts, the database will never be correct 
and there is certainly no reason for people who would like to, to try 
and update the information contained within it.

> John Curran <mailto:jcurran at arin.net>
> February 17, 2014 at 2:02 PM
> On Feb 17, 2014, at 4:08 PM, Steve Noble <snoble at sonn.com 
> <mailto:snoble at sonn.com>> wrote:
>
>
> Steve -
>   I'll be the first to admit you suffered needlessly, and appreciate 
> your diligence in
>   pursuing the correction with ARIN (as it led to us finding an end 
> case for ASN-
>   only resource records.)    For those who might not remember the 
> issue,  read
> <http://lists.arin.net/pipermail/arin-ppml/2012-September/026100.html>
>   At this time, you should not longer have any problem updating your 
> ASN records,
>   and I will apologize again that we did not recognize the issue as a 
> fallout from our
>   migration any sooner than we did.
>
> Thanks,
> /John
>
> John Curran
> President and CEO
> ARIN
>
>
> Steve Noble <mailto:snoble at sonn.com>
> February 17, 2014 at 1:08 PM
> As a holder of both legacy and non-legacy ARIN objects, I have been 
> subject to ARIN's registry update blocks on _non-legacy_ objects that 
> I rightfully control and use.  I spent years (6 I believe) fighting 
> with ARIN to update the information on one of my ASNs while ARIN 
> continued to bill me for a 'service' which they did not provide.  
> ARIN's unwillingness to update the database to have correct contact 
> information is not only an undesirable effect of their policies, but 
> also an indication of ARIN's lack of concern about having correct 
> information in the database.
>
>  As a consumer, I see no value to the service that ARIN provides. I 
> pay ARIN's fees only to keep ARIN from giving the AS that I use to 
> someone else and causing an administrative issue to become an 
> operational issue.
>
> Lindsey, Marc <mailto:mlindsey at lb3law.com>
> February 17, 2014 at 11:53 AM
>
> I advise several large legacy block holders.  Some of them signed the 
> LRSA, but many have not.  For them, the burdens imposed by the LRSA 
> outweigh the benefits.   Some on the PPML have suggested that 
> off-contract legacy holders don't sign up with ARIN because they want 
> to be free-riders.  But the fees (and the avoidance of the fees) are 
> not a factor in their LRSA decision.
>
> Based on my experience working with legacy block holders, I believe 
> adopting a policy substantially similar to RIPE 605 (ARIN prop 203) 
> would go a long way in harmonizing the interests of the ARIN community 
> with the community of legacy holders that do not have formal 
> relationships with ARIN.
>
> ARIN's absolute control over additional allocations of "free" IPv4 
> numbers in its region has served as the primary policy enforcement 
> mechanism.  This carrot really only works on recipients that need more 
> IPv4 numbers, and then only as long as ARIN has free numbers to give 
> out.  It doesn't directly influence the behavior of many legacy block 
> holders when they convey their spare numbers.   Legacy holders are a 
> major source of future IPv4 number distributions, and their relevance 
> to the broader ARIN community will become more prominent as ARIN's 
> IPv4 free pool reaches depletion.
>
> In the secondary market context, ARIN now relies on its ability to 
> withhold registry database updates as the primary means to extend 
> enforcement of its current policies into private transactions between 
> parties conveying beneficial use of IPv4 numbers.  This, however, is a 
> weak enforcement tool. Two parties can convey beneficial use of IPv4 
> numbers in lawful commercial transactions without updating ARIN's 
> registry database.  But IPv4 number conveyances not recorded in the 
> registry system produces very undesirable results -- the "reality" in 
> the registry database will not reflect operational reality, as David 
> Conrad and others have pointed out in several posts.
>
> Buyers and sellers would prefer to document their conveyances in a 
> reliable and accurate public registry, but not if the contingencies 
> and conditions materially and adversely affect their commercial 
> arrangement.  RIPE 605/ ARIN prop 203 recognizes this reality.  With a 
> little tweaking, adopting it would go a long way in minimizing the 
> disincentives now facing legacy holders (and entities that want to 
> acquire their numbers) when contemplating whether updating the 
> registry database is worth the risk of subjecting their transactions 
> to ARIN's approval process.
>
> *Marc Lindsey*
> Levine, Blaszak, Block & Boothby, LLP
> 2001 L Street, NW Suite 900
> Washington, DC 20036
> /Office:/ (202) 857-2564
> /Mobile:/ (202) 491-3230
> /Email:/ mlindsey at lb3law.com <mailto:mlindsey at lb3law.com>
> Website: www.lb3law.com <http://www.lb3law.com>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140217/a5b4c2a2/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140217/a5b4c2a2/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1365 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140217/a5b4c2a2/attachment-0001.jpg>

From hannigan at gmail.com  Mon Feb 17 22:07:43 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Mon, 17 Feb 2014 22:07:43 -0500
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy Internet
	Resource Holders
In-Reply-To: <CAMDXq5PLP3=x16ROvbkZRsLF0XDN=tLMGHtQ3FMb0ibiSomYpg@mail.gmail.com>
References: <cb24b94beb454acea335aaa5d73118d4@BN1PR07MB022.namprd07.prod.outlook.com>
	<F5A17F76-8EC8-42AC-BD88-22EB1E06C3F7@gmail.com>
	<CAMDXq5P-VH83pk-OVYMxwSxMSUs+XZpQKhG+dicfnoBQmLz-cg@mail.gmail.com>
	<07555295-0A95-4EB5-BC99-E53726775B56@twcable.com>
	<CAMDXq5PLP3=x16ROvbkZRsLF0XDN=tLMGHtQ3FMb0ibiSomYpg@mail.gmail.com>
Message-ID: <CAMDXq5MjYddHOJ8xr8UFb31jNTu4z8KDuw=sJG5uCx19yOmDsw@mail.gmail.com>

Whoops, dropped a word. There was a PDP Simplification Committee
established by the board. Sorely needed.

Best,

-M<



On Mon, Feb 17, 2014 at 9:53 PM, Martin Hannigan <hannigan at gmail.com> wrote:
> Let me know if we can work on this before the meeting.
>
> Side note, I noticed that in January 2013 there was a PDP
> simplification by the board. Another discussion happened in February
> 2013. There was an update by Bill Woodcock, the "PDP Simplification
> Chair" and then nothing. Might be a good committee to breathe some
> life back into.
>
> Thanks!
>
> -M<
>
>
>
>
>
> On Mon, Feb 17, 2014 at 8:32 PM, Sweeting, John
> <john.sweeting at twcable.com> wrote:
>> Since I just received confirmation from the Primary I can now let you know
>> it will be Kevin as primary and Bill D as secondary. They will be reaching
>> out to you ASAP. Please let me know if there is anything else I can do at
>> this time. Thanks again
>>
>> -john
>>
>> Sent from my iPhone
>>
>> On Feb 17, 2014, at 7:52 PM, "Martin Hannigan" <hannigan at gmail.com> wrote:
>>
>>
>> Who are the shepherds and should I expect to hear from them with plenty of
>> time available prior to the next AC meeting to make potential initial
>> adjustments?
>>
>> Best,
>>
>> Martin
>>
>>
>>
>> On Monday, February 17, 2014, Scott Leibrand <scottleibrand at gmail.com>
>> wrote:
>>>
>>> Marc,
>>>
>>> Good input, thanks. Can you expand a bit on which aspects of the LRSA some
>>> of your clients find burdensome, and which aspects of RIPE 605 they find
>>> preferable? As we (and particularly the AC shepherds) work with the proposal
>>> originator on getting a clear problem statement and then figuring out which
>>> parts of prop-203 are in scope for the PDP (and which parts should be
>>> submitted through the ACSP), it would be good to have your perspective on
>>> what aspects of the RIPE policy would be most helpful for making sure that
>>> transfers from non-RSA address holders get properly recorded.
>>>
>>> Thanks,
>>> Scott
>>>
>>> On Feb 17, 2014, at 11:53 AM, "Lindsey, Marc" <mlindsey at lb3law.com> wrote:
>>>
>>> I advise several large legacy block holders.  Some of them signed the
>>> LRSA, but many have not.  For them, the burdens imposed by the LRSA outweigh
>>> the benefits.   Some on the PPML have suggested that off-contract legacy
>>> holders don't sign up with ARIN because they want to be free-riders.  But
>>> the fees (and the avoidance of the fees) are not a factor in their LRSA
>>> decision.
>>>
>>>
>>>
>>> Based on my experience working with legacy block holders, I believe
>>> adopting a policy substantially similar to RIPE 605 (ARIN prop 203) would go
>>> a long way in harmonizing the interests of the ARIN community with the
>>> community of legacy holders that do not have formal relationships with ARIN.
>>>
>>>
>>>
>>> ARIN's absolute control over additional allocations of "free" IPv4 numbers
>>> in its region has served as the primary policy enforcement mechanism.  This
>>> carrot really only works on recipients that need more IPv4 numbers, and then
>>> only as long as ARIN has free numbers to give out.  It doesn't directly
>>> influence the behavior of many legacy block holders when they convey their
>>> spare numbers.   Legacy holders are a major source of future IPv4 number
>>> distributions, and their relevance to the broader ARIN community will become
>>> more prominent as ARIN's IPv4 free pool reaches depletion.
>>>
>>>
>>>
>>> In the secondary market context, ARIN now relies on its ability to
>>> withhold registry database updates as the primary means to extend
>>> enforcement of its current policies into private transactions between
>>> parties conveying beneficial use of IPv4 numbers.  This, however, is a weak
>>> enforcement tool. Two parties can convey beneficial use of IPv4 numbers in
>>> lawful commercial transactions without updating ARIN's registry database.
>>> But IPv4 number conveyances not recorded in the registry system produces
>>> very undesirable results - the "reality" in the registry database will not
>>> reflect operational reality, as David Conrad and others have pointed out in
>>> several posts.
>>>
>>>
>>>
>>> Buyers and sellers would prefer to document their conveyances in a
>>> reliable and accurate public registry, but not if the contingencies and
>>> conditions materially and adversely affect their commercial arrangement.
>>> RIPE 605/ ARIN prop 203 recognizes this reality.  With a little tweaking,
>>> adopting it would go a long way in minimizing the disincentives now facing
>>> legacy holders (and entities that want to acquire their numbers) when
>>> contemplating whether updating the registry database is worth the risk of
>>> subjecting their transactions to ARIN's approval process.
>>>
>>>
>>>
>>> Marc Lindsey
>>> Levine, Blaszak, Block & Boothby, LLP
>>> 2001 L Street, NW Suite 900
>>> Washington, DC 20036
>>> Office: (202) 857-2564
>>> Mobile: (202) 491-3230
>>> Email: mlindsey at lb3law.com
>>> Website: www.lb3law.com
>>>
>>>
>>>
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
>>
>> ________________________________
>> This E-mail and any of its attachments may contain Time Warner Cable
>> proprietary information, which is privileged, confidential, or subject to
>> copyright belonging to Time Warner Cable. This E-mail is intended solely for
>> the use of the individual or entity to which it is addressed. If you are not
>> the intended recipient of this E-mail, you are hereby notified that any
>> dissemination, distribution, copying, or action taken in relation to the
>> contents of and attachments to this E-mail is strictly prohibited and may be
>> unlawful. If you have received this E-mail in error, please notify the
>> sender immediately and permanently delete the original and any copy of this
>> E-mail and any printout.


From jcurran at arin.net  Mon Feb 17 22:18:10 2014
From: jcurran at arin.net (John Curran)
Date: Tue, 18 Feb 2014 03:18:10 +0000
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy Internet
 Resource Holders
In-Reply-To: <5302BE93.1020001@sonn.com>
References: <cb24b94beb454acea335aaa5d73118d4@BN1PR07MB022.namprd07.prod.outlook.com>
	<53027A34.5000303@sonn.com>
	<15A4C5D7-1EAE-4FB5-BF18-5D1BE44F4103@arin.net>
	<5302BE93.1020001@sonn.com>
Message-ID: <C40BA340-26D6-40FD-A4AF-4F9B065AFEE3@arin.net>

On Feb 17, 2014, at 8:59 PM, Steve Noble <snoble at sonn.com<mailto:snoble at sonn.com>> wrote:

Hi John,

You were the one who eventually did fix the issue and I do appreciate that.

I don't believe that ARIN today will treat anyone differently than they treated me, as the behavior is based on the rules and regulations that ARIN runs under.  The bar is set too high to allow objects to be updated, especially if they have not been updated in a long time.

We obviously need to exercise due caution in making an update of an Internet
number resource records  (particularly the organization field) given the potential
for adverse consequences.   While it is quite obvious to everyone that they are
indeed the rightful address holder, we've had some remarkably creative attempts
by third-parties to "correct their records" and in the process hijack resources.

As I noted in your case, there was a particular system change which impacted you
(and anyone else with an organization record with no current contacts and only
AS numbers associated with it); this has been fixed and would definitely result in
more expeditious processing of your request if done today.

I've been around long enough to know a number of resources/objects be it legacy IP assignments or legacy AS numbers that are in use today but still reflect old data.  I believe it would be foolhardy to even attempt to correct the information as it would only cause excess paperwork, wasted time, management sign-offs, possible loss of the resource or worse.

Until there is a change in ARIN's behavior that allows for the acceptance of historical artifacts, the database will never be correct and there is certainly no reason for people who would like to, to try and update the information contained within it.

While I can't speak to the AS numbers, it is quite possible that some amount of
the IPv4 address blocks will clean up over time due to interest in transfers.  We
are seeing an increasingly number of related updates (even now before free pool
depletion), the brokers are assisting with such, and it is likely to increase with IPv4
runout.

Thanks!
/John

John Curran
President and CEO
ARIN

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

From hannigan at gmail.com  Mon Feb 17 21:53:46 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Mon, 17 Feb 2014 21:53:46 -0500
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy Internet
	Resource Holders
In-Reply-To: <07555295-0A95-4EB5-BC99-E53726775B56@twcable.com>
References: <cb24b94beb454acea335aaa5d73118d4@BN1PR07MB022.namprd07.prod.outlook.com>
	<F5A17F76-8EC8-42AC-BD88-22EB1E06C3F7@gmail.com>
	<CAMDXq5P-VH83pk-OVYMxwSxMSUs+XZpQKhG+dicfnoBQmLz-cg@mail.gmail.com>
	<07555295-0A95-4EB5-BC99-E53726775B56@twcable.com>
Message-ID: <CAMDXq5PLP3=x16ROvbkZRsLF0XDN=tLMGHtQ3FMb0ibiSomYpg@mail.gmail.com>

Let me know if we can work on this before the meeting.

Side note, I noticed that in January 2013 there was a PDP
simplification by the board. Another discussion happened in February
2013. There was an update by Bill Woodcock, the "PDP Simplification
Chair" and then nothing. Might be a good committee to breathe some
life back into.

Thanks!

-M<





On Mon, Feb 17, 2014 at 8:32 PM, Sweeting, John
<john.sweeting at twcable.com> wrote:
> Since I just received confirmation from the Primary I can now let you know
> it will be Kevin as primary and Bill D as secondary. They will be reaching
> out to you ASAP. Please let me know if there is anything else I can do at
> this time. Thanks again
>
> -john
>
> Sent from my iPhone
>
> On Feb 17, 2014, at 7:52 PM, "Martin Hannigan" <hannigan at gmail.com> wrote:
>
>
> Who are the shepherds and should I expect to hear from them with plenty of
> time available prior to the next AC meeting to make potential initial
> adjustments?
>
> Best,
>
> Martin
>
>
>
> On Monday, February 17, 2014, Scott Leibrand <scottleibrand at gmail.com>
> wrote:
>>
>> Marc,
>>
>> Good input, thanks. Can you expand a bit on which aspects of the LRSA some
>> of your clients find burdensome, and which aspects of RIPE 605 they find
>> preferable? As we (and particularly the AC shepherds) work with the proposal
>> originator on getting a clear problem statement and then figuring out which
>> parts of prop-203 are in scope for the PDP (and which parts should be
>> submitted through the ACSP), it would be good to have your perspective on
>> what aspects of the RIPE policy would be most helpful for making sure that
>> transfers from non-RSA address holders get properly recorded.
>>
>> Thanks,
>> Scott
>>
>> On Feb 17, 2014, at 11:53 AM, "Lindsey, Marc" <mlindsey at lb3law.com> wrote:
>>
>> I advise several large legacy block holders.  Some of them signed the
>> LRSA, but many have not.  For them, the burdens imposed by the LRSA outweigh
>> the benefits.   Some on the PPML have suggested that off-contract legacy
>> holders don't sign up with ARIN because they want to be free-riders.  But
>> the fees (and the avoidance of the fees) are not a factor in their LRSA
>> decision.
>>
>>
>>
>> Based on my experience working with legacy block holders, I believe
>> adopting a policy substantially similar to RIPE 605 (ARIN prop 203) would go
>> a long way in harmonizing the interests of the ARIN community with the
>> community of legacy holders that do not have formal relationships with ARIN.
>>
>>
>>
>> ARIN's absolute control over additional allocations of "free" IPv4 numbers
>> in its region has served as the primary policy enforcement mechanism.  This
>> carrot really only works on recipients that need more IPv4 numbers, and then
>> only as long as ARIN has free numbers to give out.  It doesn't directly
>> influence the behavior of many legacy block holders when they convey their
>> spare numbers.   Legacy holders are a major source of future IPv4 number
>> distributions, and their relevance to the broader ARIN community will become
>> more prominent as ARIN's IPv4 free pool reaches depletion.
>>
>>
>>
>> In the secondary market context, ARIN now relies on its ability to
>> withhold registry database updates as the primary means to extend
>> enforcement of its current policies into private transactions between
>> parties conveying beneficial use of IPv4 numbers.  This, however, is a weak
>> enforcement tool. Two parties can convey beneficial use of IPv4 numbers in
>> lawful commercial transactions without updating ARIN's registry database.
>> But IPv4 number conveyances not recorded in the registry system produces
>> very undesirable results - the "reality" in the registry database will not
>> reflect operational reality, as David Conrad and others have pointed out in
>> several posts.
>>
>>
>>
>> Buyers and sellers would prefer to document their conveyances in a
>> reliable and accurate public registry, but not if the contingencies and
>> conditions materially and adversely affect their commercial arrangement.
>> RIPE 605/ ARIN prop 203 recognizes this reality.  With a little tweaking,
>> adopting it would go a long way in minimizing the disincentives now facing
>> legacy holders (and entities that want to acquire their numbers) when
>> contemplating whether updating the registry database is worth the risk of
>> subjecting their transactions to ARIN's approval process.
>>
>>
>>
>> Marc Lindsey
>> Levine, Blaszak, Block & Boothby, LLP
>> 2001 L Street, NW Suite 900
>> Washington, DC 20036
>> Office: (202) 857-2564
>> Mobile: (202) 491-3230
>> Email: mlindsey at lb3law.com
>> Website: www.lb3law.com
>>
>>
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
>
> ________________________________
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject to
> copyright belonging to Time Warner Cable. This E-mail is intended solely for
> the use of the individual or entity to which it is addressed. If you are not
> the intended recipient of this E-mail, you are hereby notified that any
> dissemination, distribution, copying, or action taken in relation to the
> contents of and attachments to this E-mail is strictly prohibited and may be
> unlawful. If you have received this E-mail in error, please notify the
> sender immediately and permanently delete the original and any copy of this
> E-mail and any printout.


From john.sweeting at twcable.com  Tue Feb 18 08:10:05 2014
From: john.sweeting at twcable.com (Sweeting, John)
Date: Tue, 18 Feb 2014 08:10:05 -0500
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy Internet
 Resource Holders
In-Reply-To: <CAMDXq5PLP3=x16ROvbkZRsLF0XDN=tLMGHtQ3FMb0ibiSomYpg@mail.gmail.com>
References: <cb24b94beb454acea335aaa5d73118d4@BN1PR07MB022.namprd07.prod.outlook.com>
	<F5A17F76-8EC8-42AC-BD88-22EB1E06C3F7@gmail.com>
	<CAMDXq5P-VH83pk-OVYMxwSxMSUs+XZpQKhG+dicfnoBQmLz-cg@mail.gmail.com>
	<07555295-0A95-4EB5-BC99-E53726775B56@twcable.com>
	<CAMDXq5PLP3=x16ROvbkZRsLF0XDN=tLMGHtQ3FMb0ibiSomYpg@mail.gmail.com>
Message-ID: <3769DF1A-2960-4683-B052-4B4C19598898@twcable.com>

Kevin is setting up a conference call based on your availability, so yes. Thanks

Sent from my iPhone

> On Feb 17, 2014, at 9:54 PM, "Martin Hannigan" <hannigan at gmail.com> wrote:
>
> Let me know if we can work on this before the meeting.
>
> Side note, I noticed that in January 2013 there was a PDP
> simplification by the board. Another discussion happened in February
> 2013. There was an update by Bill Woodcock, the "PDP Simplification
> Chair" and then nothing. Might be a good committee to breathe some
> life back into.
>
> Thanks!
>
> -M<
>
>
>
>
>
> On Mon, Feb 17, 2014 at 8:32 PM, Sweeting, John
> <john.sweeting at twcable.com> wrote:
>> Since I just received confirmation from the Primary I can now let you know
>> it will be Kevin as primary and Bill D as secondary. They will be reaching
>> out to you ASAP. Please let me know if there is anything else I can do at
>> this time. Thanks again
>>
>> -john
>>
>> Sent from my iPhone
>>
>> On Feb 17, 2014, at 7:52 PM, "Martin Hannigan" <hannigan at gmail.com> wrote:
>>
>>
>> Who are the shepherds and should I expect to hear from them with plenty of
>> time available prior to the next AC meeting to make potential initial
>> adjustments?
>>
>> Best,
>>
>> Martin
>>
>>
>>
>> On Monday, February 17, 2014, Scott Leibrand <scottleibrand at gmail.com>
>> wrote:
>>>
>>> Marc,
>>>
>>> Good input, thanks. Can you expand a bit on which aspects of the LRSA some
>>> of your clients find burdensome, and which aspects of RIPE 605 they find
>>> preferable? As we (and particularly the AC shepherds) work with the proposal
>>> originator on getting a clear problem statement and then figuring out which
>>> parts of prop-203 are in scope for the PDP (and which parts should be
>>> submitted through the ACSP), it would be good to have your perspective on
>>> what aspects of the RIPE policy would be most helpful for making sure that
>>> transfers from non-RSA address holders get properly recorded.
>>>
>>> Thanks,
>>> Scott
>>>
>>> On Feb 17, 2014, at 11:53 AM, "Lindsey, Marc" <mlindsey at lb3law.com> wrote:
>>>
>>> I advise several large legacy block holders.  Some of them signed the
>>> LRSA, but many have not.  For them, the burdens imposed by the LRSA outweigh
>>> the benefits.   Some on the PPML have suggested that off-contract legacy
>>> holders don't sign up with ARIN because they want to be free-riders.  But
>>> the fees (and the avoidance of the fees) are not a factor in their LRSA
>>> decision.
>>>
>>>
>>>
>>> Based on my experience working with legacy block holders, I believe
>>> adopting a policy substantially similar to RIPE 605 (ARIN prop 203) would go
>>> a long way in harmonizing the interests of the ARIN community with the
>>> community of legacy holders that do not have formal relationships with ARIN.
>>>
>>>
>>>
>>> ARIN's absolute control over additional allocations of "free" IPv4 numbers
>>> in its region has served as the primary policy enforcement mechanism.  This
>>> carrot really only works on recipients that need more IPv4 numbers, and then
>>> only as long as ARIN has free numbers to give out.  It doesn't directly
>>> influence the behavior of many legacy block holders when they convey their
>>> spare numbers.   Legacy holders are a major source of future IPv4 number
>>> distributions, and their relevance to the broader ARIN community will become
>>> more prominent as ARIN's IPv4 free pool reaches depletion.
>>>
>>>
>>>
>>> In the secondary market context, ARIN now relies on its ability to
>>> withhold registry database updates as the primary means to extend
>>> enforcement of its current policies into private transactions between
>>> parties conveying beneficial use of IPv4 numbers.  This, however, is a weak
>>> enforcement tool. Two parties can convey beneficial use of IPv4 numbers in
>>> lawful commercial transactions without updating ARIN's registry database.
>>> But IPv4 number conveyances not recorded in the registry system produces
>>> very undesirable results - the "reality" in the registry database will not
>>> reflect operational reality, as David Conrad and others have pointed out in
>>> several posts.
>>>
>>>
>>>
>>> Buyers and sellers would prefer to document their conveyances in a
>>> reliable and accurate public registry, but not if the contingencies and
>>> conditions materially and adversely affect their commercial arrangement.
>>> RIPE 605/ ARIN prop 203 recognizes this reality.  With a little tweaking,
>>> adopting it would go a long way in minimizing the disincentives now facing
>>> legacy holders (and entities that want to acquire their numbers) when
>>> contemplating whether updating the registry database is worth the risk of
>>> subjecting their transactions to ARIN's approval process.
>>>
>>>
>>>
>>> Marc Lindsey
>>> Levine, Blaszak, Block & Boothby, LLP
>>> 2001 L Street, NW Suite 900
>>> Washington, DC 20036
>>> Office: (202) 857-2564
>>> Mobile: (202) 491-3230
>>> Email: mlindsey at lb3law.com
>>> Website: www.lb3law.com
>>>
>>>
>>>
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
>>
>> ________________________________
>> This E-mail and any of its attachments may contain Time Warner Cable
>> proprietary information, which is privileged, confidential, or subject to
>> copyright belonging to Time Warner Cable. This E-mail is intended solely for
>> the use of the individual or entity to which it is addressed. If you are not
>> the intended recipient of this E-mail, you are hereby notified that any
>> dissemination, distribution, copying, or action taken in relation to the
>> contents of and attachments to this E-mail is strictly prohibited and may be
>> unlawful. If you have received this E-mail in error, please notify the
>> sender immediately and permanently delete the original and any copy of this
>> E-mail and any printout.

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.


From hannigan at gmail.com  Tue Feb 18 18:38:14 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Tue, 18 Feb 2014 18:38:14 -0500
Subject: [arin-ppml] Proposal 204 Submitted, Registry Accuracy Proposal
In-Reply-To: <5D46946D-2D9C-4851-946D-BD8706E5E2CF@arin.net>
References: <CAMDXq5POOHsz=gpMZqLVVPTE86w0hJp51+an=qS3fLTY0BwKXw@mail.gmail.com>
	<5D46946D-2D9C-4851-946D-BD8706E5E2CF@arin.net>
Message-ID: <CAMDXq5OyzpRQ6fYeVs+5+g0HsqRxvp0G+peh0SDXsFf7Wmh+zQ@mail.gmail.com>

On Sat, Feb 15, 2014 at 4:54 PM, John Curran <jcurran at arin.net> wrote:
> On Feb 15, 2014, at 3:15 PM, Martin Hannigan <hannigan at gmail.com> wrote:
>

[ clip ]


> Top priority at this point is a clear in-scope problem statement and
> suggested
> changes to existing policy text.   I will note that the policy development
> process
> is used for number resource policy and not ARIN business practices or
> services;
> the latter should be submitted to the ARIN consultation and suggestion
> process
> as they come under the fiduciary responsibilities of the ARIN Board of
> Trustees.

This is a bit confusing since "Principles" can be considered business
practice, they were designed to be used as a crutch to say no legacy
holders and deflect any responsibility for it to us. Which is a whole
new thread upon itself if we would like to debate that.

Here's the revision I think may work and allow you to do something 605 like:

ARARIRIRRIR Services to Legacy Internet Resource Holders

Problem Statement

The importance of maintaining accurate records in the ARIN database is
recognized as the Registries principal task and is not being debated.
The Registry is unable to responsibly fulfill this task. Many resource
holders are not incented through mutual benefits to participate in the
registry, the process or the community and instead operate
successfully outside of its bounds further hampering the mission of
accuracy.

Intent

To create a sustainable RIPE 605 environment in the ARIN region that
provides mutual benefits to legacy holders and ARIN and in support of
vastly improved and accurate registry service.

Policy Changes

Section 1, Adds to "Principles"

Accuracy

The principle of Accuracy guarantees stakeholders that all reasonable
and mutually beneficial steps will be take to insure that the Registry
is as accurate as possible.

Fairness

The principle of Fairness guarantees stakeholders that they will be
treated fairly with respect to whatever class of resources they hold,
whether they are pre or post RIR assigned addresses.

Value Add

The principle of Value Add guarantees that the Registry, in its effort
to insure that all of the principles are applied equitably, will seek
to add value to all resource holders regardless of class by insuring
such thing as rapid update functionalities and reasonably easy
transfer administration.

Mutual Benefit

The principle of Mutual Benefit guarantees that ARIN will enter into
or dissolve contracts related to legacy resource holders in like
fashion of comparable Registries.


Section 2, Adds to "Definitions"

Legacy Internet Resource

Any Internet Resource obtained prior to or otherwise outside the
current system of hierarchical distribution (by allocation or
assignment) through the Regional Internet Registries.

Legacy Internet Resource Holder

The holder of a Legacy Internet Resource. Either by receiving these
resources directly or by receiving (part of) Legacy Internet Resources
from a Legacy Internet Resource Holder.

Registry Service Element

In practice, any Legacy Resource Holder actually avails of a subset of
the Registry Services mentioned above. Where it is necessary to
distinguish between the entire class of Registry Services and the
specific Registry Services actually provided in a particular case, the
latter are described as Registry Service Elements.


Best,

-M<


From jcurran at arin.net  Tue Feb 18 22:13:37 2014
From: jcurran at arin.net (John Curran)
Date: Wed, 19 Feb 2014 03:13:37 +0000
Subject: [arin-ppml] Proposal 204 Submitted, Registry Accuracy Proposal
In-Reply-To: <CAMDXq5OyzpRQ6fYeVs+5+g0HsqRxvp0G+peh0SDXsFf7Wmh+zQ@mail.gmail.com>
References: <CAMDXq5POOHsz=gpMZqLVVPTE86w0hJp51+an=qS3fLTY0BwKXw@mail.gmail.com>
	<5D46946D-2D9C-4851-946D-BD8706E5E2CF@arin.net>
	<CAMDXq5OyzpRQ6fYeVs+5+g0HsqRxvp0G+peh0SDXsFf7Wmh+zQ@mail.gmail.com>
Message-ID: <164D1D76-B004-45BC-9B1A-74FDF7E85CAB@arin.net>

Marty - 
 
Thanks for working on this... it is looking much closer to an policy 
proposal.   I'll keep my remarks brief, simply to facilitate its 
consideration by the Advisory Council - 

On Feb 18, 2014, at 6:38 PM, Martin Hannigan <hannigan at gmail.com> wrote:
> This is a bit confusing since "Principles" can be considered business
> practice, they were designed to be used as a crutch to say no legacy
> holders and deflect any responsibility for it to us. Which is a whole
> new thread upon itself if we would like to debate that.

"Principles" for the registry inherently have an impact on registry services, 
but for avoidance of doubt, I do believe that we should include the full set
of principles in the policy proposal so as to allow discussion by the community.

> Here's the revision I think may work and allow you to do something 605 like:
> 
> ARARIRIRRIR Services to Legacy Internet Resource Holders
> 
> Problem Statement
> 
> The importance of maintaining accurate records in the ARIN database is
> recognized as the Registries principal task and is not being debated.
> The Registry is unable to responsibly fulfill this task. Many resource
> holders are not incented through mutual benefits to participate in the
> registry, the process or the community and instead operate
> successfully outside of its bounds further hampering the mission of
> accuracy.
> 
> Intent
> 
> To create a sustainable RIPE 605 environment in the ARIN region that
> provides mutual benefits to legacy holders and ARIN and in support of
> vastly improved and accurate registry service.

For sake of clarity, it would be good to explain the problem more fully
(and without reference to RIPE 605, as that has quite a bit of material 
including multiple registrant LIR relationships, etc.)

Perhaps augmenting what you have to say 'providing fairness, equity, 
and mutual benefit to all resource holders, legacy and non-legacy alike'
(or something to the effect)?   It's your call, but in the end it is 
the problem statement is that defines the problem being solved, so it
is fairly important to get specific.

Thanks again for your efforts!
/John

John Curran
President and CEO
ARIN



From mlindsey at lb3law.com  Tue Feb 18 23:07:45 2014
From: mlindsey at lb3law.com (Lindsey, Marc)
Date: Wed, 19 Feb 2014 04:07:45 +0000
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy Internet Resource
	Holders
Message-ID: <2d8efd6ff5c7409db7a872b6b363b110@BN1PR07MB022.namprd07.prod.outlook.com>

Hello John,

On Feb 17, 2014, at 5:30 PM you wrote:

"As noted earlier, RIPE 605 covers quite a bit of ground; could you be more specific about what specific policy changes you are seeking?"

I agree that RIPE 605 covers a lot of ground, and there are opportunities to improve it.  From my perspective, the core desirable policy points are as follows:


1.       Formal preservation and recognition of the pre-existing rights of legacy resource holders, including the right to be left alone by ARIN without risk that legacy resource holders' registration records will be altered or removed except when they request updates or changes.



2.       Codification of ARIN's commitment to maintain the existing registry records for legacy resources without regard to whether the holder of the legacy resource enters into a formal contractual relationship with ARIN for those legal resources.


3.       Allowing legacy holders to obtain certain registry services as members or paying non-members under a new class of contracts that offer differentiated rights, responsibilities and registry services based on the nature of the formal relationship selected (e.g., member or non-member registry contract).


4.       Offering entities that signed an LRSA or obtained legacy resources under RSA before the new policy is enacted an opportunity for a fresh look, giving them an equal opportunity to benefit from the flexibility of the new policy.

In addition, there are several items worth considering as the policy proposal is reviewed and revised for the ARIN community.  The following is my initial list:


1.       For legacy resources that have "no relationship" with the RIR, the policy states that the RIR "may update the related entries in the [RIR] database from time to time to correspond to the current actual situation."   I believe the policy should include some guiding criteria for when these updates may be made.



2.       The policy sets some minimum contractual requirements, but it does not provide any guidance on the form of the contracts or any limitations on their scope.  If the contracts are too onerous or one-sided, many legacy holders will continue to opt for the "no-relationship" status.  To avoid this outcome, the policy should be crafted to ensure that the contracts are minimally intrusive and reasonably balanced (as if an objectively reasonable legacy holder and ARIN actually negotiated the terms and conditions at arm's length).



3.       The 6 classes of legacy holder relationships could be streamlined considerably.



4.       Transfer polices are not expressly covered.  However, I believe the community should (again) reconsider whether needs justification is an appropriate pre-condition for ARIN to record in its registry database otherwise lawful conveyances / transfers between private parties (particularly after ARIN reaches its final phase of exhaustion).

-Marc

Marc Lindsey
Levine, Blaszak, Block & Boothby, LLP
2001 L Street, NW Suite 900
Washington, DC 20036
Office: (202) 857-2564
Mobile: (202) 491-3230
Email: mlindsey at lb3law.com<mailto:mlindsey at lb3law.com>
Website: www.lb3law.com<http://www.lb3law.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140219/280824a6/attachment.htm>

From jcurran at arin.net  Tue Feb 18 23:35:05 2014
From: jcurran at arin.net (John Curran)
Date: Wed, 19 Feb 2014 04:35:05 +0000
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy Internet
 Resource Holders
In-Reply-To: <2d8efd6ff5c7409db7a872b6b363b110@BN1PR07MB022.namprd07.prod.outlook.com>
References: <2d8efd6ff5c7409db7a872b6b363b110@BN1PR07MB022.namprd07.prod.outlook.com>
Message-ID: <8CE59EEE-3E2F-48FD-BCC8-F142155D6A31@arin.net>

On Feb 18, 2014, at 11:07 PM, Lindsey, Marc <mlindsey at lb3law.com<mailto:mlindsey at lb3law.com>> wrote:

Hello John,

On Feb 17, 2014, at 5:30 PM you wrote:

?As noted earlier, RIPE 605 covers quite a bit of ground; could you be more specific about what specific policy changes you are seeking??

I agree that RIPE 605 covers a lot of ground, and there are opportunities to improve it.  From my perspective, the core desirable policy points are as follows:


Marc -

   Thanks for the excellent delineation of desirable policy points from your perspective.
   It would be worthwhile to add those (not clearly contractual) into the discussion once
   we have a draft policy for discussion.

Thanks again!
/John

John Curran
President and CEO
ARIN

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

From mlindsey at lb3law.com  Wed Feb 19 01:36:17 2014
From: mlindsey at lb3law.com (Lindsey, Marc)
Date: Wed, 19 Feb 2014 06:36:17 +0000
Subject: [arin-ppml] FYI -- RIPE-605 Services to Legacy Internet
 Resource Holders
In-Reply-To: <8CE59EEE-3E2F-48FD-BCC8-F142155D6A31@arin.net>
References: <2d8efd6ff5c7409db7a872b6b363b110@BN1PR07MB022.namprd07.prod.outlook.com>
	<8CE59EEE-3E2F-48FD-BCC8-F142155D6A31@arin.net>
Message-ID: <18c4aaca5f9743338f205fe41978a420@BN1PR07MB022.namprd07.prod.outlook.com>

John,

If I can assist, please let me know.

-Marc

From: John Curran [mailto:jcurran at arin.net]
Sent: Tuesday, February 18, 2014 11:35 PM
To: Lindsey, Marc
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] FYI -- RIPE-605 Services to Legacy Internet Resource Holders

On Feb 18, 2014, at 11:07 PM, Lindsey, Marc <mlindsey at lb3law.com<mailto:mlindsey at lb3law.com>> wrote:


Hello John,

On Feb 17, 2014, at 5:30 PM you wrote:

"As noted earlier, RIPE 605 covers quite a bit of ground; could you be more specific about what specific policy changes you are seeking?"

I agree that RIPE 605 covers a lot of ground, and there are opportunities to improve it.  From my perspective, the core desirable policy points are as follows:


Marc -

   Thanks for the excellent delineation of desirable policy points from your perspective.
   It would be worthwhile to add those (not clearly contractual) into the discussion once
   we have a draft policy for discussion.

Thanks again!
/John

John Curran
President and CEO
ARIN

From: Lindsey, Marc
Sent: Tuesday, February 18, 2014 11:08 PM
To: 'John Curran'
Cc: 'arin-ppml at arin.net'
Subject: FYI -- RIPE-605 Services to Legacy Internet Resource Holders

Hello John,

On Feb 17, 2014, at 5:30 PM you wrote:

"As noted earlier, RIPE 605 covers quite a bit of ground; could you be more specific about what specific policy changes you are seeking?"

I agree that RIPE 605 covers a lot of ground, and there are opportunities to improve it.  From my perspective, the core desirable policy points are as follows:


1.       Formal preservation and recognition of the pre-existing rights of legacy resource holders, including the right to be left alone by ARIN without risk that legacy resource holders' registration records will be altered or removed except when they request updates or changes.

2.       Codification of ARIN's commitment to maintain the existing registry records for legacy resources without regard to whether the holder of the legacy resource enters into a formal contractual relationship with ARIN for those legal resources.

3.       Allowing legacy holders to obtain certain registry services as members or paying non-members under a new class of contracts that offer differentiated rights, responsibilities and registry services based on the nature of the formal relationship selected (e.g., member or non-member registry contract).

4.       Offering entities that signed an LRSA or obtained legacy resources under RSA before the new policy is enacted an opportunity for a fresh look, giving them an equal opportunity to benefit from the flexibility of the new policy.

In addition, there are several items worth considering as the policy proposal is reviewed and revised for the ARIN community.  The following is my initial list:


1.       For legacy resources that have "no relationship" with the RIR, the policy states that the RIR "may update the related entries in the [RIR] database from time to time to correspond to the current actual situation."   I believe the policy should include some guiding criteria for when these updates may be made.

2.       The policy sets some minimum contractual requirements, but it does not provide any guidance on the form of the contracts or any limitations on their scope.  If the contracts are too onerous or one-sided, many legacy holders will continue to opt for the "no-relationship" status.  To avoid this outcome, the policy should be crafted to ensure that the contracts are minimally intrusive and reasonably balanced (as if an objectively reasonable legacy holder and ARIN actually negotiated the terms and conditions at arm's length).

3.       The 6 classes of legacy holder relationships could be streamlined considerably.

4.       Transfer policies are not expressly covered.  However, I believe the community should (again) reconsider whether needs justification is an appropriate pre-condition for ARIN to record in its registry database otherwise lawful conveyances / transfers between private parties (particularly after ARIN reaches its final phase of exhaustion).

-Marc

Marc Lindsey
Levine, Blaszak, Block & Boothby, LLP
2001 L Street, NW Suite 900
Washington, DC 20036
Office: (202) 857-2564
Mobile: (202) 491-3230
Email: mlindsey at lb3law.com<mailto:mlindsey at lb3law.com>
Website: www.lb3law.com<http://www.lb3law.com>

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

From hannigan at gmail.com  Thu Feb 20 14:16:23 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Thu, 20 Feb 2014 14:16:23 -0500
Subject: [arin-ppml] Update to Prop 203
Message-ID: <CAMDXq5NhjJANcgctz3YfrRvJuivLSo8Gk0MjP5vAtLP+m1YPiA@mail.gmail.com>

Einar,

Please update Section 203 Proposal with:



Problem Statement

The importance of maintaining accurate records in the ARIN database is
recognized as the Registries principal task and is not being debated.
The Registry is unable to responsibly fulfill this task. Many resource
holders are not incented through mutual benefits to participate in the
registry, the process or the community and instead operate
successfully outside of its bounds further hampering the mission of
accuracy.

Intent

To create a sustainable RIPE 605-like environment in the ARIN region that
provides mutual benefits to legacy holders and ARIN and in support of
vastly improved and accurate registry service.

Policy Changes

Section 1, Adds to "Principles"

Accuracy

The principle of Accuracy guarantees stakeholders that all reasonable
and mutually beneficial steps will be take to insure that the Registry
is as accurate as possible.

Fairness

The principle of Fairness guarantees stakeholders that they will be
treated fairly with respect to whatever class of resources they hold,
whether they are pre or post RIR assigned addresses.

Value Add

The principle of Value Add guarantees that the Registry, in its effort
to insure that all of the principles are applied equitably, will seek
to add value to all resource holders regardless of class by insuring
such thing as rapid update functionalities and reasonably easy
transfer administration.

Mutual Benefit

The principle of Mutual Benefit guarantees that ARIN will enter into
or dissolve contracts related to legacy resource holders in like
fashion of comparable Registries.


Section 2, Adds to "Definitions"

Legacy Internet Resource

Any Internet Resource obtained prior to or otherwise outside the
current system of hierarchical distribution (by allocation or
assignment) through the Regional Internet Registries.

Legacy Internet Resource Holder

The holder of a Legacy Internet Resource. Either by receiving these
resources directly or by receiving (part of) Legacy Internet Resources
from a Legacy Internet Resource Holder.

Registry Service Element

In practice, any Legacy Resource Holder actually avails of a subset of
the Registry Services mentioned above. Where it is necessary to
distinguish between the entire class of Registry Services and the
specific Registry Services actually provided in a particular case, the
latter are described as Registry Service Elements.


From narten at us.ibm.com  Fri Feb 21 00:53:02 2014
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 21 Feb 2014 00:53:02 -0500
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201402210553.s1L5r2Sh013158@rotala.raleigh.ibm.com>

Total of 33 messages in the last 7 days.
 
script run at: Fri Feb 21 00:53:02 EST 2014
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 33.33% |   11 | 22.14% |   102922 | jcurran at arin.net
 24.24% |    8 | 18.42% |    85630 | hannigan at gmail.com
  9.09% |    3 | 19.83% |    92205 | mlindsey at lb3law.com
  9.09% |    3 | 13.33% |    61983 | john.sweeting at twcable.com
  6.06% |    2 | 10.25% |    47633 | snoble at sonn.com
  6.06% |    2 |  4.30% |    19979 | drc at virtualized.org
  3.03% |    1 |  3.65% |    16949 | scottleibrand at gmail.com
  3.03% |    1 |  3.35% |    15553 | keith at jcc.com
  3.03% |    1 |  3.06% |    14222 | sryerse at eclipse-networks.com
  3.03% |    1 |  1.68% |     7822 | narten at us.ibm.com
--------+------+--------+----------+------------------------
100.00% |   33 |100.00% |   464898 | Total



From billdarte at gmail.com  Fri Feb 21 11:53:12 2014
From: billdarte at gmail.com (Bill Darte)
Date: Fri, 21 Feb 2014 10:53:12 -0600
Subject: [arin-ppml] ARIN Draft Policy 2014-2 Improving 8.4 Anti-Flip
	Language
Message-ID: <CAMApp34bqyS=uQETQXsabBsO16x+TLz2qZfCMU+9WDkjFcmkkA@mail.gmail.com>

At the Advisory Council's meeting of Feb 20, discussion about Draft Policy
2014-2 concluded that there is a real issue with transfer restrictions of
address blocks between RIR jurisdictions for organizations having received
a different block of addresses from ARIN within the last 12 months (per
existing policy).

The current Draft Policy language is as follows with only the last sentence
being added from what is current ARIN policy:
"Source entities within the ARIN region must not have received a transfer,
allocation, or assignment of IPv4 number resources from ARIN for the 12
months prior to the approval of a transfer request. This restriction does
not include M&A transfers. Restrictions related to recent receipt of blocks
shall not apply to inter-RIR transfers within the same organization and its
subsidiaries."

The last sentence of this language was added to mitigate the problems
related by the author in the problem statement and from experience. The
author supported this change, however, some concern has been expressed on
the PPML and within the AC about the possibility of 'rinse and repeat'
abuse associated with the ease of establishing new subsidiaries and using
those transfers to get around the restrictions of the existing transfer
policy.

Three alternatives were primarily discussed and I wish to elicit feedback
from the community relative to each.

1. Use the existing last sentence as is and ask ARIN staff to be
particularly watchful for seeming abuse and to bring such back to the
community through regular Policy Experience Reports.  There was discussion
about this option suggesting that by the time abuse was recognized and
reported, and given limited existing free pool stocks and the extended
policy development cycle....this option may be moot.

2. Remove the clause 'and its subsidiaries' or modify it in such a way as
to mitigate the risk of a laundering of addresses through fraudulent
transfers, but this may still potentially limit the utility to
organizations who may have complex organizational structures in use
internationally.

3. Take an alternative tack and simply restrict transfers on a per-block
rather than a per-organization basis. e.g. 'No block acquired within the
past 24 months would be eligible for transfer.' (The time frame is of
course an arbitrary number at this point.)

If you believe this Draft Policy is improved most significantly by one of
the above alternatives, or through another alternative you can pose....I,
and the community would benefit from your input. Thanks,

Bill Darte
Policy Shepherd for 2014-2 and
Advisory Council member
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140221/77d17c87/attachment.htm>

From gdendy at equinix.com  Sat Feb 22 00:20:54 2014
From: gdendy at equinix.com (Greg Dendy)
Date: Fri, 21 Feb 2014 21:20:54 -0800
Subject: [arin-ppml] NANOG 61 - Bellevue - Call For Presentations is open!
Message-ID: <5A388661-CDD4-4146-9F99-9EFD1ACAE3AE@equinix.com>

NANOG Community-

I hope everyone enjoyed NANOG 60, NANOG?s largest attended winter meeting.  Fresh off a great meeting, and post our NANOG Icelanta Reception, we are ready start the process for NANOG 61 in Bellevue.  NANOG 61 will be NANOG?s 20th year serving the network operator community and helping to make the Internet better.    If you have a topic you'd like to speak about, the program committee would love to consider it.  Please read http://www.nanog.org/meetings/nanog61/callforpresentations for more information.

We will continue with the Monday-Wednesday format, with Tracks on Monday and Wednesday afternoons and Tutorials to be scheduled on Tuesday morning.  The program will begin on Monday morning at 10:00AM followed by our popular Newcomers Lunch.  The exact schedule layout can be found at http://www.nanog.org/meetings/nanog60/preagenda, please take this into account as you plan travel.  If you wish to submit a presentation, please keep these important dates in mind:

 *   Presentation Abstracts and Draft Slides Due:          April 7, 2014
 *   Slides Due:                                                               May 5, 2014
 *   Topic List Posted:                                                          April 21, 2014
 *   Agenda Published:                                                       May 12, 2014

Please submit your materials to http://pc.nanog.org<http://pc.nanog.org/>.

Looking forward to seeing everyone in Bellevue!

Thanks,

Greg Dendy
Chair, NANOG Program Committee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140221/e08292a6/attachment.htm>

From owen at delong.com  Sat Feb 22 18:06:22 2014
From: owen at delong.com (Owen DeLong)
Date: Sat, 22 Feb 2014 15:06:22 -0800
Subject: [arin-ppml] 2014-2 8.4 Anti-flip Language
Message-ID: <2CB940E2-1465-4FED-A6F3-7172849A90EA@delong.com>

Several options are being discussed regarding this proposal:

1. Use the existing last sentence as is and ask ARIN staff to be particularly watchful for seeming abuse and to bring such back to the community through regular Policy Experience Reports.  There was discussion about this option suggesting that by the time abuse was recognized and reported, and given limited existing free pool stocks and the extended policy development cycle....this option is mute.

2. Remove the clause 'and its subsidiaries' and or modify it in such a way as to mitigate the risk of a laundering of addresses through fraudulent transfers, but potentially limit the utility of organizations who may have complex organizations structures in use internationally.

3. Take an alternative tack and simply restrict the Inter-RIR re-org transfer of the 'recently issued block' only, allowing other existing blocks to be transferred without restriction by recent block acquisition. This alternative seems to have been expressed and supported in the recent Atlanta Public Policy Consultation.

It is my opinion that option 3 is perilous in that it allows a large resource holder to sell off their address space out of region while backfilling from the ARIN free pool.

As such, I am much more comfortable with option 2. One set of language that was suggested which I like is:

??subsidiaries having been operational for a minimum of 18 months.?

While this might not prevent all possible subsidiary-based rinse-repeat abuse scenarios, it would at least prevent the obvious subsidiary created for this purpose scenario and certainly provides better protections than proposal number 3.

I think option 1 is probably an unfair burden for the ARIN staff and makes policy vague in a way that would be difficult, if not impossible, to reliably enforce and may be even harder to defend in the event of litigation. This is strictly my own opinion as a member of the community and I have not discussed the matter with legal council or even the other members of the AC.

Owen

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

From scottleibrand at gmail.com  Sat Feb 22 18:28:16 2014
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Sat, 22 Feb 2014 15:28:16 -0800
Subject: [arin-ppml] 2014-2 8.4 Anti-flip Language
In-Reply-To: <2CB940E2-1465-4FED-A6F3-7172849A90EA@delong.com>
References: <2CB940E2-1465-4FED-A6F3-7172849A90EA@delong.com>
Message-ID: <CAGkMwz5HKPdCJBvXWRpvx2Uys0NJ6=TCDLTpszeJWg6V90vsXA@mail.gmail.com>

There is another restriction already in 8.3, which reads "The source entity
will be ineligible to receive any further IPv4 address allocations or
assignments from ARIN for a period of 12 months after a transfer approval,
or until the exhaustion of ARIN's IPv4 space, whichever occurs first."  In
light of that, do you still see a problem with #3?

-Scott


On Sat, Feb 22, 2014 at 3:06 PM, Owen DeLong <owen at delong.com> wrote:

> Several options are being discussed regarding this proposal:
>
>>
> 1. Use the existing last sentence as is and ask ARIN staff to be
> particularly watchful for seeming abuse and to bring such back to the
> community through regular Policy Experience Reports.  There was discussion
> about this option suggesting that by the time abuse was recognized and
> reported, and given limited existing free pool stocks and the extended
> policy development cycle....this option is mute.
>
> 2. Remove the clause 'and its subsidiaries' and or modify it in such a way
> as to mitigate the risk of a laundering of addresses through fraudulent
> transfers, but potentially limit the utility of organizations who may have
> complex organizations structures in use internationally.
>
> 3. Take an alternative tack and simply restrict the Inter-RIR re-org
> transfer of the 'recently issued block' only, allowing other existing
> blocks to be transferred without restriction by recent block acquisition.
> This alternative seems to have been expressed and supported in the recent
> Atlanta Public Policy Consultation.
>
>
> It is my opinion that option 3 is perilous in that it allows a large
> resource holder to sell off their address space out of region while
> backfilling from the ARIN free pool.
>
> As such, I am much more comfortable with option 2. One set of language
> that was suggested which I like is:
>
> "...subsidiaries having been operational for a minimum of 18 months."
>
> While this might not prevent all possible subsidiary-based rinse-repeat
> abuse scenarios, it would at least prevent the obvious subsidiary created
> for this purpose scenario and certainly provides better protections than
> proposal number 3.
>
> I think option 1 is probably an unfair burden for the ARIN staff and makes
> policy vague in a way that would be difficult, if not impossible, to
> reliably enforce and may be even harder to defend in the event of
> litigation. This is strictly my own opinion as a member of the community
> and I have not discussed the matter with legal council or even the other
> members of the AC.
>
> 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/20140222/8f1ef2a4/attachment.htm>

From billdarte at gmail.com  Sat Feb 22 19:24:16 2014
From: billdarte at gmail.com (Bill Darte)
Date: Sat, 22 Feb 2014 18:24:16 -0600
Subject: [arin-ppml] 2014-2 8.4 Anti-flip Language
In-Reply-To: <CAGkMwz5HKPdCJBvXWRpvx2Uys0NJ6=TCDLTpszeJWg6V90vsXA@mail.gmail.com>
References: <2CB940E2-1465-4FED-A6F3-7172849A90EA@delong.com>
	<CAGkMwz5HKPdCJBvXWRpvx2Uys0NJ6=TCDLTpszeJWg6V90vsXA@mail.gmail.com>
Message-ID: <CAMApp353i3gfRYkKXp=vwk9oX4-tbbFynMYyYj8DWA8H75kbWA@mail.gmail.com>

Thanks to Owen and Scott for beginning a conversation about this Draft.
Scott....given the other restriction that you reference, do you prefer one
alternative over another....does the addition of an operational time frame
associated with option #2 improve its ability to accomplish the problem
statement.....

"Source entities within the ARIN region must not have received a transfer,
allocation, or assignment of IPv4 number resources from ARIN for the 12
months prior to the approval of a transfer request. This restriction does
not include M&A transfers."

This accidentally prevents anyone who receives BLOCK A in 2014 from
transferring to another RIR a different block, BLOCK B, which was issued 5,
10, 15, 20 years ago. In my company, we needed to move a block being used
in Asia over to APNIC. The block was legacy. But because we had gotten a
new block in 2013, we were prevented from moving the old block to a
different RIR."

bd


On Sat, Feb 22, 2014 at 5:28 PM, Scott Leibrand <scottleibrand at gmail.com>wrote:

> There is another restriction already in 8.3, which reads "The source
> entity will be ineligible to receive any further IPv4 address allocations
> or assignments from ARIN for a period of 12 months after a transfer
> approval, or until the exhaustion of ARIN's IPv4 space, whichever occurs
> first."  In light of that, do you still see a problem with #3?
>
> -Scott
>
>
> On Sat, Feb 22, 2014 at 3:06 PM, Owen DeLong <owen at delong.com> wrote:
>
>> Several options are being discussed regarding this proposal:
>>
>>>
>> 1. Use the existing last sentence as is and ask ARIN staff to be
>> particularly watchful for seeming abuse and to bring such back to the
>> community through regular Policy Experience Reports.  There was discussion
>> about this option suggesting that by the time abuse was recognized and
>> reported, and given limited existing free pool stocks and the extended
>> policy development cycle....this option is mute.
>>
>> 2. Remove the clause 'and its subsidiaries' and or modify it in such a
>> way as to mitigate the risk of a laundering of addresses through fraudulent
>> transfers, but potentially limit the utility of organizations who may have
>> complex organizations structures in use internationally.
>>
>> 3. Take an alternative tack and simply restrict the Inter-RIR re-org
>> transfer of the 'recently issued block' only, allowing other existing
>> blocks to be transferred without restriction by recent block acquisition.
>> This alternative seems to have been expressed and supported in the recent
>> Atlanta Public Policy Consultation.
>>
>>
>> It is my opinion that option 3 is perilous in that it allows a large
>> resource holder to sell off their address space out of region while
>> backfilling from the ARIN free pool.
>>
>> As such, I am much more comfortable with option 2. One set of language
>> that was suggested which I like is:
>>
>> "...subsidiaries having been operational for a minimum of 18 months."
>>
>> While this might not prevent all possible subsidiary-based rinse-repeat
>> abuse scenarios, it would at least prevent the obvious subsidiary created
>> for this purpose scenario and certainly provides better protections than
>> proposal number 3.
>>
>> I think option 1 is probably an unfair burden for the ARIN staff and
>> makes policy vague in a way that would be difficult, if not impossible, to
>> reliably enforce and may be even harder to defend in the event of
>> litigation. This is strictly my own opinion as a member of the community
>> and I have not discussed the matter with legal council or even the other
>> members of the AC.
>>
>> 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.
>>
>
>
> _______________________________________________
> 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/20140222/b6b69ef3/attachment.htm>

From owen at delong.com  Sat Feb 22 23:42:35 2014
From: owen at delong.com (Owen DeLong)
Date: Sat, 22 Feb 2014 20:42:35 -0800
Subject: [arin-ppml] 2014-2 8.4 Anti-flip Language
In-Reply-To: <CAGkMwz5HKPdCJBvXWRpvx2Uys0NJ6=TCDLTpszeJWg6V90vsXA@mail.gmail.com>
References: <2CB940E2-1465-4FED-A6F3-7172849A90EA@delong.com>
	<CAGkMwz5HKPdCJBvXWRpvx2Uys0NJ6=TCDLTpszeJWg6V90vsXA@mail.gmail.com>
Message-ID: <D83E9DD2-07F5-4F73-B705-A171B3F47FA0@delong.com>

It makes option 3 slightly more palatable, but I would still prefer option 2 as described below.

Owen

On Feb 22, 2014, at 3:28 PM, Scott Leibrand <scottleibrand at gmail.com> wrote:

> There is another restriction already in 8.3, which reads "The source entity will be ineligible to receive any further IPv4 address allocations or assignments from ARIN for a period of 12 months after a transfer approval, or until the exhaustion of ARIN's IPv4 space, whichever occurs first."  In light of that, do you still see a problem with #3?
> 
> -Scott
> 
> 
> On Sat, Feb 22, 2014 at 3:06 PM, Owen DeLong <owen at delong.com> wrote:
> Several options are being discussed regarding this proposal:
> 
> 1. Use the existing last sentence as is and ask ARIN staff to be particularly watchful for seeming abuse and to bring such back to the community through regular Policy Experience Reports.  There was discussion about this option suggesting that by the time abuse was recognized and reported, and given limited existing free pool stocks and the extended policy development cycle....this option is mute.
> 
> 2. Remove the clause 'and its subsidiaries' and or modify it in such a way as to mitigate the risk of a laundering of addresses through fraudulent transfers, but potentially limit the utility of organizations who may have complex organizations structures in use internationally.
> 
> 3. Take an alternative tack and simply restrict the Inter-RIR re-org transfer of the 'recently issued block' only, allowing other existing blocks to be transferred without restriction by recent block acquisition. This alternative seems to have been expressed and supported in the recent Atlanta Public Policy Consultation.
> 
> It is my opinion that option 3 is perilous in that it allows a large resource holder to sell off their address space out of region while backfilling from the ARIN free pool.
> 
> As such, I am much more comfortable with option 2. One set of language that was suggested which I like is:
> 
> ??subsidiaries having been operational for a minimum of 18 months.?
> 
> While this might not prevent all possible subsidiary-based rinse-repeat abuse scenarios, it would at least prevent the obvious subsidiary created for this purpose scenario and certainly provides better protections than proposal number 3.
> 
> I think option 1 is probably an unfair burden for the ARIN staff and makes policy vague in a way that would be difficult, if not impossible, to reliably enforce and may be even harder to defend in the event of litigation. This is strictly my own opinion as a member of the community and I have not discussed the matter with legal council or even the other members of the AC.
> 
> 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/20140222/fd0b8863/attachment.htm>

From rudi.daniel at gmail.com  Sun Feb 23 11:50:06 2014
From: rudi.daniel at gmail.com (Rudolph Daniel)
Date: Sun, 23 Feb 2014 12:50:06 -0400
Subject: [arin-ppml] update section 203 proposal
In-Reply-To: <CA+uaoiXvTCDKuh40Q0=YAsq=B1XM+2+L6E6bEMzk=RCou_oueQ@mail.gmail.com>
References: <CA+uaoiXvTCDKuh40Q0=YAsq=B1XM+2+L6E6bEMzk=RCou_oueQ@mail.gmail.com>
Message-ID: <CA+uaoiWb0rPMxTjXkwFFQ6u858K8DVeYX3EKz1xmMMkF9i+KKA@mail.gmail.com>

This may seem a stupid question, but since we now want to accept that
accuracy is a principle task of registries, what measure are we to use as
an acceptable measure of an accurate 'whois' or at the macro level, ' an
accurate registry service' ?......% of legacy holders participating on the
registry?

Rudi Daniel
(information technologist)
784 430 9235
On Feb 22, 2014 7:10 PM, <arin-ppml-request at arin.net> wrote:

Send ARIN-PPML mailing list submissions to
        arin-ppml at arin.net

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.arin.net/mailman/listinfo/arin-ppml
or, via email, send a message with subject or body 'help' to
        arin-ppml-request at arin.net

You can reach the person managing the list at
        arin-ppml-owner at arin.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of ARIN-PPML digest..."


Today's Topics:

   1. Update to Prop 203 (Martin Hannigan)
   2. Weekly posting summary for ppml at arin.net (Thomas Narten)
   3. ARIN Draft Policy 2014-2 Improving 8.4 Anti-Flip  Language
      (Bill Darte)
   4. NANOG 61 - Bellevue - Call For Presentations is open! (Greg Dendy)
   5. 2014-2 8.4 Anti-flip Language (Owen DeLong)


----------------------------------------------------------------------

Message: 1
Date: Thu, 20 Feb 2014 14:16:23 -0500
From: Martin Hannigan <hannigan at gmail.com>
To: Public Policy Mailing List <ppml at arin.net>
Subject: [arin-ppml] Update to Prop 203
Message-ID:
        <CAMDXq5NhjJANcgctz3YfrRvJuivLSo8Gk0MjP5vAtLP+m1YPiA at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Einar,

Please update Section 203 Proposal with:



Problem Statement

The importance of maintaining accurate records in the ARIN database is
recognized as the Registries principal task and is not being debated.
The Registry is unable to responsibly fulfill this task. Many resource
holders are not incented through mutual benefits to participate in the
registry, the process or the community and instead operate
successfully outside of its bounds further hampering the mission of
accuracy.

Intent

To create a sustainable RIPE 605-like environment in the ARIN region that
provides mutual benefits to legacy holders and ARIN and in support of
vastly improved and accurate registry service.

Policy Changes

Section 1, Adds to "Principles"

Accuracy

The principle of Accuracy guarantees stakeholders that all reasonable
and mutually beneficial steps will be take to insure that the Registry
is as accurate as possible.

Fairness

The principle of Fairness guarantees stakeholders that they will be
treated fairly with respect to whatever class of resources they hold,
whether they are pre or post RIR assigned addresses.

Value Add

The principle of Value Add guarantees that the Registry, in its effort
to insure that all of the principles are applied equitably, will seek
to add value to all resource holders regardless of class by insuring
such thing as rapid update functionalities and reasonably easy
transfer administration.

Mutual Benefit

The principle of Mutual Benefit guarantees that ARIN will enter into
or dissolve contracts related to legacy resource holders in like
fashion of comparable Registries.


Section 2, Adds to "Definitions"

Legacy Internet Resource

Any Internet Resource obtained prior to or otherwise outside the
current system of hierarchical distribution (by allocation or
assignment) through the Regional Internet Registries.

Legacy Internet Resource Holder

The holder of a Legacy Internet Resource. Either by receiving these
resources directly or by receiving (part of) Legacy Internet Resources
from a Legacy Internet Resource Holder.

Registry Service Element

In practice, any Legacy Resource Holder actually avails of a subset of
the Registry Services mentioned above. Where it is necessary to
distinguish between the entire class of Registry Services and the
specific Registry Services actually provided in a particular case, the
latter are described as Registry Service Elements.


------------------------------

Message: 2
Date: Fri, 21 Feb 2014 00:53:02 -0500
From: Thomas Narten <narten at us.ibm.com>
To: arin-ppml at arin.net
Subject: [arin-ppml] Weekly posting summary for ppml at arin.net
Message-ID: <201402210553.s1L5r2Sh013158 at rotala.raleigh.ibm.com>
Content-Type: text/plain; charset=us-ascii

Total of 33 messages in the last 7 days.

script run at: Fri Feb 21 00:53:02 EST 2014

    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 33.33% |   11 | 22.14% |   102922 | jcurran at arin.net
 24.24% |    8 | 18.42% |    85630 | hannigan at gmail.com
  9.09% |    3 | 19.83% |    92205 | mlindsey at lb3law.com
  9.09% |    3 | 13.33% |    61983 | john.sweeting at twcable.com
  6.06% |    2 | 10.25% |    47633 | snoble at sonn.com
  6.06% |    2 |  4.30% |    19979 | drc at virtualized.org
  3.03% |    1 |  3.65% |    16949 | scottleibrand at gmail.com
  3.03% |    1 |  3.35% |    15553 | keith at jcc.com
  3.03% |    1 |  3.06% |    14222 | sryerse at eclipse-networks.com
  3.03% |    1 |  1.68% |     7822 | narten at us.ibm.com
--------+------+--------+----------+------------------------
100.00% |   33 |100.00% |   464898 | Total



------------------------------

Message: 3
Date: Fri, 21 Feb 2014 10:53:12 -0600
From: Bill Darte <billdarte at gmail.com>
To: "arin-ppml at arin.net" <arin-ppml at arin.net>
Subject: [arin-ppml] ARIN Draft Policy 2014-2 Improving 8.4 Anti-Flip
        Language
Message-ID:
        <CAMApp34bqyS=uQETQXsabBsO16x+TLz2qZfCMU+9WDkjFcmkkA at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

At the Advisory Council's meeting of Feb 20, discussion about Draft Policy
2014-2 concluded that there is a real issue with transfer restrictions of
address blocks between RIR jurisdictions for organizations having received
a different block of addresses from ARIN within the last 12 months (per
existing policy).

The current Draft Policy language is as follows with only the last sentence
being added from what is current ARIN policy:
"Source entities within the ARIN region must not have received a transfer,
allocation, or assignment of IPv4 number resources from ARIN for the 12
months prior to the approval of a transfer request. This restriction does
not include M&A transfers. Restrictions related to recent receipt of blocks
shall not apply to inter-RIR transfers within the same organization and its
subsidiaries."

The last sentence of this language was added to mitigate the problems
related by the author in the problem statement and from experience. The
author supported this change, however, some concern has been expressed on
the PPML and within the AC about the possibility of 'rinse and repeat'
abuse associated with the ease of establishing new subsidiaries and using
those transfers to get around the restrictions of the existing transfer
policy.

Three alternatives were primarily discussed and I wish to elicit feedback
from the community relative to each.

1. Use the existing last sentence as is and ask ARIN staff to be
particularly watchful for seeming abuse and to bring such back to the
community through regular Policy Experience Reports.  There was discussion
about this option suggesting that by the time abuse was recognized and
reported, and given limited existing free pool stocks and the extended
policy development cycle....this option may be moot.

2. Remove the clause 'and its subsidiaries' or modify it in such a way as
to mitigate the risk of a laundering of addresses through fraudulent
transfers, but this may still potentially limit the utility to
organizations who may have complex organizational structures in use
internationally.

3. Take an alternative tack and simply restrict transfers on a per-block
rather than a per-organization basis. e.g. 'No block acquired within the
past 24 months would be eligible for transfer.' (The time frame is of
course an arbitrary number at this point.)

If you believe this Draft Policy is improved most significantly by one of
the above alternatives, or through another alternative you can pose....I,
and the community would benefit from your input. Thanks,

Bill Darte
Policy Shepherd for 2014-2 and
Advisory Council member
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.arin.net/pipermail/arin-ppml/attachments/20140221/77d17c87/attachment-0001.html
>

------------------------------

Message: 4
Date: Fri, 21 Feb 2014 21:20:54 -0800
From: Greg Dendy <gdendy at equinix.com>
To: "North American Network Operators' Group" <nanog at nanog.org>,
        "nanog-announce at nanog.org" <nanog-announce at nanog.org>,
        "arin-ppml at arin.net"    <arin-ppml at arin.net>, "ripe-list at ripe.net"
        <ripe-list at ripe.net>
Cc: NANOG Program Committee <nanogpc at nanog.org>,        "board at nanog.org"
        <board at nanog.org>
Subject: [arin-ppml] NANOG 61 - Bellevue - Call For Presentations is
        open!
Message-ID: <5A388661-CDD4-4146-9F99-9EFD1ACAE3AE at equinix.com>
Content-Type: text/plain; charset="windows-1252"

NANOG Community-

I hope everyone enjoyed NANOG 60, NANOG?s largest attended winter meeting.
 Fresh off a great meeting, and post our NANOG Icelanta Reception, we are
ready start the process for NANOG 61 in Bellevue.  NANOG 61 will be NANOG?s
20th year serving the network operator community and helping to make the
Internet better.    If you have a topic you'd like to speak about, the
program committee would love to consider it.  Please read
http://www.nanog.org/meetings/nanog61/callforpresentations for more
information.

We will continue with the Monday-Wednesday format, with Tracks on Monday
and Wednesday afternoons and Tutorials to be scheduled on Tuesday morning.
 The program will begin on Monday morning at 10:00AM followed by our
popular Newcomers Lunch.  The exact schedule layout can be found at
http://www.nanog.org/meetings/nanog60/preagenda, please take this into
account as you plan travel.  If you wish to submit a presentation, please
keep these important dates in mind:

 *   Presentation Abstracts and Draft Slides Due:          April 7, 2014
 *   Slides Due:
    May 5, 2014
 *   Topic List Posted:
     April 21, 2014
 *   Agenda Published:
  May 12, 2014

Please submit your materials to http://pc.nanog.org<http://pc.nanog.org/>.

Looking forward to seeing everyone in Bellevue!

Thanks,

Greg Dendy
Chair, NANOG Program Committee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.arin.net/pipermail/arin-ppml/attachments/20140221/e08292a6/attachment-0001.html
>

------------------------------

Message: 5
Date: Sat, 22 Feb 2014 15:06:22 -0800
From: Owen DeLong <owen at delong.com>
To: ARIN-PPML List <arin-ppml at arin.net>
Subject: [arin-ppml] 2014-2 8.4 Anti-flip Language
Message-ID: <2CB940E2-1465-4FED-A6F3-7172849A90EA at delong.com>
Content-Type: text/plain; charset="windows-1252"

Several options are being discussed regarding this proposal:

1. Use the existing last sentence as is and ask ARIN staff to be
particularly watchful for seeming abuse and to bring such back to the
community through regular Policy Experience Reports.  There was discussion
about this option suggesting that by the time abuse was recognized and
reported, and given limited existing free pool stocks and the extended
policy development cycle....this option is mute.

2. Remove the clause 'and its subsidiaries' and or modify it in such a way
as to mitigate the risk of a laundering of addresses through fraudulent
transfers, but potentially limit the utility of organizations who may have
complex organizations structures in use internationally.

3. Take an alternative tack and simply restrict the Inter-RIR re-org
transfer of the 'recently issued block' only, allowing other existing
blocks to be transferred without restriction by recent block acquisition.
This alternative seems to have been expressed and supported in the recent
Atlanta Public Policy Consultation.

It is my opinion that option 3 is perilous in that it allows a large
resource holder to sell off their address space out of region while
backfilling from the ARIN free pool.

As such, I am much more comfortable with option 2. One set of language that
was suggested which I like is:

??subsidiaries having been operational for a minimum of 18 months.?

While this might not prevent all possible subsidiary-based rinse-repeat
abuse scenarios, it would at least prevent the obvious subsidiary created
for this purpose scenario and certainly provides better protections than
proposal number 3.

I think option 1 is probably an unfair burden for the ARIN staff and makes
policy vague in a way that would be difficult, if not impossible, to
reliably enforce and may be even harder to defend in the event of
litigation. This is strictly my own opinion as a member of the community
and I have not discussed the matter with legal council or even the other
members of the AC.

Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.arin.net/pipermail/arin-ppml/attachments/20140222/ebff8f89/attachment.html
>

------------------------------

_______________________________________________
ARIN-PPML mailing list
ARIN-PPML at arin.net
http://lists.arin.net/mailman/listinfo/arin-ppml

End of ARIN-PPML Digest, Vol 104, Issue 41
******************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140223/8a1e01a5/attachment.htm>

From jcurran at arin.net  Sun Feb 23 13:35:02 2014
From: jcurran at arin.net (John Curran)
Date: Sun, 23 Feb 2014 18:35:02 +0000
Subject: [arin-ppml] update section 203 proposal
In-Reply-To: <CA+uaoiWb0rPMxTjXkwFFQ6u858K8DVeYX3EKz1xmMMkF9i+KKA@mail.gmail.com>
References: <CA+uaoiXvTCDKuh40Q0=YAsq=B1XM+2+L6E6bEMzk=RCou_oueQ@mail.gmail.com>
	<CA+uaoiWb0rPMxTjXkwFFQ6u858K8DVeYX3EKz1xmMMkF9i+KKA@mail.gmail.com>
Message-ID: <A831E5D9-801F-43F0-B828-76046D324C69@arin.net>

On Feb 23, 2014, at 11:50 AM, Rudolph Daniel <rudi.daniel at gmail.com<mailto:rudi.daniel at gmail.com>> wrote:

This may seem a stupid question, but since we now want to accept that accuracy is a principle task of registries, what measure are we to use as an acceptable measure of an accurate 'whois' or at the macro level, ' an accurate registry service' ?......% of legacy holders participating on the registry?

It's actually a fairly complicated question, since there are many legacy holder who already
participate in the registry and update their resources (e.g. abuse contact, DNS servers)
without any formal contractual relationship with ARIN.  In any case, individual legacy holders
are unlikely to be the major contributor of inaccuracy in the registry when compared to those
parties who fail to update the registry with their reassignment information (despite the
requirement to do so per NRPM 4.2.3.7.)

We do know that many folks are quite good about making updates before they request
more IPv4 space, but that's unlikely to be a significant motivator for much longer...

FYI,
/John

John Curran
President and CEO
ARIN

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140223/13d3b5c3/attachment.htm>

From SRyerse at eclipse-networks.com  Sun Feb 23 15:38:33 2014
From: SRyerse at eclipse-networks.com (Steven Ryerse)
Date: Sun, 23 Feb 2014 20:38:33 +0000
Subject: [arin-ppml] 2014-2 8.4 Anti-flip Language
In-Reply-To: <D83E9DD2-07F5-4F73-B705-A171B3F47FA0@delong.com>
References: <2CB940E2-1465-4FED-A6F3-7172849A90EA@delong.com><CAGkMwz5HKPdCJ
	BvXWRpvx2Uys0NJ6=TCDLTpszeJWg6V90vsXA@mail.gmail.com>
	<D83E9DD2-07F5-4F73-B705-A171B3F47FA0@delong.com>
Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD1201509C6268@ENI-MAIL.eclipse-networks.com>

This is an example of how policies penalize legitimate organizations needing to do legitimate transfers.  In my opinion the Polices have swung so far towards preventing abuse they impact legitimate transfers.  In the publicly traded company world, each quarter is like a year and a year is like 4 years to them since they have to publish their quarterly results 4 times a year.  For them a year is an eternity.  Also, the Internet itself has allowed business functions that once took months or years to take days or weeks which is todays reality.  Some of y?all think 12 months or even 18 months is a short time but that doesn?t align with the reality of today?s business world that the Internet has helped foster.

Although I don?t like abuse either, I am definitely AGAINST raising the hold period to be longer than a year.  If it has to be a year then at minimum, there should be a procedure defined in the policy that an organization can appeal to the ARIN CFO (or whoever) to get an exception for a shorter timeframe ? even as short as 30 days.  If what the organization is doing is legitimate and the ARIN CFO will approve it, then the 12 month hold rule should be waived.  My 2 cents.

Steven Ryerse
President
100 Ashford Center North, Suite 110, Atlanta, GA  30338
770.656.1460 - Cell
770.399.9099- Office

[Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc.
        Conquering Complex Networks?

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong
Sent: Saturday, February 22, 2014 11:43 PM
To: Scott Leibrand
Cc: ARIN-PPML List
Subject: Re: [arin-ppml] 2014-2 8.4 Anti-flip Language

It makes option 3 slightly more palatable, but I would still prefer option 2 as described below.

Owen

On Feb 22, 2014, at 3:28 PM, Scott Leibrand <scottleibrand at gmail.com<mailto:scottleibrand at gmail.com>> wrote:


There is another restriction already in 8.3, which reads "The source entity will be ineligible to receive any further IPv4 address allocations or assignments from ARIN for a period of 12 months after a transfer approval, or until the exhaustion of ARIN's IPv4 space, whichever occurs first."  In light of that, do you still see a problem with #3?

-Scott

On Sat, Feb 22, 2014 at 3:06 PM, Owen DeLong <owen at delong.com<mailto:owen at delong.com>> wrote:
Several options are being discussed regarding this proposal:

1. Use the existing last sentence as is and ask ARIN staff to be particularly watchful for seeming abuse and to bring such back to the community through regular Policy Experience Reports.  There was discussion about this option suggesting that by the time abuse was recognized and reported, and given limited existing free pool stocks and the extended policy development cycle....this option is mute.

2. Remove the clause 'and its subsidiaries' and or modify it in such a way as to mitigate the risk of a laundering of addresses through fraudulent transfers, but potentially limit the utility of organizations who may have complex organizations structures in use internationally.

3. Take an alternative tack and simply restrict the Inter-RIR re-org transfer of the 'recently issued block' only, allowing other existing blocks to be transferred without restriction by recent block acquisition. This alternative seems to have been expressed and supported in the recent Atlanta Public Policy Consultation.

It is my opinion that option 3 is perilous in that it allows a large resource holder to sell off their address space out of region while backfilling from the ARIN free pool.

As such, I am much more comfortable with option 2. One set of language that was suggested which I like is:

??subsidiaries having been operational for a minimum of 18 months.?

While this might not prevent all possible subsidiary-based rinse-repeat abuse scenarios, it would at least prevent the obvious subsidiary created for this purpose scenario and certainly provides better protections than proposal number 3.

I think option 1 is probably an unfair burden for the ARIN staff and makes policy vague in a way that would be difficult, if not impossible, to reliably enforce and may be even harder to defend in the event of litigation. This is strictly my own opinion as a member of the community and I have not discussed the matter with legal council or even the other members of the AC.

Owen


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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140223/862b6ab6/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 1468 bytes
Desc: image001.jpg
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140223/862b6ab6/attachment.jpg>

From jcurran at arin.net  Sun Feb 23 16:56:44 2014
From: jcurran at arin.net (John Curran)
Date: Sun, 23 Feb 2014 21:56:44 +0000
Subject: [arin-ppml] 2014-2 8.4 Anti-flip Language
In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD1201509C6268@ENI-MAIL.eclipse-networks.com>
References: <2CB940E2-1465-4FED-A6F3-7172849A90EA@delong.com>
	<"CAGkMwz5HKPdCJ BvXWRpvx2Uys0NJ6=TCDLTpszeJWg6V90vsXA"@mail.gmail.com>
	<D83E9DD2-07F5-4F73-B705-A171B3F47FA0@delong.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201509C6268@ENI-MAIL.eclipse-networks.com>
Message-ID: <FE89108A-705B-4200-A9AF-3C3030576E94@arin.net>

On Feb 23, 2014, at 3:38 PM, Steven Ryerse <SRyerse at eclipse-networks.com<mailto:SRyerse at eclipse-networks.com>> wrote:

This is an example of how policies penalize legitimate organizations needing to do legitimate transfers.  In my opinion the Polices have swung so far towards preventing abuse they impact legitimate transfers.  In the publicly traded company world, each quarter is like a year and a year is like 4 years to them since they have to publish their quarterly results 4 times a year.  For them a year is an eternity.  Also, the Internet itself has allowed business functions that once took months or years to take days or weeks which is todays reality.  Some of y?all think 12 months or even 18 months is a short time but that doesn?t align with the reality of today?s business world that the Internet has helped foster.

Although I don?t like abuse either, I am definitely AGAINST raising the hold period to be longer than a year.  If it has to be a year then at minimum, there should be a procedure defined in the policy that an organization can appeal to the ARIN CFO (or whoever) to get an exception for a shorter timeframe ? even as short as 30 days.  If what the organization is doing is legitimate and the ARIN CFO will approve it, then the 12 month hold rule should be waived.  My 2 cents.

Steve -

   Just to ask a question - if the hold time was fairly short (e.g. 1 year), would it really be necessary
   to have an exception process?   To the extent possible, it would be nice to keep processes (ergo,
   policy that drives processes) as simple as possible, as this both helps with automation as well as
   predicability for registry users.

   While there is already an ARIN appeals process, it is for the situation when it appears that ARIN did
   not follow adopted policy in handling a resource request,  as opposed to an appeal for a particular
   ARIN officer to reexamine and exercise their own judgement (which is what I understand from your
   proposal above.)   There are some implications to your proposed appeal option (potential for variation,
   fraud) which would need to be carefully considered carefully before implementation.

FYI,
/John

John Curran
President and CEO
ARIN


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140223/30d1739a/attachment.htm>

From gary.buhrmaster at gmail.com  Sun Feb 23 17:29:11 2014
From: gary.buhrmaster at gmail.com (Gary Buhrmaster)
Date: Sun, 23 Feb 2014 22:29:11 +0000
Subject: [arin-ppml] 2014-2 8.4 Anti-flip Language
In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD1201509C6268@ENI-MAIL.eclipse-networks.com>
References: <2CB940E2-1465-4FED-A6F3-7172849A90EA@delong.com>
	<D83E9DD2-07F5-4F73-B705-A171B3F47FA0@delong.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201509C6268@ENI-MAIL.eclipse-networks.com>
Message-ID: <CAMfXtQxSRVLi3UqynjrnZp6wG9duWtthZctaOt+3Wpd3U4uVUQ@mail.gmail.com>

On Sun, Feb 23, 2014 at 8:38 PM, Steven Ryerse <SRyerse at eclipse-networks.com
> wrote:

>  This is an example of how policies penalize legitimate organizations
> needing to do legitimate transfers.  In my opinion the Polices have swung
> so far towards preventing abuse they impact legitimate transfers.
>

Let us imagine a companies business *is* flipping
(or, worse, a subset of the business, to raise that
quarterly report numbers, since we are focused on
the quarterly numbers).  And let us say the policies
should make that difficult.

What policy language would you propose that would
preventing intentional abuse to make the quarterly
numbers while enabling your legitimate transfers
on a shorter scale?

Maybe we need to implement number clawbacks?
(yeah, that would work...)

Gary
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140223/96401f58/attachment.htm>

From mysidia at gmail.com  Sun Feb 23 20:56:27 2014
From: mysidia at gmail.com (Jimmy Hess)
Date: Sun, 23 Feb 2014 19:56:27 -0600
Subject: [arin-ppml] 2014-2 8.4 Anti-flip Language
In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD1201509C6268@ENI-MAIL.eclipse-networks.com>
References: <2CB940E2-1465-4FED-A6F3-7172849A90EA@delong.com>
	<D83E9DD2-07F5-4F73-B705-A171B3F47FA0@delong.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201509C6268@ENI-MAIL.eclipse-networks.com>
Message-ID: <CAAAwwbUC6wtw8HQ2g_QxgHMrTuX+TxFVxaaTeoXoYCJPc17LqA@mail.gmail.com>

On Sun, Feb 23, 2014 at 2:38 PM, Steven Ryerse <SRyerse at eclipse-networks.com
> wrote:

>  This is an example of how policies penalize legitimate organizations
> needing to do legitimate transfers.  In my opinion the Polices have swung
> so far towards preventing abuse they impact legitimate transfers.  In the
> publicly traded company world, each quarter is like a year and a year is
> like 4 years to them since they have to publish their quarterly results 4
> times a year.  For them a year is an eternity.
>

I would say that the new policies such as the 8.3 specified transfer and
inter-RIR transfer policies  are ENABLING resource holders.

ARIN is not required to allow such transfers;  historically,  they were not
allowed, but the community has decided that in some cases,  it makes sense
to allow transfers to specified recipients or between RIRs.    In cases
that are not allowed;  returning and applying for more resources is always
an option,   so  organizations are not being penalized.      Some
organizations may be  better enabled by new policies than others, and
that's okay.

While not all conceivable legitimate uses will be enabled by the specified
transfer policy and its abuse protections;  It is more important to
 prevent  potential abuses or possible flipping,  than to enable all
conceivable uses of resource transfer  that would be deemed legitimate.

I believe:  wait for 12 months,  or apply for the additional resources in
the proper region are appropriate answers,  and this example doesn't
 revise  relaxing  protections against abuse  that come  with the  new
policies that enable  resource transfers.

--
-JH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140223/661d7517/attachment.htm>

From billdarte at gmail.com  Sun Feb 23 21:09:08 2014
From: billdarte at gmail.com (Bill Darte)
Date: Sun, 23 Feb 2014 20:09:08 -0600
Subject: [arin-ppml] 2014-2 8.4 Anti-flip Language
In-Reply-To: <CAAAwwbUC6wtw8HQ2g_QxgHMrTuX+TxFVxaaTeoXoYCJPc17LqA@mail.gmail.com>
References: <2CB940E2-1465-4FED-A6F3-7172849A90EA@delong.com>
	<D83E9DD2-07F5-4F73-B705-A171B3F47FA0@delong.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201509C6268@ENI-MAIL.eclipse-networks.com>
	<CAAAwwbUC6wtw8HQ2g_QxgHMrTuX+TxFVxaaTeoXoYCJPc17LqA@mail.gmail.com>
Message-ID: <CAMApp36C4chWa02uQUkFbusJmHg8Xh9pYr74rpTeTaB1g5PnpQ@mail.gmail.com>

Jimmy....
Do you support one or another of the proposed alternatives for making
2014-2 a viable policy?  Or perhaps you have differing wording or yet
another alternative?

Thanks,
bd


On Sun, Feb 23, 2014 at 7:56 PM, Jimmy Hess <mysidia at gmail.com> wrote:

> On Sun, Feb 23, 2014 at 2:38 PM, Steven Ryerse <
> SRyerse at eclipse-networks.com> wrote:
>
>>  This is an example of how policies penalize legitimate organizations
>> needing to do legitimate transfers.  In my opinion the Polices have swung
>> so far towards preventing abuse they impact legitimate transfers.  In the
>> publicly traded company world, each quarter is like a year and a year is
>> like 4 years to them since they have to publish their quarterly results 4
>> times a year.  For them a year is an eternity.
>>
>
> I would say that the new policies such as the 8.3 specified transfer and
> inter-RIR transfer policies  are ENABLING resource holders.
>
> ARIN is not required to allow such transfers;  historically,  they were
> not allowed, but the community has decided that in some cases,  it makes
> sense to allow transfers to specified recipients or between RIRs.    In
> cases that are not allowed;  returning and applying for more resources is
> always an option,   so  organizations are not being penalized.      Some
> organizations may be  better enabled by new policies than others, and
> that's okay.
>
> While not all conceivable legitimate uses will be enabled by the specified
> transfer policy and its abuse protections;  It is more important to
>  prevent  potential abuses or possible flipping,  than to enable all
> conceivable uses of resource transfer  that would be deemed legitimate.
>
> I believe:  wait for 12 months,  or apply for the additional resources in
> the proper region are appropriate answers,  and this example doesn't
>  revise  relaxing  protections against abuse  that come  with the  new
> policies that enable  resource transfers.
>
> --
> -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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140223/a8704804/attachment.htm>

From farmer at umn.edu  Sun Feb 23 21:32:56 2014
From: farmer at umn.edu (David Farmer)
Date: Sun, 23 Feb 2014 20:32:56 -0600
Subject: [arin-ppml] 2014-2 8.4 Anti-flip Language
In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD1201509C6268@ENI-MAIL.eclipse-networks.com>
References: <2CB940E2-1465-4FED-A6F3-7172849A90EA@delong.com><CAGkMwz5HKPdCJ	BvXWRpvx2Uys0NJ6=TCDLTpszeJWg6V90vsXA@mail.gmail.com>	<D83E9DD2-07F5-4F73-B705-A171B3F47FA0@delong.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201509C6268@ENI-MAIL.eclipse-networks.com>
Message-ID: <530AAF58.9080407@umn.edu>

On 2/23/14, 14:38 , Steven Ryerse wrote:
> This is an example of how policies penalize legitimate organizations
> needing to do legitimate transfers.  In my opinion the Polices have
> swung so far towards preventing abuse they impact legitimate transfers.
> In the publicly traded company world, each quarter is like a year and a
> year is like 4 years to them since they have to publish their quarterly
> results 4 times a year.  For them a year is an eternity.  Also, the
> Internet itself has allowed business functions that once took months or
> years to take days or weeks which is todays reality.  Some of y?all
> think 12 months or even 18 months is a short time but that doesn?t align
> with the reality of today?s business world that the Internet has helped
> foster.
>
> Although I don?t like abuse either, I am definitely AGAINST raising the
> hold period to be longer than a year.  If it has to be a year then at
> minimum, there should be a procedure defined in the policy that an
> organization can appeal to the ARIN CFO (or whoever) to get an exception
> for a shorter timeframe ? even as short as 30 days.  If what the
> organization is doing is legitimate and the ARIN CFO will approve it,
> then the 12 month hold rule should be waived.  My 2 cents.


I've been thinking about this maybe the restrictions for anti-flipping 
don't belong in section 8 at all.  Maybe they belong in section 4 as 
they are intended to protect the ARIN IPv4 free pool.

The restrictions were needed because we enabled Inter-RIR transfers, so 
they were included with the Inter-RIR transfer policy.  I'm beginning to 
think this may have been a mistake.  Tactically we allowing IPv4 
allocations to remain liberal and restricting transfers.

It may be more effective to be more restrictive on the allocation of 
IPv4 resources and more liberal on transfers.

I think part of the reason we didn't do this is that we were trying to 
minimize the changes to allocation policy because of run-out and not 
wanting to have uncertain effects on the end-game of run-out.  So we've 
placed the restrictions on transfers as the new policy items rather than 
the the allocation policies.

I'll note, that several people have advocated liberalizing transfer 
policies for a while now.  However, they have not also advocated the 
accompanying restrictions that would be necessary on the allocation 
policy side.  I'll also note, that at this point it may be to late for 
this type of radical change.


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


From mysidia at gmail.com  Sun Feb 23 22:29:00 2014
From: mysidia at gmail.com (Jimmy Hess)
Date: Sun, 23 Feb 2014 21:29:00 -0600
Subject: [arin-ppml] 2014-2 8.4 Anti-flip Language
In-Reply-To: <530AAF58.9080407@umn.edu>
References: <2CB940E2-1465-4FED-A6F3-7172849A90EA@delong.com>
	<D83E9DD2-07F5-4F73-B705-A171B3F47FA0@delong.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201509C6268@ENI-MAIL.eclipse-networks.com>
	<530AAF58.9080407@umn.edu>
Message-ID: <CAAAwwbVESxeY24XpAmx5jDj+a8o9tfHXzva60HUck5MPfpD1Xw@mail.gmail.com>

On Sun, Feb 23, 2014 at 8:32 PM, David Farmer <farmer at umn.edu> wrote:


> I'll note, that several people have advocated liberalizing transfer
> policies for a while now.  However, they have not also advocated the
> accompanying restrictions that would be necessary on the allocation policy
> side.  I'll also note, that at this point it may be to late for this type
> of radical change.


I don't think it is too late.   Perhaps the rule should say  something to
this effect:   expire the rule after exhaustion?

o  Make the anti-flip language state that the waiting period will
automatically be reduced to 3 months;  following 6 months,  after  which
ARIN  continuously no longer has the free resources available  to satisfy
 any resource allocation request  of  /22 or more addresses,  that would be
accepted if the resources were available.


--
-JH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140223/9d2df8ee/attachment.htm>

From owen at delong.com  Mon Feb 24 05:20:09 2014
From: owen at delong.com (Owen DeLong)
Date: Mon, 24 Feb 2014 02:20:09 -0800
Subject: [arin-ppml] 2014-2 8.4 Anti-flip Language
In-Reply-To: <530AAF58.9080407@umn.edu>
References: <2CB940E2-1465-4FED-A6F3-7172849A90EA@delong.com><CAGkMwz5HKPdCJ	BvXWRpvx2Uys0NJ6=TCDLTpszeJWg6V90vsXA@mail.gmail.com>	<D83E9DD2-07F5-4F73-B705-A171B3F47FA0@delong.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201509C6268@ENI-MAIL.eclipse-networks.com>
	<530AAF58.9080407@umn.edu>
Message-ID: <0858DDF3-553B-4E3B-92FD-2A52BCCE85FC@delong.com>


On Feb 23, 2014, at 6:32 PM, David Farmer <farmer at umn.edu> wrote:

> On 2/23/14, 14:38 , Steven Ryerse wrote:
>> This is an example of how policies penalize legitimate organizations
>> needing to do legitimate transfers.  In my opinion the Polices have
>> swung so far towards preventing abuse they impact legitimate transfers.
>> In the publicly traded company world, each quarter is like a year and a
>> year is like 4 years to them since they have to publish their quarterly
>> results 4 times a year.  For them a year is an eternity.  Also, the
>> Internet itself has allowed business functions that once took months or
>> years to take days or weeks which is todays reality.  Some of y?all
>> think 12 months or even 18 months is a short time but that doesn?t align
>> with the reality of today?s business world that the Internet has helped
>> foster.
>> 
>> Although I don?t like abuse either, I am definitely AGAINST raising the
>> hold period to be longer than a year.  If it has to be a year then at
>> minimum, there should be a procedure defined in the policy that an
>> organization can appeal to the ARIN CFO (or whoever) to get an exception
>> for a shorter timeframe ? even as short as 30 days.  If what the
>> organization is doing is legitimate and the ARIN CFO will approve it,
>> then the 12 month hold rule should be waived.  My 2 cents.
> 
> 
> I've been thinking about this maybe the restrictions for anti-flipping don't belong in section 8 at all.  Maybe they belong in section 4 as they are intended to protect the ARIN IPv4 free pool.

I disagree. I don?t want to see flipping become a tool for speculation in the market post-exhaustion, any more than I want to see it become a tool for draining the free pool. In fact, I think that the former might be significantly more harmful than the latter at this point.

> The restrictions were needed because we enabled Inter-RIR transfers, so they were included with the Inter-RIR transfer policy.  I'm beginning to think this may have been a mistake.  Tactically we allowing IPv4 allocations to remain liberal and restricting transfers.

I don?t see a problem with that. I have no desire to encourage transfers as a primary choice. I think it is, in fact, just bad policy to do so. Transfers should, IMHO, be viewed as a last resort when free pool options have been exhausted.


> It may be more effective to be more restrictive on the allocation of IPv4 resources and more liberal on transfers.

I see no benefit whatsoever from this approach. I think it would do more harm than good. cf. deck chairs.

> I think part of the reason we didn't do this is that we were trying to minimize the changes to allocation policy because of run-out and not wanting to have uncertain effects on the end-game of run-out.  So we've placed the restrictions on transfers as the new policy items rather than the the allocation policies.
> 
> I'll note, that several people have advocated liberalizing transfer policies for a while now.  However, they have not also advocated the accompanying restrictions that would be necessary on the allocation policy side.  I'll also note, that at this point it may be to late for this type of radical change.

I?ll also note that several people have been arguing against significant liberalization of transfers and I have not seen any indication that there is anything approaching consensus towards such liberalization.

Owen



From jcurran at arin.net  Mon Feb 24 08:13:33 2014
From: jcurran at arin.net (John Curran)
Date: Mon, 24 Feb 2014 13:13:33 +0000
Subject: [arin-ppml] 2014-2 8.4 Anti-flip Language
In-Reply-To: <0858DDF3-553B-4E3B-92FD-2A52BCCE85FC@delong.com>
References: <2CB940E2-1465-4FED-A6F3-7172849A90EA@delong.com>
	<"CAGkMwz5HKPdCJ BvXWRpvx2Uys0NJ6=TCDLTpszeJWg6V90vsXA"@mail.gmail.com>
	<D83E9DD2-07F5-4F73-B705-A171B3F47FA0@delong.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201509C6268@ENI-MAIL.eclipse-networks.com>
	<530AAF58.9080407@umn.edu>
	<0858DDF3-553B-4E3B-92FD-2A52BCCE85FC@delong.com>
Message-ID: <407F662E-B241-4AC6-B8C9-A65C23DC0CB7@corp.arin.net>

On Feb 24, 2014, at 5:20 AM, Owen DeLong <owen at delong.com> wrote:

> On Feb 23, 2014, at 6:32 PM, David Farmer <farmer at umn.edu> wrote:
>> ...
>> I've been thinking about this maybe the restrictions for anti-flipping don't belong in section 8 at all.  Maybe they belong in section 4 as they are intended to protect the ARIN IPv4 free pool.
> 
> I disagree. I don?t want to see flipping become a tool for speculation in the market post-exhaustion, any more than I want to see it become a tool for draining the free pool. In fact, I think that the former might be significantly more harmful than the latter at this point.

Owen - 
 
  Could you elaborate your thoughts regarding the harm that might occur?

  I believe that folks understand risks associated with sudden/unexpected IPv4 free
  pool depletion, but you are suggesting that liquidity itself in the IPv4 transfer 
  market is harmful.  As that is neither obvious nor aligned with most market theory, 
  it would be best for you to elaborate your thoughts some on that aspect.

Thanks!
/John

John Curran
President and CEO
ARIN



From billdarte at gmail.com  Mon Feb 24 09:33:51 2014
From: billdarte at gmail.com (Bill Darte)
Date: Mon, 24 Feb 2014 08:33:51 -0600
Subject: [arin-ppml] 2014-2 8.4 Anti-flip Language
In-Reply-To: <407F662E-B241-4AC6-B8C9-A65C23DC0CB7@corp.arin.net>
References: <2CB940E2-1465-4FED-A6F3-7172849A90EA@delong.com>
	<D83E9DD2-07F5-4F73-B705-A171B3F47FA0@delong.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201509C6268@ENI-MAIL.eclipse-networks.com>
	<530AAF58.9080407@umn.edu>
	<0858DDF3-553B-4E3B-92FD-2A52BCCE85FC@delong.com>
	<407F662E-B241-4AC6-B8C9-A65C23DC0CB7@corp.arin.net>
Message-ID: <CAMApp372etUJ36jw=NREDKLUy6sAtOV5PoJCwtutdNpDq40Q+Q@mail.gmail.com>

I'll not answer for Owen, but your question prompts me to say that the
transfer market is not a goodness.  It was, in my mind, a reasonable yet
distasteful stop gap on the way toward a once again more unified protocol
environment...to wit.. IPv6.

My market theory suggest that transfer market at its free-est and most open
deters and confuses the way forward.  The purpose of standards is to
eliminate confusion and choices which require understanding investment
options and application consequences.  While standards have their downside,
one of them is not those elements of marketplace choice.

The more options existing the more confused.  Investment=legacy.  End-users
must predict and interpret, making decisions that may come back to haunt.
Developers delay their innovation in order to better understand whether
they're investing in a blind technology. Transport providers must deploy
and support more complicated configurations with their limited funds,
inevitably satisfying some an thwarting others.

Would that the transfer market and all efforts to prolong IPv4 come to an
end quickly IMO.

End of soapbox

bd


On Mon, Feb 24, 2014 at 7:13 AM, John Curran <jcurran at arin.net> wrote:

> On Feb 24, 2014, at 5:20 AM, Owen DeLong <owen at delong.com> wrote:
>
> > On Feb 23, 2014, at 6:32 PM, David Farmer <farmer at umn.edu> wrote:
> >> ...
> >> I've been thinking about this maybe the restrictions for anti-flipping
> don't belong in section 8 at all.  Maybe they belong in section 4 as they
> are intended to protect the ARIN IPv4 free pool.
> >
> > I disagree. I don't want to see flipping become a tool for speculation
> in the market post-exhaustion, any more than I want to see it become a tool
> for draining the free pool. In fact, I think that the former might be
> significantly more harmful than the latter at this point.
>
> Owen -
>
>   Could you elaborate your thoughts regarding the harm that might occur?
>
>   I believe that folks understand risks associated with sudden/unexpected
> IPv4 free
>   pool depletion, but you are suggesting that liquidity itself in the IPv4
> transfer
>   market is harmful.  As that is neither obvious nor aligned with most
> market theory,
>   it would be best for you to elaborate your thoughts some on that aspect.
>
> Thanks!
> /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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140224/75901806/attachment.htm>

From bill at herrin.us  Mon Feb 24 12:50:50 2014
From: bill at herrin.us (William Herrin)
Date: Mon, 24 Feb 2014 12:50:50 -0500
Subject: [arin-ppml] ARIN Draft Policy 2014-2 Improving 8.4 Anti-Flip
	Language
In-Reply-To: <CAMApp34bqyS=uQETQXsabBsO16x+TLz2qZfCMU+9WDkjFcmkkA@mail.gmail.com>
References: <CAMApp34bqyS=uQETQXsabBsO16x+TLz2qZfCMU+9WDkjFcmkkA@mail.gmail.com>
Message-ID: <CAP-guGXrhkM-6hP4oTGSPUCE5OrZyFHatzTDi4G23uZ4T0kshQ@mail.gmail.com>

On Fri, Feb 21, 2014 at 11:53 AM, Bill Darte <billdarte at gmail.com> wrote:
> Three alternatives were primarily discussed and I wish to elicit feedback
> from the community relative to each.
>
> 1. Use the existing last sentence as is and ask ARIN staff to be
> particularly watchful for seeming abuse and to bring such back to the
> community through regular Policy Experience Reports.  There was discussion
> about this option suggesting that by the time abuse was recognized and
> reported, and given limited existing free pool stocks and the extended
> policy development cycle....this option may be moot.
>
> 2. Remove the clause 'and its subsidiaries' or modify it in such a way as to
> mitigate the risk of a laundering of addresses through fraudulent transfers,
> but this may still potentially limit the utility to organizations who may
> have complex organizational structures in use internationally.
>
> 3. Take an alternative tack and simply restrict transfers on a per-block
> rather than a per-organization basis. e.g. 'No block acquired within the
> past 24 months would be eligible for transfer.' (The time frame is of course
> an arbitrary number at this point.)

Howdy,

My preference is for #2: remove the clause. Moreover, I question
whether this matter requires policy action at all.

As was recently and eloquently pointed out to us, organizations can
and do receive the beneficial use of blocks of IP addresses without
effecting a transfer at the registry. In the case of a subsidiary
which will remain a subsidiary for a policy-relevant period of time,
nothing is lost by processing contact via the parent organization.
Why, then, should ARIN create a loophole in the regulations and risk
its abuse?

Loopholes = bad. Allow open transfers or don't, but please don't
create loopholes for folks to abuse.

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 rudi.daniel at gmail.com  Mon Feb 24 13:09:28 2014
From: rudi.daniel at gmail.com (Rudolph Daniel)
Date: Mon, 24 Feb 2014 14:09:28 -0400
Subject: [arin-ppml] update section 203 proposal
In-Reply-To: <A831E5D9-801F-43F0-B828-76046D324C69@arin.net>
References: <CA+uaoiXvTCDKuh40Q0=YAsq=B1XM+2+L6E6bEMzk=RCou_oueQ@mail.gmail.com>
	<CA+uaoiWb0rPMxTjXkwFFQ6u858K8DVeYX3EKz1xmMMkF9i+KKA@mail.gmail.com>
	<A831E5D9-801F-43F0-B828-76046D324C69@arin.net>
Message-ID: <CA+uaoiWLwHZLxVROAOeLW+a0sovg6Bw9vComgXf5mnUCsoahUQ@mail.gmail.com>

John
Ripe605 made a recall from memory of discussions on the ppml probably
around the time I started participating on the list.
I simply have not made the time to dig back in the archives to refresh my
memory....I do remember a lengthy community discussion about legacy holders
and keeping resources within the region....of course things have changed
since then and I have been listening attentively to the recent exchanges
about inter RIR transfers....which I suspect may continue to evolve after
runout whilst the transition to ipv6 remains slower than we would all
ideally like to see....but there is a suggestion that the reassignments
ecosystem needs some kind of ongoing monitoring mechanism.

Rudi Daniel
(information technologist)
784 430 9235
 On Feb 23, 2014, at 11:50 AM, Rudolph Daniel <rudi.daniel at gmail.com>
wrote:

This may seem a stupid question, but since we now want to accept that
accuracy is a principle task of registries, what measure are we to use as
an acceptable measure of an accurate 'whois' or at the macro level, ' an
accurate registry service' ?......% of legacy holders participating on the
registry?

It's actually a fairly complicated question, since there are many legacy
holder who already
participate in the registry and update their resources (e.g. abuse contact,
DNS servers)
without any formal contractual relationship with ARIN.  In any case,
individual legacy holders
are unlikely to be the major contributor of inaccuracy in the registry when
compared to those
parties who fail to update the registry with their reassignment information
(despite the
requirement to do so per NRPM 4.2.3.7.)

 We do know that many folks are quite good about making updates before they
request
more IPv4 space, but that's unlikely to be a significant motivator for much
longer...

 FYI,
/John

 John Curran
President and CEO
ARIN
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140224/06a61a7c/attachment.htm>

From owen at delong.com  Mon Feb 24 20:10:23 2014
From: owen at delong.com (Owen DeLong)
Date: Mon, 24 Feb 2014 17:10:23 -0800
Subject: [arin-ppml] 2014-2 8.4 Anti-flip Language
In-Reply-To: <407F662E-B241-4AC6-B8C9-A65C23DC0CB7@corp.arin.net>
References: <2CB940E2-1465-4FED-A6F3-7172849A90EA@delong.com> <"CAGkMwz5HKPdCJ
	BvXWRpvx2Uys0NJ6=TCDLTpszeJWg6V90vsXA"@mail.gmail.com>
	<D83E9DD2-07F5-4F73-B705-A171B3F47FA0@delong.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201509C6268@ENI-MAIL.eclipse-networks.com>
	<530AAF58.9080407@umn.edu>
	<0858DDF3-553B-4E3B-92FD-2A52BCCE85FC@delong.com>
	<407F662E-B241-4AC6-B8C9-A65C23DC0CB7@corp.arin.net>
Message-ID: <52C74E9A-3B9A-41B8-9115-1F69FEA6B9A7@delong.com>


On Feb 24, 2014, at 5:13 AM, John Curran <jcurran at arin.net> wrote:

> On Feb 24, 2014, at 5:20 AM, Owen DeLong <owen at delong.com> wrote:
> 
>> On Feb 23, 2014, at 6:32 PM, David Farmer <farmer at umn.edu> wrote:
>>> ...
>>> I've been thinking about this maybe the restrictions for anti-flipping don't belong in section 8 at all.  Maybe they belong in section 4 as they are intended to protect the ARIN IPv4 free pool.
>> 
>> I disagree. I don?t want to see flipping become a tool for speculation in the market post-exhaustion, any more than I want to see it become a tool for draining the free pool. In fact, I think that the former might be significantly more harmful than the latter at this point.
> 
> Owen - 
> 
>  Could you elaborate your thoughts regarding the harm that might occur?
> 
>  I believe that folks understand risks associated with sudden/unexpected IPv4 free
>  pool depletion, but you are suggesting that liquidity itself in the IPv4 transfer 
>  market is harmful.  As that is neither obvious nor aligned with most market theory, 
>  it would be best for you to elaborate your thoughts some on that aspect.

I?m not suggesting that liquidity is harmful, but I am suggesting that creating an environment that is friendly to market manipulators and speculators would be harmful.

I realize that my opinions are definitely not aligned with most market theories, especially the more lessez faire ones, but I am not one of the free-market zealots that believes all regulation is harmful and all thins should be decided by dollars.

Look at the effect house flipping had on the California real estate market. This has been harmful in a number of ways and I see no reason to believe that similar behavior, if allowed, in the IP address realm would not be even more harmful.

Owen



From owen at delong.com  Mon Feb 24 20:14:15 2014
From: owen at delong.com (Owen DeLong)
Date: Mon, 24 Feb 2014 17:14:15 -0800
Subject: [arin-ppml] 2014-2 8.4 Anti-flip Language
In-Reply-To: <CAMApp372etUJ36jw=NREDKLUy6sAtOV5PoJCwtutdNpDq40Q+Q@mail.gmail.com>
References: <2CB940E2-1465-4FED-A6F3-7172849A90EA@delong.com>
	<D83E9DD2-07F5-4F73-B705-A171B3F47FA0@delong.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201509C6268@ENI-MAIL.eclipse-networks.com>
	<530AAF58.9080407@umn.edu>
	<0858DDF3-553B-4E3B-92FD-2A52BCCE85FC@delong.com>
	<407F662E-B241-4AC6-B8C9-A65C23DC0CB7@corp.arin.net>
	<CAMApp372etUJ36jw=NREDKLUy6sAtOV5PoJCwtutdNpDq40Q+Q@mail.gmail.com>
Message-ID: <D2E22E3A-8B66-4ECC-9928-8231F9AE1755@delong.com>

This, too.

Owen

On Feb 24, 2014, at 6:33 AM, Bill Darte <billdarte at gmail.com> wrote:

> I'll not answer for Owen, but your question prompts me to say that the transfer market is not a goodness.  It was, in my mind, a reasonable yet distasteful stop gap on the way toward a once again more unified protocol environment...to wit.. IPv6.
> 
> My market theory suggest that transfer market at its free-est and most open deters and confuses the way forward.  The purpose of standards is to eliminate confusion and choices which require understanding investment options and application consequences.  While standards have their downside, one of them is not those elements of marketplace choice.  
> 
> The more options existing the more confused.  Investment=legacy.  End-users must predict and interpret, making decisions that may come back to haunt. Developers delay their innovation in order to better understand whether they're investing in a blind technology. Transport providers must deploy and support more complicated configurations with their limited funds, inevitably satisfying some an thwarting others.
> 
> Would that the transfer market and all efforts to prolong IPv4 come to an end quickly IMO.
> 
> End of soapbox
> 
> bd
> 
> 
> On Mon, Feb 24, 2014 at 7:13 AM, John Curran <jcurran at arin.net> wrote:
> On Feb 24, 2014, at 5:20 AM, Owen DeLong <owen at delong.com> wrote:
> 
> > On Feb 23, 2014, at 6:32 PM, David Farmer <farmer at umn.edu> wrote:
> >> ...
> >> I've been thinking about this maybe the restrictions for anti-flipping don't belong in section 8 at all.  Maybe they belong in section 4 as they are intended to protect the ARIN IPv4 free pool.
> >
> > I disagree. I don?t want to see flipping become a tool for speculation in the market post-exhaustion, any more than I want to see it become a tool for draining the free pool. In fact, I think that the former might be significantly more harmful than the latter at this point.
> 
> Owen -
> 
>   Could you elaborate your thoughts regarding the harm that might occur?
> 
>   I believe that folks understand risks associated with sudden/unexpected IPv4 free
>   pool depletion, but you are suggesting that liquidity itself in the IPv4 transfer
>   market is harmful.  As that is neither obvious nor aligned with most market theory,
>   it would be best for you to elaborate your thoughts some on that aspect.
> 
> Thanks!
> /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.
> 

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

From george.herbert at gmail.com  Mon Feb 24 20:20:30 2014
From: george.herbert at gmail.com (George Herbert)
Date: Mon, 24 Feb 2014 17:20:30 -0800
Subject: [arin-ppml] 2014-2 8.4 Anti-flip Language
In-Reply-To: <52C74E9A-3B9A-41B8-9115-1F69FEA6B9A7@delong.com>
References: <2CB940E2-1465-4FED-A6F3-7172849A90EA@delong.com>
	<D83E9DD2-07F5-4F73-B705-A171B3F47FA0@delong.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201509C6268@ENI-MAIL.eclipse-networks.com>
	<530AAF58.9080407@umn.edu>
	<0858DDF3-553B-4E3B-92FD-2A52BCCE85FC@delong.com>
	<407F662E-B241-4AC6-B8C9-A65C23DC0CB7@corp.arin.net>
	<52C74E9A-3B9A-41B8-9115-1F69FEA6B9A7@delong.com>
Message-ID: <CAK__KzsxOrpeXhPon=_qLRU-rHNXhumkmVbqc3b793Qq4f3zPw@mail.gmail.com>

Right; a proper *market analysis* will not just say "free market" and stop
- we need to understand what will be sold, from who, where it is, and where
it's going and to whom; whether it will be direct or intermediated,
speculated, in what forms, etc.

This analysis needs to be done by Q4 2012 and we need to be discussing the
results of some field tests now...

Oops.




On Mon, Feb 24, 2014 at 5:10 PM, Owen DeLong <owen at delong.com> wrote:

>
> On Feb 24, 2014, at 5:13 AM, John Curran <jcurran at arin.net> wrote:
>
> > On Feb 24, 2014, at 5:20 AM, Owen DeLong <owen at delong.com> wrote:
> >
> >> On Feb 23, 2014, at 6:32 PM, David Farmer <farmer at umn.edu> wrote:
> >>> ...
> >>> I've been thinking about this maybe the restrictions for anti-flipping
> don't belong in section 8 at all.  Maybe they belong in section 4 as they
> are intended to protect the ARIN IPv4 free pool.
> >>
> >> I disagree. I don't want to see flipping become a tool for speculation
> in the market post-exhaustion, any more than I want to see it become a tool
> for draining the free pool. In fact, I think that the former might be
> significantly more harmful than the latter at this point.
> >
> > Owen -
> >
> >  Could you elaborate your thoughts regarding the harm that might occur?
> >
> >  I believe that folks understand risks associated with sudden/unexpected
> IPv4 free
> >  pool depletion, but you are suggesting that liquidity itself in the
> IPv4 transfer
> >  market is harmful.  As that is neither obvious nor aligned with most
> market theory,
> >  it would be best for you to elaborate your thoughts some on that aspect.
>
> I'm not suggesting that liquidity is harmful, but I am suggesting that
> creating an environment that is friendly to market manipulators and
> speculators would be harmful.
>
> I realize that my opinions are definitely not aligned with most market
> theories, especially the more lessez faire ones, but I am not one of the
> free-market zealots that believes all regulation is harmful and all thins
> should be decided by dollars.
>
> Look at the effect house flipping had on the California real estate
> market. This has been harmful in a number of ways and I see no reason to
> believe that similar behavior, if allowed, in the IP address realm would
> not be even more harmful.
>
> 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.
>



-- 
-george william herbert
george.herbert at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140224/0306bed9/attachment.htm>

From george.herbert at gmail.com  Mon Feb 24 20:23:14 2014
From: george.herbert at gmail.com (George Herbert)
Date: Mon, 24 Feb 2014 17:23:14 -0800
Subject: [arin-ppml] 2014-2 8.4 Anti-flip Language
In-Reply-To: <D2E22E3A-8B66-4ECC-9928-8231F9AE1755@delong.com>
References: <2CB940E2-1465-4FED-A6F3-7172849A90EA@delong.com>
	<D83E9DD2-07F5-4F73-B705-A171B3F47FA0@delong.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201509C6268@ENI-MAIL.eclipse-networks.com>
	<530AAF58.9080407@umn.edu>
	<0858DDF3-553B-4E3B-92FD-2A52BCCE85FC@delong.com>
	<407F662E-B241-4AC6-B8C9-A65C23DC0CB7@corp.arin.net>
	<CAMApp372etUJ36jw=NREDKLUy6sAtOV5PoJCwtutdNpDq40Q+Q@mail.gmail.com>
	<D2E22E3A-8B66-4ECC-9928-8231F9AE1755@delong.com>
Message-ID: <CAK__Kzs1TwqGvVC7Jj-A7Oq=AAJ0-Am2K_EaXNQyKVKPE_M+7Q@mail.gmail.com>

I object to the viewpoint that we should use policy to confuse things so
that IPv6 is more attractive sooner.  There are systemic risks with IPv4
runout and inflexibility prior to IPv6 being fully baked in the
works-for-everyone sense.  The time to have made those adjustments was 2008
or so, not now.

If we're going to go back to recent history for economic lessons, the Fed
letting Lehman Brothers crash is a good one.  They were trying to make a
couple of points, too, but the collateral damage nearly caused a
depression...


On Mon, Feb 24, 2014 at 5:14 PM, Owen DeLong <owen at delong.com> wrote:

> This, too.
>
> Owen
>
> On Feb 24, 2014, at 6:33 AM, Bill Darte <billdarte at gmail.com> wrote:
>
> I'll not answer for Owen, but your question prompts me to say that the
> transfer market is not a goodness.  It was, in my mind, a reasonable yet
> distasteful stop gap on the way toward a once again more unified protocol
> environment...to wit.. IPv6.
>
> My market theory suggest that transfer market at its free-est and most
> open deters and confuses the way forward.  The purpose of standards is to
> eliminate confusion and choices which require understanding investment
> options and application consequences.  While standards have their downside,
> one of them is not those elements of marketplace choice.
>
> The more options existing the more confused.  Investment=legacy.
>  End-users must predict and interpret, making decisions that may come back
> to haunt. Developers delay their innovation in order to better understand
> whether they're investing in a blind technology. Transport providers must
> deploy and support more complicated configurations with their limited
> funds, inevitably satisfying some an thwarting others.
>
> Would that the transfer market and all efforts to prolong IPv4 come to an
> end quickly IMO.
>
> End of soapbox
>
> bd
>
>
> On Mon, Feb 24, 2014 at 7:13 AM, John Curran <jcurran at arin.net> wrote:
>
>> On Feb 24, 2014, at 5:20 AM, Owen DeLong <owen at delong.com> wrote:
>>
>> > On Feb 23, 2014, at 6:32 PM, David Farmer <farmer at umn.edu> wrote:
>> >> ...
>> >> I've been thinking about this maybe the restrictions for anti-flipping
>> don't belong in section 8 at all.  Maybe they belong in section 4 as they
>> are intended to protect the ARIN IPv4 free pool.
>> >
>> > I disagree. I don't want to see flipping become a tool for speculation
>> in the market post-exhaustion, any more than I want to see it become a tool
>> for draining the free pool. In fact, I think that the former might be
>> significantly more harmful than the latter at this point.
>>
>> Owen -
>>
>>   Could you elaborate your thoughts regarding the harm that might occur?
>>
>>   I believe that folks understand risks associated with sudden/unexpected
>> IPv4 free
>>   pool depletion, but you are suggesting that liquidity itself in the
>> IPv4 transfer
>>   market is harmful.  As that is neither obvious nor aligned with most
>> market theory,
>>   it would be best for you to elaborate your thoughts some on that aspect.
>>
>> Thanks!
>> /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.
>>
>
>
>
> _______________________________________________
> 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.
>



-- 
-george william herbert
george.herbert at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140224/22cbfb7a/attachment.htm>

From owen at delong.com  Mon Feb 24 20:46:46 2014
From: owen at delong.com (Owen DeLong)
Date: Mon, 24 Feb 2014 17:46:46 -0800
Subject: [arin-ppml] 2014-2 8.4 Anti-flip Language
In-Reply-To: <CAK__Kzs1TwqGvVC7Jj-A7Oq=AAJ0-Am2K_EaXNQyKVKPE_M+7Q@mail.gmail.com>
References: <2CB940E2-1465-4FED-A6F3-7172849A90EA@delong.com>
	<D83E9DD2-07F5-4F73-B705-A171B3F47FA0@delong.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201509C6268@ENI-MAIL.eclipse-networks.com>
	<530AAF58.9080407@umn.edu>
	<0858DDF3-553B-4E3B-92FD-2A52BCCE85FC@delong.com>
	<407F662E-B241-4AC6-B8C9-A65C23DC0CB7@corp.arin.net>
	<CAMApp372etUJ36jw=NREDKLUy6sAtOV5PoJCwtutdNpDq40Q+Q@mail.gmail.com>
	<D2E22E3A-8B66-4ECC-9928-8231F9AE1755@delong.com>
	<CAK__Kzs1TwqGvVC7Jj-A7Oq=AAJ0-Am2K_EaXNQyKVKPE_M+7Q@mail.gmail.com>
Message-ID: <BDE5661D-4133-4C95-851C-79CCA18F4B76@delong.com>


On Feb 24, 2014, at 5:23 PM, George Herbert <george.herbert at gmail.com> wrote:

> I object to the viewpoint that we should use policy to confuse things so that IPv6 is more attractive sooner.  There are systemic risks with IPv4 runout and inflexibility prior to IPv6 being fully baked in the works-for-everyone sense.  The time to have made those adjustments was 2008 or so, not now.

I don?t believe that is what Bill suggested. I believe he stated that mucking with policy to make the market artificially attractive would harm the transition process.

> If we're going to go back to recent history for economic lessons, the Fed letting Lehman Brothers crash is a good one.  They were trying to make a couple of points, too, but the collateral damage nearly caused a depression?

IMHO, failing to let a number of the others collapse and not dismantling those that were propped up was the bigger mistake.

Owen

> 
> 
> On Mon, Feb 24, 2014 at 5:14 PM, Owen DeLong <owen at delong.com> wrote:
> This, too.
> 
> Owen
> 
> On Feb 24, 2014, at 6:33 AM, Bill Darte <billdarte at gmail.com> wrote:
> 
>> I'll not answer for Owen, but your question prompts me to say that the transfer market is not a goodness.  It was, in my mind, a reasonable yet distasteful stop gap on the way toward a once again more unified protocol environment...to wit.. IPv6.
>> 
>> My market theory suggest that transfer market at its free-est and most open deters and confuses the way forward.  The purpose of standards is to eliminate confusion and choices which require understanding investment options and application consequences.  While standards have their downside, one of them is not those elements of marketplace choice.  
>> 
>> The more options existing the more confused.  Investment=legacy.  End-users must predict and interpret, making decisions that may come back to haunt. Developers delay their innovation in order to better understand whether they're investing in a blind technology. Transport providers must deploy and support more complicated configurations with their limited funds, inevitably satisfying some an thwarting others.
>> 
>> Would that the transfer market and all efforts to prolong IPv4 come to an end quickly IMO.
>> 
>> End of soapbox
>> 
>> bd
>> 
>> 
>> On Mon, Feb 24, 2014 at 7:13 AM, John Curran <jcurran at arin.net> wrote:
>> On Feb 24, 2014, at 5:20 AM, Owen DeLong <owen at delong.com> wrote:
>> 
>> > On Feb 23, 2014, at 6:32 PM, David Farmer <farmer at umn.edu> wrote:
>> >> ...
>> >> I've been thinking about this maybe the restrictions for anti-flipping don't belong in section 8 at all.  Maybe they belong in section 4 as they are intended to protect the ARIN IPv4 free pool.
>> >
>> > I disagree. I don?t want to see flipping become a tool for speculation in the market post-exhaustion, any more than I want to see it become a tool for draining the free pool. In fact, I think that the former might be significantly more harmful than the latter at this point.
>> 
>> Owen -
>> 
>>   Could you elaborate your thoughts regarding the harm that might occur?
>> 
>>   I believe that folks understand risks associated with sudden/unexpected IPv4 free
>>   pool depletion, but you are suggesting that liquidity itself in the IPv4 transfer
>>   market is harmful.  As that is neither obvious nor aligned with most market theory,
>>   it would be best for you to elaborate your thoughts some on that aspect.
>> 
>> Thanks!
>> /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.
>> 
> 
> 
> _______________________________________________
> 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.
> 
> 
> 
> -- 
> -george william herbert
> george.herbert at gmail.com

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

From billdarte at gmail.com  Mon Feb 24 21:12:53 2014
From: billdarte at gmail.com (Bill Darte)
Date: Mon, 24 Feb 2014 20:12:53 -0600
Subject: [arin-ppml] 2014-2 8.4 Anti-flip Language
In-Reply-To: <CAK__Kzs1TwqGvVC7Jj-A7Oq=AAJ0-Am2K_EaXNQyKVKPE_M+7Q@mail.gmail.com>
References: <2CB940E2-1465-4FED-A6F3-7172849A90EA@delong.com>
	<D83E9DD2-07F5-4F73-B705-A171B3F47FA0@delong.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201509C6268@ENI-MAIL.eclipse-networks.com>
	<530AAF58.9080407@umn.edu>
	<0858DDF3-553B-4E3B-92FD-2A52BCCE85FC@delong.com>
	<407F662E-B241-4AC6-B8C9-A65C23DC0CB7@corp.arin.net>
	<CAMApp372etUJ36jw=NREDKLUy6sAtOV5PoJCwtutdNpDq40Q+Q@mail.gmail.com>
	<D2E22E3A-8B66-4ECC-9928-8231F9AE1755@delong.com>
	<CAK__Kzs1TwqGvVC7Jj-A7Oq=AAJ0-Am2K_EaXNQyKVKPE_M+7Q@mail.gmail.com>
Message-ID: <CAMApp35M++m5H+dWZ6Q30ZGa2xJtqnMqOqfofAVbEno+AAL1hA@mail.gmail.com>

Sure, I think I agreed with you....but it remains in my mind a stop-gap (or
should be) until such time the baking is complete and too much emphasis on
free-market transfers simply lowers the oven temperature....

bd


On Mon, Feb 24, 2014 at 7:23 PM, George Herbert <george.herbert at gmail.com>wrote:

> I object to the viewpoint that we should use policy to confuse things so
> that IPv6 is more attractive sooner.  There are systemic risks with IPv4
> runout and inflexibility prior to IPv6 being fully baked in the
> works-for-everyone sense.  The time to have made those adjustments was 2008
> or so, not now.
>
> If we're going to go back to recent history for economic lessons, the Fed
> letting Lehman Brothers crash is a good one.  They were trying to make a
> couple of points, too, but the collateral damage nearly caused a
> depression...
>
>
> On Mon, Feb 24, 2014 at 5:14 PM, Owen DeLong <owen at delong.com> wrote:
>
>> This, too.
>>
>> Owen
>>
>> On Feb 24, 2014, at 6:33 AM, Bill Darte <billdarte at gmail.com> wrote:
>>
>> I'll not answer for Owen, but your question prompts me to say that the
>> transfer market is not a goodness.  It was, in my mind, a reasonable yet
>> distasteful stop gap on the way toward a once again more unified protocol
>> environment...to wit.. IPv6.
>>
>> My market theory suggest that transfer market at its free-est and most
>> open deters and confuses the way forward.  The purpose of standards is to
>> eliminate confusion and choices which require understanding investment
>> options and application consequences.  While standards have their downside,
>> one of them is not those elements of marketplace choice.
>>
>> The more options existing the more confused.  Investment=legacy.
>>  End-users must predict and interpret, making decisions that may come back
>> to haunt. Developers delay their innovation in order to better understand
>> whether they're investing in a blind technology. Transport providers must
>> deploy and support more complicated configurations with their limited
>> funds, inevitably satisfying some an thwarting others.
>>
>> Would that the transfer market and all efforts to prolong IPv4 come to an
>> end quickly IMO.
>>
>> End of soapbox
>>
>> bd
>>
>>
>> On Mon, Feb 24, 2014 at 7:13 AM, John Curran <jcurran at arin.net> wrote:
>>
>>> On Feb 24, 2014, at 5:20 AM, Owen DeLong <owen at delong.com> wrote:
>>>
>>> > On Feb 23, 2014, at 6:32 PM, David Farmer <farmer at umn.edu> wrote:
>>> >> ...
>>> >> I've been thinking about this maybe the restrictions for
>>> anti-flipping don't belong in section 8 at all.  Maybe they belong in
>>> section 4 as they are intended to protect the ARIN IPv4 free pool.
>>> >
>>> > I disagree. I don't want to see flipping become a tool for speculation
>>> in the market post-exhaustion, any more than I want to see it become a tool
>>> for draining the free pool. In fact, I think that the former might be
>>> significantly more harmful than the latter at this point.
>>>
>>> Owen -
>>>
>>>   Could you elaborate your thoughts regarding the harm that might occur?
>>>
>>>   I believe that folks understand risks associated with
>>> sudden/unexpected IPv4 free
>>>   pool depletion, but you are suggesting that liquidity itself in the
>>> IPv4 transfer
>>>   market is harmful.  As that is neither obvious nor aligned with most
>>> market theory,
>>>   it would be best for you to elaborate your thoughts some on that
>>> aspect.
>>>
>>> Thanks!
>>> /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.
>>>
>>
>>
>>
>> _______________________________________________
>> 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.
>>
>
>
>
> --
> -george william herbert
> george.herbert at gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140224/acb8f7c3/attachment.htm>

From matthew at matthew.at  Mon Feb 24 23:07:24 2014
From: matthew at matthew.at (Matthew Kaufman)
Date: Mon, 24 Feb 2014 20:07:24 -0800
Subject: [arin-ppml] 2014-2 8.4 Anti-flip Language
In-Reply-To: <0858DDF3-553B-4E3B-92FD-2A52BCCE85FC@delong.com>
References: <2CB940E2-1465-4FED-A6F3-7172849A90EA@delong.com><CAGkMwz5HKPdCJ	BvXWRpvx2Uys0NJ6=TCDLTpszeJWg6V90vsXA@mail.gmail.com>	<D83E9DD2-07F5-4F73-B705-A171B3F47FA0@delong.com>	<5B9E90747FA2974D91A54FCFA1B8AD1201509C6268@ENI-MAIL.eclipse-networks.com>	<530AAF58.9080407@umn.edu>
	<0858DDF3-553B-4E3B-92FD-2A52BCCE85FC@delong.com>
Message-ID: <530C16FC.7070306@matthew.at>

On 2/24/2014 2:20 AM, Owen DeLong wrote:
> I disagree. I don?t want to see flipping become a tool for speculation 
> in the market post-exhaustion, any more than I want to see it become a 
> tool for draining the free pool. In fact, I think that the former 
> might be significantly more harmful than the latter at this point. 

I don't get it. You want everyone to switch to IPv6 as soon as possible, 
and yet you don't want the IPv4 market to experience speculation that is 
detrimental to continued use of IPv4?!?

> I don?t see a problem with that. I have no desire to encourage transfers as a primary choice. I think it is, in fact, just bad policy to do so. Transfers should, IMHO, be viewed as a last resort when free pool options have been exhausted.

I believe they'd be the "last" "first" and "only" resort, wouldn't they? 
I mean, if you *need* IPv4, and there's no free pool, what else can you do?

Matthew Kaufman


From matthew at matthew.at  Mon Feb 24 23:10:20 2014
From: matthew at matthew.at (Matthew Kaufman)
Date: Mon, 24 Feb 2014 20:10:20 -0800
Subject: [arin-ppml] 2014-2 8.4 Anti-flip Language
In-Reply-To: <CAMApp372etUJ36jw=NREDKLUy6sAtOV5PoJCwtutdNpDq40Q+Q@mail.gmail.com>
References: <2CB940E2-1465-4FED-A6F3-7172849A90EA@delong.com>	<D83E9DD2-07F5-4F73-B705-A171B3F47FA0@delong.com>	<5B9E90747FA2974D91A54FCFA1B8AD1201509C6268@ENI-MAIL.eclipse-networks.com>	<530AAF58.9080407@umn.edu>	<0858DDF3-553B-4E3B-92FD-2A52BCCE85FC@delong.com>	<407F662E-B241-4AC6-B8C9-A65C23DC0CB7@corp.arin.net>
	<CAMApp372etUJ36jw=NREDKLUy6sAtOV5PoJCwtutdNpDq40Q+Q@mail.gmail.com>
Message-ID: <530C17AC.1080609@matthew.at>

On 2/24/2014 6:33 AM, Bill Darte wrote:
> I'll not answer for Owen, but your question prompts me to say that the 
> transfer market is not a goodness.  It was, in my mind, a reasonable 
> yet distasteful stop gap on the way toward a once again more unified 
> protocol environment...to wit.. IPv6.
>
> My market theory suggest that transfer market at its free-est and most 
> open deters and confuses the way forward.  The purpose of standards is 
> to eliminate confusion and choices which require understanding 
> investment options and application consequences.  While standards have 
> their downside, one of them is not those elements of marketplace choice.
>
> The more options existing the more confused.  Investment=legacy. 
>  End-users must predict and interpret, making decisions that may come 
> back to haunt. Developers delay their innovation in order to better 
> understand whether they're investing in a blind technology. Transport 
> providers must deploy and support more complicated configurations with 
> their limited funds, inevitably satisfying some an thwarting others.
>
> Would that the transfer market and all efforts to prolong IPv4 come to 
> an end quickly IMO.
>
> End of soapbox
>

I will yet again point out, as I'm sure others will as well, that it 
hardly matters how large your soapbox when push comes to shove and 
someone who has money and needs more IPv4 space figures out that there's 
people willing to let them use other allocated space in exchange for 
some of that money.

If you wanted the outcome you propose, you should have made IPv6 
seamless to deploy and fully-featured for the people who need to deploy 
it some years ago. (Note that there are still ongoing arguments about 
the latter, to this very day)

Matthew Kaufman



From matthew at matthew.at  Mon Feb 24 23:14:01 2014
From: matthew at matthew.at (Matthew Kaufman)
Date: Mon, 24 Feb 2014 20:14:01 -0800
Subject: [arin-ppml] 2014-2 8.4 Anti-flip Language
In-Reply-To: <52C74E9A-3B9A-41B8-9115-1F69FEA6B9A7@delong.com>
References: <2CB940E2-1465-4FED-A6F3-7172849A90EA@delong.com>
	<"CAGkMwz5HKPdCJ	BvXWRpvx2Uys0NJ6=TCDLTpszeJWg6V90vsXA"@mail.gmail.com>	<D83E9DD2-07F5-4F73-B705-A171B3F47FA0@delong.com>	<5B9E90747FA2974D91A54FCFA1B8AD1201509C6268@ENI-MAIL.eclipse-networks.com>	<530AAF58.9080407@umn.edu>	<0858DDF3-553B-4E3B-92FD-2A52BCCE85FC@delong.com>	<407F662E-B241-4AC6-B8C9-A65C23DC0CB7@corp.arin.net>
	<52C74E9A-3B9A-41B8-9115-1F69FEA6B9A7@delong.com>
Message-ID: <530C1889.7050808@matthew.at>

On 2/24/2014 5:10 PM, Owen DeLong wrote:
> Look at the effect house flipping had on the California real estate 
> market. This has been harmful in a number of ways and I see no reason 
> to believe that similar behavior, if allowed, in the IP address realm 
> would not be even more harmful.

Because the people speculatively buying up /24s and giving them a coat 
of fresh paint and replacing the old carpet with new wood floors would 
do what, exactly?

Matthew Kaufman


From owen at delong.com  Tue Feb 25 00:16:25 2014
From: owen at delong.com (Owen DeLong)
Date: Mon, 24 Feb 2014 21:16:25 -0800
Subject: [arin-ppml] 2014-2 8.4 Anti-flip Language
In-Reply-To: <530C1889.7050808@matthew.at>
References: <2CB940E2-1465-4FED-A6F3-7172849A90EA@delong.com>
	<"CAGkMwz5HKPdCJ	BvXWRpvx2Uys0NJ6=TCDLTpszeJWg6V90vsXA"@mail.gmail.com>	<D83E9DD2-07F5-4F73-B705-A171B3F47FA0@delong.com>	<5B9E90747FA2974D91A54FCFA1B8AD1201509C6268@ENI-MAIL.eclipse-networks.com>	<530AAF58.9080407@umn.edu>	<0858DDF3-553B-4E3B-92FD-2A52BCCE85FC@delong.com>	<407F662E-B241-4AC6-B8C9-A65C23DC0CB7@corp.arin.net>
	<52C74E9A-3B9A-41B8-9115-1F69FEA6B9A7@delong.com>
	<530C1889.7050808@matthew.at>
Message-ID: <6577EF51-2BEA-47D2-8D5A-F7FA2552A03B@delong.com>


On Feb 24, 2014, at 8:14 PM, Matthew Kaufman <matthew at matthew.at> wrote:

> On 2/24/2014 5:10 PM, Owen DeLong wrote:
>> Look at the effect house flipping had on the California real estate market. This has been harmful in a number of ways and I see no reason to believe that similar behavior, if allowed, in the IP address realm would not be even more harmful.
> 
> Because the people speculatively buying up /24s and giving them a coat of fresh paint and replacing the old carpet with new wood floors would do what, exactly?

First, you are assuming that all speculative IP purchases would be for flipping. In this case, there is a motivation also available for speculation in terms of attempting to deprive other organizations of the ability to compete. It allows heavily resourced organizations to distort the competitive landscape and would thus be an unfair policy. (Fair is one of the requirements for the AC to advance policy).

Second, speculators purchasing addresses in hopes of flipping them (perhaps purchasing black-listed addresses, getting them off the BLs, and then reselling them) would also be looking to make a profit and would likely distort the pricing of said addresses in the process. Such distortions, when they occur, are rarely to the benefit of the overall community.

Owen



From ajs at anvilwalrusden.com  Tue Feb 25 00:19:50 2014
From: ajs at anvilwalrusden.com (Andrew Sullivan)
Date: Tue, 25 Feb 2014 00:19:50 -0500
Subject: [arin-ppml] 2014-2 8.4 Anti-flip Language
In-Reply-To: <52C74E9A-3B9A-41B8-9115-1F69FEA6B9A7@delong.com>
References: <2CB940E2-1465-4FED-A6F3-7172849A90EA@delong.com>
	<"CAGkMwz5HKPdCJBvXWRpvx2Uys0NJ6=TCDLTpszeJWg6V90vsXA"@mail.gmail.com>
	<D83E9DD2-07F5-4F73-B705-A171B3F47FA0@delong.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201509C6268@ENI-MAIL.eclipse-networks.com>
	<530AAF58.9080407@umn.edu>
	<0858DDF3-553B-4E3B-92FD-2A52BCCE85FC@delong.com>
	<407F662E-B241-4AC6-B8C9-A65C23DC0CB7@corp.arin.net>
	<52C74E9A-3B9A-41B8-9115-1F69FEA6B9A7@delong.com>
Message-ID: <20140225051950.GB73241@mx1.yitter.info>

On Mon, Feb 24, 2014 at 05:10:23PM -0800, Owen DeLong wrote:
> 
> Look at the effect house flipping had on the California real estate market.

That is a terrible analogy.  IPv4 space is very close to a pure
commodity, and moreover it is one for which there is an imperfect
substitute.  Also, despite the attempts of various (in my opinion,
misguided) people to nail IPv4 space to physical location, as a
practical matter you can move your IPv4 in a way you can't move your
house, much less your land.

If we are going to draw analogies with speculative markets, surely
commodity markets like grains, livestock, and textiles are better
analogies.  And indeed, such analogies are instructive, because
commodity markets in which there is massive speculation tends to drive
people to the alternatives, even if they're imperfect.  Raise the
price of coffee enough, and you find that chickory markets rise.
Indeed, I believe Lee Howard has presented an analysis that suggests
the tipping cost for abandoning IPv4 in favour of v6 is rather lower
than many people have imagined.  Even if he is off by some margin,
the benefits of strong regulation attempts on this sort of v4 market
activity are far from obvious.  They might actually be harmful, to the
extent they inspire people to devote energy to gaming the v4
regulations in stead of just working to move to v6.

Best regards,

Andrew

-- 
Andrew Sullivan
ajs at anvilwalrusden.com


From owen at delong.com  Tue Feb 25 00:12:46 2014
From: owen at delong.com (Owen DeLong)
Date: Mon, 24 Feb 2014 21:12:46 -0800
Subject: [arin-ppml] 2014-2 8.4 Anti-flip Language
In-Reply-To: <530C16FC.7070306@matthew.at>
References: <2CB940E2-1465-4FED-A6F3-7172849A90EA@delong.com><CAGkMwz5HKPdCJ	BvXWRpvx2Uys0NJ6=TCDLTpszeJWg6V90vsXA@mail.gmail.com>	<D83E9DD2-07F5-4F73-B705-A171B3F47FA0@delong.com>	<5B9E90747FA2974D91A54FCFA1B8AD1201509C6268@ENI-MAIL.eclipse-networks.com>	<530AAF58.9080407@umn.edu>
	<0858DDF3-553B-4E3B-92FD-2A52BCCE85FC@delong.com>
	<530C16FC.7070306@matthew.at>
Message-ID: <F9A29D0B-A779-4B75-98D5-D70163CCFB1E@delong.com>


On Feb 24, 2014, at 8:07 PM, Matthew Kaufman <matthew at matthew.at> wrote:

> On 2/24/2014 2:20 AM, Owen DeLong wrote:
>> I disagree. I don?t want to see flipping become a tool for speculation in the market post-exhaustion, any more than I want to see it become a tool for draining the free pool. In fact, I think that the former might be significantly more harmful than the latter at this point. 
> 
> I don't get it. You want everyone to switch to IPv6 as soon as possible, and yet you don't want the IPv4 market to experience speculation that is detrimental to continued use of IPv4?!?

This is because you are ignoring a certain reality of my situation.

Personally, I want everyone to switch. I believe that is best for the internet and best for everyone involved. I want to provide as many incentives and motivations to accomplish that.

However, as an AC member, my responsibility is to act as a good steward of the address space on behalf of the community. Speculation, while it may indirectly serve my personal goal above, will not directly serve the community and is definitely not good stewardship of the address space.

>> I don?t see a problem with that. I have no desire to encourage transfers as a primary choice. I think it is, in fact, just bad policy to do so. Transfers should, IMHO, be viewed as a last resort when free pool options have been exhausted.
> 
> I believe they'd be the "last" "first" and "only" resort, wouldn't they? I mean, if you *need* IPv4, and there's no free pool, what else can you do?

Currently, there is still a free pool. There are those that are advocating distorting policy to make transfers more attractive than draining obtaining addresses from the free pool in hopes of keeping the free pool around for an artificially long time. It is my opinion that such policies are harmful both in terms of creating an artificial extension of the lifetime of the free pool and in terms of distorting the free market aspects of managing transfer policy.

Owen



From jcurran at arin.net  Tue Feb 25 02:09:08 2014
From: jcurran at arin.net (John Curran)
Date: Tue, 25 Feb 2014 07:09:08 +0000
Subject: [arin-ppml] 2014-2 8.4 Anti-flip Language
In-Reply-To: <52C74E9A-3B9A-41B8-9115-1F69FEA6B9A7@delong.com>
References: <2CB940E2-1465-4FED-A6F3-7172849A90EA@delong.com>
	<"CAGkMwz5HKPdCJ	BvXWRpvx2Uys0NJ6=TCDLTpszeJWg6V90vsXA"@mail.gmail.com>
	<D83E9DD2-07F5-4F73-B705-A171B3F47FA0@delong.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201509C6268@ENI-MAIL.eclipse-networks.com>
	<530AAF58.9080407@umn.edu>
	<0858DDF3-553B-4E3B-92FD-2A52BCCE85FC@delong.com>
	<407F662E-B241-4AC6-B8C9-A65C23DC0CB7@corp.arin.net>
	<52C74E9A-3B9A-41B8-9115-1F69FEA6B9A7@delong.com>
Message-ID: <495871ED-5E5A-4B29-85E4-6FD718B64056@arin.net>

On Feb 24, 2014, at 5:10 PM, Owen DeLong <owen at delong.com> wrote:

> On Feb 24, 2014, at 5:13 AM, John Curran <jcurran at arin.net> wrote:
>> 
>> Could you elaborate your thoughts regarding the harm that might occur?
>> 
>> I believe that folks understand risks associated with sudden/unexpected IPv4 free
>> pool depletion, but you are suggesting that liquidity itself in the IPv4 transfer 
>> market is harmful.  As that is neither obvious nor aligned with most market theory, 
>> it would be best for you to elaborate your thoughts some on that aspect.
> 
> I?m not suggesting that liquidity is harmful, but I am suggesting that creating an environment that is friendly to market manipulators and speculators would be harmful.

Understood. 

Could you state directly the harm that you believe will occur in such an environment?   
This will help the ARIN AC in crafting a balanced draft policy document which includes 
the both the perceived benefits and risks associated with this approach.

Thanks!
/John

John Curran
President and CEO
ARIn



From SRyerse at eclipse-networks.com  Tue Feb 25 09:02:29 2014
From: SRyerse at eclipse-networks.com (Steven Ryerse)
Date: Tue, 25 Feb 2014 14:02:29 +0000
Subject: [arin-ppml] 2014-2 8.4 Anti-flip Language
In-Reply-To: <F9A29D0B-A779-4B75-98D5-D70163CCFB1E@delong.com>
References: <2CB940E2-1465-4FED-A6F3-7172849A90EA@delong.com><CAGkMwz5HKPdCJ
	BvXWRpvx2Uys0NJ6=TCDLTpszeJWg6V90vsXA@mail.gmail.com>	<D83E9DD2-07F5-4F73-
	B705-A171B3F47FA0@delong.com>	<5B9E90747FA2974D91A54FCFA1B8AD1201509C6268@E
	NI-MAIL.eclipse-networks.com>	<530AAF58.9080407@umn.edu><0858DDF3-553B-4E3B
	-92FD-2A52BCCE85FC@delong.com><530C16FC.7070306@matthew.at>,
	<F9A29D0B-A779-4B75-98D5-D70163CCFB1E@delong.com>
Message-ID: <EE5CCD0A-5172-43E4-AE31-C69FA9557289@eclipse-networks.com>

I would just point out that john postal gave out resources freely and let the market take the Internet where it wanted and a great thing happened. I think we should be following his model and I will keep advocating for it. 

Sent from my iPhone

> On Feb 25, 2014, at 12:23 AM, "Owen DeLong" <owen at delong.com> wrote:
> 
> 
>> On Feb 24, 2014, at 8:07 PM, Matthew Kaufman <matthew at matthew.at> wrote:
>> 
>>> On 2/24/2014 2:20 AM, Owen DeLong wrote:
>>> I disagree. I don?t want to see flipping become a tool for speculation in the market post-exhaustion, any more than I want to see it become a tool for draining the free pool. In fact, I think that the former might be significantly more harmful than the latter at this point. 
>> 
>> I don't get it. You want everyone to switch to IPv6 as soon as possible, and yet you don't want the IPv4 market to experience speculation that is detrimental to continued use of IPv4?!?
> 
> This is because you are ignoring a certain reality of my situation.
> 
> Personally, I want everyone to switch. I believe that is best for the internet and best for everyone involved. I want to provide as many incentives and motivations to accomplish that.
> 
> However, as an AC member, my responsibility is to act as a good steward of the address space on behalf of the community. Speculation, while it may indirectly serve my personal goal above, will not directly serve the community and is definitely not good stewardship of the address space.
> 
>>> I don?t see a problem with that. I have no desire to encourage transfers as a primary choice. I think it is, in fact, just bad policy to do so. Transfers should, IMHO, be viewed as a last resort when free pool options have been exhausted.
>> 
>> I believe they'd be the "last" "first" and "only" resort, wouldn't they? I mean, if you *need* IPv4, and there's no free pool, what else can you do?
> 
> Currently, there is still a free pool. There are those that are advocating distorting policy to make transfers more attractive than draining obtaining addresses from the free pool in hopes of keeping the free pool around for an artificially long time. It is my opinion that such policies are harmful both in terms of creating an artificial extension of the lifetime of the free pool and in terms of distorting the free market aspects of managing transfer policy.
> 
> 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  Tue Feb 25 11:28:10 2014
From: owen at delong.com (Owen DeLong)
Date: Tue, 25 Feb 2014 08:28:10 -0800
Subject: [arin-ppml] 2014-2 8.4 Anti-flip Language
In-Reply-To: <EE5CCD0A-5172-43E4-AE31-C69FA9557289@eclipse-networks.com>
References: <2CB940E2-1465-4FED-A6F3-7172849A90EA@delong.com><CAGkMwz5HKPdCJ
	BvXWRpvx2Uys0NJ6=TCDLTpszeJWg6V90vsXA@mail.gmail.com>	<D83E9DD2-07F5-4F73-
	B705-A171B3F47FA0@delong.com>	<5B9E90747FA2974D91A54FCFA1B8AD1201509C6268@E
	NI-MAIL.eclipse-networks.com>	<530AAF58.9080407@umn.edu><0858DDF3-553B-4E3B
	-92FD-2A52BCCE85FC@delong.com><530C16FC.7070306@matthew.at>,
	<F9A29D0B-A779-4B75-98D5-D70163CCFB1E@delong.com>
	<EE5CCD0A-5172-43E4-AE31-C69FA9557289@eclipse-networks.com>
Message-ID: <5D388A71-A937-4364-BCBB-70123E328FFF@delong.com>

I will point out that Jon Postel required organizations to show need for the resources before he gave them out and that the concept of selling address space was not really considered since addresses were plentiful and available for free. The implicit expectation (and indeed, the normal
behavior) of the time was that resources no longer needed were returned to the free pool.

Owen

On Feb 25, 2014, at 6:02 AM, Steven Ryerse <SRyerse at eclipse-networks.com> wrote:

> I would just point out that john postal gave out resources freely and let the market take the Internet where it wanted and a great thing happened. I think we should be following his model and I will keep advocating for it. 
> 
> Sent from my iPhone
> 
>> On Feb 25, 2014, at 12:23 AM, "Owen DeLong" <owen at delong.com> wrote:
>> 
>> 
>>> On Feb 24, 2014, at 8:07 PM, Matthew Kaufman <matthew at matthew.at> wrote:
>>> 
>>>> On 2/24/2014 2:20 AM, Owen DeLong wrote:
>>>> I disagree. I don?t want to see flipping become a tool for speculation in the market post-exhaustion, any more than I want to see it become a tool for draining the free pool. In fact, I think that the former might be significantly more harmful than the latter at this point. 
>>> 
>>> I don't get it. You want everyone to switch to IPv6 as soon as possible, and yet you don't want the IPv4 market to experience speculation that is detrimental to continued use of IPv4?!?
>> 
>> This is because you are ignoring a certain reality of my situation.
>> 
>> Personally, I want everyone to switch. I believe that is best for the internet and best for everyone involved. I want to provide as many incentives and motivations to accomplish that.
>> 
>> However, as an AC member, my responsibility is to act as a good steward of the address space on behalf of the community. Speculation, while it may indirectly serve my personal goal above, will not directly serve the community and is definitely not good stewardship of the address space.
>> 
>>>> I don?t see a problem with that. I have no desire to encourage transfers as a primary choice. I think it is, in fact, just bad policy to do so. Transfers should, IMHO, be viewed as a last resort when free pool options have been exhausted.
>>> 
>>> I believe they'd be the "last" "first" and "only" resort, wouldn't they? I mean, if you *need* IPv4, and there's no free pool, what else can you do?
>> 
>> Currently, there is still a free pool. There are those that are advocating distorting policy to make transfers more attractive than draining obtaining addresses from the free pool in hopes of keeping the free pool around for an artificially long time. It is my opinion that such policies are harmful both in terms of creating an artificial extension of the lifetime of the free pool and in terms of distorting the free market aspects of managing transfer policy.
>> 
>> 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 SRyerse at eclipse-networks.com  Tue Feb 25 14:51:31 2014
From: SRyerse at eclipse-networks.com (Steven Ryerse)
Date: Tue, 25 Feb 2014 19:51:31 +0000
Subject: [arin-ppml] 2014-2 8.4 Anti-flip Language
In-Reply-To: <5D388A71-A937-4364-BCBB-70123E328FFF@delong.com>
References: <2CB940E2-1465-4FED-A6F3-7172849A90EA@delong.com><CAGkMwz5HKPdCJ
	BvXWRpvx2Uys0NJ6=TCDLTpszeJWg6V90vsXA@mail.gmail.com>	<D83E9DD2-07F5-4F73-
	B705-A171B3F47FA0@delong.com>	<5B9E90747FA2974D91A54FCFA1B8AD1201509C6268@
	E 	NI-MAIL.eclipse-networks.com>
	<530AAF58.9080407@umn.edu><0858DDF3-553B-4E3B
	-92FD-2A52BCCE85FC@delong.com><530C16FC.7070306@matthew.at>,
	<F9A29D0B-A779 -4B75-98D5-D70163CCFB1E@delong.com>
	<EE5CCD0A-5172-43E4-AE31-C69FA9557289@eclipse-networks.com>
	<5D388A71-A937-4364-BCBB-70123E328FFF@delong.com>
Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD1201509C9656@ENI-MAIL.eclipse-networks.com>

I would point out that what he really did was size the block (A, B, or C) according to the organization's size and not their need.  When I applied for one Class C for my company he/Network Solutions  didn't ask me whether I needed it or not.  I was just asked who would be using it.  

Steven Ryerse
President
100 Ashford Center North, Suite 110, Atlanta, GA? 30338
770.656.1460 - Cell
770.399.9099- Office

? Eclipse Networks, Inc.
             ??????? Conquering Complex Networks?


-----Original Message-----
From: Owen DeLong [mailto:owen at delong.com] 
Sent: Tuesday, February 25, 2014 11:28 AM
To: Steven Ryerse
Cc: Matthew Kaufman; ARIN-PPML List
Subject: Re: [arin-ppml] 2014-2 8.4 Anti-flip Language

I will point out that Jon Postel required organizations to show need for the resources before he gave them out and that the concept of selling address space was not really considered since addresses were plentiful and available for free. The implicit expectation (and indeed, the normal
behavior) of the time was that resources no longer needed were returned to the free pool.

Owen

On Feb 25, 2014, at 6:02 AM, Steven Ryerse <SRyerse at eclipse-networks.com> wrote:

> I would just point out that john postal gave out resources freely and let the market take the Internet where it wanted and a great thing happened. I think we should be following his model and I will keep advocating for it. 
> 
> Sent from my iPhone
> 
>> On Feb 25, 2014, at 12:23 AM, "Owen DeLong" <owen at delong.com> wrote:
>> 
>> 
>>> On Feb 24, 2014, at 8:07 PM, Matthew Kaufman <matthew at matthew.at> wrote:
>>> 
>>>> On 2/24/2014 2:20 AM, Owen DeLong wrote:
>>>> I disagree. I don?t want to see flipping become a tool for speculation in the market post-exhaustion, any more than I want to see it become a tool for draining the free pool. In fact, I think that the former might be significantly more harmful than the latter at this point. 
>>> 
>>> I don't get it. You want everyone to switch to IPv6 as soon as possible, and yet you don't want the IPv4 market to experience speculation that is detrimental to continued use of IPv4?!?
>> 
>> This is because you are ignoring a certain reality of my situation.
>> 
>> Personally, I want everyone to switch. I believe that is best for the internet and best for everyone involved. I want to provide as many incentives and motivations to accomplish that.
>> 
>> However, as an AC member, my responsibility is to act as a good steward of the address space on behalf of the community. Speculation, while it may indirectly serve my personal goal above, will not directly serve the community and is definitely not good stewardship of the address space.
>> 
>>>> I don?t see a problem with that. I have no desire to encourage transfers as a primary choice. I think it is, in fact, just bad policy to do so. Transfers should, IMHO, be viewed as a last resort when free pool options have been exhausted.
>>> 
>>> I believe they'd be the "last" "first" and "only" resort, wouldn't they? I mean, if you *need* IPv4, and there's no free pool, what else can you do?
>> 
>> Currently, there is still a free pool. There are those that are advocating distorting policy to make transfers more attractive than draining obtaining addresses from the free pool in hopes of keeping the free pool around for an artificially long time. It is my opinion that such policies are harmful both in terms of creating an artificial extension of the lifetime of the free pool and in terms of distorting the free market aspects of managing transfer policy.
>> 
>> 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 george.herbert at gmail.com  Tue Feb 25 15:09:01 2014
From: george.herbert at gmail.com (George William Herbert)
Date: Tue, 25 Feb 2014 12:09:01 -0800
Subject: [arin-ppml] 2014-2 8.4 Anti-flip Language
In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD1201509C9656@ENI-MAIL.eclipse-networks.com>
References: <2CB940E2-1465-4FED-A6F3-7172849A90EA@delong.com> <CAGkMwz5HKPdCJ
	BvXWRpvx2Uys0NJ6=TCDLTpszeJWg6V90vsXA@mail.gmail.com>
	<D83E9DD2-07F5-4F73- B705-A171B3F47FA0@delong.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201509C6268@ E
	NI-MAIL.eclipse-networks.com> <530AAF58.9080407@umn.edu>
	<0858DDF3-553B-4E3B -92FD-2A52BCCE85FC@delong.com>
	<530C16FC.7070306@matthew.at> <F9A29D0B-A779
	-4B75-98D5-D70163CCFB1E@delong.com>
	<EE5CCD0A-5172-43E4-AE31-C69FA9557289@eclipse-networks.com>
	<5D388A71-A937-4364-BCBB-70123E328FFF@delong.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201509C9656@ENI-MAIL.eclipse-networks.com>
Message-ID: <0502EECC-293A-4C9C-B477-C818B75E0138@gmail.com>


Jon sadly did not live to see the days when exhaustion of v4 space was a looming reality.  Invoking his name in the debate is not useful; other than generally wanting everyone to be good stewards of the Internet as a whole, he never had to confront runout as stark reality.  We have no idea what nuanced opinions he would have come to espouse by now as we marched down to the end of the last 'virgin free blocks'.


-george william herbert
george.herbert at gmail.com

Sent from Kangphone

On Feb 25, 2014, at 11:51 AM, Steven Ryerse <SRyerse at eclipse-networks.com> wrote:

> I would point out that what he really did was size the block (A, B, or C) according to the organization's size and not their need.  When I applied for one Class C for my company he/Network Solutions  didn't ask me whether I needed it or not.  I was just asked who would be using it.  
> 
> Steven Ryerse
> President
> 100 Ashford Center North, Suite 110, Atlanta, GA  30338
> 770.656.1460 - Cell
> 770.399.9099- Office
> 
> ? Eclipse Networks, Inc.
>                     Conquering Complex Networks?
> 
> 
> -----Original Message-----
> From: Owen DeLong [mailto:owen at delong.com] 
> Sent: Tuesday, February 25, 2014 11:28 AM
> To: Steven Ryerse
> Cc: Matthew Kaufman; ARIN-PPML List
> Subject: Re: [arin-ppml] 2014-2 8.4 Anti-flip Language
> 
> I will point out that Jon Postel required organizations to show need for the resources before he gave them out and that the concept of selling address space was not really considered since addresses were plentiful and available for free. The implicit expectation (and indeed, the normal
> behavior) of the time was that resources no longer needed were returned to the free pool.
> 
> Owen
> 
> On Feb 25, 2014, at 6:02 AM, Steven Ryerse <SRyerse at eclipse-networks.com> wrote:
> 
>> I would just point out that john postal gave out resources freely and let the market take the Internet where it wanted and a great thing happened. I think we should be following his model and I will keep advocating for it. 
>> 
>> Sent from my iPhone
>> 
>>> On Feb 25, 2014, at 12:23 AM, "Owen DeLong" <owen at delong.com> wrote:
>>> 
>>> 
>>>> On Feb 24, 2014, at 8:07 PM, Matthew Kaufman <matthew at matthew.at> wrote:
>>>> 
>>>>> On 2/24/2014 2:20 AM, Owen DeLong wrote:
>>>>> I disagree. I don?t want to see flipping become a tool for speculation in the market post-exhaustion, any more than I want to see it become a tool for draining the free pool. In fact, I think that the former might be significantly more harmful than the latter at this point.
>>>> 
>>>> I don't get it. You want everyone to switch to IPv6 as soon as possible, and yet you don't want the IPv4 market to experience speculation that is detrimental to continued use of IPv4?!?
>>> 
>>> This is because you are ignoring a certain reality of my situation.
>>> 
>>> Personally, I want everyone to switch. I believe that is best for the internet and best for everyone involved. I want to provide as many incentives and motivations to accomplish that.
>>> 
>>> However, as an AC member, my responsibility is to act as a good steward of the address space on behalf of the community. Speculation, while it may indirectly serve my personal goal above, will not directly serve the community and is definitely not good stewardship of the address space.
>>> 
>>>>> I don?t see a problem with that. I have no desire to encourage transfers as a primary choice. I think it is, in fact, just bad policy to do so. Transfers should, IMHO, be viewed as a last resort when free pool options have been exhausted.
>>>> 
>>>> I believe they'd be the "last" "first" and "only" resort, wouldn't they? I mean, if you *need* IPv4, and there's no free pool, what else can you do?
>>> 
>>> Currently, there is still a free pool. There are those that are advocating distorting policy to make transfers more attractive than draining obtaining addresses from the free pool in hopes of keeping the free pool around for an artificially long time. It is my opinion that such policies are harmful both in terms of creating an artificial extension of the lifetime of the free pool and in terms of distorting the free market aspects of managing transfer policy.
>>> 
>>> 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.
> 
> _______________________________________________
> 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 SRyerse at eclipse-networks.com  Tue Feb 25 15:11:58 2014
From: SRyerse at eclipse-networks.com (Steven Ryerse)
Date: Tue, 25 Feb 2014 20:11:58 +0000
Subject: [arin-ppml] 2014-2 8.4 Anti-flip Language
In-Reply-To: <0502EECC-293A-4C9C-B477-C818B75E0138@gmail.com>
References: <2CB940E2-1465-4FED-A6F3-7172849A90EA@delong.com>
	<CAGkMwz5HKPdCJ BvXWRpvx2Uys0NJ6=TCDLTpszeJWg6V90vsXA@mail.gmail.com>
	<D83E9DD2-07F5-4F73- B705-A171B3F47FA0@delong.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201509C6268@ E
	NI-MAIL.eclipse-networks.com> <530AAF58.9080407@umn.edu>
	<0858DDF3-553B-4E3B -92FD-2A52BCCE85FC@delong.com>
	<530C16FC.7070306@matthew.at> <F9A29D0B-A779
	-4B75-98D5-D70163CCFB1E@delong.com>
	<EE5CCD0A-5172-43E4-AE31-C69FA9557289@eclipse-networks.com>
	<5D388A71-A937-4364-BCBB-70123E328FFF@delong.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201509C9656@ENI-MAIL.eclipse-networks.com>
	<0502EECC-293A-4C9C-B477-C818B75E0138@gmail.com>
Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD1201509C9786@ENI-MAIL.eclipse-networks.com>

Nope but we sure know his model of getting blocks out there worked and we should strive to continue that model of allocating right sized blocks as they are requested.

Steven Ryerse
President
100 Ashford Center North, Suite 110, Atlanta, GA? 30338
770.656.1460 - Cell
770.399.9099- Office

? Eclipse Networks, Inc.
             ??????? Conquering Complex Networks?


-----Original Message-----
From: George William Herbert [mailto:george.herbert at gmail.com] 
Sent: Tuesday, February 25, 2014 3:09 PM
To: Steven Ryerse; Owen DeLong
Cc: ARIN-PPML List
Subject: Re: [arin-ppml] 2014-2 8.4 Anti-flip Language


Jon sadly did not live to see the days when exhaustion of v4 space was a looming reality.  Invoking his name in the debate is not useful; other than generally wanting everyone to be good stewards of the Internet as a whole, he never had to confront runout as stark reality.  We have no idea what nuanced opinions he would have come to espouse by now as we marched down to the end of the last 'virgin free blocks'.


-george william herbert
george.herbert at gmail.com

Sent from Kangphone

On Feb 25, 2014, at 11:51 AM, Steven Ryerse <SRyerse at eclipse-networks.com> wrote:

> I would point out that what he really did was size the block (A, B, or C) according to the organization's size and not their need.  When I applied for one Class C for my company he/Network Solutions  didn't ask me whether I needed it or not.  I was just asked who would be using it.  
> 
> Steven Ryerse
> President
> 100 Ashford Center North, Suite 110, Atlanta, GA  30338
> 770.656.1460 - Cell
> 770.399.9099- Office
> 
> ? Eclipse Networks, Inc.
>                     Conquering Complex Networks?
> 
> 
> -----Original Message-----
> From: Owen DeLong [mailto:owen at delong.com]
> Sent: Tuesday, February 25, 2014 11:28 AM
> To: Steven Ryerse
> Cc: Matthew Kaufman; ARIN-PPML List
> Subject: Re: [arin-ppml] 2014-2 8.4 Anti-flip Language
> 
> I will point out that Jon Postel required organizations to show need 
> for the resources before he gave them out and that the concept of 
> selling address space was not really considered since addresses were 
> plentiful and available for free. The implicit expectation (and 
> indeed, the normal
> behavior) of the time was that resources no longer needed were returned to the free pool.
> 
> Owen
> 
> On Feb 25, 2014, at 6:02 AM, Steven Ryerse <SRyerse at eclipse-networks.com> wrote:
> 
>> I would just point out that john postal gave out resources freely and let the market take the Internet where it wanted and a great thing happened. I think we should be following his model and I will keep advocating for it. 
>> 
>> Sent from my iPhone
>> 
>>> On Feb 25, 2014, at 12:23 AM, "Owen DeLong" <owen at delong.com> wrote:
>>> 
>>> 
>>>> On Feb 24, 2014, at 8:07 PM, Matthew Kaufman <matthew at matthew.at> wrote:
>>>> 
>>>>> On 2/24/2014 2:20 AM, Owen DeLong wrote:
>>>>> I disagree. I don?t want to see flipping become a tool for speculation in the market post-exhaustion, any more than I want to see it become a tool for draining the free pool. In fact, I think that the former might be significantly more harmful than the latter at this point.
>>>> 
>>>> I don't get it. You want everyone to switch to IPv6 as soon as possible, and yet you don't want the IPv4 market to experience speculation that is detrimental to continued use of IPv4?!?
>>> 
>>> This is because you are ignoring a certain reality of my situation.
>>> 
>>> Personally, I want everyone to switch. I believe that is best for the internet and best for everyone involved. I want to provide as many incentives and motivations to accomplish that.
>>> 
>>> However, as an AC member, my responsibility is to act as a good steward of the address space on behalf of the community. Speculation, while it may indirectly serve my personal goal above, will not directly serve the community and is definitely not good stewardship of the address space.
>>> 
>>>>> I don?t see a problem with that. I have no desire to encourage transfers as a primary choice. I think it is, in fact, just bad policy to do so. Transfers should, IMHO, be viewed as a last resort when free pool options have been exhausted.
>>>> 
>>>> I believe they'd be the "last" "first" and "only" resort, wouldn't they? I mean, if you *need* IPv4, and there's no free pool, what else can you do?
>>> 
>>> Currently, there is still a free pool. There are those that are advocating distorting policy to make transfers more attractive than draining obtaining addresses from the free pool in hopes of keeping the free pool around for an artificially long time. It is my opinion that such policies are harmful both in terms of creating an artificial extension of the lifetime of the free pool and in terms of distorting the free market aspects of managing transfer policy.
>>> 
>>> 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.
> 
> _______________________________________________
> 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 Feb 25 17:05:36 2014
From: owen at delong.com (Owen DeLong)
Date: Tue, 25 Feb 2014 14:05:36 -0800
Subject: [arin-ppml] 2014-2 8.4 Anti-flip Language
In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD1201509C9656@ENI-MAIL.eclipse-networks.com>
References: <2CB940E2-1465-4FED-A6F3-7172849A90EA@delong.com> <CAGkMwz5HKPdCJ
	BvXWRpvx2Uys0NJ6=TCDLTpszeJWg6V90vsXA@mail.gmail.com>
	<D83E9DD2-07F5-4F73- B705-A171B3F47FA0@delong.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201509C6268@ E
	NI-MAIL.eclipse-networks.com> <530AAF58.9080407@umn.edu>
	<0858DDF3-553B-4E3B -92FD-2A52BCCE85FC@delong.com>
	<530C16FC.7070306@matthew.at> <F9A29D0B-A779
	-4B75-98D5-D70163CCFB1E@delong.com>
	<EE5CCD0A-5172-43E4-AE31-C69FA9557289@eclipse-networks.com>
	<5D388A71-A937-4364-BCBB-70123E328FFF@delong.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201509C9656@ENI-MAIL.eclipse-networks.com>
Message-ID: <1C9B9DA8-061A-493B-8FDD-E21A76529217@delong.com>

While I would agree that the definition of need has become more precise over time, the reality was that they not only asked who, but also asked why... If you weren't connecting to the internet, you needed to show some other reason that you needed ip addresses. 

Owen

> On Feb 25, 2014, at 11:51, Steven Ryerse <SRyerse at eclipse-networks.com> wrote:
> 
> I would point out that what he really did was size the block (A, B, or C) according to the organization's size and not their need.  When I applied for one Class C for my company he/Network Solutions  didn't ask me whether I needed it or not.  I was just asked who would be using it.  
> 
> Steven Ryerse
> President
> 100 Ashford Center North, Suite 110, Atlanta, GA  30338
> 770.656.1460 - Cell
> 770.399.9099- Office
> 
> ? Eclipse Networks, Inc.
>                     Conquering Complex Networks?
> 
> 
> -----Original Message-----
> From: Owen DeLong [mailto:owen at delong.com] 
> Sent: Tuesday, February 25, 2014 11:28 AM
> To: Steven Ryerse
> Cc: Matthew Kaufman; ARIN-PPML List
> Subject: Re: [arin-ppml] 2014-2 8.4 Anti-flip Language
> 
> I will point out that Jon Postel required organizations to show need for the resources before he gave them out and that the concept of selling address space was not really considered since addresses were plentiful and available for free. The implicit expectation (and indeed, the normal
> behavior) of the time was that resources no longer needed were returned to the free pool.
> 
> Owen
> 
>> On Feb 25, 2014, at 6:02 AM, Steven Ryerse <SRyerse at eclipse-networks.com> wrote:
>> 
>> I would just point out that john postal gave out resources freely and let the market take the Internet where it wanted and a great thing happened. I think we should be following his model and I will keep advocating for it. 
>> 
>> Sent from my iPhone
>> 
>>> On Feb 25, 2014, at 12:23 AM, "Owen DeLong" <owen at delong.com> wrote:
>>> 
>>> 
>>>>> On Feb 24, 2014, at 8:07 PM, Matthew Kaufman <matthew at matthew.at> wrote:
>>>>> 
>>>>> On 2/24/2014 2:20 AM, Owen DeLong wrote:
>>>>> I disagree. I don?t want to see flipping become a tool for speculation in the market post-exhaustion, any more than I want to see it become a tool for draining the free pool. In fact, I think that the former might be significantly more harmful than the latter at this point. 
>>>> 
>>>> I don't get it. You want everyone to switch to IPv6 as soon as possible, and yet you don't want the IPv4 market to experience speculation that is detrimental to continued use of IPv4?!?
>>> 
>>> This is because you are ignoring a certain reality of my situation.
>>> 
>>> Personally, I want everyone to switch. I believe that is best for the internet and best for everyone involved. I want to provide as many incentives and motivations to accomplish that.
>>> 
>>> However, as an AC member, my responsibility is to act as a good steward of the address space on behalf of the community. Speculation, while it may indirectly serve my personal goal above, will not directly serve the community and is definitely not good stewardship of the address space.
>>> 
>>>>> I don?t see a problem with that. I have no desire to encourage transfers as a primary choice. I think it is, in fact, just bad policy to do so. Transfers should, IMHO, be viewed as a last resort when free pool options have been exhausted.
>>>> 
>>>> I believe they'd be the "last" "first" and "only" resort, wouldn't they? I mean, if you *need* IPv4, and there's no free pool, what else can you do?
>>> 
>>> Currently, there is still a free pool. There are those that are advocating distorting policy to make transfers more attractive than draining obtaining addresses from the free pool in hopes of keeping the free pool around for an artificially long time. It is my opinion that such policies are harmful both in terms of creating an artificial extension of the lifetime of the free pool and in terms of distorting the free market aspects of managing transfer policy.
>>> 
>>> 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 dogwallah at gmail.com  Tue Feb 25 17:38:05 2014
From: dogwallah at gmail.com (McTim)
Date: Tue, 25 Feb 2014 17:38:05 -0500
Subject: [arin-ppml] 2014-2 8.4 Anti-flip Language
In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD1201509C9786@ENI-MAIL.eclipse-networks.com>
References: <2CB940E2-1465-4FED-A6F3-7172849A90EA@delong.com>
	<530AAF58.9080407@umn.edu> <530C16FC.7070306@matthew.at>
	<EE5CCD0A-5172-43E4-AE31-C69FA9557289@eclipse-networks.com>
	<5D388A71-A937-4364-BCBB-70123E328FFF@delong.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201509C9656@ENI-MAIL.eclipse-networks.com>
	<0502EECC-293A-4C9C-B477-C818B75E0138@gmail.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201509C9786@ENI-MAIL.eclipse-networks.com>
Message-ID: <CACAaNxhG8DnxDqVua2AxeS159Je5bwGMFSmjm=RWgXO4m_A5rQ@mail.gmail.com>

On Tue, Feb 25, 2014 at 3:11 PM, Steven Ryerse <SRyerse at eclipse-networks.com
> wrote:

> Nope but we sure know his model of getting blocks out there worked and we
> should strive to continue that model of allocating right sized blocks as
> they are requested.
>


and in retrospect, many were not exactly "right sized".


-- 
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/20140225/c5100446/attachment.htm>

From SRyerse at eclipse-networks.com  Tue Feb 25 17:40:03 2014
From: SRyerse at eclipse-networks.com (Steven Ryerse)
Date: Tue, 25 Feb 2014 22:40:03 +0000
Subject: [arin-ppml] 2014-2 8.4 Anti-flip Language
In-Reply-To: <CACAaNxhG8DnxDqVua2AxeS159Je5bwGMFSmjm=RWgXO4m_A5rQ@mail.gmail.com>
References: <2CB940E2-1465-4FED-A6F3-7172849A90EA@delong.com><530AAF58.90804
	07@umn.edu> <530C16FC.7070306@matthew.at>
	<EE5CCD0A-5172-43E4-AE31-C69FA9557289@eclipse-networks.com><5D388A71-A937-4
	364-BCBB-70123E328FFF@delong.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201509C9656@ENI-MAIL.eclipse-networks.com><
	0502EECC-293A-4C9C-B477-C818B75E0138@gmail.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201509C9786@ENI-MAIL.eclipse-networks.com>
	<CACAaNxhG8DnxDqVua2AxeS159Je5bwGMFSmjm=RWgXO4m_A5rQ@mail.gmail.com>
Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD1201509C9C4E@ENI-MAIL.eclipse-networks.com>

I would agree and I am definitely for right sizing them today.  Cheers.

Steven Ryerse
President
100 Ashford Center North, Suite 110, Atlanta, GA  30338
770.656.1460 - Cell
770.399.9099- Office

[Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc.
        Conquering Complex Networks?

From: McTim [mailto:dogwallah at gmail.com]
Sent: Tuesday, February 25, 2014 5:38 PM
To: Steven Ryerse
Cc: George William Herbert; Owen DeLong; ARIN-PPML List
Subject: Re: [arin-ppml] 2014-2 8.4 Anti-flip Language



On Tue, Feb 25, 2014 at 3:11 PM, Steven Ryerse <SRyerse at eclipse-networks.com<mailto:SRyerse at eclipse-networks.com>> wrote:
Nope but we sure know his model of getting blocks out there worked and we should strive to continue that model of allocating right sized blocks as they are requested.


and in retrospect, many were not exactly "right sized".


--
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/20140225/eb06b3e1/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 1468 bytes
Desc: image001.jpg
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140225/eb06b3e1/attachment.jpg>

From mysidia at gmail.com  Tue Feb 25 20:09:42 2014
From: mysidia at gmail.com (Jimmy Hess)
Date: Tue, 25 Feb 2014 19:09:42 -0600
Subject: [arin-ppml] 2014-2 8.4 Anti-flip Language
In-Reply-To: <20140225051950.GB73241@mx1.yitter.info>
References: <2CB940E2-1465-4FED-A6F3-7172849A90EA@delong.com>
	<CAGkMwz5HKPdCJBvXWRpvx2Uys0NJ6=TCDLTpszeJWg6V90vsXA@mail.gmail.com>
	<D83E9DD2-07F5-4F73-B705-A171B3F47FA0@delong.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201509C6268@ENI-MAIL.eclipse-networks.com>
	<530AAF58.9080407@umn.edu>
	<0858DDF3-553B-4E3B-92FD-2A52BCCE85FC@delong.com>
	<407F662E-B241-4AC6-B8C9-A65C23DC0CB7@corp.arin.net>
	<52C74E9A-3B9A-41B8-9115-1F69FEA6B9A7@delong.com>
	<20140225051950.GB73241@mx1.yitter.info>
Message-ID: <CAAAwwbXgZR-=i7+2Y=iirvJL1NJ8O7VgjHoV0G33aJ+kHC==mA@mail.gmail.com>

On Mon, Feb 24, 2014 at 11:19 PM, Andrew Sullivan <ajs at anvilwalrusden.com>wrote:

> On Mon, Feb 24, 2014 at 05:10:23PM -0800, Owen DeLong wrote:
> > Look at the effect house flipping had on the California real estate
> market.
> That is a terrible analogy.  IPv4 space is very close to a pure
> commodity, and moreover it is one for which there is an imperfect
> substitute.  Also, despite the attempts of various (in my opinion,
>

Have you tried renumbering an IP network, after IP addresses have been
assigned?

Real-estate,  or a piece of  'virtual land'  inside the TCP/IP world is a
more apt comparison, than a commodity.

A  /32  would be the virtual plot of IPv4 land required for a digital
single-family home.
A  /24  would be a subdivision, or an apartment building.
A  /16  would be a small city.

Of course land that has never been used can easily be traded between
real-estate developers,  with no repurcussions -----  but as soon as   you
have production tenants;
"renumbering"  or    selling off    can no longer be done without great
pains.



> misguided) people to nail IPv4 space to physical location, as a
> practical matter you can move your IPv4 in a way you can't move your
> house, much less your land.
>

You can't move IPv4 addresses either.      You can only change what they
are assigned to in the physical world;   inside the IPv4 world, every IP
address is always located at exactly the same position within the IPv4
address space.


> If we are going to draw analogies with speculative markets, surely
> commodity markets like grains, livestock, and textiles are better
> analogies.  And indeed, such analogies are instructive, because
>

Grains and livestock are consumables with finite lifetimes,  and textiles
wear out quickly;  there is high predictable future demand for these items
which are needed in massive quantities,   since members of the population
never stop needing to eat or wear clothing every day,  they are therefore
very large highly liquid markets.

As for IPv4 addresses.....  they never wear out.   Each address satisfies a
single device,  when the device is replaced --- the IP continues to be
useful.      There is not demand for  "massive IP address production",
nor  is there likely to be liquidity,  due to the problems with renumbering
networks.


2 Billion IP addresses is a TINY drop in a tiny bucket,  compared to the
number of units of  grains,  livestock, and textiles  required by consumers
every  month.



> commodity markets in which there is massive speculation tends to drive
> people to the alternatives, even if they're imperfect.  Raise the
>

The alternatives aren't just imperfect;  they are deficient, in the sense,
 that many of the  alternatives  don't work today,  cause major problems,
or can't work.

So massive speculation is apparently equivalent to "damage" or "harm".



> than many people have imagined.  Even if he is off by some margin,
> the benefits of strong regulation attempts on this sort of v4 market
> activity are far from obvious.  They might actually be harmful, to the
> extent they inspire people to devote energy to gaming the v4
> regulations in stead of just working to move to v6.
>

On the flip side...  ARIN doesn't need to facilitate anyone's attempt to
create a market in the first place.

Now is not the time to abandon principles of stewardship.




> Best regards,
>
> Andrew
>
> --
> Andrew Sullivan
> ajs at anvilwalrusden.com
>
> --
-JH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140225/1f782fa8/attachment.htm>

From ajs at anvilwalrusden.com  Tue Feb 25 20:40:55 2014
From: ajs at anvilwalrusden.com (Andrew Sullivan)
Date: Tue, 25 Feb 2014 20:40:55 -0500
Subject: [arin-ppml] 2014-2 8.4 Anti-flip Language
In-Reply-To: <CAAAwwbXgZR-=i7+2Y=iirvJL1NJ8O7VgjHoV0G33aJ+kHC==mA@mail.gmail.com>
References: <2CB940E2-1465-4FED-A6F3-7172849A90EA@delong.com>
	<CAGkMwz5HKPdCJBvXWRpvx2Uys0NJ6=TCDLTpszeJWg6V90vsXA@mail.gmail.com>
	<D83E9DD2-07F5-4F73-B705-A171B3F47FA0@delong.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201509C6268@ENI-MAIL.eclipse-networks.com>
	<530AAF58.9080407@umn.edu>
	<0858DDF3-553B-4E3B-92FD-2A52BCCE85FC@delong.com>
	<407F662E-B241-4AC6-B8C9-A65C23DC0CB7@corp.arin.net>
	<52C74E9A-3B9A-41B8-9115-1F69FEA6B9A7@delong.com>
	<20140225051950.GB73241@mx1.yitter.info>
	<CAAAwwbXgZR-=i7+2Y=iirvJL1NJ8O7VgjHoV0G33aJ+kHC==mA@mail.gmail.com>
Message-ID: <20140226014055.GC38432@mx1.yitter.info>

On Tue, Feb 25, 2014 at 07:09:42PM -0600, Jimmy Hess wrote:

> Have you tried renumbering an IP network, after IP addresses have been
> assigned?

Yes, but not (admittedly) as an ISP, where I can certainly appreciate
the issues.  All analogies are, in some ways, false, or they wouldn't
be analogies.  They'd be identities.

> every IP address is always located at exactly the same position
> within the IPv4 address space.

That's just equivocation on "move", and I don't see how it's relevant.

> The alternatives aren't just imperfect;  they are deficient, in the sense,
>  that many of the  alternatives  don't work today,  cause major problems,
> or can't work.

If you're arguing that IPv6 just isn't an alternative to IPv4 and
can't be used that way, however imperfect it is (e.g. admitting that
there are still lots of v4-only parts of the Internet), then you're
going to need to show not only that v6 is doomed in that way but also
that there is any hope whatsoever in trying to extend the v4 life
meaningfully and that the proposed policy will actually be effective.
If v4 is both as valuable as you suggest and as scarce as we think,
then I think tight regulation is likely to result in a black market
(and I suggest that economic history supports that opinion).  There
are reasons to suppose this is sort of happening sometimes today, and
I think the burden is on those who'd promote tight regulation to
address those possible negative consequences.
 
> So massive speculation is apparently equivalent to "damage" or "harm".

It's a kind of harm.  There's a trade-off.  Speculation in land and
houses is doubtless a consequence of a market in property.  The
question is whether a particular result is worth the costs imposed by
attempting to address it, particularly since nearly every policy
action has externalized consequences.  One way to prevent land
speculation is serfdom, for instance.  Do we think that would be
better?  We appear to have decided not.

> On the flip side...  ARIN doesn't need to facilitate anyone's attempt to
> create a market in the first place.

The idea that, in a monetized world such as ours, it will be possible
to prevent such a market for real is, I would like to suggest, a
little optimistic.  It seems to me that the question is much more
whether transfers of this sort will happen in public (i.e. registered
with ARIN) or not (e.g. by address holders effectively transferring
without actually doing so).  I would prefer the former result.  I
think that's better stewardship.

Best regards,

A

-- 
Andrew Sullivan
ajs at anvilwalrusden.com


From narten at us.ibm.com  Fri Feb 28 00:53:03 2014
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 28 Feb 2014 00:53:03 -0500
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201402280553.s1S5r30e016383@rotala.raleigh.ibm.com>

Total of 44 messages in the last 7 days.
 
script run at: Fri Feb 28 00:53:02 EST 2014
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 22.73% |   10 | 21.16% |   106747 | owen at delong.com
 11.36% |    5 | 15.80% |    79740 | sryerse at eclipse-networks.com
 11.36% |    5 | 14.10% |    71138 | billdarte at gmail.com
  9.09% |    4 |  6.55% |    33070 | jcurran at arin.net
  6.82% |    3 |  7.78% |    39238 | george.herbert at gmail.com
  4.55% |    2 |  9.52% |    48042 | rudi.daniel at gmail.com
  6.82% |    3 |  6.55% |    33067 | mysidia at gmail.com
  6.82% |    3 |  3.42% |    17281 | matthew at matthew.at
  4.55% |    2 |  2.72% |    13733 | ajs at anvilwalrusden.com
  2.27% |    1 |  2.76% |    13933 | scottleibrand at gmail.com
  2.27% |    1 |  1.96% |     9909 | gdendy at equinix.com
  2.27% |    1 |  1.83% |     9219 | farmer at umn.edu
  2.27% |    1 |  1.61% |     8120 | gary.buhrmaster at gmail.com
  2.27% |    1 |  1.50% |     7569 | dogwallah at gmail.com
  2.27% |    1 |  1.42% |     7186 | bill at herrin.us
  2.27% |    1 |  1.31% |     6587 | narten at us.ibm.com
--------+------+--------+----------+------------------------
100.00% |   44 |100.00% |   504579 | Total