- lir-wg - mailman.ripe.net

Changing old format dates in the RIPE DB
by Joao Luis Silva Damas 24 Jun '99

24 Jun '99

Dear all, we are going to start with the procedure to modify all the dates in the changed fields of database objects that were using only two figures for the year. After the modifications, the year part of the date will contain 4 digits. Changed fields which currently do not have a date will not be changed (*) This is taking place according to the action points agreed on the Vienna RIPE meeting. The process will be carried over the next few days due to the time it takes to re-index some of the bigger files. Regards, Joao Damas DB Group RIPE NCC (*) These objects will not be updatable by the user unless a date is included at update time or the only changed field without a date is the last one, in which case the database automatically fills in the date at which the update takes place.

1 0

Update processing delayed
by RIPE Database Administration 22 Jun '99

22 Jun '99

Dear Colleagues, the database is very loaded now, due to some huge updates sent tonight. The queue of waiting updates is very long and you should be prepered for waiting times of several hours before your update gets processed. Please do not resend your updates. Thank you for your patience. If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, Roman Karpiuk ____________________________ The RIPE NCC Database Group.

1 0

Re: RE: admin-c in inetnum
by Hostmaster DE-NIC 21 Jun '99

21 Jun '99

Sehr geehrte Damen und Herren, dies ist eine automatisch generierte Antwort zum Thema Update von Domain- bzw. Personendaten (RIPE-Handles). Anforderungen zum Update von Domain- bzw. Personendaten werden grundsaetzlich nur von dem DENIC-eG Provider entgegengenommen, der die Domain bei uns beantragt hat. Dies hat folgende Vorteile: - Daten werden an einer Stelle gesammelt und koordiniert. - die Daten werden vor missbraeuchlichen Aenderungen durch Dritte geschuetzt, da das DENIC nicht in der Lage ist, die Berechtigung desjenigen, der die Datenaenderung anzeigt, zu verifizieren. - die techn. Implikationen, z.B. bei Aenderung vom Nameserversatz (Update bei den Secondaries ...) werden beruecksichtigt. - Ihr Provider verfuegt z.T. ueber automatische Tools zur Aenderung der Datensaetze, d.h. der Update erfordert keine manuellen Eingriffe bei uns. Bitte wenden Sie sich aus oben genannten Gruenden zur Koordination nur an Ihren Provider; wir nehmen keine Dnderungen vor, die nicht von einem DENIC-Mitglied bei uns eingehen. viele Gruesse Ihr DENIC (Automatical Departement) P.S. Weitere Informationen zur Dnderung des RIPE-Handles finden Sie auch auf folgenden Seiten: http://www.ripe.net/docs/ripe-157.html http://www.ripe.net/docs/ripe-189.html +-----------------------------------+--------------------------------+ | DENIC eG | Phone: +49 69/27235-272 | | Wiesenhuettenplatz 26 | Fax: +49 69/27235-235 | | D-60329 Frankfurt am Main | E-Mail: hostmaster(a)denic.de | | Germany | http://www.denic.de | | | | | don't hesitate to contact us ... | | +-----------------------------------+--------------------------------+ > Return-path: <owner-lir-wg(a)ripe.net> > Envelope-to: hostmaster(a)nic.de > Delivery-date: Mon, 21 Jun 1999 14:35:02 +0200 > Received: from postman.ripe.net [193.0.0.199] > by denics4.denic.de with smtp (Exim 1.82 #1) > id 10w3Hy-0007A0-00; Mon, 21 Jun 1999 14:35:02 +0200 > Received: (qmail 9953 invoked by alias); 21 Jun 1999 12:36:37 -0000 > Delivered-To: lists-lir-wg-out(a)lists.ripe.net > Received: (qmail 9950 invoked by uid 66); 21 Jun 1999 12:36:37 -0000 > From: Ralph.Hall(a)swisscom.com > Message-ID: <21C15D5AE757D011AFBF0000F830A4A903DDF01F(a)gd3i5y.swissptt.ch> > To: lir-wg(a)ripe.net > Subject: RE: admin-c in inetnum > Date: Mon, 21 Jun 1999 14:36:32 +0200 > MIME-Version: 1.0 > X-Mailer: Internet Mail Service (5.5.2232.9) > Content-Type: text/plain > Sender: owner-lir-wg(a)ripe.net > Precedence: bulk > > I welcome proposal to remove the constraint on admin-c. Now entering the > virtual age, reachability is key, not physical location (I carry my phone > around with me most of the time). Even more so for those LIR's that are > becoming more international. > > Kind regards > Ralph > >

1 0

RE: admin-c in inetnum
by Ralph.Hall＠swisscom.com 21 Jun '99

21 Jun '99

I welcome proposal to remove the constraint on admin-c. Now entering the virtual age, reachability is key, not physical location (I carry my phone around with me most of the time). Even more so for those LIR's that are becoming more international. Kind regards Ralph

1 0

[Fwd: FW: admin-c in inetnum]
by andreas perret 17 Jun '99

17 Jun '99

