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

Hi everybody,

> 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.

Sounds like a good suggestion. Imho the Best Practice for reporting
abuse issues is e-mail for several good reasons. That's why I decided to
stay with e-mail in this proposal. If there is any other Best Practice
out there that tells us to add an attribute for webforms please let me
know and I will add it to the proposal as an optional field in addition
to e-mail and abuse-mailbox attributes.

> 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.

Even if I fully agree with your statement about the crisp and brilliant
proposal ;-) I do not agree with your other statement. I think the
abuse-c should be mandatory for several good reasons I already brought
up on this list. I also agree that there are several reasons for not
making it mandatory, but the brilliance of this proposal is probably not
one of them.


> On item (1b) above, the proposal is unclear about the target audience for the
> "abuse-c" object on the receiving side.

It is all of the following.

>   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.

Absolutely agree with the additional explanation and guidance.
The Abuse Finder Tool is the Tool to use for this audience. Never the
less to come back to the "mess" the Abuse Finder can not find all
entries in the Database just because there is no way to parse free text
in an 100% correct way. And to be honest needing up to 150 queries to
get one email address is far away from not being a "mess".

Please recognize, that I have not put this specific issue in the
proposal, because it has nothing to do with the idea of the proposal
itself. Never the less it shows that this proposal would also be a huge
improvement when it comes to maintenance and development for RIPE NCC
and the functionality and reliability of the Database which should be
and hopefully is the most important issue.

>   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.

As already stated in another mail on this mailinglist the IRT Object is
another Object that has not direct connection to the abuse-c. Of course
there will be maintainers that feel, that the abuse-c is a copy of the
IRT and makes data redundant. Since we have seen numbers of IRT Object
published there is absolutely no doubt about, that the future of the IRT
Object has to be discussed. Whether if it will be removed, stays like it
is or will be pushed more with documentation and "IRT Object Marketing".
But this is and will not be part of this discussion.

>   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.

Disagree from my experience in the anti-abuse industry. First of all
reporting must be easy and receiving reports must be easy as well.
That's why opt-in is a bad idea, which can bee seen at feedbackloops.

Second, if you do not want to receive reports from one party, block them
or directly delete them. That is best practice and widely adopted and
really not complicated to do.

Not even talking about the huge amount of work and maintenance that is
needed to keep up a opt-in infrastructure and to find the right data
sources.

> 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?

The target audience is the reporter and the receiver.

The reporter will find the responsible address more easy and the
receiver can publish his information more easy.

By publishing the abuse-c the receiver subscribes to his already
existing duty to keep his network clean and avoid abusive behavior. I
hope all people here agree to this.

> 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.

It is about the possibility to access the abuse-c without query
restrictions. As a policy proposer I do not care about the
implementation, I care about functionality. And if this functionality is
not possible in the RIPE DB, RIPE NCC will mention this in the impact
analysis. If it is possible they will probably implement it as soon as
this proposal reached consensus.

> 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.

Same here. We are talking about the goal and not the way at the moment.
If we decide that we have the same goal we can talk with RIPE NCC about
the way to get there and find a way that suits (mostly) all parties.

> 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)? 

It will be mandatory for aut-nums, inetnums and inet6nums. I have seen
that there is something missing in the proposal text and I'm sorry for
that.

It will be mandatory for aut-nums, inetnums and inet6nums.

I will try to get it fixed in this version or at least in the next
version. Thanks for pointing this out.

> 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.

I was reading the hole proposal, which was written by me, again a few
seconds ago just to make sure I fully understood it. I have not seen
anything about revoking address space and a possibility that high
volumes lead to any kind of punishment. Not explicitly and not between
the lines. Honestly (as honest as the proposal itself) reading between
the lines and to fan fear are imho not good arguments against this
proposal. Sorry.

However the idea of revoking ip space based on high level complaint
rates may be dreamed by some people, but there would be still a policy
proposal necessary to go down this road and I think if this proposal
shows up we can disagree there.

I hope I was able to clear some stuff up and make it more clear what
this proposal is about and about which parts we should discuss now.

Thanks,

Tobias






-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 307 bytes
Desc: OpenPGP digital signature
URL: </ripe/mail/archives/anti-abuse-wg/attachments/20120426/05beb1f2/attachment.sig>