Hi all Attached are the new draft versions of 4 proposals concerning person and other objects. They include the two already discussed in the DB-WG session at RIPE 54: Maintaining person objects Cleanup of person objects plus another issue we briefly discussed at the DP-TF meeting at RIPE 54: Authenticating references to person objects and another loosely related proposal: Structuring the address fields of person objects. We have tried to accommodate all the issues raised in the DB-WG session. As a package they address a number of Data Protection and security issues. If all these proposals are accepted by the community we will implement them one at a time. But we would like to plan the code changes based on the full set that are approved as they are all related. Your initial feedback will be appreciated before we release them to the wider community. regards Denis Walker RIPE NCC Maintaining person, role and domain objects Abstract -------- This is a proposal regarding maintaining all objects. * Maintaining person, role and domain objects o Abstract o Intended Audience o Introduction o Proposal o Illustrations of how the checks work + New startup + Closing down + Modifying existing data o Implementation + Stage 1 + Stage 2 o Statistics o Code changes (for our benefit, not part of public proposal) Introduction ------------ It was agreed at RIPE 54 to make "mnt-by:" mandatory on all objects. Currently, for person, role and domain objects, "mnt-by:" is optional. Making "mnt-by:" mandatory on person objects raises two clear issues: 1. It creates a chicken and egg situation between person and mntner objects. 2. Many person objects are not changed for years, so any change to syntax may take a long time to be reflected in the database. So many un-maintained person objects could remain so for many years. Proposal -------- Making "mnt-by:" mandatory on role and domain objects does not cause any technical difficulties. To accommodate all the issues for the person objects, we suggest a slightly different approach. 1. Make "mnt-by:" mandatory in person objects. 2. Provide a mechanism in dbupdate to handle the startup case where a new person and mntner objects are required. 3. Provide a mechanism in dbupdate to handle the closing down situation where the last person and mntner objects are to be deleted. 4. Extend the referential integrity checks so that a person object cannot be referenced unless it is maintained, except in a mntner object 5. Extend the referential integrity checks so that a mntner object cannot be referenced unless it's referenced person objects are maintained, but excluding the cyclic case of a person and mntner object referencing each other. The referencing checks sound complicated in words, but are actually quite simple. The illustrations below explain how it works in practice. This approach has a number of advantages: 1. It accommodates the chicken and egg situation. 2. We already do referential integrity checks. Whenever there is a reference to a person object, the database software checks if the person object exists. We only have to extend this check to see if the person object is also maintained. 3. Whenever there is a reference to a mntner object, the database software checks if the mntner object exists. We only have to extend this check to see if the person objects referenced by the mntner are maintained. 4. Each time any other object (say an inetnum or aut-num) is modified, the referenced person objects need to be maintained. If not, the update will fail. This will not prevent anyone from working. If they are going to modify an inetnum object, they must be authorised to do so. They can apply the same mntner to any un-maintained person objects. This encourages users to maintain the existing person objects. A cgi script will be provided to make this process simple and quick. 5. No un-maintained person object can be linked to the white pages to avoid deletion. Illustrations of how the checks work ------------------------------------ New startup ----------- Send an update message to dbupdate to create a person object and a mntner object. These must be the first two objects in an update message, in any order. The references to each other must also be in place. The database software will accommodate this. person: Denis Walker address: RIPE Network Coordination Centre (NCC) address: Singel 258 address: 1016 AB Amsterdam address: The Netherlands phone: +31 20 535 4444 nic-hdl: DW-RIPE mnt-by: aardvark-mnt notify: denis@ripe.net changed: denis@ripe.net 20040318 source: RIPE mntner: AARDVARK-MNT descr: Mntner for denis' objects. admin-c: DW-RIPE tech-c: DW-RIPE upd-to: denis@ripe.net auth: X509-1 notify: denis@ripe.net mnt-by: AARDVARK-MNT referral-by: RIPE-DBM-MNT changed: denis@ripe.net 20040225 source: RIPE In dbupdate it will recognise that the first person/mntner object references a non-existent mntner/person object. It will check that this referenced object is next in the update message. If so the "mnt-by:" attribute will be removed from the person object. The person and mntner objects will be created. Then the person object will be modified to add back the "mnt-by:" attribute. The objects are now fully configured and can be used. The person object can be referenced by any other object where a nic-hdl is referenced. It can also be linked to the white pages. The mntner can be used to protect any data in the database. If the non-existent referenced object is not next in the update message then an error message will be generated and the update will fail. This is the current behaviour. Closing down ------------ The same situation occurs when closing down and deleting all the data. It is possible to delete all data except for the last person and mntner objects in the normal way. Send these last two together in an update message, both marked with the "delete:" pseudo attribute. Only these two objects should be in the update message. In dbupdate it will recognise that the first person/mntner object to delete is referenced in a mntner/person object. It will check that this referencing object is next in the update message and also marked for deletion. If so the person object will be modified first to remove the "mnt-by:" attribute. The mntner object will then be deleted followed by the person object. Modifying existing data ----------------------- Suppose some data is to be modified and there is a reference to an un-maintained person object. Suppose you already have this data in the database: inetnum: 193.0.0.0 - 193.0.7.255 netname: RIPE-NCC descr: RIPE Network Coordination Centre descr: Amsterdam, Netherlands remarks: Used for RIPE NCC infrastructure. country: NL admin-c: DW-RIPE tech-c: DW-RIPE status: ASSIGNED PI mnt-by: AARDVARK-MNT mnt-lower: AARDVARK-MNT changed: bit-bucket@ripe.net 20060221 source: RIPE person: Denis Walker address: RIPE Network Coordination Centre (NCC) address: Singel 258 address: 1016 AB Amsterdam address: The Netherlands phone: +31 20 535 4444 nic-hdl: DW-RIPE notify: denis@ripe.net changed: denis@ripe.net 20040318 source: RIPE mntner: AARDVARK-MNT descr: Mntner for denis' objects. admin-c: DW-RIPE tech-c: DW-RIPE upd-to: denis@ripe.net auth: X509-1 notify: denis@ripe.net mnt-by: AARDVARK-MNT referral-by: RIPE-DBM-MNT changed: denis@ripe.net 20040225 source: RIPE The inetnum and mntner objects both reference a person object that is not maintained. This situation can continue for the foreseeable future with no problem. Until some data needs to be changed. An attempt to modify the inetnum object will fail. This is because it references a person object that is not maintained. It also references a mntner object which references un-maintained person objects. These person objects will have to be maintained before the inetnum object can be modified. A cgi script will be provided to allow this to be done quickly and easily. When all referenced person objects are maintained, the original update can be resubmitted and will proceed. Implementation -------------- As with the crypt-pw deprecation this will have a staged rollout. Stage 1 * No new person, role or domain objects can be created without a "mnt-by:" attribute. * Any unmaintained person, role or domain object cannot be modified without adding an "mnt-by:" attribute. * Any update where objects reference an un-maintained person object, either directly or their mntner has such references, will generate a warning message in the acknowledgement. In this stage the acknowledgement message may include these warnings: ***WARNING: Un-maintained person object referenced [DW-RIPE] Stage 2 * Any update where objects reference an un-maintained person object, either directly or their mntner has such references, will generate an error message in the acknowledgement and the update will fail. In this stage the acknowledgement message may include these errors: ***ERROR: Un-maintained person object referenced [DW-RIPE] Statistics ---------- Not a very statistically valid survey, but we looked at a few days just after the RIPE meeting to see how many new person objects were created with and without a mntner. They were queried some time after creation to allow for a "mnt-by:" to be added later. Also how many unique person objects were referenced in any objects in update messages with and without a mntner. AUTO- references were ignored in both creations and updates. Multiple instances of the same person object being referenced many times were counted as one. date created with created without referenced with referenced without 20070515 156 89 925 726 20070516 111 67 1022 486 20070517 85 48 476 185 20070518 82 18 679 445 Clean up of unreferenced person objects Abstract -------- This is a proposal for a one time cleanup of unreferenced person objects. It also addresses the issues of flagging objects prior to deletion and an opt-in white pages. * Clean up of unreferenced person objects o Abstract o Intended Audience o Introduction o Background o Changes to objects o Flagged o White pages o Bulk cleanup procedure + Month 1 + Month 2 + Month 3 + Notes o References o Follow up + WG mailing list references + RIPE Meeting minutes references Introduction ------------ According to our database consistency statistics program (dbconstat [1]) we currently have 460,573 unreferenced person/role objects [2]. Some of these may be maintained, but are still unreferenced. Any personal data not referenced by Internet resources do not fit within the primary purpose of the RIPE Database. They should not be stored in the RIPE Database beyond a reasonable 'work in progress' period. A secondary purpose of the RIPE Database has been proposed. This will be a 'white pages' listing of 'significant' people within the Internet community. Those wishing to be linked to these white pages must 'opt-in' and explicitly consent to their personal data being displayed in a public database. We regard this consent to be given by providing the authentication to modify the person object. Those doing so will be exempt from the cleanup process. One of the other current proposals is to maintain all objects. This may result in many of the currently unreferenced person/role objects being referenced in a maintainer which maintains the person/role object. This pair of mutually referencing objects may not be linked to any other object. This may have a significant effect on the original proposal. We therefore propose a change to this one time cleanup to accommodate this effect and aim to hit the majority of the previously identified objects which should be removed. The rest will be taken care of later with the introduction of a regular cleanup script. The new proposal will still target any unreferenced person/role objects. But also target person objects and their referencing mntner object, providing this pair of objects only reference each other. Even though person/role objects must now be maintained, this does not mean they will all be referenced by a mntner. They may be maintained by an existing mntner which references other person/role objects. This allows for the maintained person/role objects to still be unreferenced. Targeting 'loose' mntner objects will catch the mutually referencing pairs. There may be many more of these when it is required to maintain person objects. In this case we will only target the person/mntner object pairs. To include role objects implies person/role/mntner groups with many more references. This is too complicated to handle within the scope of this one time cleanup process. Background ---------- The RIPE NCC has had a mandate to delete these since RIPE40: http://www.ripe.net/ripe/wg/db/minutes/ripe-40.html (2001) At RIPE 41, the Database Working Group agreed that "maintained objects will now be removed" and "gave a mandate to the RIPE NCC to continue with the cleanup process." http://www.ripe.net/ripe/wg/db/minutes/ripe-41.html (2002) The cleanup process of 2003 (http://www.ripe.net/db/news/unref-cleanup-200304.html) involved using a script to run periodic cleanups. This script was put in place. However, it failed about 18 months ago. Because of other priorities, we have not had the time to examine this issue again until now. The graph showing the increase in these unreferenced person objects [3] indicates that the cleanup script appeared not to be performing correctly. At the start of 2006, there were about 300,000 unreferenced person/role objects. Since then there has been a steady increase with a large increase of almost 50,000 in February 2007. The graph also shows a slightly higher rate of increases in these objects since February 2007. At RIPE 54 (2007) it was agreed that a new cleanup process is needed. Concerns regarding use as 'white pages' and the issue of tagging objects prior to deletion to delay re-use of nic-hdls have been addressed in this new proposal. Because redundant personal data, with no explicit consent to remain, is a serious data protection issue, we want to take a new approach to this in the future. Once the initial cleanup is in progress, we will create a new proposal for a new, regular cleanup procedure. This will be sent to the Data Protection Task Force [4] and then to the rest of the community. Changes to objects ------------------ Add a "not-ref:" attribute to person/role objects. This indicates that the person/role object is not referenced and the date when it last became unreferenced. It is generated by the database software and takes a date stamp. It can also take an extra tag 'FLAGGED'. It cannot be changed in any way by users. person: [mandatory] [single] address: [mandatory] [multiple] phone: [mandatory] [multiple] fax-no: [optional] [multiple] e-mail: [optional] [multiple] org: [optional] [multiple] nic-hdl: [mandatory] [single] not-ref: [generated] [single] remarks: [optional] [multiple] notify: [optional] [multiple] abuse-mailbox: [optional] [multiple] mnt-by: [mandatory] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single] Create a new org-type for organisation objects: org-type: WHITE-PAGES This type can only be set by the database administrators. Flagged ------- When an object is deleted the nic-hdl becomes immediately re-usable by anyone. To allow sufficient time for the user to decide what they want to do with their (unreferenced) person/role objects, they will be flagged before deletion. During this flagged period the user can make appropriate references, link it to the white pages (maintained person objects only) or delete it themselves. If nothing is done it will be automatically deleted after a set flagged period is over. The cleanup script will append the 'FLAGGED' tag to the "not-ref:" generated attribute in the selected, (unreferenced) person/role objects: not-ref: <date> FLAGGED If the object has a "notify:" attribute or is maintained, the user will be notified of this modification by the normal update mechanism. A customised notification message will be used to make it clear to the user why this notification has been sent and reference a web page with further details. If the user wishes to keep this object they can reference it either directly or indirectly from an internet resource or apply to link it to the white pages (maintained person objects only). Either of these operations, if successful, will result in the "not-ref:" attribute being removed from the object by the database software. After an agreed period, if this "not-ref:" attribute is still present with the 'FLAGGED' tag the object will be deleted. The user will be notified by the normal update mechanism with the standard message, if the appropriate contact attributes are present. White pages ----------- There are some people who have a 'significant presence' within the internet community, but who are not directly responsible for any internet resource. These people may want/need to be easily contactable by the community. To facilitate this we will introduce a white pages to the RIPE Database. Users can have their person objects linked to the white pages. The RIPE NCC will create a number of organisation objects to define the categories of the white pages. For example: RIPE NCC board RIPE WG chairs RIPE working groups etc These organisation objects will have a new "org-type:" of 'WHITE-PAGES'. For each category there will be a moderator who will approve an application. The nic-hdl of the moderator(s) will be stored in a "remarks:" attribute in the organisation objects. Details of the white pages and how to apply will be available on the RIPE website. A user can apply to have their person object linked to the white pages. They should select the category and contact the moderator. The user needs to send their full person object to the moderator. This should either include the plain text password or be a signed message providing the authentication to modify this person object. Unmaintained person objects will not be linked to the white-pages. If the moderator approves the application s/he will add an "org:" attribute referencing the appropriate organisation object and the required authentication and submit the message as an update to the RIPE Database software. If the user no longer wishes to be linked to the white pages they can remove the "org:" attribute from the person object. However, if the object is not referenced it will be tagged and then deleted. Person objects that are referenced by internet resources can still be linked to the white pages if the user wishes to be known in a specific category. Unreferenced person objects and person/mntner pairs will be exempt from the cleanup process if linked to the white pages. You can only apply for an existing, maintained person object with an "e-mail:" attribute to be linked to the white pages. The person objects must be created and maintained in the normal way before applying. If the object is later modified to remove the "e-mail:" attribute it will lose it's white pages status. The nominated moderator for the selected categories can be the RIPE NCC for such categories as RIPE NCC board and RIPE WG chairs. The WG chairs (or co-chairs) for their WG category, etc. Requests for additional white pages categories can be sent to Customer Services at RIPE NCC. These requests will be forwarded to the WG chairs mailing list for approval. If approved the RIPE NCC will create the new organisation object, update the web page and notify the moderator. At RIPE 54 there was no discussion on who should be allowed to use the white pages. Without any limits or restrictions applied, it is open to abuse and could become an address book with thousands or tens of thousands of entries. We would simply move the problem of unreferenced person objects from one place to another. Although the RIPE NCC is Data Controller for the RIPE Database, it is not in a position to decide on the usage of the white pages. This is why we have introduced the moderator position to put this responsibility on members of the community who are in a position to make these decisions. We do not expect a high demand for this service or for creating many new white pages categories. If the demand does become excessive then it becomes a social networking service for technical people. In that case we should reassess the purpose and implementation. Our first option is to keep it simple and constrained. Bulk cleanup procedure ---------------------- Month 1 * Select 80,000 unreferenced person/role objects or person/mntner pairs and tag them. (These will be the first 80,000 found by an sql query on the database.) Month 2 * Check selected objects. * Those still unreferenced and tagged: o Delete using normal update process. o Run updates overnight to avoid any unnecessary load on the servers. * Select next 80,000 unreferenced person/role objects or person/mntner pairs and tag them. Month 3 * Repeat process until complete. Notes ----- This procedure will take about 6 months to clear the current backlog, not including the extra time that may be necessary due to the increases over that period. We will announce the start of the cleanup to the Working Group mailing lists and as a news item on our web site home page. References ---------- [1] dbconstat http://www.ripe.net/projects/dbconstat/index.html [2] current unreferenced person/role objects http://www.ripe.net/projects/dbconstat/html/cons-current.html [3] graph of unreferenced person object increase http://www.ripe.net/projects/dbconstat/cons-unrefpero.html [4] Data Protection Task Force http://www.ripe.net/ripe/tf/dp/index.html Authentication for referencing of person and role objects Abstract -------- This is a proposal regarding authentication of references to person and role objects. * Authentication for referencing of person and role objects o Abstract o Intended Audience o Introduction o Background o Details o Implementation o How to implement this in a large company or organisation. o For internal reference (not part of proposal) + Possible extension to the proposal Introduction ------------ There is currently no requirement to authenticate a reference to any person or role object in the database. This can lead to hijacking and the accidental or deliberate misrepresentation of responsibility for data. The database software already includes a mechanism for this type of authentication. References to organisation and irt objects must be authenticated. We propose to extend this list to include person and role objects. Background ---------- There are two ways a reference to the wrong person object can be made - accidental and deliberate. Accidental references can be made by mistyping. Maybe xy58-ripe instead of xy85-ripe. Even though it is accidental it can still cause confusion to anyone wanting to contact the responsible people for some data. Deliberate references to the wrong person may be made to avoid responsibility for use of address space. If someone is doing something nasty on the internet they have three options to try to avoid responsibility for a while. 1. Reference a person object with obviously stupid data in it. But anyone seeing a person object for Donald Duck will waste no more time looking further. 2. Reference a person object with false, but sensible looking data in it. But if a law enforcement agency is looking to make contact with the responsible party they will quickly find out if London Road in Southend has a number 147. If the address does not exist or the phone number does not match the address they will again quickly dismiss this false data. 3. Reference an existing, valid person object belonging to someone else. If a spammer references my person object, the police will come knocking on my door. I will say it has nothing to do with me, which of course I would say if I was the spammer. The police will then waste time investigating me while I try to prove my innocence. This wastes time as well as causing me problems. The RIPE NCC occasionally receives requests from LEAs for information about the responsible persons for address space. So this data is used in investigations. This proposal prevents any deliberate attempt to divert attention as well as avoiding mistakes. Details ------- The proposal is to add an "mnt-ref:" attribute to person and role objects. person: [mandatory] [single] address: [mandatory] [multiple] phone: [mandatory] [multiple] fax-no: [optional] [multiple] e-mail: [optional] [multiple] org: [optional] [multiple] nic-hdl: [mandatory] [single] mnt-ref: [optional] [multiple] remarks: [optional] [multiple] notify: [optional] [multiple] abuse-mailbox: [optional] [multiple] mnt-by: [mandatory] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single] This attribute will specify mntner objects that can authorise a reference to this person/role object. This will only be required when a reference is added to an object. The "mnt-ref:" attribute is optional. The functionality will default to the "mnt-by:" when this new attribute is not present, or if authentication is not passed by any mntners in the "mnt-ref:" attributes. To add a reference to a person object as "admin-c:" of say an inetnum object, authentication will be required from a mntner listed in the "mnt-by:" of the inetnum object, as is the case now. In addition to this, authentication will also be required from a mntner listed in the "mnt-ref:" of the person object, if this attribute is present. If this attribute is not present, or non of the authentications passed, the mntner in the "mnt-by:" of the person object will need to authorise the reference. Implementation -------------- * All new person or role objects can be created with an optional "mnt-ref:" attribute. * Any person or role object can be modified to add an "mnt-ref:" attribute. After an agreed flag date, adding references to person or role objects will require the authentication of the person/role object. How to implement this in a large company or organisation. --------------------------------------------------------- Many organisations have several staff who make changes to their data in the RIPE Database. Their data may also reference many person objects of their customers. If these have been generated by the company on behalf of their customers and all have the same mntner as "mnt-by:", it is a simple matter to add the authentication for this mntner to all updates where a new reference is created. If the person objects have different mntners or are maintained by the customers themselves it requires a little bit more work to set up. One way to accommodate this is to create one new mntner object. Add a pgp key for each staff member to this mntner. Put this mntner in all the referenced person objects as the "mnt-ref:". Or ask all the customers to add this mntner for you. All these staff can now authorise references to all the person objects. If a staff member leaves simply remove their pgp key from the mntner. If a person does not want to be referenced they can either remove or not add this mntner to their person object. Structuring of address attributes in person, role and organisation objects Abstract -------- This is a proposal to properly structure address attributes in person, role and organisation objects. * Structuring of address attributes in person, role and organisation objects o Abstract o Intended Audience o Introduction o Changes to objects o Implementation + Stage 1 + Stage 2 Introduction ------------ Currently there is only a single "address:" attribute. This holds all the address details in free text format. It is almost impossible to break down this single free text into the component parts of an address. We propose to structure the address into separate attributes matching the standard components. It also brings it into line with our internal Registration Database. This will * improve the overall 'usefulness' of the data * allow historical data in the database to be 'cleaned' by removing the personal data but keep the city/country information. This may be useful for future statistical purposes * allow information to be made available to those who insist on doing IP to city mapping without disclosing any personal data. This is a convenient time to do this along with the other changes currently proposed with person and role objects. Changes to objects ------------------ The "address:" attribute will be replaced with: * "street:" * "city:" * "zip:" * "country:" The "country:" attribute will only accept an international country code to avoid differences in spelling. Taking the person object as an example (the same change will apply to role and organisation). person: [mandatory] [single] street: [mandatory] [multiple] city: [mandatory] [single] zip: [optional] [single] country: [mandatory] [single] phone: [mandatory] [multiple] fax-no: [optional] [multiple] e-mail: [optional] [multiple] org: [optional] [multiple] nic-hdl: [mandatory] [single] remarks: [optional] [multiple] notify: [optional] [multiple] abuse-mailbox: [optional] [multiple] mnt-by: [optional] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single] These new attributes will not be inverse searchable. So it will not be possible to find all persons in a city, for example. Implementation -------------- Again this will be rolled out in stages. Stage 1 * Only allow new objects with properly constructed attributes. * Whenever a person/role/organisation object is modified with "address:" attributes a warning message will be added to the acknowledgement. * Whenever a person/role/organisation object is referenced with "address:" attributes a warning message will be added to the acknowledgement. ***WARNING: The person object [DW-RIPE] still contains "address:" attributes. Stage 2 * Whenever a person/role/organisation object is modified with only "address:" attributes an error message will be added to the acknowledgement. * Whenever a person/role/organisation object is referenced with only "address:" attributes an error message will be added to the acknowledgement and the update will fail. ***ERROR: The person object [DW-RIPE] still contains "address:" attributes.
Hi Denis, hi group, just a couple of comments that came to my mind. [Maintaining (as many) objects (as possible)] I consider it a splendid idea to have all DB objects maintained, so - I know who _must_ have once had knowledge about the object in question - I know where to go to have something updated / to inquire Others may find the idea appealing in order to create a string of objects that belong together (amazing what you can find out about people/companies that way). That does seem to create other privacy issues. The alternative of exempting person objects seems to be a good idea. Anyway, the chicken-and-egg problem does persist with all solutions where I need the objects created at the same time, because the normal and desired way of creating objects in the RIPE-DB is by using the "AUTO-xxx" variable instead of a preassumed name (DW1, AARDVARK-MNT). That those in the know define their object names themselves after having checked them to be available doesn't help the others. If we could use the object creation mechanism like the following, we can circumvent the chicken-and-egg problem. I have not tried it, so I'm not certain it will work already. If not, this could be item 2 in the proposal. person: Denis Walker address: RIPE Network Coordination Centre (NCC) address: Singel 258 address: 1016 AB Amsterdam address: The Netherlands phone: +31 20 535 4444 nic-hdl: AUTO-1 mnt-by: AUTO-2 notify: denis@ripe.net changed: denis@ripe.net source: RIPE mntner: AUTO-2 descr: Mntner for denis' objects. admin-c: AUTO-1 tech-c: AUTO-1 upd-to: denis@ripe.net auth: X509-1 notify: denis@ripe.net mnt-by: AUTO-2 referral-by: RIPE-DBM-MNT changed: denis@ripe.net source: RIPE Apart from the creation issue I concur with this proposal. The linked-objects privacy issue can be circumvented, but with the ability of inverse lookups already built into the RIPE DB, this poses no _new_ issues. [White pages] I'm not certain if the RIPE NCC should create a new "phone directory" for "significant persons". Who defines significance, who decides whether the user-selected category applies, who defines categories in the first place, who points out moderators? Concerning the moderation process... - Is it really a good idea to have users send their maintainer password to a moderator? - Since a changed object needs re-signing, in the case of PGP or X.509 key security, the moderator needs the private keyring involved. - Alternatively the moderator can have special rights to the RIPE DB. Well. - Can a user be kept from adding any org: attribute to an object? (That's not a rhetorical question, I couldn't find that it be checked, even though I have a faint inkling here) Yours, Elmar.
Hi Elmar Thanks very much for your quick feedback. You raise some interesting points. But I think some of the issues may mean I did not explain my thoughts clearly enough in the proposals. My replies are inline below. Elmar K. Bins wrote:
Hi Denis, hi group,
just a couple of comments that came to my mind.
[Maintaining (as many) objects (as possible)]
I consider it a splendid idea to have all DB objects maintained, so - I know who _must_ have once had knowledge about the object in question - I know where to go to have something updated / to inquire
Others may find the idea appealing in order to create a string of objects that belong together (amazing what you can find out about people/companies that way). That does seem to create other privacy issues.
From a public accountability point of view it may not be a bad idea to be able to find out some of this information. From a company point of view maybe some rationalisation is needed. Do companies really have 20 staff responsible for administering IP addresses, all of whom need to be
publicly addressable? Or do some people just want to be in the RIPE Database (White Pages)? There are ways of using the database now to allow 20 people to work with the data, but only have one or two as the publicly accountable and contactable persons. The other 18 don't need to have there personal details in the database. If public accountability vs company confidentiality becomes an issue then we can look at that as a separate item.
The alternative of exempting person objects seems to be a good idea.
Not sure where this comes from. The proposals don't mention any exemption from being maintained. The only person exemption is from being deleted if in the white pages.
Anyway, the chicken-and-egg problem does persist with all solutions where I need the objects created at the same time, because the normal and desired way of creating objects in the RIPE-DB is by using the "AUTO-xxx" variable instead of a preassumed name (DW1, AARDVARK-MNT). That those in the know define their object names themselves after having checked them to be available doesn't help the others.
Although I have used 'real' data in the example, it is not the lack of AUTO- tags that causes the chicken and egg situation. The example you show below still has the chicken and egg. You have two objects, each with an auto generated name. But each object references the auto generated name from the other object. So which ever one you create first needs to reference the 'as yet not generated' name from the other object.
If we could use the object creation mechanism like the following, we can circumvent the chicken-and-egg problem. I have not tried it, so I'm not certain it will work already. If not, this could be item 2 in the proposal.
person: Denis Walker address: RIPE Network Coordination Centre (NCC) address: Singel 258 address: 1016 AB Amsterdam address: The Netherlands phone: +31 20 535 4444 nic-hdl: AUTO-1 mnt-by: AUTO-2 notify: denis@ripe.net changed: denis@ripe.net source: RIPE
mntner: AUTO-2 descr: Mntner for denis' objects. admin-c: AUTO-1 tech-c: AUTO-1 upd-to: denis@ripe.net auth: X509-1 notify: denis@ripe.net mnt-by: AUTO-2 referral-by: RIPE-DBM-MNT changed: denis@ripe.net source: RIPE
Apart from the creation issue I concur with this proposal. The linked-objects privacy issue can be circumvented, but with the ability of inverse lookups already built into the RIPE DB, this poses no _new_ issues.
[White pages]
I'm not certain if the RIPE NCC should create a new "phone directory" for "significant persons". Who defines significance, who decides whether the user-selected category applies,
This is why we introduced the idea of moderators as the RIPE NCC has no idea how to make these decisions.
who defines categories in the first place, who points out moderators?
We hope this will be a small list and perhaps WG chairs and co-chairs have been around long enough (and I say that in the nicest possible way :) ) to know who these 'significant people' are. If it becomes heavily used then we are talking about social networking. Then we need to look at alternative solutions (if we still think there is a problem here to be solved).
Concerning the moderation process...
- Is it really a good idea to have users send their maintainer password to a moderator? - Since a changed object needs re-signing, in the case of PGP or X.509 key security, the moderator needs the private keyring involved.
We do not advise anyone to send their passwords to other people. So that requires use of PGP. Now your other point shows a flaw in my logic, which I will correct in the proposal. The user will have to add the organisation reference to their person object, sign it and send it to the moderator. If the moderator approves it, they just need to sign it again and send it to the database.
- Alternatively the moderator can have special rights to the RIPE DB. Well.
This is not something we want to do.
- Can a user be kept from adding any org: attribute to an object? (That's not a rhetorical question, I couldn't find that it be checked, even though I have a faint inkling here)
Adding an "org:" reference to any object needs to be authenticated by the "mnt-ref:" of the organisation object. Thanks again for your feedback. These are the issues we need to sort out before publishing the proposals. regards Denis Walker RIPE NCC
Yours, Elmar.
Hi all, Thanks Denis for the excellent job done. Of course agree on the line to have all the objects maintained. Just a comment more: don't forget that the core for us is not to have fields to store private data, but, probably, have one_field_more to get the owner authorization to publish them. So, the big problem is that we normally have contacts from our maintainers that aren't owners of all data maintained. The question is who get the responsability to put the "yes" in that field. This is a rule that, I think, we have to build. Cheers Manfredo -- Manfredo Miserocchi Network & Information Security Administration Mobile: +41 76 5708123 e-mail: mis@wari.net -- Warinet Global Services SA Via Soave, 2 CH-6901 Lugano Switzerland -- -----Original Message----- From: Denis Walker <denis@ripe.net> To: "Elmar K. Bins" <elmi@4ever.de> Cc: dp-tf@ripe.net Date: Mon, 11 Jun 2007 18:20:16 +0200 Subject: Re: [dp-tf] Quadlogy of person proposals
Hi Elmar
Thanks very much for your quick feedback. You raise some interesting points. But I think some of the issues may mean I did not explain my thoughts clearly enough in the proposals. My replies are inline below.
Elmar K. Bins wrote:
Hi Denis, hi group,
just a couple of comments that came to my mind.
[Maintaining (as many) objects (as possible)]
I consider it a splendid idea to have all DB objects maintained, so - I know who _must_ have once had knowledge about the object in question - I know where to go to have something updated / to inquire
Others may find the idea appealing in order to create a string of objects that belong together (amazing what you can find out about people/companies that way). That does seem to create other privacy issues.
From a public accountability point of view it may not be a bad idea to be able to find out some of this information. From a company point of view maybe some rationalisation is needed. Do companies really have 20 staff responsible for administering IP addresses, all of whom need to be publicly addressable? Or do some people just want to be in the RIPE Database (White Pages)? There are ways of using the database now to allow 20 people to work with the data, but only have one or two as the publicly accountable and contactable persons. The other 18 don't need to have there personal details in the database. If public accountability vs company confidentiality becomes an issue then we can look at that as a separate item.
The alternative of exempting person objects seems to be a good idea.
Not sure where this comes from. The proposals don't mention any exemption from being maintained. The only person exemption is from being deleted if in the white pages.
Anyway, the chicken-and-egg problem does persist with all solutions where I need the objects created at the same time, because the normal and desired way of creating objects in the RIPE-DB is by using the "AUTO-xxx" variable instead of a preassumed name (DW1, AARDVARK-MNT). That those in the know define their object names themselves after having checked them to be available doesn't help the others.
If we could use the object creation mechanism like the following, we can circumvent the chicken-and-egg problem. I have not tried it, so I'm not certain it will work already. If not, this could be item 2 in the proposal.
person: Denis Walker address: RIPE Network Coordination Centre (NCC) address: Singel 258 address: 1016 AB Amsterdam address: The Netherlands phone: +31 20 535 4444 nic-hdl: AUTO-1 mnt-by: AUTO-2 notify: denis@ripe.net changed: denis@ripe.net source: RIPE
mntner: AUTO-2 descr: Mntner for denis' objects. admin-c: AUTO-1 tech-c: AUTO-1 upd-to: denis@ripe.net auth: X509-1 notify: denis@ripe.net mnt-by: AUTO-2 referral-by: RIPE-DBM-MNT changed: denis@ripe.net source: RIPE
Apart from the creation issue I concur with this proposal. The
privacy issue can be circumvented, but with the ability of inverse lookups already built into the RIPE DB, this poses no _new_ issues.
[White pages]
I'm not certain if the RIPE NCC should create a new "phone directory" for "significant persons". Who defines significance, who decides whether
Although I have used 'real' data in the example, it is not the lack of AUTO- tags that causes the chicken and egg situation. The example you show below still has the chicken and egg. You have two objects, each with an auto generated name. But each object references the auto generated name from the other object. So which ever one you create first needs to reference the 'as yet not generated' name from the other object. linked-objects the
user-selected category applies,
This is why we introduced the idea of moderators as the RIPE NCC has no idea how to make these decisions.
who defines categories in the first place, who points out moderators?
We hope this will be a small list and perhaps WG chairs and co-chairs have been around long enough (and I say that in the nicest possible way :) ) to know who these 'significant people' are. If it becomes heavily used then we are talking about social networking. Then we need to look at alternative solutions (if we still think there is a problem here to be solved).
Concerning the moderation process...
- Is it really a good idea to have users send their maintainer password to a moderator? - Since a changed object needs re-signing, in the case of PGP or X.509 key security, the moderator needs the private keyring involved.
We do not advise anyone to send their passwords to other people. So that requires use of PGP. Now your other point shows a flaw in my logic, which I will correct in the proposal. The user will have to add the organisation reference to their person object, sign it and send it to the moderator. If the moderator approves it, they just need to sign it again and send it to the database.
- Alternatively the moderator can have special rights to the RIPE DB. Well.
This is not something we want to do.
- Can a user be kept from adding any org: attribute to an object? (That's not a rhetorical question, I couldn't find that it be checked, even though I have a faint inkling here)
Adding an "org:" reference to any object needs to be authenticated by the "mnt-ref:" of the organisation object.
Thanks again for your feedback. These are the issues we need to sort out before publishing the proposals.
regards Denis Walker RIPE NCC
Yours, Elmar.
Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario. Qualora il presente messaggio Le fosse pervenuto per errore, La invitiamo ad eliminarlo senza copiarlo ed a non inoltrarlo a terzi, dandocene gentilmente comunicazione. Grazie. You are hereby informed that this message contains confidential informations intended for the addressee's use only. If yu're not the addressee and have received this message by mistake, please delete it and immediately notify us. You may not copy or disseminate this message to anyone. Thank you.
Dear all,
Just a comment more: don't forget that the core for us is not to have fields to store private data, but, probably, have one_field_more to get the owner authorization to publish them.
So, the big problem is that we normally have contacts from our maintainers that aren't owners of all data maintained. The question is who get the responsability to put the "yes" in that field. This is a rule that, I think, we have to build.
Very good point. I think the best approach is to have the responsibilty reside with the maintainer. It would be good to have this in the service contract (i.e. the service contract should say that by putting a person object in the RIPE database, you acknowledge that you did get the approval of the person to publish his/her data). This is what we have in the .hu registration rules. As far as I remember, the GM is now authorized to change the service contract in such a way to be mandatory for all members (i.e. we do not have to have all members sign again). We should bring this up at the next GM. Of course this should be checked with the lawyers too. Best regards, Janos
Janos Zsako wrote:
Dear all,
Just a comment more: don't forget that the core for us is not to have fields to store private data, but, probably, have one_field_more to get the owner authorization to publish them.
So, the big problem is that we normally have contacts from our maintainers that aren't owners of all data maintained. The question is who get the responsability to put the "yes" in that field. This is a rule that, I think, we have to build.
I am not quite sure what you mean here. I 'think' you are saying you want some means of recording that you have permission to publish data in the RIPE Database that you do not own and indicating who has the responsibility for this data. Is that correct?
Very good point. I think the best approach is to have the responsibilty reside with the maintainer. It would be good to have this in the service contract (i.e. the service contract should say that by putting a person object in the RIPE database, you acknowledge that you did get the approval of the person to publish his/her data). This is what we have in the .hu registration rules.
Don't forget that not everyone who enters data into the RIPE Database is a member. So this statement may be better in the Database Terms and Conditions. cheers denis
As far as I remember, the GM is now authorized to change the service contract in such a way to be mandatory for all members (i.e. we do not have to have all members sign again). We should bring this up at the next GM. Of course this should be checked with the lawyers too.
Best regards, Janos
Denis,
think, we have to build.
I am not quite sure what you mean here. I 'think' you are saying you want some means of recording that you have permission to publish data in the RIPE Database that you do not own and indicating who has the responsibility for this data. Is that correct?
No, the answer is to interface us only with members. They have a contract with us ans they must get the responsability to give us permission to publish personal data.
Very good point. I think the best approach is to have the responsibilty reside with the maintainer. It would be good to have this in the service contract (i.e. the service contract should say that by putting a person object in the RIPE database, you acknowledge that you did get the approval of the person to publish his/her data). This is what we have in the .hu registration rules.
Don't forget that not everyone who enters data into the RIPE Database is a member. So this statement may be better in the Database Terms and Conditions.
Yes, but if we'll have all object maintained it seems that only members will do. cheers Manfredo Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario. Qualora il presente messaggio Le fosse pervenuto per errore, La invitiamo ad eliminarlo senza copiarlo ed a non inoltrarlo a terzi, dandocene gentilmente comunicazione. Grazie. You are hereby informed that this message contains confidential informations intended for the addressee's use only. If yu're not the addressee and have received this message by mistake, please delete it and immediately notify us. You may not copy or disseminate this message to anyone. Thank you.
Manfredo Miserocchi wrote:
Denis,
think, we have to build.
I am not quite sure what you mean here. I 'think' you are saying you want some means of recording that you have permission to publish data in the RIPE Database that you do not own and indicating who has the responsibility for this data. Is that correct?
No, the answer is to interface us only with members. They have a contract with us ans they must get the responsability to give us permission to publish personal data.
That is not going to work with the current database and business models. Also maintaining all data will not restrict data to members only. At the moment anyone can put data into the database. A student with nothing to do one afternoon can create person/mntner objects and enter all their friends details without permission. We have no contract with such a student. In that case a clause in the database T&C requiring consent would cover it. We also have lots of PI space holders who have no contract with the RIPE NCC and therefore can only be held to account by database T&C. There are also people in other regions who create aut-num and route objects with person/mntner objects in our database. We can't easily cover all of these people with a contract. A change to the standard contract may cover a large proportion of the database users. But the only way to cover them all is with the database T&C. cheers denis
Very good point. I think the best approach is to have the
responsibilty
reside with the maintainer. It would be good to have this in the
service
contract (i.e. the service contract should say that by putting a
person
object in the RIPE database, you acknowledge that you did get the approval of the person to publish his/her data). This is what we have in the
.hu
registration rules.
Don't forget that not everyone who enters data into the RIPE Database is a member. So this statement may be better in the Database Terms and Conditions.
Yes, but if we'll have all object maintained it seems that only members will do.
cheers Manfredo
Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario. Qualora il presente messaggio Le fosse pervenuto per errore, La invitiamo ad eliminarlo senza copiarlo ed a non inoltrarlo a terzi, dandocene gentilmente comunicazione. Grazie.
You are hereby informed that this message contains confidential informations intended for the addressee's use only. If yu're not the addressee and have received this message by mistake, please delete it and immediately notify us. You may not copy or disseminate this message to anyone. Thank you.
Denis,
That is not going to work with the current database and business models. Also maintaining all data will not restrict data to members only. At the moment anyone can put data into the database. A student with nothing to do one afternoon can create person/mntner objects and enter all their friends details without permission.
This is absolutely not safe and not compliant with our rules, before UE rules. We cannot have a system like that in the future. Is the GM informed about this hole ? We have no contract with such a
student. In that case a clause in the database T&C requiring consent would cover it.
We also have lots of PI space holders who have no contract with the RIPE
Yes, correct. This is another issue. We should obtain the authorization from the owner of the space. Or what else ? cheers Manfredo Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario. Qualora il presente messaggio Le fosse pervenuto per errore, La invitiamo ad eliminarlo senza copiarlo ed a non inoltrarlo a terzi, dandocene gentilmente comunicazione. Grazie. You are hereby informed that this message contains confidential informations intended for the addressee's use only. If yu're not the addressee and have received this message by mistake, please delete it and immediately notify us. You may not copy or disseminate this message to anyone. Thank you.
Manfredo Miserocchi wrote:
Denis,
That is not going to work with the current database and business models. Also maintaining all data will not restrict data to members only. At the moment anyone can put data into the database. A student with nothing to do one afternoon can create person/mntner objects and enter all their friends details without permission.
This is absolutely not safe and not compliant with our rules, before UE rules. We cannot have a system like that in the future. Is the GM informed about this hole ?
I agree that this is not safe from a data protection point of view. But this is not a 'hole'. This is fundamental to the way the RIPE Database was designed. It was built as an open, public database. Anyone can read it, anyone can write to it. To change that would require a major re-design. A work around will be in a later proposal on the regular cleanup process. We can't stop anyone from entering data into the database, but we can remove inappropriate data. My idea is to look for clusters of objects (person, role, mntner, key-cert, organisation) which form a self referencing group and have no connection to any operational data (like inetnum, route, etc). When such a cluster is recognised, delete the whole cluster of objects. This is possible, but also technically very difficult. It is outside the scope of the current set of proposals, but we do need to consider this as a follow on. cheers denis
We have no contract with such a
student. In that case a clause in the database T&C requiring consent would cover it.
We also have lots of PI space holders who have no contract with the RIPE
Yes, correct. This is another issue. We should obtain the authorization from the owner of the space. Or what else ?
cheers Manfredo
Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario. Qualora il presente messaggio Le fosse pervenuto per errore, La invitiamo ad eliminarlo senza copiarlo ed a non inoltrarlo a terzi, dandocene gentilmente comunicazione. Grazie.
You are hereby informed that this message contains confidential informations intended for the addressee's use only. If yu're not the addressee and have received this message by mistake, please delete it and immediately notify us. You may not copy or disseminate this message to anyone. Thank you.
Ok. Denis, So we've to return back in the task. Until we can get the appropriate authorization, we cannot publish any personal data. We need not to stop people to write into the database, even if this is not safe, but we do_need to stop people to read from the database what (any data) not properly authorized. cheers Manfredo
I agree that this is not safe from a data protection point of view. But this is not a 'hole'. This is fundamental to the way the RIPE Database was designed. It was built as an open, public database. Anyone can read it, anyone can write to it. To change that would require a major re-design.
A work around will be in a later proposal on the regular cleanup process. We can't stop anyone from entering data into the database, but we can remove inappropriate data. My idea is to look for clusters of objects (person, role, mntner, key-cert, organisation) which form a self referencing group and have no connection to any operational data (like inetnum, route, etc). When such a cluster is recognised, delete the whole cluster of objects. This is possible, but also technically very difficult. It is outside the scope of the current set of proposals, but we do need to consider this as a follow on.
cheers denis
We have no contract with such a
student. In that case a clause in the database T&C requiring consent would cover it.
We also have lots of PI space holders who have no contract with the RIPE
Yes, correct. This is another issue. We should obtain the
authorization
from the owner of the space. Or what else ?
cheers Manfredo
Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario. Qualora il presente messaggio Le fosse pervenuto per errore, La invitiamo ad eliminarlo senza copiarlo ed a non inoltrarlo a terzi, dandocene gentilmente comunicazione. Grazie.
You are hereby informed that this message contains confidential informations intended for the addressee's use only. If yu're not the addressee and have received this message by mistake, please delete it and immediately notify us. You may not copy or disseminate this message to anyone. Thank you.
Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario. Qualora il presente messaggio Le fosse pervenuto per errore, La invitiamo ad eliminarlo senza copiarlo ed a non inoltrarlo a terzi, dandocene gentilmente comunicazione. Grazie. You are hereby informed that this message contains confidential informations intended for the addressee's use only. If yu're not the addressee and have received this message by mistake, please delete it and immediately notify us. You may not copy or disseminate this message to anyone. Thank you.
Dear Manfredo,
So we've to return back in the task. Until we can get the appropriate authorization, we cannot publish any personal data. We need not to stop people to write into the database, even if this is not safe, but we do_need to stop people to read from the database what (any data) not properly authorized.
Correct. This is what may eventually happen in the worst case, if DP people (authorities) ask us to do that. However, I do not think we should target to have this kind of behaviour, as this would render the RIPE DB useless, like a Write Only memory. :) Best regards, Janos
Janos,
However, I do not think we should target to have this kind of behaviour, as this would render the RIPE DB useless, like a Write Only memory. :)
Of course, this is not what I intended. Not every data are considered "personal". We only have to read-protect those; and are few fields. Cheers Manfredo Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario. Qualora il presente messaggio Le fosse pervenuto per errore, La invitiamo ad eliminarlo senza copiarlo ed a non inoltrarlo a terzi, dandocene gentilmente comunicazione. Grazie. You are hereby informed that this message contains confidential informations intended for the addressee's use only. If yu're not the addressee and have received this message by mistake, please delete it and immediately notify us. You may not copy or disseminate this message to anyone. Thank you.
Manfredo Miserocchi wrote:
Janos,
However, I do not think we should target to have this kind of behaviour, as this would render the RIPE DB useless, like a Write Only memory. :)
Of course, this is not what I intended. Not every data are considered "personal". We only have to read-protect those; and are few fields.
We are entering very tricky ground here. There has always been a strong resistance to having any 'hidden' fields in the database. Perhaps we need a brainstorming session on this sometime. I have many 'wild ideas' in this area. One example would be to hide all email addresses and operate a mail forwarding service. Our IT department say that is technically feasible. But it is a fundamental shift in business practise. There are many things that can be done technically (although not all are easy to do). But often a technical solution also requires a change in thinking and usage as well. I think this is getting well outside the scope of the current proposals. Can I suggest we continue this 'fundamental' discussion when we meet in July. cheers denis
Cheers Manfredo
Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario. Qualora il presente messaggio Le fosse pervenuto per errore, La invitiamo ad eliminarlo senza copiarlo ed a non inoltrarlo a terzi, dandocene gentilmente comunicazione. Grazie.
You are hereby informed that this message contains confidential informations intended for the addressee's use only. If yu're not the addressee and have received this message by mistake, please delete it and immediately notify us. You may not copy or disseminate this message to anyone. Thank you.
On Thu, 14 Jun 2007, Janos Zsako wrote: Hi,
Dear Manfredo,
So we've to return back in the task. Until we can get the appropriate authorization, we cannot publish any personal data. We need not to stop people to write into the database, even if this is not safe, but we do_need to stop people to read from the database what (any data) not properly authorized.
I wonder what authorization is from the point of view of the law. In Russian DP act it is said, any personal data cannot be published without written consent of the data subject. The 'written consent' consists of 6 points including (besides name-address-tel etc) passport No with date of issue, aim of processing data, list of data which can be processed, list of operations the data should undergo, terms of the consent given. Had it been said that written consent could be replaced by authorization scheme, it would be OK. But it had not.
Correct. This is what may eventually happen in the worst case, if DP people (authorities) ask us to do that.
However, I do not think we should target to have this kind of behaviour, as this would render the RIPE DB useless, like a Write Only memory. :)
Best regards, Janos
With respect, Larisa Yurkina --- RIPN Registry center -----
Dear Larisa, Let me understand correctly what you say. You are saying that we may not invent new authorization rules, as these are laid down by the law already (and may not be changed). I think this (inventing new rules) is not what Manfredo (or I) suggested. What I said is that by some contract/agreement with the data maintainer (from RIPE DB point of view) we can make sure that personal data is not entered in the RIPE database without proper authorization (i.e. without the authorization required by the law, whatever that may be). Should a problem occur (e.g. the person complains, or the authorities ask for evidence of the authorization) then the RIPE NCC, based on the abovementioned contract can ask the maintainer to provide such evidence. If this is not available, based on the contract terms, the RIPE NCC may delete the illegal data (and may take further steps, like withdrawing the right of that particular maintainer to put data in the database, if such a clause exists in the contract). This is why it is important to have this contract/agreement in place with the data maintainer. I hope this clarifies the situation. Best regards, Janos
So we've to return back in the task. Until we can get the appropriate authorization, we cannot publish any personal data. We need not to stop people to write into the database, even if this is not safe, but we do_need to stop people to read from the database what (any data) not properly authorized.
I wonder what authorization is from the point of view of the law.
In Russian DP act it is said, any personal data cannot be published without written consent of the data subject. The 'written consent' consists of 6 points including (besides name-address-tel etc) passport No with date of issue, aim of processing data, list of data which can be processed, list of operations the data should undergo, terms of the consent given.
Had it been said that written consent could be replaced by authorization scheme, it would be OK. But it had not.
Correct. This is what may eventually happen in the worst case, if DP people (authorities) ask us to do that.
However, I do not think we should target to have this kind of behaviour, as this would render the RIPE DB useless, like a Write Only memory. :)
Best regards, Janos
With respect, Larisa Yurkina --- RIPN Registry center -----
Hi Janos and Larissa, zsako@3c-hungary.hu (Janos Zsako) wrote:
You are saying that we may not invent new authorization rules, as these are laid down by the law already (and may not be changed).
As long as there is no unified european law governing this, the RIPE NCC and all contracts it makes are by default governed by dutch law. There are cases where special contracts need to be made, governed by another country's law (e.g., russian federation). Nonetheless, as long as there is no such european general law that applies to the RIPE NCC, the RIPE NCC is free to create agreements that are legal under dutch law. What special laws any country within RIPE's region creates or doesn't is entirely irrelevant to the RIPE NCC's course _unless_ there is a special contract governed by that country's law. So, in order to follow Larissa's argument, the RIPE NCC would have to create special/different contracts for contractors from different countries, if the parties need the contract to be governed by that country's laws. I'm quite humble in legal matters, so if what I write above is crap, discard it. But to me the problem of international contracts breaks down to the simple thing of having an encompassing law or not. Yours, Elmar. -- "Hinken ist kein Mangel eines Vergleichs, sondern sollte als wesentliche Eigenschaft von Vergleichen angesehen werden." (Marius Fränzel in desd) --------------------------------------------------------------[ ELMI-RIPE ]---
On Fri, 15 Jun 2007, Elmar K. Bins wrote: Hi Elmar,
Hi Janos and Larissa,
zsako@3c-hungary.hu (Janos Zsako) wrote:
You are saying that we may not invent new authorization rules, as these are laid down by the law already (and may not be changed).
As long as there is no unified european law governing this, the RIPE NCC and all contracts it makes are by default governed by dutch law.
Right. EU Directive will be also OK. Let's look if the RIPE Database rules comly with it. For example, Section II, "CRITERIA FOR MAKING DATA PROCESSING LEGITIMATE" 1. Member States shall provide that personal data may be processed only if: (a) the data subject has unambiguously given his consent; or No. admin-c and tech-c are mandatory, without any personal consent (b) processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract; or Contract (SSA) says nothing about pers. data protection at the moment. (c) processing is necessary for compliance with a legal obligation to which the controller is subject; what a legal obligationis here, unclear. A loyer needed. If in the sence of Policy ripe document "The RIPE NCC is responsible for the allocation and assignment of Internet Protocol (IP) address space, Autonomous System Numbers (ASNs) and the management of reverse domain names within this region..." RIPE NCC can fulfil it's obligations without personal data publishing in the whois. We do not need person nic-hdl entering resource objects into the db, mntner is enough. To get approval from the hostmaster, we don't need to open data to everybody, it would be enough to keep them on the lir portal. If smbody want to get in touch because of spam etc, there is "remarks" in the inetnum and others objects etc. What else? So, how my personal data help the RIPE NCC to fulfil obligations? (d) processing is necessary in order to protect the vital interests of the data subject; or No (e) processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller or in a third party to whom the data are disclosed; or No (f) processing is necessary for the purposes of the legitimate interests pursued by the controller or by the third party or parties to whom the data are disclosed,<...> Legitimate interests also will do without personal data in "admin-c" or "tech-c", which could be easily filled in with e-mail of org or tel number with the same effect. Thats'all. So, WHAT MAKES PERSONAL DATA PROCESSING IN THE RIPE DB LEGITIMATE? :))
There are cases where special contracts need to be made, governed by another country's law (e.g., russian federation).
Nonetheless, as long as there is no such european general law that applies to the RIPE NCC, the RIPE NCC is free to create agreements that are legal under dutch law. What special laws any country within RIPE's region creates or doesn't is entirely irrelevant to the RIPE NCC's course _unless_ there is a special contract governed by that country's law.
So, in order to follow Larissa's argument, the RIPE NCC would have to create special/different contracts for contractors from different countries, if the parties need the contract to be governed by that country's laws.
I'm quite humble in legal matters, so if what I write above is crap, discard it. But to me the problem of international contracts breaks down to the simple thing of having an encompassing law or not.
Yours, Elmar.
--
"Hinken ist kein Mangel eines Vergleichs, sondern sollte als wesentliche Eigenschaft von Vergleichen angesehen werden." (Marius FrДnzel in desd)
--------------------------------------------------------------[ ELMI-RIPE ]---
With respect, Larisa Yurkina --- RIPN Registry center -----
Dear Larisa,
Let's look if the RIPE Database rules comly with it. For example, Section II, "CRITERIA FOR MAKING DATA PROCESSING LEGITIMATE"
1. Member States shall provide that personal data may be processed only if: (a) the data subject has unambiguously given his consent; or
No. admin-c and tech-c are mandatory, without any personal consent
I am not sure this is the right way of putting it. Yes, admin-c and tech-c _are_ mandatory, however, nobody says you may (or even worse: you should) publish such data without the given person's consent. In fact we never did so, and I am sure many other people did not do so either. The idea is that you have to find a person who consents to this, and only publish his/her data.
So, WHAT MAKES PERSONAL DATA PROCESSING IN THE RIPE DB LEGITIMATE?
I think you are right, the only paragraph that may apply is (a) above. What we have to make sure is that people act in accordance with it. Best regards, Janos
On Fri, 15 Jun 2007, Janos Zsako wrote: Hi Janos,
Dear Larisa,
Let's look if the RIPE Database rules comly with it. For example, Section II, "CRITERIA FOR MAKING DATA PROCESSING LEGITIMATE"
1. Member States shall provide that personal data may be processed only if: (a) the data subject has unambiguously given his consent; or
No. admin-c and tech-c are mandatory, without any personal consent
I am not sure this is the right way of putting it. Yes, admin-c and tech-c _are_ mandatory, however, nobody says you may (or even worse: you should) publish such data without the given person's consent. In fact we never did so, and I am sure many other people did not do so either.
ripe-252 states what contact information is: "details of people who are responsible for the operation of networks or routers, and those who are responsible for maintaining information in the RIPE Database." Or the person responsible for all that either not responsible. If the person is responsible, he/she must be published. If you have never did so, - very bad! :)
The idea is that you have to find a person who consents to this, and only publish his/her data.
So, WHAT MAKES PERSONAL DATA PROCESSING IN THE RIPE DB LEGITIMATE?
I think you are right, the only paragraph that may apply is (a) above. What we have to make sure is that people act in accordance with it.
Best regards, Janos
With respect, Larisa Yurkina --- RIPN Registry center -----
Dear Larisa,
Let's look if the RIPE Database rules comly with it. For example, Section II, "CRITERIA FOR MAKING DATA PROCESSING LEGITIMATE"
1. Member States shall provide that personal data may be processed only if: (a) the data subject has unambiguously given his consent; or
No. admin-c and tech-c are mandatory, without any personal consent
I am not sure this is the right way of putting it. Yes, admin-c and tech-c _are_ mandatory, however, nobody says you may (or even worse: you should) publish such data without the given person's consent. In fact we never did so, and I am sure many other people did not do so either.
ripe-252 states what contact information is:
"details of people who are responsible for the operation of networks or routers, and those who are responsible for maintaining information in the RIPE Database."
Or the person responsible for all that either not responsible. If the person is responsible, he/she must be published.
Again, this is not the proper way to put it. Nobody can oblige you to breach the law. You have to publish the data of a person responsible for the operations/maintenance. If within an organization somebody does not accept to have his/her data published, they have to appoint an other person who assumes this responsibility and accepts to have his/her data published.
If you have never did so, - very bad! :)
What I said is: we never published personal data without the given person's consent. I do not think this was bad. :)
The idea is that you have to find a person who consents to this, and only publish his/her data.
So, WHAT MAKES PERSONAL DATA PROCESSING IN THE RIPE DB LEGITIMATE?
I think you are right, the only paragraph that may apply is (a) above. What we have to make sure is that people act in accordance with it.
Best regards, Janos
With respect, Larisa Yurkina --- RIPN Registry center -----
Janos, team, after listening to some "important" consumers of data kept in the RIPE DB, I am feeling strongly that e) does apply as well. And on the item of who's data (whatever set) to register as the repsonsible contact for a unique global resource: In principle the policy and procedure machinery does already provide for *not* involving the end user at all. ISPs are allowed to do self-assignments and still allow their customers to use those (potentially dynamilcally assigned) addresses. But, for the end user, it is a matter of either/or! You cannot keep your lunch and eat it at the same time. You cannot reasonably be expect to be listed as legitimate holder of a resource and remain anonymous at the same time. this is where "e)" comes in to the picture, imho. The only thing that *might* get us into trouble is the monopoly situation that trickles down from IANA to the RIRs and the LIRs. the last thing I'd want to suggest is portable addresses like in the phone world ;-) Wilfried. PS: when we designed the irt: object we already had the vision to cater for breaking the one-to-one relationship between holding resources and providing authoritative contact information for operational and abuse situations :-) Janos Zsako wrote:
Dear Larisa,
Let's look if the RIPE Database rules comly with it. For example, Section II, "CRITERIA FOR MAKING DATA PROCESSING LEGITIMATE"
1. Member States shall provide that personal data may be processed only if: (a) the data subject has unambiguously given his consent; or
No. admin-c and tech-c are mandatory, without any personal consent
I am not sure this is the right way of putting it. Yes, admin-c and tech-c _are_ mandatory, however, nobody says you may (or even worse: you should) publish such data without the given person's consent. In fact we never did so, and I am sure many other people did not do so either. The idea is that you have to find a person who consents to this, and only publish his/her data.
So, WHAT MAKES PERSONAL DATA PROCESSING IN THE RIPE DB LEGITIMATE?
I think you are right, the only paragraph that may apply is (a) above. What we have to make sure is that people act in accordance with it.
Best regards, Janos
Larisa, On 15 Jun 2007, at 1:16pm, Larisa A. Yurkina wrote: [...]
Right. EU Directive will be also OK. Let's look if the RIPE Database rules comly with it. For example, Section II, "CRITERIA FOR MAKING DATA PROCESSING LEGITIMATE"
1. Member States shall provide that personal data may be processed only if: (a) the data subject has unambiguously given his consent; or
No. admin-c and tech-c are mandatory, without any personal consent
It is possible to provide useful contact information without providing personal information. A self referential role object like this could be used and filled with non-personal data that allows contact from third parties when necessary: % This is the RIPE Whois query server #2. % The objects are in RPSL format. % % Rights restricted by copyright. % See http://www.ripe.net/db/copyright.html role: Test Role Object address: Anywhere e-mail: example@example.com admin-c: TRO5-RIPE tech-c: TRO5-RIPE nic-hdl: TRO5-RIPE changed: example@example.com 20070615 source: RIPE A person object could also be used, I suppose, although it might be confusing to have a person object that shows a role's name. I think the important thing is to carefully select the data that is published. Regards, -- Leo Vegoda IANA Numbers Liaison
Dear all,
As long as there is no unified european law governing this, the RIPE NCC and all contracts it makes are by default governed by dutch law.
This is my understanding as well. If we look at the problem from the RIPE NCC's point of view (and this is what we are doing now, and should be doing), then we have to make sure the RIPE NCC complies with the Dutch data protection law. If we look at the problem from the maintainer's point of view (e.g. a LIR), then they have to make sure they act in accordance with any contract/agreement they have with the RIPE NCC, AND in accordance with all legal requirements of the country they act in. In other words, if Russian law requires a _written_ consent to publish personal data, the Russian LIR will have to make sure they have such a document from their client, but it is not RIPE NCC's task to enforce this.
So, in order to follow Larissa's argument, the RIPE NCC would have to create special/different contracts for contractors from different countries, if the parties need the contract to be governed by that country's laws.
I do not think this should be done, for the reason above.
I'm quite humble in legal matters
:)) The same with me. :)) I am not a lawyer either. Best regards, Janos
Janos,
Dear all,
As long as there is no unified european law governing this, the RIPE NCC and all contracts it makes are by default governed by dutch law.
This is my understanding as well. If we look at the problem from the RIPE NCC's point of view (and this is what we are doing now, and should be doing),
Agreed then we have to make sure the RIPE NCC complies
with the Dutch data protection law.
Quite Correct. We have to make sure RIPE NCC complies with EU and Dutch data protection law, regarding at the more restrictive one.
If we look at the problem from the maintainer's point of view (e.g. a LIR), then they have to make sure they act in accordance with any contract/agreement they have with the RIPE NCC, AND in accordance with all legal requirements of the country they act in. In other words, if Russian law requires a _written_ consent to publish personal data, the Russian LIR will have to make sure they have such a document from their client, but it is not RIPE NCC's task to enforce this.
Agreed.
So, in order to follow Larissa's argument, the RIPE NCC would have to create special/different contracts for contractors from different countries, if the parties need the contract to be governed by that country's laws.
I do not think this should be done, for the reason above.
Absolutely not. Cheers Manfredo Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario. Qualora il presente messaggio Le fosse pervenuto per errore, La invitiamo ad eliminarlo senza copiarlo ed a non inoltrarlo a terzi, dandocene gentilmente comunicazione. Grazie. You are hereby informed that this message contains confidential informations intended for the addressee's use only. If yu're not the addressee and have received this message by mistake, please delete it and immediately notify us. You may not copy or disseminate this message to anyone. Thank you.
On Thu, 14 Jun 2007, Janos Zsako wrote:
Dear Larisa,
Dear Janos, thanks for your detailed explanation.
Let me understand correctly what you say.
You are saying that we may not invent new authorization rules, as these are laid down by the law already (and may not be changed).
Perhaps I was inexact in expression, i'm sorry. I didn't mean anything like that. On the contrary, protecting personal data you care about is exactly what is needed for the RIPE db to comply with the relevant Directive (art. 17, 'Security of processing'). Of course person object should be maintained properly, no doubt. But not only that. What I do care about is another aspect, see article, 6 (1): 1. Member States shall provide that personal data must be: (a) processed fairly and lawfully; To be 'fairly' pd should be protected, data subject should have access to his data for update etc. But to be 'lawfully' it should be processes and used exactly as the law says. Otherwise 'data controller's right to process data might appear disputable. To avoid that, i try to find if the 'written permission' could be equal to authorization, mntner etc., maybe some other law could be applied here, for ex, 'electronic signature' act. Maybe somebody could advise smth here?
I think this (inventing new rules) is not what Manfredo (or I) suggested.
What I said is that by some contract/agreement with the data maintainer (from RIPE DB point of view) we can make sure that personal data is not entered in the RIPE database without proper authorization (i.e. without the authorization required by the law, whatever that may be).
Should a problem occur (e.g. the person complains, or the authorities ask for evidence of the authorization) then the RIPE NCC, based on the abovementioned contract can ask the maintainer to provide such evidence. If this is not available, based on the contract terms, the RIPE NCC may delete the illegal data (and may take further steps, like withdrawing the right of that particular maintainer to put data in the database, if such a clause exists in the contract).
This is why it is important to have this contract/agreement in place with the data maintainer.
I hope this clarifies the situation.
Best regards, Janos
With respect, Larisa Yurkina --- RIPN Registry center -----
So we've to return back in the task. Until we can get the appropriate authorization, we cannot publish any personal data. We need not to stop people to write into the database, even if this is not safe, but we do_need to stop people to read from the database what (any data) not properly authorized.
I wonder what authorization is from the point of view of the law.
In Russian DP act it is said, any personal data cannot be published without written consent of the data subject. The 'written consent' consists of 6 points including (besides name-address-tel etc) passport No with date of issue, aim of processing data, list of data which can be processed, list of operations the data should undergo, terms of the consent given.
Had it been said that written consent could be replaced by authorization scheme, it would be OK. But it had not.
Correct. This is what may eventually happen in the worst case, if DP people (authorities) ask us to do that.
However, I do not think we should target to have this kind of behaviour, as this would render the RIPE DB useless, like a Write Only memory. :)
Best regards, Janos
With respect, Larisa Yurkina --- RIPN Registry center -----
[ apologies if this has been beaten to death in later messages. I am in catch-up and preparation mode for tomorrow :-) ] Manfredo Miserocchi wrote: [...]
Don't forget that not everyone who enters data into the RIPE Database is a member. So this statement may be better in the Database Terms and Conditions.
Yes, but if we'll have all object maintained it seems that only members will do.
Well, not for a looongf time, I guess, unless we take this as an "opportunity" to clean up all the relationship with all the legcy resource holders? :-O My feeling was that we would wnat to defer touching *that* can of worms till we have something in our hands that attracts them to the feeding station (i.e the resource certificates).
cheers Manfredo
Wilfried
Dear all,
Very good point. I think the best approach is to have the responsibilty reside with the maintainer. It would be good to have this in the service contract (i.e. the service contract should say that by putting a person object in the RIPE database, you acknowledge that you did get the approval of the person to publish his/her data). This is what we have in the .hu registration rules.
Don't forget that not everyone who enters data into the RIPE Database is a member. So this statement may be better in the Database Terms and Conditions.
You are right, I did not think about all these "exceptions". A good approach can be to have a clear statement in the contract with the LIRs that they are responsible for obtaining the permission to publish any personal data they maintain OR that are maintained by maintainers they created. This solves a large part of the problem. As we will require all objects to be maintained in the future, it seems enough for me to make sure we have the above principle accepted by the _maintainers_. We may have to think over the process of creating a new maintainer. We may have to have it created by an existing maintainer or by some otherwise authenticated person (who can then assume the responsibility for the data they maintain in the future). How does this sound? Best regards, Janos
zsako@3c-hungary.hu (Janos Zsako) wrote:
Don't forget that not everyone who enters data into the RIPE Database is a member. So this statement may be better in the Database Terms and Conditions.
A good approach can be to have a clear statement in the contract with the LIRs that they are responsible for obtaining the permission to publish any personal data they maintain OR that are maintained by maintainers they created. This solves a large part of the problem.
[...]
How does this sound?
Not different. A lot of maintainers do not belong to LIRs, so there is no contract. Elmar.
Dear Elmar,
Don't forget that not everyone who enters data into the RIPE Database is a member. So this statement may be better in the Database Terms and Conditions.
A good approach can be to have a clear statement in the contract with the LIRs that they are responsible for obtaining the permission to publish any personal data they maintain OR that are maintained by maintainers they created. This solves a large part of the problem.
[...]
How does this sound?
Not different. A lot of maintainers do not belong to LIRs, so there is no contract.
I was not clear enough, I suppose. I see three cases: 1. Maintainer is a LIR - we have a contract. 2. Maintainer created by LIR - bound by LIR contract. 3. Maintainer authorized/created by RIPE NCC - authenticated by RIPE NCC and bound by DB Terms and Conditions (you deleted the part that referred to this case, see below). Best regards, Janos As we will require all objects to be maintained in the future, it seems enough for me to make sure we have the above principle accepted by the _maintainers_. We may have to think over the process of creating a new maintainer. We may have to have it created by an existing maintainer or by some otherwise authenticated person (who can then assume the responsibility for the data they maintain in the future).
Hi Janos, zsako@3c-hungary.hu (Janos Zsako) wrote:
Not different. A lot of maintainers do not belong to LIRs, so there is no contract.
I was not clear enough, I suppose. I see three cases:
1. Maintainer is a LIR - we have a contract.
Agreed, that's easy.
2. Maintainer created by LIR - bound by LIR contract.
Not agreed. A lot of maintainers are pretty old, the link to the LIR (who may as well have gone out of business years ago) is not necessarily existent anymore. Moreover, a lot of maintainers have been created in order to relieve the LIR of the maintainance of customer objects (for customers who want to do that themselves). And, on another leg entirely, there isn't necessarily a special contract between LIR and customer that covers RIPE DB updates / maintainer issues. I don't see how the maintainer's owner would be bound by RIPE-LIR contracts.
3. Maintainer authorized/created by RIPE NCC - authenticated by RIPE NCC and bound by DB Terms and Conditions (you deleted the part that referred to this case, see below).
I tend to shorten the stuff I quote a lot - sometimes the scissors are too sharp - sorry for that. Nonetheless, there would then have to be a contract or agreement between maintainer holder and the RIPE NCC, and that's a hard case to make, if the RIPE NCC _insists_ on creating a maintainer for some reason, but the holder doesn't want to sign agreements.
As we will require all objects to be maintained in the future, it seems enough for me to make sure we have the above principle accepted by the _maintainers_. We may have to think over the process of creating a new maintainer. We may have to have it created by an existing maintainer or by some otherwise authenticated person (who can then assume the responsibility for the data they maintain in the future).
You will not be able to reach all (or even a majority) of maintainers in your lifetime. This is a hopeless case, I'm afraid. If you are happy with like 50%, then it's doable. Yours, Elmar.
Dear Elmar,
2. Maintainer created by LIR - bound by LIR contract.
Not agreed. A lot of maintainers are pretty old, the link to the LIR (who may as well have gone out of business years ago) is not necessarily existent anymore. Moreover, a lot of maintainers have been created in order to relieve the LIR of the maintainance of customer objects (for customers who want to do that themselves). And, on another leg entirely, there isn't necessarily a special contract between LIR and customer that covers RIPE DB updates / maintainer issues. I don't see how the maintainer's owner would be bound by RIPE-LIR contracts.
You are right. I was thinking here mainly of the future (i.e. not about the already existing objects). A way to solve the problem of old objects is to keep track of maintainers we know are bound by a contract and those that are not. Eventually, we may have to treat in some special way those personal objects that are not maintained by maintainers bound by a contract. For example we may have to hide them, delete them, etc. Probably hiding the data is better, as we can re-publish it if we can get the contract with the maintainer.
You will not be able to reach all (or even a majority) of maintainers in your lifetime. This is a hopeless case, I'm afraid.
I fully agree with you. This is somewhat similar to signing the new service contract with all members. In last phase we still had 2-3% of the existing members who did not give any sign of life and we had to cancel the contract with them. I think we can have a similar approach here, we will eventually have to delete "doubtful" data, i.e. data we are not sure we arte allowed to keep in the database.
If you are happy with like 50%, then it's doable.
I am afraid we have no other choice. Best regards, Janos
Janos, All,
there isn't necessarily a special contract between LIR and customer that covers RIPE DB updates / maintainer issues. I don't see how the maintainer's owner would be bound by RIPE-LIR contracts.
You are right. I was thinking here mainly of the future (i.e. not about the already existing objects).
A way to solve the problem of old objects is to keep track of maintainers we know are bound by a contract and those that are not.
Eventually, we may have to treat in some special way those personal objects that are not maintained by maintainers bound by a contract. For example we may have to hide them, delete them, etc. Probably hiding the data is better, as we can re-publish it if we can get the contract with the maintainer.
Absolutely agreed. We have to hide what we cannot manage. Cheers Manfredo Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario. Qualora il presente messaggio Le fosse pervenuto per errore, La invitiamo ad eliminarlo senza copiarlo ed a non inoltrarlo a terzi, dandocene gentilmente comunicazione. Grazie. You are hereby informed that this message contains confidential informations intended for the addressee's use only. If yu're not the addressee and have received this message by mistake, please delete it and immediately notify us. You may not copy or disseminate this message to anyone. Thank you.
Janos, all,
Very good point. I think the best approach is to have the responsibilty reside with the maintainer. It would be good to have this in the service contract
I'm afraid it will be mandatory (i.e. the service contract should say that by putting a person
object in the RIPE database, you acknowledge that you did get the approval of the person to publish his/her data). This is what we have in the .hu registration rules.
In the .it TLD we have something similar, and all maintainers have a private web interface to put the famous "yes/no" into the field. I think we can borrow the idea from them in our LIR portal.
As far as I remember, the GM is now authorized to change the service contract in such a way to be mandatory for all members
Correct (i.e. we do not have to
have all members sign again).
No, please !!! We should bring this up at the next GM. Of
course this should be checked with the lawyers too.
Agreed Cheers Manfredo Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario. Qualora il presente messaggio Le fosse pervenuto per errore, La invitiamo ad eliminarlo senza copiarlo ed a non inoltrarlo a terzi, dandocene gentilmente comunicazione. Grazie. You are hereby informed that this message contains confidential informations intended for the addressee's use only. If yu're not the addressee and have received this message by mistake, please delete it and immediately notify us. You may not copy or disseminate this message to anyone. Thank you.
On Wed, 13 Jun 2007, Janos Zsako wrote:
Dear all,
Just a comment more: don't forget that the core for us is not to have fields to store private data, but, probably, have one_field_more to get the owner authorization to publish them.
So, the big problem is that we normally have contacts from our maintainers that aren't owners of all data maintained. The question is who get the responsability to put the "yes" in that field. This is a rule that, I think, we have to build.
Very good point. I think the best approach is to have the responsibilty reside with the maintainer. It would be good to have this in the service contract (i.e. the service contract should say that by putting a person object in the RIPE database, you acknowledge that you did get the approval of the person to publish his/her data). This is what we have in the .hu registration rules.
in the .ru registration rules we had approximately the same, untill a Pers.data act was issued about half a year ago. Act states that a person have right to keep his/her data secret, even if he/she is resonsible for the resourse. It means that person is not mandatory anymore, a problem of access to the resp. party arises. I'm afraid, a person object in the RIPE database is very much the same, like TLD registrar the RIPE NCC may face the necessity to legally prove their right to openly publish smbd's personal data.
As far as I remember, the GM is now authorized to change the service contract in such a way to be mandatory for all members (i.e. we do not have to have all members sign again). We should bring this up at the next GM. Of course this should be checked with the lawyers too.
Best regards, Janos
With respect, Larisa Yurkina --- RIPN Registry center -----
Larisa A. Yurkina wrote:
On Wed, 13 Jun 2007, Janos Zsako wrote:
Dear all,
Just a comment more: don't forget that the core for us is not to have fields to store private data, but, probably, have one_field_more to get the owner authorization to publish them.
So, the big problem is that we normally have contacts from our maintainers that aren't owners of all data maintained. The question is who get the responsability to put the "yes" in that field. This is a rule that, I think, we have to build.
Very good point. I think the best approach is to have the responsibilty reside with the maintainer. It would be good to have this in the service contract (i.e. the service contract should say that by putting a person object in the RIPE database, you acknowledge that you did get the approval of the person to publish his/her data). This is what we have in the .hu registration rules.
in the .ru registration rules we had approximately the same, untill a Pers.data act was issued about half a year ago. Act states that a person have right to keep his/her data secret, even if he/she is resonsible for the resourse. It means that person is not mandatory anymore, a problem of access to the resp. party arises. I'm afraid, a person object in the RIPE database is very much the same, like TLD registrar the RIPE NCC may face the necessity to legally prove their right to openly publish smbd's personal data.
There are some interesting issues coming from these discussions. Maybe a more basic question about personal data is why do we need it? Is it for accountability, contactability or both? If some of it is there for accountability only, then it is questionable if it needs to be publicly displayed. For contactability maybe we should give people a choice of how they wish to be contacted and levels of access to that information. If they choose email only, we can hide emails and provide a mail forwarding service. Maybe they could provide a phone number but specify it is to be available to members only and not the whole public. It is certainly questionable if an ISPs customers need to be contactable by the general public. Most of them are not going to be any help solving network problems either. Maybe these need to be only accountable and therefore not displayed publicly. So before we go too far down the road on issues of authentication, authorisation, permissions and contracts, maybe we need to answer these basic questions: * what personal data do we need * who needs access to it and by what means * what do we need it for We are trying to address these questions in the privacy statement, but in a general way. If we can really focus in on these questions and comprehensively answer them, all the other issues will flow out of this. cheers denis
As far as I remember, the GM is now authorized to change the service contract in such a way to be mandatory for all members (i.e. we do not have to have all members sign again). We should bring this up at the next GM. Of course this should be checked with the lawyers too.
Best regards, Janos
With respect, Larisa Yurkina --- RIPN Registry center -----
On Fri, 15 Jun 2007, Denis Walker wrote:
Larisa A. Yurkina wrote:
On Wed, 13 Jun 2007, Janos Zsako wrote:
Dear all,
Just a comment more: don't forget that the core for us is not to have fields to store private data, but, probably, have one_field_more to get the owner authorization to publish them.
So, the big problem is that we normally have contacts from our maintainers that aren't owners of all data maintained. The question is who get the responsability to put the "yes" in that field. This is a rule that, I think, we have to build.
Very good point. I think the best approach is to have the responsibilty reside with the maintainer. It would be good to have this in the service contract (i.e. the service contract should say that by putting a person object in the RIPE database, you acknowledge that you did get the approval of the person to publish his/her data). This is what we have in the .hu registration rules.
in the .ru registration rules we had approximately the same, untill a Pers.data act was issued about half a year ago. Act states that a person have right to keep his/her data secret, even if he/she is resonsible for the resourse. It means that person is not mandatory anymore, a problem of access to the resp. party arises. I'm afraid, a person object in the RIPE database is very much the same, like TLD registrar the RIPE NCC may face the necessity to legally prove their right to openly publish smbd's personal data.
There are some interesting issues coming from these discussions. Maybe a more basic question about personal data is why do we need it? Is it for accountability, contactability or both?
If some of it is there for accountability only, then it is questionable if it needs to be publicly displayed. For contactability maybe we should give people a choice of how they wish to be contacted and levels of access to that information. If they choose email only, we can hide emails and provide a mail forwarding service. Maybe they could provide a phone number but specify it is to be available to members only and not the whole public.
It is certainly questionable if an ISPs customers need to be contactable by the general public. Most of them are not going to be any help solving network problems either. Maybe these need to be only accountable and therefore not displayed publicly.
So before we go too far down the road on issues of authentication, authorisation, permissions and contracts, maybe we need to answer these basic questions:
* what personal data do we need * who needs access to it and by what means * what do we need it for
one more question, sorry do wee really need it
We are trying to address these questions in the privacy statement, but in a general way. If we can really focus in on these questions and comprehensively answer them, all the other issues will flow out of this.
cheers denis
As far as I remember, the GM is now authorized to change the service contract in such a way to be mandatory for all members (i.e. we do not have to have all members sign again). We should bring this up at the next GM. Of course this should be checked with the lawyers too.
Best regards, Janos
With respect, Larisa Yurkina --- RIPN Registry center -----
With respect, Larisa Yurkina --- RIPN Registry center -----
Denis, On 15 Jun 2007, at 12:44pm, Denis Walker wrote: [...]
So before we go too far down the road on issues of authentication, authorisation, permissions and contracts, maybe we need to answer these basic questions:
* what personal data do we need * who needs access to it and by what means * what do we need it for
Surely this last question should be considered before the other two. Depending on the answer to it the other two many not apply at all. For instance, if the main purpose is to provide contact information to third parties who many need it for network troubleshooting purposes, role information may be sufficient and personal data is not needed at all. That would eliminate the need for the first question. Regards, -- Leo Vegoda IANA Numbers Liaison
On Fri, 15 Jun 2007, Leo Vegoda wrote:
Denis,
On 15 Jun 2007, at 12:44pm, Denis Walker wrote:
[...]
So before we go too far down the road on issues of authentication, authorisation, permissions and contracts, maybe we need to answer these basic questions:
* what personal data do we need * who needs access to it and by what means * what do we need it for
Surely this last question should be considered before the other two. Depending on the answer to it the other two many not apply at all. For instance, if the main purpose is to provide contact information to third parties who many need it for network troubleshooting purposes, role information may be sufficient and personal data is not needed at all. That would eliminate the need for the first question.
Right, the Directive states the same thing: ... personal data must be: (b) collected for specified, explicit and legitimate purposes and not further processed in a way incompatible with those purposes. there also is a next point: (c) adequate, relevant and not excessive in relation to the purposes for which they are collected and/or further processed; Please note, "not excessive". Don't you think that person object exactly falls under "excessive" category?
Regards,
-- Leo Vegoda IANA Numbers Liaison
With respect, Larisa Yurkina --- RIPN Registry center -----
Larisa A. Yurkina wrote: [...]
there also is a next point: (c) adequate, relevant and not excessive in relation to the purposes for which they are collected and/or further processed;
Please note, "not excessive". Don't you think that person object exactly falls under "excessive" category?
No, I don't. Assuming that keeping track of globally unique resources and keeping the DB populated and up-to-date is a reason for operating under "e)".
Regards,
-- Leo Vegoda IANA Numbers Liaison
With respect, Larisa Yurkina --- RIPN Registry center -----
Wilfried.
Leo Vegoda wrote:
Denis,
On 15 Jun 2007, at 12:44pm, Denis Walker wrote:
[...]
So before we go too far down the road on issues of authentication, authorisation, permissions and contracts, maybe we need to answer these basic questions:
* what personal data do we need * who needs access to it and by what means * what do we need it for
Surely this last question should be considered before the other two. Depending on the answer to it the other two many not apply at all. For instance, if the main purpose is to provide contact information to third parties who many need it for network troubleshooting purposes, role information may be sufficient and personal data is not needed at all. That would eliminate the need for the first question.
This is why I think we should focus attention first of all on these questions. But I don't think this is a simple as it looks. Maybe the original wording of policies said we need contact information for troubleshooting. The world has moved on a lot since then. Now accountability is also important. Governments and LEAs want to know "who" is responsible for Internet resources. A faceless role object will not be good enough. cheers Denis RIPE NCC
Regards,
--Leo Vegoda IANA Numbers Liaison
On 15 Jun 2007, at 4:26pm, Denis Walker wrote: [...]
This is why I think we should focus attention first of all on these questions. But I don't think this is a simple as it looks. Maybe the original wording of policies said we need contact information for troubleshooting. The world has moved on a lot since then. Now accountability is also important. Governments and LEAs want to know "who" is responsible for Internet resources.
I agree.
A faceless role object will not be good enough.
I doubt person objects would be, either. That's what organisation objects, do. Regards, -- Leo Vegoda IANA Numbers Liaison
Leo Vegoda wrote:
On 15 Jun 2007, at 4:26pm, Denis Walker wrote:
[...]
This is why I think we should focus attention first of all on these questions. But I don't think this is a simple as it looks. Maybe the original wording of policies said we need contact information for troubleshooting. The world has moved on a lot since then. Now accountability is also important. Governments and LEAs want to know "who" is responsible for Internet resources.
I agree.
A faceless role object will not be good enough.
I doubt person objects would be, either. That's what organisation objects, do.
The "who" is probably the enduser. This is often a customer of an ISP. They will not have an organisation object. If we drop person objects, the full picture is split over many databases. An LEA has to go to the RIPE Database with a list of IP addresses. Find the organisations, then go to the individual organisations to find the "who" from their customer databases. It is better to keep this full picture in the RIPE Database. But maybe it does not all need to be publicly visible. cheers denis RIPE NCC
Regards,
--Leo Vegoda IANA Numbers Liaison
On 15 Jun 2007, at 4:37pm, Denis Walker wrote: [...]
accountability is also important. Governments and LEAs want to know "who" is responsible for Internet resources.
I agree.
A faceless role object will not be good enough.
I doubt person objects would be, either. That's what organisation objects, do.
The "who" is probably the enduser. This is often a customer of an ISP. They will not have an organisation object.
If they're a domestic user with a /32 then there's no need to register their assignment and the police have to ask the ISP for details. If they are a small business with a small assignment of /29 or shorter then a role object with the full business name and possibly a postal address for the business premises will give enough information. I don't understand what value is added by asking a person to put their name and personal contact information in the database in such a situation.
If we drop person objects, the full picture is split over many databases. An LEA has to go to the RIPE Database with a list of IP addresses. Find the organisations, then go to the individual organisations to find the "who" from their customer databases.
I'm suggesting that personal identifying information is probably not necessary for most small network operators. I'm not suggesting that no contact information should be provided at all. However, I really think that this discussion is premature and should only be addressed once we have identified the database's purpose(s). Regards, -- Leo Vegoda IANA Numbers Liaison
On Fri, 15 Jun 2007, Leo Vegoda wrote: Hi Leo,
On 15 Jun 2007, at 4:37pm, Denis Walker wrote:
[...]
accountability is also important. Governments and LEAs want to know "who" is responsible for Internet resources.
I agree.
A faceless role object will not be good enough.
I doubt person objects would be, either. That's what organisation objects, do.
The "who" is probably the enduser. This is often a customer of an ISP. They will not have an organisation object.
If they're a domestic user with a /32 then there's no need to register their assignment and the police have to ask the ISP for details. If they are a small business with a small assignment of /29 or shorter then a role object with the full business name and possibly a postal address for the business premises will give enough information. I don't understand what value is added by asking a person to put their name and personal contact information in the database in such a situation.
Nithher do I.
If we drop person objects, the full picture is split over many databases. An LEA has to go to the RIPE Database with a list of IP addresses. Find the organisations, then go to the individual organisations to find the "who" from their customer databases.
I'm suggesting that personal identifying information is probably not necessary for most small network operators. I'm not suggesting that no contact information should be provided at all.
Agree. Contact information is enough when you need contact in case of troubleshooting. No matter whether it is personal or impersonal, if only 'alive'. Personal identifying information you only need for legal action against person doing smth illegal which cause damage to you. Only contractual basis of getting IPs could possibly help to identify violator. Contract is only possible between either legal entity or legal persons. Whois is unable to ensure legality. It can only contain reference to contact who should be aware of legal entity or legal person holding IP. No matter, again, whether the contact is personal or not.
However, I really think that this discussion is premature and should only be addressed once we have identified the database's purpose(s).
Regards,
-- Leo Vegoda IANA Numbers Liaison
With respect, Larisa Yurkina --- RIPN Registry center -----
Leo Vegoda wrote:
On 15 Jun 2007, at 4:26pm, Denis Walker wrote:
[...]
This is why I think we should focus attention first of all on these questions. But I don't think this is a simple as it looks. Maybe the original wording of policies said we need contact information for troubleshooting. The world has moved on a lot since then. Now accountability is also important. Governments and LEAs want to know "who" is responsible for Internet resources.
I agree.
A faceless role object will not be good enough.
I doubt person objects would be, either. That's what organisation objects, do.
Maybe, but in many cases it would simply shift the problem from the left hand to the right hand. Take my case at home: I have been assigned 8 addresses for my ADSL connection by my Telekom Op. With your approach I could easily hide my personal contact information because that can/has to go into "my" organisation: object. In the end it is the same set of (personal) information under a different heading. If that approach gets us out from unerneath the PD rules, fine with me :-) But I am not convinced...
Regards,
-- Leo Vegoda IANA Numbers Liaison
Wilfried.
On 17 Jul 2007, at 14:04, Wilfried Woeber, UniVie/ACOnet wrote: [...]
I doubt person objects would be, either. That's what organisation objects, do.
Maybe, but in many cases it would simply shift the problem from the left hand to the right hand. Take my case at home:
I have been assigned 8 addresses for my ADSL connection by my Telekom Op.
With your approach I could easily hide my personal contact information because that can/has to go into "my" organisation: object. In the end it is the same set of (personal) information under a different heading.
There is an inevitable tension between the needs of LEAs and the rules set down in data protection legislation. Unless there is a law requiring contact information for consumer customers to be entered into the RIPE database I would encourage us to set policies that comply with data protection laws. I think that in the vast majority of cases there is no need to list a contact from the customer end of a DSL or other consumer service. Noting that the assignment has been made is important but identifying the contact information is unlikely to be helpful in most situations. Listing the ISP's contact information is the right approach in the majority of cases, I think. The ISP obviously knows the end user's contact information and can supply it when appropriate. Regards, Leo
Leo Vegoda wrote:
On 17 Jul 2007, at 14:04, Wilfried Woeber, UniVie/ACOnet wrote:
[...]
I doubt person objects would be, either. That's what organisation objects, do.
Maybe, but in many cases it would simply shift the problem from the left hand to the right hand. Take my case at home:
I have been assigned 8 addresses for my ADSL connection by my Telekom Op.
With your approach I could easily hide my personal contact information because that can/has to go into "my" organisation: object. In the end it is the same set of (personal) information under a different heading.
There is an inevitable tension between the needs of LEAs and the rules set down in data protection legislation. Unless there is a law requiring contact information for consumer customers to be entered into the RIPE database I would encourage us to set policies that comply with data protection laws.
I think that in the vast majority of cases there is no need to list a contact from the customer end of a DSL or other consumer service. Noting that the assignment has been made is important but identifying the contact information is unlikely to be helpful in most situations. Listing the ISP's contact information is the right approach in the majority of cases, I think. The ISP obviously knows the end user's contact information and can supply it when appropriate.
I see some conflict here between your right not to be identified and my right to know who is spamming me. Maybe I want to complain directly to the spammer. But if I have to go to the ISP and ask them to identify the end user they may just say "sorry we can't give out confidential customer information". Then I have to go to court of the police to even write a letter of complaint to the spammer. The RIPE DB is a registry of IP Address information. If we hide the bottom layer we change the whole concept. cheers denis
Regards,
Leo
Denis, On 17 Jul 2007, at 15:59, Denis Walker wrote: [...]
I see some conflict here between your right not to be identified and my right to know who is spamming me. Maybe I want to complain directly to the spammer. But if I have to go to the ISP and ask them to identify the end user they may just say "sorry we can't give out confidential customer information". Then I have to go to court of the police to even write a letter of complaint to the spammer.
The RIPE DB is a registry of IP Address information. If we hide the bottom layer we change the whole concept.
That is a fine principle but probably doesn't fit well with a world where most consumer network operators are not in a position to fix the problem. If a consumer's machine is part of a 'botnet' and sending spam then calling them on the telephone and complaining is unlikely to be effective. Network operations intelligence sits in ISP and (some) enterprise networks most of the time, not consumer end sites. As such, that is the contact information that is needed in the RIPE database. If the problem with going through the police or the courts is that they take too long then the police and courts need to improve their interfaces to allow efficient handling of complaints about illegal activity. Putting the consumer's contact information in the RIPE database is very unlikely to help resolve this kind of problem and might even encourage vigilantism. Regards, Leo
Although it is very late to respond, but still... Leo Vegoda wrote:
Denis,
On 17 Jul 2007, at 15:59, Denis Walker wrote:
[...]
I see some conflict here between your right not to be identified and my right to know who is spamming me. Maybe I want to complain directly to the spammer. But if I have to go to the ISP and ask them to identify the end user they may just say "sorry we can't give out confidential customer information". Then I have to go to court of the police to even write a letter of complaint to the spammer.
The RIPE DB is a registry of IP Address information. If we hide the bottom layer we change the whole concept.
That is a fine principle but probably doesn't fit well with a world where most consumer network operators are not in a position to fix the problem. If a consumer's machine is part of a 'botnet' and sending spam then calling them on the telephone and complaining is unlikely to be effective. Network operations intelligence sits in ISP and (some) enterprise networks most of the time, not consumer end sites. As such, that is the contact information that is needed in the RIPE database.
This is actually where the irt: object should come into the picture. It was designed, on purpose, to support that split of interests or responsibilities. Using irt:, an ISP could *very effectively* declare itself "responsible" for operational and security/abuse complaints - while still having the fact registered that a particular address block has been assigned to a customer (and as such not being counted as a self-assignment). Btw, for PA space, we can even support a "search list" or "escalation path" by registering an irt: for the different blocks in the hierarchy :-)
If the problem with going through the police or the courts is that they take too long then the police and courts need to improve their interfaces to allow efficient handling of complaints about illegal activity.
Dream on... :-) But yes, I agree, in principle.
Putting the consumer's contact information in the RIPE database is very unlikely to help resolve this kind of problem and might even encourage vigilantism.
Regards,
Leo
Wilfried
Dear Denis, Thank you for the nice work! Overall, I think it is very good. I have a couple of comments below:
Clean up of unreferenced person objects
Targeting 'loose' mntner objects will catch the mutually referencing pairs. There may be many more of these when it is required to maintain person objects. In this case we will only target the person/mntner object pairs. To include role objects implies person/role/mntner groups with many more references. This is too complicated to handle within the scope of this one time cleanup process.
You do not need the role objects to make things complicated. Actually the mntner-person "pairs" can cause you some more headache as well. Consider the case: mntner1: admin-c: p1 tech-c: p2 p1: mnt-by: mntner2 p2: mnt-by: mntner3 mntner2: admin-c: p1 tech-c: p2 mntner3: admin-c: p1 tech-c: p2 You have here five objects that reference each other, but nothing else. Of course, this can be made as complex as you wish: mntner1: admin-c: p1 p1: mnt-by: mntner2 mntner2: admin-c: p2 p2: mnt-by: mntner3 mntner3: admin-c: p3 p3: mnt-by: mntner4 ... mntner"n": admin-c: p"n" p"n": mnt-by: mntner1 Do I miss something?
Changes to objects
Add a "not-ref:" attribute to person/role objects. This indicates that the person/role object is not referenced and the date when it last became unreferenced. ...
Is it not the date when it _first_ became unreferenced (i.e. when you first noticed it is unreferenced)?
A user can apply to have their person object linked to the white pages. They should select the category and contact the moderator. The user needs to send their full person object to the moderator. This should either include the plain text password or be a signed message providing the authentication to modify this person object. ...
I think this is what Elmar objected to as well... (Never send passwords to somebody else.)
Requests for additional white pages categories can be sent to Customer Services at RIPE NCC. These requests will be forwarded to the WG chairs mailing list for approval. If approved the RIPE NCC will create the new organisation object, update the web page and notify the moderator.
I think you mean _appoint_ a moderator. (Once appointed, he/she will be have to be notified as well, of course.)
Authentication for referencing of person and role objects
I think I would call this _authorization_ rather than authentication. This applies to the other uses of this term throughout this document.
Structuring of address attributes in person, role and organisation objects
Stage 2
* Whenever a person/role/organisation object is modified with only "address:" attributes an error message will be added to the acknowledgement. * Whenever a person/role/organisation object is referenced with only "address:" attributes an error message will be added to the acknowledgement and the update will fail.
Delete the word "only" in the two bullets above, as you either have "address:" attribute(s) or the other set, not both. I hope this helps. Please let me know if I misunderstood something, or if what I was trying to say is not clear enough. Best regards, Janos
Janos Zsako wrote:
Dear Denis,
Thank you for the nice work! Overall, I think it is very good.
I have a couple of comments below:
Clean up of unreferenced person objects
Targeting 'loose' mntner objects will catch the mutually referencing pairs. There may be many more of these when it is required to maintain person objects. In this case we will only target the person/mntner object pairs. To include role objects implies person/role/mntner groups with many more references. This is too complicated to handle within the scope of this one time cleanup process.
You do not need the role objects to make things complicated.
Actually the mntner-person "pairs" can cause you some more headache as well. Consider the case:
mntner1: admin-c: p1 tech-c: p2 p1: mnt-by: mntner2 p2: mnt-by: mntner3 mntner2: admin-c: p1 tech-c: p2 mntner3: admin-c: p1 tech-c: p2
You have here five objects that reference each other, but nothing else. Of course, this can be made as complex as you wish:
mntner1: admin-c: p1 p1: mnt-by: mntner2 mntner2: admin-c: p2 p2: mnt-by: mntner3 mntner3: admin-c: p3 p3: mnt-by: mntner4 ... mntner"n": admin-c: p"n" p"n": mnt-by: mntner1
Do I miss something?
I agree that these chains can get very complex. The issue for this proposal is to only look for those simple couples of person and mntner objects which reference each other and nothing else. As soon as other references are involved it gets difficult. We will tackle the more complex issues later. As a follow on from this one time cleanup we will put forward a proposal for a regular cleanup process. That will analyse data much more and identify clusters of objects with no connection to any operational data. But that is outside the scope of this proposal.
Changes to objects
Add a "not-ref:" attribute to person/role objects. This indicates that the person/role object is not referenced and the date when it last became unreferenced. ...
Is it not the date when it _first_ became unreferenced (i.e. when you first noticed it is unreferenced)?
I think this is semantics :) It is when we first notice it last became unreferenced. An object can be referenced now. Then it becomes unreferenced for a while, then referenced again and then unreferenced again. So this date reflects the start of the period in which it last became unreferenced.
A user can apply to have their person object linked to the white pages. They should select the category and contact the moderator. The user needs to send their full person object to the moderator. This should either include the plain text password or be a signed message providing the authentication to modify this person object. ...
I think this is what Elmar objected to as well... (Never send passwords to somebody else.)
This is not a new situation. Double authorisation is required for route creation. We simply point out the two options for achieving this. Clearly it is not a good idea to give someone your password, so it may encourage more people to change to PGP authorisation method. <dreaming> But an idea that just came to mind now....it would not be difficult to introduce a 'one use only' password feature. So you could add this to your mntner: auth: MD5-PW-ONE $1$...$.... <object> The first time this password is used for authorisation, it is removed from the mntner by the database software. It would only pass if used on the specified object. This allows you to give this one time password to someone (that you trust). They can use it for the requested purpose and then it is removed. This is also outside the scope of this proposal, but if it is considered a useful feature we could look more closely at it. We are already introducing the concept of a user requesting an update and the database software expanding that into more than one update. This is needed for the chicken and egg situation in the mntner proposal. </dreaming>
Requests for additional white pages categories can be sent to Customer Services at RIPE NCC. These requests will be forwarded to the WG chairs mailing list for approval. If approved the RIPE NCC will create the new organisation object, update the web page and notify the moderator.
I think you mean _appoint_ a moderator. (Once appointed, he/she will be have to be notified as well, of course.)
Again the RIPE NCC does not want to make these decisions. We would either assume the person requesting the new category would become the moderator, if approved, or the WG chairs will nominate the moderator.
Authentication for referencing of person and role objects
I think I would call this _authorization_ rather than authentication. This applies to the other uses of this term throughout this document.
agreed
Structuring of address attributes in person, role and organisation objects
Stage 2
* Whenever a person/role/organisation object is modified with only "address:" attributes an error message will be added to the acknowledgement. * Whenever a person/role/organisation object is referenced with only "address:" attributes an error message will be added to the acknowledgement and the update will fail.
Delete the word "only" in the two bullets above, as you either have "address:" attribute(s) or the other set, not both.
agreed regards Denis RIPE NCC
I hope this helps.
Please let me know if I misunderstood something, or if what I was trying to say is not clear enough.
Best regards, Janos
Dear Denis,
I agree that these chains can get very complex. The issue for this proposal is to only look for those simple couples of person and mntner objects which reference each other and nothing else. As soon as other references are involved it gets difficult. We will tackle the more complex issues later. As a follow on from this one time cleanup we will put forward a proposal for a regular cleanup process. That will analyse data much more and identify clusters of objects with no connection to any operational data. But that is outside the scope of this proposal.
Agreed. I think the general solution is complex enough to deserve a separate planning phase. At this moment what you propose is enough. It may be useful though to mention the above fact in one sentence so that others do not make the the same comment I made (i.e. we should point out that we are aware of the complexity, but do not want to handle all cases - you point this out in case of the role object, but probably not strongly enough in case of person only).
Changes to objects
Add a "not-ref:" attribute to person/role objects. This indicates that the person/role object is not referenced and the date when it last became unreferenced. ...
Is it not the date when it _first_ became unreferenced (i.e. when you first noticed it is unreferenced)?
I think this is semantics :) It is when we first notice it last became unreferenced. An object can be referenced now. Then it becomes unreferenced for a while, then referenced again and then unreferenced again. So this date reflects the start of the period in which it last became unreferenced.
OK, I now understand. :) The original text is fine. :)
A user can apply to have their person object linked to the white pages. They should select the category and contact the moderator. The user needs to send their full person object to the moderator. This should either include the plain text password or be a signed message providing the authentication to modify this person object. ...
I think this is what Elmar objected to as well... (Never send passwords to somebody else.)
This is not a new situation. Double authorisation is required for route creation. We simply point out the two options for achieving this. Clearly it is not a good idea to give someone your password, so it may encourage more people to change to PGP authorisation method.
Fine. However, the way it is now seems to suggest we do encourage people to do so (to send their password). Perhaps it should be rephrased to: The user needs to send their full person object to the moderator. This should either include the plain text password (which we strongly recommend against) or be a signed message providing the authentication to modify this person object.
<dreaming> But an idea that just came to mind now....it would not be difficult to introduce a 'one use only' password feature. So you could add this to your mntner:
auth: MD5-PW-ONE $1$...$.... <object>
The first time this password is used for authorisation, it is removed from the mntner by the database software. It would only pass if used on the specified object. This allows you to give this one time password to someone (that you trust). They can use it for the requested purpose and then it is removed.
This is also outside the scope of this proposal, but if it is considered a useful feature we could look more closely at it. We are already introducing the concept of a user requesting an update and the database software expanding that into more than one update. This is needed for the chicken and egg situation in the mntner proposal. </dreaming>
It would lower the risks, but would not eliminate them. You would have no control over what that password would be used for (e.g. deleting all maintaned objects, etc...). At present you can still do roughly the same: you temporarily modify the password to something you tell the other person, and once he/she performed the change you asked for, change the password. It is not automatic, but does not need further change to code.
Requests for additional white pages categories can be sent to Customer Services at RIPE NCC. These requests will be forwarded to the WG chairs mailing list for approval. If approved the RIPE NCC will create the new organisation object, update the web page and notify the moderator.
I think you mean _appoint_ a moderator. (Once appointed, he/she will be have to be notified as well, of course.)
Again the RIPE NCC does not want to make these decisions. We would either assume the person requesting the new category would become the moderator, if approved, or the WG chairs will nominate the moderator.
Agreed. In this case a small addition: If approved, and the moderator is appointed, the RIPE NCC will create the new organisation... Best regards, Janos
Janos Zsako wrote:
Dear Denis,
I agree that these chains can get very complex. The issue for this proposal is to only look for those simple couples of person and mntner objects which reference each other and nothing else. As soon as other references are involved it gets difficult. We will tackle the more complex issues later. As a follow on from this one time cleanup we will put forward a proposal for a regular cleanup process. That will analyse data much more and identify clusters of objects with no connection to any operational data. But that is outside the scope of this proposal.
Agreed. I think the general solution is complex enough to deserve a separate planning phase. At this moment what you propose is enough.
It may be useful though to mention the above fact in one sentence so that others do not make the the same comment I made (i.e. we should point out that we are aware of the complexity, but do not want to handle all cases - you point this out in case of the role object, but probably not strongly enough in case of person only).
agreed
Changes to objects
Add a "not-ref:" attribute to person/role objects. This indicates that the person/role object is not referenced and the date when it last became unreferenced. ...
Is it not the date when it _first_ became unreferenced (i.e. when you first noticed it is unreferenced)?
I think this is semantics :) It is when we first notice it last became unreferenced. An object can be referenced now. Then it becomes unreferenced for a while, then referenced again and then unreferenced again. So this date reflects the start of the period in which it last became unreferenced.
OK, I now understand. :) The original text is fine. :)
A user can apply to have their person object linked to the white pages. They should select the category and contact the moderator. The user needs to send their full person object to the moderator. This should either include the plain text password or be a signed message providing the authentication to modify this person object. ...
I think this is what Elmar objected to as well... (Never send passwords to somebody else.)
This is not a new situation. Double authorisation is required for route creation. We simply point out the two options for achieving this. Clearly it is not a good idea to give someone your password, so it may encourage more people to change to PGP authorisation method.
Fine. However, the way it is now seems to suggest we do encourage people to do so (to send their password). Perhaps it should be rephrased to:
The user needs to send their full person object to the moderator. This should either include the plain text password (which we strongly recommend against) or be a signed message providing the authentication to modify this person object.
agreed
<dreaming> But an idea that just came to mind now....it would not be difficult to introduce a 'one use only' password feature. So you could add this to your mntner:
auth: MD5-PW-ONE $1$...$.... <object>
The first time this password is used for authorisation, it is removed from the mntner by the database software. It would only pass if used on the specified object. This allows you to give this one time password to someone (that you trust). They can use it for the requested purpose and then it is removed.
This is also outside the scope of this proposal, but if it is considered a useful feature we could look more closely at it. We are already introducing the concept of a user requesting an update and the database software expanding that into more than one update. This is needed for the chicken and egg situation in the mntner proposal. </dreaming>
It would lower the risks, but would not eliminate them. You would have no control over what that password would be used for (e.g. deleting all maintaned objects, etc...). At present you can still do roughly the same: you temporarily modify the password to something you tell the other person, and once he/she performed the change you asked for, change the password. It is not automatic, but does not need further change to code.
sometimes I dream a bit too much :)
Requests for additional white pages categories can be sent to Customer Services at RIPE NCC. These requests will be forwarded to the WG chairs mailing list for approval. If approved the RIPE NCC will create the new organisation object, update the web page and notify the moderator.
I think you mean _appoint_ a moderator. (Once appointed, he/she will be have to be notified as well, of course.)
Again the RIPE NCC does not want to make these decisions. We would either assume the person requesting the new category would become the moderator, if approved, or the WG chairs will nominate the moderator.
Agreed. In this case a small addition:
If approved, and the moderator is appointed, the RIPE NCC will create the new organisation...
agreed cheers denis
Best regards, Janos
participants (7)
-
Denis Walker -
Elmar K. Bins -
Janos Zsako -
Larisa A. Yurkina -
Leo Vegoda -
Manfredo Miserocchi -
Wilfried Woeber, UniVie/ACOnet