-------- Original Message -------- Betreff: FW: admin-c in inetnum Datum: Thu, 17 Jun 1999 10:08:17 +0100 Von: marcus.nutting(a)theplanet.net An: lir-wg(a)ripe.net We mostly use the same name for admin-c and tech-c at the moment. Sometimes using a customer name for admin-c. I think that admin-c should be optional. Perhaps if our customers want some point of contact. -----Original Message----- From: owner-lir-wg(a)ripe.net [mailto:owner-lir-wg@ripe.net]On Behalf Of Paula Caslav Sent: Wednesday, June 16, 1999 8:56 AM To: lir-wg(a)ripe.net Subject: admin-c in inetnum Hello all, It's good to see so much discussion. Just to clarify something, the admin-c can be a role object. This is something that was decided 1 or 2 RIPE meetings ago. The latest release of the database code supports this fully now. When you do a recursive look-up of an inetnum object you will now see any role objects that were referenced in the admin-c attribute (in the past you would only see role objects referenced in tech-c but not admin-c). I will wait until the end of the week for responses, and then try to summarize the views here and come up with a suggestion. Kind regards, Paula Caslav RIPE NCC

1 0

FW: admin-c in inetnum
by Marcus Nutting 16 Jun '99

16 Jun '99

We mostly use the same name for admin-c and tech-c at the moment. Sometimes using a customer name for admin-c. I think that admin-c should be optional. Perhaps if our customers want some point of contact. -----Original Message----- From: owner-lir-wg(a)ripe.net [mailto:owner-lir-wg@ripe.net]On Behalf Of Paula Caslav Sent: Wednesday, June 16, 1999 8:56 AM To: lir-wg(a)ripe.net Subject: admin-c in inetnum Hello all, It's good to see so much discussion. Just to clarify something, the admin-c can be a role object. This is something that was decided 1 or 2 RIPE meetings ago. The latest release of the database code supports this fully now. When you do a recursive look-up of an inetnum object you will now see any role objects that were referenced in the admin-c attribute (in the past you would only see role objects referenced in tech-c but not admin-c). I will wait until the end of the week for responses, and then try to summarize the views here and come up with a suggestion. Kind regards, Paula Caslav RIPE NCC

1 0

Re: admin-c in inetnum
by Xlink Netmaster 16 Jun '99

16 Jun '99

Hi, our expectations regarding admin-c are that it is a person sufficiently elevated in the organisation to do sth about things if you threaten the organisation with a hit squad^W^W^Wlawyers. If there are technical problems I expect the tech-c to handle things. kind regards, Petra Zeidler -- i.A. Petra Zeidler, Neukundenanschluss Xlink Internet Service GmbH [X] zeidler(a)xlink.net [X] Tel: 0721/9652-220 [X] Fax: 0721/9652-209 [X] Geschaeftsfuehrer: Michael Rotert. Amtsgericht Karlsruhe HRB 8161. [X] Auftraege erledigen wir zu unseren Allgemeinen Geschaeftsbedingungen.

1 0

Re: admin-c in inetnum
by SAEED KHADEMI 16 Jun '99

16 Jun '99

Hello all, It seems that some of our friends are thinking that admin-c should or must know about technical aspects. If it is the case, why should we have tech-c? Kind Regards, Saeed.

4 3

admin-c in inetnum
by Paula Caslav 16 Jun '99

16 Jun '99

Dear Registries, Please note that this message is send to both the lir-wg and the local-ir mailing lists. We would like all discussion to take place on the lir-wg mailing list only. We are re-evaluating the usage of the admin-c field in the inetnum database object. This is what ripe-185 currently says about the admin-c field: The administrative person specified in the admin-c field must be physically located at the site of the network. The person does not have to have technical knowledge of the network. The technical person specified in the tech-c field may be a network support person located on site, but could also be a consultant that maintains the network for the organisation. In both cases, more than one person can be specified. We are wondering how the admin-c field is used in practice, and whether it is really necessary for the administrative contact to be on-site. Usually when something goes wrong with a network, people are meant to try the technical contact to get things fixed. If that person cannot be reached, however, the administrative contact should be somebody responsible for the network who can in an emergency find someone who can take care of the problems. The administrative person does not have to have technical knowledge of the network, but should know who to contact in case of problems. For this purpose it is not strictly necessary for the administrative contact to be on-site. We therefore propose a change to the policy- that the administrative contact should be somebody who is responsible for the network, but does not necessarily need to be on-site. Please let us know your thoughts on this, we would especially like to hear how these fields are used in real-life. Have you ever had the need to contact the admin-c? Is it usefull for that person to be on-site or not? Kind regards, Paula Caslav RIPE NCC

8 7

Adding nic handles to objects without one
by Joao Luis Silva Damas 16 Jun '99

16 Jun '99

Dear all, as discussed and agreed to during discussions in the mailing lists and at the RIPE Meeting in Vienna, the RIPE NCC will be adding newly generated NIC handles to person objects that do not currently have one. Over the last days we have been testing the procedures to do this in a non-disruptive way. Unfortunately, due to the nature of the current database, the process needs about 5 hours to run. Due to this and to avoid interactions with nightly jobs that create several copies of the files, including the ftp site and the full text search indexes, we will stop updates tomorrow Tuesday at 19:00 (Amsterdam time). This will cause all updates to the DB sent after 19:00 to be queued for later processing that night. There is no need to send updates more than once. Queries will not be affected. That is, the whois server will keep answering queries normally. During the process, objects without nic handles will get unique new ones and also a "changed" attribute will be added with tomorrow's data and ripe-dbm(a)ripe.net as the author of the change. This is for future reference. If you have any questions, please do not hesitate to contact us. Best regards, Joao Damas DB Group RIPE NCC

2 1