Hi,
On Thursday, November 3, 2016 11:31 AM, Sebastian Wiesinger
<[email protected]> wrote:
>I just requested a NWI for this. Do you have other (better) ways in
>mind already?
Creating new org objects per network/services is annoying and cumbersome for PA
space but eventually works, not very beautiful and just replicates a lot of
identical data that will eventually become outdated or abandoned across the
Database.
It is however not quite possible to apply the same logic to AS and PI.
PI and AS number registered as INFRA to an LIR will have the same org object as
all other resources from that LIR that are issued by the RIPE NCC.
PI resource holders should have the same org Object across all their resources
or it becomes really difficult to track the various resources registered to
that one end-user.
And this might break the delegated stats a bit:
http://ftp.ripe.net/ripe/stats/delegated-ripencc-extended-latest
Not so much breaking it, but rendering the "opaque-id" useless, each
authoritative resource holder is registered with its own "opaque-id" if LIRs
and PI resources holders start to have multiple Org Objects on their resources
issued by the RIPE NCC, it will render that info useless (that is assuming
their is today a link between OrgID in RIPE DB and opaque ID in delegated
stats).
Based on the current system, possible ways forward could be:
A) Being able to indicate the AS and prefixes covered by a specific abuse email
directly in the role object used as abuse-c: .
Annoying to set up, not very intuitive at first, but less annoying than having
to create new org objects per network segments requiring different role objects
as abuse-c: each time.
Covers the need of LIRs with PA, AS number and PI resource holders in terms of
potential granularity.
or
B) Allow abuse handler to be added directly on the Inet(6)num/Aut-num entries
in the DB.
It would override whatever is on the central Org Object when querying the
resources, users would lose the central management provided by having the
abuse-c: directly linked to the org object and end up with having to replicate
the abuse email or abuse-c: role object entry on all the needed resources in
the RIPE Database.
Covers LIRs with PA and AS numbers in general.
It would still not solve PI abuse management granularity, as a /22 PI holder
may want to be able to define different abuse mailbox for different network
segments within that range.
or
C) Multiple org Objects for same resource holders and PI prefix splitting.
Replication of identical information causing less accuracy in the RIPE Database
in grouping resources from LIRs and independent resources holders, plus
eventual out of date info on the org Objects that were created solely for the
sake of the abuse-c: entry.
You would also eventually end up having to split PI assignments into smaller
prefixes to have different org objects for abuse handling, losing the
possibility to aggregate the prefixes as a single route in the process.
And whatever combination of A),B) and C) for full chaos and complexity.
I am not quite having any other ideas on how to proceed that would fit within
the current RIPE DB rules...route objects pop to mind, but would also have
their quirks.
The first one seems to me the "simplest" in term of resource management for the
users in general, has very little to no draw backs on resource registration and
if the NCC provides a nice simple wizard interface as well for it, then it
becomes very simple for users who use GUI based updates.
Cheers,
David Hilario
