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] [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 ]
Tobias Knecht
tk at abusix.com
Tue Jul 2 19:47:07 CEST 2013
Hi, > 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. That was in some ways wanted that way. The biggest challenge was to find a way that makes 100% sure that there will be no way to what so ever it will be to start creating a new mess in the RIPE DB. So we had to keep very strict. We figured out that people and even we ourselves tend to underestimate the risk of deigning something that end up messy. If we allow direct multiple references and multiply org references we would end up in a mess again. So since I was the proposer of the policy, the implementation impact showed me that this indirect allocation over ORG is a much better way. That's why I agreed on this way and it was reached consensus. One of the main goals imho of the RIPE DB has to be not ending up in a mess. Because this leads to a unusable DB. > 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. Having an abuse-c referenced in an asn-num is a "relict" from one of the first proposals I wrote. And I'm fully responsible for forgetting about this issue. I'm at the moment wondering if there is really a need to have an abuse-c referenced by an aut-num. After the transition phase we should end up with an abuse-c for every single ip-address. So is it necessary? I know it can be helpful if an LIR does not want to react or handle complaints we would have a chance that the aut-num is doing something. But if he is not doing something we need to have another route to go, which is already in discussion. So do we really need an abuse-c referenced in aut-nums? And sorry again, this was my fault not being patience enough with my own policy text. > Fully agree - it's probably the most efficient way to do it, but I see > no reason for it to be the only one. There is. As described above if we allow direct multiple references and multiply org references we would end up in a mess again. > 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. You can in regards of all inet(6)nums. You just have to use ORGs. > (and to be honest, returning real data in the 'comment' section of the > result gives me the shivers) brrrrrr :-) No please don't do that. :-) I was already talking to some people and tried to find a way to solve your requests. We are working on it. Thanks, Tobias -- AA-WG Chair
- 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 ]