- lir-wg - mailman.ripe.net

Re: admin-c in inetnum
by Rainer May 16 Jun '99

16 Jun '99

-----Ursprüngliche Nachricht----- Von: Paula Caslav [SMTP:paula@ripe.net] Gesendet am: Dienstag, 15. Juni 1999 10:35 An: lir-wg(a)ripe.net Cc: local-ir(a)ripe.net Betreff: admin-c in inetnum lir-wg(a)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

1 0

RE: admin-c in inetnum
by Wilfried Woeber, UniVie/ACOnet 15 Jun '99

15 Jun '99

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(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 --------------------------------------------------------------------------

2 1

Re: admin-c in inetnum
by Eric_vanLaarhoven＠infonetnl.com 15 Jun '99

15 Jun '99

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

1 0

Re: admin-c in inetnum
by Alberto Pasquale 15 Jun '99

15 Jun '99

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

1 0

RE: admin-c in inetnum
by mike.norris＠heanet.ie 15 Jun '99

15 Jun '99

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(a)ripe.net [mailto:owner-lir-wg@ripe.net]On Behalf Of > Paula Caslav > Sent: Tuesday, June 15, 1999 9:53 AM > To: lir-wg(a)ripe.net > Cc: local-ir(a)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 >

1 0

RE: admin-c in inetnum
by SAEED KHADEMI 15 Jun '99

15 Jun '99

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.

1 0

New RIPE DB sw version
by Joao Luis Silva Damas 04 Jun '99

04 Jun '99

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

1 0

Tagging of IP adresses / Application-Database
by Nacamar AS Guardian 03 Jun '99

03 Jun '99

Hi, at RIPE-Meeting 33, the issue on the agenda of the lir-wg of "Tagging of IP adresses and ANTI SPAM" was rejected. Partly, because this has been implemented by Paul Vixi, http://maps.vix.com/dul Further, it was felt that these tags should not be an addition to the IP-Objects, because it has a much broader range of possible applications. So, the issue was handed over to the db-wg to think about a new application-registry. Such an application-object could look like: >>> location: [mandatory] [single] [primary/look-up key] app-type: [mandatory] [single] [primary key] app-subtype: [mandatory] [single] [primary key] descr: [mandatory] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [optional] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] <<< Location would be a range of IP-Addresses or maybe a hostname, app-type a value/keyword like "nameserver", "dialin", "mail" etc., app-subtype a more detailed code for the application, like root-nameserver, tld-nameserver, cc-nameserver, etc. Details to be discussed... Then descr, contacts etc, just the usual stuff. Technically, this shouldn't be too hard, but the main questions remain on the administrative side: - who would use this database, and for what purpose (Anti-SPAM, better route-flap-dampening ...) - who should insert/maintain the contents - how to determine if the contents are 'legal', e.g. come from the 'owner' of the mentioned ip-ranges/hosts - what to do if someone protests against some contents, or claims damages because of some contents Just to spark a bit of discussion... Best Regards, HaJo Gurt ------------------------------------------------------------------- Nacamar Network Administration NACAMAR Data Communications guardian(a)nacamar.net Robert-Bosch-Str. 32 D-63303 Dreieich +49 6103 993 0 Voice Germany +49 6103 993 222 FAX gurt(a)nacamar.de ------------------------------------------------------------------- Titanic 12 - Hiroshima 45 - Tschernobyl 86 - Windows 95 - Silvester 99

3 2

Draft Agenda for the Local IR WG at RIPE 33
by Hans Petter Holen 04 May '99

04 May '99

My deepest aplogies for yet another time beeing far to late with the preparations for the meeting. The good thing is that there as been several discussions on the mailing list so there is clearly activity in this working group again. Below I have put together a "standard agenda" and added the action list from the last meeting at the end. Theese items may be promoted do agenda items if requested. RIPE 33 - 4th to 5th May 1999 Local IR Working Group D R A F T A G E N D A 1. Admin - scribe - participant list - agenda - meet the RIPE NCC hostmasters - mailinglists 2. RIPE 32 - minutes - actions 3. Reports from registries - European regional (RIPE NCC) - Statistics - APNIC - ARIN - other regionals ...Open space here .... 8. I/O with other WGs - Ipv6 Guidelines - Tagging of IP adresses and ANTI SPAM - 9. AOB ----- Action points RIPE 31 - Web interface to address forms - Comments to RIPE 185 - NCC To inform the WG on possible ARIN policy changes Action points RIPE 32 + NCC: Web interface to address forms RIPE 141 Status: released source 15/3-1999 + NCC: Ipv6 Guidelines Status: released 16/4 http://www.ripe.net/lir/registries/ipv6.html - NCC: Write up suggestion on lowering AW to /19 Status: Paula posted suggestion to list on 10/2, modified proposal by Stephen Burley - Guy Davies UUNET: Start discussion on max allocation size and internal aggregation needs for large registries Status: Discussion started on 2/2-1999 - NCC: Make pretty address statistics charts - Poul-Henning: Present proposal on tagging IP addresses for anti SPAM measures Status: This has been implemented by Paul Vixi, http://maps.vix.com/dul - NCC: IP adresses to cable networks Status: Paula suggested policy change 15/2, no comments on the list - Everybody: Participate in policies for IPv6 discussion Sincerely, Hans Petter Holen LIR-WG Chair

1 0

Autohm source release
by Maldwyn Morris 30 Apr '99

30 Apr '99

Dear Colleagues, On March 15th 1999, the RIPE NCC released the source code of autohm, the syntax checking part of Web141, which is the RIPE NCC's European IP Address Space Request web form. Since that time the software has been downloaded 106 times. We would very much like to recieve feedback as to how the software functioned. We are specifically interested in hearing if autohm met your needs and if not in which areas it was lacking. Please send your comments directly to myself or to the lir-wg mailing list. Thanks, Maldwyn Morris Software Manager RIPE NCC

1 0