RIPE Database Proxy Service Issues
[Apologies for duplicate emails] Dear colleagues, There has been discussion on various mailing lists regarding the status of the RIPE Database Proxy Service. Before I address the issues that arose, I'd like to give you some background information on the service itself that may help with the discussions. Technical Background -------------------- To prevent the automatic harvesting of personal information (real names, email addresses, phone numbers) from the RIPE Database, there are PERSON and ROLE object query limits defined in the RIPE Database Acceptable Use Policy. This is set at 1,000 PERSON or ROLE objects per IP address per day. Queries that result in more than 1,000 objects with personal data being returned result in that IP address being blocked from carrying out queries for that day. Users of the RIPE Database have unlimited access to Network Information Centre (NIC)-related objects. They can use the -r flag in order to filter out personal objects and query NIC objects without any limitations. The RIPE Database Proxy Service allows websites to provide a third party interface to the RIPE Database. Without the proxy service, the third parties would quickly run into the limits set on RIPE Database queries. With the proxy service, we whitelist the third party IP address and ask them to pass their user's IP address to us, so limits are only set on the user's IP address, not the third party's. There is no technical way to ensure that the user IP addresses passed to us by the third party are valid. Potentially, third party users of the proxy service could harvest all personal data in the RIPE Database (approximately 2 million objects) in a matter of hours. To ensure that the RIPE NCC's Terms and Conditions are followed, we require a contract between the third party and the RIPE NCC. Users of the Proxy Service -------------------------- In the past ten years, the RIPE NCC has had 31 requests for the proxy service and over the past year, there have been only four active users of the service. Of these four, one is already a RIPE NCC member. NIC Information --------------- All NIC information is still available without access to the proxy service. In the normal presentation of whois data, there is a redirect system that allows users with a normal whois client to deal directly with the RIPE Database whois service. There is no need for a proxy service in this scenario. The proxy service is only necessary if the data needs to be presented in alternative forms, such as on a third party's website. The limits imposed on RIPE Database queries only apply to personal data. Users can always access NIC data in any form they like if they are happy not to receive personal data. On 6 March 2012, the RIPE NCC proposed to change the default behaviour of the query system to instead return only "ALLOWED" results if a user had reached their daily personal data query limit, but there was disagreement over this on the mailing list so the change was not implemented. The proposal is available at: http://www.ripe.net/ripe/mail/archives/db-wg/2012-March/003885.html Legal Considerations -------------------- The RIPE NCC operates under European Data Protection laws, so to avoid risk in this area we insist on having a contract with third parties who wish to use the proxy service. The RIPE NCC and its Executive Board believes that the proxy service should become a member service because it tightens the contractual relationship between the RIPE NCC and third parties. Currently, no such agreement that meets the EU Data Protection legislation is in place between the RIPE NCC and the proxy service users. In order to tighten the contractual relationship between the RIPE NCC and the Proxy service users, taking into account the recent approval of the Charging Scheme 2013 that caused a simplification of the contractual agreements between the RIPE NCC and its service users, the RIPE NCC offered to conclude the membership agreement for continuation of the service. Next Steps? ------------ The Executive Board approved changes to the draft version of the Activity Plan and Budget 2013, and the RIPE NCC published the final version on 13 December 2012: http://www.ripe.net/internet-coordination/news/announcements/ripe-ncc-activi... We do apologise, however, that the changes regarding the proxy service were not more explicitly communicated to the members and the RIPE community in advance of the final publication of the Activity Plan. The RIPE NCC asks that non-RIPE NCC member proxy service users become members but we propose to waive their membership fee until the discussion of the RIPE NCC Charging Scheme 2014 takes place. This will give the membership and community the opportunity to discuss the best way forward for the proxy service in the coming months while ensuring a strong contractual bond between the RIPE NCC and users of this service. In the meantime, there will be no changes to the proxy service and no loss of functionality for the community. The RIPE NCC and its Executive Board will return to its members with proposals for ways to ensure that their wishes are met with regard to service developments while allowing the RIPE NCC to be operate efficiently and responsively. If you have any comments on this issue, please direct them to this mailing list. Best regards, Axel Pawlik Managing Director RIPE NCC
Hello, Sorry, but the main question in this discussion seems to be wrong. What kind of goal we're trying to reach? To protect personal data from being processed not in that way or purpose they were collected by the RIPE? - but RIPE can't guaranty that the third parties will process data for the legal way or purpose. It will not be guarantied nor by direct access to RIPE's database nor by access via proxy service. The main question we should answer: why personal data are stored in RIPE database? There're two answers on this this question: 1. The only goal ot this data is to provide information to the RIPE ======================================= In this case all personal data should not be visible to any other parties 2. Data must provide contact information to any parties to be able to communicate with the person who described by the personal data object ============================================================================== In this case personal data provided and processed in the same way and purpose that they were collected and no restrictions should be used Axel, I'd like to pay your attention that RIPE (or any other organisation or individual) can: - protect personal data - do not protect personal data That's all. There's no third option As soon we speaking that the limitation of the FREE access to personal data is the means of the personal data protection - we're deceiving ourself. We DO NOT protect personal data. Also, I'd like to pay your attention that /64 IPv6 block should be provided to any End Site (according to ripe-538). So. if the RIPE database contains 2,000,000 ot records - the /64 allocation is enought to get all personal data from the database in a one hour for many-many-many times and it will avoid any RIPE limitations. So, in case of IPv6 access no limitations will work All the RIPE should provide - is the limited access to personal data (but not in the way it was prosed). All data should be stored in RIPE database. And any person should have a choice: to provide free access to this personal data or not. If the End User does not allow to provide free access to his/her personal data - the only one information should be displayed - is the phone (the phone number is not the personal information). It will provide acceptable level of direct communication to the personnel of the resource holder organization (for this type of communication the name of person is not required because it's not the private call and this call maked to "any person who can and may help with the issue"). Nor person's address nor person's name should be provided. Email address should be provided in output from the RIPE database but not the person's email address but the RIPE's robot email address with unique and autogenerated key that provide information to the robot to identify the person and forward email to his/her. Any parties can send email to the person from the RIPE database and this letter will be delivered by the RIPE robot (and robot will resend this letter to the correct recipient) - in this case the initial communication between third parties and the person from RIPE database contains no private information -- Best wishes, Andrey Semenchuk Trifle Internet Service Provider (056) 731-99-11 www.trifle.net
On 2 Jan 2013, at 18:43, Andrey Semenchuk <andrey@trifle.net> wrote:
the phone number is not the personal information
Sorry Andrey, it is. In the context of EU Data Protection legislation, ANY data identifying a Living Person is Personal Data. So things like (throwaway) email addresses, phone numbers, IM handles, URLs for someone's Facebook pages and so on are covered by the same Data Protection principles that would apply to a social security number, passport details or postal address. BTW, Europe's Data Protection Authorities can have different perspectives on what is and isn't acceptable even though the national Data Protection legislation in each EU country is underpinned by the same EU directives. Whatever works in one jurisdiction might not be allowed in another. Or vice versa. So unless you're based in the Netherlands please don't assume that whatever your DPA tells you (if you have one) is the same as the Dutch one tells the NCC.
What kind of goal we're trying to reach? To protect personal data from being processed not in that way or purpose they were collected by the RIPE? - but RIPE can't guaranty that the third parties will process data for the legal way or purpose.
This is precisely the problem. RIPE NCC is the Data Controller. It *has* to have a contractual relationship with any Data Processors (like a proxy service provider). The same Data Protection regime used by the Data Controller has to apply to any downstream Data Processors. The NCC can't just hand over the Personal Data in its databases and let anyone do whatever they want with that data. The matter at hand is the nature of the contractual relationship with these third parties. There's some confusion about that and how best to proceed. Clearly we need to arrive at a consensus. This will presumably involve production of a policy about third party access to the NCC database(s) or fixing whatever's broken in the current policy. To my mind there are essentially three options to choose from. All three will mean the third parties sign something that conforms with the NCC's EU/NL Data Protection obligations. 1) Provide third party access at no charge as a general public benefit. 2) Provide third party access for a fee which might (or might not) cover the NCC's costs for providing that service. 3) Restrict third party access to NCC members only. FWIW I can see advantages and disadvantages to all of these. I favour a fourth option: terminate all third party access and provide no bulk export from the database at all. That one's unlikely to be popular so I didn't suggest it.
On Thu, Jan 03, 2013 at 10:10:17AM +0000, Jim Reid wrote:
I favour a fourth option: terminate all third party access and provide no bulk export from the database at all. That one's unlikely to be popular so I didn't suggest it.
a fifth option, assuming it is technically feasible: provide all non-identifying data FOC to anyone but restrict all access (bulk or otherwise) to personal data (presumably person: and maybe role: objects) to members or under contract. Contracts to contain language restricting the purposes for which this data can be used and strict penalties for mis-use. Regards, Sascha Luck
On 2 Jan 2013, at 18:43, Andrey Semenchuk <andrey@trifle.net> wrote:
the phone number is not the personal information Sorry Andrey, it is.
In the context of EU Data Protection legislation, ANY data identifying a Living Person is Personal Data. "Person" object intended to identify employer of the organisation that holds objects in the RIPE database (aut-num, domain, inet-num, etc). In
Jim Reid wrote: this case the phone int person object is not the personal phone but the phone provided by employer. It's the service phone that should not indentify the person. If someone puts there his/her private phone - it's not the RIPE database problem - maybe this person consider it's private life (or part ot it) as an public information. In any case this phone publication - is the decision of the person and RIPE (even if this information is public and has none limitations of access) provides access to the data in compliance with the person's intentions, If we wants to make data protection safer - ok, let's strip phone information from the database output of the person object. In this case only organisation objects will contains phones.
What kind of goal we're trying to reach? To protect personal data from being processed not in that way or purpose they were collected by the RIPE? - but RIPE can't guaranty that the third parties will process data for the legal way or purpose.
This is precisely the problem. RIPE NCC is the Data Controller. It *has* to have a contractual relationship with any Data Processors (like a proxy service provider). The same Data Protection regime used by the Data Controller has to apply to any downstream Data Processors. The NCC can't just hand over the Personal Data in its databases and let anyone do whatever they want with that data.
The matter at hand is the nature of the contractual relationship with
Is there any chance to identify Data Processor systems? Not the person who queries RIPE database search but any type of Data Processor system? It's not. Any data processor system can make a single request from IP address in a day (in IPv6 address space it's not a problem) and none system will tell this data processor system from the user who queries the database The current question with data protection exists because the database provide personal data. And all we should do - is to cut personal data from the output. Personal information from the RIPE database (even if it is there) does not required to solve any situation between the Internet user (or organisation) and any resource holder - all communication will be done on "user (who initiate communication) -- organisation (resource holder)" or "organisation (that initiate communication) -- organisation (resource holder)". That's all these third parties. There's some confusion about that and how best to proceed. Clearly we need to arrive at a consensus. This will presumably involve production of a policy about third party access to the NCC database(s) or fixing whatever's broken in the current policy. As soon we provide access to personal data that are stored (or may be stored) in RIPE database on any basis - the first question should be not about relations between RIPE and third parties that may collect and process that data. The first question should be: is every person who stores personal data in the RIPE database agrees with this situation and allow to collect/process his/her data by any organisation except RIPE? If the person wished to provide free access to his/her personal data - RIPE should provide this access without any limitation. All data protection RIPE should provide - is a storage protection. If the person wishes to provide this information to RIPE only - no personal data should be displayed to any other third party. It's so simple! We're trying to answer to question that is not the main question by itself. The main question is: provide or do not provide personal information to third parties? -- Best wishes, Andrey Semenchuk Trifle Internet Service Provider (056) 731-99-11 www.trifle.net
On Thu, Jan 03, 2013 at 01:53:27PM +0200, Andrey Semenchuk wrote:
"Person" object intended to identify employer of the organisation that holds objects in the RIPE database (aut-num, domain, inet-num, etc). In this case the phone int person object is not the personal phone but the phone provided by employer. It's the service phone that should not indentify the person. If someone puts there his/her private phone - it's not the RIPE database problem - maybe this person consider it's private life (or part ot it) as an public information. In any case this phone publication - is the decision of the person and RIPE (even if this information is public and has none limitations of access) provides access to the data in compliance with the person's intentions,
Individuals hold IP space and other resources. Actually, in that case, even the organisation: object must be considered personal data as it usually even contains physical address information.
If the person wished to provide free access to his/her personal data - RIPE should provide this access without any limitation. All data protection RIPE should provide - is a storage protection. If the person wishes to provide this information to RIPE only - no personal data should be displayed to any other third party. It's so simple!
That leaves the issue of masking this data from whois - no idea whether this is technically even possible. Regards, Sascha Luck
Sascha Luck wrote:
Actually, in that case, even the organisation: object must be considered personal data as it usually even contains physical address information. Organisation is not the person
"'personal data' shall mean any information relating to an identified or identifiable natural person" (q) Directive 95/46/EC of the European Parliament and of the Council
If the person wished to provide free access to his/her personal data - RIPE should provide this access without any limitation. All data protection RIPE should provide - is a storage protection. If the person wishes to provide this information to RIPE only - no personal data should be displayed to any other third party. It's so simple!
That leaves the issue of masking this data from whois - no idea whether this is technically even possible.
Technically, specifying the data that should be provided and the data that shouldn't - it's even not a question for discussion "is it possible or not". Of course it's possible. It's not the subject of heuristic analysis of the arbitrary data - all the information stored inside the database (whatever type of database that is used) and specifying the criteria for displaying (or masking) data it not the question of possibility - it's the question of realization -- Best wishes, Andrey Semenchuk Trifle Internet Service Provider (056) 731-99-11 www.trifle.net
On Thu, Jan 03, 2013 at 03:20:15PM +0200, Andrey Semenchuk wrote:
Organisation is not the person
"'personal data' shall mean any information relating to an identified or identifiable natural person" (q) Directive 95/46/EC of the European Parliament and of the Council
Yes. If a natural person holds internet resources, the organisation: object is that person. I'm assuming you don't intend to ban natural persons from holding resources (and thereby requiring an organisation: object)? Regards, Sascha Luck
On Thu, Jan 03, 2013 at 03:20:15PM +0200, Andrey Semenchuk wrote:
Organisation is not the person
"'personal data' shall mean any information relating to an identified or identifiable natural person" (q) Directive 95/46/EC of the European Parliament and of the Council
Yes. If a natural person holds internet resources, the organisation: object is that person. I'm assuming you don't intend to ban natural persons from holding resources (and thereby requiring an organisation: object)? http://www.ripe.net/data-tools/support/organisation-object-in-the-ripe-datab... =========== The RIPE Database stores three main types of contact information:
Sascha Luck wrote: person, role and organisation objects. The person and role objects provide a way to find people responsible for operations or usage of the resources represented in the RIPE Database (IP blocks, Autonomous Systems, and domain names). However, these do not provide an easy way of mapping resources to a particular organisation. The organisation object fulfills this need. =========== http://meetings.ripe.net/ripe-46/presentations/ripe46-db-organisation_object... =========== Idea •Provide information about an organisation –LIR –Any other company, university, charity =========== Organisation object contains information about organisation. It's not the type of objects that should be used for natural person -- Best wishes, Andrey Semenchuk Trifle Internet Service Provider (056) 731-99-11 www.trifle.net
On Thu, Jan 03, 2013 at 03:48:48PM +0200, Andrey Semenchuk wrote:
Organisation object contains information about organisation. It's not the type of objects that should be used for natural person
In the hypothetical situation, when natural person is a holder of PI space or act as a LIR (i have no idea if this is even possible ;-) ), organisation object is mandatory and I guess it will be filled with that natural person's data. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
On 3 Jan 2013, at 11:53, Andrey Semenchuk <andrey@trifle.net> wrote:
Jim Reid wrote:
On 2 Jan 2013, at 18:43, Andrey Semenchuk <andrey@trifle.net> wrote:
the phone number is not the personal information Sorry Andrey, it is.
In the context of EU Data Protection legislation, ANY data identifying a Living Person is Personal Data. "Person" object intended to identify employer of the organisation that holds objects in the RIPE database (aut-num, domain, inet-num, etc).
Nope. Well, not always. The name of this object is a massive hint about the thing it identifies. :-) And not all objects in the database are held by organisations either. Sometimes IP resources are held by individuals. [An ISP added me to the database (without my consent or knowledge) when they gave me a /29. They later deleted that when I handed the space back. The ISP's policy was to populate the database with the contact details for every customer assignment they made. They buried a consent clause in the very small print of their customer contract.] Some organisations will be sole traders or one-person companies. In those cases pretty much all of the data about one of those organisations is Personal Data because they identify the individual who operates or owns that organisation.
In this case the phone int person object is not the personal phone but the phone provided by employer. ...
If we wants to make data protection safer - ok, let's strip phone information from the database output of the person object.
Andrey, you're focusing on unimportant detail and missing the bigger picture. This is not about phone numbers or what they might be used for in some contexts. If you want to discuss that, take it elsewhere. Deleting these (or email addresses or....) from contact objects will not solve anything. [And good luck getting consensus for a revised person object which also satisfies contradictory international requirements for Data Protection, privacy and Law Enforcement.] There will still be Personal Data in the database which has to be protected even if phone numbers are removed. Your name is Personal Data. Your DPA might well say the organisation field of a contact object is not Personal Data. Mine may well say the exact opposite. Or, worse, both say it depends on the context in which the Personal Data get used. ie: It might be OK for Hollywood's lawyers to mine whois for chasing down copyright violation but not OK for spammers to harvest email addresses from whois. This gets very murky very quickly. The subject is about levels of greyness and there's very little that lends itself to a clear black/white or yes/no decision.
Is there any chance to identify Data Processor systems? Not the person who queries RIPE database search but any type of Data Processor system? It's not. Any data processor system can make a single request from IP address in a day (in IPv6 address space it's not a problem) and none system will tell this data processor system from the user who queries the database
You seem to be focusing on detail and missing the bigger picture again. The terms Data Controller and Data Processor have specific definitions in Data Protection legislation. [I capitalise these terms to make it clear the formal definitions apply instead of a more generic or informal use.] These terms apply to roles. The specifics of the systems or procedures that someone/something in one of those roles may use don't matter: that's implementation detail. If you want a detailed explanation I suggest you consult the EU Directives, prevailing national law and a competent lawyer who understands this field. I am not a lawyer. Broadly speaking, the NCC is the Data Controller for the database. They are the legal entity responsible for it and how it gets used. Anyone or anything manipulating that database or extracting data from it (or possibly even just doing a lookup on it) is a Data Processor. As a Data Controller the NCC must ensure that the Data Processor does so in accordance with the EU Directive and Dutch law. You also seem to be more concerned about the identify of whatever is making a database lookup. That's not the issue. It's about the data which is provided as a result of that lookup. For regular whois lookups, there's usually a pile of legalese in the response which says what the data can and can't be used for. That's usually enough to keep the DPA happy. However if there's a bulk export of some database for a Data Processor to use for something else, the DPA will almost certainly insist on a paper contract between the Data Processor and the Data Controller.
The current question with data protection exists because the database provide personal data. And all we should do - is to cut personal data from the output.
A discussion about how or if Personal Data about IP resource holders get published will go round in circles forever and quickly degenerate into a screaming match. So I suggest we don't start that.
As soon we provide access to personal data that are stored (or may be stored) in RIPE database on any basis - the first question should be not about relations between RIPE and third parties that may collect and process that data. The first question should be: is every person who stores personal data in the RIPE database agrees with this situation and allow to collect/process his/her data by any organisation except RIPE?
That's a good question. But the wrong one. For one thing, many people don't know about the RIPE database, let alone that their details might be in it. I expect the current setup satisfies the Dutch authorities. So provided they're happy, it's best not to (re)open the whois can of worms. A better question would be "is there consensus that the RIPE database provides satisfactory mechanisms for individuals to protect or conceal their Personal Data and publishes information on how to use those mechanisms?
If the person wished to provide free access to his/her personal data - RIPE should provide this access without any limitation. All data protection RIPE should provide - is a storage protection. If the person wishes to provide this information to RIPE only - no personal data should be displayed to any other third party. It's so simple!
It's not. Anyone who thinks it is that simple does not understand the problem space. Sorry.
We're trying to answer to question that is not the main question by itself. The main question is: provide or do not provide personal information to third parties?
It's not that simple. It depends on what the third party wants the data for. As an example, you might think it's a no-brainer to provide that third party access to law enforcement. We all want to prevent crime and help the police catch bad guys. But suppose the cops are hunting whoever's hosting Wikileaks this week or Mugabe's goons want to arrest human rights campaigners. What then? OK, Zimbabwe's not in our service region but you get the general idea.
If you want to discuss that, take it elsewhere. Ouch, you're not friendly
You seem to be focusing on detail and missing the bigger picture again.
It's not. Anyone who thinks it is that simple does not understand the problem space. Sorry.
We're trying to answer to question that is not the main question by itself. The main question is: provide or do not provide personal information to third parties?
It's not that simple. It depends on what the third party wants the data for. As an example, you might think it's a no-brainer to provide that third party access to law enforcement. We all want to prevent crime and help the police catch bad guys. But suppose the cops are hunting whoever's hosting Wikileaks this week or Mugabe's goons want to arrest human rights campaigners. What then? OK, Zimbabwe's not in our service region but you get the general idea. Jim, do you listen yourself? Third parties will decide instead of person how his/her personal data should be processed and for what?
I may agree with you that the picture is too big to estimate it's size but you watching the picture from the wrong side. The goal of personal data protection is to protect data. But not the third-parties. And just for your information: law enforcements already has access to databases that they should has. If they hasn't - they use authorized procedures in their investigation to gain access to the required data. Assistance for the law enforcements is not the question of this discussion -- Best wishes, Andrey Semenchuk Trifle Internet Service Provider (056) 731-99-11 www.trifle.net
On 3 Jan 2013, at 14:51, Andrey Semenchuk <andrey@trifle.net> wrote:
If you want to discuss that, take it elsewhere. Ouch, you're not friendly
Apologies. I was just saying a discussion about the contextual significance of phone numbers was not appropriate for this list. No unfriendliness was stated or implied.
It's not that simple. It depends on what the third party wants the data for. As an example, you might think it's a no-brainer to provide that third party access to law enforcement. We all want to prevent crime and help the police catch bad guys. But suppose the cops are hunting whoever's hosting Wikileaks this week or Mugabe's goons want to arrest human rights campaigners. What then? OK, Zimbabwe's not in our service region but you get the general idea. Jim, do you listen yourself?
Of course. I only do what the voices inside my head tell me. :-) Well, maybe just the ones who shout loudest for longest. :-)
Third parties will decide instead of person how his/her personal data should be processed and for what?
I didn't imply anything like that at all. So let me spell it out for you. A Data Controller has certain responsibilities to discharge before they pass Personal Data to a third party. These include, but are not limited to, considering what that third party may do with that Personal Data, whether that Data Processor can be trusted (or not), if the Data Processor's data protection regime is acceptable, etc.
I may agree with you that the picture is too big to estimate it's size but you watching the picture from the wrong side. The goal of personal data protection is to protect data. But not the third-parties.
Nobody ever said it was about protecting third parties AFAICT.
And just for your information: law enforcements already has access to databases that they should has. If they hasn't - they use authorized procedures in their investigation to gain access to the required data. Assistance for the law enforcements is not the question of this discussion
You still seem to be missing the point and focusing on detail instead of the big picture. I was using law enforcement as an obvious example of a case where third party access to registry data isn't as clear-cut as may be first thought. And just for your information, I am very familiar with the authorised procedures that are used here and what would happen when overseas law enforcement knocked on the door.
Andrey, On Wednesday, 2013-01-02 20:43:33 +0200, Andrey Semenchuk <andrey@trifle.net> wrote:
2. Data must provide contact information to any parties to be able to communicate with the person who described by the personal data object ============================================================================== In this case personal data provided and processed in the same way and purpose that they were collected and no restrictions should be used
An alternate approach would be for the RIPE NCC to act as a go-between for communicating with resource holders. For example, if I know which hotel you are staying at, I can call the hotel and ask them to put me through to your room so I can talk to you, or I can leave a message. The hotel should not give me your room number, or any other information about you that they know. Likewise the RIPE NCC could convey messages to resource holders. In such a system we would not have to publish ANY private information. Cheers, -- Shane
Shane Kerr wrote:
On Wednesday, 2013-01-02 20:43:33 +0200, Andrey Semenchuk <andrey@trifle.net> wrote:
2. Data must provide contact information to any parties to be able to communicate with the person who described by the personal data object ============================================================================== In this case personal data provided and processed in the same way and purpose that they were collected and no restrictions should be used
An alternate approach would be for the RIPE NCC to act as a go-between for communicating with resource holders.
Actually this method was proposed in the letter you quote :) It will not work with phone numbers but with the emails - it will work. And already works for some public organisations which operates with personal data in compliance with Directive 95/46/EC. So RIPE has nothing to devise in this situation -- Best wishes, Andrey Semenchuk Trifle Internet Service Provider (056) 731-99-11 www.trifle.net
Andrey, On Thursday, 2013-01-03 16:03:28 +0200, Andrey Semenchuk <andrey@trifle.net> wrote:
Shane Kerr wrote:
On Wednesday, 2013-01-02 20:43:33 +0200, Andrey Semenchuk <andrey@trifle.net> wrote:
2. Data must provide contact information to any parties to be able to communicate with the person who described by the personal data object ============================================================================== In this case personal data provided and processed in the same way and purpose that they were collected and no restrictions should be used
An alternate approach would be for the RIPE NCC to act as a go-between for communicating with resource holders.
Actually this method was proposed in the letter you quote :) It will not work with phone numbers but with the emails - it will work. And already works for some public organisations which operates with personal data in compliance with Directive 95/46/EC. So RIPE has nothing to devise in this situation
Oh, I see. I should read more carefully. One slight difference is that I don't propose any particular mechanism, including where or how data is stored, or how messages are received or transmitted. I'm glad that other organisations have figured this out, and that we can happily copy what they have done. :) Cheers, -- Shane
On Thu, Jan 03, 2013 at 02:13:33PM +0100, Shane Kerr wrote:
An alternate approach would be for the RIPE NCC to act as a go-between for communicating with resource holders.
Not that I dislike the idea but, considering automated antispam bitching, that might be a DDoS vector ;) cheers, Sascha
On Thu, Jan 03, 2013 at 02:13:33PM +0100, Shane Kerr wrote:
An alternate approach would be for the RIPE NCC to act as a go-between for communicating with resource holders.
Not that I dislike the idea but, considering automated antispam bitching, that might be a DDoS vector ;) ... and ff the DDoS occurs in this situation, it should be prevented as
Sascha Luck wrote: the any other DDoS -- Best wishes, Andrey Semenchuk Trifle Internet Service Provider (056) 731-99-11 www.trifle.net
On 02/01/2013 15:57, Axel Pawlik wrote:
RIPE NCC offered to conclude the membership agreement for continuation of the service. [...] The RIPE NCC asks that non-RIPE NCC member proxy service users become members but we propose to waive their membership fee until the discussion of the RIPE NCC Charging Scheme 2014 takes place.
Axel, Thanks for your prompt reply and for providing an explanation of this decision. I have no objection to requesting a contract for access to bulk data access provided by the RIPE NCC. I do, however, have a problem with: - the general concept of requiring RIPE NCC membership for services which were previously available on a free-as-in-beer basis. - executive decisions being made which have a significant impact on the RIPE community, and which are made without consultation with either the RIPE NCC membership or the RIPE community. The decision by the RIPE NCC board to require RIPE NCC membership for proxy database access is not based on either a RIPE community or a RIPE NCC membership mandate, and I'm surprised to find out about this decision on nanog-l. Can you please roll back this decision until we've had some sensible debate on the matter, thanks, Nick -- Network Ability Ltd. ie.netability
Hi Nick, On Jan 2, 2013, at 11:38 PM, Nick Hilliard <nick@netability.ie> wrote:
Can you please roll back this decision until we've had some sensible debate on the matter,
Alex did email us "In the meantime, there will be no changes to the proxy service and no loss of functionality for the community." Rodney Joffe from geektools confirmed that the service did not go down on first of January 2013 and still is functional today, same as it was 31th of December 2012. It seems to me that the deadlines have been removed for now and the playing ground has been set up so that we can engage in proper discussion. Kind regards, Job
On 02/01/2013 22:45, Job Snijders wrote:
It seems to me that the deadlines have been removed for now and the playing ground has been set up so that we can engage in proper discussion.
The demand for RIPE NCC membership (with waived fees for at least 9 months) still stands. I think it inappropriate for this demand to remain until the issue is resolved with the ripe community / ripe ncc membership. Nick
Le 03/01/2013 00:15, Nick Hilliard a écrit :
On 02/01/2013 22:45, Job Snijders wrote:
It seems to me that the deadlines have been removed for now and the playing ground has been set up so that we can engage in proper discussion. The demand for RIPE NCC membership (with waived fees for at least 9 months) still stands. I think it inappropriate for this demand to remain until the issue is resolved with the ripe community / ripe ncc membership.
Nick
Yes, and would have seemed much preferred to take the case transparently to the community in the first place. (Let's use it as a classroom example for the future.) Cheers mh
Hi,
The demand for RIPE NCC membership (with waived fees for at least 9 months) still stands. I think it inappropriate for this demand to remain until the issue is resolved with the ripe community / ripe ncc membership.
Very big +1 Sander
as i am not a european or a ripe member, i generally try not to make non-tecnical comments on ncc policy. but, in this case, i am employed by a current user of this service.
It seems to me that the deadlines have been removed for now and the playing ground has been set up so that we can engage in proper discussion. The demand for RIPE NCC membership (with waived fees for at least 9 months) still stands. I think it inappropriate for this demand to remain until the issue is resolved with the ripe community / ripe ncc membership.
imiho, there are at least two issues. first is the one you address, that the game was changed after the members' approval, that is a violation of trust, and should be completely revoked, not just pushed ahead with a cost suspension. the second is the contractual issue. i understand the ncc feeling it needs a contractual relationship with bulk data users. this is needed to ensure respect for the data. the confusion here is that this need not be the membership contract. in fact, i wonder if (i confess to not checking) the membership agreement protects the bulk data. randy
All, On Wednesday, 2013-01-02 22:38:27 +0000, Nick Hilliard <nick@netability.ie> wrote:
I have no objection to requesting a contract for access to bulk data access provided by the RIPE NCC. I do, however, have a problem with:
- the general concept of requiring RIPE NCC membership for services which were previously available on a free-as-in-beer basis.
Especially since apparently this is something that really only affects a very few WHOIS users, so if this issue is a contract then it should be straightforward to get a free-but-binding contract for those folks. I vaguely remember from my days as manager of the RIPE Database group that we actually had signed contracts with such providers already, but perhaps the decade or so of time since those days has clouded my memory.
- executive decisions being made which have a significant impact on the RIPE community, and which are made without consultation with either the RIPE NCC membership or the RIPE community.
I recognize that it is hard to know whether any particular issue is one that warrants community or member input. Nobody is perfect, and there will be mistakes. However, the default should be transparency. If in doubt, isn't the best idea to simply ask? You know, rather than make people upset because unpopular decisions were made without consultation. Again. -- Shane
Hi, On Thu, Jan 03, 2013 at 03:05:37PM +0100, Shane Kerr wrote:
Especially since apparently this is something that really only affects a very few WHOIS users, so if this issue is a contract then it should be straightforward to get a free-but-binding contract for those folks.
+1 (Not commenting on the issue of "present one document for voting, then go implement something else". *That* is for the board to sort out) 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
Hi On 03.01.13 15:05, wrote Shane Kerr:
Especially since apparently this is something that really only affects a very few WHOIS users, so if this issue is a contract then it should be straightforward to get a free-but-binding contract for those folks. Full ack, it should be free but binding.
Regards Erich
On Wed, 2013-01-02 at 16:57 +0100, Axel Pawlik wrote: [...]
In the meantime, there will be no changes to the proxy service and no loss of functionality for the community.
The RIPE NCC and its Executive Board will return to its members with proposals for ways to ensure that their wishes are met with regard to service developments while allowing the RIPE NCC to be operate efficiently and responsively.
Hello Axel, Thank you for the clarification. In addition to points already addressed by others I have another remark and question: RIPE NCC sent me the contracts on December 17th stating they had to be signed and returned before the 31th. It amazes me that RIPE NCC sent these out just before the holidays, making it impossible for us (and I think many others) to have these documents reviewed by the right people and returned in time. Now that we've had time to review the document and that I've read your email I'm wondering if I still need to sign and return these documents. Could you please elaborate? Best regards, -- Teun Vink, Network Engineer BIT BV | teun@bit.nl | +31 318 648 688 KvK: 09090351 | GPG: 0x5A04F4E2 | RIPE: TEUN-RIPE
Dear Teun, All current RIPE NCC members who received the RIPE Database Proxy Service Agreement should check that they are satisfied with it and, if so, they should sign it and return it to the RIPE NCC. We will individually contact all non-RIPE NCC members who received the membership agreements and inform them of the situation regarding discussions on this service. Best regards, Axel On 1/3/13 12:00 PM, Teun Vink wrote:
On Wed, 2013-01-02 at 16:57 +0100, Axel Pawlik wrote: [...]
In the meantime, there will be no changes to the proxy service and no loss of functionality for the community.
The RIPE NCC and its Executive Board will return to its members with proposals for ways to ensure that their wishes are met with regard to service developments while allowing the RIPE NCC to be operate efficiently and responsively.
Hello Axel,
Thank you for the clarification. In addition to points already addressed by others I have another remark and question:
RIPE NCC sent me the contracts on December 17th stating they had to be signed and returned before the 31th. It amazes me that RIPE NCC sent these out just before the holidays, making it impossible for us (and I think many others) to have these documents reviewed by the right people and returned in time.
Now that we've had time to review the document and that I've read your email I'm wondering if I still need to sign and return these documents. Could you please elaborate?
Best regards,
participants (14)
-
Andrey Semenchuk -
Axel Pawlik -
Erich Hohermuth -
Gert Doering -
Jim Reid -
Job Snijders -
Michael Hallgren -
Nick Hilliard -
Piotr Strzyzewski -
Randy Bush -
Sander Steffann -
Sascha Luck -
Shane Kerr -
Teun Vink