Hi Elvis
On 04/11/2016 17:20, Elvis Daniel Velea wrote:
Hi,
I'm just throwing this idea to the mailing list without giving it
extensive thought. But I believe it should work.
Instead of having the abuse-c in the org, why don't we have it in the
maintainer object?
The MNTNER object is a box holding anonymous security tokens. Whilst I
agree authorisation should be personalised, it is not a good idea to mix
this with corporate contact details in this way.
have an abuse-mnt: new attribute in a resource object and abuse-c as
role object in the mnt.
This would be like the "mnt-irt:" attribute that implies security but is
really contact. It confuses people enormously.
wouldn't that fix all the problems of granularity *and* keep it somehow
organized into one type of object only?
Also links to MNTNER objects are multiple. This would lead to abuse
contact data being splattered all over the database with links to
multiple, conflicting and confusing abuse contacts. It would take us
back to the swamp we had before we introduced "abuse-c:".
cheers
denis
regards,
elvis
PS: david, so nice to see you active in this WG lately
On 11/4/16 2:38 PM, Sebastian Wiesinger wrote:
Hi David,
thank you for the in-depth answer!
* [email protected] <[email protected]> [2016-11-03 12:12]:
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.
I personally would also find this annoying and quite a bit
unintuitive. ;) I *DO* like the granularity but I don't think it
outweighs having all of that pushed to a single object instead of
having multiple abuse-c's that are probably managed by different
maintainers (giving customers the opportunity to manage their own
abuse-c object). Also I would image this would necessitate quite a bit
of special parsing in the database software.
B) Allow abuse handler to be added directly on the
Inet(6)num/Aut-num entries in the DB.
This is what I would prefer right now. It is low cost to implement, it
is easy to parse (use abuse-c: if available, else go to the
organisation abuse-c).
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.
I would prefer to have option B) right now. *If* we need more
granularity it would probably need to be a full fledged (meaning: more
complicated) solution. I imagine a new object-type that can be a CIDR
less-or-equal your allocation/assignment that references a abuse
contact (which would bring in all sort of questions regarding
authorization etc.) or an inet(6)num: with special type ABUSE-CONTACT
(or something else).
I think that this is a special case that probably not many people have
use for. Right now having abuse-c at inet(6)nums would ease the pain
for quite a few people.
Best Regards
Sebastian
