changes to the implementation of "abuse-c:"
Colleagues The new co-chairs have prioritized existing and proposed NWIs. Our intent is to reach consensus on open items. We accept that we can't tackle them all at once and we may not address them in numerical order. We would like to start with one that has been discussed for many years, without coming to an acceptable solution, the implementation of the "abuse-c:" attribute. We thoroughly reviewed the working group discussion on the “abuse-c:” attribute, including reviewing Tim's initial draft of a problem statement. We removed the examples to make the problem statement brief and to the point. Anyone concerned with "abuse-c:" has most likely encountered one of these problems and doesn't need quoted examples. We also removed comments on the 'good parts' of the current implementation. That can come back when we discuss pros and cons of possible solutions. Then added in the issue Tobias made about the cleanup. So we end up with the problem statement shown below. Can we agree these are the problems that cause issues with some users? Are there any other problems that anyone has encountered? cheers Denis co-chair DB-WG Problem statement on "abuse-c:" implementation: =============================================== It is currently not possible to specify alternative abuse contacts for different resources in the RIPE Database held by different parts of the same organisation. It is currently not reasonably possible to specify alternative abuse contacts for resources in the RIPE Database assigned to organisations other than the parent organisation. In many circumstances these organisations are customers of the parent organisation. The lower organisation wishes to handle the abuse separate from the parent organisation. After the introduction of "abuse-c", the "abuse-mailbox:" attribute in the PERSON, MNTNER, ORGANISATION and IRT objects was intended to be deprecated. This cleanup was never done and the old data causes confusion to users manually searching the database.
* ripedenis@yahoo.co.uk <ripedenis@yahoo.co.uk> [2017-01-12 13:51]:
Problem statement on "abuse-c:" implementation: =============================================== [..]
The problem statement looks good to me, I only would like to comment that the current way seems *too* complicated / bloated for a lot of people. So a solution should aim to be more "lightweight" for lack of a better word. That might happen naturally when tackling the problem statement but nontheless I would like to mention it. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant
On Thu, Jan 12, 2017 at 12:43:06PM +0000, ripedenis@yahoo.co.uk wrote: Denis, Colleagues,
It is currently not possible to specify alternative abuse contacts for different resources in the RIPE Database held by different parts of the same organisation.
Agree.
It is currently not reasonably possible to specify alternative abuse contacts for resources in the RIPE Database assigned to organisations other than the parent organisation. In many circumstances these organisations are customers of the parent organisation. The lower organisation wishes to handle the abuse separate from the parent organisation.
Would you be so kind and elaborate more about "(...) not reasonably possible (...)". Do I understand correctly that putting proper ROLE object in abuse-c attribute of ORGANISATION object is beyond reasonable possibility?
After the introduction of "abuse-c", the "abuse-mailbox:" attribute in the PERSON, MNTNER, ORGANISATION and IRT objects was intended to be deprecated. This cleanup was never done and the old data causes confusion to users manually searching the database.
Agree. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Hi Piotr On 14/01/2017 09:33, Piotr Strzyzewski wrote:
On Thu, Jan 12, 2017 at 12:43:06PM +0000,ripedenis@yahoo.co.uk wrote:
Denis, Colleagues,
It is currently not possible to specify alternative abuse contacts for different resources in the RIPE Database held by different parts of the same organisation. Agree.
It is currently not reasonably possible to specify alternative abuse contacts for resources in the RIPE Database assigned to organisations other than the parent organisation. In many circumstances these organisations are customers of the parent organisation. The lower organisation wishes to handle the abuse separate from the parent organisation. Would you be so kind and elaborate more about "(...) not reasonably possible (...)". Do I understand correctly that putting proper ROLE object in abuse-c attribute of ORGANISATION object is beyond reasonable possibility?
For a resource holder with an ORGANISATION object set up by the RIPE NCC, the default "abuse-c:" in that ORGANISATION object, referencing a ROLE object, should already exist now for all resources. Some people have expressed concern over the amount of work required to add abuse contacts for customers. It can be done by creating a new ROLE object and a new ORGANISATION object, referencing the ROLE and containing either the customer's organisation details or a copy of the resource holder's organisation details. Then reference this new ORGANISATION object in the customer's assignment object. For a handful of customers that is not difficult, although some still believe it is over complicated. If you have tens or hundreds of customers wanting to handle abuse complaints themselves, then it moves into the 'unreasonable' zone if all this has to be handled manually. If it is considered unreasonable and it is optional, then people won't do it and we don't have the best information available in the RIPE Database. I don't want to start discussing solutions yet. Lets make sure we all agree what is a problem and that we have all the problems listed. We don't want to have to fix it twice. cheers denis co-chair DB-WG
After the introduction of "abuse-c", the "abuse-mailbox:" attribute in the PERSON, MNTNER, ORGANISATION and IRT objects was intended to be deprecated. This cleanup was never done and the old data causes confusion to users manually searching the database. Agree.
Piotr
On Sat, Jan 14, 2017 at 07:45:18PM +0100, denis wrote: Hi Denis
On 14/01/2017 09:33, Piotr Strzyzewski wrote:
It is currently not reasonably possible to specify alternative abuse contacts for resources in the RIPE Database assigned to organisations other than the parent organisation. In many circumstances these organisations are customers of the parent organisation. The lower organisation wishes to handle the abuse separate from the parent organisation. Would you be so kind and elaborate more about "(...) not reasonably
On Thu, Jan 12, 2017 at 12:43:06PM +0000,ripedenis@yahoo.co.uk wrote: possible (...)". Do I understand correctly that putting proper ROLE object in abuse-c attribute of ORGANISATION object is beyond reasonable possibility?
For a resource holder with an ORGANISATION object set up by the RIPE NCC, the default "abuse-c:" in that ORGANISATION object, referencing a ROLE object, should already exist now for all resources.
Some people have expressed concern over the amount of work required to add abuse contacts for customers. It can be done by creating a new ROLE object and a new ORGANISATION object, referencing the ROLE and containing either the customer's organisation details or a copy of the resource holder's organisation details. Then reference this new ORGANISATION object in the customer's assignment object.
For a handful of customers that is not difficult, although some still believe it is over complicated. If you have tens or hundreds of customers wanting to handle abuse complaints themselves, then it moves into the 'unreasonable' zone if all this has to be handled manually. If it is considered unreasonable and it is optional, then people won't do it and we don't have the best information available in the RIPE Database.
So, as I understand, the problem is either necessity to "create a lot of redundant objects" (as described by Gert Doering) or just a scale and automation (as described by you). None of this is beyond reasonable possibility to me. Although I can agree that both Gert and you are right with more detailed description of the problem and I'm ok with the problem description made in the original email. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
* Piotr Strzyzewski <Piotr.Strzyzewski@polsl.pl> [2017-01-17 12:51]:
So, as I understand, the problem is either necessity to "create a lot of redundant objects" (as described by Gert Doering) or just a scale and automation (as described by you). None of this is beyond reasonable possibility to me. Although I can agree that both Gert and you are right with more detailed description of the problem and I'm ok with the problem description made in the original email.
Hello Piotr, it seems it is not even possible to have different objects for independent resources at the moment. To quote the NCC: We understand the reasoning for wanting to use two different org objects. However, we cannot use different org object IDs for the same enduser in resources assigned by the RIPE NCC and have to be strict about it. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant
We understand the reasoning for wanting to use two different org objects. However, we cannot use different org object IDs for the same enduser in resources assigned by the RIPE NCC and have to be strict about it.
seems to me that this strong identity binding is a feature, not a bug. randy
Hi, On Wed, Jan 25, 2017 at 02:11:49PM -0800, Randy Bush wrote:
We understand the reasoning for wanting to use two different org objects. However, we cannot use different org object IDs for the same enduser in resources assigned by the RIPE NCC and have to be strict about it.
seems to me that this strong identity binding is a feature, not a bug.
So how do you register two different abuse contacts for different abuse departments in house responsible for different parts of a network block, if abuse-c is hard-tied to the org object, and you can have only one? Which nicely emphasizes the problem statement - it needs to be possible to define abuse contacts for more-specific inet(6)num: objects without introducing extra org objects... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
seems to me that this strong identity binding is a feature, not a bug.
So how do you register two different abuse contacts for different abuse departments in house responsible for different parts of a network block, if abuse-c is hard-tied to the org object, and you can have only one?
Which nicely emphasizes the problem statement - it needs to be possible to define abuse contacts for more-specific inet(6)num: objects without introducing extra org objects...
fine with that. just do not want org being orgorgorgorg. arin has made a fun mess that way. randy
Colleagues We have taken into account the comments made in recent weeks and propose the following as the final draft of a problem statement. If there are no more comments on this then the co-chairs accept this as NWI-7 and we will move onto phase 2 and start to look at possible solutions to the defined problems. cheersDenisco-chair DB-WG Problem statement on "abuse-c:" implementation: =============================================== It is currently not possible to specify alternative abuse contacts for different resources in the RIPE Database held by different parts of the same organisation. It is currently not reasonably possible to specify alternative abuse contacts for resources in the RIPE Database assigned to organisations other than the parent oganisation. In many circumstances these organisations are customers of the parent organization. The lower organization wishes to handle the abuse separate from the parent organization. The current mechanism is considered by some people to be over complicated when it has to be set up manually. Others believe it is simple to implement using the API and available libraries. Others question the need for double indirection for abuse-c. This point may come down to a question of raw data manipulation vs tooled information management. After the introduction of "abuse-c", the "abuse-mailbox:" attribute in the PERSON, MNTNER, ORGANISATION and IRT objects was intended to be deprecated. This cleanup was never done and the old data causes confusion to users manually searching the database. After the introduction of "abuse-c", the implementation of the 'person' keyword did not get updated.
ripedenis@yahoo.co.uk wrote:
After the introduction of "abuse-c", the "abuse-mailbox:" attribute in the PERSON, MNTNER, ORGANISATION and IRT objects was intended to be deprecated. This cleanup was never done and the old data causes confusion to users manually searching the database.
Add: After the introduction of "abuse-c", the "pn" shortcut did not get updated. Explanation: pn is a shortcut for "admin-c,tech-c,zone-c,author" in inverse queries. To find all references blocking the deletion of a person or role object I used to be able to query whois -r -i pn uk41-ripe Now I have to use whois -r -i abuse-c,pn uk41-ripe which is synonymous to whois -r -i abuse-c,admin-c,tech-c,zone-c,author uk41-ripe This should be easily fixable. Regards, -- Ulf Kieber
Hi Ulf I see this as more of an oversight than a problem. But I will add it to the problem statement so it doesn't get overlooked again. As you say it is probably quite easy to fix but we will let the RIPE NCC comment on that when we get to the stage of discussing solutions. btw...'pn' is the short form for 'person', so it is the implementation of the 'person' keyword that needs fixing. cheers denis On 15/01/2017 03:51, Ulf Kieber wrote:
ripedenis@yahoo.co.uk wrote:
After the introduction of "abuse-c", the "abuse-mailbox:" attribute in the PERSON, MNTNER, ORGANISATION and IRT objects was intended to be deprecated. This cleanup was never done and the old data causes confusion to users manually searching the database. Add: After the introduction of "abuse-c", the "pn" shortcut did not get updated.
Explanation:
pn is a shortcut for "admin-c,tech-c,zone-c,author" in inverse queries.
To find all references blocking the deletion of a person or role object I used to be able to query
whois -r -i pn uk41-ripe
Now I have to use
whois -r -i abuse-c,pn uk41-ripe
which is synonymous to
whois -r -i abuse-c,admin-c,tech-c,zone-c,author uk41-ripe
This should be easily fixable.
Regards,
participants (7)
-
denis -
Gert Doering -
Piotr Strzyzewski -
Randy Bush -
ripedenis＠yahoo.co.uk
-
Sebastian Wiesinger -
Ulf Kieber