Hi, On Thursday, November 3, 2016 11:31 AM, Sebastian Wiesinger <sebastian@karotte.org> 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