[arin-tech-discuss] Delete problems with ORG and POC

[David Huberman]

Hello Aaron,

You wrote:

> Is the intent to simply leave stale resources in the DB once a resource
> is reclaimed? In this case, I created two test POCs and one ORG while
> validating the code prior to production roll-out. Do these simply go
> away with the next round of POC/ORG validating e-mails sent by ARIN?

I think a fair statement is ARIN's primary concern was respecting
the authority model for objects in Whois which already existed (prior
to us developing the RESTful API). In lieu of a complex hierarchy
that was aware of the meta reason an object existed -- OrgID X was
created by Aaron to reassign space to one of his customers, and now
that the customer has disconnected, Aaron should be able to remove
OrgID X -- we deployed a straight-forward model which says "either
you're authoritative for it because your ARIN Online account is
linked to it, or you're not".  A result of this may be ORG and POC
data which is not linked to any number resource. That data, however,
is expected to not be of operational concern to the broad community.

(And I think it's worth noting: If you want to ensure that you can
remove orphaned ORGs or POCs, one option would be to include yourself
[either as POC, or as e-mail on the POC] in the authority chain of
the ORG or POC. Whether that's acceptable to you, or your customer,
is left to your discretion.)

You also asked:
 
> Also, to bring up the expected use issue again, is this the way I
> should be handling detail reassigns and reallocates?


The expected methodology for detailed reassigns and reallocates is:

- CREATE RECIPIENT ORG
- NET reassign or reallocate
- eventually, DELETE that reassignment or reallocation

I hope that helps :)

Regards,
David

---
David R Huberman
ARIN Technical Specialist
(703) 227-9866