April 1997 - db-wg - mailman.ripe.net

Inaddr Robot <auto-inaddr@ripe.net>
by Carol Orange 22 Apr '97

22 Apr '97

Dear All, First off, my apologies to all who get more than one copy of this message. I'm hoping not to miss anyone who may be effected. As many of you may know, we have long been planning to more fully automate our inaddr robot <auto-inaddr(a)ripe.net>. Well, we've gotten around to it and are happy to announce we will soon be doing almost all processing automatically, with just a touch of human intervention at the end to make certain our robot behaves as expected. The result will be a substantial reduction in rather tedius work for the NCC staff, and consistent short response times (one working day) for inaddr requests. The new robot, programmed by Mal Morris, will be installed on *** Tuesday, May 6, 1997 *** It is essential that users take the following changes into account: 1. The domain or inetnum database object must be in the RIPE database before the request is submitted to <auto-inaddr(a)ripe.net>. 2. As is required in ripe-140 (Section 3.4.2), the "status" field must be filled in properly for any inetnum associated with the request. The robot will complain and fail if either of these does not hold. We hope the new robot serves you well, Carol

1 0

Re: Proposal for db change
by Wilfried Woeber, UniVie/ACOnet 18 Apr '97

18 Apr '97

David, => Honestly, how about offering that for as long as there is no => authentication interaction? => => As soon as we hit the wall we might have a solution ready or we might => have to *not* offer that comfort for signed or checksummed updates? = =Please, don't get me wrong: I don't have a problem with John's proposed =feature but I wanted to make clear which trade-offs are made and that =there are certainly a few disadvatages involved that might not be obvious =at first sight. that was perfectly understood here. Cheers, Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------

1 0

Re: Proposal for db change
by Wilfried Woeber, UniVie/ACOnet 17 Apr '97

17 Apr '97

Hi John! Thank's for raising that issue. = davidk(a)isi.edu writes: = * = * John, = * = * I am afraid that the people that forget the "source:" field are the same = * people that send a "source: RADB/MCI/whatever" to the RIPE database. You = * will thus get more consistency problems if those people find out about = * the possibility to omit the "source:" field. We are dealing with a set of = * logical different databases and I think that it is better that people = * *know* about this to avoid all the possible confusion about where their = * data is stored and mistakes made by people that have to deal with more = * databases then just the RIPE one. = =The letting them know would occur when they recieve warnings, or in =the case of an incorrect "source:" have the update fail. One of the reasons why we insist on a source: field is the dream(?) of eventually having a system where we can submit updates to our local/favourite/whatever registry (db update mechanism) and have the update automatically forwarded to the "correct" registry. Of course, it's still a dream... I'd like to get input whether the user community would prefer more "comfort" locally and to trade in some future functionality... =People are clearly told that they need to put in a source field in the =documents, the ones I see most are where people forget to add a source =field, even if they know about the different databases. They just =forget, a warning should be enough for these people to remember =next time. I tend to agree. = * Another problem is that many people don't really like the automatic = * fiddling with their objects which also makes it very hard to do things = * (in the future) like signing objects by the user itself and storing them = * as-is including the signature in the database. = =We do this already with some fields. inetnum gets changed if they =send in ... = =inetnum: 194.0.1.0 = =or = =inetnum: 194.0.1.0/24 = =... to = =inetnum: 194.0.1.0 - 194.0.1.255 That's an interesting aspect. (Actually, only the "classful" update would be expanded, isn't it?) Which indeed adds another facette to an authentication environment ;-) But we might be able to solve that by disallowing "classful" *updates* as soon as we offer authentication. Please note that I don't see a problem in *replacing* any existing "classful" object by a signed new object. Or do I miss something? >The changed field can also be fiddled with, i.e if the date is in >the future. I think this should be solved while implementing the automatic UTC (and source) tagging. As soon as we have that in place, I do no longer see a reason to touch any user-supplied data in the changed field(s). >These are both cases where the database needs a particular format >and can therefor make the change. I would suggest that the "source:" >could be a similar case. > >Is there a reason that I am missing why the "source:" differs >from these when it comes to "signatures" etc. That's true. Although I'd like to limit "automatic" modifications, anyway. > * On the other hand I really like this since I am a lazy person and I have > * to admit that I have a local db running as my address book that does > * exactly the thing that you propose ... Me too! (Ok, get these flame throwers set up :-) Honestly, how about offering that for as long as there is no authentication interaction? As soon as we hit the wall we might have a solution ready or we might have to *not* offer that comfort for signed or checksummed updates? Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------

2 1

Proposal for db change
by John LeRoy Crain 17 Apr '97

17 Apr '97

Hello folks, I was sitting here getting annoyed at people who forget to add "source:" fields when I had a thought; Would it be useful to have the "source:" field added automatically when people forget it? I am assuming here that all updates to auto-dbm(a)ripe.net should contain "source: RIPE". The update could take place and a warning could be issued. _______________________ Warning "source:" field missing The field "source: RIPE" has been added to your object. _______________________ My experience is that many people forget to add "source:" fields and the objects get rejected. As the field should always be the same would it not be useful to update it and generate a warning? Your opinions would be appreciated, Kind regards, John Crain RIPE NCC

2 3

Re: Tools based on whois -t output.
by Wilfried Woeber, UniVie/ACOnet 14 Apr '97

14 Apr '97

