Hmm,
I'm not entirely happy with this proposal. In brief, I think it
overcomplicates matters.
It seems to me that this proposal may give rise to creation of
"pseudo-organizations" in the RIPE database. I think this will dilute
the value of the organization objects, since you can no longer in a
reasonable way expect that an organization object in the RIPE database
represents a real genuine real-world organization.
I agree it's a good idea to provide the default value of the abuse
handler via the organization object. What I don't understand is the
apparent reluctance to permit per-resource simple overrides of this
inheritance, something which could be done by allowing the marking of
resource objects with abuse-c pointing to a role object for the abuse
handler for the resource. Why insist on an indirection via an
organization object for this override?
So... I guess I don't understand this justification:
> If it is accepted that an email on it's own is not sufficient
> information [...]
Pointing to an abuse role object via abuse-c provides more than just
an e-mail address.
> [...] and the clear link to the organisation with responsibility for
> handling abuse is also required, then this double indirection is
> needed.
Can you please expand the justification for why this information is
required? Isn't it just as likely that the information provided in
such a "must be registered" organization will just be a "pseudo-
organization" where the the only thing which causes it to spring into
existence is the insistence of the (proposed) RIPE DB data model?
Ultimately the responsibility for the use of the resource rests with
the organization holding the resource, so that's always a possible
recourse should the overriding abuse-c prove to produce
non-satisfactory results.
Best regards,
- Håvard