[arin-ppml] PolicyProposal:EquitableDistributionofIPv4ResourcesbeforeIPv4 Run out
Ted Mittelstaedt
tedm at ipinc.net
Fri May 23 15:29:29 EDT 2008
> -----Original Message-----
> From: arin-ppml-bounces at arin.net
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Nathan Day
> Sent: Thursday, May 22, 2008 6:53 PM
> To: Michael K. Smith - Adhost; arin-ppml at arin.net
> Subject: Re:
> [arin-ppml]PolicyProposal:EquitableDistributionofIPv4Resources
> beforeIPv4 Run out
>
>
> Michael,
>
> I do agree with trying to make the most efficient use of the
> ipv4 resources as we approach the end of this limited
> resource and I'm glad people are discussing it.
>
> You don't try to hide that this proposal is for the benefit
> of smaller orgs at the expense of the larger orgs. I just
> don't understand what qualities a smaller org has that makes
> it more deserving of ipv4 resources than a larger org. Are
> smaller orgs better custodians of ipv4 resources than larger
> orgs based on purely their size?
>
It has nothing to do with that. It has everything to do with
innovation and continuting to grow the Internet.
If you look at EVERY major application today that is popular,
and generating scads of money for the large orgs, you will
find if you look at it's history that it DID NOT originate in
a large org. It originated in a small org.
In the tech industry, SOP is that the small orgs dream up the
new ideas, the large orgs then copy the successful ones and
market the shoit out of them, making millions doing so.
And the cost to the larg orgs for this is trivial - maybe 2%
fewer customers than they would otherwise have.
If the large orgs wanted to stomp the small orgs out of existence
they could do so VERY easily. But if they did this they would
sacrifice their own future, because they would kill the golden
geese that are out there laying eggs - which the large orgs are
then picking up.
If you look at industries - like the soft drink industry - where
the large companies were allowed to stomp the small makers out of
business, you find extremely static markets that are very vulnerable.
Thus, the loss of the soft drink market to Starbucks and it's ilk.
Which, if the soft drink market did have the golden geese out
there laying eggs, would never have happened. It is too late for
the soft drink market to recover from this, their loss to the
coffee people will continue - but the large orgs in the Tech industry
are going to make sure this doesen't happen in the Internet business.
Ted
> The current policies are intended to balance need and
> efficient use. I would prefer to see the last blocks of ipv4
> space allocated based on need and demonstrated efficient use
> of previous allocations.
>
> Nathan Day
> SoftLayer.com
>
>
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Michael K.
> Smith - Adhost
> Sent: Thursday, May 22, 2008 7:22 PM
> To: Alexander, Daniel; arin-ppml at arin.net
> Subject: Re: [arin-ppml]
> PolicyProposal:EquitableDistributionofIPv4Resourcesbefore IPv4 Run out
>
> Hello Daniel:
>
> I'm sure you can guess my position, but the idea that smaller
> organizations would be more adversely affected at the point
> of depletion was part of my rationale behind submitting a
> policy that was tilted at benefitting those organizations.
>
> I had thought through several different models for
> distribution, including flat percentages based upon org size,
> a model based upon only allocating in halves the last IANA
> allocation (if a /14 is left, you can't allocate the /14 to
> one org, only half of it, then half the remaining, etc. But,
> that got ugly fast), and reserving space based upon the
> allocation size for the groups (x number of /20's, x number
> of /22's, etc.). Using the percentages from previous
> allocations seemed the most equitable and, thus, the most
> likely to be palatable to orgs of every size, provided the
> bigger concept of helping the smaller orgs was accepted by
> the community. If anyone has a better model I am all ears.
>
> Regards,
>
> Mike
>
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net
> [mailto:arin-ppml-bounces at arin.net]
> > On Behalf Of Alexander, Daniel
> > Sent: Thursday, May 22, 2008 4:13 PM
> > To: Ted Mittelstaedt; arin-ppml at arin.net
> > Subject: Re: [arin-ppml]
> > PolicyProposal:EquitableDistributionofIPv4Resources
> > before IPv4 Run out
> >
> > Ted,
> >
> > You made some points in your reply that I think echo the intent of
> > Michael's proposal. Aside from how it tries to get there, I
> am curious
> > to hear from the community on its thoughts of the rationale.
> >
> > Who likes the idea of a policy to handle an IANA depleted
> situation,
> > where the smaller organizations are less effected, in order to buy
> > them time, while the larger organizations are forced
> towards IPv6. It
> > is the largest IP consumers who will drive the vendors, and develop
> > the market for IPv6 enabled equipment. It is the smallest
> > organizations who need to remain on IPv4 until the shift has gained
> > the necessary momentum.
> >
> > When the IANA pool is depleted, regardless of whether there
> is a black
> > market, or a paid transfer policy, it is very difficult to see a
> > sufficient supply of IPv4 resources, for the extra-large ISP. This
> > means that these ISP will hit the wall first, and hit it
> the hardest.
> > It is also this group who is more able to bear the burden
> of working
> > with equipment vendors, and software developers, to push
> the necessary
> > momentum towards IPv6. Would a policy proposal that supports this
> > model be preferred by the community?
> >
> > Dan Alexander
> > Comcast Cable
> > ARIN AC
> >
> >
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net
> [mailto:arin-ppml-bounces at arin.net]
> > On Behalf Of Ted Mittelstaedt
> > Sent: Thursday, May 22, 2008 4:42 PM
> > To: 'Michael Thomas - Mathbox'; arin-ppml at arin.net
> > Subject: Re: [arin-ppml] Policy
> > Proposal:EquitableDistributionofIPv4Resources before IPv4 Run out
> >
> >
> >
> > > -----Original Message-----
> > > From: arin-ppml-bounces at arin.net
> [mailto:arin-ppml-bounces at arin.net]
> > > On Behalf Of Michael Thomas - Mathbox
> > > Sent: Thursday, May 22, 2008 12:22 PM
> > > To: arin-ppml at arin.net
> > > Subject: Re: [arin-ppml] Policy Proposal:
> > > EquitableDistributionofIPv4Resources before IPv4 Run out
> > >
> > >
> > > Ted,
> > >
> > > At the risk of receiving the wrath of the PPML Gods...
> > >
> > > > X-small: 61 cents/year
> > >
> > > X-Large fee is up to a /14. Anything over a /14 is no charge. So,
> > > you cannot apply a single divisor that applies to all X-Large. The
> >
> > > /8 that they may also have is FREE. Most X-Large pay less
> than $.01
> > > per IP.
> > >
> >
> > "...may also have is FREE..." is a reference to legacy allocations
> > and I was not talking about that, those are a separate issue.
> >
> > As for the penny an IP address the X-large pays, sure on
> the surface
> > that seems unfair. But, I will point out that precisely
> because they
> > are X-large, and have so many IP's already, that in a time of IPv4
> > runout, they are going to be under intense pressure to both move to
> > IPv6, and also to justify why they have so much IPv4 tied up.
> >
> > The small low-growth organizations who have maybe a /18
> tied up, and
> > who are experiencing maybe a 2% per year real growth in customer
> > count, those folks aren't going to suffer in IPv4 runout
> time. They
> > will be paying their bills, keeping people employed, keeping their
> > customers happy, basically being good citizens. They will
> be able to
> > sit back and weather the storm, and because they have so
> little IPv4
> > tied up as compared to the large holders, nobody is going to come
> > banging on their door demanding they prove justification for their
> > holdings, because even if what they have has a lot of
> unused numbers,
> > the amount of unused numbering they have is so small it
> won't help any
> > of the larger well-financed consumers of IP addressing for
> more than a
> > few days of growth.
> >
> > The political and economic realities are that the X-larges
> are going
> > to bear the brunt of the costs of switchover to IPv6 - and
> they will
> > also suffer the largest customer losses, as they tell
> customers that
> > they can't support IPv4, those customers who don't want to switch
> > (think - all of them) will be going to the smaller providers.
> >
> > And when the large guys have ended up funding all the R&D for the
> > production deployment of IPv6, by then the small guys will have a
> > literal wealth of gear and deployment strategies to pick and choose
> > from, as well as be able to know all the pitfalls, AND even better,
> > since they really will be the last to covert over, their customers
> > will not be able to carry out the threat of "quitting service and
> > finding an ISP that will sell us IPv4" since there won't BE
> any ISP's
> > left that will sell IPv4.
> >
> > > > The fact of the matter is that on a per-IP basis, the smaller
> > > > allocations cost everyone on the Internet more money
> per customer,
> > > > because we have to carry more route entries for the same number
> > >
> > > It is a two-way street...
> > >
> > > > of customers, so I am perfectly contented with the "smaller
> > > allocation
> > > > tax" of more cents per IP per year
> > >
> > > Exactly how much of that "tax-the-poor" does your company
> collect?
> > > Other than providing a barrier to competition, how does
> it benefit
> > > your company?
> > >
> >
> > Naturally, our pricing has to be set according to what the
> other guy
> > has his pricing set to - that's determined by competition. But,
> > because we are smaller, we have much more flexibility in
> reducing our
> > internal costs than the large guy does. So we pay more for
> numbering,
> > but we can do things like using PC's running Quagga for BGP routers
> > instead of Junipers, and the savings more than make up for the IP
> > costs. (I'm not saying that we currently do this, but we
> have done so
> > in the past - and the reliability is no worse than the commercial
> > routers) It all has a way of working out in the end.
> >
> > Ted
> >
> > > Michael Thomas
> > >
> > > > -----Original Message-----
> > > > From: arin-ppml-bounces at arin.net
> > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted
> Mittelstaedt
> > > > Sent: Thursday, May 22, 2008 2:32 PM
> > > > To: 'Charlie Sawyer'; arin-ppml at arin.net
> > > > Subject: Re: [arin-ppml] Policy Proposal: Equitable
> > > > DistributionofIPv4Resources before IPv4 Run out
> > > >
> > > >
> > > > Hey, whatever your smoking, I want some!
> > > >
> > > > ARIN -does- charge per IP address. I may have imbibed
> a number of
> > > > hallucinogenic substances over the years but the bill
> we get from
> > > > them every year is most definitely NOT a figment of my
> > > > imagination!
> > > >
> > > > Or were you under the impression that ARIN was funded by
> > > Tinker Bell
> > > > and friends?
> > > >
> > > > In case you were, here is the ARIN fee schedule:
> > > >
> > > > http://www.arin.net/billing/fee_schedule.html
> > > >
> > > > Fees per IP address:
> > > >
> > > > X-small: 61 cents/year
> > > > Small: 28 cents/year
> > > > Medium: 6 cents/year
> > > > Large: 3 cents/year
> > > >
> > > > and so forth.
> > > >
> > > > The fact of the matter is that on a per-IP basis, the smaller
> > > > allocations cost everyone on the Internet more money
> per customer,
> > > > because we have to carry more route entries for the
> same number of
> > > > customers, so I am perfectly contented with the "smaller
> > > > allocation tax" of more cents per IP per year
> > > >
> > > > If you go to Costco the giant bundle of toilet paper also
> > > costs less
> > > > per roll. That's just how things work in life.
> > > >
> > > > But the idea that ARIN isn't charging money for IP's is
> > > > rediculous.
> > > >
> > > >
> > > > Ted
> > > >
> > > > > -----Original Message-----
> > > > > From: arin-ppml-bounces at arin.net
> > > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of
> Charlie Sawyer
> > > > > Sent: Thursday, May 22, 2008 11:04 AM
> > > > > To: arin-ppml at arin.net
> > > > > Subject: Re: [arin-ppml] Policy Proposal: Equitable
> Distribution
> > > > > ofIPv4Resources before IPv4 Run out
> > > > >
> > > > >
> > > > > Ip do have value, as any business using the web to generate a
> > > > > revenue stream can tell you. If Arin charged per ip,
> I doubt we
> > > > > would be running out of IP' addresses any time in the near
> > > > > future.
> > > > You would
> > > > > see a lot of IP addresses being returned that were
> not in use,
> > > > > at the very least.
> > > > >
> > > > > Supply and demand with free market can solve many issues.
> > > > >
> > > > >
> > > > > Thanks,
> > > > > Charlie Sawyer
> > > > > -----Original Message-----
> > > > > From: arin-ppml-bounces at arin.net
> > > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted
> > > > > Mittelstaedt
> > > > > Sent: Thursday, May 22, 2008 12:25 PM
> > > > > To: arin-ppml at arin.net
> > > > > Subject: Re: [arin-ppml] Policy Proposal: Equitable
> Distribution
> > > > > of IPv4Resources before IPv4 Run out
> > > > >
> > > > >
> > > > > I support the idea of trying to equalize the last bit of IPv4
> > > > > address distribution, which this proposal is trying
> to address.
> > > > >
> > > > > However, I think that while the moral is a Good Thing,
> > > there is no
> > > > > practical way to mandate it.
> > > > >
> > > > > If this proposal were to be supported I would ask that the
> > > > > author modify it so that at the least, there would be an
> > > > > automatic expiration to this.
> > > > >
> > > > > The cold hard fact of the matter is that ANY isp or
> other "small
> > > > > or Very Small" organization that is NOT requesting IP
> addressing
> > > > > at this time to meet their projected future needs, is
> likely to
> > > > > get shafted when IPv4 runs out.
> > > > >
> > > > > On the day of IPv4 runout, if an ISP or organization does
> > > not have a
> > > > > supply of IPv4 to carry them forward for the immediate
> > > future, due
> > > > > to lack of planning, then I daresay they DESERVE to
> go bankrupt.
> > > > >
> > > > > Do we really want network administrators who aren't paying
> > > > > attention to the gas guage to be driving the Internet into
> > > > the future?
> > > > >
> > > > > Ted
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: arin-ppml-bounces at arin.net
> > > > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member
> > > > > > Services
> > > > > > Sent: Wednesday, May 21, 2008 7:37 AM
> > > > > > To: arin-ppml at arin.net
> > > > > > Subject: [arin-ppml] Policy Proposal: Equitable
> Distribution of
> > > > > > IPv4 Resources before IPv4 Run out
> > > > > >
> > > > > >
> > > > > > ARIN received the following policy proposal. In accordance
> > > > > > with the ARIN Internet Resource Policy Evaluation Process,
> > > the proposal
> > > > > > is being posted to the ARIN Public Policy Mailing List
> > > (PPML) and
> > > > > > being placed on ARIN's website.
> > > > > >
> > > > > > The ARIN Advisory Council (AC) will review this
> > > proposal at their
> > > > > > next regularly scheduled meeting. The AC may decide to:
> > > > > >
> > > > > > 1. Accept the proposal as written. If the AC
> accepts the
> > > > > > proposal, it will be posted as a formal policy proposal to
> > > > > > PPML and it will be presented at a Public Policy Meeting.
> > > > > >
> > > > > > 2. Postpone their decision regarding the proposal
> > > until the
> > > > > > next regularly scheduled AC meeting in order to
> work with the
> > > > > > author. The AC will work with the author to
> clarify, combine
> > > > > > or divide the proposal. At their following meeting the AC
> > > will accept
> > > > > > or not accept the proposal.
> > > > > >
> > > > > > 3. Not accept the proposal. If the AC does not accept
> > > > > > the proposal, the AC will explain their decision
> via the PPML.
> > > > > > If a proposal is not accepted, then the author may elect to
> > > > > > use the petition process to advance their proposal. If the
> > > author elects
> > > > > > not to petition or the petition fails, then the
> > > proposal will be
> > > > > > closed.
> > > > > >
> > > > > > The AC will assign shepherds in the near future. ARIN
> > > will provide
> > > > > > the names of the shepherds to the community via the PPML.
> > > > > >
> > > > > > In the meantime, the AC invites everyone to comment on this
> > > > > > proposal on the PPML, particularly their support or
> > > > > > non-support and the reasoning behind their opinion. Such
> > > > > > participation contributes to a thorough vetting and provides
> > > important guidance
> > > > > > to the AC in their deliberations.
> > > > > >
> > > > > > The ARIN Internet Resource Policy Evaluation Process
> > > can be found
> > > > > > at: http://www.arin.net/policy/irpep.html
> > > > > >
> > > > > > Mailing list subscription information can be found at:
> > > > > > http://www.arin.net/mailing_lists/
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Member Services
> > > > > > American Registry for Internet Numbers (ARIN)
> > > > > >
> > > > > >
> > > > > > ## * ##
> > > > > >
> > > > > >
> > > > > > Policy Proposal Name: Equitable Distribution of
> IPv4 Resources
> > > > > > before IPv4 Run out
> > > > > >
> > > > > > Author: Michael K. Smith
> > > > > >
> > > > > > Proposal Version: 1
> > > > > >
> > > > > > Submission Date: 05/20/2008
> > > > > >
> > > > > > Proposal type: new
> > > > > >
> > > > > > Policy term: permanent
> > > > > >
> > > > > > Policy statement:
> > > > > >
> > > > > > Upon receipt of the last allocation of IPv4 address
> > > space to ARIN
> > > > > > from IANA, ARIN will reserve address space within the
> > > > > > allocated block for Organizations within the defined ARIN
> > > > > > Organizational Size determinations (Extra Small,
> Small, Large,
> > > > > > Extra
> > > Large) based
> > > > > > upon the utilization percentages for each group
> > > gathered from the
> > > > > > statistics of the last two IANA allocations to ARIN.
> > > In order to
> > > > > > make the allocation percentages mathematically
> feasible, the
> > > > > > percentages will be rounded to the closest whole
> number and,
> > > > > > subsequently, the the closest bit boundary for
> assignment the
> > > > > > maximum allocation size for the Organization size
> as defined
> > > > > > by ARIN.
> > > > > >
> > > > > > Once the final IANA allocation is received, ARIN will
> > > publish the
> > > > > > allocation percentages that will be used for the final
> > > allocation
> > > > > > to the PPML and ARIN website with the necessary
> documentation
> > > > > > supporting the assignment of percentages.
> > > > > >
> > > > > > Rationale:
> > > > > >
> > > > > > Description:
> > > > > >
> > > > > > This policy is designed to allow Organizations of
> the various
> > > > > > defined sizes to continue to receive address
> > > allocations from the
> > > > > > last available space and is slanted towards ensuring that
> > > > > > organizations within the Large, Small and Extra Small
> > > groups (and
> > > > > > more specifically, the Small and Extra Small groups)
> > > are able to
> > > > > > get additional IPv4 space at the end of the ARIN's
> ability to
> > > > > > allocate such space. Given the statistics below,
> it is likely
> > > > > > that Extra Large Organizations would get most or all of
> > > the last
> > > > > > remaining space because given the amount they have been
> > > allocated
> > > > > > to date. This policy would help ensure that other
> > > Organizations
> > > > > > had a statistically equal opportunity to receive space as
> > > > > > well.
> > > > > >
> > > > > >
> > > > > > Example:
> > > > > >
> > > > > > Please see http://www.arin.net/statistics/index.html (Note:
> > > > > > the statistics are generated from IP allocations from 2006
> > > and 2007).
> > > > > > This policy would require statistics to be limited to
> > > the previous
> > > > > > 2 IANA allocations to ARIN.)
> > > > > >
> > > > > > The present distribution as of May 20th 2008 is:
> > > > > >
> > > > > > Extra Large: 83.11%
> > > > > > Large: 6.75%
> > > > > > Small: 9.00%
> > > > > > Extra Small: 1.14%
> > > > > >
> > > > > > With this example, ARIN would reserve address space in
> > > the final
> > > > > > IANA allocation according to those percentages, to the
> > > extent that
> > > > > > it is mathematically possible within the existing
> > > range. In order
> > > > > > to make the math work, rounding would give us:
> > > > > >
> > > > > > Extra Large: 83%
> > > > > > Large: 7%
> > > > > > Small: 9%
> > > > > > Extra Small: 1%
> > > > > >
> > > > > > Who is affected:
> > > > > >
> > > > > > All ARIN Members will be affected by this policy. I
> > > assume that
> > > > > > smaller providers will benefit from having some space
> > > available to
> > > > > > them beyond where they would be with an organic
> > > allocation model,
> > > > > > and the Extra Large Organizations would experience
> some pain
> > > > > > because, using the model above, they would be excluded
> > > from being
> > > > > > allocated 17% of the remaining space, even if they had
> > > all of the
> > > > > > necessary justifications for receiving allocations
> from within
> > > > > > that space.
> > > > > >
> > > > > > Policy Enforcement:
> > > > > >
> > > > > > ARIN staff will have to enforce this policy and ensure that
> > > > > > allocations stay within the published percentages.
> > > > > >
> > > > > > Financial and Liability Implications:
> > > > > >
> > > > > > Financially, there may be additional resources required by
> > > > > > ARIN Staff to allocate resources using this model. These
> > > > > > resources might include application development, staff
> > > > > > training
> > > and tracking
> > > > > > of allocations based upon the model.
> > > > > >
> > > > > > ARIN may have legal liability should Organizations
> that were
> > > > > > denied space according to the model decide to contest
> > > the legality
> > > > > > of the policy in court.
> > > > > >
> > > > > > Timetable for implementation: Upon receipt of finall IANA
> > > > > > allocation (roughly 2011).
> > > > > >
> > > > > > _______________________________________________
> > > > > > 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 the ARIN Member Services Help Desk at
> > > > > > 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 the ARIN Member Services Help Desk at
> > > > 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 the ARIN Member Services Help Desk at
> > > > > 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 the ARIN Member Services Help Desk at
> > > > 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 the ARIN Member Services Help Desk at
> 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 the ARIN Member Services Help Desk at
> 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 the ARIN Member Services Help Desk at
> info at arin.net if you
> > experience any issues.
>
>
> The contents of this email message and any attachments are
> confidential and are intended solely for the addressee. The
> information may also be legally privileged. This transmission
> is sent in trust for the sole purpose of delivery to the
> intended recipient. If you have received this transmission in
> error; any use, reproduction or dissemination of this
> transmission is strictly prohibited. If you are not the
> intended recipient, please immediately notify the sender by
> reply email and delete this message and all associated attachments.
> _______________________________________________
> 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 the ARIN Member Services Help Desk at
> info at arin.net if you experience any issues.
>
>
More information about the ARIN-PPML
mailing list