[arin-ppml] Revised - Draft Policy ARIN-2025-1: Clarify ISP and LIR Definitions and References to Address Ambiguity in NRPM Text

[Jay Moran]

Thanks, Owen and Dale. I should be specifically clear:

I too believe LIR is the term that should be used. My own company's example
(Fiserv) is exactly why using the term ISP is the wrong choice in my
opinion. In the end if the majority wishes to use ISP though, then that is
fine.

Jay
--
Jay Moran


On Fri, Sep 19, 2025 at 5:27 PM Dale W. Carder <dwcarder at es.net> wrote:

> Thus spake Jay Moran via ARIN-PPML (arin-ppml at arin.net) on Fri, Sep 19,
> 2025 at 03:18:46PM -0400:
> > Thank you, Leif. Good information. I think you said that it would be hard
> > to get Hank Williams, Jr. to re-record his song to say "Are you ready for
> > somet American Football!!!" So, we'll keep using ISP.
> >
> > I'm okay with the switch to ISP and the footnote about the LIR term being
> > equivalent - essentially what Mohibul said quoted below. I think we
> should
> > also add another footnote and state that American's term "Soccer" is also
> > equal to the other 7.5+ BILLION people in the world's Football. ;-)
> >
> > "To bridge this, I’d suggest we converge on a practical editorial
> approach:
> >
> > • Select one preferred term for the NRPM (ISP or LIR).
> >
> > • Add a clear definition note stating that ISP and LIR are can be used
> > interchangeably in ARIN policy."
> >
> > My company still is NOT the commonly accepted definition of ISP, and we
> > will STILL allocate address space to our customers for various reasons,
> so
> > I guess we're also this special use of the term ISP.
>
> This would be the problem I have as well.  ISP is overloaded with varying
> colloquial usage, particularly with an interdependence with customers,
> commerce having transpired, or even that Internet service is a line of
> business.  From a policy perspective I think it's problematic to reign
> "ISP" in vs migrate to LIR as a term of art and work to define how it
> operates within this region.
>
> Dale
>
>
> > On Fri, Sep 19, 2025 at 2:53 PM Leif Sawyer via ARIN-PPML <
> > arin-ppml at arin.net> wrote:
> >
> > > Hi Owen (et al) –
> > >
> > >
> > >
> > > Apologies if this is a little scattered, but I’m trying to summarize
> > > everything that’s happened on the back end and front end.
> > >
> > >
> > >
> > >
> > >
> > > Internally, ARIN uses ISP (or end-user)  nearly universally for all
> > > communications, back-end terminology, documentation, and
> business-practices.
> > >
> > >
> > >
> > > It DOES, however, use  LIR/ISP  in the IP request flow  (
> > > https://account.arin.net/public/secure/resources/request/ip)  with the
> > > following definition:
> > >
> > >
> > >
> > > “An LIR/ISP (Local Internet Registry or Internet Service Provider) is
> an
> > > organization that provides Internet services to other organizations,
> its
> > > customers, and/or individuals other than its
> > >
> > > employees. Internet services include, but are not limited to,
> connectivity
> > > services, web hosting services, colocation, dedicated servers, virtual
> > > private servers, and virtual private networks.”
> > >
> > >
> > >
> > > We can align the definitions in the NRPM to match the line above,
> noting
> > > that  LIR is a term not used in this region but is operationally
> equivalent
> > > here.
> > >
> > >
> > >
> > > Since it’s beyond the scope of a policy proposal to change the
> business of
> > > ARIN ( back-end programming, databases, etc )  to move to “LIR” as the
> > > industry-standard term of art (rather than ISP)
> > >
> > > it would require following the ACSP – so that everyone can weigh in on
> > > whether the cost/effort/desire to implement is community supported.
> > > Alongside the policy changes, of course.
> > >
> > >
> > >
> > > Since using the conjoined term  “LIR/ISP”  was shot down at ARIN55 ,
> and
> > > since LIR isn’t used in region, the move to “ISP” as the single term
> was
> > > proposed for the Section 6 corrections, in order to match the remaining
> > > sections of the NRPM.   (converting to LIR impacts the entirety of the
> NRPM)
> > >
> > >
> > >
> > > Note also that all of this stems from the Section 6 global policy
> > > inclusion not correcting the [ LIR==ISP ] “applies to this document”
> > > statement into “applies to this section” when it was imported after
> > > approval.
> > >
> > >
> > >
> > > My personal question:  Outside of limited scope of people who work with
> > > directly with the outside-region registry systems, is there any other
> > > compelling reason to move to LIR in this region, given the amount of
> work
> > > involved in re-education and retooling?
> > >
> > >
> > >
> > >
> > >
> > > I hope that helps reframe and clarify the work that’s happening here,
> and
> > > keeps this discussion moving!
> > >
> > >
> > >
> > > -Leif
> > >
> > >
> > >
> > > *Leif Sawyer*
> > >
> > > *GCI* | he/him | Engineer, CNI – Standards and Planning
> > >
> > > *t:* 907-351-1535 | *w:* www.gci.com | KL5BN
> > >
> > >
> > >
> > > *From:* ARIN-PPML <arin-ppml-bounces at arin.net> *On Behalf Of *Owen
> DeLong
> > > via ARIN-PPML
> > > *Sent:* Wednesday, September 17, 2025 8:22 AM
> > > *To:* Jay Moran <jay-ARIN at tp.org>
> > > *Cc:* arin-ppml at arin.net
> > > *Subject:* Re: [arin-ppml] Revised - Draft Policy ARIN-2025-1: Clarify
> > > ISP and LIR Definitions and References to Address Ambiguity in NRPM
> Text
> > >
> > >
> > >
> > > [*EXTERNAL EMAIL* - CAUTION: Do not open unexpected attachments or
> links.]
> > >
> > > Exactly what Jay said. David’s definitions are livable, but why not
> join
> > > the rest of the world in using globally accepted terminology rather
> than
> > > contorting the definition of ISP because we can. It kind of reminds me
> of
> > > the US still using imperial units while the rest of the world moved on
> to
> > > SI (metric) long ago.
> > >
> > >
> > >
> > > Owen
> > >
> > >
> > >
> > >
> > >
> > > On Sep 17, 2025, at 05:18, Jay Moran (AOL) via ARIN-PPML <
> > > arin-ppml at arin.net> wrote:
> > >
> > > 
> > >
> > > I can live with that definition; it covers the description of my
> > > organization as written. However I believe that goes against the
> commonly
> > > understood definition of an ISP.
> > >
> > >
> > >
> > > I’ll state one last time that LIR seems fine, and just because we in
> the
> > > “American Region” don’t normally use or “like” the term/acronym LIR,
> > > doesn’t make it any less accurate… or globally accepted where the
> majority
> > > of humans live.
> > >
> > >
> > >
> > > For now, I am going to go watch some football. ;-)
> > >
> > >
> > >
> > >
> > > --
> > > Jay Moran
> > > http://linkedin.com/in/jaycmoran
> > >
> > >
> > >
> > >
> > >
> > > On Wed, Sep 17, 2025 at 7:27 AM David Farmer via ARIN-PPML <
> > > arin-ppml at arin.net> wrote:
> > >
> > > I suggest the following revised definitions for LIR and ISP;
> > >
> > >
> > >
> > > 2.4. Local Internet Registry (LIR)
> > >
> > >
> > >
> > > A Local Internet Registry (LIR) is an IR that assigns IP addresses to
> the
> > > users of the network services that it provides. LIRs are generally
> Internet
> > > Service Providers (ISPs) whose customers are primarily end users, other
> > > organizations, or possibly other ISPs. LIR is the term used for an ISP
> in
> > > the context of the Internet Registry System, defined in RFC 7020 and
> in the
> > > diagram at the beginning of this section.
> > >
> > >
> > >
> > > 2.18  Internet Service Provider (ISP)
> > >
> > >
> > >
> > > An Internet Service Provider (ISP) is any organization that provides
> > > Internet services to its customers, who are primarily end users
> > > (individuals other than employees or visitors to a premises), other
> > > organizations, or possibly other ISPs. The specific Internet services
> are
> > > irrelevant; the important aspect is that Internet Number Resources are
> > > consumed and justified by assigning them to customers. ISP is the term
> used
> > > in the context of ARIN Policy, instead of Local Internet Registry
> (LIR).
> > >
> > >
> > >
> > > Thanks.
> > >
> > >
> > >
> > >
> > >
> > > On Tue, Sep 16, 2025 at 5:28 PM Mohibul Mahmud <
> mohibul.mahmud at gmail.com>
> > > wrote:
> > >
> > > Hello Team,
> > >
> > >
> > >
> > > It seems most of us agree that clarity is the main goal. Would it make
> > > sense to keep one preferred term in the NRPM, but also add a short
> note in
> > > the definitions section that explains how ISP and LIR are used
> > > interchangeably in ARIN policy?
> > >
> > >
> > >
> > > Best
> > >
> > > Mohibul Mahmud
> > >
> > > Microsoft
> > >
> > > ARIN Advisory Council Candidate
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Tue, Sep 16, 2025 at 3:54 PM Owen DeLong via ARIN-PPML <
> > > arin-ppml at arin.net> wrote:
> > >
> > > Precisely what David said. I prefer LIR since I think ISP is
> over-specific
> > > in its vernacular usage and LIR is the more accurate term for what
> ARIN is
> > > actually doing. However, I can live with either if the NRPM definition
> of
> > > whichever term is used matches the general meaning of LIR.
> > >
> > >
> > >
> > > The policy as written would disqualify several, if not many legitimate
> > > users of IP addresses.
> > >
> > >
> > >
> > > Owen
> > >
> > >
> > >
> > >
> > >
> > > On Sep 16, 2025, at 11:58, David Farmer <farmer at umn.edu> wrote:
> > >
> > > 
> > >
> > > Leif.
> > >
> > >
> > >
> > > If the ARIN community wants to use the term "ISP" instead of "LIR", I
> can
> > > accept that. However, the definition for "ISP" provided in the draft
> policy
> > > focuses on the types of services the ISP provides, which are mostly
> > > irrelevant from an ARIN Policy perspective. The current definition of
> LIR
> > > focuses on the relationship between users/customers and the LIR/ISP. I
> > > would call your attention to the definition John Seeeting provided or
> the
> > > definition of LIR in RFC 7020. They focus on what is important from an
> ARIN
> > > Policy perspective: the relationship between the LIR/ISP and its
> > > users/customers, and the relationship with the RIR. If the definition
> > > provided focuses on the important aspects of ARIN policy, the term used
> > > will be unimportant; LIR and ISP can be used interchangeably. But that
> is
> > > not the case for the provided definition of ISP in the draft policy.
> > >
> > >
> > >
> > > Thanks.
> > >
> > >
> > >
> > > On Tue, Sep 16, 2025 at 1:11 PM Leif Sawyer via ARIN-PPML <
> > > arin-ppml at arin.net> wrote:
> > >
> > > Owen –
> > >
> > >
> > >
> > >    This latest update is a result of the April ARIN meeting, where the
> > > overwhelming message was to “remove LIR” and use ISP, since that’s what
> > >
> > > Is used both internally by ARIN, and predominantly within this region.
> > >
> > >
> > >
> > > Note that the changes proposed are for section 6, to normalize it
> against
> > > the remainder of the NRPM’s use of ISP.
> > >
> > >
> > >
> > > -L
> > >
> > >
> > >
> > > *Leif Sawyer*
> > >
> > > *GCI* | he/him | Engineer, CNI – Standards and Planning
> > >
> > > *t:* 907-351-1535 | *w:* www.gci.com | KL5BN
> > >
> > >
> > >
> > > *From:* ARIN-PPML <arin-ppml-bounces at arin.net> *On Behalf Of *Owen
> DeLong
> > > via ARIN-PPML
> > > *Sent:* Saturday, September 13, 2025 7:39 AM
> > > *To:* ARIN <info at arin.net>
> > > *Cc:* arin-ppml at arin.net
> > > *Subject:* Re: [arin-ppml] Revised - Draft Policy ARIN-2025-1: Clarify
> > > ISP and LIR Definitions and References to Address Ambiguity in NRPM
> Text
> > >
> > >
> > >
> > > [*EXTERNAL EMAIL* - CAUTION: Do not open unexpected attachments or
> links.]
> > >
> > > I think this is the wrong approach.
> > >
> > > In reality, ARIN cares about LIRs and deals with LIRs and end users.
> It is
> > > generally irrelevant from a policy perspective whether a given LIR is
> an
> > > ISP or not.
> > >
> > > Therefore, IMHO, a better approach would be to simply consolidate to
> the
> > > LIR term and eliminate ISP from the NRPM.
> > >
> > > IPv6 policy already explicitly declares that the terms are
> interchangeable
> > > from a policy perspective.
> > >
> > > Owen
> > >
> > >
> > > > On Sep 12, 2025, at 10:18, ARIN <info at arin.net> wrote:
> > > >
> > > > The following Draft Policy has been revised:
> > > >
> > > > *ARIN-2025-1: Clarify ISP and LIR Definitions and References to
> Address
> > > Ambiguity in NRPM Text
> > > >
> > > > Revised text is below and can be found at:
> > > >
> > > > https://www.arin.net/participate/policy/drafts/2025_1/
> > > >
> > > > A PDF document showing the proposed NRPM edits is available to
> download
> > > at:
> > > >
> > > >
> > >
> https://arin.net/participate/policy/drafts/pdf/ARIN_2025_1_diff_091225.pdf
> > > >
> > > > You are encouraged to discuss all Draft Policies on PPML. The AC will
> > > evaluate the discussion to assess the conformance of this Draft Policy
> with
> > > ARIN's Principles of Internet number resource policy as stated in the
> > > Policy Development Process (PDP). Specifically, these principles are:
> > > >
> > > > * Enabling Fair and Impartial Number Resource Administration
> > > > * Technically Sound
> > > > * Supported by the Community
> > > >
> > > > The PDP can be found at:
> > > >
> > > > https://www.arin.net/participate/policy/pdp/
> > > >
> > > > Draft Policies and Proposals under discussion can be found at:
> > > >
> > > > https://www.arin.net/participate/policy/drafts/
> > > >
> > > > Regards,
> > > >
> > > > Eddie Diego
> > > > Policy Analyst
> > > > American Registry for Internet Numbers (ARIN)
> > > >
> > > >
> > > >
> > > > Draft Policy ARIN-2025-1: Clarify ISP and LIR Definitions and
> References
> > > to Address Ambiguity in NRPM Text
> > > >
> > > > Problem Statement:
> > > >
> > > > Section 2.4 of the NRPM defines an LIR but does not explicitly
> define an
> > > ISP. An ISP is defined in the context of an LIR, but the explicit
> > > definition is otherwise assumed.
> > > >
> > > > Through implication and in common business practice, all ISPs are
> LIRs,
> > > but not all LIRs are ISPs.
> > > >
> > > > This proposal adds clarity by creating an explicit definition for
> ISP,
> > > clarifying the historical and out-of-region usage for the term LIR, and
> > > replaces LIR with ISP throughout the NRPM as appropriate.
> > > >
> > > > Policy Statement:
> > > >
> > > > Add Internet Service Provider definition:
> > > >
> > > > Remove the word “primarily” from the definition of LIR and add usage
> > > clarification:
> > > >
> > > > FROM:
> > > >
> > > > 2.4. Local Internet Registry (LIR)
> > > >
> > > > A Local Internet Registry (LIR) is primarily an IR that assigns IP
> > > addresses to the users of the network services that it provides. LIRs
> are
> > > generally Internet Service Providers (ISPs) whose customers are
> primarily
> > > end users and possibly other ISPs.
> > > >
> > > > TO:
> > > >
> > > > 2.4. Local Internet Registry (LIR)
> > > >
> > > > A Local Internet Registry (LIR) is an IR that assigns IP addresses to
> > > the users of the network services that it provides. LIRs are generally
> > > Internet Service Providers (ISPs) whose customers are primarily end
> users
> > > and possibly other ISPs. _While LIR has been historically referenced in
> > > policies for ease of comparing other region's policies, LIR is not
> used in
> > > the ARIN service region; ISP is the equivalent term._
> > > >
> > > >
> > > > Add definition for ISP:
> > > >
> > > > 2.18 Internet Service Provider (ISP)
> > > >
> > > > An Internet Service Provider (ISP) is a type of organization that
> > > provides Internet services to other organizations, its customers,
> and\or
> > > individuals other than its employees. Internet services include, but
> are
> > > not limited to, connectivity services, web services, colocation,
> dedicated
> > > servers, virtual private servers, and virtual private networks.
> > > >
> > > >
> > > > Replace Section 6.5.1a
> > > >
> > > > Original Text: “The terms ISP and LIR are used interchangeably in
> this
> > > document and any use of either term shall be construed to include both
> > > meanings.”
> > > >
> > > > New Text: “[Retired]”
> > > >
> > > >
> > > > Remove all references in section 6.5 of LIR where appropriate:
> > > >
> > > > [Editing note: For the purposes of clarity in plaintext communication
> > > mediums, any changes to the text is denoted with the underscore
> character
> > > before and after the insertion. The underscore character is not
> considered
> > > a part of the final text.]
> > > >
> > > >
> > > > Amend Section 6.5.2 to replace LIR with ISP, 12 in total
> > > >
> > > > 6.5.2. Initial Allocation to _ISPs_
> > > >
> > > > 6.5.2.1. Size
> > > >
> > > > 1. All allocations shall be made on nibble boundaries.
> > > >
> > > > 2. In no case shall an _ISP_ receive smaller than a /32 unless they
> > > specifically request a /36 or /40. In order to be eligible for a /40,
> an
> > > ISP must meet the following requirements:
> > > >
> > > > - Hold IPv4 direct allocations totaling a /24 or less (to include
> zero)
> > > >
> > > > - Hold IPv4 reassignments/reallocations totaling a /22 or less (to
> > > include zero)
> > > >
> > > > In no case shall an ISP receive more than a /16 initial allocation.
> > > >
> > > > 3. The maximum allowable allocation shall be the smallest
> > > nibble-boundary aligned block that can provide an equally sized
> > > nibble-boundary aligned block to each of the requesters serving sites
> large
> > > enough to satisfy the needs of the requesters largest single serving
> site
> > > using no more than 75% of the available addresses.
> > > > This calculation can be summarized as /N where N = P-(X+Y) and P is
> the
> > > organization’s Provider Allocation Unit X is a multiple of 4 greater
> than
> > > 4/3*serving sites and Y is a multiple of 4 greater than 4/3*end sites
> > > served by largest serving site.
> > > >
> > > > 4. For purposes of the calculation in (c), an end site which can
> justify
> > > more than a /48 under the end-user assignment criteria in 6.5.8 shall
> count
> > > as the appropriate number of /48s that would be assigned under that
> policy.
> > > >
> > > > 5. For purposes of the calculation in (c), an _ISP_ which has
> > > subordinate _ISPs_ shall make such reallocations according to the same
> > > policies and criteria as ARIN. In such a case, the prefixes necessary
> for
> > > such a reallocation should be treated as fully utilized in determining
> the
> > > block sizing for the parent _ISP_. _ISPs_ which do not receive
> resources
> > > directly from ARIN will not be able to make such reallocations to
> > > subordinate _ISPs_ and subordinate _ISPs_ which need more than a /32
> shall
> > > apply directly to ARIN.
> > > >
> > > > 6. An _ISP_ is not required to design or deploy their network
> according
> > > to this structure. It is strictly a mechanism to determine the largest
> IP
> > > address block to which the _ISP_ is entitled.
> > > >
> > > > 7 An _ISP_ that requests a smaller /36 or /40 allocation is entitled
> to
> > > expand the allocation to any nibble aligned size up to /32 at any time
> > > without renumbering or additional justification. /40 allocations shall
> be
> > > automatically upgraded to /36 if at any time said _ISP_’s IPv4 direct
> > > allocations exceed a /24. Expansions up to and including a /32 are not
> > > considered subsequent allocations, however any expansions beyond /32
> are
> > > considered subsequent allocations and must conform to section 6.5.3.
> > > Partial returns of any IPv6 allocation that results in less than a /36
> of
> > > holding are not permitted regardless of the ISP’s current or former
> IPv4
> > > address holdings.
> > > >
> > > >
> > > > Amend Section 6.5.3 to replace LIR with ISP in 4 locations:
> > > >
> > > > 6.5.3. Subsequent Allocations to _ISPs_
> > > >
> > > > 1. Where possible ARIN will make subsequent allocations by expanding
> the
> > > existing allocation.
> > > >
> > > > 2. An _ISP_ qualifies for a subsequent allocation if they meet any of
> > > the following criteria:
> > > >
> > > > - Shows utilization of 75% or more of their total address space
> > > >
> > > > - Shows utilization of more than 90% of any serving site
> > > >
> > > > - Has allocated more than 90% of their total address space to serving
> > > sites, with the block size allocated to each serving site being
> justified
> > > based on the criteria specified in section 6.5.2
> > > >
> > > > 3. If ARIN can not expand one or more existing allocations, ARIN
> shall
> > > make a new allocation based on the initial allocation criteria above.
> The
> > > _ISP_ is encouraged, but not required to renumber into the new
> allocation
> > > over time and return any allocations no longer in use.
> > > >
> > > > 4. If an _ISP_ has already reached a /12 or more, ARIN will allocate
> a
> > > single additional /12 rather than continue expanding nibble boundaries.
> > > >
> > > >
> > > > Amend Section 6.5.4.1 to replace LIR with ISP in 1 location:
> > > >
> > > > 6.5.4.1. Reassignment to Operator’s Infrastructure
> > > >
> > > > An _ISP_ may reassign up to a /48 per PoP as well as up to an
> additional
> > > /48 globally for its own infrastructure.
> > > >
> > > >
> > > > Amend Section 6.5.7 to replace LIR with ISP in 1 location:
> > > >
> > > > 6.5.7. Existing IPv6 Address Space Holders
> > > >
> > > > _ISPs_ which received an allocation under previous policies which is
> > > smaller than what they are entitled to under this policy may receive a
> new
> > > initial allocation under this policy. If possible, ARIN will expand
> their
> > > existing allocation.
> > > >
> > > >
> > > > Amend Section 6.5.8 to remove “or other LIR” in 2 locations
> > > >
> > > > 6.5.8.1. Initial Assignment Criteria
> > > >
> > > > FROM:
> > > >
> > > > f. By providing a reasonable technical justification indicating why
> IPv6
> > > addresses from an ISP or other LIR are unsuitable.
> > > >
> > > > TO:
> > > >
> > > > f. By providing a reasonable technical justification indicating why
> IPv6
> > > > addresses from an ISP are unsuitable.
> > > >
> > > >
> > > > FROM:
> > > >
> > > > Examples of justifications for why addresses from an ISP or other LIR
> > > may be unsuitable include, but are not limited to:
> > > >
> > > > TO:
> > > >
> > > > Examples of justifications for why addresses from an ISP may be
> > > unsuitable include, but are not limited to:
> > > >
> > > > Timetable for Implementation: Immediate
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > ARIN-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:
> > > > https://lists.arin.net/mailman/listinfo/arin-ppml
> > > > Please contact info at 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 at arin.net).
> > > Unsubscribe or manage your mailing list subscription at:
> > > https://lists.arin.net/mailman/listinfo/arin-ppml
> > > Please contact info at 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 at arin.net).
> > > Unsubscribe or manage your mailing list subscription at:
> > > https://lists.arin.net/mailman/listinfo/arin-ppml
> > > Please contact info at arin.net if you experience any issues.
> > >
> > >
> > >
> > >
> > > --
> > >
> > > ===============================================
> > > David Farmer               Email:farmer at umn.edu
> > > Networking & Telecommunication Services
> > > Office of Information Technology
> > > University of Minnesota
> > > 2218 University Ave SE
> > > <
> https://www.google.com/maps/search/2218+University+Ave+SE?entry=gmail&source=g
> >
> > >       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 at arin.net).
> > > Unsubscribe or manage your mailing list subscription at:
> > > https://lists.arin.net/mailman/listinfo/arin-ppml
> > > Please contact info at arin.net if you experience any issues.
> > >
> > >
> > >
> > >
> > > --
> > >
> > > ===============================================
> > > David Farmer               Email:farmer at umn.edu
> > > Networking & Telecommunication Services
> > > Office of Information Technology
> > > University of Minnesota
> > > 2218 University Ave SE
> > > <
> https://www.google.com/maps/search/2218+University+Ave+SE?entry=gmail&source=g
> >
> > >       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 at arin.net).
> > > Unsubscribe or manage your mailing list subscription at:
> > > https://lists.arin.net/mailman/listinfo/arin-ppml
> > > Please contact info at 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 at arin.net).
> > > Unsubscribe or manage your mailing list subscription at:
> > > https://lists.arin.net/mailman/listinfo/arin-ppml
> > > Please contact info at 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 at arin.net).
> > > Unsubscribe or manage your mailing list subscription at:
> > > https://lists.arin.net/mailman/listinfo/arin-ppml
> > > Please contact info at 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 at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > https://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20250919/453af672/attachment-0001.htm>