Thus spake John Sweeting ([email protected]) on Thu, Jun 20, 2024 at 
07:11:54PM +0000:
> Hello list,
> 
> ARIN would like to call attention to slides 11 – 13 of the Policy 
> Implementation and Experience Report presented at ARIN 53 in Barbados 
> regarding LIR versus ISP.
> 
> https://www.arin.net/participate/meetings/ARIN53/materials/monday/arin53_policyimplementation.pdf
> 
> ARIN staff is fine with whichever terminology the community prefers to use, 
> but at present considers ISPs to be organizations that provide some form of 
> IP connectivity services and not just address management services. If ISP is 
> replaced with LIR, there will be a change in policy unless care is taken 
> (e.g. section 4 regarding issuance of number resources) to make clear the 
> requirement that organizations may only obtain additional resources from ARIN 
> based on their documented need to use in the provisioning of IP connectivity 
> services.

Thanks, John for that reminder from ARIN 53.  I personally believe that
while it would be some work, it could be a welcome clarification in the
NPRM where justifications specifically require a burden of physical
presence or existence.  

I think the current blurring of terminology between LIR and ISP leaves
parts of policy ambiguous (in particular to a lay person, as ARIN staff
are interpreting the intent correctly) as to where the physical
existence test does and does not apply.   So I think there is an
opportunity to clarify that aspect.

A recent discussion of micro-allocations for exchange points also comes to
my mind as similarly struggling with this physical (vs virtual) aspect.

Dale


