RIPE NCC's proposed implementation of Abuse Contact Management in the RIPE Database
Dear Colleagues, The RIPE NCC's proposed implementation plan of RIPE policy 563 (policy proposal 2011-06) titled "Abuse Contact Management in the RIPE Database" is as follows: =========== Introduction =========== Abuse Contact Management in the RIPE Database (as defined in RIPE policy document 563) mandates the RIPE NCC to gather and publish abuse contact information for Internet resources provisioned by the RIPE NCC. =========== Approach =========== Abuse handling is generally a role within an organisation and the RIPE NCC is planning to model this relation in the RIPE Database. So the "abuse-c:" attribute will be available in the ORGANISATION object and should reference a ROLE object. When a ROLE object is referenced from an ORGANISATION object by the "abuse-c:" attribute, it must have an "abuse-mailbox:" attribute. All resources allocated or assigned by the RIPE NCC are required to have a reference to an ORGANISATION object in the RIPE Database. By adding a single "abuse-c:" attribute to their ORGANISATION object, a resource holder can quickly cover all their resources. All resources that are allocated or assigned by the RIPE NCC and which are subject to and compliant with current resource policies will then either directly reference an abuse contact or will inherit one from the parent resource. The detailed changes to RIPE Database objects and business rules, fine tuning, search options and facilities for quick data entry by RIPE NCC members using the LIR Portal are all described in an article on RIPE Labs: https://labs.ripe.net/Members/kranjbar/implementation-details-of-policy-2011... ============ Timeline ============ * Phase 0 - Q1 2013 The RIPE NCC will make internal changes to the RIPE Database and LIR Portal, this should be done by end of Q1 2013. * Phase 1 - Q2 and Q3 2013 The RIPE NCC will ask members to add "abuse-c:" to their member ORGANISATION object at least and will conduct a follow-up on that. RIPE NCC Members will be required to have abuse contact data for their resources when working with our Registration Services department. If a member has not added abuse-c:" to their ORGANISATION object by the end of this phase, the RIPE NCC will automatically add the member's published contact email address as the member's abuse contact. Members can edit this information any time through the LIR Portal. At the end of this phase, all PA allocations and their more specifics will have an abuse contact. * Phase 2 - Q4 2013 to Q3 2014 The RIPE NCC will ask AS Number and PI Resource holders to add abuse contact information to their ORGANISATION objects. If some resource holders have not added their abuse contact data by the end of this phase, the RIPE NCC will add the published abuse contact data for the responsible LIR to the ORGANISATION object listed in the resource. Any resource holder with access to the related object can always edit this information. At this point, ALL resources in the RIPE Database which are subject to and compliant with RIPE policies will have accessible abuse contact information. Please let us know if you like this proposal or have any feedback or ideas for improvement of this implementation proposal. Regards, Kaveh Ranjbar, RIPE NCC Database Group Manager
Kaveh, On Thursday, 2012-11-15 13:30:09 +0100, Kaveh Ranjbar <kranjbar@ripe.net> wrote:
Abuse handling is generally a role within an organisation and the RIPE NCC is planning to model this relation in the RIPE Database. So the "abuse-c:" attribute will be available in the ORGANISATION object and should reference a ROLE object. When a ROLE object is referenced from an ORGANISATION object by the "abuse-c:" attribute, it must have an "abuse-mailbox:" attribute.
All resources allocated or assigned by the RIPE NCC are required to have a reference to an ORGANISATION object in the RIPE Database. By adding a single "abuse-c:" attribute to their ORGANISATION object, a resource holder can quickly cover all their resources. All resources that are allocated or assigned by the RIPE NCC and which are subject to and compliant with current resource policies will then either directly reference an abuse contact or will inherit one from the parent resource.
The detailed changes to RIPE Database objects and business rules, fine tuning, search options and facilities for quick data entry by RIPE NCC members using the LIR Portal are all described in an article on RIPE Labs:
https://labs.ripe.net/Members/kranjbar/implementation-details-of-policy-2011...
I can't get to that article as the site is currently down, but basically I think you're describing something like this: +----------+ org: +--------------+ | resource +------->| ORGANISATION | +----------+ +--------+-----+ | | abuse-c: v -------- +------+ ( e-mail )<----------------+ ROLE | -------- abuse-mailbox: +------+ While it seems a bit complicated, the layers of indirection make sense, and if the Whois server follows the chains automatically then it should be workable. A maintainer only has to create a single mailbox and point to it once. A user gets the correct e-mail spit out somewhere logical in their Whois query. Cool. Looking forward to having this implemented so we can move on to the much scarier phase of abuse contact management. :) Cheers, -- Shane
Hello Shane,
... https://labs.ripe.net/Members/kranjbar/implementation-details-of-policy-2011...
I can't get to that article as the site is currently down, but basically I think you're describing something like this:
I am sorry to hear that, I have reported the issue to our Webmaster. It seems to be all fine at the moment.
+----------+ org: +--------------+ | resource +------->| ORGANISATION | +----------+ +--------+-----+ | | abuse-c: v -------- +------+ ( e-mail )<----------------+ ROLE | -------- abuse-mailbox: +------+
In the article, it is exactly like that :)
While it seems a bit complicated, the layers of indirection make sense, and if the Whois server follows the chains automatically then it should be workable.
Yes. That's exactly what we have proposed to implement (and again detailed in the article). The query server will automatically follow the path and shows the contacts when answering relevant queries.
Cool. Looking forward to having this implemented so we can move on to the much scarier phase of abuse contact management. :)
Thank you very much for your feedback. All the best, Kaveh. --- Kaveh Ranjbar, RIPE NCC Database Group Manager
* Kaveh Ranjbar:
Abuse handling is generally a role within an organisation and the RIPE NCC is planning to model this relation in the RIPE Database. So the "abuse-c:" attribute will be available in the ORGANISATION object and should reference a ROLE object. When a ROLE object is referenced from an ORGANISATION object by the "abuse-c:" attribute, it must have an "abuse-mailbox:" attribute.
Doesn't this invite mingling of allegedly privacy-relevant data and abuse contact information?
On Nov 15, 2012, at 9:05 PM, Florian Weimer <fw@deneb.enyo.de> wrote:
...
Doesn't this invite mingling of allegedly privacy-relevant data and abuse contact information?
Hello Florian, One of the reasons that it is only tied to the "role" object and not the "person" object is to avoid those issues. A role object is not designed to hold personal information, it is a representation of a unit in an organisation. The "abuse-mailbox:" attribute is also supposed to represent the generic email address of the contact point for the abuse handling entity within an organisation, not a real person. We will place clarifying notifications about this when users enter the data. None of the objects in the chain, "inetnum/inet6num/aut-num", "organisation" and "role" are provisioned as, or designed to be private data holders. Thank you for your comment, Kaveh. --- Kaveh Ranjbar, RIPE NCC Database Group Manager
* Kaveh Ranjbar:
One of the reasons that it is only tied to the "role" object and not the "person" object is to avoid those issues. A role object is not designed to hold personal information, it is a representation of a unit in an organisation. The "abuse-mailbox:" attribute is also supposed to represent the generic email address of the contact point for the abuse handling entity within an organisation, not a real person. We will place clarifying notifications about this when users enter the data.
None of the objects in the chain, "inetnum/inet6num/aut-num", "organisation" and "role" are provisioned as, or designed to be private data holders.
Are you sure? After all, you anonymize these objects in the database dumps, citing data protection concerns: aut-num: AS3255 as-name: UARNET-AS descr: State Enterprise Scientific and Telecommunication Centre "Ukrainian Academic and Research Network" of the Institute for Condensed Matter Physics of the National Academy of Sc ience of Ukraine (UARNet) descr: EARN-Ukraine [...] admin-c: DUMY-RIPE tech-c: DUMY-RIPE [...] changed: [...] source: RIPE remarks: **************************** remarks: * THIS OBJECT IS MODIFIED remarks: * Please note that all data that is generally regarded as personal remarks: * data has been removed from this object. remarks: * To view the original object, please query the RIPE Database at: remarks: * http://www.ripe.net/whois remarks: **************************** inet6num: 2001:0658:021A::/48 netname: DE-TRMD-HACKETHAL-1 descr: IPv6 Markus Hackethal descr: Langenfeld country: DE admin-c: DUMY-RIPE tech-c: DUMY-RIPE status: ASSIGNED mnt-by: TRMD-MNT changed: [...] source: RIPE remarks: **************************** remarks: * THIS OBJECT IS MODIFIED remarks: * Please note that all data that is generally regarded as personal remarks: * data has been removed from this object. remarks: * To view the original object, please query the RIPE Database at: remarks: * http://www.ripe.net/whois remarks: **************************** inetnum: 80.16.151.184 - 80.16.151.191 netname: NETECONOMY-MG41731 descr: TELECOM ITALIA LAB SPA country: IT admin-c: DUMY-RIPE tech-c: DUMY-RIPE status: ASSIGNED PA [...] changed: [...] source: RIPE remarks: **************************** remarks: * THIS OBJECT IS MODIFIED remarks: * Please note that all data that is generally regarded as personal remarks: * data has been removed from this object. remarks: * To view the original object, please query the RIPE Database at: remarks: * http://www.ripe.net/whois remarks: **************************** organisation: ORG-NCC1-RIPE org-name: Dummy organisation name for ORG-NCC1-RIPE org-type: RIR address: Dummy address for ORG-NCC1-RIPE e-mail: unread@ripe.net mnt-ref: RIPE-NCC-RIS-MNT mnt-ref: RIPE-NCC-HM-MNT mnt-by: RIPE-NCC-HM-MNT changed: unread@ripe.net 20000101 source: RIPE remarks: **************************** remarks: * THIS OBJECT IS MODIFIED remarks: * Please note that all data that is generally regarded as personal remarks: * data has been removed from this object. remarks: * To view the original object, please query the RIPE Database at: remarks: * http://www.ripe.net/whois remarks: **************************** person: Placeholder Person Object address: RIPE Network Coordination Centre address: P.O. Box 10096 address: 1001 EB Amsterdam address: The Netherlands phone: +31 20 535 4444 nic-hdl: DUMY-RIPE mnt-by: RIPE-DBM-MNT remarks: ********************************************************** remarks: * This is a placeholder object to protect personal data. remarks: * To view the original object, please query the RIPE remarks: * Database at: remarks: * http://www.ripe.net/whois remarks: ********************************************************** changed: ripe-dbm@ripe.net 20090724 source: RIPE The latter is from the ripe.db.role.gz file. (Curiously, the "changed:" lines are left intact in the dump.) I worry that most LIRs put quite a bit of effort into updating the contact information, and then RIPE NCC decides to hide it because it's considered personal data, like all the other contact information currently in the database.
Dear Florien Thank you for your comments. You have touched on several issues here. Lets take them individually. Currently all data in the RIPE Database is publicly available, except password hashes. So any individual object can be queried and the full data returned. The RIPE Database does contain personal data and this data is also publicly available by querying the database, but with limits. To avoid data mining of this personal data, which is not required for any of the purposes of the database, the RIPE NCC does not allow bulk access to the personal data. The data examples you refer to are from the daily dump of the database. These have been "dummified" to remove personal data and references to personal data. The dummy PERSON and ORGANISATION objects you listed are place holders in the data dumps to maintain a consistent data set. The real objects and references are available if you query the RIPE Database within the acceptable use limits. None of the data that the LIRs maintain is hidden. But that part that is considered personal has some limits. The discussions around the abuse handling in the Anti Abuse Working Group have made it clear that this will not be personal data. So these ROLE objects will be available without the limits that personal data is subject to. They will also be available in the bulk data dumps. This is why we propose to allow an "abuse-c:" attribute to reference only a ROLE object and not a PERSON object. As Kaveh said, the ROLE object was not designed to, and should not, hold personal data. The tools the RIPE NCC will provide to facilitate abuse contact data entry will make it very clear that it will be available without limits and should not contain any personal data. The RIPE Database query service will also provision easy access to the abuse contact data related to individual resources without the need for users to drill down through individual data objects or hit any access limits. This should also help to avoid misuse of the personal data held in the RIPE Database. Regards, Denis Walker Business Analyst RIPE NCC Database Group On 16/11/2012 07:06, Florian Weimer wrote:
* Kaveh Ranjbar:
One of the reasons that it is only tied to the "role" object and not the "person" object is to avoid those issues. A role object is not designed to hold personal information, it is a representation of a unit in an organisation. The "abuse-mailbox:" attribute is also supposed to represent the generic email address of the contact point for the abuse handling entity within an organisation, not a real person. We will place clarifying notifications about this when users enter the data.
None of the objects in the chain, "inetnum/inet6num/aut-num", "organisation" and "role" are provisioned as, or designed to be private data holders.
Are you sure? After all, you anonymize these objects in the database dumps, citing data protection concerns:
aut-num: AS3255 as-name: UARNET-AS descr: State Enterprise Scientific and Telecommunication Centre "Ukrainian Academic and Research Network" of the Institute for Condensed Matter Physics of the National Academy of Sc ience of Ukraine (UARNet) descr: EARN-Ukraine [...] admin-c: DUMY-RIPE tech-c: DUMY-RIPE [...] changed: [...] source: RIPE remarks: **************************** remarks: * THIS OBJECT IS MODIFIED remarks: * Please note that all data that is generally regarded as personal remarks: * data has been removed from this object. remarks: * To view the original object, please query the RIPE Database at: remarks: * http://www.ripe.net/whois remarks: ****************************
inet6num: 2001:0658:021A::/48 netname: DE-TRMD-HACKETHAL-1 descr: IPv6 Markus Hackethal descr: Langenfeld country: DE admin-c: DUMY-RIPE tech-c: DUMY-RIPE status: ASSIGNED mnt-by: TRMD-MNT changed: [...] source: RIPE remarks: **************************** remarks: * THIS OBJECT IS MODIFIED remarks: * Please note that all data that is generally regarded as personal remarks: * data has been removed from this object. remarks: * To view the original object, please query the RIPE Database at: remarks: * http://www.ripe.net/whois remarks: ****************************
inetnum: 80.16.151.184 - 80.16.151.191 netname: NETECONOMY-MG41731 descr: TELECOM ITALIA LAB SPA country: IT admin-c: DUMY-RIPE tech-c: DUMY-RIPE status: ASSIGNED PA [...] changed: [...] source: RIPE remarks: **************************** remarks: * THIS OBJECT IS MODIFIED remarks: * Please note that all data that is generally regarded as personal remarks: * data has been removed from this object. remarks: * To view the original object, please query the RIPE Database at: remarks: * http://www.ripe.net/whois remarks: ****************************
organisation: ORG-NCC1-RIPE org-name: Dummy organisation name for ORG-NCC1-RIPE org-type: RIR address: Dummy address for ORG-NCC1-RIPE e-mail: unread@ripe.net mnt-ref: RIPE-NCC-RIS-MNT mnt-ref: RIPE-NCC-HM-MNT mnt-by: RIPE-NCC-HM-MNT changed: unread@ripe.net 20000101 source: RIPE remarks: **************************** remarks: * THIS OBJECT IS MODIFIED remarks: * Please note that all data that is generally regarded as personal remarks: * data has been removed from this object. remarks: * To view the original object, please query the RIPE Database at: remarks: * http://www.ripe.net/whois remarks: ****************************
person: Placeholder Person Object address: RIPE Network Coordination Centre address: P.O. Box 10096 address: 1001 EB Amsterdam address: The Netherlands phone: +31 20 535 4444 nic-hdl: DUMY-RIPE mnt-by: RIPE-DBM-MNT remarks: ********************************************************** remarks: * This is a placeholder object to protect personal data. remarks: * To view the original object, please query the RIPE remarks: * Database at: remarks: * http://www.ripe.net/whois remarks: ********************************************************** changed: ripe-dbm@ripe.net 20090724 source: RIPE
The latter is from the ripe.db.role.gz file. (Curiously, the "changed:" lines are left intact in the dump.)
I worry that most LIRs put quite a bit of effort into updating the contact information, and then RIPE NCC decides to hide it because it's considered personal data, like all the other contact information currently in the database.
* Denis Walker:
The discussions around the abuse handling in the Anti Abuse Working Group have made it clear that this will not be personal data. So these ROLE objects will be available without the limits that personal data is subject to. They will also be available in the bulk data dumps. This is why we propose to allow an "abuse-c:" attribute to reference only a ROLE object and not a PERSON object. As Kaveh said, the ROLE object was not designed to, and should not, hold personal data.
Does this mean that you will publish a ROLE object in the bulk dump once it is referenced from an abuse-c: field? Right now, you're redacting ROLE objects—but as Kaveh said, ROLE objects should not contain personal data, so there shouldn't be a reason for redacting them. That's where my confusion comes from, I guess.
Hello Florian, You are right about "ROLE" objects in the bulk dump. They were designed to contain role information and they should hold non-personal data, but unfortunately over time this did not happen and that's why at the moment we have to hide personal data. Obviously we want to clean that up and as we have announced in RIPE 65 after we finish with reimplementing current software we will initiate and effort to clean up objects including "Role" objects with personal data, but that is a different story. However, as mentioned before, for roles referred from the "abuse-c:" we will put a notification during data entry. The notification will clearly state that this data will be published fully and will be accessible with no restrictions. With that in place, we don't have to "dummify" those objects anymore and "ROLE" objects with "abuse-mailbox:" attribute will be accessible with no restriction. Kind Regards, Kaveh. --- Kaveh Ranjbar, RIPE NCC Database Group Manager On Nov 16, 2012, at 8:18 PM, Florian Weimer <fw@deneb.enyo.de> wrote:
* Denis Walker:
... This is why we propose to allow an "abuse-c:" attribute to reference only a ROLE object and not a PERSON object. As Kaveh said, the ROLE object was not designed to, and should not, hold personal data.
Does this mean that you will publish a ROLE object in the bulk dump once it is referenced from an abuse-c: field?
Right now, you're redacting ROLE objects—but as Kaveh said, ROLE objects should not contain personal data, so there shouldn't be a reason for redacting them. That's where my confusion comes from, I guess.
On Nov 15, Kaveh Ranjbar <kranjbar@ripe.net> wrote:
The RIPE NCC's proposed implementation plan of RIPE policy 563 (policy proposal 2011-06) titled "Abuse Contact Management in the RIPE Database" is as follows:
Requiring that LIRs maintain a new and otherwise totally useless organization object for every customer who need a delegated abuse-c attribute is very inconvenient. At least unless that object can be simplified to contain only the abuse-c attribute and no other data. I believe that the original proposal (abuse-c attributes on hierarchical resources) would be much easier to deploy, even if it initially requires adding the abuse-c attribute to a (usually) small number of top-level inetnum objects. If LIRs with hundreds of directly-assigned resources are concerned about modifying them (are they?), then why not support both schemes? -- ciao, Marco
Hello Marco, Yes, in the data entry side a little bit more effort is required, but as we have mentioned at (https://labs.ripe.net/Members/kranjbar/implementation-details-of-policy-2011...), there are two main reasons for that: a) This models the reality, in almost every case we know of, abuse handling is a role within an organisation. On he other hand attaching an email address to a resource is creating an arbitrary link. b) Operationally it is a lot more feasible for our members and users to enter data and more importantly to maintain this data over time if it is centralised in an entity modelled after their real work setup. All that said, we have also considered facilitating data entry. As we have mentioned we will provide additional tooling for data entry, so users can add their data easily. In the case you have mentioned, we are planning to provide a web based data entry tool which asks users for some basic required information and automatically prepares and creates both "ROLE" and "ORG" objects and then updates the internet resource in question. We just need to ask the user for the name of the entity, address, abuse contact email address and a maintainer and with that we can create all required objects and update the resource in question. We will also provide this through our update API for users who prefer to automatically add abuse contact information for their own customers. All the best, Kaveh. --- Kaveh Ranjbar, RIPE NCC Database Group Manager On Nov 16, 2012, at 5:03 PM, Marco d'Itri <md@Linux.IT> wrote:
On Nov 15, Kaveh Ranjbar <kranjbar@ripe.net> wrote:
The RIPE NCC's proposed implementation plan of RIPE policy 563 (policy proposal 2011-06) titled "Abuse Contact Management in the RIPE Database" is as follows:
Requiring that LIRs maintain a new and otherwise totally useless organization object for every customer who need a delegated abuse-c attribute is very inconvenient. At least unless that object can be simplified to contain only the abuse-c attribute and no other data. ...
Hi Kaveh, et.al, I'm trying to figure out what I need to do to benefit from the abuse-c initiative with minimal impact to our documentation and processes. On 19.11.2012 10:38 AM, Kaveh Ranjbar wrote:
Yes, in the data entry side a little bit more effort is required, but as we have mentioned at (https://labs.ripe.net/Members/kranjbar/implementation-details-of-policy-2011...), there are two main reasons for that:
a) This models the reality, in almost every case we know of, abuse handling is a role within an organisation. On he other hand attaching an email address to a resource is creating an arbitrary link.
b) Operationally it is a lot more feasible for our members and users to enter data and more importantly to maintain this data over time if it is centralised in an entity modelled after their real work setup.
While rolling out IPv6 we (must) document the assignments. This can (as far as I known) either be done by a covering inet6num object with an "assignment-size" and an internal documentation or by having an inet6num object for every assignment. With the later we can have an "abuse-mailbox" in a role object linking to "tech-c" (and "admin-c") of the inet6num object. So this is what we are doing today (create a role-object with abuse-mailbox etc. per role/customer/participant and link to it from admin-c and tech-c in the inet[6]num objects). With this new schema we need to create an additional organisation object just to link from the inet[6]num object (through "org" and the organisation object) to the (already existing) role object. In the additional organisation object we copy the address and e-mail information from the role object, because these two fields are mandatory in both objects. So we need to keep track of this information in two objects. Please see an example scheme here with the mandatory fields: inet6num: 2001:db8:1337::/48 ~~~~~~~~~ netname: blubb-net1 descr: network of blubb country: DE admin-c: >--------------------+ tech-c: >--------------------+ status: ASSIGNED | mnt-by, changed, source: ... | (org): >------------------+ | | | | | organisation: ORG-BLUBB-RIPE <---+ | ~~~~~~~~~~~~~ | abuse-c: >------------------+ | org-name: blubb | | org-type: OTHER | | address: <copy from | | e-mail: role object> | | mnt-ref: ... | | mnt-by, changed, source: ... | | | | | | role: blubb | | ~~~~~ | | address: fantasialand | | nic-hdl: blubb-RIPE <------+-+ e-mail: role-email@example.com admin-c: >-----------------------> person: tech-c: >-----------------------> person(s): mnt-by, changed, source: ... abuse-mailbox: abuse@example.com Did I miss something? Can I do this easier? Or is it mandatory/best practice to create an organisation object for each customer/party anyway ? If not, I would be happy to link directly from an "abuse-c" in the inet[6]num object to the role account (in parallel to tech-c and admin-c). Many thanks for help, Tim
Dear Tim, Lets start at the beginning. You mentioned there are two ways of creating your INET6NUM objects in the RIPE Database. Either you aggregate them in groups of customers with the same size of address space assignments or you list them individually. If your customers are simply end users who will not be managing the address space, routing, abuse handling themselves then you might choose to aggregate them. In this case you will be handling the abuse complaints and you can use your own ORGANISATION object to reference the abuse handling ROLE object. So all you need to do is create one additional ROLE object and everything is set up. If each of your customers is a separate business (even if it is an individual) who will be doing much of the management themselves, including handling any abuse complaints for their assigned address space, then you need a bit more setup. As we said in the implementation plan we are trying to move the RIPE Database in the direction of modelling the real world setup. This may require a little more initial setup, but in the end will be easier for everyone to understand and follow. So if each of your customers is an organisation handling it's own abuse, creating an ORGANISATION object for them as a reference point with an abuse ROLE object, shows they manage resources or have some role within this management. We will provide tools to assist in the setting up of this data. This will simplify your workload and avoid the need for you to enter information twice. Regards Denis Walker Business Analyst RIPE NCC Database Group On 04/12/2012 15:42, Tim Kleefass wrote:
Hi Kaveh, et.al,
I'm trying to figure out what I need to do to benefit from the abuse-c initiative with minimal impact to our documentation and processes.
On 19.11.2012 10:38 AM, Kaveh Ranjbar wrote:
Yes, in the data entry side a little bit more effort is required, but as we have mentioned at (https://labs.ripe.net/Members/kranjbar/implementation-details-of-policy-2011...), there are two main reasons for that:
a) This models the reality, in almost every case we know of, abuse handling is a role within an organisation. On he other hand attaching an email address to a resource is creating an arbitrary link.
b) Operationally it is a lot more feasible for our members and users to enter data and more importantly to maintain this data over time if it is centralised in an entity modelled after their real work setup.
While rolling out IPv6 we (must) document the assignments. This can (as far as I known) either be done by a covering inet6num object with an "assignment-size" and an internal documentation or by having an inet6num object for every assignment.
With the later we can have an "abuse-mailbox" in a role object linking to "tech-c" (and "admin-c") of the inet6num object.
So this is what we are doing today (create a role-object with abuse-mailbox etc. per role/customer/participant and link to it from admin-c and tech-c in the inet[6]num objects).
With this new schema we need to create an additional organisation object just to link from the inet[6]num object (through "org" and the organisation object) to the (already existing) role object. In the additional organisation object we copy the address and e-mail information from the role object, because these two fields are mandatory in both objects. So we need to keep track of this information in two objects.
Please see an example scheme here with the mandatory fields:
inet6num: 2001:db8:1337::/48 ~~~~~~~~~ netname: blubb-net1 descr: network of blubb country: DE admin-c: >--------------------+ tech-c: >--------------------+ status: ASSIGNED | mnt-by, changed, source: ... | (org): >------------------+ | | | | | organisation: ORG-BLUBB-RIPE <---+ | ~~~~~~~~~~~~~ | abuse-c: >------------------+ | org-name: blubb | | org-type: OTHER | | address: <copy from | | e-mail: role object> | | mnt-ref: ... | | mnt-by, changed, source: ... | | | | | | role: blubb | | ~~~~~ | | address: fantasialand | | nic-hdl: blubb-RIPE <------+-+ e-mail: role-email@example.com admin-c: >-----------------------> person: tech-c: >-----------------------> person(s): mnt-by, changed, source: ... abuse-mailbox: abuse@example.com
Did I miss something? Can I do this easier? Or is it mandatory/best practice to create an organisation object for each customer/party anyway ?
If not, I would be happy to link directly from an "abuse-c" in the inet[6]num object to the role account (in parallel to tech-c and admin-c).
Many thanks for help, Tim
Hi Denis, On 04.12.2012 5:11 PM, Denis Walker wrote:
If each of your customers is a separate business (even if it is an individual) who will be doing much of the management themselves, including handling any abuse complaints for their assigned address space, then you need a bit more setup.
As we said in the implementation plan we are trying to move the RIPE Database in the direction of modelling the real world setup. This may require a little more initial setup, but in the end will be easier for everyone to understand and follow. So if each of your customers is an organisation handling it's own abuse, creating an ORGANISATION object for them as a reference point with an abuse ROLE object, shows they manage resources or have some role within this management. We will provide tools to assist in the setting up of this data. This will simplify your workload and avoid the need for you to enter information twice.
Thank you for your explanation. My "mileage" would prefer a smaller setup without an organisation object, but if this (more) general solution fits more people lets go. Cheers, Tim
participants (6)
-
Denis Walker -
Florian Weimer -
Kaveh Ranjbar -
md＠Linux.IT -
Shane Kerr -
Tim Kleefass