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

On 17.04.12 11:57, Chris wrote:
> On 04/17/2012 11:46 AM, Tobias Knecht wrote: [...]
> 
> folks, just read what i already wrote. as i said, essentially nothing
> has changed. there's no point in going thru all this again. it's all
> there already. if you lost it, there's the archive (hint: 20111207). 
> follow-ups welcome (i.e. questions that haven't already been
> answered).

As far as I can see you had 3 main issues with the proposal that time.

First was the implementation, which we left out completely this time to
concentrate on the main issue of "one" specific abuse contact. As stated
in the proposal the implementation will be discussed later after RIPE
NCC has done an implementation plan.

Second was, that you haven't seen a positive effect because you say that
things will stay in the database and we just add another object that
makes things more complex.

That is in fact only partly true. There is no automatic way of deleting
remark fields with abuse contact (freeform in a DB is nearly always a
mess). From that perspective we have to wait until maintainers are
changing their information. But the remark fields will get obsolete,
because there will be an abuse-c in place. So there is already a point
that get's less complex and this will be the way people can find abuse
contact information. And not only people, RIPE NCCs Abuse Findertool
will be able to parse them as well, what is not possible at the moment.

The other side, when we are talking about abuse-mailbox attributes. We
will not get rid of them, but this proposal will led into a situation
where the abuse-mailbox attribute is only shown on whois and other
outputs if it is related to an abuse-c. That makes the output again less
complex, because there is only "one" abuse-mailbox attribute in a whois
output and not 3 with different addresses.

In addition to that we have a clear differentiation between personal
data and role accounts, which can be communicated by the RIPE NCC when
the object will be published.

So I can not see any increase of complexity as I couldn't see it in
December 2011.


The third issue you had, was bulk spamming. I can see it and I can
understand this issue. Nevertheless I have to say, that there are
already techniques that can solve this problem and would also solve the
problem you have at the moment with bulk spamming. So this is not a new
problem at all, it is already a problem that needs to be fixed.

Besides the implementation, which will come from RIPE NCC and can be
discussed further in a later step I see less complexity and operational
overhead for resource holders as well.


I haven't seen most of your points in late 2011 and I do not see all of
them now. Maybe I'm just coming from another corner.

Since Community agreed on setting up a Task Force and work on this issue
and try to fix the mess in the Database which is as well recognized by
RIPE NCC staff with this word "mess" there must be something true about
it. Even if it is only something little.

So the question is not only what you do not like about the proposal,
it's more about how can we fix it. And you haven't come up with ideas
about a solution in December. So maybe you have ideas know and want to
share them.

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/20120417/12e2052b/attachment.sig>