= "Mike Norris" <mnorris(a)hea.ie> writes: = * = * Good idea, Ambrose. I presume the asterisk is a = * place-holder and will appear in the case of attributes = * that are neither look-up nor inverse keys? = =Yes. The aim is to make the output easier to read. I =suppose an "-" character or a blank space could be used =instead. I will think about it. I'd ask you to come up with a somewhat consistent format. A blank by itself doesn't sound like a good idea from the SW engineering point of view. How about having the brackets anyway, but no tag inside, or a hyphen, or an asterisk. I think it would be easier to parse in the end, if we can expect a constant number of (non-blank :-) fields. Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------

4 3

Changing rrdb objects in the future
by Joe Abley 14 Apr '97

14 Apr '97

Apologies if this is the wrong forum to bring this up... It would appear that current implementations of the e-mail gateway which lets you update RR records impose a restriction on the date field to prevent people from entering dates that appear to be in the future - records like that are returned with an error. This is a bit of a pain for people in NZ and Australia, who are typically 18-20 hours ahead of RR machines located in the US, and are hence generally the date is a day ahead. It means that every time we make an update to an RR, we have to date the modification with the previous day's date. Now this isn't a really serious problem or anything, but it is annoying. Could the RRDB not store date and time records in (say) UTC, and convert local times supplied with timezones before sanity-checking dates that appear to be in the future? Joe -- Joe Abley <jabley(a)clear.co.nz> CLEAR Communications Ltd Systems Engineer, ISD http://www.clear.co.nz/

3 3

Re: Changing rrdb objects in the future
by Wilfried Woeber, UniVie/ACOnet 14 Apr '97

14 Apr '97

=At 02:46 PM 4/08/97 -0400, you wrote: =>At the last ripe meeting it was agreed to track object history =>including UTC time zone, although I'm not entirely clear what this =>means. Presumebly it means that the changed field will be stamped =>automatically by the db software with utc time and the from =>line of the email. = =That would certainly sort it out. The RIPE-DB WG proposed to have the db update mechanism *automatically* tag objects being updated with a UTC timestamp (and some other data). This data would *not* be under the control of the submitting entity. It is not meant to replace or modify any data in the changed: field as supplied by the submitting entity. This change is already on the RIPE-NCC's to-do-list for implementation. => I think another holdup is the issue of the millenium approaching. =>The current date format (ie, YYMMDD) will be insufficient for those =>future dates. And so this problem must be fixed too. => I would think that YYYYMMDD is an obvious solution. The RIPE DB production software already accepts objects with the extended 8 character format. =That will take care of the y2k problem, but won't help those of us in =unusual time zones... For that we would need something like YYYYMMDDHHMMZZZ =(ZZZ=time zone). This is a bit more of a mouthful, of course. I think local time details (time zones, DST, whatever) should become a non-issue as soon as we get the changed: data decoupled from the UTC time stamps as applied by the db update process? =>The db software =>will be converted from ripe181 to rpsl over the coming 6 months. =>Maybe when the db's are officially changed to rpsl we can update =>the objects from YYMMDD --> YYYYMMDD format. => =>ps Yes, this is exactly the correct forum to bring this up. = =Good :) Although I wonder whether it would be useful and more consistent to convert all the exiting objects from the 6 character to the 8 character format and to expand the 6 character format on the fly during the update processing... Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------

1 0

Tools based on whois -t output.
by RIPE Database Administration 09 Apr '97

09 Apr '97

Hi, all ! We are contemplating changing the output of the "-t" option of "whois" to give more information. Please inform us if you write or use tools based on this output. Example: The current output for "-t person" is person: [mandatory] [single] address: [mandatory] [multiple] phone: [mandatory] [multiple] fax-no: [optional] [multiple] e-mail: [optional] [multiple] nic-hdl: [optional] [single] remarks: [optional] [multiple] notify: [optional] [multiple] mnt-by: [optional] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single] the new output would be person: [mandatory] [single] [look-up key] address: [mandatory] [multiple] * phone: [mandatory] [multiple] * fax-no: [optional] [multiple] * e-mail: [optional] [multiple] [look-up key] nic-hdl: [optional] [single] [look-up key] remarks: [optional] [multiple] * notify: [optional] [multiple] [inverse key] mnt-by: [optional] [multiple] [inverse key] changed: [mandatory] [multiple] * source: [mandatory] [single] * where [look-up key] indicates that you use this attribute as an argument to whois and [inverse key] indicates that you can use the attribute as an argument to whois -i. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

3 3

Database Inconsistencies
by Carol Orange 07 Apr '97

07 Apr '97

Hi all, At the January meeting of the RIPE Database WG, I promised to post the reports on RIPE Database inconsistencies produced by the group of students at the Free University last fall. The reports are now on our ftp site and can be found in: "Problem Definition" ftp://ftp.ripe.net/ripe/dbase/info/consistency1.ps ftp://ftp.ripe.net/ripe/dbase/info/consistency1.txt "The RIPE Database: Constraints and possible Solutions" ftp://ftp.ripe.net/ripe/dbase/info/consistency2.ps ftp://ftp.ripe.net/ripe/dbase/info/consistency2.txt Greetings, -- Carol

1 0

"Fake" records in RIPE DB
by RIPE Database Administration 07 Apr '97

07 Apr '97

Hi, Gabor ! I have traced the source of the problem and have contacted those responsible. Thank you for informing us. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

1 0