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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbill.herrin.us%2F&data=05%7C02%7C%7C352a22489a6d42c7f99808dc90c998b5%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638544442722994139%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=R%2FHUv7OIQ1iBweMlBe4NjLulKgTEzDkAX0a7tvu%2FelI%3D&reserved=0
> >  <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.

Reply via email to