Dear WG, and RIPE NCC staff, While trying to add an abuse-c to our resources, I was quite surprised that you can only attach the abuse-c to an org object (while the policy suggests otherwise and implementation notes are not very clear on the limitation). So I'd like to ask why this restriction exists? What is wrong with adding an abuse-c directly to an inet[6]num or aut-num? Best regards, Gilles -- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473
[Apologies for duplicate emails.] Dear Gilles, These points were discussed on the Anti Abuse Working Group mailing lists quite extensively in June and December 2012. As you correctly pointed out policy ripe-563 says "This policy introduces a new contact attribute named "abuse-c:”, that can be included in inetnum, inet6num and aut-num objects." During the discussions last year it was asked if the RIPE NCC should 'interpret' policy. Our understanding is that this policy expresses the desire and goal of the RIPE community for a new feature in the RIPE Database. To achieve these goals this desire needs to be translated into, and incorporated in, an efficient, technical database design. In the RIPE Labs article https://labs.ripe.net/Members/kranjbar/implementation-details-of-policy-2011... 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. 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". It is not physically stored in each object in an unmanageable way, but logically associated with each object in an efficient and manageable way. 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.ht... In a follow up RIPE Labs article https://labs.ripe.net/Members/denis/creating-and-finding-abuse-contacts-in-t... the RIPE NCC explained how this implementation works in practise. You may recall that we discussed the details of how these references using the ORGANISATION object worked and how they can be fine tuned: http://www.ripe.net/ripe/mail/archives/anti-abuse-wg/2012-December/001998.ht... 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. I hope this answers your specific questions. Regards Denis Walker Business Analyst RIPE NCC Database Team On 27/06/2013 10:06, Gilles Massen wrote:
Dear WG, and RIPE NCC staff,
While trying to add an abuse-c to our resources, I was quite surprised that you can only attach the abuse-c to an org object (while the policy suggests otherwise and implementation notes are not very clear on the limitation).
So I'd like to ask why this restriction exists? What is wrong with adding an abuse-c directly to an inet[6]num or aut-num?
Best regards, Gilles
Hello, in (not only) ORGANISATION object we had abuse-mailbox field available already, even it was optional.
From database point of view creates current implementation inefficient overhead (both technical and administrative) - there's requirement of new ROLE object containing abuse-mailbox insteand simple filling of abuse-mailbox in ORGANISATION object. And only! role - even existing PERSON has abuse-mailbox optional, too...
Even if we have abuse-mailbox filled in ORGANISATION object (and also having IRT object with referencing mnt-irt containing similar information), new abuse-c ROLE is _required_ in ORGANISATION object. This require modification of _every_ ORGANISATION object, even if there was reference of abuse-mailbox in other way already. Mentioned mnt-irt was usable in INET(6)NUM object without any problems. So your argumentation about abuse-c in INET(6)NUM doesn't make sense. Why we cannot have here abuse-c role and/or abuse-mailbox fields? Why abuse-mailbox in current PERSON fields (used in admin-c/tech-c) isn't sufficient? IRT object is - in the fact - also abuse contact point. We used it to reference direct abuse contact to end-user of particular IP space (because direct abuse-mailbox I cannot use in INET(6)NUM). New abuse-c implements almost similar thing... In general, I think it's wrong, when several working groups should modify database scheme by their own policies. Not every person is watching all RIPE mailing lists. DB-WG should be arbiter here in all cases, and not only RIPE-NCC - i don't thing RIPE NCC / ANTI-ABUSE-WG considered all existing possibilities (specially IRT, abuse-mailbox in other objects...). Current implementation is still inconsistent - somewhere I can use abuse-c, somewhere abuse-mailbox directly, somewhere mnt-irt... but there're objects, where some of fileds mentioned above I cannot use. The goal is simple - publish abuse contact and I support this at all. But from database point of view - there're several ways - and all should be valid (not only abuse-c ROLE). Even adding abuse-mailbox and abuse-c to INET(6)NUM. This goal can be reached by multiple ways. Requirement of _new_ field, where existed other options already is wrong and unsystematic. About documentitation you mentioned (this is job of RIPE NCC) - it should be updated - not (only) archived. You used a lot of links for your argumentation - this should be in _single_ place, in documentation (not only in mailing list archives, not only in blogs etc). In general - informations are on too many points and you described that clearly (ANTI-ABUSE-WG, DB-WG, RIPE-LABS etc). One of RIPE-NCC role should be some kind of coordination between all working groups. I wrote this long email with one goal in the mind - things should be kept simple and stupid... With regards, Daniel On 07/01/2013 06:10 PM, Denis Walker wrote:
These points were discussed on the Anti Abuse Working Group mailing lists quite extensively in June and December 2012. As you correctly pointed out policy ripe-563 says "This policy introduces a new contact attribute named "abuse-c:”, that can be included in inetnum, inet6num and aut-num objects." During the discussions last year it was asked if the RIPE NCC should 'interpret' policy. Our understanding is that this policy expresses the desire and goal of the RIPE community for a new feature in the RIPE Database. To achieve these goals this desire needs to be translated into, and incorporated in, an efficient, technical database design.
In the RIPE Labs article https://labs.ripe.net/Members/kranjbar/implementation-details-of-policy-2011... 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.
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". It is not physically stored in each object in an unmanageable way, but logically associated with each object in an efficient and manageable way.
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.ht...
In a follow up RIPE Labs article https://labs.ripe.net/Members/denis/creating-and-finding-abuse-contacts-in-t... the RIPE NCC explained how this implementation works in practise. You may recall that we discussed the details of how these references using the ORGANISATION object worked and how they can be fine tuned: http://www.ripe.net/ripe/mail/archives/anti-abuse-wg/2012-December/001998.ht...
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.
I hope this answers your specific questions.
Regards Denis Walker Business Analyst RIPE NCC Database Team
On 27/06/2013 10:06, Gilles Massen wrote:
Dear WG, and RIPE NCC staff,
While trying to add an abuse-c to our resources, I was quite surprised that you can only attach the abuse-c to an org object (while the policy suggests otherwise and implementation notes are not very clear on the limitation).
So I'd like to ask why this restriction exists? What is wrong with adding an abuse-c directly to an inet[6]num or aut-num?
Best regards, Gilles
Hello Daniel, a lot of your concerns, questions and misunderstandings are clarified in official documents provided by RIPE NCC. I will go through your email and try to clarify some of these things, since I have been the proposer of this policy.
Even if we have abuse-mailbox filled in ORGANISATION object (and also having IRT object with referencing mnt-irt containing similar information), new abuse-c ROLE is _required_ in ORGANISATION object. This require modification of _every_ ORGANISATION object, even if there was reference of abuse-mailbox in other way already.
Mentioned mnt-irt was usable in INET(6)NUM object without any problems. So your argumentation about abuse-c in INET(6)NUM doesn't make sense. Why we cannot have here abuse-c role and/or abuse-mailbox fields? Why abuse-mailbox in current PERSON fields (used in admin-c/tech-c) isn't sufficient?
IRT object is - in the fact - also abuse contact point. We used it to reference direct abuse contact to end-user of particular IP space (because direct abuse-mailbox I cannot use in INET(6)NUM). New abuse-c implements almost similar thing...
The main idea of the proposal was to have "_ONE_" single place to publish abuse contact information and not several. That means: implementation of abuse-c takes several steps. One of them is a cleanup phase. This cleanup will try to clean up RIPE DB as much as possible. Within this step it will for example made sure that abuse-mailbox attribute will only be shown in abuse-c contacts and not in admin-c or tech-c objects in future. At the moment it is correct that it looks a bit messy. So please stay tuned a bit longer until clean up phases will start and show first results.
In general, I think it's wrong, when several working groups should modify database scheme by their own policies. Not every person is watching all RIPE mailing lists. DB-WG should be arbiter here in all cases, and not only RIPE-NCC - i don't thing RIPE NCC / ANTI-ABUSE-WG considered all existing possibilities (specially IRT, abuse-mailbox in other objects...).
This is exactly what we didn't do. It was agreed by all involved WG that discussions will take place on AA-WG mailinglist. Updates about the policy proposal have been communicated on this list and in the sessions of all involved WG at every RIPE Meeting. In addition to that we discussed this in a task force and with RIPE NCC technical staff and let them come up with an implementation plan that also fits their plan of future development. So all important parties have been involved and agreed at the end to the implementation plan, which was of course publicly available.
Current implementation is still inconsistent - somewhere I can use abuse-c, somewhere abuse-mailbox directly, somewhere mnt-irt... but there're objects, where some of fileds mentioned above I cannot use.
Right. This is a cause of a not already started clean-up phase, which can not happen before some other steps that are already in process.
The goal is simple - publish abuse contact and I support this at all.
Nearly right! The goal is to publish abuse contacts at "_ONE_" place that is always the same and does not let any space for discussions.
But from database point of view - there're several ways - and all should be valid (not only abuse-c ROLE). Even adding abuse-mailbox and abuse-c to INET(6)NUM. This goal can be reached by multiple ways. Requirement of _new_ field, where existed other options already is wrong and unsystematic.
This "all valid" ruleset lead to the "mess" we have in the database today. The mess you call inconsistency. ;-) We ended up having several different contact information about the same ip-address/range/space. Several as abuse-mailbox in addition with mnt-irt. This lead to confusion of people who didn't know where they should publish their data and confused the requester about where to look. abuse-c will fix all of these issues! Thanks, Tobias -- being 50% AA-WG Chair and 50% Policy Proposer in this email :-)
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...
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.ht...
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
Hi, On Tue, Jul 02, 2013 at 11:28:31AM +0200, Gilles Massen wrote:
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.
I seem to remember that I stated this as well, back then, and it was not seen as "important". So, yes, seconded. 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 (89) 32356-444 USt-IdNr.: DE813185279
On Tue, 2 Jul 2013, Gert Doering wrote:
Hi,
On Tue, Jul 02, 2013 at 11:28:31AM +0200, Gilles Massen wrote:
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.
I seem to remember that I stated this as well, back then, and it was not seen as "important".
So, yes, seconded.
There is alo a strange thing here: organisation: [mandatory] [single] [primary/lookup key] org-name: [mandatory] [single] [lookup key] org-type: [mandatory] [single] [ ] descr: [optional] [multiple] [ ] remarks: [optional] [multiple] [ ] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] geoloc: [optional] [single] [ ] language: [optional] [multiple] [ ] org: [optional] [multiple] [inverse key] admin-c: [optional] [multiple] [inverse key] tech-c: [optional] [multiple] [inverse key] abuse-c: [optional] [single] [inverse key] ref-nfy: [optional] [multiple] [inverse key] mnt-ref: [mandatory] [multiple] [inverse key] notify: [optional] [multiple] [inverse key] abuse-mailbox: [optional] [multiple] [inverse key] <- mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] Multiple abuse-mailboxes. role: [mandatory] [single] [lookup key] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] org: [optional] [multiple] [inverse key] admin-c: [optional] [multiple] [inverse key] tech-c: [optional] [multiple] [inverse key] nic-hdl: [mandatory] [single] [primary/lookup key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] abuse-mailbox: [optional] [single] [inverse key] <- mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] One single. The one in "role" is the one that counts. Why don't we allow multiple addresses there? And yes. What it leads to is you have to create several org objects in order to get more than one (or different) abuse-mailboxes. Best Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe@resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm
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
Hi Tobias,
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.
You are quite optimistic :) You cannot design anything foolproof - fools are much too inventive. :)
If we allow direct multiple references and multiply org references we would end up in a mess again.
I can see why you wouldn't want multiple references but I don't buy that a direct reference would create a mess. The concept of 'more specific' should be somewhat obvious to this community.
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.
I wouldn't want to challenge the policy process based on my inattention, but considering that the policy text explicitely mentions inetnum and aut-num, I never understood the proposed implementation as the only way, only as a facilitating workaround to inetnum-referenced abuse-c. But that's probably only me...
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.
I think the main goal of the RIPE DB is to serve the data that the data provider wants to be served.
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?
Frankly: unsure. But in a setup with anycasted IP addresses, maybe different addresses served by different ASs, I can imagine a situation were it would be useful.
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.
As I said: not multiple references, only more specific.
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.
In theory yes, but as the ORG is the same, only the abuse handler different that would mean creating an duplicate of the ORG for the sole purpose of referencing a different abuse-c. There is a lot potential for creating a mess in that workaround. (and one of the use cases I have in mind is a direct anycast assignment - not even sure that I'm allowed to do that) More generically I could also imagine having a different abuse handler for, say, dynamic DSL ranges than for web hosting: having an efficient abuse handling is obviously also in the interest of the submitter.
(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. :-)
Like: % Abuse contact for '193.0.0.0 - 193.0.7.255' is 'abuse@ripe.net' ? :)
I was already talking to some people and tried to find a way to solve your requests. We are working on it.
One thing that annoys me in this is that the implementation does not match the (my?) understanding of the policy text. Whatever the outcome of this discussion is, I would welcome if they were more aligned (and yes, I know that the boundaries between policy and implementation are not always clearly cut). Best, Gilles
On Tue, Jul 02, 2013 at 10:40:18PM +0200, Gilles Massen wrote:
I wouldn't want to challenge the policy process based on my inattention, but considering that the policy text explicitely mentions inetnum and aut-num, I never understood the proposed implementation as the only way, only as a facilitating workaround to inetnum-referenced abuse-c. But that's probably only me...
no -Peter
Hi Gilles,
You are quite optimistic :) You cannot design anything foolproof - fools are much too inventive. :)
That is true and that was never the intend. But we tried to have something that can be checked with rules to find the fools. :-)
I can see why you wouldn't want multiple references but I don't buy that a direct reference would create a mess. The concept of 'more specific' should be somewhat obvious to this community.
We would end up in some cases having 2 or more possibly different abuse-c objects for 1 resource.
I think the main goal of the RIPE DB is to serve the data that the data provider wants to be served.
I think I have to slightly disagree here. :-) If every data provider can put whatever he wants in the DB ... There are rules and these rules are usually policies. BUT the policies proposal process is a process that has the right to change policy texts while discussion is going on. And yes we or better I made the mistake to not adjust the policy text at the end completely to what the implementation process was. BUT never the less the policy as is worked for the majority of people otherwise it would not have been consensus called by Brian.
Frankly: unsure. But in a setup with anycasted IP addresses, maybe different addresses served by different ASs, I can imagine a situation were it would be useful.
Maybe this is something we have to discuss further more.
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.
As I said: not multiple references, only more specific.
You can be as specific as you want to be. you just have to go the way over the ORG. I'm not 100% but I think the ORG might be a bit misleading here. ORG doesn't mean a company. It can be different divisions of an Organisation.
In theory yes, but as the ORG is the same, only the abuse handler different that would mean creating an duplicate of the ORG for the sole purpose of referencing a different abuse-c. There is a lot potential for creating a mess in that workaround. (and one of the use cases I have in mind is a direct anycast assignment - not even sure that I'm allowed to do that)
More generically I could also imagine having a different abuse handler for, say, dynamic DSL ranges than for web hosting: having an efficient abuse handling is obviously also in the interest of the submitter.
To be honest I'm not sure either with the anycast assignments. As already mentioned: ORG is not a company. It can be a division of a company. So if you are talking about dynamic DSL ranges and hosting ranges, you can create an ORG for Hosting and DSL. In future, when you add new resources or change stuff in the abuse-c you will have to change it at one single point. and not in all ranges. So this leads to a much easier way of maintaining it. Yes the pain now will be bigger until everybody has build up the new structure and has it in place.
I was already talking to some people and tried to find a way to solve your requests. We are working on it.
One thing that annoys me in this is that the implementation does not match the (my?) understanding of the policy text. Whatever the outcome of this discussion is, I would welcome if they were more aligned (and yes, I know that the boundaries between policy and implementation are not always clearly cut).
As mentioned, my fault. I will check if we can change the policy text in a few points to match the real world plan we have agreed on as a policy. Otherwise, there will be some more policy proposals coming up soon so maybe we have the chance to get things straitened out a bit. Sorry again for that. Thanks, Tobias
Hi, On Wed, Jul 03, 2013 at 08:50:49AM -0700, Tobias Knecht wrote:
So if you are talking about dynamic DSL ranges and hosting ranges, you can create an ORG for Hosting and DSL. In future, when you add new resources or change stuff in the abuse-c you will have to change it at one single point. and not in all ranges. So this leads to a much easier way of maintaining it. Yes the pain now will be bigger until everybody has build up the new structure and has it in place.
If I want to change stuff "in the abuse-c", I change it "in the abuse-c", so that argument just doesn't hold. This indirection, always using an org, is nice from a computer science and database design point of view, but if you want people to *accept* and *use* what you give them, you should design something that people like to use. I find the idea quite useful, and adding a single object (abuse-c) for a single purpose is perfectly fine, but having to add extra objects just to fulfill synthetic constraints is annoying me, so I don't do it, and the quality of the abuse-c: is not as good as it could be (because I don't bother to add more detailed information). So, how exactly did anyone benefit from this "must have org!" constraint? (And for the argument "it wouldn't be clear, then, which one takes precedence" - that's easy: document it - and it's quite obvious to anyone but a computer scientist, I'd say - "if there is an abuse-c:, take that one, if not, take the org:, if neither, go less specific and repeat") 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 (89) 32356-444 USt-IdNr.: DE813185279
Hello,
If I want to change stuff "in the abuse-c", I change it "in the abuse-c", so that argument just doesn't hold.
There are members that have just a few more resources than others and possibly a much more complicated structure. The new way is generalized and by this easier to maintain and more flexible without destroying structure.
This indirection, always using an org, is nice from a computer science and database design point of view, but if you want people to *accept* and *use* what you give them, you should design something that people like to use.
There were a few phases in the policy proposal process where exactly this could have happened. It did not! There have been a few cases which have been discussed on the mailing list and after all we asked for feedback of all people that brought up concerns if they are happy with the way we tried to solve them. The majority has been happy with it. Overall I got extremely good feedback from members in Dublin. Even the numbers tell us that it's not that people do not like the new way. Of course there will always be some that do not like it, but that's why this is a community and a democratic process.
I find the idea quite useful, and adding a single object (abuse-c) for a single purpose is perfectly fine, but having to add extra objects just to fulfill synthetic constraints is annoying me, so I don't do it, and the quality of the abuse-c: is not as good as it could be (because I don't bother to add more detailed information).
The intend was to put real life scenarios into database. You usually always have resources given to organizations. If it's different teams within a company or if it's business customers having their own ranges doesn't matter. Even both is easily doable with the new structure. The new structure seems in the first step a bit more complicated, but makes things so much easier over time. That's what I heard a lot from people by talking to them in Dublin. Funny enough a lot of members were already asking me why we are not doing the same with admin-c and tech-c. Not updating will lead into an automatic update by RIPE NCC. Data accuracy is another part we are working on at the moment. There will be some ideas coming up on the mailing list before Athens in October. We already have some ideas in mind, but I'd rather listen to the community discussion happening at the moment and figure out that we not missed something.
So, how exactly did anyone benefit from this "must have org!" constraint?
For huge organizations it's getting easier to manage and update their huge amounts of resources. For very small organizations it is very easy, because they have one single place to organize their objects. Easy to have everything setup in the same way. Easy to split and not getting confused. Midsize companies can maybe profit from both. And if somebody not benefiting from any of these things - I'm sorry. And as already mentioned: Majority of people I talked to like it a lot.
(And for the argument "it wouldn't be clear, then, which one takes precedence" - that's easy: document it - and it's quite obvious to anyone but a computer scientist, I'd say - "if there is an abuse-c:, take that one, if not, take the org:, if neither, go less specific and repeat")
I guess that would have been possible. But we (Proposer, Task Force, RIPE NCC DB Team, several WG Chairs, ...) didn't decide this way. We always communicated that this is only a first step of what we have on our agenda (Further clean up, data accuracy, ...). So I guess there will some thing coming up that make things more clear and some others that create different confusion again. Never the less our aim is to be as open as possible, what we always tried and try to be. So if there are further questions, concerns or ideas please let us know and we will do our best to answer them or take them in considerations and discuss them any further. Thanks, Tobias -- AA-WG Chair
Hi Tobias,
I can see why you wouldn't want multiple references but I don't buy that a direct reference would create a mess. The concept of 'more specific' should be somewhat obvious to this community.
We would end up in some cases having 2 or more possibly different abuse-c objects for 1 resource.
Exactly as we have now: if a resource has, besides the LIR, an organisation object with abuse-c, you do have 2 covering abuse-c object (as the one for the 'customer' org is optional).
I think the main goal of the RIPE DB is to serve the data that the data provider wants to be served.
I think I have to slightly disagree here. :-) If every data provider can put whatever he wants in the DB ...
Correct... but as Gert pointed out: if you make it difficult for the data provider to be accurate (within the rules), he won't. And it's a loss to everyone. After all, providing accurate data via the RIPE DB is more a service to the community than a revenue generating action.
BUT never the less the policy as is worked for the majority of people otherwise it would not have been consensus called by Brian.
Well, the mail said 'no objections' - and that's correct. But if the absence of objections is based on a misunderstanding of the implementation (because the restrictions were not spelled out) the consensus is pretty worthless. As I can obviously only speak for myself, I'd love to hear from others if it was clear to them that an abuse-c could ONLY be linked to an organisation.
You can be as specific as you want to be. you just have to go the way over the ORG. I'm not 100% but I think the ORG might be a bit misleading here. ORG doesn't mean a company. It can be different divisions of an Organisation.
From the reference manual about organisation: "This entity may be a company, non profit group or individual.". Besides, if you would create a division as the referenced org of an inetnum, you would lose (or make it hard to find) the information 'what resources does this org have?' And I'd consider that as a loss.
So if you are talking about dynamic DSL ranges and hosting ranges, you can create an ORG for Hosting and DSL. In future, when you add new resources or change stuff in the abuse-c you will have to change it at one single point. and not in all ranges. So this leads to a much easier way of maintaining it. Yes the pain now will be bigger until everybody has build up the new structure and has it in place.
One point of the organisation construct was to lessen the pain, wasn't it? But at the end of the day all your arguments are in favor of having the organisation construct (and I agree). It certainly suits the majority. However none of them convinces me that allowing references from the resource objects is actually bad. I just don't see anyone using it unless he sees a need...and having accurate abuse-c is, after all, a goal of the AA WG and the abuse-c policy.
I will check if we can change the policy text in a few points to match the real world plan we have agreed on as a policy.
I strongly object to that conception: only the policy is policy. Even if the implementation is confirmed (or non-objected) by the WGs, it cannot modify, enhance or restrict the initial policy. Best, Gilles
On 3 Jul 2013, at 21:53, Gilles Massen wrote:
Well, the mail said 'no objections' - and that's correct. But if the absence of objections is based on a misunderstanding of the implementation (because the restrictions were not spelled out) the consensus is pretty worthless.
+1
As I can obviously only speak for myself, I'd love to hear from others if it was clear to them that an abuse-c could ONLY be linked to an organisation.
This wasn't clear to me either. ATB Niall
Hi there,
As I can obviously only speak for myself, I'd love to hear from others if it was clear to them that an abuse-c could ONLY be linked to an organisation.
This wasn't clear to me either. https://labs.ripe.net/Members/kranjbar/implementation-details-of-policy-2011... […]This means each resource object which is subject to, and in compliance with, RIPE Policy will inherit abuse contact information from its organisation object. Each RIPE NCC member should maintain correct contact information representing their organisation, including the new abuse details, in the organisation object.[…] […]The resource is not directly linked to an abuse contact role, but they are connected through the organisation object.[…] This is the implementation document and this was base for the decision as requested by community, since the policy text didn't go deep enough into implementation and community didn't want to do a decision based on the policy text without knowing exact implementation details. Thanks, Tobias
participants (8)
-
Daniel Stolpe -
Daniel Suchy -
Denis Walker -
Gert Doering -
Gilles Massen -
Niall O'Reilly -
Peter Koch -
Tobias Knecht