[dp-tf] Quadlogy of person proposals
Elmar K. Bins elmi at 4ever.de
Mon Jun 11 16:11:50 CEST 2007
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.
[ dp-tf Archives ]