From denis at ripe.net Mon Jun 11 13:45:51 2007 From: denis at ripe.net (Denis Walker) Date: Mon, 11 Jun 2007 13:45:51 +0200 Subject: [dp-tf] Quadlogy of person proposals Message-ID: <466D35EF.6030306@ripe.net> 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 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pn_mnt_by.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pn_cleanup.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pn_ref.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pn_address.txt URL: From elmi at 4ever.de Mon Jun 11 16:11:50 2007 From: elmi at 4ever.de (Elmar K. Bins) Date: Mon, 11 Jun 2007 16:11:50 +0200 Subject: [dp-tf] Quadlogy of person proposals In-Reply-To: <466D35EF.6030306@ripe.net> References: <466D35EF.6030306@ripe.net> Message-ID: <20070611141150.GM69658@ronin.4ever.de> 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 at ripe.net changed: denis at ripe.net source: RIPE mntner: AUTO-2 descr: Mntner for denis' objects. admin-c: AUTO-1 tech-c: AUTO-1 upd-to: denis at ripe.net auth: X509-1 notify: denis at ripe.net mnt-by: AUTO-2 referral-by: RIPE-DBM-MNT changed: denis at 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. From denis at ripe.net Mon Jun 11 18:20:16 2007 From: denis at ripe.net (Denis Walker) Date: Mon, 11 Jun 2007 18:20:16 +0200 Subject: [dp-tf] Quadlogy of person proposals In-Reply-To: <20070611141150.GM69658@ronin.4ever.de> References: <466D35EF.6030306@ripe.net> <20070611141150.GM69658@ronin.4ever.de> Message-ID: <466D7640.8060105@ripe.net> 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 at ripe.net > changed: denis at ripe.net > source: RIPE > > mntner: AUTO-2 > descr: Mntner for denis' objects. > admin-c: AUTO-1 > tech-c: AUTO-1 > upd-to: denis at ripe.net > auth: X509-1 > notify: denis at ripe.net > mnt-by: AUTO-2 > referral-by: RIPE-DBM-MNT > changed: denis at 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. > > From mis at wari.net Tue Jun 12 11:58:50 2007 From: mis at wari.net (Manfredo Miserocchi) Date: Tue, 12 Jun 2007 11:58:50 +0200 Subject: [dp-tf] Quadlogy of person proposals In-Reply-To: <466D7640.8060105@ripe.net> References: <466D35EF.6030306@ripe.net> <20070611141150.GM69658@ronin.4ever.de> <466D7640.8060105@ripe.net> Message-ID: 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 at wari.net -- Warinet Global Services SA Via Soave, 2 CH-6901 Lugano Switzerland -- -----Original Message----- From: Denis Walker To: "Elmar K. Bins" Cc: dp-tf at 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. > > > > 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 at ripe.net > > changed: denis at ripe.net > > source: RIPE > > > > mntner: AUTO-2 > > descr: Mntner for denis' objects. > > admin-c: AUTO-1 > > tech-c: AUTO-1 > > upd-to: denis at ripe.net > > auth: X509-1 > > notify: denis at ripe.net > > mnt-by: AUTO-2 > > referral-by: RIPE-DBM-MNT > > changed: denis at 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. > > > > > 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. From zsako at 3c-hungary.hu Tue Jun 12 18:16:23 2007 From: zsako at 3c-hungary.hu (Janos Zsako) Date: Tue, 12 Jun 2007 18:16:23 +0200 Subject: [dp-tf] Quadlogy of person proposals References: <466D35EF.6030306@ripe.net> Message-ID: <466EC6D7.1090101@3c-hungary.hu> 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 From denis at ripe.net Wed Jun 13 13:08:31 2007 From: denis at ripe.net (Denis Walker) Date: Wed, 13 Jun 2007 13:08:31 +0200 Subject: [dp-tf] Quadlogy of person proposals In-Reply-To: <466EC6D7.1090101@3c-hungary.hu> References: <466D35EF.6030306@ripe.net> <466EC6D7.1090101@3c-hungary.hu> Message-ID: <466FD02F.4000704@ripe.net> 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. 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$...$.... 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. > > >> 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 > From zsako at 3c-hungary.hu Wed Jun 13 13:47:38 2007 From: zsako at 3c-hungary.hu (Janos Zsako) Date: Wed, 13 Jun 2007 13:47:38 +0200 Subject: [dp-tf] Quadlogy of person proposals References: <466D35EF.6030306@ripe.net> <466EC6D7.1090101@3c-hungary.hu> <466FD02F.4000704@ripe.net> Message-ID: <466FD95A.6030003@3c-hungary.hu> 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. > > 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$...$.... > > 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. > 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 From Woeber at CC.UniVie.ac.at Wed Jun 13 15:07:49 2007 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 13 Jun 2007 13:07:49 +0000 Subject: [dp-tf] busy... Message-ID: <466FEC25.2080701@CC.UniVie.ac.at> Just wanted to let you know that I am terribly busy at the moment with the preparations for our operations meeting tomorrow and Friday. I hope to be able to read up on the most recent proposals and feedback during next week in Sevilla (FIRST Conference). Othrwise I will be back in the office on the 2nd of July. Sorry, Wilfried. From zsako at 3c-hungary.hu Wed Jun 13 17:02:36 2007 From: zsako at 3c-hungary.hu (Janos Zsako) Date: Wed, 13 Jun 2007 17:02:36 +0200 Subject: [dp-tf] Quadlogy of person proposals References: <466D35EF.6030306@ripe.net> <20070611141150.GM69658@ronin.4ever.de> <466D7640.8060105@ripe.net> Message-ID: <4670070C.1070606@3c-hungary.hu> 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 From denis at ripe.net Wed Jun 13 18:17:50 2007 From: denis at ripe.net (Denis Walker) Date: Wed, 13 Jun 2007 18:17:50 +0200 Subject: [dp-tf] Quadlogy of person proposals In-Reply-To: <4670070C.1070606@3c-hungary.hu> References: <466D35EF.6030306@ripe.net> <20070611141150.GM69658@ronin.4ever.de> <466D7640.8060105@ripe.net> <4670070C.1070606@3c-hungary.hu> Message-ID: <467018AE.4030900@ripe.net> 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 > From mis at wari.net Wed Jun 13 18:20:51 2007 From: mis at wari.net (Manfredo Miserocchi) Date: Wed, 13 Jun 2007 18:20:51 +0200 Subject: [dp-tf] Quadlogy of person proposals In-Reply-To: <4670070C.1070606@3c-hungary.hu> References: <466D35EF.6030306@ripe.net> <20070611141150.GM69658@ronin.4ever.de> <466D7640.8060105@ripe.net> <4670070C.1070606@3c-hungary.hu> Message-ID: 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. From denis at ripe.net Wed Jun 13 18:23:02 2007 From: denis at ripe.net (Denis Walker) Date: Wed, 13 Jun 2007 18:23:02 +0200 Subject: [dp-tf] Quadlogy of person proposals In-Reply-To: <466FD95A.6030003@3c-hungary.hu> References: <466D35EF.6030306@ripe.net> <466EC6D7.1090101@3c-hungary.hu> <466FD02F.4000704@ripe.net> <466FD95A.6030003@3c-hungary.hu> Message-ID: <467019E6.9010506@ripe.net> 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 > >> >> 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$...$.... >> >> 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. >> > > 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 > From mis at wari.net Wed Jun 13 18:44:14 2007 From: mis at wari.net (Manfredo Miserocchi) Date: Wed, 13 Jun 2007 18:44:14 +0200 Subject: [dp-tf] Quadlogy of person proposals In-Reply-To: <467018AE.4030900@ripe.net> References: <466D35EF.6030306@ripe.net> <20070611141150.GM69658@ronin.4ever.de> <466D7640.8060105@ripe.net> <4670070C.1070606@3c-hungary.hu> <467018AE.4030900@ripe.net> Message-ID: 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. From denis at ripe.net Wed Jun 13 19:05:45 2007 From: denis at ripe.net (Denis Walker) Date: Wed, 13 Jun 2007 19:05:45 +0200 Subject: [dp-tf] Quadlogy of person proposals In-Reply-To: References: <466D35EF.6030306@ripe.net> <20070611141150.GM69658@ronin.4ever.de> <466D7640.8060105@ripe.net> <4670070C.1070606@3c-hungary.hu> <467018AE.4030900@ripe.net> Message-ID: <467023E9.2070506@ripe.net> 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. > > > From mis at wari.net Thu Jun 14 13:22:01 2007 From: mis at wari.net (Manfredo Miserocchi) Date: Thu, 14 Jun 2007 13:22:01 +0200 Subject: [dp-tf] Quadlogy of person proposals In-Reply-To: <467023E9.2070506@ripe.net> References: <466D35EF.6030306@ripe.net> <20070611141150.GM69658@ronin.4ever.de> <466D7640.8060105@ripe.net> <4670070C.1070606@3c-hungary.hu> <467018AE.4030900@ripe.net> <467023E9.2070506@ripe.net> Message-ID: 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. From denis at ripe.net Thu Jun 14 13:41:19 2007 From: denis at ripe.net (Denis Walker) Date: Thu, 14 Jun 2007 13:41:19 +0200 Subject: [dp-tf] Quadlogy of person proposals In-Reply-To: References: <466D35EF.6030306@ripe.net> <20070611141150.GM69658@ronin.4ever.de> <466D7640.8060105@ripe.net> <4670070C.1070606@3c-hungary.hu> <467018AE.4030900@ripe.net> <467023E9.2070506@ripe.net> Message-ID: <4671295F.3060603@ripe.net> 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. > > > From mis at wari.net Thu Jun 14 14:13:42 2007 From: mis at wari.net (Manfredo Miserocchi) Date: Thu, 14 Jun 2007 14:13:42 +0200 Subject: [dp-tf] Quadlogy of person proposals In-Reply-To: <4671295F.3060603@ripe.net> References: <466D35EF.6030306@ripe.net> <20070611141150.GM69658@ronin.4ever.de> <466D7640.8060105@ripe.net> <4670070C.1070606@3c-hungary.hu> <467018AE.4030900@ripe.net> <467023E9.2070506@ripe.net> <4671295F.3060603@ripe.net> Message-ID: 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. From zsako at 3c-hungary.hu Thu Jun 14 14:28:33 2007 From: zsako at 3c-hungary.hu (Janos Zsako) Date: Thu, 14 Jun 2007 14:28:33 +0200 Subject: Maintainer's responsibility (was Re: [dp-tf] Quadlogy of person proposals) References: <466D35EF.6030306@ripe.net> <20070611141150.GM69658@ronin.4ever.de> <466D7640.8060105@ripe.net> <4670070C.1070606@3c-hungary.hu> <467018AE.4030900@ripe.net> Message-ID: <46713471.9040207@3c-hungary.hu> 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 From zsako at 3c-hungary.hu Thu Jun 14 14:33:00 2007 From: zsako at 3c-hungary.hu (Janos Zsako) Date: Thu, 14 Jun 2007 14:33:00 +0200 Subject: [dp-tf] Quadlogy of person proposals References: <466D35EF.6030306@ripe.net> <20070611141150.GM69658@ronin.4ever.de> <466D7640.8060105@ripe.net> <4670070C.1070606@3c-hungary.hu> <467018AE.4030900@ripe.net> <467023E9.2070506@ripe.net> <4671295F.3060603@ripe.net> Message-ID: <4671357C.1080404@3c-hungary.hu> 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 From mis at wari.net Thu Jun 14 14:41:41 2007 From: mis at wari.net (Manfredo Miserocchi) Date: Thu, 14 Jun 2007 14:41:41 +0200 Subject: [dp-tf] Quadlogy of person proposals In-Reply-To: <4671357C.1080404@3c-hungary.hu> References: <466D7640.8060105@ripe.net> <4670070C.1070606@3c-hungary.hu> <467018AE.4030900@ripe.net> <467023E9.2070506@ripe.net> <4671295F.3060603@ripe.net> <4671357C.1080404@3c-hungary.hu> Message-ID: 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. From denis at ripe.net Thu Jun 14 14:55:13 2007 From: denis at ripe.net (Denis Walker) Date: Thu, 14 Jun 2007 14:55:13 +0200 Subject: [dp-tf] Quadlogy of person proposals In-Reply-To: References: <466D7640.8060105@ripe.net> <4670070C.1070606@3c-hungary.hu> <467018AE.4030900@ripe.net> <467023E9.2070506@ripe.net> <4671295F.3060603@ripe.net> <4671357C.1080404@3c-hungary.hu> Message-ID: <46713AB1.1060600@ripe.net> 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. > > > From elmi at 4ever.de Thu Jun 14 15:32:11 2007 From: elmi at 4ever.de (Elmar K. Bins) Date: Thu, 14 Jun 2007 15:32:11 +0200 Subject: Maintainer's responsibility (was Re: [dp-tf] Quadlogy of person proposals) In-Reply-To: <46713471.9040207@3c-hungary.hu> References: <466D35EF.6030306@ripe.net> <20070611141150.GM69658@ronin.4ever.de> <466D7640.8060105@ripe.net> <4670070C.1070606@3c-hungary.hu> <467018AE.4030900@ripe.net> <46713471.9040207@3c-hungary.hu> Message-ID: <20070614133210.GN69658@ronin.4ever.de> zsako at 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. From ula at ripn.net Thu Jun 14 16:06:29 2007 From: ula at ripn.net (Larisa A. Yurkina) Date: Thu, 14 Jun 2007 18:06:29 +0400 (MSD) Subject: [dp-tf] Quadlogy of person proposals In-Reply-To: <4671357C.1080404@3c-hungary.hu> Message-ID: <20070614170003.T23752-100000@capral.ripn.net> 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 ----- From zsako at 3c-hungary.hu Thu Jun 14 17:08:32 2007 From: zsako at 3c-hungary.hu (Janos Zsako) Date: Thu, 14 Jun 2007 17:08:32 +0200 Subject: Maintainer's responsibility (was Re: [dp-tf] Quadlogy of person proposals) References: <466D35EF.6030306@ripe.net> <20070611141150.GM69658@ronin.4ever.de> <466D7640.8060105@ripe.net> <4670070C.1070606@3c-hungary.hu> <467018AE.4030900@ripe.net> <46713471.9040207@3c-hungary.hu> <20070614133210.GN69658@ronin.4ever.de> Message-ID: <467159F0.7000409@3c-hungary.hu> 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). From zsako at 3c-hungary.hu Thu Jun 14 17:23:29 2007 From: zsako at 3c-hungary.hu (Janos Zsako) Date: Thu, 14 Jun 2007 17:23:29 +0200 Subject: [dp-tf] Authorization to publish personal data in the DB (was Re: [dp-tf] Quadlogy of person proposals) References: <20070614170003.T23752-100000@capral.ripn.net> Message-ID: <46715D71.1000408@3c-hungary.hu> 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 > ----- > > > > > > > From mis at atragon.net Thu Jun 14 18:32:22 2007 From: mis at atragon.net (Manfredo Miserocchi) Date: Thu, 14 Jun 2007 18:32:22 +0200 Subject: [dp-tf] Fwd: Authenticated Whois Message-ID: All, Have a look at this news from the .it TLD Registry. In particular what is about EU and not EU countries and the last paragraph. Cheers Manfredo -----Original Message----- From: "ccTLD .it Registry Hostmaster" To: maintainers at NIC.IT Date: Wed, 13 Jun 2007 18:31:49 +0200 Subject: [Ticket#2007061310006295] Whois autenticato/Authenticated Whois ========================================================================= To all Maintainers, In our email to you dated 6 June we informed you of our intention to provide Maintainers that have an active contract, upon subscription to a confidentiality agreement, with an authenticated Whois Service. We would now like to inform you that this agreement is now availabe on RAIN in the section "Tools/Authenticated Whois", which also contains Schedule A, the technical schedule. The agreement describes the conditions and terms on the basis of which it is possible to access the data in order to carry out the modifications of the Maintainer and modifications of the Registrant relating to a domain name and to modify the domain names and the contact details associated with the domain names. Upon signing of this agreement, the Maintainer is nominated responsible for processing data and this role will be made public on the Registry's website in compliance with D.Lgs. 196/2003. The technical schedule (Schedule A) contains the characteristics of the service and the means with which it is possible to access the authenticated Whois service". It also outlines the security measures that the Maintainer must observe when using this service. Schedule B, which is referred to in Schedule A is only applicable to Maintainers whose registered offices are in a non EU country and who are considered by the European Commission as not being adequate in terms of data protection, in compliance with the general authorization of the Guarantor of 10 April published in G.U. No. 105 dated 7 May 2002. Please note that after thirty days from today's date, the Registry will not make available any personal data associated with domain names assigned to physical persons who have not given their express consent. Best regards, The ccTLD.it Registry staff -- ccTLD .it Registry - Hostmaster of the Day ---------- ------------- ccTLD .it Registry E-mail: hostmaster at nic.it IIT - Istituto del CNR Phone: +39 050 3139811 Via Giuseppe Moruzzi, 1 Fax: +39 050 542420 56124 Pisa - Italy From elmi at 4ever.de Fri Jun 15 10:12:00 2007 From: elmi at 4ever.de (Elmar K. Bins) Date: Fri, 15 Jun 2007 10:12:00 +0200 Subject: Maintainer's responsibility (was Re: [dp-tf] Quadlogy of person proposals) In-Reply-To: <467159F0.7000409@3c-hungary.hu> References: <466D35EF.6030306@ripe.net> <20070611141150.GM69658@ronin.4ever.de> <466D7640.8060105@ripe.net> <4670070C.1070606@3c-hungary.hu> <467018AE.4030900@ripe.net> <46713471.9040207@3c-hungary.hu> <20070614133210.GN69658@ronin.4ever.de> <467159F0.7000409@3c-hungary.hu> Message-ID: <20070615081200.GT69658@ronin.4ever.de> Hi Janos, zsako at 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. From elmi at 4ever.de Fri Jun 15 10:16:31 2007 From: elmi at 4ever.de (Elmar K. Bins) Date: Fri, 15 Jun 2007 10:16:31 +0200 Subject: [dp-tf] Authorization to publish personal data in the DB (was Re: [dp-tf] Quadlogy of person proposals) In-Reply-To: <46715D71.1000408@3c-hungary.hu> References: <20070614170003.T23752-100000@capral.ripn.net> <46715D71.1000408@3c-hungary.hu> Message-ID: <20070615081631.GU69658@ronin.4ever.de> Hi Janos and Larissa, zsako at 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 ]--- From ula at ripn.net Fri Jun 15 12:07:31 2007 From: ula at ripn.net (Larisa A. Yurkina) Date: Fri, 15 Jun 2007 14:07:31 +0400 (MSD) Subject: [dp-tf] Authorization to publish personal data in the DB (was Re: [dp-tf] Quadlogy of person proposals) In-Reply-To: <46715D71.1000408@3c-hungary.hu> Message-ID: <20070615133723.Q37024-100000@capral.ripn.net> 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 > > ----- > > > > > > > > > > > > > > > > > From ula at ripn.net Fri Jun 15 12:10:44 2007 From: ula at ripn.net (Larisa A. Yurkina) Date: Fri, 15 Jun 2007 14:10:44 +0400 (MSD) Subject: [dp-tf] Quadlogy of person proposals In-Reply-To: <4670070C.1070606@3c-hungary.hu> Message-ID: <20070614181258.G23752-100000@capral.ripn.net> 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 ----- From denis at ripe.net Fri Jun 15 12:44:01 2007 From: denis at ripe.net (Denis Walker) Date: Fri, 15 Jun 2007 12:44:01 +0200 Subject: [dp-tf] Quadlogy of person proposals In-Reply-To: <20070614181258.G23752-100000@capral.ripn.net> References: <20070614181258.G23752-100000@capral.ripn.net> Message-ID: <46726D71.6080100@ripe.net> 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 > ----- > > > > > > > > > > From ula at ripn.net Fri Jun 15 13:16:55 2007 From: ula at ripn.net (Larisa A. Yurkina) Date: Fri, 15 Jun 2007 15:16:55 +0400 (MSD) Subject: [dp-tf] Authorization to publish personal data in the DB (was Re: [dp-tf] Quadlogy of person proposals) In-Reply-To: <20070615081631.GU69658@ronin.4ever.de> Message-ID: <20070615144950.W37024-100000@capral.ripn.net> On Fri, 15 Jun 2007, Elmar K. Bins wrote: Hi Elmar, > Hi Janos and Larissa, > > zsako at 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 ----- From ula at ripn.net Fri Jun 15 13:22:20 2007 From: ula at ripn.net (Larisa A. Yurkina) Date: Fri, 15 Jun 2007 15:22:20 +0400 (MSD) Subject: [dp-tf] Quadlogy of person proposals In-Reply-To: <46726D71.6080100@ripe.net> Message-ID: <20070615151923.A37024-100000@capral.ripn.net> 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 ----- From zsako at 3c-hungary.hu Fri Jun 15 14:18:49 2007 From: zsako at 3c-hungary.hu (Janos Zsako) Date: Fri, 15 Jun 2007 14:18:49 +0200 Subject: [dp-tf] Authorization to publish personal data in the DB (was Re: [dp-tf] Quadlogy of person proposals) References: <20070615144950.W37024-100000@capral.ripn.net> Message-ID: <467283A9.8020209@3c-hungary.hu> 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 From zsako at 3c-hungary.hu Fri Jun 15 14:30:22 2007 From: zsako at 3c-hungary.hu (Janos Zsako) Date: Fri, 15 Jun 2007 14:30:22 +0200 Subject: Maintainer's responsibility (was Re: [dp-tf] Quadlogy of person proposals) References: <466D35EF.6030306@ripe.net> <20070611141150.GM69658@ronin.4ever.de> <466D7640.8060105@ripe.net> <4670070C.1070606@3c-hungary.hu> <467018AE.4030900@ripe.net> <46713471.9040207@3c-hungary.hu> <20070614133210.GN69658@ronin.4ever.de> <467159F0.7000409@3c-hungary.hu> <20070615081200.GT69658@ronin.4ever.de> Message-ID: <4672865E.9090403@3c-hungary.hu> 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 From zsako at 3c-hungary.hu Fri Jun 15 14:40:14 2007 From: zsako at 3c-hungary.hu (Janos Zsako) Date: Fri, 15 Jun 2007 14:40:14 +0200 Subject: [dp-tf] Authorization to publish personal data in the DB (was Re: [dp-tf] Quadlogy of person proposals) References: <20070614170003.T23752-100000@capral.ripn.net> <46715D71.1000408@3c-hungary.hu> <20070615081631.GU69658@ronin.4ever.de> Message-ID: <467288AE.8050708@3c-hungary.hu> 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 From ula at ripn.net Fri Jun 15 14:56:21 2007 From: ula at ripn.net (Larisa A. Yurkina) Date: Fri, 15 Jun 2007 16:56:21 +0400 (MSD) Subject: [dp-tf] Authorization to publish personal data in the DB (was Re: [dp-tf] Quadlogy of person proposals) In-Reply-To: <467283A9.8020209@3c-hungary.hu> Message-ID: <20070615163443.R37024-100000@capral.ripn.net> 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 ----- From leo.vegoda at icann.org Fri Jun 15 15:02:32 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Fri, 15 Jun 2007 15:02:32 +0200 Subject: [dp-tf] Quadlogy of person proposals In-Reply-To: <46726D71.6080100@ripe.net> References: <20070614181258.G23752-100000@capral.ripn.net> <46726D71.6080100@ripe.net> Message-ID: 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 From ula at ripn.net Fri Jun 15 15:28:32 2007 From: ula at ripn.net (Larisa A. Yurkina) Date: Fri, 15 Jun 2007 17:28:32 +0400 (MSD) Subject: [dp-tf] Quadlogy of person proposals In-Reply-To: Message-ID: <20070615171635.F37024-100000@capral.ripn.net> 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 ----- From leo.vegoda at icann.org Fri Jun 15 14:52:44 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Fri, 15 Jun 2007 14:52:44 +0200 Subject: [dp-tf] Authorization to publish personal data in the DB (was Re: [dp-tf] Quadlogy of person proposals) In-Reply-To: <20070615144950.W37024-100000@capral.ripn.net> References: <20070615144950.W37024-100000@capral.ripn.net> Message-ID: <9393024C-39AF-4F37-9857-CBE60E22AE2D@icann.org> 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 at example.com admin-c: TRO5-RIPE tech-c: TRO5-RIPE nic-hdl: TRO5-RIPE changed: example at 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 From zsako at 3c-hungary.hu Fri Jun 15 16:03:21 2007 From: zsako at 3c-hungary.hu (Janos Zsako) Date: Fri, 15 Jun 2007 16:03:21 +0200 Subject: [dp-tf] Authorization to publish personal data in the DB (was Re: [dp-tf] Quadlogy of person proposals) References: <20070615163443.R37024-100000@capral.ripn.net> Message-ID: <46729C29.7080000@3c-hungary.hu> 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 > ----- From denis at ripe.net Fri Jun 15 16:26:02 2007 From: denis at ripe.net (Denis Walker) Date: Fri, 15 Jun 2007 16:26:02 +0200 Subject: [dp-tf] Quadlogy of person proposals In-Reply-To: References: <20070614181258.G23752-100000@capral.ripn.net> <46726D71.6080100@ripe.net> Message-ID: <4672A17A.5050103@ripe.net> 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 From leo.vegoda at icann.org Fri Jun 15 16:29:44 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Fri, 15 Jun 2007 16:29:44 +0200 Subject: [dp-tf] Quadlogy of person proposals In-Reply-To: <4672A17A.5050103@ripe.net> References: <20070614181258.G23752-100000@capral.ripn.net> <46726D71.6080100@ripe.net> <4672A17A.5050103@ripe.net> Message-ID: 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 From denis at ripe.net Fri Jun 15 16:37:47 2007 From: denis at ripe.net (Denis Walker) Date: Fri, 15 Jun 2007 16:37:47 +0200 Subject: [dp-tf] Quadlogy of person proposals In-Reply-To: References: <20070614181258.G23752-100000@capral.ripn.net> <46726D71.6080100@ripe.net> <4672A17A.5050103@ripe.net> Message-ID: <4672A43B.5060208@ripe.net> 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 > > From mis at wari.net Fri Jun 15 16:53:07 2007 From: mis at wari.net (Manfredo Miserocchi) Date: Fri, 15 Jun 2007 16:53:07 +0200 Subject: Maintainer's responsibility (was Re: [dp-tf] Quadlogy of person proposals) In-Reply-To: <4672865E.9090403@3c-hungary.hu> References: <466D35EF.6030306@ripe.net> <20070611141150.GM69658@ronin.4ever.de> <466D7640.8060105@ripe.net> <4670070C.1070606@3c-hungary.hu> <467018AE.4030900@ripe.net> <46713471.9040207@3c-hungary.hu> <20070614133210.GN69658@ronin.4ever.de> <467159F0.7000409@3c-hungary.hu> <20070615081200.GT69658@ronin.4ever.de> <4672865E.9090403@3c-hungary.hu> Message-ID: 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. From mis at wari.net Fri Jun 15 17:04:19 2007 From: mis at wari.net (Manfredo Miserocchi) Date: Fri, 15 Jun 2007 17:04:19 +0200 Subject: [dp-tf] Authorization to publish personal data in the DB (was Re: [dp-tf] Quadlogy of person proposals) In-Reply-To: <467288AE.8050708@3c-hungary.hu> References: <20070614170003.T23752-100000@capral.ripn.net> <46715D71.1000408@3c-hungary.hu> <20070615081631.GU69658@ronin.4ever.de> <467288AE.8050708@3c-hungary.hu> Message-ID: 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. From leo.vegoda at icann.org Fri Jun 15 17:35:11 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Fri, 15 Jun 2007 17:35:11 +0200 Subject: [dp-tf] Quadlogy of person proposals In-Reply-To: <4672A43B.5060208@ripe.net> References: <20070614181258.G23752-100000@capral.ripn.net> <46726D71.6080100@ripe.net> <4672A17A.5050103@ripe.net> <4672A43B.5060208@ripe.net> Message-ID: <5856F24B-B01E-4C05-93DE-E5870583D42D@icann.org> 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 From denis at ripe.net Mon Jun 18 15:55:49 2007 From: denis at ripe.net (Denis Walker) Date: Mon, 18 Jun 2007 15:55:49 +0200 Subject: [dp-tf] Maintaining person, role and domain objects Message-ID: <46768EE5.6000004@ripe.net> Hi all I think we all agreed that this one is Ok almost as I sent it out. There are issues around who should be allowed to create mntners and who should be able to put data into the RIPE Database. But these are outside the immediate scope of this proposal. I have made one significant change to the implementation plan. I expanded Stage 2 into 2 separate stages. This is to allow for the problem of other people maintaining referenced data. We don't want to stop anyone from modifying existing data, maybe until a much later time. So I have added the point about new references. So the implementation plan now looks like this: 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 a warning message in the acknowledgement. * Any NEW reference to an un-maintained person object or to a mntner which 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 warnings and errors: ***WARNING: Un-maintained person object referenced [DW-RIPE] ***WARNING: Un-maintained person object referenced [DW-RIPE] in mntner [AARDVARK-MNT] ***ERROR: New reference to un-maintained person object [DW-RIPE] ***ERROR: New reference to un-maintained person object [DW-RIPE] in mntner [AARDVARK-MNT] Stage 3 * 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] ***ERROR: Un-maintained person object referenced [DW-RIPE] in mntner [AARDVARK-MNT] We will send this one to the community later this week. The others will follow over the next few weeks. We don't want to send them all out at the same time and overload people. regards Denis RIPE NCC From ula at ripn.net Tue Jun 19 09:30:50 2007 From: ula at ripn.net (Larisa A. Yurkina) Date: Tue, 19 Jun 2007 11:30:50 +0400 (MSD) Subject: [dp-tf] Quadlogy of person proposals In-Reply-To: <5856F24B-B01E-4C05-93DE-E5870583D42D@icann.org> Message-ID: <20070618114335.V55601-100000@capral.ripn.net> 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 -----