Re: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database)
Hello all, thanks for the already ongoing discussion about the new abuse contact policy proposal. I will try to clarify some things. We had some really technical discussions about this with database people from RIPE NCC and came up with this idea. So let's have a look at it. If we use a person object as an example, this person object can be referenced for example by an admin-c or tech-c attribute at the moment. In future it can be referenced by the abuse-c as well, BUT to create this reference the person objects needs to have an abuse-mailbox attribute. If there is no abuse-mailbox attribute it can not be referenced by the abuse-c. This will be done by the business logic. Same when you query for an ip range - admin-c, tech-c and abuse-c can be the same person, but output will show an abuse-mailbox attribute in the abuse-c part. So at the end it is only a matter, if the attributes requested by the business rules are existing for the intended use of the object. I will answer the other questions on the mailing list directly. Just wanted to give a real quick overview about the technical idea of the Task Force and RIPE NCC. Thanks, Tobias -- abusix
Hello, On 11/24/11 12:41, Tobias Knecht wrote:
Hello all,
thanks for the already ongoing discussion about the new abuse contact policy proposal. I will try to clarify some things.
We had some really technical discussions about this with database people from RIPE NCC and came up with this idea.
So let's have a look at it.
If we use a person object as an example, this person object can be referenced for example by an admin-c or tech-c attribute at the moment.
In future it can be referenced by the abuse-c as well, BUT to create this reference the person objects needs to have an abuse-mailbox attribute. If there is no abuse-mailbox attribute it can not be referenced by the abuse-c. This will be done by the business logic.
Why is an abuse-mailbox attribute needed at all? The whole object is an abuse-c. Everything in it is to be used as abuse contact. This also includes, but is not limited to, telephone numbers, postal address, fax etc. There is already an email attribute. If I remember correctly, this attribute is not mandatory - which is fine by me for now. Cheers,
Hi,
Why is an abuse-mailbox attribute needed at all? The whole object is an abuse-c. Everything in it is to be used as abuse contact. This also includes, but is not limited to, telephone numbers, postal address, fax etc. There is already an email attribute. If I remember correctly, this attribute is not mandatory - which is fine by me for now.
The idea is to use the abuse-mailbox attribute for automated complaints and the email attribute for human conversations. The main difference would take part in the query process, while the email attribute will be handled as personal data the abuse-mailbox attribute could be queried unrestricted. This makes it very easy for abuse reporters to automate these mechanisms. The mailbox for human conversations could be secured with a spamfilter. That gives spammer a smaller chance to deliver their junk and it makes it pretty hard for "VIPs" to send their spam complaints to the wrong address to gain more attention. Thanks, Tobias -- abusix
Tobias Knecht <tk@abusix.com> writes: Hello Tobias, nice to see a progress in this area, coming in the form of a proposal. Other people in this thread have more or less covered my questions. However, it is my general feeling that while the essence of the idea was explained in the thread it is not reflected well in the proposal wording. To me only by reading the proposal it is not clear that - the proposed approach is to replace all other alternatives and become THE reference point for abuse contacts - what exactly the transition period will be and what might be required by the relevant users and the RIPE NCC (this might also be added as an argument opposing the proposal) - what exactly happens in case someone does not comply after the transition period I also think that it is a good idea the rational of the Task Force to come up with this solution be presented in the policy text. Thanks for all your work and of course I think that the proposal moves toward the right direction. I only feel that the proposal wording needs some extra work. Just my 2 cents :) Regards, Kostas
Hello all,
thanks for the already ongoing discussion about the new abuse contact policy proposal. I will try to clarify some things.
We had some really technical discussions about this with database people from RIPE NCC and came up with this idea.
So let's have a look at it.
If we use a person object as an example, this person object can be referenced for example by an admin-c or tech-c attribute at the moment.
In future it can be referenced by the abuse-c as well, BUT to create this reference the person objects needs to have an abuse-mailbox attribute. If there is no abuse-mailbox attribute it can not be referenced by the abuse-c. This will be done by the business logic.
Same when you query for an ip range - admin-c, tech-c and abuse-c can be the same person, but output will show an abuse-mailbox attribute in the abuse-c part.
So at the end it is only a matter, if the attributes requested by the business rules are existing for the intended use of the object.
I will answer the other questions on the mailing list directly. Just wanted to give a real quick overview about the technical idea of the Task Force and RIPE NCC.
Thanks,
Tobias
-- Kostas Zorbadelos twitter:@kzorbadelos http://gr.linkedin.com/in/kzorba ---------------------------------------------------------------------------- () www.asciiribbon.org - against HTML e-mail & proprietary attachments /\
Hi Kostas,
- the proposed approach is to replace all other alternatives and become THE reference point for abuse contacts
That is true, I will add this to the proposal in the next version.
- what exactly the transition period will be and what might be required by the relevant users and the RIPE NCC (this might also be added as an argument opposing the proposal)
This is an operational issue and can not be a 100% defined at this point. The idea is, to transfer as much information as possible to the system automatically. So from this point we could for example use a admin-c or tech-c object that has already an abuse-mailbox as abuse-c as well. That is one possibility. There probably will be a notification of all members. There will be a cleanup process. But at the moment it is much to early to define these things. And in addition to that, the process of implementing and transition should not be part of the policy, because once the policy is in place and all transitions have been made, nobody will care about it anymore.
- what exactly happens in case someone does not comply after the transition period
Same what happens if somebody does not comply with any other policy. RIPE NCC will take care with the already defined processes that are in place right at the moment.
I also think that it is a good idea the rational of the Task Force to come up with this solution be presented in the policy text. Thanks for all your work and of course I think that the proposal moves toward the right direction. I only feel that the proposal wording needs some extra work.
In pieces I think you are right, but we should not put together things that are not belonging together. The policy is about adding an abuse-c in a specific way. The implementation will be added by RIPE NCC and what happens when is also coming from already existing RIPE NCC processes. But I will add the mentioned part to the proposal. Thanks for your feedback, Tobias -- abusix
Hi Tobias,
This is an operational issue and can not be a 100% defined at this point. The idea is, to transfer as much information as possible to the system automatically. So from this point we could for example use a admin-c or tech-c object that has already an abuse-mailbox as abuse-c as well. That is one possibility. There probably will be a notification of all members. There will be a cleanup process. But at the moment it is much to early to define these things. And in addition to that, the process of implementing and transition should not be part of the policy, because once the policy is in place and all transitions have been made, nobody will care about it anymore.
Yes, I agree its an operational issue, but there must be some deliberation from the RIPE NCC team regarding the implementation.
Same what happens if somebody does not comply with any other policy. RIPE NCC will take care with the already defined processes that are in place right at the moment.
And it doesn't involve the correctness of information provided and incorrect info will be dealt with in the same manner? right? again its an operational thing. Regards, Aftab A. Siddiqui
+1 .. i fully agree that this aspect needs to be thought out first --srs (iPad) On 25-Nov-2011, at 16:23, Aftab Siddiqui <aftab.siddiqui@gmail.com> wrote:
Hi Tobias,
This is an operational issue and can not be a 100% defined at this point. The idea is, to transfer as much information as possible to the system automatically. So from this point we could for example use a admin-c or tech-c object that has already an abuse-mailbox as abuse-c as well. That is one possibility. There probably will be a notification of all members. There will be a cleanup process. But at the moment it is much to early to define these things. And in addition to that, the process of implementing and transition should not be part of the policy, because once the policy is in place and all transitions have been made, nobody will care about it anymore.
Yes, I agree its an operational issue, but there must be some deliberation from the RIPE NCC team regarding the implementation.
Same what happens if somebody does not comply with any other policy. RIPE NCC will take care with the already defined processes that are in place right at the moment.
And it doesn't involve the correctness of information provided and incorrect info will be dealt with in the same manner? right? again its an operational thing.
Regards,
Aftab A. Siddiqui
Tobias,
If we use a person object as an example, this person object can be referenced for example by an admin-c or tech-c attribute at the moment.
In future it can be referenced by the abuse-c as well, BUT to create this reference the person objects needs to have an abuse-mailbox attribute. If there is no abuse-mailbox attribute it can not be referenced by the abuse-c. This will be done by the business logic.
I am confused because i remember the discussion slightly differently and this is also not in line with what the policy proposal text says. We should not overlay existing objects with magic that does or does not make them eligible as a target for a reference. Also, abuse handling is more or a role function, so if at all, we'd talk about a "role:" derivative here. Some gatekeeping is indeed advised.
Same when you query for an ip range - admin-c, tech-c and abuse-c can be the same person, but output will show an abuse-mailbox attribute in the abuse-c part.
This could be misread as giving different views onto the same object depending on the reference that made it appear in the output. -Peter (usual disclaimer applies)
participants (6)
-
Aftab Siddiqui -
Jørgen Hovland -
Kostas Zorbadelos -
Peter Koch -
Suresh Ramasubramanian -
Tobias Knecht