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

On Fri 16/Nov/2012 07:06:42 +0100 Florian Weimer wrote:

* Kaveh Ranjbar:

...

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: [...] admin-c: DUMY-RIPE tech-c: DUMY-RIPE

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.

It may be necessary to contact a "person", sometimes. However, machines are not allowed to do that. I believe mechanisms better than the existing CAPTCHA are being considered, but that seems to be tied to a different implementation plan, as it is not entirely within RIPE. *Tools for searching* are mentioned in the Implementation Details page that Kaveh posted. Other pages are obsolete; for example, the Refinements to the RIPE Database Query API is of 23 Aug 2010, and has a broken link for the RIPE Database Web Services. The specification of RESTful web services for retrieving registration data involves all RIRs and most names registries, so it doesn't depend on RIPE only. Even so, I hope Kaveh will be able to keep us informed about those developments' timeline.

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.

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 15/11/2012 2:11 PM, Kaveh Ranjbar wrote:

On Nov 15, 2012, at 9:05 PM, Florian Weimer <fw@deneb.enyo.de <mailto: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.

As a user of the RIPE database for reporting SPAM, I really don't need any of the associated personal information behind the 'abuse address'. I don't care about names, addresses etc. That part can and likely should stay hidden away without making the plain e-mail address any less useful. All that is really necessary to make that e-mail address effective and useful, that it actually is valid and mail to it will be acted on, promptly. Arnold

Thank you for your comment, Kaveh.

--- Kaveh Ranjbar, RIPE NCC Database Group Manager

-- Fight Spam - report it with wxSR 0.5 - ready for Vista & Win7 http://www.columbinehoney.net/wxSR.shtml

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. ...

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

Dear Alessandro, The design does ease the fine tuning of abuse handling. By default the LIR's ORGANISATION object will reference the LIR's abuse handling ROLE. This is the root for all abuse handling for the resources allocated to an LIR. If at some point a customer chooses to do their own management of abuse handling for their assigned address space you simply create the ORGANISATION and abuse ROLE objects for this customer and add the "org:" reference to this customers assignment. The RIPE NCC will provide a tool for doing this in a single step. If the customer changes their mind again and no longer wishes to handle the abuse themselves, you simply remove the "org:" reference from their assignment. Abuse handling returns to the LIR by default. The ORGANISATION and ROLE object will be deleted by the RIPE Database's automated cleanup process, after a short time, if no longer referenced anywhere else. Regards Denis Walker Business Analyst RIPE NCC Database Group On 05/12/2012 09:59, Alessandro Vesely wrote:

On Tue 04/Dec/2012 17:11:28 +0100 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.

I think that the general case is that some customers just want to get connected while some others want to manage abuse. Customers may change their mind after some time, of course. Wasn't the design supposed to ease overriding the abuse handling object at will?

Dear Gert and other colleagues, After some off list clarification we see the point you are concerned with. The simplest case where an organisation manages all the abuse for all customers is easy to understand. In the real world this organisation has one or more internet resources and within the organisation there is a function (or role) that handles abuse complaints. So a real world picture is clear. Taking a member organisation as an example: member organisation / \ / \ internet abuse resources role This maps exactly to the new RIPE Database model: member ORGANISATION object / \ / \ INET(6)NUM member abuse objects ROLE object It is easy to see how to find the abuse handling role for any of these internet resources. The problem appears to be with the vision of what happens lower down in a network. After years of modifications the data model of the RIPE Database no longer reflects the real world. The relationships between objects are less than optimal. If you try to think of anything in terms of RIPE Database objects and relationships, it is not always obvious or clear. The implementation of the abuse-c proposal takes one small step to bringing the RIPE Database model closer to reflecting the real world, as outlined in the Database Groups presentation at RIPE 65. When a customer wants to handle abuse for their part of a network, they are taking over part of the management of that internet resource. In reality the customer's situation is the same as the member's. member ORGANISATION object / \ / \ INET(6)NUM abuse objects ROLE object / \ / \ / \ customer ORGANISATION object / \ / \ / \ / \ other INET(6)NUM customer abuse customers object ROLE object INET(6)NUM objects By including the customers ORGANISATION object the same structure is modelled at any level. This is the basic structure of any organisation that manages internet resources. So now it is easy to see how to find this customers abuse handling role and also how to find the abuse handling role for any of the other customers. This structure can be repeated as many times as necessary at any point in a network. We don't have abuse contacts hanging off different object types. The principle of finding the abuse contact is always the same. That is what makes the model simple in all cases. Internet resources includes AUT-NUM objects as well, and an organisation can have multiple top level INET(6)NUM objects, but to keep the diagram simple I ignored them. I hope this helps to explain the reasoning behind this model. To help with practical administration the RIPE NCC will provide some easy to use tools initially so a customers details only need to be entered once and appropriate objects will be created and the references made. To remove this setup for a specific customer just delete the reference to the ORGANISATION object. The extended garbage cleanup process will delete any cluster of ORGANISATION, MNTNER, ROLE, PERSON objects that are unused. We will also provide more extensive tools for managing changes to contact data at any level across multiple objects. Regards, Denis Walker Business Analyst RIPE NCC Database Group On 10/12/2012 14:42, Gert Doering wrote:

Hi,

On Wed, Dec 05, 2012 at 11:10:09AM +0100, Denis Walker wrote:

...

If at some point a customer chooses to do their own management of abuse handling for their assigned address space you simply create the ORGANISATION and abuse ROLE objects for this customer and add the "org:" reference to this customers assignment.

I'm not sure if I find this "simple", to be honest.

Being able to specify an abuse-c: in the ASSIGNED inet(6)num: object, and having the RIPE DB software honour that on queries - that is: not go to the allocation's org->abuse-c - would require less objects to be created, and thus, less effort and less opportunity for confusion.

Gert Doering -- NetMaster

Dear Gilles, Yes you are absolutely correct. I was outlining a simplistic example where the only part of resource management the customer handled was abuse. In this case, if they no longer handled their own abuse there would perhaps be no need for any of these objects. In which case the easiest way to clean up would be to remove the reference to the ORGANISATION object and the database garbage collector would remove the unreferenced objects. But of course there may be other reasons why a customer needs an ORGANISATION object. In these ORGANISATION objects with "org-type: OTHER" the "abuse-c:" reference is optional. So when looking for the most appropriate abuse handler, the database logic will work up the hierarchy looking for the first ORGANISATION object with an abuse contact referenced. Thanks for pointing this out. Regards Denis Walker Business Analyst RIPE NCC Database Group On 13/12/2012 10:54, Gilles Massen wrote:

Dear Denis,

On 12/11/2012 12:21 PM, Denis Walker wrote:

...

When a customer wants to handle abuse for their part of a network, they are taking over part of the management of that internet resource. In reality the customer's situation is the same as the member's.

member ORGANISATION object / \ / \ INET(6)NUM abuse objects ROLE object / \ / \ / \ customer ORGANISATION object / \ / \ / \ / \ other INET(6)NUM customer abuse customers object ROLE object INET(6)NUM objects

There is one thing that worries me with the setup: if I understood you correctly the appropriate (only?) way to remove a specific customer abuse object (and let the parent LIR handle abuses) is to remove the customer organisation object. However this would create a strong dependency between the org and the abuse object: if another object would be created that relies on the org object (like abuse-c does), you would link its existence to the presence of an abuse-c - appropriate/wanted or not.

You could circumvent this limitation by adapting the logic so that not each org object needs an abuse-c, but somewhere up the tree you need an abuse-c, even if the 'closest' org hasn't one. Parsing wouldn't get easier, though.

Best regards, Gilles