From phk at critter.freebsd.dk Thu Jun 3 11:30:29 1999 From: phk at critter.freebsd.dk (Poul-Henning Kamp) Date: Thu, 03 Jun 1999 11:30:29 +0200 Subject: Tagging of IP adresses / Application-Database In-Reply-To: Your message of "Wed, 26 May 1999 21:46:48 +0200." Message-ID: <2198.928402229@critter.freebsd.dk> I'm sorry for my inactivity on this subject, but let me just try to get this back to basics: The only thing I wanted was an attribute which said "SMTP connections from these IP numbers shouldn't happen" As it is today, we pretty indiscriminantly reject email from the dial-in ports of a large number of (mostly USAnian) ISPs to limit the amount of SPAM. All I wanted was to enable ISP's to cooperate on this tactic against "hit and run" spammers. -- Poul-Henning Kamp FreeBSD coreteam member phk at FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! From joao at ripe.net Fri Jun 4 11:12:45 1999 From: joao at ripe.net (Joao Luis Silva Damas) Date: Fri, 04 Jun 1999 11:12:45 +0200 Subject: New RIPE DB sw version Message-ID: <199906040912.LAA23036@x41.ripe.net> Dear all, the RIPE NCC is happy to announce version 2.3 of the RIPE Database software. This new version introduces complete support for the IPv6 address objects. Only the RIPE NCC can introduce objects with value ALLOCATED in the status field of IPv4 address objects. This reflects the current registration policy. Some other minor features and a number of bug fixes have been introduced. For more details, please see the release notes included below and on the software package. This new version is available immediately from ftp.ripe.net and will be used on whois.ripe.net starting next Monday (7th June). Regards, Joao Damas DB Group RIPE NCC -------------- next part -------------- RELEASE NOTES for RIPE Database 2.3 This a new release with substantial new features added. There are also some bug fixes and some operational enhancements. SUPPORTED SYSTEMS This release has been tested with perl 5.004_04 on bsdi3.1 and Solaris 2.6 systems. Please let us know if you have problems running it on other systems. NEW FEATURES Changes on inet6num object: - mnt-lower attribute has been added to the inet6num object, so that users will be able to use hierarchical authorisation with inet6num objects. - status attribute has been added to the inet6num object. It is a generated attribute. Possible values are TLA, SUBTLA, NLA and SLA (Top Level Aggregator, Sub-TLA, Next Level Aggregator and Site Local Aggregator). o inet6num objects with a prefix length between 4 and 15, inclusive, are assigned TLA in their status attribute. o For TLA 0x0001 (first two bytes are 2001 in hexadecimal notation): o prefixes between 16 and 35, inclusive, are assigned SUBTLA value in status attribute. o prefixes between 36 and 48, inclusive, are assigned NLA value in status attribute. o prefixes between 49 and 64, inclusive, are assigned SLA value in status attribute. o For TLAs other than 0x0001: o prefixes between 16 and 24, inclusive, are not allowed, since they are reserved bits. o prefixes between 25 and 48, inclusive, are assigned NLA value in status attribute. o prefixes between 49 and 64, inclusive, are assigned SLA value in status attribute. o inet6num objects with a prefix length grater than 64 are not allowed. - Only aggregatable global unicast address blocks can be registered in the database (the most significant three bits are 001). A check has been added for updates of inetnum objects. Only certain maintainers are allowed to add inetnum objects with status ALLOCATED now, others should use ASSIGNED. The list of authorised maintainers is set in the configuration file with the following syntax ALLOCMNT [ ...] Instead of putting many mntners in this line, the setting can span many lines. INCLUDE facility. A possibility of splitting the configuration file into separate files has been added. The syntax is INCLUDE Inclusion may be nested (up to the number of free file descriptors). If the does not contain a "/" sign, it is considered to refer to a file from the same directory as the main configuration file. newdb changes. The newdb program has been modified, a few minor bugs have been fixed. Now, if a database file exists, newdb -a prints a warning message and skips that file (before, it would stop with an error). New syntax checks. The regular expression passed in the auth attribute like follows auth: MAIL-FROM is now subject to new syntax checks. Missing regexp is signaled with an error, a whitespace in the regexp triggers a warning. All e-mail addresses in various attributes of the database (upd-to, e-mail, guardian, mnt-nfy, notify) are checked. If they match the AUTOBOX address then the object is rejected to prevent mail loops. MAINTENANCE RELATED CHANGES New log file was introduced which logs values given to whois client on the command line. No timestamp and no query source information is logged. When running in test mode server sends additional RFC822 header line containing the original recipient address a message would be sent to in normal mode of operation. BUG FIXES After a hierarchical authorisation failure an erratical notification was sent to maintainer of the object stating that creation was succesfull while in fact it wasn't. At the same time a proper acknowledge message was sent informing about an authorisation failure. This was corrected and false notification is not sent anymore. From joao at ripe.net Mon Jun 14 16:05:26 1999 From: joao at ripe.net (Joao Luis Silva Damas) Date: Mon, 14 Jun 1999 16:05:26 +0200 Subject: Adding nic handles to objects without one Message-ID: <199906141405.QAA15248@x41.ripe.net> 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 at 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 From paula at ripe.net Tue Jun 15 10:35:22 1999 From: paula at ripe.net (Paula Caslav) Date: Tue, 15 Jun 1999 10:35:22 +0200 Subject: admin-c in inetnum Message-ID: <199906150835.KAA12642@x30.ripe.net> 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 From mike.norris at heanet.ie Tue Jun 15 15:51:32 1999 From: mike.norris at heanet.ie (mike.norris at heanet.ie) Date: Tue, 15 Jun 1999 14:51:32 +0100 Subject: admin-c in inetnum In-Reply-To: <3F2D1A940FB8D1118A1F0060978361290B3F15@ntserver.heanet.ie> Message-ID: <3F2D1A940FB8D1118A1F0060978361290AA113@ntserver.heanet.ie> Paula thanks for polling us on this one. As owners of inetnum objects, we (HEAnet) would have more degrees of freedom if the admin contact did not have to be on-site, and I think admin-c might also enjoy the greater latitude. >From the other perspective i.e. that of someone using the database to identify an admin contact for a network, I don't regard it as important whether the admin-c is on-site or not. If I need to contact someone on-site, I'll go for the tech-c. Besides, nowadays coordinates such as e-mail and GSM numbers tend to render meainingless the distinction between on-site and off-site. In conclusion, I would not be unhappy if the on-site requirement for the admin-c was dropped. Regards. Mike > -----Original Message----- > From: owner-lir-wg at ripe.net [mailto:owner-lir-wg at ripe.net]On Behalf Of > Paula Caslav > Sent: Tuesday, June 15, 1999 9:53 AM > To: lir-wg at ripe.net > Cc: local-ir at ripe.net > Subject: admin-c in inetnum > > > > 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 > From woeber at cc.univie.ac.at Tue Jun 15 16:07:54 1999 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 15 Jun 1999 16:07:54 MET-DST Subject: admin-c in inetnum Message-ID: <009D9AD1.B0D3245C.1@cc.univie.ac.at> Hi Paula! Interesting question... >The administrative person specified in the admin-c field must be >physically located at the site of the network. Reviewing some of my most recent assignments, I have to conclude that this requirement is broken. E.g. where to "find" a suitable admin-c for a regional school network? The responsible people, and thus the admin-c: are civil servants located in some admin building. The network itself is serving all the schools across a county/region/federal state. Only occasionally would the admin-c be geographically co-located with (parts of the) network. I suppose a more reasonable requirement would be to have the admin-c "belong" to the organisation requesting address space. Btw, I'm working with that requirement for xx.ac.at domains, too. It has proven to be sensible. Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber at 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 -------------------------------------------------------------------------- From saeed at vax.ipm.ac.ir Tue Jun 15 12:18:49 1999 From: saeed at vax.ipm.ac.ir (SAEED KHADEMI) Date: Tue, 15 Jun 1999 13:48:49 +0330 Subject: admin-c in inetnum Message-ID: <009D9ABE.4291FB20.6@ROSE.IPM.AC.IR> Dear Paula, >We are wondering how the admin-c field is used in practice, Well, According to my experiment ( app. 5 years ), it happens frequently that organizations are changing their technical people without inform us about it. In these cases, none of administratives have changed. So when I want to contact tech-c, and I get error msg which says "USER NOT FOUND", I have to contact to admin-c. Now if admin-c is not located at site, he may not know about new assignments in the organization. Besides, some registries are charging their customers for their registration operations. For official payments, it is neccessary that some authorative person who is working on site, approves the payment, ( it is regular law in my country ). I suggest to keep the policy as it is now. Kind Regards, Saeed. From phk at critter.freebsd.dk Tue Jun 15 11:53:25 1999 From: phk at critter.freebsd.dk (Poul-Henning Kamp) Date: Tue, 15 Jun 1999 11:53:25 +0200 Subject: admin-c in inetnum In-Reply-To: Your message of "Tue, 15 Jun 1999 10:35:22 +0200." <199906150835.KAA12642@x30.ripe.net> Message-ID: <5887.929440405@critter.freebsd.dk> >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? I have several times had to contact admin-c people, and generally found that more often than not they had no idea where I had gotten their name from and what they had to do with it. In one case the phone number listed was the "secret emergency mobile phone" of the CEO for a $1B multinational company, but he was very polite about it :-) I generally assume that the admin-c would be able to kick the tech-c around if need be. I also generally assume that issues of legal and/or political substance belongs with the admin-c rather than the tech-c. I've had a couple of cases where a tech-c was way out of bounds (hacking, mail-bombing etc etc), and complaining to the tech-c is unlikely to work in such cases, in both cases the admin-c handled the case. It would be nice if the admin-c represented a management capability (in the legal sense of the concept) for the org/company. -- Poul-Henning Kamp FreeBSD coreteam member phk at FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! From phil at pavilion.net Tue Jun 15 17:15:40 1999 From: phil at pavilion.net (Phil Duffen) Date: Tue, 15 Jun 1999 16:15:40 +0100 Subject: admin-c in inetnum In-Reply-To: <199906150835.KAA12642@x30.ripe.net>; from Paula Caslav on Tue, Jun 15, 1999 at 10:35:22AM +0200 References: <199906150835.KAA12642@x30.ripe.net> Message-ID: <19990615161540.B8687@pavilion.net> One problem I've found with setting up customers as admin-c others may have come across - they move! I've found several have left the company, changed email address etc Seldom are we informed of these changes. What is the reasoning for the requirement that the admin-c be physically on site. If it is to be able to 'disconnect' their network from the Net, ie to turn off their router. If so then their isp should be able to do this, either by shutting down a router interface or disabling their dial-up account. I would also wager that quite a few admin-c's if contacted would a. Panic :) b. Try and contact their ISP c. Not be available, see above. As you have probably gathered I am in favour of dropping this on-site requirement for the admin-c. On Tue, Jun 15, 1999 at 10:35:22AM +0200, Paula Caslav wrote: > > We are re-evaluating the usage of the admin-c field in the inetnum > database object. > -- ------------------------------------------------------- P h i l D u f f e n S y s t e m s M a n a g e r t e l +44 (0)845 333 5000 f a x +44 (0)845 333 5001 e - m a i l phil at pavilion.net ------------------------------------------------------- From mh at graphnet.fr Tue Jun 15 22:25:11 1999 From: mh at graphnet.fr (Michael Hallgren) Date: Tue, 15 Jun 1999 22:25:11 +0200 Subject: admin-c in inetnum In-Reply-To: <009D9AD1.B0D3245C.1@cc.univie.ac.at>; from Wilfried Woeber, UniVie/ACOnet on Tue, Jun 15, 1999 at 04:07:54PM +0000 References: <009D9AD1.B0D3245C.1@cc.univie.ac.at> Message-ID: <19990615222511.A469@graphnet.fr> On Tue, Jun 15, 1999 at 04:07:54PM +0000, Wilfried Woeber, UniVie/ACOnet wrote: > Hi Paula! > > Interesting question... > > >The administrative person specified in the admin-c field must be > >physically located at the site of the network. > > Reviewing some of my most recent assignments, I have to conclude that > this requirement is broken. E.g. where to "find" a suitable admin-c for > a regional school network? The responsible people, and thus the admin-c: > are civil servants located in some admin building. The network itself is > serving all the schools across a county/region/federal state. > Only occasionally would the admin-c be geographically co-located with > (parts of the) network. > > I suppose a more reasonable requirement would be to have the admin-c > "belong" to the organisation requesting address space. As a role account, for example (a well managed role account that is). Of course, some admin. overhead, but ?? Michael > > Btw, I'm working with that requirement for xx.ac.at domains, too. It has > proven to be sensible. > > Wilfried. > -------------------------------------------------------------------------- > Wilfried Woeber : e-mail: Woeber at 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 > -------------------------------------------------------------------------- -- Michael Hallgren, Graphnet Systems, http://mh.graphnet.fr Always make new mistakes. - E Dyson From paula at ripe.net Wed Jun 16 09:55:52 1999 From: paula at ripe.net (Paula Caslav) Date: Wed, 16 Jun 1999 09:55:52 +0200 Subject: admin-c in inetnum Message-ID: <199906160755.JAA15414@x30.ripe.net> 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 From ysam at ipng.gr Tue Jun 15 18:03:53 1999 From: ysam at ipng.gr (Yiannis Samouhos) Date: Tue, 15 Jun 1999 19:03:53 +0300 (EET) Subject: admin-c in inetnum In-Reply-To: <199906150835.KAA12642@x30.ripe.net> Message-ID: In real Life? I don't think there's any use! Instaid of admin-c I think this should be either nothing or a "last resort-c" in case of trouble.. Almost in all cases I know of, the Admin-c does NOT have a clue of what is going on, what are all thouse templates/objects. The admin-c justs redirects any messages to the first available tech-c. Kind Regards, -Yiannis Samouhos IPNG Group SA. On Tue, 15 Jun 1999, Paula Caslav wrote: > > 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 > > > From registry at pianeta.it Tue Jun 15 17:55:01 1999 From: registry at pianeta.it (Alberto Pasquale) Date: Tue, 15 Jun 1999 17:55:01 +0200 Subject: admin-c in inetnum Message-ID: <199906151555.RAA21285@saturno.pianeta.it> On Tue, 15 Jun 1999 10:35:22 +0200, Paula Caslav wrote: >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. I support this viewpoint. I have never had the need to contact an admin-c about problems on his/her network, anyway I think it should just be a person responsible for the network administration and not necessarily a person that actually administers the network on site. --- Alberto Pasquale Pianeta Local Registry From Eric_vanLaarhoven at infonetnl.com Tue Jun 15 19:33:48 1999 From: Eric_vanLaarhoven at infonetnl.com (Eric_vanLaarhoven at infonetnl.com) Date: Tue, 15 Jun 1999 19:33:48 +0200 Subject: admin-c in inetnum Message-ID: Paula, Currently infonet Netherlands admin-c contacts on many (international) location to whom we assign address space, are either non-technical contact persons which know nothing of the address schemes used, or IT people in the dutch HQ's, which are thus not on the local sites. This is a common practice, as many companys centralise their IT personnel and the local people will only be able to reset equipment or mumble 'call the HQ is you have any questions!' Therefore I would like to see the admin-c to become the tech-c only, or the admin-c of the main location for this company (the HQ most probably) this would simplify the order and be more in line with reality. regards Eric van Laarhoven Infonet Netherlands From rainer.may at smartnet.de Wed Jun 16 09:37:55 1999 From: rainer.may at smartnet.de (Rainer May) Date: Wed, 16 Jun 1999 09:37:55 +0200 Subject: admin-c in inetnum Message-ID: <01BEB7DB.E9D31C00.rainer.may@smartnet.de> -----Urspr?ngliche Nachricht----- Von: Paula Caslav [SMTP:paula at ripe.net] Gesendet am: Dienstag, 15. Juni 1999 10:35 An: lir-wg at ripe.net Cc: local-ir at ripe.net Betreff: admin-c in inetnum lir-wg at ripe.net wrote: 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? making a fast rush through the database entries we are affected by one can see that very often a not-on-site-admin-c is common practice (hard to believe that someone living in Munich can be on-site wirh a network in Hamburg, around 800 km away). And we don#t think that this can cause any problems. The job of the admin-c (in case of emergencies) is clear: Alarming someone who knows where's the "red button". This usually will be done by phone, and it doesn't matter if the caller is next door or not. Just our 2 c smartnet Online Service rm From barak at netvision.net.il Wed Jun 16 11:24:46 1999 From: barak at netvision.net.il (Barak Engel) Date: Wed, 16 Jun 1999 11:24:46 +0200 Subject: admin-c in inetnum In-Reply-To: <001701beb7d0$9a921ca0$d68038d4@melitacable.com> Message-ID: <000601beb7da$137d87e0$de64cbc7@shitty.network.org.il> > In our experience with admin-c, we always assigned it to > the contact person of the customer. Same here. And Tech-c is our NOC team's role contact, which means it never "expires", even if people do leave or change positions within the company (as, for example, is evident from my sig below :-) 10x, Sincerely, \'"'/ Barak Engel ( o o ) ---------------------ooOO-^-oOOo--------------------------- barak at netvision.net.il Business development BE-RIPE BE174 Phone/Fax: +972 48 560600#666/551132 Cell: +972 50 469 341 ----------------------------------------------------------- From dvella at melitacable.com Wed Jun 16 10:16:58 1999 From: dvella at melitacable.com (Duncan Vella) Date: Wed, 16 Jun 1999 10:16:58 +0200 Subject: admin-c in inetnum In-Reply-To: <199906150835.KAA12642@x30.ripe.net> Message-ID: <001701beb7d0$9a921ca0$d68038d4@melitacable.com> Hi, In our experience with admin-c, we always assigned it to the contact person of the customer. We also do not bother to explain what the role of the admin-c is. Some even suggested us to talk to their company's lawyer! So I never bothered asking again. I agree that the admin-c field may not be physically located at the site of the network and also would allow the tech-c and admin-c to be the same person. Regards, Duncan > -----Original Message----- > From: owner-local-ir at ripe.net [mailto:owner-local-ir at ripe.net]On Behalf > Of Paula Caslav > Sent: Tuesday, June 15, 1999 10:35 AM > To: lir-wg at ripe.net > Cc: local-ir at ripe.net > Subject: admin-c in inetnum > > > > 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 > > From darren at jpci.net Wed Jun 16 10:32:02 1999 From: darren at jpci.net (Darren Smith) Date: Wed, 16 Jun 1999 09:32:02 +0100 Subject: admin-c in inetnum In-Reply-To: <001701beb7d0$9a921ca0$d68038d4@melitacable.com> Message-ID: A non-text attachment was scrubbed... Name: smime.p7m Type: application/x-pkcs7-mime Size: 6136 bytes Desc: not available URL: From saeed at vax.ipm.ac.ir Wed Jun 16 11:23:48 1999 From: saeed at vax.ipm.ac.ir (SAEED KHADEMI) Date: Wed, 16 Jun 1999 12:53:48 +0330 Subject: admin-c in inetnum Message-ID: <009D9B7F.BD5B4480.1@ROSE.IPM.AC.IR> 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. From dvella at melitacable.com Wed Jun 16 13:29:40 1999 From: dvella at melitacable.com (Duncan Vella) Date: Wed, 16 Jun 1999 13:29:40 +0200 Subject: admin-c in inetnum In-Reply-To: <009D9B7F.BD5B4480.1@ROSE.IPM.AC.IR> Message-ID: <000b01beb7eb$86156820$d68038d4@melitacable.com> No, I don't think so Saeed. But from the look of it, I think that most would like to remove the admin-c altogether and remain with tech-c only. I would suggest leaving the field admin-c optional. Regards, Duncan > > 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. > > From netmaster at xlink.net Wed Jun 16 16:09:13 1999 From: netmaster at xlink.net (Xlink Netmaster) Date: Wed, 16 Jun 1999 16:09:13 +0200 Subject: admin-c in inetnum Message-ID: <19990616160913.A571@xlink.net> 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 at 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. From engin at ripe.net Wed Jun 16 13:28:37 1999 From: engin at ripe.net (Engin Gunduz) Date: Wed, 16 Jun 1999 13:28:37 +0200 Subject: Adding nic handles to objects without one References: <199906141405.QAA15248@x41.ripe.net> Message-ID: <37678A65.6EEA4806@ripe.net> Dear list members, The addition of NIC handles to the person objects that do not have one already successfully and smoothly completed. NIC handles are added to 31981 person objects. The process began at 19:00 and ended at 23:30, CET. Thanks for your cooperation by not sending huge updates while the addition process was in progress. Please do not hesitate to contact us for any questions. Kind regards, Engin Gunduz RIPE NCC DB Group Joao Luis Silva Damas wrote: > > 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 at 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 From davem at hiway.co.uk Wed Jun 16 13:26:34 1999 From: davem at hiway.co.uk (Dave Mullender) Date: Wed, 16 Jun 1999 12:26:34 +0100 Subject: admin-c in inetnum In-Reply-To: <000b01beb7eb$86156820$d68038d4@melitacable.com> References: <009D9B7F.BD5B4480.1@ROSE.IPM.AC.IR> Message-ID: <199906161132.MAA11656@mailsrv.hiway.co.uk> > No, I don't think so Saeed. > > But from the look of it, I think that most would like to remove > the admin-c altogether and remain with tech-c only. I would suggest > leaving the field admin-c optional. I thought the reason was that the admin contact needed to be physically located at the site where the IP's are in use, whereas the tech contact could be remote, but I stand to be corrected! Dave > > > > 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? ----------- Dave Mullender Hiway Communications Ltd Tel: 01635 573300 Fax: 01635 573329 From ag at bs.volga.ru Wed Jun 16 16:02:45 1999 From: ag at bs.volga.ru (Lebedev Andrew) Date: Wed, 16 Jun 1999 18:02:45 +0400 Subject: admin-c in inetnum References: <000b01beb7eb$86156820$d68038d4@melitacable.com> Message-ID: <3767AE84.4180B5D8@bs.volga.ru> I think, that admin-c it is the man carrying out a management tech-c. It necessarily should understand thoroughly technical questions, but it should be. Duncan Vella wrote: > No, I don't think so Saeed. > > But from the look of it, I think that most would like to remove > the admin-c altogether and remain with tech-c only. I would suggest > leaving the field admin-c optional. > > Regards, > Duncan > > > > > 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. > > > > -- SY, Lebedev Andrew BS ISP From antoin at iaehv.nl Wed Jun 16 15:24:36 1999 From: antoin at iaehv.nl (Antoin Verschuren) Date: Wed, 16 Jun 1999 15:24:36 +0200 (CEST) Subject: admin-c in inetnum In-Reply-To: <199906150835.KAA12642@x30.ripe.net> Message-ID: On Tue, 15 Jun 1999, Paula Caslav wrote: >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? I always use the admin-c the same way as domain-registries use it. It should be somebody from the company that uses the network, and is responsible for the people that use that network. most of the time, this is the director or system administrator of the company, that actualy does the request. So it's more of a "legal responsible person", and somebody that knows that they use the network. I don't think the person should be on-site all the time. after all, what is "on-site" if the network is used on several sites located in different parts of the country. As long as he knows the situation, and can control where the network is used. Met groet, Antoin Verschuren Projectcoordinator Internet Access Eindhoven ----------------------------------------------------------------- | Informatie over zakelijke diensten: http://www.iae.nl/info/ | | Helpdesk Internet Access Eindhoven: http://www.iae.nl/helpdesk/ | ----------------------------------------------------------------- | Antoin Verschuren | | Projectcoordinator Internet Access Eindhoven | | E-mail : support at iae.nl | ----------------------------------------------------------------- From marcus.nutting at theplanet.net Wed Jun 16 17:45:39 1999 From: marcus.nutting at theplanet.net (Marcus Nutting) Date: Wed, 16 Jun 1999 16:45:39 +0100 Subject: FW: admin-c in inetnum Message-ID: <01bc01beb80f$49498dd0$1aff1fac@nmc-09.localnet> 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 at ripe.net [mailto:owner-lir-wg at ripe.net]On Behalf Of Paula Caslav Sent: Wednesday, June 16, 1999 8:56 AM To: lir-wg at 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 From aperret at inet.de Thu Jun 17 12:32:20 1999 From: aperret at inet.de (andreas perret) Date: Thu, 17 Jun 1999 12:32:20 +0200 Subject: [Fwd: FW: admin-c in inetnum] Message-ID: <3768CEB4.519A1BB8@inet.de> -------- Original Message -------- Betreff: FW: admin-c in inetnum Datum: Thu, 17 Jun 1999 10:08:17 +0100 Von: marcus.nutting at theplanet.net An: lir-wg at 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 at ripe.net [mailto:owner-lir-wg at ripe.net]On Behalf Of Paula Caslav Sent: Wednesday, June 16, 1999 8:56 AM To: lir-wg at 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 From joao at ripe.net Mon Jun 21 11:48:36 1999 From: joao at ripe.net (Joao Luis Silva Damas) Date: Mon, 21 Jun 1999 11:48:36 +0200 Subject: Modifying references to contact info in the RIPE DB Message-ID: <199906210948.LAA01812@x41.ripe.net> Dear all, the Database consistency project has been going forward in its goals since RIPE 33 (eg. addition of nic handles to all objects without one.) Statistics and reports about the "status" of the database can be seen at http://www.ripe.net/db/state/. We will keep adding information to these pages as the project progresses. We are now at the point where we would like to tackle the issue of references by name in the admin-c, tech-c and zone-c. As a next step, we would like to have references by nic handles (which are unique) instead of references by name (which can be non -unique). At this point, we would like to automatically go through all the references by name which can uniquely be assigned to a person or role object and substitute them by references to their nic handles. This will prevent these references from becoming non-unqiue in the future. Later we will go through the process of fixing the non-unique references left in the database. This process requires user intervention since we can't decide who "owns" a particular set of resources. For this later stage, we will be preparing reports that we will send to all maintainers for whom we detect objects with inconsistencies and try to get them fixed. Information about this part will be sent to the lists in a few weeks. We would like to do this after as much as possible has been done by automatic means to correct inconsistencies so that human effort is reduced to a minimum. If there are any concerns regarding this move, please make them known before next Friday (June 25th). Looking forward to your comments, Joao Damas Database Group RIPE NCC From Ralph.Hall at swisscom.com Mon Jun 21 14:36:32 1999 From: Ralph.Hall at swisscom.com (Ralph.Hall at swisscom.com) Date: Mon, 21 Jun 1999 14:36:32 +0200 Subject: admin-c in inetnum Message-ID: <21C15D5AE757D011AFBF0000F830A4A903DDF01F@gd3i5y.swissptt.ch> 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 From hostmaster at nic.de Mon Jun 21 14:47:31 1999 From: hostmaster at nic.de (Hostmaster DE-NIC) Date: Mon, 21 Jun 1999 14:47:31 +0200 Subject: admin-c in inetnum Message-ID: 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 at denic.de | | Germany | http://www.denic.de | | | | | don't hesitate to contact us ... | | +-----------------------------------+--------------------------------+ > Return-path: > Envelope-to: hostmaster at 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 at lists.ripe.net > Received: (qmail 9950 invoked by uid 66); 21 Jun 1999 12:36:37 -0000 > From: Ralph.Hall at swisscom.com > Message-ID: <21C15D5AE757D011AFBF0000F830A4A903DDF01F at gd3i5y.swissptt.ch> > To: lir-wg at 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 at 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 > > From ripe-dbm at ripe.net Tue Jun 22 11:20:40 1999 From: ripe-dbm at ripe.net (RIPE Database Administration) Date: Tue, 22 Jun 1999 11:20:40 +0200 Subject: Update processing delayed Message-ID: <199906220920.LAA09796@birch.ripe.net> 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 . Regards, Roman Karpiuk ____________________________ The RIPE NCC Database Group. From joao at ripe.net Thu Jun 24 10:01:27 1999 From: joao at ripe.net (Joao Luis Silva Damas) Date: Thu, 24 Jun 1999 10:01:27 +0200 Subject: Changing old format dates in the RIPE DB Message-ID: <199906240801.KAA19717@x41.ripe.net> 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. From joao at ripe.net Thu Jun 24 10:19:01 1999 From: joao at ripe.net (Joao Luis Silva Damas) Date: Thu, 24 Jun 1999 10:19:01 +0200 Subject: Modifying references to contact info in the RIPE DB In-Reply-To: Your message of Mon, 21 Jun 1999 11:48:36 +0200. <199906210948.LAA01812@x41.ripe.net> References: <199906210948.LAA01812@x41.ripe.net> Message-ID: <199906240819.KAA19760@x41.ripe.net> Thanks for the comments on this item. We do realize that there might be a few cases where the possibility raised actually happens: That the original person referenced got deleted some time in the past and a new one with the same name was introduced into the database. However, contacting the holders of all the affected objects is really not feasible and I think also not practical (the order of magnitude is 10^5 objects that would get touched). We could actually send out all these emails and write a mail robot to process the responses. However, with the respondent being a human being, the chances are that a lot of mails would not be be able to be automatically processed. And a lot of people would not even reply. Also, many people not affected by the problem (being the correct reference) would get (unsolicited) emails. I would therefore not be able to extract a valid conclusion from the process. In the meantime, not carrying out the proposed modifications can only make the situation worse (as more person get registered in the database the chances of any two having the same name increase, and old person objects can get deleted). I think at this point there is not a perfect solution for this situation but I would rather deal with the few complaints about an object pointing to someone incorrect (and then act on them) rather than let the situation keep on deteriorating. One of the solutions to catch some of the misassignements (at least for inetnums) is to run a cross check of the database objects against the registry database. So, in spite of the concerns raised (valid as they are) I would still vote to go ahead on this one as proposed. What do people think? Regards, Joao Damas DB Group RIPE NCC From joao at ripe.net Thu Jun 24 11:04:40 1999 From: joao at ripe.net (Joao Luis Silva Damas) Date: Thu, 24 Jun 1999 11:04:40 +0200 Subject: Modifying references to contact info in the RIPE DB In-Reply-To: Your message of Sun, 24 Jun 2001 10:50:59 +0200. <200106240850.KAA09195@eunet.ch> References: <200106240850.KAA09195@eunet.ch> Message-ID: <199906240904.LAA19915@x41.ripe.net> Bernard Steiner writes: * * > That the original person referenced got deleted some time in the past and * a new one with the same name was introduced into the database. * * Coming to think about it... * How about catching such (obvious) cases where the first changed date of the * person is younger or either of the changed dates is not available ? * How much human intelligence would that require to sort out ? As a philosopher said some time ago: "I am me and my circumstances". This also applies to the RIPE Database (and in a very big measure). I guess everyone remembers the (in)famous -c changes and how many changed lines (particularly the old ones) disappeared during that period. We can do the check you propose and see how many objects would not get modified. If it happens to be a small number we can look at them individually. If not it is back to square one. Thanks for the suggestion, Joao * * Bernard * * From phk at critter.freebsd.dk Thu Jun 24 11:50:41 1999 From: phk at critter.freebsd.dk (Poul-Henning Kamp) Date: Thu, 24 Jun 1999 11:50:41 +0200 Subject: Modifying references to contact info in the RIPE DB In-Reply-To: Your message of "Sun, 24 Jun 2001 10:50:59 +0200." <200106240850.KAA09195@eunet.ch> Message-ID: <3129.930217841@critter.freebsd.dk> Talking about the database and consistency of same: The following LIRs all have 100 or more IP numbers in use which are not correctly registered in the RIPE database. Detailed information available at: http://stat.cybercity.dk/ripe Poul-Henning se.swipnet 3842 nl.wapi 2650 uk.global 1477 uk.demon 986 uk.pipex 945 pl.tpsa 857 se.sunet 804 uk.pol 520 fi.kolumbus 507 fr.isdnet 501 it.iunet 459 uk.telinco 363 si.telekom 309 ch.swissonline 282 uk.ntli 272 de.maz 271 dk.teledanmark 269 tr.superonline 259 uk.force9 249 eu.eunet 198 it.flashnet 186 eu.compuserve 180 ch.petrel 169 de.ginko 155 hu.datanet 152 de.rak 147 dk.sektornet 139 dk.proventum 132 fr.cybercable 130 pt.ipglobal 127 de.mediaways 126 se.transpac 123 de.cybernet 107 nl.demon 104 de.roka 103 dk.euroconnect 103 se.umdac 101 -- Poul-Henning Kamp FreeBSD coreteam member phk at FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! From kieber at ga-telecom.net Thu Jun 24 12:11:50 1999 From: kieber at ga-telecom.net (Ulf Kieber) Date: Thu, 24 Jun 1999 12:11:50 +0200 (CEST) Subject: Modifying references to contact info in the RIPE DB In-Reply-To: <200106240850.KAA09195@eunet.ch> from Bernard Steiner at "Jun 24, 2001 10:50:59 am" Message-ID: <199906241011.MAA05970@rocky.ga-telecom.net> Bernard Steiner writes: > > That the original person referenced got deleted some time in the past and a new one with the same name was introduced into the database. > > Coming to think about it... > How about catching such (obvious) cases where the first changed date of the > person is younger or either of the changed dates is not available ? > How much human intelligence would that require to sort out ? Probably not too much, but ... there are (quite a considerable number of) LIRs that insist in keeping only the very last changed line. -- Ulf Kieber email: kieber at ga-telecom.net Network Engineer voice: +49-69-299896-21 Global Access Telecommunications, Inc. fax : +49-69-299896-66 internet solutions for business www : www.ga-telecom.net From woeber at cc.univie.ac.at Thu Jun 24 15:00:56 1999 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 24 Jun 1999 15:00:56 MET-DST Subject: Modifying references to contact info in the RIPE DB Message-ID: <009DA1DA.D349508C.1@cc.univie.ac.at> Hi Joao! >So, in spite of the concerns raised (valid as they are) I would still >vote to go ahead on this one as proposed. > >What do people think? Well, some as yet unstructured rants, off the top of my head... I'd love to see some sort of test-run being performed, e.g. going ahead and putting the result up as the (or an additional) test db? One of the key things might be to make sure that we (you :-) can perform a roll-back, if it turns out that we've messed up things badly... Is there any chance to do some sort of dry-run, and put up some sort of list of cases deserving investigation? Poul's page is a very good thing, indeed, although tackling a different aspect. My reasoning is that whatever can be fixed by humans, in a distributed project, before the brute-force attack would make life easier. Most probably basic rule #1 applies to my comments: use the brain before using the keyboard :-) Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber at 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 -------------------------------------------------------------------------- From joao at ripe.net Thu Jun 24 15:48:08 1999 From: joao at ripe.net (Joao Luis Silva Damas) Date: Thu, 24 Jun 1999 15:48:08 +0200 Subject: Modifying references to contact info in the RIPE DB In-Reply-To: Your message of Thu, 24 Jun 1999 15:00:56 +0700. <009DA1DA.D349508C.1@cc.univie.ac.at> References: <009DA1DA.D349508C.1@cc.univie.ac.at> Message-ID: <199906241348.PAA21236@x41.ripe.net> Hi, throwing some more brain cycles at it... At least for inetnums, we do have an alternate source of info to check against. Our internal registry database. But guess what. On registries that have been around for some time, contact info is stored with references by name, not nic handle. Those are also the DB objects that have references by name. So... one gains nothing from doing this. What I am trying to do here is minimize the amount of human intervention. On all sides. Let's have an example. What if I want to contact an admin-c (since they seem to be popular lately) for an object. If the reference is by name then when I query the DB I will get the list of persons with that name, 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. 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: 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. If I am being pointed at by some object in the DB because the original person went away, then it is not going to help me whether the reference is by name or nic handle. However, having references by nic handle can stop at least this kind of deterioration. We will still have problems with objects that have references by name when there are already several person with the same name. But we are not going to chose those in this run. This is aimed at stopping this last set from increasing. We'll tackle the current ambiguities in the (near) future. Hope this made things a bit more clear, Joao "Wilfried Woeber, UniVie/ACOnet" writes: * Hi Joao! * * >So, in spite of the concerns raised (valid as they are) I would still * >vote to go ahead on this one as proposed. * > * >What do people think? * * Well, some as yet unstructured rants, off the top of my head... * * I'd love to see some sort of test-run being performed, e.g. going * ahead and putting the result up as the (or an additional) test db? * * One of the key things might be to make sure that we (you :-) can perform * a roll-back, if it turns out that we've messed up things badly... * * Is there any chance to do some sort of dry-run, and put up some sort of * list of cases deserving investigation? Poul's page is a very good thing, * indeed, although tackling a different aspect. * * My reasoning is that whatever can be fixed by humans, in a distributed * project, before the brute-force attack would make life easier. * * Most probably basic rule #1 applies to my comments: * use the brain before using the keyboard :-) * * Wilfried. * -------------------------------------------------------------------------- * Wilfried Woeber : e-mail: Woeber at 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 * -------------------------------------------------------------------------- * From zsako at banknet.net Thu Jun 24 15:56:05 1999 From: zsako at banknet.net (Janos Zsako) Date: Thu, 24 Jun 1999 15:56:05 +0200 (MET DST) Subject: Modifying references to contact info in the RIPE DB Message-ID: <199906241356.PAA09872@banknet.banknet.net> > From owner-db-wg at ripe.net Thu Jun 24 14:35:25 1999 > From: "Wilfried Woeber, UniVie/ACOnet" > One of the key things might be to make sure that we (you :-) can perform > a roll-back, if it turns out that we've messed up things badly... My feeling is that if one replaces the name reference with the NIC-handle, at least as long as the referenced person object is not deleted (which I suppose cannot be deleted once it has an other object referencing it), the roll-back is always possible (i.e. one could re-substitute the NIC-handle with the name). Although, I feel this would be in the best case useless, since either there is no other person object with the same name, or the other object(s) was(were) added later. Janos From zsako at banknet.net Thu Jun 24 16:05:58 1999 From: zsako at banknet.net (Janos Zsako) Date: Thu, 24 Jun 1999 16:05:58 +0200 (MET DST) Subject: Modifying references to contact info in the RIPE DB Message-ID: <199906241405.QAA10088@banknet.banknet.net> > From owner-db-wg at ripe.net Thu Jun 24 15:23:02 1999 > From: Joao Luis Silva Damas > 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 From woeber at cc.univie.ac.at Thu Jun 24 16:38:49 1999 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 24 Jun 1999 16:38:49 MET-DST Subject: Modifying references to contact info in the RIPE DB Message-ID: <009DA1E8.7FC3C04C.3@cc.univie.ac.at> 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 at 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 -------------------------------------------------------------------------- From joao at ripe.net Thu Jun 24 17:00:21 1999 From: joao at ripe.net (Joao Luis Silva Damas) Date: Thu, 24 Jun 1999 17:00:21 +0200 Subject: Modifying references to contact info in the RIPE DB In-Reply-To: Your message of Thu, 24 Jun 1999 16:38:49 +0700. <009DA1E8.7FC3C04C.3@cc.univie.ac.at> References: <009DA1E8.7FC3C04C.3@cc.univie.ac.at> Message-ID: <199906241500.RAA21474@x41.ripe.net> Hi, I explicitly excluded those objects from this run. I can't possibly think of a simple script that can take that kind of decisions. 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. 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). The RIPE DB has been around for a long time and it's requirements and constraints have evolved a lot. I don't pretend to be able to solve all problems and certainly not all at once, but I think each step takes us closer. 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). ** For the cases where the ambiguity is already there: we'll look at them, try to categorize them 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. Regards, Joao "Wilfried Woeber, UniVie/ACOnet" writes: * 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 at 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 * -------------------------------------------------------------------------- * From woeber at cc.univie.ac.at Thu Jun 24 17:07:47 1999 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 24 Jun 1999 17:07:47 MET-DST Subject: Modifying references to contact info in the RIPE DB Message-ID: <009DA1EC.8BA9920C.7@cc.univie.ac.at> >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. From joao at ripe.net Thu Jun 24 17:49:37 1999 From: joao at ripe.net (Joao Luis Silva Damas) Date: Thu, 24 Jun 1999 17:49:37 +0200 Subject: Modifying references to contact info in the RIPE DB In-Reply-To: Your message of Sun, 24 Jun 2001 17:45:16 +0200. <200106241545.RAA09683@eunet.ch> References: <200106241545.RAA09683@eunet.ch> Message-ID: <199906241549.RAA21716@x41.ripe.net> Of course! And will gladly help s/he since that corrects an existing inconsistency in the DB. We do this all the time, whenever someone contacts us with this kind of request [although we do check it is not a case of someone trying to run away from their objects :-)] If you know anyone with that problem now, direct them to ripe-dbm at ripe.net, please. Joao Bernard Steiner writes: * Hi, * * > So, can we agree to proceed with our suggestion as stated below? * > ** * > Change references by names to references by nic handle where these are uni * que * > (there are not already more than two persons with the same referenced name * ). * > ** * * Can we also decide that when a person decides she (sic) is not responsible * for whatever record references hir, said person is allowed to have the * reference removed ? * * (This problem exists already...) * * Bernard * * From Daniel.Karrenberg at ripe.net Thu Jun 24 20:41:59 1999 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 24 Jun 1999 20:41:59 +0200 Subject: admin-c in inetnum In-Reply-To: <199906160755.JAA15414@x30.ripe.net> Message-ID: <4.1.19990624203201.00a2cb20@127.0.0.1> If my memory serves me right the requirement for the asmin-c to be on site was primarily intended to make sure that the person belonged to the organisation using the resource concerned and not a consultant or contractor. I think it is perfectly reasonable to drop the 'on site' requirement and replace it with 'belongs to the organisatin using the resource' (address space in this context). Also I'd like to clarify the expectations of an admin contact and why it is different rom the tech contact. The tech contact is the contact for all operational aspects of the resource mentioned. They will be contacted if there is a technical or operational issue to be addressed. The admin contact is the one who is administratively responsible for the use of the resource. They will be contacted if there is a clearly administrative issue or *if any technical issue cannot be resolved with the tech-c*. So the ecpectation is that the admin-c is somewhat higher in the management chain of the organisation than the tech-c, or if the tech-c is not in the same organisation the admin-c can influence their contractors. It is an escalation contact. This is a very useful thing to have. That is why it is required and it should remain so. Also it should be the contact for issues that may lead to legal actions or some such. Daniel From engin at ripe.net Tue Jun 29 18:25:03 1999 From: engin at ripe.net (Engin Gunduz) Date: Tue, 29 Jun 1999 18:25:03 +0200 Subject: Converting named references to NIC handle references Message-ID: <3778F35F.751F5ECB@ripe.net> 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