Dear WGs, In the light of the upcoming RIPE meeting I'd like to bring the problem of a single entity (organisation) wanting different abuse-c for different resources up again. The discussion starting in June (http://www.ripe.net/ripe/mail/archives/db-wg/2013-June/004079.html ) was rather open ended. Apparently the only workable solution at this point is to create a duplicate organisation object with a different abuse-c. Is data duplication really the solution that the WGs would like? Gilles -- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473
On 7 Oct 2013, at 15:02, Gilles Massen wrote:
In the light of the upcoming RIPE meeting I'd like to bring the problem of a single entity (organisation) wanting different abuse-c for different resources up again. The discussion starting in June (http://www.ripe.net/ripe/mail/archives/db-wg/2013-June/004079.html ) was rather open ended.
Apparently the only workable solution at this point is to create a duplicate organisation object with a different abuse-c.
Is data duplication really the solution that the WGs would like?
I'm glad you've re-opened this question, Gilles, as I just last week had occasion to update an object which had long had multiple 'abuse-c' contacts, and had to choose which one to keep. I'm in the "No" camp wrt your question above. Back in the original "abuse-c" proposal [*], http://www.ripe.net/ripe/mail/archives/db-wg/2004-January/002489.html there was provision for multiple "abuse-c" attributes, but this was not carried over into the current specification. Would "hint strings" be a way to go, or have you something else in mind, or are you just re-opening the question? ATB /Niall [*] Disclosure: I was a co-author. /N
On 7/10/13 17:04 , Niall O'Reilly wrote:
On 7 Oct 2013, at 15:02, Gilles Massen wrote:
Apparently the only workable solution at this point is to create a duplicate organisation object with a different abuse-c.
Is data duplication really the solution that the WGs would like?
I'm glad you've re-opened this question, Gilles, as I just last week had occasion to update an object which had long had multiple 'abuse-c' contacts, and had to choose which one to keep.
I'm in the "No" camp wrt your question above.
Glad to hear that. I'm not sure I would make use of multiple abuse-c for a given object, unless one could provide some additional information with them.
Back in the original "abuse-c" proposal [*],
http://www.ripe.net/ripe/mail/archives/db-wg/2004-January/002489.html
there was provision for multiple "abuse-c" attributes, but this was not carried over into the current specification.
Would "hint strings" be a way to go, or have you something else in mind, or are you just re-opening the question?
The short version: No, yes, not really :) A bit more verbose: While I certainly would welcome a mechanism like 'hint strings' and have use for it, it would not apply my case where I simply need different abuse-c for different subnets, not due to the type of report but rather for the people that should read/react upon them. Not all inet*nums are equally important. As for re-opening the question: I feel that it was never closed, only abandoned over summer time. But the most important driver for coming back is that the only available solution (data duplication) is so tremendously wrong that I'd really like the WGs to be conscious about it. It the members feels that's ok and I'm only paranoid about data quality - fine. Silence, however, it not going to convince me. Something else in mind: as before: allow abuse-c for inet*num. Prefer and encourage the organisation way, but allow the other. Even if I did share Tobias' belief that attaching abuse-c to inet*num would weaken it's overall quality, I'd always prefer a hypothetical issue (intenum+abuse-c) over a certain one (multiple identical roles), unless the former is substantiated by something more than 'someone might get it wrong'. If anyone has a different idea, please share! Best, Gilles
Hi, On Mon, Oct 07, 2013 at 11:00:28PM +0200, Gilles Massen wrote:
Something else in mind: as before: allow abuse-c for inet*num. Prefer
This. (But I've said this before :-) - I do not see it as a useful excercise having to create an organization: object for the sole purpose of being able to have a different abuse-c: for some inet(6)num object) Gert Doering -- inetnum maintainer -- 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
* Gert Doering <gert@space.net> [2013-10-08 13:33]:
Hi,
On Mon, Oct 07, 2013 at 11:00:28PM +0200, Gilles Massen wrote:
Something else in mind: as before: allow abuse-c for inet*num. Prefer
This.
(But I've said this before :-) - I do not see it as a useful excercise having to create an organization: object for the sole purpose of being able to have a different abuse-c: for some inet(6)num object)
++++++1 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
Hi, On 10/10/13 5:50 PM, Sebastian Wiesinger wrote:
* Gert Doering <gert@space.net> [2013-10-08 13:33]:
Hi,
On Mon, Oct 07, 2013 at 11:00:28PM +0200, Gilles Massen wrote:
Something else in mind: as before: allow abuse-c for inet*num. Prefer
This.
(But I've said this before :-) - I do not see it as a useful excercise having to create an organization: object for the sole purpose of being able to have a different abuse-c: for some inet(6)num object)
++++++1
I think that having the abuse-c role linked to the org object was a great idea. I also understand that some organisation may want to have different abuse contacts/roles defined for different IP blocks. One way on how this could be fixed, in my opinion, is by allowing an abuse-c role to be referenced in the inet*num object (but only if the inet*num object references an org that already has an abuse-c role referenced). In this case, the general abuse-c would be the one referenced in the org and the 'local' abuse-c would be the role referenced in the inet*num object. cheers, elvis
On Oct 08, Gert Doering <gert@space.net> wrote:
(But I've said this before :-) - I do not see it as a useful excercise having to create an organization: object for the sole purpose of being able to have a different abuse-c: for some inet(6)num object) Agreed. I am not sure about who actually disagrees with this among operators.
-- ciao, Marco
participants (6)
-
Elvis Velea
-
Gert Doering
-
Gilles Massen
-
md@Linux.IT
-
Niall O'Reilly
-
Sebastian Wiesinger