[anti-abuse-wg] [db-wg] abuse-c + org
- Previous message (by thread): [anti-abuse-wg] [db-wg] abuse-c + org
- Next message (by thread): [anti-abuse-wg] [db-wg] abuse-c + org
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Gilles Massen
gilles.massen at restena.lu
Tue Jul 2 11:28:31 CEST 2013
Dear Denis, I think I did not make my concerns clear enough. While I'm not thrilled by the current aspect of abuse-c (esp. content limitations w.r.t. IRT) it is the current policy and I accept to live with that. What I was trying to point out is that the current implementation does not implement the policy correctly as it does not *allow* to attach an abuse-c to an inet[6]num or aut-num. The indirection via the ORGANISATION is fine and efficient, but constraining. My use case is to set a specific abuse-c for one autnum and inetnum, which is not the same as the general abuse-c of the organisation. Maybe I could create a 'fake' ORG in order to link to that (probably it would not work in my case), but that means data duplication. Allowing to attach the abuse-c to whatever object would solve it more nicely. The DBs query logic should hardly be affected as it is simply a matter of returning the most specific abuse-c for the object. > In the RIPE Labs article > https://labs.ripe.net/Members/kranjbar/implementation-details-of-policy-2011-06 > > we pointed out that there are about 3.7 million Internet resource > objects in the RIPE Database. To add an "abuse-c:" attribute > physically to each of these objects is unmanageable. Every users > network is physically linked to their existing ORGANISATION object. > Each user only needs to add one "abuse-c:" attribute in their > ORGANISATION object and all their networks are covered. Fully agree - it's probably the most efficient way to do it, but I see no reason for it to be the only one. > When any address is queried in the RIPE Database, the software will > find the related "abuse-c:" reference and return this information as > part of the query. By returning this information as a default with > each query we have satisfied the policy requirement that the > "abuse-c:" is "included in inetnum, inet6num and aut-num objects". Well, the policy is met in so far that all queries do return an abuse-c. However if I, the resource holder, can not chose accurately which one should be displayed the aim of the policy (having a good abuse-c) is missed. (and to be honest, returning real data in the 'comment' section of the result gives me the shivers) > This implementation was presented to and discussed by the community > on the Anti Abuse Working Group mailing list last year and Brian > declared that a consensus had been reached in his email on December > 5, on behalf of the co-chairs of the DB and AA Working Groups: > http://www.ripe.net/ripe/mail/archives/anti-abuse-wg/2012-December/001993.html I've > read that at the time (maybe not carefully enough) but is was never clear to me that the reference via the ORG object was the only way - I understood it as a complement to the obvious possibility of adding the contact to any object. > The old RIPE Database reference manuals on the ripe.net web site > still refer to the use of "abuse-mailbox:" attributes in other object > types, but don't refer to "abuse-c:" at all. These attributes were > never allowed to be added directly to the resource objects even in > the legacy software. These old reference manuals are now out of date > in many respects and should perhaps be clearly marked as archived > documents. By all means, please do so. There is nothing more confusion that slightly wrong documentation. Obviously an up to date documentation would be most welcome :) - at least a rough description of the objects with their fields (and the optional/mandatory nature of them). Best regards, Gilles -- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473
- Previous message (by thread): [anti-abuse-wg] [db-wg] abuse-c + org
- Next message (by thread): [anti-abuse-wg] [db-wg] abuse-c + org
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]