[arin-ppml] ARIN actions regarding address blocks with no valid POCs (was: Re: Deceased Companies?)

[Mattapally Technologies]

got it.

On Thursday, August 4, 2022, Paul E McNary via ARIN-PPML <arin-ppml at arin.net>
wrote:

> If I understood what John clarified for me earlier in this thread ...
> Many of the Legacy blocks will not be under NPRM and ARIN has to tread
> very carefully on trying to claw these addresses back.
> Many blocks that might be abandoned fall into legacy, especially /24's,
> assigned pre-ARIN.
> As always, many times I understand incorrectly.
>
> ----- Original Message -----
> From: "Ted Mittelstaedt" <tedm at ipinc.net>
> To: "John Curran" <jcurran at arin.net>
> Cc: "arin-ppml" <arin-ppml at arin.net>
> Sent: Thursday, August 4, 2022 9:30:36 PM
> Subject: Re: [arin-ppml] ARIN actions regarding address blocks with no
> valid POCs (was: Re: Deceased Companies?)
>
> > Ted -
> >
> > To my knowledge, the Number Resource Policy Manual (NRPM, i.e.
> > https://www.arin.net/participate/policy/nrpm/
> > <https://www.arin.net/participate/policy/nrpm/> ) does not presently
> > provide for ARIN performing reclamation of address blocks assigned to an
> > organization that has no valid POCs – it provides that such
> > organizations "will be unable to access further functionalities within
> > ARIN Online” and cannot be receiving organization for a reallocation or
> > detailed reassignment. (NRPM 3.6.5 and NRPM 3.7 respectively)
> >
>
> Technically an org like LT is obtaining a detailed reassignment from
> whatever ISP they are using (most likely, it's a /29)   Of course, they
> probably don't even realize or remember that they have a prior
> allocation which according to the NRPM needs valid POCs and also needs
> to meet utilization requirements before they were supposed to get their /29
>
> But, like I said, they aren't bad people, just likely ignorant of what
> they have.  I suspect ARIN could take care of this by directly
> contacting them based on 3.6.5 and 3.7.  I also suspect that is the case
> for a lot of the abandoned stuff.  I do agree it would take a LOT of
> manpower and lacking clear direction from the community to do it is
> probably a big sticking point for ARIN which is why you are hinting a
> policy change is needed.
>
> > If you’d like ARIN to take particular action on address blocks with no
> > valid POCs, please propose policy specifying the actions for community
> > consideration and potential adoption.
> As you know, the main reason the POC validation was put into NRPM was to
> allow ARIN to require POC validity, so that it would discourage spammers
> and other criminals from trying to hide themselves behind fake names if
> they registered blocks, and it would make it possible to alert block
> holders who had bad citizens acting from IPs in their blocks.
>
> It was the "license plate" argument, that is, just like a car they are
> using a public resource, so the public has a right to know who they are,
> which is why we slap license plates on cars.  Even though that really
> pisses off some people.
>
> But a secondary reason was to try to get a handle (no pun intended) on
> the extent of the "abandoned resources" problem.  Along with validation
> came a requirement for ARIN to report.   Well, it's certainly been long
> enough to get some valid data back - could you, John, say now, based on
> that data, what percentage of IPv4 number resources in ARIN are like
> this particular one - they have only invalid POCs and no valid ones?
>
> While those resources might not be available for use  (as their orgs
> might be using them internally and just not kept up with the reporting
> requirements) if you could give us a percentage, if it's high enough
> it might stimulate the community to support additional requirements for
> having ARIN get a bit more activist on getting these resources back.
>
> I sort of liken this to the "abandoned car" issue in a major city.  If
> the numbers of abandoned vehicles in a city are below .0001% then the
> population does nothing, but if it increases to .01% or .1% the
> population goes ballistic and starts demanding the city start towing,
> because the public wants it's street parking space back.
>
> So the question is, what are we leaving on the table?  I think that was
> the thrust behind the very first query on this thread.
>
> Frankly I DO think we should seriously consider revoking registrations
> of number blocks that lack valid POCs.  In this day and age, asking a
> number block holder to supply a valid POC is the absolute LEAST that the
> community can ask.  It's not enough to have just a valid street address.
>   It is after all, year 2022.  Having an email address is NOT a barrier
> to anyone.  If they are a small org they can just duplicate most of the
> info in the main number block into a POC and add a phone number and
> email address.  It's not a hardship.  If they are large then a street
> address of some main corporate HQ is useless if anyone needs to contact
> an individual about something going on from their IP addresses.
>
> Ted
>
> >   You can find more information on
> > submission of policy proposals here -
> > https://www.arin.net/participate/policy/pdp/appendix_b/
> > <https://www.arin.net/participate/policy/pdp/appendix_b/>
> >
> > Thanks!
> > /John
> >
> > John Curran
> > President and CEO
> > American Registry for Internet Numbers
> >
> _______________________________________________
> 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/20220804/bc403a40/attachment.htm>