[arin-ppml] ARIN actions regarding address blocks with no valid POCs (was: Re: Deceased Companies?)
Ted Mittelstaedt
tedm at ipinc.net
Sat Aug 6 18:24:29 EDT 2022
Once more, nobody cares about those because they are _in use_.
Interesting that there's a handful of legacy space in other RIRs. I
hadn't thought about transfers. However I don't believe transfers
can happen unless they sign an LSRA so they are "in the system" at that
point.
Ted
On 8/6/2022 2:19 PM, Mike Burns wrote:
> Just a point of clarification.
> ARIN is not the only RIR with legacy blocks.
> Check ARIN ERX Transfers.
> Every RIR has them, and has similar policies regarding them.
> There are some significant differences related to transfers of legacy space.
>
> Regards,
> Mike
>
>
>
>
> ------- Original Message -------
> *From :* Ted Mittelstaedt[mailto:tedm at ipinc.net]
> *Sent :* 8/6/2022 4:10:28 PM
> *To :* lee at dilkie.com; pmcnary at cameron.net
> *Cc :* arin-ppml at arin.net
> *Subject :* RE: Re: [arin-ppml] ARIN actions regarding address blocks
> with no valid POCs (was: Re: Deceased Companies?)
>
> Nobody not even me is suggesting that. What I am saying is that the
> ARIN community has that power.
>
> Ted
>
> On 8/6/2022 11:25 AM, Lee Dilkie wrote:
> > The legacy blocks were created and in existence before ARIN took
> > responsibility of them and while ARIN could simply take them all back,
> > with no regard for history, it smacks of "colonialism" to me. You know,
> > where the enlightened civilized folks take property from the savages
> > because they can put it to better use. Those savages aren't even paying
> > tax (arin fees) so really they should have no rights at all.
> >
> > See? That's how history repeats itself.
> >
> > -lee
> >
> > On 2022-08-06 11:45, Ted Mittelstaedt wrote:
> >> That is correct which is why John has repeatedly stated that action on
> >> these needs to originate with the community. Essentially the RIR
> >> system's legal support and basis for power is the same as the United
> >> Nations various subcommittees such as WIPO - general consensus among
> >> members.
> >>
> >> ARIN is the only RIR that has legacy blocks so this is a unique issue
> >> with just the ARIN RIR. Most of the rest of ARIN such as NRPM is used
> >> as a pattern by the other RIRs.
> >>
> >> It is likely that what the community does with regards to the legacy
> >> blocks will have an effect on the "deceased company" issue but the
> >> simple reality with registered blocks, which John has tried to get
> >> people to understand, is that as long as an entity is paying the
> >> renewal fees, while it might be apparent that the block is "on
> >> autopilot" and is not in use/being sat on/etc. and that is incredibly
> >> irritating, the existence of ongoing payments and ongoing claims that
> >> the block is "in use" by the payor and the existence of the original
> >> contract between the entity and the RIR, all of that establishes a
> >> legal right to continue to have the registration, by that entity.
> >>
> >> If ARIN acts without consensus among the community, then it
> >> jeopardizes the entire RIR system. We don't want the UN coming in and
> >> taking it all over and the UN doesn't want to do that as long as the
> >> RIR system appears to be functioning on consensus.
> >>
> >> The gray line is what constitutes legitimate operations of the RIR and
> >> where is the line between that and operations that cannot happen
> >> without consensus to modify the NRPM. I have argued in the past that
> >> ARIN has enough authority by the NRPM to houseclean - John's statement
> >> a few days ago contradicts that - which means as John said if we want
> >> ARIN to take a broom to the legacy blocks, we have to give them more
> >> authority to do so by modifying the NRPM.
> >>
> >> The actual truth is that if the community was united it could revoke
> >> all legacy blocks tomorrow despite whatever legalities people out
> >> there would argue. Ultimately it all comes down to what the major ISP
> >> networks would accept, just because a RIR says a block is assigned to
> >> someone else doesn't mean all the major ISPs are required to adhere to
> >> that. In practice the major ISPs do because they prefer this over the
> >> chaos that would result otherwise, but ultimately all a legacy block
> >> is, is a checkoff in a database in ARIN. Nobody HAS to actually
> >> follow it.
> >>
> >> We could vote in power to ARIN to revoke and they could do it. It
> >> would be a hellofa mess and absolutely the wrong thing to do - but the
> >> community absolutely does have the power to do it.
> >>
> >> Beyond that, absence of a proposal, it's all talk and no action. So I
> >> guess if I want to see anything done I have to get cracking on a
> >> proposal.
> >>
> >> Ted
> >>
> >> On 8/4/2022 7:42 PM, Paul E McNary 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/>
> >>>> < 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/>
> >>>> < 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
> <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
> <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
> <https://lists.arin.net/mailman/listinfo/arin-ppml>
> Please contact info at arin.net if you experience any issues.
>
More information about the ARIN-PPML
mailing list