[arin-ppml] ARIN 2014-13
Rudolph Daniel
rudi.daniel at gmail.com
Wed Jul 9 14:34:33 EDT 2014
I Support for /24.
RD
On Jul 8, 2014 7:42 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. Weekly posting summary for 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>
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Weekly posting summary for ppml at arin.net
> Message-ID: <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
> 18.18% | 4 | 19.71% | 81738 | cja at daydream.com
> 4.55% | 1 | 31.02% | 128615 | derekc at cnets.net
> 13.64% | 3 | 12.68% | 52580 | scottleibrand at gmail.com
> 13.64% | 3 | 4.31% | 17863 | jcurran at arin.net
> 4.55% | 1 | 5.31% | 22027 | mpetach at netflight.com
> 4.55% | 1 | 3.88% | 16098 | celestea at usc.edu
> 4.55% | 1 | 2.26% | 9382 | khatfield at socllc.net
> 4.55% | 1 | 2.15% | 8917 | info at arin.net
> 4.55% | 1 | 1.73% | 7180 | narten at us.ibm.com
> 4.55% | 1 | 1.19% | 4948 | 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>
> To: <arin-ppml at arin.net>
> Subject: [arin-ppml] comment - Draft Policy ARIN-2013-8
> Message-ID:
> <01c001cf9aef$45776eb0$d0664c10$@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>
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] comment - Draft Policy ARIN-2013-8
> Message-ID: <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).
> > 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: 4
> Date: Tue, 08 Jul 2014 16:38:34 -0700
> From: Matthew Kaufman <matthew at matthew.at>
> To: 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>
> 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).
> > 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: 5
> Date: Tue, 08 Jul 2014 16:39:37 -0700
> From: Matthew Kaufman <matthew at matthew.at>
> To: 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>
> 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>
> To: 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>
> 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
> 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/20140709/82c1b8ea/attachment.htm>
More information about the ARIN-PPML
mailing list