Leasing involves a contract for services, just like an ISP.

It’s no more arms length than leasing addresses to someone you sell 
connectivity to, you have a nearly identical contractual relationship.

In fact, many ISPs charge for former customers to retain their addresses after 
they terminate their connectivity. How does that differ from a company which 
leases addresses without connectivity?

I’m currently neither in favor of nor opposed to the proposed policy as 
written. I think it needs work before it’s ready to be a policy.

However, I am in favor of formalizing the practice of leasing in policy since 
it is the economic reality of IPv4 for the foreseeable future, whether it is 
formalized in policy or not.

Owen


> On Mar 18, 2022, at 16:13, Michael Peddemors <mich...@linuxmagic.com> wrote:
> 
> I oppose..
> 
> This removes ARIN's governance of IPv4 resources completely.  And in a worst 
> case scenario a single party could buy up all of the IPv4 resources in 
> theory, and effectively control the internet.
> 
> "Leasing" is for to wide of a definition, and needs to be better described 
> before even considering this.
> 
> "leasing" is not a usage, IMHO in terms of the original mandate of ARIN, 
> without a fixed customer base for services (eg, it could be said every ISP 
> leases IPs to their customers) which is very different than saying we rent 
> the IP(s) to arm's length parties.
> 
> On 2022-03-17 17:23, Owen DeLong via ARIN-PPML wrote:
>> Actually, they’d be doing all of the same things any other LIR does with the 
>> exception of providing bandwidth and connectivity services.
>> They’d still be responsible for getting a reasonable justification from the 
>> customer, validating that justification, registering the addresses properly 
>> in whois, etc.
>> 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.
>> 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.
>> 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.
>> This situation will only get worse as the cost of IPv4 addresses continues 
>> to rise and as IPv6 deployment continues.
>> Owen
>>> On Mar 17, 2022, at 16:28 , Holden Karau <hol...@pigscanfly.ca 
>>> <mailto:hol...@pigscanfly.ca>> wrote:
>>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>> On Thu, Mar 17, 2022 at 4:18 PM Andrew Dul <andrew....@quark.net 
>>> <mailto:andrew....@quark.net>> wrote:
>>> 
>>>    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.
>>> 
>>>    With that policy change what types of limits does the community
>>>    think would be needed?
>>> 
>>>    Thanks,
>>>    Andrew
>>> 
>>>    On 3/17/2022 3:00 PM, Scott Leibrand wrote:
>>>>    +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.
>>>> 
>>>>    -Scott
>>>> 
>>>>    On Thu, Mar 17, 2022 at 1:33 PM Owen DeLong via ARIN-PPML
>>>>    <arin-ppml@arin.net <mailto:arin-ppml@arin.net>> wrote:
>>>> 
>>>> 
>>>> 
>>>>>        On Mar 16, 2022, at 15:22 , Fernando Frediani
>>>>>        <fhfredi...@gmail.com <mailto:fhfredi...@gmail.com>> wrote:
>>>>> 
>>>>>        Hi David
>>>>> 
>>>>>        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.
>>>>> 
>>>>        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.
>>>> 
>>>>>        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.
>>>>> 
>>>> 
>>>>        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:
>>>>        +Brokers and specified transfers were going to happen with or
>>>>        without the RIRs. If they happened without the RIRs,
>>>>        there’d be no accurate record of who was using which address
>>>>        space and the provenance of addresses would be
>>>>        very difficult to support or defend.
>>>> 
>>>>        *Benefit to the community from brokers: (ethical) brokers are
>>>>        familiar with the rules in the RIRs in which
>>>>        they operate and can assist their customers in accurate and
>>>>        compliant registration updates and
>>>>        aid in keeping the allocation database(s) accurate.
>>>> 
>>>>        +With the economic realities of IPv4 addresses becoming
>>>>        progressively more and more expensive and the advent
>>>>        of ISPs with limited IPv4 resources available, it is
>>>>        inevitable that more and more IP service providers will be
>>>>        doing one or more of the following:
>>>> 
>>>>        +Separate surcharges for IPv4 addresses
>>>>        +Expecting customers to supply their own IPv4 addresses
>>>>        +Surcharges for IPv4 services
>>>>        +IPv4 “installation charges” large enough to cover the
>>>>        procurement of addresses
>>>> 
>>>>        *Brokers assist ISPs and customers in many of the above
>>>>        circumstances.
>>>> 
>>>>        +With a variety of organizations holding IPv4 addresses that
>>>>        may or may not even known they have them and whose
>>>>        IPv4 resources may vastly exceed their needs, it is
>>>>        (arguably) desirable to have those addresses be transferred
>>>>        to parties
>>>>        that have current need for IPv4 addresses.
>>>> 
>>>>        *Brokers provide a valuable service to the community
>>>>        identifying and marketing these resources
>>>>        *Paid transfers provide an incentive for entities to make
>>>>        more efficient use of the resources they have in order
>>>>        to monetize the resources they no longer need. Brokers are
>>>>        frequently able to assist in this process.
>>>> 
>>>>        +With the high cost of acquisition, IPv4 addresses have
>>>>        become a capital intensive part of any network-dependent
>>>>        business model that must support IPv4. Further, there is some
>>>>        risk that this capital outlay may be fore a resource
>>>>        which will abruptly and quickly lose its value and no longer
>>>>        be needed well before it can be amortized as a capital
>>>>        expenditure. As such, it may make sense for some entities to
>>>>        transfer that risk to another organization by using
>>>>        a lease structure instead of purchasing the addresses outright.
>>>> 
>>>>        *Brokers that provide IPv4 leasing in an ethical and policy
>>>>        compliant way provide a valuable service
>>>>        to these businesses. Yes, their price per address may
>>>>        eventually be more than it would have cost
>>>>        them to purchase the addresses, but the same is true of
>>>>        virtually any rental situation.  On the other hand,
>>>>        that excess helps offset the risk that the lessor is taking
>>>>        by owning a resource that may or may not remain
>>>>        valuable and may or may not continue to produce revenue.
>>>>> 
>>>>>        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.
>>>>> 
>>>>        If we set the policies up correctly, we should have the same
>>>>        exact guarantees on a lease.
>>>> 
>>>>        If $ISP acquires a /10 through transfer and then issues
>>>>        various subordinate prefixes to their customer, the only
>>>>        guarantee
>>>>        you have that $ISP’s customers who receive the addresses
>>>>        really justify them is that $ISP says so. We generally trust $ISP
>>>>        to act in good faith.
>>>> 
>>>>        If $LESSOR acquires a /10 through transfer and then leases
>>>>        various subordinate prefixes to their customers, we have pretty
>>>>        much the same guarantee with the additional bit that
>>>>        $CUSTOMER is at least willing to pay enough for the addresses
>>>>        to $LESSOR
>>>>        to make the lease make sense. In general, I think it is
>>>>        somewhat safe to assume that $CUSTOMER is not going to make a
>>>>        monthly recurring payment to $LESSOR for something they don’t
>>>>        intend to use. If one’s intent is to deprive the market and
>>>>        inflate the price, then the risk profile for such a
>>>>        transaction is vastly more favorable if you purchase rather
>>>>        than lease.
>>>> 
>>>>        Sure, there could be lessors that don’t get reasonable
>>>>        justification for allocations from their customers, but there
>>>>        are most
>>>>        certainly ISPs in that category as well. Either way, you’ve
>>>>        got very little assurance. A lessor can provide just as much
>>>>        justification to an RIR for the addresses they will allocate
>>>>        to leases as an ISP can for addresses they will lease to their
>>>>        customers. The only difference is a lease with connectivity
>>>>        from the same company or a lease from a company other than
>>>>        the one(s) providing connectivity.
>>>>> 
>>>>>        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 those crumbs that seem to be
>>>>>        offered with good intention but in reality it is feeding a
>>>>>        system that is contrary the interests to most organizations
>>>>>        involved.
>>>>> 
>>>>        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.
>>>>> 
>>>>>        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.
>>>>> 
>>>>        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.
>>>> 
>>>>        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.
>>>>> 
>>>>>        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.
>>>>> 
>>>>        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.
>>>> 
>>>>        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.
>>>> 
>>>>        Owen
>>>> 
>>>>>        Regards
>>>>>        Fernando
>>>>> 
>>>>>        On 16/03/2022 13:09, David Farmer via ARIN-PPML wrote:
>>>>>>        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.
>>>>>> 
>>>>>>        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.
>>>>>> 
>>>>>>        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.
>>>>>>        In other words, address brokers wouldn't exist if there
>>>>>>        wasn't a demand for their services.
>>>>>> 
>>>>>>        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.
>>>>>> 
>>>>>>        Thanks.
>>>>>> 
>>>>>>        On Fri, Mar 11, 2022 at 5:05 PM John Santos <j...@egh.com
>>>>>>        <mailto:j...@egh.com>> wrote:
>>>>>> 
>>>>>>            I disagree.  The addresses are useless unless they ALSO
>>>>>>            purchase access and
>>>>>>            routing from another network operator.  How is this
>>>>>>            cheaper?
>>>>>> 
>>>>>>            It is and always has been allowed to lease bundled
>>>>>>            access of addresses and
>>>>>>            connectivity from a LIR, without any expense for
>>>>>>            purchasing those addresses.
>>>>>> 
>>>>>> 
>>>>>>            On 3/11/2022 12:13 PM, Tom Fantacone wrote:
>>>>>>            > I support the proposal as written.
>>>>>>            >
>>>>>>            > It facilitates the provision of a valuable service to
>>>>>>            a large swath of the ARIN
>>>>>>            > community, namely the ability of network operators
>>>>>>            with an operational need to
>>>>>>            > lease IPv4 addresses from 3rd party lessors at a
>>>>>>            fraction of the cost of
>>>>>>            > purchasing those addresses.  Too often we have seen
>>>>>>            network operators justify
>>>>>>            > their need for IPv4 space only to find that they
>>>>>>            can't afford to make the
>>>>>>            > purchase.  They end up using CGNAT or some other
>>>>>>            sub-optimal solution.
>>>>>>            >
>>>>>>            > Bill, regarding your point "B", by providing IPv4
>>>>>>            leasing, these 3rd parties are
>>>>>>            > certainly performing a function that ARIN does not.
>>>>>>            >
>>>>>>            >
>>>>>>            >
>>>>>>            > ---- On Thu, 10 Mar 2022 17:46:36 -0500 *William
>>>>>>            Herrin <b...@herrin.us <mailto:b...@herrin.us>>* wrote ----
>>>>>>            >
>>>>>>            >     On Wed, Mar 9, 2022 at 8:24 PM ARIN
>>>>>>            <i...@arin.net
>>>>>>            <mailto:i...@arin.net> <mailto:i...@arin.net
>>>>>>            <mailto:i...@arin.net>>>
>>>>>>            >     wrote:
>>>>>>            >      > * ARIN-2021-6: Permit IPv4 Leased Addresses
>>>>>>            for Purposes of Determining
>>>>>>            >     Utilization for Future Allocations
>>>>>>            >
>>>>>>            >     I continue to OPPOSE this proposal because:
>>>>>>            >
>>>>>>            >     A) It asks ARIN to facilitate blatant and
>>>>>>            unapologetic rent-seeking
>>>>>>            >     behavior with changes to public policy.
>>>>>>            >
>>>>>>            >     B) It proposes that third parties perform
>>>>>>            precisely and only the
>>>>>>            >     functions that ARIN itself performs without any
>>>>>>            credible compliance
>>>>>>            >     mechanism to assure the third party performs to
>>>>>>            ARIN's standards or in
>>>>>>            >     accordance with the community's established
>>>>>>            number policy.
>>>>>>            >
>>>>>>            >     Regards,
>>>>>>            >     Bill Herrin
>>>>>>            >
>>>>>>            >
>>>>>>            >     --
>>>>>>            >     William Herrin
>>>>>>            > b...@herrin.us
>>>>>>            <mailto:b...@herrin.us> <mailto:b...@herrin.us
>>>>>>            <mailto:b...@herrin.us>>
>>>>>>            > https://bill.herrin.us/
>>>>>>            <https://bill.herrin.us/> <https://bill.herrin.us/
>>>>>>            <https://bill.herrin.us/>>
>>>>>>            >  _______________________________________________
>>>>>>            >     ARIN-PPML
>>>>>>            >     You are receiving this message because you are
>>>>>>            subscribed to
>>>>>>            >     the ARIN Public Policy Mailing List
>>>>>>            (ARIN-PPML@arin.net <mailto:ARIN-PPML@arin.net>
>>>>>>            >     <mailto:ARIN-PPML@arin.net
>>>>>>            <mailto:ARIN-PPML@arin.net>>).
>>>>>>            >     Unsubscribe or manage your mailing list
>>>>>>            subscription at:
>>>>>>            > https://lists.arin.net/mailman/listinfo/arin-ppml
>>>>>>            <https://lists.arin.net/mailman/listinfo/arin-ppml>
>>>>>>            >                
>>>>>> <https://lists.arin.net/mailman/listinfo/arin-ppml
>>>>>>            <https://lists.arin.net/mailman/listinfo/arin-ppml>>
>>>>>>            >     Please contact i...@arin.net
>>>>>>            <mailto:i...@arin.net> <mailto:i...@arin.net
>>>>>>            <mailto:i...@arin.net>> if you experience any
>>>>>>            >     issues.
>>>>>>            >
>>>>>>            >
>>>>>>            >
>>>>>>            >
>>>>>>            > _______________________________________________
>>>>>>            > ARIN-PPML
>>>>>>            > You are receiving this message because you are
>>>>>>            subscribed to
>>>>>>            > the ARIN Public Policy Mailing List
>>>>>>            (ARIN-PPML@arin.net <mailto:ARIN-PPML@arin.net>).
>>>>>>            > Unsubscribe or manage your mailing list subscription at:
>>>>>>            > https://lists.arin.net/mailman/listinfo/arin-ppml
>>>>>>            <https://lists.arin.net/mailman/listinfo/arin-ppml>
>>>>>>            > Please contact i...@arin.net
>>>>>>            <mailto:i...@arin.net> if you experience any issues.
>>>>>> 
>>>>>>            --             John Santos
>>>>>>            Evans Griffiths & Hart, Inc.
>>>>>>            781-861-0670 ext 539
>>>>>>            _______________________________________________
>>>>>>            ARIN-PPML
>>>>>>            You are receiving this message because you are
>>>>>>            subscribed to
>>>>>>            the ARIN Public Policy Mailing List (ARIN-PPML@arin.net
>>>>>>            <mailto:ARIN-PPML@arin.net>).
>>>>>>            Unsubscribe or manage your mailing list subscription at:
>>>>>>            https://lists.arin.net/mailman/listinfo/arin-ppml
>>>>>>            <https://lists.arin.net/mailman/listinfo/arin-ppml>
>>>>>>            Please contact i...@arin.net <mailto:i...@arin.net> if
>>>>>>            you experience any issues.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>        --         ===============================================
>>>>>>        David Farmer Email:far...@umn.edu
>>>>>>        <mailto:email%3afar...@umn.edu>
>>>>>>        Networking & Telecommunication Services
>>>>>>        Office of Information Technology
>>>>>>        University of Minnesota
>>>>>>        2218 University Ave SE        Phone: 612-626-0815
>>>>>>        Minneapolis, MN 55414-3029   Cell: 612-812-9952
>>>>>>        ===============================================
>>>>>> 
>>>>>>        _______________________________________________
>>>>>>        ARIN-PPML
>>>>>>        You are receiving this message because you are subscribed to
>>>>>>        the ARIN Public Policy Mailing List (ARIN-PPML@arin.net  
>>>>>> <mailto:ARIN-PPML@arin.net>).
>>>>>>        Unsubscribe or manage your mailing list subscription at:
>>>>>>        https://lists.arin.net/mailman/listinfo/arin-ppml  
>>>>>> <https://lists.arin.net/mailman/listinfo/arin-ppml>
>>>>>>        Please contacti...@arin.net  <mailto:i...@arin.net>  if you 
>>>>>> experience any issues.
>>>>>        _______________________________________________
>>>>>        ARIN-PPML
>>>>>        You are receiving this message because you are subscribed to
>>>>>        the ARIN Public Policy Mailing List (ARIN-PPML@arin.net
>>>>>        <mailto:ARIN-PPML@arin.net>).
>>>>>        Unsubscribe or manage your mailing list subscription at:
>>>>>        https://lists.arin.net/mailman/listinfo/arin-ppml
>>>>>        <https://lists.arin.net/mailman/listinfo/arin-ppml>
>>>>>        Please contact i...@arin.net <mailto:i...@arin.net> if you
>>>>>        experience any issues.
>>>> 
>>>>        _______________________________________________
>>>>        ARIN-PPML
>>>>        You are receiving this message because you are subscribed to
>>>>        the ARIN Public Policy Mailing List (ARIN-PPML@arin.net
>>>>        <mailto:ARIN-PPML@arin.net>).
>>>>        Unsubscribe or manage your mailing list subscription at:
>>>>        https://lists.arin.net/mailman/listinfo/arin-ppml
>>>>        <https://lists.arin.net/mailman/listinfo/arin-ppml>
>>>>        Please contact i...@arin.net <mailto:i...@arin.net> if you
>>>>        experience any issues.
>>>> 
>>>> 
>>>>    _______________________________________________
>>>>    ARIN-PPML
>>>>    You are receiving this message because you are subscribed to
>>>>    the ARIN Public Policy Mailing List (ARIN-PPML@arin.net  
>>>> <mailto:ARIN-PPML@arin.net>).
>>>>    Unsubscribe or manage your mailing list subscription at:
>>>>    https://lists.arin.net/mailman/listinfo/arin-ppml  
>>>> <https://lists.arin.net/mailman/listinfo/arin-ppml>
>>>>    Please contacti...@arin.net  <mailto:i...@arin.net>  if you experience 
>>>> any issues.
>>> 
>>> 
>>>    _______________________________________________
>>>    ARIN-PPML
>>>    You are receiving this message because you are subscribed to
>>>    the ARIN Public Policy Mailing List (ARIN-PPML@arin.net
>>>    <mailto:ARIN-PPML@arin.net>).
>>>    Unsubscribe or manage your mailing list subscription at:
>>>    https://lists.arin.net/mailman/listinfo/arin-ppml
>>>    <https://lists.arin.net/mailman/listinfo/arin-ppml>
>>>    Please contact i...@arin.net <mailto:i...@arin.net> if you
>>>    experience any issues.
>>> 
>>> 
>>> 
>>> -- 
>>> Twitter: https://twitter.com/holdenkarau <https://twitter.com/holdenkarau>
>>> Books (Learning Spark, High Performance Spark, etc.): 
>>> https://amzn.to/2MaRAG9 <https://amzn.to/2MaRAG9>
>>> YouTube Live Streams: https://www.youtube.com/user/holdenkarau 
>>> <https://www.youtube.com/user/holdenkarau>
>>> _______________________________________________
>>> ARIN-PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net 
>>> <mailto:ARIN-PPML@arin.net>).
>>> Unsubscribe or manage your mailing list subscription at:
>>> https://lists.arin.net/mailman/listinfo/arin-ppml 
>>> <https://lists.arin.net/mailman/listinfo/arin-ppml>
>>> Please contact i...@arin.net if you experience any issues.
>> _______________________________________________
>> ARIN-PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> https://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact i...@arin.net if you experience any issues.
> 
> 
> 
> -- 
> "Catch the Magic of Linux..."
> ------------------------------------------------------------------------
> Michael Peddemors, President/CEO LinuxMagic Inc.
> Visit us at http://www.linuxmagic.com @linuxmagic
> A Wizard IT Company - For More Info http://www.wizard.ca
> "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
> ------------------------------------------------------------------------
> 604-682-0300 Beautiful British Columbia, Canada
> 
> This email and any electronic data contained are confidential and intended
> solely for the use of the individual or entity to which they are addressed.
> Please note that any views or opinions presented in this email are solely
> those of the author and are not intended to represent those of the company.
> _______________________________________________
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.

_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Reply via email to