<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Actually, they’d be doing all of the same things any other LIR does with the exception of providing bandwidth and connectivity services.<div class=""><br class=""></div><div class="">They’d still be responsible for getting a reasonable justification from the customer, validating that justification, registering the addresses properly in whois, etc.</div><div class=""><br class=""></div><div class="">It might be a bit less overhead than being an ISP, but ISPs are increasingly short on IPv4 addresses and asking customers to get their own.</div><div class=""><br class=""></div><div class="">Many customers are unable to make the capital outlay necessary to purchase the addresses they need, but do have the cash flow to support a lease.</div><div class=""><br class=""></div><div class="">Many customers have a desire not to take the risk of a large capital outlay for a necessary component which may abruptly lose its value in the near to medium term.</div><div class=""><br class=""></div><div class="">This situation will only get worse as the cost of IPv4 addresses continues to rise and as IPv6 deployment continues.</div><div class=""><br class=""></div><div class="">Owen</div><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Mar 17, 2022, at 16:28 , Holden Karau <<a href="mailto:holden@pigscanfly.ca" class="">holden@pigscanfly.ca</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Wait so some company could come to ARIN and ask for a block of IP addresses using leasing as the justification and then turn around and lease them.<div class=""><br class=""></div><div class="">What value is the leasing company providing? It seems like a solid way to get a bunch of LLCs formed to acquire IP addresses from the waiting list and then make money for doing ~nothing.</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 17, 2022 at 4:18 PM Andrew Dul <<a href="mailto:andrew.dul@quark.net" class="">andrew.dul@quark.net</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="">
<div class="">The draft policy as currently written
does not provide any additional limits against speculation. As
drafted, it allows any organization (including those who do not
operate networks) to obtain IPv4 addresses for the purpose of
leasing. </div>
<div class=""><br class="">
</div>
<div class="">With that policy change what types of
limits does the community think would be needed?</div>
<div class=""><br class="">
</div>
<div class="">Thanks,</div>
<div class="">Andrew<br class="">
</div>
<div class=""><br class="">
</div>
<div class="">On 3/17/2022 3:00 PM, Scott Leibrand
wrote:<br class="">
</div>
<blockquote type="cite" class="">
<div dir="ltr" class="">+1 to both Owen and David Farmer's comments.
Leasing IPv4 space is likely the best solution for some networks
that need those addresses to operate their network. If an
organization wants to acquire and lease out IPv4 space without
providing bundled IPv4 transit, that should be allowed by
policy. It might be useful for ARIN policy to try to slightly
dampen speculation by requiring that organizations seeking to
acquire large blocks of IPv4 space demonstrate that their
current holdings are being efficiently used by the organization
they're registered to in whois. I am not sure if this policy
proposal does that to my satisfaction, but once we ensure it
does so, I would likely support it.<br class="">
<div class=""><br class="">
</div>
<div class="">-Scott</div>
</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Mar 17, 2022 at 1:33
PM Owen DeLong via ARIN-PPML <<a href="mailto:arin-ppml@arin.net" target="_blank" class="">arin-ppml@arin.net</a>>
wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=""><br class="">
<div class="">
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On Mar 16, 2022, at 15:22 , Fernando Frediani
<<a href="mailto:fhfrediani@gmail.com" target="_blank" class="">fhfrediani@gmail.com</a>>
wrote:</div>
<br class="">
<div class="">
<div class=""><p class="">Hi David</p><p class="">If I understand correctly you seem to have a
view that there should be a ARIN policy to
permit IPv4 leasing just because it is a reality
and we kind of have to accept it in our days. No
we don't, and that's for many different reasons.</p>
</div>
</div>
</blockquote>
Well, of course, you are free to deny reality as much as
you want. Many people do. It’s not particularly helpful
in the discussion, however.</div>
<div class=""><br class="">
<blockquote type="cite" class="">
<div class=""><p class="">I am used to see people saying the brokers are
doing a good thing for the community by
facilitating the things which in reality is the
opposite. It may look like a good things, but the
real beneficiaries are only them who profit from
it without much concern of what is fair or not to
most organizations involved.<br class="">
</p>
</div>
</blockquote>
<div class=""><br class="">
</div>
You are actually mistaken here. I used to think as you
do, actually. I was very resistant to the first
“specified transfer” policies because of some of the
reasons you describe. However, what you are failing to
recognize is that:</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>+<span style="white-space:pre-wrap" class=""> </span>Brokers
and specified transfers were going to happen with or
without the RIRs. If they happened without the RIRs,</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>there’d
be no accurate record of who was using which address
space and the provenance of addresses would be</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>very
difficult to support or defend.</div>
<div class=""><br class="">
</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>*<span style="white-space:pre-wrap" class=""> </span>Benefit
to the community from brokers: (ethical) brokers are
familiar with the rules in the RIRs in which</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>they
operate and can assist their customers in accurate and
compliant registration updates and</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>aid in
keeping the allocation database(s) accurate.</div>
<div class=""><br class="">
</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>+<span style="white-space:pre-wrap" class=""> </span>With
the economic realities of IPv4 addresses becoming
progressively more and more expensive and the advent</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>of ISPs
with limited IPv4 resources available, it is inevitable
that more and more IP service providers will be</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>doing one
or more of the following:</div>
<div class=""><br class="">
</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>+<span style="white-space:pre-wrap" class=""> </span>Separate
surcharges for IPv4 addresses</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>+<span style="white-space:pre-wrap" class=""> </span>Expecting
customers to supply their own IPv4 addresses</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>+<span style="white-space:pre-wrap" class=""> </span>Surcharges
for IPv4 services</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>+<span style="white-space:pre-wrap" class=""> </span>IPv4
“installation charges” large enough to cover the
procurement of addresses</div>
<div class=""><br class="">
</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>*<span style="white-space:pre-wrap" class=""> </span>Brokers
assist ISPs and customers in many of the above
circumstances.</div>
<div class=""><br class="">
</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>+<span style="white-space:pre-wrap" class=""> </span>With
a variety of organizations holding IPv4 addresses that
may or may not even known they have them and whose</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>IPv4
resources may vastly exceed their needs, it is
(arguably) desirable to have those addresses be
transferred to parties</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>that have
current need for IPv4 addresses.</div>
<div class=""><br class="">
</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>*<span style="white-space:pre-wrap" class=""> </span>Brokers
provide a valuable service to the community identifying
and marketing these resources</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>*<span style="white-space:pre-wrap" class=""> </span>Paid
transfers provide an incentive for entities to make more
efficient use of the resources they have in order</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>to
monetize the resources they no longer need. Brokers are
frequently able to assist in this process.</div>
<div class=""><br class="">
</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>+<span style="white-space:pre-wrap" class=""> </span>With
the high cost of acquisition, IPv4 addresses have become
a capital intensive part of any network-dependent</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>business
model that must support IPv4. Further, there is some
risk that this capital outlay may be fore a resource</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>which
will abruptly and quickly lose its value and no longer
be needed well before it can be amortized as a capital</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>expenditure.
As such, it may make sense for some entities to transfer
that risk to another organization by using</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>a lease
structure instead of purchasing the addresses outright.</div>
<div class=""><br class="">
</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>*<span style="white-space:pre-wrap" class=""> </span>Brokers
that provide IPv4 leasing in an ethical and policy
compliant way provide a valuable service</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>to these
businesses. Yes, their price per address may eventually
be more than it would have cost</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>them to
purchase the addresses, but the same is true of
virtually any rental situation. On the other hand,</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>that
excess helps offset the risk that the lessor is taking
by owning a resource that may or may not remain</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>valuable
and may or may not continue to produce revenue.</div>
<div class="">
<blockquote type="cite" class="">
<div class=""><p class="">IP Leasing is very different from IP Transfer
which I see not problem they continue doing it. IP
Transfer at least we have some guarantees that the
directly receiving organization really justify for
them and that is a quiet important (I would say
fundamental) point to look at, because that is
fairer to everyone involved. What guarantees we
have when a IP Leasing is done in that sense, that
fairness start to lack here.</p>
</div>
</blockquote>
If we set the policies up correctly, we should have the
same exact guarantees on a lease.</div>
<div class=""><br class="">
</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>If $ISP
acquires a /10 through transfer and then issues various
subordinate prefixes to their customer, the only
guarantee</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>you have
that $ISP’s customers who receive the addresses really
justify them is that $ISP says so. We generally trust
$ISP</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>to act in
good faith.</div>
<div class=""><br class="">
</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>If $LESSOR
acquires a /10 through transfer and then leases various
subordinate prefixes to their customers, we have pretty</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>much the
same guarantee with the additional bit that $CUSTOMER is
at least willing to pay enough for the addresses to
$LESSOR</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>to make
the lease make sense. In general, I think it is somewhat
safe to assume that $CUSTOMER is not going to make a</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>monthly
recurring payment to $LESSOR for something they don’t
intend to use. If one’s intent is to deprive the market
and</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>inflate
the price, then the risk profile for such a transaction
is vastly more favorable if you purchase rather than
lease.</div>
<div class=""><br class="">
</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>Sure,
there could be lessors that don’t get reasonable
justification for allocations from their customers, but
there are most</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>certainly
ISPs in that category as well. Either way, you’ve got
very little assurance. A lessor can provide just as much</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>justification
to an RIR for the addresses they will allocate to leases
as an ISP can for addresses they will lease to their</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>customers.
The only difference is a lease with connectivity from
the same company or a lease from a company other than</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>the one(s)
providing connectivity.</div>
<div class="">
<blockquote type="cite" class="">
<div class=""><p class="">People see the brokers are doing a favor to
organizations in general by facilitating they get
some chunks of IPv4, but that in reality makes the
cost of IPv4 for both leasing and transfer more
and more expensive as it makes organization even
more dependent from these <span lang="en" class="">those
crumbs that seem to be offered with good
intention</span> but in reality it is feeding a
system that is contrary the interests to most
organizations involved.</p>
</div>
</blockquote>
Just as you are free to mount, balance, and rotate your
own tires, or, you can go to a tire store and have them
perform that service for a fee, brokers provide a
service for a fee. If you want to obtain addresses in
the transfer market without a broker, you’re still free
to do that. Brokers are not driving the cost of IPv4…
The scarcity and difficulty of operating with IPv4 is
driving the cost of IPv4. Brokers are along for the ride
providing a service and collecting a fee for that
service. Whether that fee is reasonable or not is (and
should be) entirely in the eye of the customer.
Customers are always free to walk away and find a
different supplier or look for their addresses
independently.</div>
<div class="">
<blockquote type="cite" class="">
<div class=""><p class="">It may sound a cliche but IPv4 is over and
organizations must learn how to survive with what
they have, reinvent themselves and make better
used of their IPv4 resources, deploy a proper
CGNAT, deploy IPv6 either they like it or not,
etc. If an organization have so little or none and
need some minimal amount is fine they seek for a
Transfer of a minimal amount with the help of
brokers. <br class="">
</p>
</div>
</blockquote>
I agree. However, the increasing cost of IPv4 is a
natural and organic part of that process and sticking
our heads in the sand and pretending that it is not the
economic reality of how the current world works will not
help anyone. Not the community, not organizations that
are short on IPv4 resources, and not the RIRs who are
only useful so long as their databases provide a
reasonably accurate reflection of the actual utilization
of the address space and who controls it.</div>
<div class=""><br class="">
</div>
<div class="">A broker is an LIR just like an ISP. Since ISPs are
now charging for addresses independent of connectivity
and bandwidth, it only makes sense that customers can
shop for them separately from different suppliers. Just
like you can buy tires for your car from the dealership
or from some other store that sells and supports tires,
IPv4 addresses are moving that way as well. The RIRs can
either recognize this and adapt to it with policies that
make sense and preserve some of the things you’ve
outlined as concerns above, or, they can simply deny the
reality of IPv4 leasing and lose track of how addresses
are actually managed for some significant chunks of the
internet.</div>
<div class="">
<blockquote type="cite" class="">
<div class=""><p class="">Encouraging IP Leasing as if it were something
normal just "because it exists today" is a shot in
the foot that in the long term only worsens the
existing scenario, it feeds a market without much
discretion increasing final prices for everyone
and what is the worst of all, creates even more
unfairness for everyone who has always submitted
to the rules we have until today for distributing
addresses to those who really have a real
justification to keep control of that resource
that does not belong to them.</p>
</div>
</blockquote>
I don’t believe that a policy that merely allows IPv4
leasing can be said to encourage it. Rather, it permits
it, recognizes that it exists and is not going to stop
existing just because policy pretends it can’t exist.</div>
<div class=""><br class="">
</div>
<div class="">The market is not likely to be significantly swayed
by policy in terms of pricing, with the exception that
AFRINIC has been able to preserve a devalued price on
addresses within their region due to their restrictive
lack of a transfer policy for moving addresses to/from
AFRINIC. However, while this has the effect of keeping
AFRINIC IPv4 addresses less expensive on the open
market, it also leads to a significant amount of
utilization of those addresses outside of policy and
quite a bit of hoarding of addresses by some of
AFRINIC’s largest members. ARIN’s counsel has advised
against naming names here, so I won’t, but if you want
names, contact me off list.</div>
<div class=""><br class="">
</div>
<div class="">Owen</div>
<div class=""> <br class="">
<blockquote type="cite" class="">
<div class=""><p class="">Regards<br class="">
Fernando<br class="">
</p>
<div class="">On 16/03/2022 13:09, David Farmer via ARIN-PPML
wrote:<br class="">
</div>
<blockquote type="cite" class="">
<div dir="ltr" class="">
<div class="">Yes, bundling IPv4 addresses with
bandwidth is permitted, and in the past was
common practice, heck even the expected
practice. However, the fact that IPv4 address
demand isn't decreasing significantly, the
costs to acquire new IPv4 addresses are
increasing significantly, and with the
increasing commoditization of bandwidth, it is
no longer economically viable to bundle
bandwidth, and its associated connectivity,
with IPv4 addressing. This is driving a
structural separation of bandwidth,
connectivity, and IPv4 addressing, from each
other, instead of bundling them together as in
the past.</div>
<div class=""><br class="">
</div>
<div class="">Let me state that differently; ISPs are
being driven, buy cost conscience consumers,
to separate the costs of bandwidth and the
costs of the IPv4 addresses needed to utilize
the bandwidth from each other. Minimally this
separation is achieved by accounting for the
costs on separate line items of a common bill
from a single provider. However, price
competition for bandwidth and IPv4 addresses
separately will inevitably drive a structural
separation between the two. Consumers will
want the best price they can get for bandwidth
and the best price they can get for IPv4
addresses, regardless of whether they come
from a single provider or not.</div>
<div class=""><br class="">
</div>
<div class="">Some may argue this is being driven by the
existence of address brokers, and their desire
to make money, I disagree. While address
brokers making money is the grease that keeps
this machine working, the need for the machine
is driven by; IPv4 free pool exhaustion, the
increasing cost of IPv4 addresses, and the
lack of adoption of IPv6.</div>
<div class="">In other words, address brokers wouldn't
exist if there wasn't a demand for their
services.</div>
<div class=""><br class="">
</div>
<div class="">In short, the economic conditions that
allowed for and even encouraged the
bundling of IPv4 addresses with bandwidth and
connectivity no longer exist, that world is
gone. While I have not personally yet
determined if I support this particular policy
text, nevertheless, the time has come to
recognize the next step in this inextricable
evolution of IPv4 address policy by the ARIN
policy community and permit IPv4 leasing.</div>
<div class=""><br class="">
</div>
<div class="">Thanks.</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Mar
11, 2022 at 5:05 PM John Santos <<a href="mailto:john@egh.com" target="_blank" class="">john@egh.com</a>>
wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I
disagree. The addresses are useless unless
they ALSO purchase access and <br class="">
routing from another network operator. How
is this cheaper?<br class="">
<br class="">
It is and always has been allowed to lease
bundled access of addresses and <br class="">
connectivity from a LIR, without any expense
for purchasing those addresses.<br class="">
<br class="">
<br class="">
On 3/11/2022 12:13 PM, Tom Fantacone wrote:<br class="">
> I support the proposal as written.<br class="">
> <br class="">
> It facilitates the provision of a
valuable service to a large swath of the
ARIN <br class="">
> community, namely the ability of
network operators with an operational need
to <br class="">
> lease IPv4 addresses from 3rd party
lessors at a fraction of the cost of <br class="">
> purchasing those addresses. Too often
we have seen network operators justify <br class="">
> their need for IPv4 space only to find
that they can't afford to make the <br class="">
> purchase. They end up using CGNAT or
some other sub-optimal solution.<br class="">
> <br class="">
> Bill, regarding your point "B", by
providing IPv4 leasing, these 3rd parties
are <br class="">
> certainly performing a function that
ARIN does not.<br class="">
> <br class="">
> <br class="">
> <br class="">
> ---- On Thu, 10 Mar 2022 17:46:36 -0500
*William Herrin <<a href="mailto:bill@herrin.us" target="_blank" class="">bill@herrin.us</a>>*
wrote ----<br class="">
> <br class="">
> On Wed, Mar 9, 2022 at 8:24 PM ARIN
<<a href="mailto:info@arin.net" target="_blank" class="">info@arin.net</a> <mailto:<a href="mailto:info@arin.net" target="_blank" class="">info@arin.net</a>>><br class="">
> wrote:<br class="">
> > * ARIN-2021-6: Permit IPv4
Leased Addresses for Purposes of Determining<br class="">
> Utilization for Future Allocations<br class="">
> <br class="">
> I continue to OPPOSE this proposal
because:<br class="">
> <br class="">
> A) It asks ARIN to facilitate
blatant and unapologetic rent-seeking<br class="">
> behavior with changes to public
policy.<br class="">
> <br class="">
> B) It proposes that third parties
perform precisely and only the<br class="">
> functions that ARIN itself performs
without any credible compliance<br class="">
> mechanism to assure the third party
performs to ARIN's standards or in<br class="">
> accordance with the community's
established number policy.<br class="">
> <br class="">
> Regards,<br class="">
> Bill Herrin<br class="">
> <br class="">
> <br class="">
> -- <br class="">
> William Herrin<br class="">
> <a href="mailto:bill@herrin.us" target="_blank" class="">bill@herrin.us</a> <mailto:<a href="mailto:bill@herrin.us" target="_blank" class="">bill@herrin.us</a>><br class="">
> <a href="https://bill.herrin.us/" rel="noreferrer" target="_blank" class="">https://bill.herrin.us/</a> <<a href="https://bill.herrin.us/" rel="noreferrer" target="_blank" class="">https://bill.herrin.us/</a>><br class="">
>
_______________________________________________<br class="">
> ARIN-PPML<br class="">
> You are receiving this message
because you are subscribed to<br class="">
> the ARIN Public Policy Mailing List
(<a href="mailto:ARIN-PPML@arin.net" target="_blank" class="">ARIN-PPML@arin.net</a><br class="">
> <mailto:<a href="mailto:ARIN-PPML@arin.net" target="_blank" class="">ARIN-PPML@arin.net</a>>).<br class="">
> Unsubscribe or manage your mailing
list subscription at:<br class="">
> <a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank" class="">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br class="">
> <<a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank" class="">https://lists.arin.net/mailman/listinfo/arin-ppml</a>><br class="">
> Please contact <a href="mailto:info@arin.net" target="_blank" class="">info@arin.net</a> <mailto:<a href="mailto:info@arin.net" target="_blank" class="">info@arin.net</a>>
if you experience any<br class="">
> issues.<br class="">
> <br class="">
> <br class="">
> <br class="">
> <br class="">
>
_______________________________________________<br class="">
> ARIN-PPML<br class="">
> You are receiving this message because
you are subscribed to<br class="">
> the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank" class="">ARIN-PPML@arin.net</a>).<br class="">
> Unsubscribe or manage your mailing list
subscription at:<br class="">
> <a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank" class="">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br class="">
> Please contact <a href="mailto:info@arin.net" target="_blank" class="">info@arin.net</a> if
you experience any issues.<br class="">
<br class="">
-- <br class="">
John Santos<br class="">
Evans Griffiths & Hart, Inc.<br class="">
781-861-0670 ext 539<br class="">
_______________________________________________<br class="">
ARIN-PPML<br class="">
You are receiving this message because you
are subscribed to<br class="">
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank" class="">ARIN-PPML@arin.net</a>).<br class="">
Unsubscribe or manage your mailing list
subscription at:<br class="">
<a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank" class="">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br class="">
Please contact <a href="mailto:info@arin.net" target="_blank" class="">info@arin.net</a> if
you experience any issues.<br class="">
</blockquote>
</div>
<br clear="all" class="">
<div class=""><br class="">
</div>
-- <br class="">
<div dir="ltr" class="">===============================================<br class="">
David Farmer <a href="mailto:Email%3Afarmer@umn.edu" target="_blank" class="">Email:farmer@umn.edu</a><br class="">
Networking & Telecommunication Services<br class="">
Office of Information Technology<br class="">
University of Minnesota <br class="">
2218 University Ave SE Phone:
612-626-0815<br class="">
Minneapolis, MN 55414-3029 Cell:
612-812-9952<br class="">
=============================================== </div>
</div>
<br class="">
<fieldset class=""></fieldset>
<pre class="">_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank" class="">ARIN-PPML@arin.net</a>).
Unsubscribe or manage your mailing list subscription at:
<a href="https://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank" class="">https://lists.arin.net/mailman/listinfo/arin-ppml</a>
Please contact <a href="mailto:info@arin.net" target="_blank" class="">info@arin.net</a> if you experience any issues.
</pre>
</blockquote>
</div>
_______________________________________________<br class="">
ARIN-PPML<br class="">
You are receiving this message because you are
subscribed to<br class="">
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank" class="">ARIN-PPML@arin.net</a>).<br class="">
Unsubscribe or manage your mailing list subscription
at:<br class="">
<a href="https://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank" class="">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br class="">
Please contact <a href="mailto:info@arin.net" target="_blank" class="">info@arin.net</a> if
you experience any issues.<br class="">
</blockquote>
<div class=""><br class="">
</div>
</div>
</div>
</div>
_______________________________________________<br class="">
ARIN-PPML<br class="">
You are receiving this message because you are subscribed to<br class="">
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank" class="">ARIN-PPML@arin.net</a>).<br class="">
Unsubscribe or manage your mailing list subscription at:<br class="">
<a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank" class="">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br class="">
Please contact <a href="mailto:info@arin.net" target="_blank" class="">info@arin.net</a>
if you experience any issues.<br class="">
</blockquote>
</div>
<br class="">
<fieldset class=""></fieldset>
<pre class="">_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank" class="">ARIN-PPML@arin.net</a>).
Unsubscribe or manage your mailing list subscription at:
<a href="https://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank" class="">https://lists.arin.net/mailman/listinfo/arin-ppml</a>
Please contact <a href="mailto:info@arin.net" target="_blank" class="">info@arin.net</a> if you experience any issues.
</pre>
</blockquote><p class=""><br class="">
</p>
</div>
_______________________________________________<br class="">
ARIN-PPML<br class="">
You are receiving this message because you are subscribed to<br class="">
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank" class="">ARIN-PPML@arin.net</a>).<br class="">
Unsubscribe or manage your mailing list subscription at:<br class="">
<a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank" class="">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br class="">
Please contact <a href="mailto:info@arin.net" target="_blank" class="">info@arin.net</a> if you experience any issues.<br class="">
</blockquote></div><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div dir="ltr" class="gmail_signature"><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class=""><span style="font-size:12.8px" class="">Twitter: </span><a href="https://twitter.com/holdenkarau" style="font-size:12.8px" target="_blank" class="">https://twitter.com/holdenkarau</a><br class=""></div><div class="">Books (Learning Spark, High Performance Spark, etc.): <a href="https://amzn.to/2MaRAG9" target="_blank" class="">https://amzn.to/2MaRAG9 </a></div><div class="">YouTube Live Streams: <a href="https://www.youtube.com/user/holdenkarau" target="_blank" class="">https://www.youtube.com/user/holdenkarau</a></div></div></div></div></div></div></div></div></div></div>
_______________________________________________<br class="">ARIN-PPML<br class="">You are receiving this message because you are subscribed to<br class="">the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" class="">ARIN-PPML@arin.net</a>).<br class="">Unsubscribe or manage your mailing list subscription at:<br class=""><a href="https://lists.arin.net/mailman/listinfo/arin-ppml" class="">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br class="">Please contact info@arin.net if you experience any issues.<br class=""></div></blockquote></div><br class=""></div></body></html>