This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/anti-abuse-wg@ripe.net/
[anti-abuse-wg] 2016-01 New Policy Proposal (Include Legacy Internet Resource Holders in the Abuse-c Policy)
- Previous message (by thread): [anti-abuse-wg] 2016-01 New Policy Proposal (Include Legacy Internet Resource Holders in the Abuse-c Policy)
- Next message (by thread): [anti-abuse-wg] 2016-01 New Policy Proposal (Include Legacy Internet Resource Holders in the Abuse-c Policy)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Gilles Massen
gilles.massen at restena.lu
Fri Jan 29 17:21:22 CET 2016
Hi Denis, IIRC, when I looked into this your proposed workaround was not possible for a maintainer/legacy reason, but since we brought the LEGACY assignments properly under the RIPE roof, it should work know. BUT, I have a real issue with the workaround. The argument for restricting the abuse-c to an organisation was to prevent duplicate data, especially the hypothetical appearance of unmaintained contacts. However, this is exactly what you are proposing with a duplicate ORG. So instead of the hypothetical problems of keeping the fundamental logic of 'more specific', a tool only to be used by those who'd need it, the workaround makes them a certainty. 'Clumsy' does not quite describe it. In our specific case, I'd stay the slightly worse abuse-c, rather than duplicating ORG objects. Unfortunately enough, the loss (as small as it might be) is not mine... best regards, Gilles On 28/01/16 21:10, ripedenis at yahoo.co.uk wrote: > Hi Gilles > > Yes it is possible to do this. I know I keep saying this and I know no > one wants to even talk about it but the current data model does impose > some limitations. However, even with these limitations it is all about > how you perceive certain objects functions. An organisation that holds > resources must have an ORGANISATION object if they are not legacy > resources and may have one if they are legacy resources. There is > nothing stopping that organisation creating multiple ORGANISATION > objects and using them to represent departments within the same > organisation or representing some sub characteristic of the > organisation. Whatever it represents can be made clear in "descr:" and > "remarks:" attributes within the other ORGANISATION objects. These > ORGANISATION objects can be referenced from any more specific INETNUM > object and contain an "abuse-c:" attribute. > > I know this is a bit clumsy, but it IS easy to do and can be clearly > documented and can accommodate any arrangement of abuse handling you > wish to represent. > > cheers > denis > > > > ------------------------------------------------------------------------ > *From:* Gilles Massen <gilles.massen at restena.lu> > *To:* anti-abuse-wg at ripe.net > *Sent:* Thursday, 28 January 2016, 19:18 > *Subject:* Re: [anti-abuse-wg] 2016-01 New Policy Proposal (Include > Legacy Internet Resource Holders in the Abuse-c Policy) > > Hello, > > Since the rationale mentions the "better quality of abuse contact data", > I'd like to point out that it is still not possible to have a different > abuse-c for different inetnums, if they belong to the same ORG. The > impossibility to have a "more specific" is the ONLY thing that prevents > me to have accurate abuse contact data for our LEGACY addresses, not the > absence of a specific policy. > > regards, > Gilles > > > > > > > -- Fondation RESTENA - DNS-LU 2, avenue de l'Université LU-4365 Esch-sur-Alzette tel: +352.4244091 fax: +352.422473
- Previous message (by thread): [anti-abuse-wg] 2016-01 New Policy Proposal (Include Legacy Internet Resource Holders in the Abuse-c Policy)
- Next message (by thread): [anti-abuse-wg] 2016-01 New Policy Proposal (Include Legacy Internet Resource Holders in the Abuse-c Policy)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]