[arin-ppml] Feedback Request: Policy ARIN-2024-6: 6.5.1a Definition Update

Thu Jun 20 15:11:54 EDT 2024

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 S.

From: ARIN-PPML <arin-ppml-bounces at arin.net> on behalf of Tyler O'Meara via ARIN-PPML <arin-ppml at arin.net>
Date: Thursday, June 20, 2024 at 1:13 PM
To: Dale W. Carder <dwcarder at es.net>, Owen DeLong <owen at delong.com>
Cc: PPML <arin-ppml at arin.net>
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 (arin-ppml at arin.net) 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 <doug at dougcamin.com> 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
> > > doug at dougcamin.com <mailto:doug at dougcamin.com>
> > >
> > > From: William Herrin <bill at herrin.us <mailto:bill at herrin.us>>
> > > Date: Wednesday, June 19, 2024 at 9:37 PM
> > > To: Douglas Camin <doug at dougcamin.com <mailto:doug at dougcamin.com>>
> > > Cc: PPML <arin-ppml at arin.net <mailto:arin-ppml at arin.net>>
> > > 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
> > > <doug at dougcamin.com <mailto:doug at dougcamin.com>> 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
> > > bill at herrin.us <mailto:bill at 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 at arin.net <mailto: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 <mailto: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/20240620/c8978056/attachment-0001.htm>