<p dir="ltr">I Support for /24.</p>
<p dir="ltr">RD</p>
<div class="gmail_quote">On Jul 8, 2014 7:42 PM, <<a href="mailto:arin-ppml-request@arin.net">arin-ppml-request@arin.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Send ARIN-PPML mailing list submissions to<br>
<a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:arin-ppml-request@arin.net">arin-ppml-request@arin.net</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:arin-ppml-owner@arin.net">arin-ppml-owner@arin.net</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of ARIN-PPML digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Weekly posting summary for <a href="mailto:ppml@arin.net">ppml@arin.net</a> (Thomas Narten)<br>
2. comment - Draft Policy ARIN-2013-8 (Mike Mazarick)<br>
3. Re: comment - Draft Policy ARIN-2013-8 (Matthew Kaufman)<br>
4. Re: LAST CALL: Recommended Draft Policy ARIN-2014-12:<br>
Anti-hijack Policy (Matthew Kaufman)<br>
5. Re: LAST CALL: Recommended Draft Policy ARIN-2014-13: Reduce<br>
All Minimum Allocation/Assignment Units to /24 (Matthew Kaufman)<br>
6. Re: LAST CALL: Recommended Draft Policy ARIN-2014-5: Remove<br>
7.2 Lame Delegations (Matthew Kaufman)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Fri, 04 Jul 2014 00:53:03 -0400<br>
From: Thomas Narten <<a href="mailto:narten@us.ibm.com">narten@us.ibm.com</a>><br>
To: <a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a><br>
Subject: [arin-ppml] Weekly posting summary for <a href="mailto:ppml@arin.net">ppml@arin.net</a><br>
Message-ID: <<a href="mailto:201407040453.s644r3WZ016040@rotala.raleigh.ibm.com">201407040453.s644r3WZ016040@rotala.raleigh.ibm.com</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
Total of 22 messages in the last 7 days.<br>
<br>
script run at: Fri Jul 4 00:53:03 EDT 2014<br>
<br>
Messages | Bytes | Who<br>
--------+------+--------+----------+------------------------<br>
22.73% | 5 | 15.74% | 65269 | <a href="mailto:hannigan@gmail.com">hannigan@gmail.com</a><br>
18.18% | 4 | 19.71% | 81738 | <a href="mailto:cja@daydream.com">cja@daydream.com</a><br>
4.55% | 1 | 31.02% | 128615 | <a href="mailto:derekc@cnets.net">derekc@cnets.net</a><br>
13.64% | 3 | 12.68% | 52580 | <a href="mailto:scottleibrand@gmail.com">scottleibrand@gmail.com</a><br>
13.64% | 3 | 4.31% | 17863 | <a href="mailto:jcurran@arin.net">jcurran@arin.net</a><br>
4.55% | 1 | 5.31% | 22027 | <a href="mailto:mpetach@netflight.com">mpetach@netflight.com</a><br>
4.55% | 1 | 3.88% | 16098 | <a href="mailto:celestea@usc.edu">celestea@usc.edu</a><br>
4.55% | 1 | 2.26% | 9382 | <a href="mailto:khatfield@socllc.net">khatfield@socllc.net</a><br>
4.55% | 1 | 2.15% | 8917 | <a href="mailto:info@arin.net">info@arin.net</a><br>
4.55% | 1 | 1.73% | 7180 | <a href="mailto:narten@us.ibm.com">narten@us.ibm.com</a><br>
4.55% | 1 | 1.19% | 4948 | <a href="mailto:john@egh.com">john@egh.com</a><br>
--------+------+--------+----------+------------------------<br>
100.00% | 22 |100.00% | 414617 | Total<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Tue, 8 Jul 2014 16:57:45 -0400<br>
From: "Mike Mazarick" <<a href="mailto:mike.mazarick@virtudatacenter.com">mike.mazarick@virtudatacenter.com</a>><br>
To: <<a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a>><br>
Subject: [arin-ppml] comment - Draft Policy ARIN-2013-8<br>
Message-ID:<br>
<01c001cf9aef$45776eb0$d0664c10$@<a href="mailto:mazarick@virtudatacenter.com">mazarick@virtudatacenter.com</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
RE: Recommended Draft Policy ARIN-2013-8<br>
<br>
My comments:<br>
<br>
All of computer science is made up of allocating storage (memory/disk),<br>
de-allocating storage, or moving bits around. Like all organizations, the<br>
current situation we are all in (exhaustion of IPv4 addresses) is due to an<br>
improper de-allocation of IP addresses. The fact that we are in 2014 after<br>
a 30 year run talking about what to do means that de-allocation is already<br>
good. The current situation is due to desktops/servers/storage units<br>
requiring a new IP address (throwing away the old one) while the core<br>
routers have the same IPs that were in place when the internet was created.<br>
There have been effective solutions put in place by ARIN and others to 'put<br>
a thumb in the dike' of this de-allocation issue. There are many possible<br>
solutions, but the proposed solution means that ARIN will 'go slow' with<br>
allocating the remaining IPv4 addresses stringing out the deployment of IPv4<br>
addresses for as long as possible. It is already economically very<br>
difficult for a new entrant to get 'in' and it will be impossible once the<br>
new policies are in place.<br>
<br>
Now, it is not all bad for there not to be any new entrants into a market<br>
(it is the heart of standards), and the market gravitates towards three<br>
major solutions anyway once something becomes a commodity. The real<br>
question is "has the internet become a commodity already, or is there still<br>
some juice left in it?". It is impossible to answer this in advance. I<br>
do know that when ARIN was formed, the biggest problem was giving everyone<br>
internet connectivity, which involved a major expense running wires, buying<br>
wireless spectrum, etc and the investors who made it possible deserve to be<br>
paid a profit because they were very successful at deploying internet<br>
connectivity.<br>
<br>
1) It appears that there will be no new ISPs and no one will get into this<br>
business. It is difficult already, but if the draft policy by ARIN is put<br>
in place, it solidifies and codifies ARIN's ratification of this. Although<br>
we all saw the unintended consequences arising when the US Congress made<br>
possible CLECs (which were unsuccessful in the market) and new ISPs are very<br>
much like CLECs were, it is a very dangerous thing to provide policy that<br>
makes sure there will be no new ISPs because there is no economic incentive<br>
for one to be created. The opportunity to get ahead by creating a new ISP<br>
will soon be removed by ARIN policy. Does ARIN want to enable the entire<br>
country to remain a 'banana republic' where the rich are getting richer at<br>
the expense of the middle class/small business, or does ARIN wish to be<br>
associated with the 'land of opportunity' (not subsidy) by allocating<br>
resources to large and small enterprises on an equal basis?<br>
<br>
2) There is no need to mess with IPv6 policy. The current situation<br>
which we have all been trying to implement for a decade will not be enhanced<br>
by this policy change. The change in policy is that IPv4 is getting a lot<br>
more restrictive in allocation and IPv6 will be tied to existing IPv4<br>
allocations. It really means that there will not be an opportunity for a<br>
new ISP even after the IPv4 addresses are a thing of the past. If it ain't<br>
broke, don't fix it. There is ample opportunity for ARIN to create an<br>
"intellectual property tax" for payment to ARIN based on existing allocation<br>
size and market prices for the IP addresses (separate ones for IPv4 and<br>
IPv6). Does ARIN want to make sure only incumbents are able to get IPv6<br>
addresses?<br>
<br>
3) If we return to the 'bank of modems' of the dial up modem era, then<br>
every modem has to have its own separate dial tone. There may be a way to<br>
use one phone number (like IP addresses), but the modem pool still has to<br>
have an isolation mechanism per modem. The policy as written will specify<br>
that someone getting into the 'dial up modem' business can't deploy but a<br>
handful of modems at a time, that all modems must be 80% utilized before any<br>
more can be bought, and that the phone number will change for all modems on<br>
the modem bank if more modems are deployed. An ISP ensures that a customer<br>
is able to put their own phone number on the banks of modems while a large<br>
enterprise means that they have to control the phone numbers too. It is a<br>
subtle distinction but it at the heart of the question "Does ARIN wish to<br>
have a more relaxed policy for large Enterprises than ISPs?".<br>
<br>
4) It is important for ARIN to maintain the existing internet policy thru<br>
allocation. It is hard to see how the existing policy change will enhance<br>
an accurate allocation other than there will be less players to watch after<br>
and the expense will be known in advance. Does ARIN want to 'remove the<br>
band-aid slowly' which the proposed policy change does, or does ARIN and<br>
others involved undergo less pain if the IPv4 band-aid is removed quickly?<br>
<br>
5) Doing something now is akin to 'closing the barn door after the horse<br>
has run off', similar to anyone that gets broken in to buying a burgler<br>
alarm system after they were robbed. In an effort at fairness, because<br>
ARIN must serve both large and small internet clients and because of the<br>
huge allocations in place in 2012-2013 (.5% of the companies got most of the<br>
IP address allocations from ARIN), the attention has been to be fair in<br>
administration of ARIN policies. Will the existing policy change enable<br>
ARIN to be more or less 'fair' with the remaining IPv4 allocation?<br>
<br>
Mike Mazarick<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Tue, 08 Jul 2014 16:21:27 -0700<br>
From: Matthew Kaufman <<a href="mailto:matthew@matthew.at">matthew@matthew.at</a>><br>
To: <a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a><br>
Subject: Re: [arin-ppml] comment - Draft Policy ARIN-2013-8<br>
Message-ID: <<a href="mailto:53BC7CF7.4030203@matthew.at">53BC7CF7.4030203@matthew.at</a>><br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>
<br>
I can't tell... do you support or oppose the policy proposal?<br>
<br>
Matthew Kaufman<br>
<br>
On 7/8/2014 1:57 PM, Mike Mazarick wrote:<br>
> RE: Recommended Draft Policy ARIN-2013-8<br>
><br>
> My comments:<br>
><br>
> All of computer science is made up of allocating storage (memory/disk),<br>
> de-allocating storage, or moving bits around. Like all organizations, the<br>
> current situation we are all in (exhaustion of IPv4 addresses) is due to an<br>
> improper de-allocation of IP addresses. The fact that we are in 2014 after<br>
> a 30 year run talking about what to do means that de-allocation is already<br>
> good. The current situation is due to desktops/servers/storage units<br>
> requiring a new IP address (throwing away the old one) while the core<br>
> routers have the same IPs that were in place when the internet was created.<br>
> There have been effective solutions put in place by ARIN and others to 'put<br>
> a thumb in the dike' of this de-allocation issue. There are many possible<br>
> solutions, but the proposed solution means that ARIN will 'go slow' with<br>
> allocating the remaining IPv4 addresses stringing out the deployment of IPv4<br>
> addresses for as long as possible. It is already economically very<br>
> difficult for a new entrant to get 'in' and it will be impossible once the<br>
> new policies are in place.<br>
><br>
> Now, it is not all bad for there not to be any new entrants into a market<br>
> (it is the heart of standards), and the market gravitates towards three<br>
> major solutions anyway once something becomes a commodity. The real<br>
> question is "has the internet become a commodity already, or is there still<br>
> some juice left in it?". It is impossible to answer this in advance. I<br>
> do know that when ARIN was formed, the biggest problem was giving everyone<br>
> internet connectivity, which involved a major expense running wires, buying<br>
> wireless spectrum, etc and the investors who made it possible deserve to be<br>
> paid a profit because they were very successful at deploying internet<br>
> connectivity.<br>
><br>
> 1) It appears that there will be no new ISPs and no one will get into this<br>
> business. It is difficult already, but if the draft policy by ARIN is put<br>
> in place, it solidifies and codifies ARIN's ratification of this. Although<br>
> we all saw the unintended consequences arising when the US Congress made<br>
> possible CLECs (which were unsuccessful in the market) and new ISPs are very<br>
> much like CLECs were, it is a very dangerous thing to provide policy that<br>
> makes sure there will be no new ISPs because there is no economic incentive<br>
> for one to be created. The opportunity to get ahead by creating a new ISP<br>
> will soon be removed by ARIN policy. Does ARIN want to enable the entire<br>
> country to remain a 'banana republic' where the rich are getting richer at<br>
> the expense of the middle class/small business, or does ARIN wish to be<br>
> associated with the 'land of opportunity' (not subsidy) by allocating<br>
> resources to large and small enterprises on an equal basis?<br>
><br>
> 2) There is no need to mess with IPv6 policy. The current situation<br>
> which we have all been trying to implement for a decade will not be enhanced<br>
> by this policy change. The change in policy is that IPv4 is getting a lot<br>
> more restrictive in allocation and IPv6 will be tied to existing IPv4<br>
> allocations. It really means that there will not be an opportunity for a<br>
> new ISP even after the IPv4 addresses are a thing of the past. If it ain't<br>
> broke, don't fix it. There is ample opportunity for ARIN to create an<br>
> "intellectual property tax" for payment to ARIN based on existing allocation<br>
> size and market prices for the IP addresses (separate ones for IPv4 and<br>
> IPv6). Does ARIN want to make sure only incumbents are able to get IPv6<br>
> addresses?<br>
><br>
> 3) If we return to the 'bank of modems' of the dial up modem era, then<br>
> every modem has to have its own separate dial tone. There may be a way to<br>
> use one phone number (like IP addresses), but the modem pool still has to<br>
> have an isolation mechanism per modem. The policy as written will specify<br>
> that someone getting into the 'dial up modem' business can't deploy but a<br>
> handful of modems at a time, that all modems must be 80% utilized before any<br>
> more can be bought, and that the phone number will change for all modems on<br>
> the modem bank if more modems are deployed. An ISP ensures that a customer<br>
> is able to put their own phone number on the banks of modems while a large<br>
> enterprise means that they have to control the phone numbers too. It is a<br>
> subtle distinction but it at the heart of the question "Does ARIN wish to<br>
> have a more relaxed policy for large Enterprises than ISPs?".<br>
><br>
> 4) It is important for ARIN to maintain the existing internet policy thru<br>
> allocation. It is hard to see how the existing policy change will enhance<br>
> an accurate allocation other than there will be less players to watch after<br>
> and the expense will be known in advance. Does ARIN want to 'remove the<br>
> band-aid slowly' which the proposed policy change does, or does ARIN and<br>
> others involved undergo less pain if the IPv4 band-aid is removed quickly?<br>
><br>
> 5) Doing something now is akin to 'closing the barn door after the horse<br>
> has run off', similar to anyone that gets broken in to buying a burgler<br>
> alarm system after they were robbed. In an effort at fairness, because<br>
> ARIN must serve both large and small internet clients and because of the<br>
> huge allocations in place in 2012-2013 (.5% of the companies got most of the<br>
> IP address allocations from ARIN), the attention has been to be fair in<br>
> administration of ARIN policies. Will the existing policy change enable<br>
> ARIN to be more or less 'fair' with the remaining IPv4 allocation?<br>
><br>
> Mike Mazarick<br>
><br>
><br>
> _______________________________________________<br>
> PPML<br>
> You are receiving this message because you are subscribed to<br>
> the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
> Unsubscribe or manage your mailing list subscription at:<br>
> <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
> Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Tue, 08 Jul 2014 16:38:34 -0700<br>
From: Matthew Kaufman <<a href="mailto:matthew@matthew.at">matthew@matthew.at</a>><br>
To: <a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a><br>
Subject: Re: [arin-ppml] LAST CALL: Recommended Draft Policy<br>
ARIN-2014-12: Anti-hijack Policy<br>
Message-ID: <<a href="mailto:53BC80FA.3030102@matthew.at">53BC80FA.3030102@matthew.at</a>><br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>
<br>
Support. Additionally I think that the community has made it clear that<br>
ARIN should be following their own policies (including this one, if<br>
applicable) if/when allocating addresses to themselves.<br>
<br>
Matthew Kaufman<br>
<br>
On 6/24/2014 1:16 PM, ARIN wrote:<br>
> The ARIN Advisory Council (AC) met on 19 June 2014 and decided to<br>
> send the following to an extended last call:<br>
><br>
> Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy<br>
><br>
> The text has been revised. The AC provided the following:<br>
><br>
> "ARIN-2014-12 has been modified since the ARIN Advisory Council (AC)<br>
> recommended this policy on 15 May 2014, in the following ways;<br>
><br>
> 1. The second and third sentences of the policy text were modified to<br>
> clarify the original policy intent regarding deviation from the minimum<br>
> allocation size, either smaller or larger as discussed on PPML. These<br>
> changes are considered editorial in nature and do not change the intent<br>
> of the policy.<br>
><br>
> 2. A sentence was added to the policy statement reflecting the changes<br>
> to the policy text as discussed above."<br>
><br>
> Feedback is encouraged during the last call period. All comments should<br>
> be provided to the Public Policy Mailing List. This last call will<br>
> expire on 15 July 2014. After last call the AC will conduct their<br>
> last call review.<br>
><br>
> The draft policy text is below and available at:<br>
> <a href="https://www.arin.net/policy/proposals/" target="_blank">https://www.arin.net/policy/proposals/</a><br>
><br>
> The ARIN Policy Development Process is available at:<br>
> <a href="https://www.arin.net/policy/pdp.html" target="_blank">https://www.arin.net/policy/pdp.html</a><br>
><br>
> Regards,<br>
><br>
> Communications and Member Services<br>
> American Registry for Internet Numbers (ARIN)<br>
><br>
><br>
> ## * ##<br>
><br>
><br>
> Recommended Draft Policy ARIN-2014-12<br>
> Anti-hijack Policy<br>
><br>
> Date: 17 June 2014<br>
><br>
> AC's assessment of conformance with the Principles of Internet Number<br>
> Resource Policy:<br>
><br>
> ARIN-2014-12: Anti-hijack Policy enables fair, impartial, and<br>
> technically sound number resource administration by updating the<br>
> guidelines for the allocation of experimental resources to ensure all<br>
> such allocation are documented in Whois, noting their experimental<br>
> status, and provides these allocations may not overlap any other<br>
> allocations. Additionally, part of the original policy text has been<br>
> clarified through editorial changes.<br>
><br>
> Problem Statement:<br>
><br>
> ARIN should not give research organizations permission to hijack<br>
> prefixes that have already been allocated. Research organizations<br>
> announcing lit aggregates may receive sensitive production traffic<br>
> belonging to live networks during periods of instability.<br>
><br>
> Section 11.7 describes more than allocation size therefore updating<br>
> the section heading to something more accurate is appropriate.<br>
><br>
> Policy statement:<br>
><br>
> Modify the section 11.7 heading to be more accurate. Modify the first<br>
> sentence to prohibit overlapping assignments. Add text at the end to<br>
> define how research allocations should be designated.<br>
><br>
> Modify the second and third sentences to clarify the original policy<br>
> intent regarding deviation from the minimum allocation size, smaller<br>
> or larger as discussed on PPML.<br>
><br>
> 11.7 Resource Allocation Guidelines<br>
><br>
> The Numbering Resources requested come from the global Internet<br>
> Resource space, do not overlap currently assigned space, and are not<br>
> from private or other non-routable Internet Resource space. The<br>
> allocation size shall be consistent with the existing ARIN minimum<br>
> allocation sizes, unless smaller allocations are intended to be<br>
> explicitly part of the experiment. If an organization requires more<br>
> resources than stipulated by the minimum allocation size in force at<br>
> the time of its request, the request must clearly describe and justify<br>
> why a larger allocation is required.<br>
><br>
> All research allocations must be registered publicly in whois. Each<br>
> research allocation will be designated as a research allocation with a<br>
> comment indicating when the allocation will end.<br>
><br>
> Comments:<br>
><br>
> a. Timetable for implementation: Immediate<br>
><br>
> b. Anything else:<br>
> _______________________________________________<br>
> PPML<br>
> You are receiving this message because you are subscribed to<br>
> the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
> Unsubscribe or manage your mailing list subscription at:<br>
> <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
> Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Tue, 08 Jul 2014 16:39:37 -0700<br>
From: Matthew Kaufman <<a href="mailto:matthew@matthew.at">matthew@matthew.at</a>><br>
To: <a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a><br>
Subject: Re: [arin-ppml] LAST CALL: Recommended Draft Policy<br>
ARIN-2014-13: Reduce All Minimum Allocation/Assignment Units to /24<br>
Message-ID: <<a href="mailto:53BC8139.6060803@matthew.at">53BC8139.6060803@matthew.at</a>><br>
Content-Type: text/plain; charset=windows-1252; format=flowed<br>
<br>
Support. Making it easier for people to receive the last of the IPv4<br>
pool is a good thing.<br>
<br>
Matthew Kaufman<br>
<br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Tue, 08 Jul 2014 16:41:52 -0700<br>
From: Matthew Kaufman <<a href="mailto:matthew@matthew.at">matthew@matthew.at</a>><br>
To: <a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a><br>
Subject: Re: [arin-ppml] LAST CALL: Recommended Draft Policy<br>
ARIN-2014-5: Remove 7.2 Lame Delegations<br>
Message-ID: <<a href="mailto:53BC81C0.5050409@matthew.at">53BC81C0.5050409@matthew.at</a>><br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>
<br>
Support. Even when DNS software bugs made it critical for ARIN and its<br>
predecessors to do their best, this has never been effectively<br>
implemented. The good news is that the bugs were fixed as a result, and<br>
so this is now a non-issue. Also, generally support removing extraneous<br>
language from NRPM.<br>
<br>
Matthew Kaufman<br>
<br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
ARIN-PPML mailing list<br>
<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a><br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
<br>
End of ARIN-PPML Digest, Vol 109, Issue 4<br>
*****************************************<br>
</blockquote></div>