> From: ARIN-PPML <[email protected]> on behalf of Tyler O'Meara via 
> ARIN-PPML <[email protected]>
> Date: Thursday, June 20, 2024 at 1:13 PM
> To: Dale W. Carder <[email protected]>, Owen DeLong <[email protected]>
> Cc: PPML <[email protected]>
> Subject: Re: [arin-ppml] Feedback Request: Policy ARIN-2024-6: 6.5.1a 
> Definition Update
> I agree that we should work toward replacing all instances of "ISP" with "LIR"
> in the entirety of the NRPM, and then retire 6.5.1a. However, my understanding
> was that for IPv4, ARIN staff considered only LIRs that have a physical 
> network
> of some kind to be ISPs, and that therefore the 2 terms are not yet treated
> identically.
> 
> If my understanding is correct, I would propose we replace ISP with LIR
> everywhere, and just add a requirement to 4.1.8 that the requesting LIR have a
> physical network presence.
> 
> Tyler
> 
> 
> On Thu, 2024-06-20 at 11:33 -0500, Dale W. Carder wrote:
> > Thus spake Owen DeLong via ARIN-PPML ([email protected]) on Thu, Jun 20, 
> > 2024
> > at 02:36:02AM -0700:
> > > This is unfinished cleanup… The correct solution (IMNSHO) is to eliminate
> > > the term ISP from the NRPM and replace all occurrences with LIR.
> > >
> > > There’s really no place in the NRPM where ISP (or equivalent) occurs that
> > > would not be better served for policy purposes by being replaced with LIR.
> >
> > I strongly agree with these points, and also point out that LIR also better
> > aligns with usage in IETF and IANA.
> >
> > Dale
> >
> > > > On Jun 19, 2024, at 20:51, Douglas Camin <[email protected]> wrote:
> > > >
> > > > Bill –
> > > >
> > > > I made a mistake in my earlier email – LIRs and ISPs *are* generally
> > > > interchangeable terms. I was confusing it with End Users. Apologies.
> > > > Notably, ARIN staff wrote a helpful blog post earlier last year pointing
> > > > out that LIR and ISP is used interchangeably under the NRPM.
> > > >
> > > > I’ll rephrase my earlier response:
> > > >
> > > > The policy proposal as I see it is looking to add clarity to the 
> > > > existing
> > > > text. Section 6.5 as a whole uses the terms ISP and LIR at different
> > > > points. 6.5.1a appears to be there to ensure a reader knows they have 
> > > > the
> > > > same meaning but used the broader term “document” rather than “section” 
> > > > to
> > > > indicate the applicability. As a subsection of Section 6.5, a statement
> > > > that it applies to the “Section” should reasonably indicate the rest of
> > > > the section it is included in, and no other sections of the document.
> > > >
> > > > If your feedback is – retire 6.5.1a, move definitions or clarifications 
> > > > to
> > > > other sections, that is fine as well. We’re here to collect your input,
> > > > and it is appreciated!
> > > >
> > > > Regards –
> > > >
> > > >
> > > > Doug
> > > >
> > > > --
> > > > Douglas J. Camin
> > > > Member, ARIN Advisory Council
> > > > [email protected] <mailto:[email protected]>
> > > >
> > > > From: William Herrin <[email protected] <mailto:[email protected]>>
> > > > Date: Wednesday, June 19, 2024 at 9:37 PM
> > > > To: Douglas Camin <[email protected] <mailto:[email protected]>>
> > > > Cc: PPML <[email protected] <mailto:[email protected]>>
> > > > Subject: Re: [arin-ppml] Feedback Request: Policy ARIN-2024-6: 6.5.1a
> > > > Definition Update
> > > >
> > > > On Wed, Jun 19, 2024 at 5:23 PM Douglas Camin
> > > > <[email protected] <mailto:[email protected]>> wrote:
> > > > > To think about it holistically – for all sections of NRPM aside from
> > > > > 6.5,
> > > > > LIRs and ISPs have distinct differences. Inside of Section 6.5, 
> > > > > anywhere
> > > > > it references an LIR, that policy also applies to an ISP. This policy
> > > > > changes the word “Document” to “Section” to ensure there is no 
> > > > > confusion
> > > > > about that.
> > > >
> > > > Hi Doug,
> > > >
> > > > Well I sure don't like that plan.
> > > >
> > > > IMO, the proposed change just makes it more confusing. "Section"
> > > > means... which section? Why should the reader understand it to mean
> > > > section 6.5? Why not section 6?
> > > >
> > > > But that's not the biggest issue. Folks should be able to skip from
> > > > section to section and understand the terms "LIR" and "ISP" to mean
> > > > the same thing there that they do everywhere else. You're telling me
> > > > that 6.5.1.a intends to morph the terms to a different meaning for
> > > > section 6.5. That's bad. Really bad. Don't do that.
> > > >
> > > > Now that you call my attention to it, I think I'd like to see section
> > > > 6.5.1 retired, any relevant terminology moved to section 2 where it
> > > > belongs, and any text whose use of words is inharmonious with the rest
> > > > of the document revised. And not necessarily in section 6.5 - we
> > > > probably should be considering LIRs and ISPs to be the same thing
> > > > elsewhere too.
> > > >
> > > > I'm curious: where in the NRPM is LIR and ISP not, for the purposes of
> > > > ARIN policy, the same thing?
> > > >
> > > > Regards,
> > > > Bill Herrin
> > > >
> > > >
> > > > p.s. 6.5.2.b is also poorly written. If I didn't already know what the
> > > > nibble boundary is, it'd leave me scratching my head. Need simpler
> > > > words along with enough context for a reader to gain a basic
> > > > understanding of why it matters.
> > > >
> > > > "A nibble is half a byte: 4 bits. A nibble boundary in a netmask is
> > > > where the number of bits in the mask is evenly divisible by 4.
> > > >
> > > > Nibble-based address delegation boundaries serve IPv6 in two ways:
> > > > First, each written digit of an IPv6 address is exactly 4 bits.
> > > > Second, the ip6.arpa reverse-DNS domain is engineered for
> > > > nibble-boundary delegation."
> > > >
> > > >
> > > > --
> > > > William Herrin
> > > > [email protected] <mailto:[email protected]>
> > > > 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
> > > > ([email protected] <mailto:[email protected]>).
> > > > Unsubscribe or manage your mailing list subscription at:
> > > > https://lists.arin.net/mailman/listinfo/arin-ppml
> > > > Please contact [email protected] <mailto:[email protected]> if you experience 
> > > > any
> > > > issues.
> > >
> >
> > > _______________________________________________
> > > ARIN-PPML
> > > You are receiving this message because you are subscribed to
> > > the ARIN Public Policy Mailing List ([email protected]).
> > > Unsubscribe or manage your mailing list subscription at:
> > > https://lists.arin.net/mailman/listinfo/arin-ppml
> > > Please contact [email protected] if you experience any issues.
> >
> > _______________________________________________
> > ARIN-PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List ([email protected]).
> > Unsubscribe or manage your mailing list subscription at:
> > https://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact [email protected] if you experience any issues.
> 
> _______________________________________________
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List ([email protected]).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact [email protected] if you experience any issues.

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

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

Reply via email to