- db-wg - mailman.ripe.net

Top 100 Maintainers List - 19990820
by RIPE Database Manager 24 Aug '99

24 Aug '99

4 5

Top 100 Maintainers List
by RIPE Database Manager 04 Aug '99

04 Aug '99

2 1

Re: Interesting object in the RIPE database
by Steven Bakker 11 Jul '99

11 Jul '99

>>>>> On Wed, 7 Jul 1999, "RLE" == Robert_Martin-Leg=E8ne wrote: RLE> Doesn't mean that it makes sense in the IP Registry world. Let's be RLE> practical. And besides, classful addressing is a Thing of the Past (ahem). The BSD way of doing it is clever, but complicated and it has no place in the DB, IMO. I always understood that the DB software would pad missing octets at the end of an IP address, no ambiguity there. What I'm surprised about is that the DB apparently allows someone to register address space that's most likely not even theirs... Of course, once it gets allocated and entered into the DB, a conflict will be detected and flagged (right!?), but until then, the error will go undetected. Is this a feature? Cheers, Steven

4 3

Interesting object in the RIPE database
by Niels Bakker 07 Jul '99

07 Jul '99

Hi, I noticed the following object in the RIPE database this afternoon: inetnum: 195.59.213.0 - 213.127.0.255 netname: WILLIAMBROOKES-TF13-GW descr: William Brookes School country: GB admin-c: PC2598-RIPE tech-c: IH22-ORG rev-srv: ns0.insnet.net rev-srv: ns1.insnet.net status: ASSIGNED PA mnt-by: AS5378-MNT changed: cliveg(a)insnet.net 19990706 source: RIPE (I stumbled over it while querying the RIPE database for an object within the APNIC database while accidentally omitting the -a option.) Clive Galway (the creator of this object) told me after I contacted him that he had entered the following information into the template: 195.59.213.0 - 213.127 instead of 195.59.213.0 - 195.59.213.127 He added, "funny that it dont complain though" - I agree wholeheartedly with him here. :) A check for the number of dots in the inetnum: line should be quite easy, and similar to this: # fix for people who don't include the first two or three octets s/^(\d+\.\d+)\.(\d+\.\d+) - (\d+\.\d+)$/$1.$2 - $1.$3/ s/^(\d+\.\d+\.\d+\).(\d+) - (\d+)$/$1.$2 - $1.$3/ if ($_ =~ /^\d+\.\d+\.\d+\.\d+ - \d+\.\d+\.\d+\.\d+$/) { &complain; } I believe there is a sub to check whether something is a valid IP address but can't find it offhand in my (by now pretty dated) copy of the RIPE database software... With regards, -- Niels Bakker, * * EuroNet Internet BV Network Operations * * Herengracht 208-214 * 1016 BS Amsterdam NJB9 * +31 (0)20 535 5555

3 2

Converting named references to NIC handle references
by Engin Gunduz 29 Jun '99

29 Jun '99

Dear collegues, As discussed and agreed to in the mailing lists, we will be converting unambiguous named references in the admin-c and tech-c fields of as-macro, autnum, community, dom-prefix, inet-rtr, mntner and role objects to NIC handle references, on 1 July, 1999, at 17:00, GMT. The process will take around half an hour, and during the process the updates will be queued. Whois queries will not be affected. The maintainers of the affected objects will get notifications about the changes. The conversion on domain and inetnum objects will be done at a later date, due to substantial time they require for this process. If you have any questions, please do not hesitate to contact us. Regards, Engin Gunduz RIPE NCC DB Group

1 0

T1
by OrderOffice - ICP Lueck und Lanzrath GbR 25 Jun '99

25 Jun '99

T1

1 0

address field limitation???
by Pedro Goncalves 25 Jun '99

25 Jun '99

Hi I would like to know what is the char limit (if any) for the address field. Some of my submitions apparently where returned because of the usage of more than 64 chars. Best regards Com os melhores cumprimentos. Pedro Gonçalves Telepac, SA Tel: 351-1-7907354 Fax: 351-1-7907001

2 1

Re: Modifying references to contact info in the RIPE DB
by Wilfried Woeber, UniVie/ACOnet 24 Jun '99

24 Jun '99

Hi Joao! >If the reference is by name then when I query the DB I will get the list of >persons with that name, right? Right. >Whether the object belongs to the person or not is not going to save this >person from being contacted. From the point of view of the database and the >user querying it, the object belongs to that person. Right >The link is via a name. > >Now we substitute the reference by name with a reference by nic handle >pointing to the same person. >What is the difference? > >ALMOST NONE except that: True, for the case where there is a strict one-to-one mapping, e.g the recursion using the name returns *one* object. What do you suggets to do with the case where the recursion, based on the names, returns a *set* of objects? I can see 2 approaches (at least): - do not perform the handle substitution for that referring object and put it on the list of those requiring human intervention - expand the xxxx-c: list (which? the tech-c:?) to refer to *all* objects, but by ref'ing their handles While human beings are quite clever in selecting the "proper" instance of a person: object (by looking at country, address, email,...) a script might be quite clueless with that respect :-) Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB (&NIC) Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 --------------------------------------------------------------------------

3 2

Re: Modifying references to contact info in the RIPE DB
by Wilfried Woeber, UniVie/ACOnet 24 Jun '99

24 Jun '99

>I explicitly excluded those objects from this run. Great. >I knew this thing was going to be a bit polemic so I am trying to split into >smaller problems and stages that we can all agree to. Well, complex, at least. I fully support your approach! >Hopefully every step will reduce the number of objects that need repairs. And >believe me, it's not the same to have to fix 250000 objects than to fix 25000. >Somehow the latter seems a bit more feasible (from a "let's deal with this" >attitude). Certainly. >So, can we agree to proceed with our suggestion as stated below? >** >Change references by names to references by nic handle where these are unique >(there are not already more than two persons with the same referenced name). >** I agree. >For the cases where the ambiguity is already there: we'll look at them, try to >categorize them Sounds interesting. I really like the approach taken by Poul-Henning with his IP address page. Maybe we can come up with a similar list, e.g. categorized by object type, and within the object type by LIR, TLD, AS-#, Maintainer... >and maybe identify another subset which can be handled by >drawing information from some other source. >We'll get back to you with our suggestion (and we take the two you mention as >input). Any input is most welcome. Wilfried.

1 0

Re: Modifying references to contact info in the RIPE DB
by Janos Zsako 24 Jun '99

24 Jun '99

> From owner-db-wg(a)ripe.net Thu Jun 24 15:23:02 1999 > From: Joao Luis Silva Damas <joao(a)ripe.net> > ALMOST NONE except that: > from that point on if someone else with a name equal to one already in the > database is entered into the database the reference will not be made ambiguous > while if we leave it as a reference by name it sure becomes ambiguous. I agree with Joao that there is virtually nothing to lose. I don't think it is better to have a reference by name with a single incorrect instance of a person object with that name, rather than a NIC-handle reference to the same incorrect instance... (By incorrect instance I mean a person object with the same name, but who has nothing to do with the referring object). At the same time the benefit is obvious (see above). Also, the longer one delays this process, the better the chances to have several instances to be handled manually (i.e. to try to identify the correct person object from several ones with the same name). Just my 2 filler (.01 HUF). :)) Janos

1 0