draft agenda (V1) for DB-WG meeting, RIPE 49, Manchester, UK
Dear DB-WG community, attached please find the draft agenda V1 for the DB-WG meeting during RIPE49 in Manchester, UK. As some of us have still been on vacation recently, we may have to update the draft agenda as we get closer to the meeting date. Please feel free to propose additional topics by either replying to the WG mailing list or in private mail to Nigel (who has volunteered to manage the meeting in Manchester - thank you very much!) and myself. Have a nice and successful meeting in Manchester! Wilfried. ++++++++ A. Administrative Matters - scribe - list of participants - agenda - minutes - "remote participation" coordination (if needed) - meeting schedule for 2005 B. DB Operational Update (N.N., RIPE NCC) tbc [~20 min] C. ERX Report [196/8, 198/8] (Leo V., RIPE NCC) [~15 min] D. RAToolSet software maintenance (N.N., RIPE NCC) tbc [~10 min] E. Routing Registry Courses (Vesna M., RIPE NCC) [~05 min] Y. Input from other WGs Z. AOB -------------------------------------------------------------------------------- 7-SEP-2004 12:55:00 UTC
On Tue, Sep 07, 2004 at 03:00:05PM +0200, Wilfried Woeber, UniVie/ACOnet wrote:
Please feel free to propose additional topics by either replying to the WG mailing list or in private mail to Nigel (who has volunteered to manage the meeting in Manchester - thank you very much!) and myself.
Hate to come up with it again, but there are various actions points open on the abuse-c stuff. One of them lists the 'implement whatever concensus there is on the mailinglist'. These should already be on the agenda as open action points, but it might be worth planning some time for discussion or at least an overview of what the outcome of the mail discussion was. I can find back 2 detailed proposals on this subject: From: Shane Kerr <shane@ripe.net> Subject: Re: [db-wg] Proposal: Abuse-C as a Reference Date: Mon, 10 May 2004 14:57:44 +0200 Message-ID: <409F7C48.8070205@ripe.net> From: Ulrich Kiermayr <ulrich.kiermayr@univie.ac.at> Subject: [db-wg] Proposal: Abuse-C as a Reference Date: Thu, 06 May 2004 10:25:12 +0200 Message-ID: <4099F668.1040508@univie.ac.at> The one from Ulrich, on abuse-c reference, met some more 'resistance' as Shane's proposal on cutting the number of email addresses returned. But they are also taking a very different approach to solve the problem. It's hard to say there is consensus on this subject, although in they end there weren't much comments posted and everybody seems to be happy (or tired of it). Grtx, MarcoH
On 10 Sep 2004, at 15:50, MarcoH wrote:
everybody seems to be happy (or tired of it).
The second option, I would say! Best regards, Niall O'Reilly
On Sep 10, Niall O'Reilly <niall.oreilly@ucd.ie> wrote:
everybody seems to be happy (or tired of it). The second option, I would say! Agreed. I'm definitely not happy with a solution which requires modifying every inetnum record, and I still would like to know from the RIPE DB people if my proposal of returning IRT records by default on inetnum/inetnum6 queries could be considered.
-- ciao, | Marco | [7930 aljXJfLaZqCQc]
On Fri, Sep 10, 2004 at 07:11:53PM +0200, Marco d'Itri wrote:
On Sep 10, Niall O'Reilly <niall.oreilly@ucd.ie> wrote:
everybody seems to be happy (or tired of it). The second option, I would say! Agreed. I'm definitely not happy with a solution which requires modifying every inetnum record, and I still would like to know from the RIPE DB people if my proposal of returning IRT records by default on inetnum/inetnum6 queries could be considered.
I'm also not happy for this to keep going on. As always the strange thing is that during coffee breaks everybody agrees it's an annoying little problem with people spamming you with, mostly not really polite, complaints. But in the end they don't show up. I think Shane's lists looks quite reasonable, although it will impact each and every object, changing the changed: attribute to contain a handle instead of an email address would make a lot of difference as long as the server doesn't resolve the handle by default. Anyway, there is an action point open to see if we can get consensus on this list. If everybody thinks this whole discussion gets more tiresome as the problem we're trying to get rid of, then at least we can close the AP with a small not that we've reached consensus on the fact we're tired of it. Summarizing the options: - implemnt a whole new object and change others to reference it - minor database changes to limit the number of '@' signs returned - use less generic attribute names (still need to work out that one, but major change) - change IRT to make PGP-stuff optional and thus IRT more usable - do nothing and stop this now Grtx, MarcoH
On Sep 10, MarcoH <marcoh@marcoh.net> wrote: > Summarizing the options: > > - implemnt a whole new object and change others to reference it > - minor database changes to limit the number of '@' signs returned > - use less generic attribute names (still need to work out that one, but > major change) > - change IRT to make PGP-stuff optional and thus IRT more usable > - do nothing and stop this now - return by default the less specific irt object for every inetnum/inetnum6 query, if one exists Many of these options are not mutually exclusive, i.e. it's probably a good idea, independently from implementing or not abuse-c, to make PGP attributes in IRT records optional and to make the email address in the changed attribute a free form string (it does not /need/ to reference a person object, as long as people in each organization can agree on what should be put there). Is anybody opposed to these changes? -- ciao, | Marco | [7931 in9oUGNDn6W1g]
On Fri, 2004-09-10 at 19:40, Marco d'Itri wrote:
On Sep 10, MarcoH <marcoh@marcoh.net> wrote:
Summarizing the options:
<SNIP the ones I would not want to see happening at all ;)>
- minor database changes to limit the number of '@' signs returned
Could break some query functionality in case someone has say 5 e-mail lines in one object or one refers to a role object which refers to multiple people etc. Don't think this is really viable. One can download the complete thing using ftp anyways.
- change IRT to make PGP-stuff optional and thus IRT more usable
I would not oppose this, see previous discussions ;)
- do nothing and stop this now
At least the PGP-optional should be fixed.
- return by default the less specific irt object for every inetnum/inetnum6 query, if one exists
Good idea too...
Many of these options are not mutually exclusive, i.e. it's probably a good idea, independently from implementing or not abuse-c, to make PGP attributes in IRT records optional and to make the email address in the changed attribute a free form string (it does not /need/ to reference a person object, as long as people in each organization can agree on what should be put there). Is anybody opposed to these changes?
Nope, changing the e-mail lines to person objects is probably wiser indeed. The whois interface could btw hide all the entries between the first and the last entry? Greets, Jeroen
On Sep 10, Jeroen Massar <jeroen@unfix.org> wrote:
Many of these options are not mutually exclusive, i.e. it's probably a good idea, independently from implementing or not abuse-c, to make PGP attributes in IRT records optional and to make the email address in the changed attribute a free form string (it does not /need/ to reference a person object, as long as people in each organization can agree on what should be put there). Is anybody opposed to these changes?
Nope, changing the e-mail lines to person objects is probably wiser indeed. The whois interface could btw hide all the entries between the first and the last entry?
Why? If you do not want them to appear in the public database you just have to edit your object. -- ciao, | Marco | [7938 alwj72cVVwVrA]
On Fri, Sep 10, 2004 at 07:47:15PM +0200, Jeroen Massar wrote:
- minor database changes to limit the number of '@' signs returned
Could break some query functionality in case someone has say 5 e-mail lines in one object or one refers to a role object which refers to multiple people etc. Don't think this is really viable.
If your query breaks when we stop returning a number of email addresses form the database, you're part of the target audience. There are better ways to find a contact then grepping for email addresses in changed attributes.
One can download the complete thing using ftp anyways.
I can't see that there will be a difference between the objects returned from the whois interface and those in the database dump on the ftp site. Removing email addresses (or censor them) will only have effect when removed in all views.
Many of these options are not mutually exclusive, i.e. it's probably a good idea, independently from implementing or not abuse-c, to make PGP attributes in IRT records optional and to make the email address in the changed attribute a free form string (it does not /need/ to reference a person object, as long as people in each organization can agree on what should be put there). Is anybody opposed to these changes?
Nope, changing the e-mail lines to person objects is probably wiser indeed. The whois interface could btw hide all the entries between the first and the last entry?
Why, it's there with a reason. If it hasn't got a reason we should remove it from the database and not just from the interface. Grtx, MarcoH
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10.09.2004 at 19:47, Jeroen Massar wrote:
attributes in IRT records optional and to make the email address in the changed attribute a free form string (it does not /need/ to reference a person object, as long as people in each organization can agree on what should be put there). Nope, changing the e-mail lines to person objects is probably wiser indeed.
I think it is not wise to use nick handles in changed lines. Why? Because Persons leaves companies and their person objects get removed. What we have then is a very cryptic link into the void and nobody will every guess again, who has changed the object. True, this holds also for email addresses, but most often they are not so cryptic that one cannot deduce who it was who did the the change and at least to which company he belonged. OK, we can make nick handles a mandatory part of the changed lines and provide the DB with a mechanism that prevents from deleting person objects references this way. But would this be worth it? Cheers Hendrik - -- Hendrik T. Voelker HTV5-RIPE MCI EMEA Registrar Team UUNET Deutschland GmbH, Sebrathweg 20, 44149 Dortmund, GERMANY A MCI Company tel+49-231-972-1565 fax+49-231-972-1180 http://www.mci.com/de/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBRZxCUmmTUZJHml0RAmoJAJ99EA2DGYgGbgTLSX23AWfgwIqt1QCfaO70 ezo4QFakV5St4iqaor/pmW4= =jKle -----END PGP SIGNATURE-----
Hi, On Mon, Sep 13, 2004 at 03:10:26PM +0200, Hendrik T Voelker wrote:
OK, we can make nick handles a mandatory part of the changed lines and provide the DB with a mechanism that prevents from deleting person objects references this way. But would this be worth it?
Actually I'm wondering where the proposal "make the changed: line a database-generated timestamp" went to. It could contain things like changed: $timestamp $authorized-by $source (e-mail or IP) like: changed: 20040913-1641 SPACENET-N gert@space.net so this would actually serve as some kind of audit trail for the object. Right now, the usefulness of changed: is questionable, as anybody can put anything inside these lines (as long as the date isn't in the future)... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 66629 (65398) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Sep 13, Gert Doering <gert@space.net> wrote:
Actually I'm wondering where the proposal "make the changed: line a database-generated timestamp" went to.
It could contain things like
changed: $timestamp $authorized-by $source (e-mail or IP) I think some people may want to not publish this kind of information.
-- ciao, | Marco | [7977 co/7MYVDRqOb2]
Hi, On Mon, Sep 13, 2004 at 04:45:50PM +0200, Marco d'Itri wrote:
On Sep 13, Gert Doering <gert@space.net> wrote:
Actually I'm wondering where the proposal "make the changed: line a database-generated timestamp" went to.
It could contain things like
changed: $timestamp $authorized-by $source (e-mail or IP) I think some people may want to not publish this kind of information.
So abandon "changed:-with-e-mail" at all, and replace it by a database-generated "changed: $timestamp" line? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 66629 (65398) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
participants (7)
-
Gert Doering -
Hendrik T Voelker -
Jeroen Massar -
Marco d'Itri -
MarcoH -
Niall O'Reilly -
Wilfried Woeber, UniVie/ACOnet