[anti-abuse-wg] 2011-06 Discussion Period extended until 7 May 2012 (Abuse Contact Management in the RIPE NCC Database)

On Mon, Apr 16, 2012 at 11:12:54PM +0200, Denis Walker wrote:

> If you can't reliably find the data you have little chance of validating
> it. The whole point of this proposal is to fix the abuse contact details
> in one easy to find place in the database, by humans and scripting. Far
> from putting off the day when the mess has to be cleared up, this is the
> first step in cleaning up the already existing mess.

this is actually what I thought where and why we started all this (except
that i'd not qualify the situation as a "mess").  Now, the policy proposal
in its version 2.0 - and even more so the discussion around it - conflate
a number of issues.  That added to the ambiguities of the proposal really make
it hard to support it.

The 'arguments supporting the porposal' lists two, maybe three, major advantages:

1) a single attribute added to a number of object types that enables
   maintainers of that object (maybe acting on behalf of the resource holder)
   to publish an abuse contact

1b) on the receiving end, framed expectations where to look for said information

2) also on the receiving end, "unlimited" access to abuse contact information

I agree that an "abuse-c" attribute pointing to some other object is much more in
line with the overall design of the RIPE DB than an "abuse-mailbox" that
would not provide another level of indirection.  To that extent the proposal
is worthwile.  However, most everything else needs clarification (or a
less mandatory attitude).

	Therefore, I do not support 2011-06 in its current form.

Accepting the assumption it was hard for resource holders/maintainers to find the
right attribute/object type to publish abuse contact information, this can
be well achieved with abuse-c.  But the various examples provided in this and other
threads suggest that more differentiation is needed for the communication channels.
An abuse-c target object should inherit most of its attributes from the role:
object and should offer different ways of reporting: manual (email),
automated (email) and, maybe, web forms and the likes.  Note, the idea was to
help resource holders communicate their preferred way of contact establishment,
_not_ to dictate or discriminate against their abuse handling procedures.
And again, still assuming the idea is to help resource holders publish their
data, there is no need to make "abuse-c" mandatory -- simply because the idea
is so crisp and brilliant that they will adopt quickly.

On item (1b) above, the proposal is unclear about the target audience for the
"abuse-c" object on the receiving side.
  Is it the end user who - regularly or occasional - sends some report?
   These folk can use the abuse finder tool today and they should really not be
    exposed to the raw database output anyway.  Whatever change is applied,
    it will need a tool with additional explanation and guidance.

  Is it for inter-operator incident handling?
   In this case, the relation to the IRT object needs to be clarified.
   That aside, people would probably expect manual or semi-automated (as in: ticketing
    system) handling of the incident report.  Still, the current abuse-finder tool
    can already be of significant help.

  Is it for high volume automated report dissemination (trap or sensor initiated
   identification of "activity")?
   For this to work it needs automated handling on the receiving side and it should
   be clearly opt-in, so that the receiving entity can prepare for proper processing.

  To summarize: who is the target audience and what mode of operation are resource
  holders going to subscribe to by publishing an "abuse-c" reference?

Item (2) above, no rate limiting on the responses, is also tricky. This is much more
about the actual access mechanism than the object type and its attributes and the
policy text (cf 'arguments opposing this proposal') already states that a proposal
with the devil in the details and the details not laid out doesn't really make sense.
And quite frankly, postponing this to the result of the NCC impact analysis is putting
the cart before the horse.  Details,please - and that also covers the proposed
inheritance function.

Then, finally, why should the "abuse-c" object, or the references to it, respectively,
be mandatory (noting that version 2 claims it's mandatory for aut-nums only, again
without giving deeper insight)?  People won't use it otherwise?  Well, that condradicts
the initial assumption that the current plethora of mechanisms actually prevents
people from choosing the right publication path.  If they see a benefit, they will make
use of it.  Until then, there will be a phase of co-existence.  However, I have read
between the lines (or maybe even explicit) that some are dreaming of creating compliance
cases at high volume, probably to get address space eventually revoked.  I am unconvinced
that this reflects the community cooperation that we celebrated happening the last 2+
decades.  In any event, if that's the end goal, the proposal should be honest about this,
but I think it's the wrong way to go.

-Peter