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