From ncc at ripe.net Thu Feb 10 13:48:24 2000 From: ncc at ripe.net (RIPE NCC Staff) Date: Thu, 10 Feb 2000 13:48:24 +0100 Subject: FYI: ICANN ASO: website and mailing lists Message-ID: <200002101248.NAA05741@birch.ripe.net> Dear colleagues, Please find attached a document from Paul Wilson of the ASO Secretariat reminding all parties interested in ASO affairs of open discussion lists available. Please feel free to re-distribute this information as you see fit. Regards, Mirjam Kuehne RIPE NCC ------- Forwarded Message Date: Thu, 10 Feb 2000 10:11:34 +1000 From: "Paul Wilson" Sender: owner-apnic-announce at lists.apnic.net To: Subject: [apnic-announce] ICANN ASO: website and mailing lists [Note "reply-to:" field] (with apologies for duplicates) Reminder: ICANN ASO - Website and Discussion Lists This is an announcement to all parties with interests in management of Internet Address space and related resources. The Address Supporting Organisation of ICANN (the Internet Corporation for Assigned Names and Numbers) was established last year, and has assumed its responsibilities under the ICANN Bylaws for coordination of global policy development in relation to Internet Addresses and related resources. The nine-member Address Council has also been established, in accordance with the ASO MoU and ICANN Bylaws. Since its establishment, the ASO has established mailing lists and a website to ensure that its processes are open and transparent, and accessible to all parties with an interest in Internet resource management issues. Three ASO mailing lists are now available for public access to ASO information, and for input into the ASO process: aso-announce - for announcements and other information relating to the ASO (read only list) aso-policy - for open discussion on policy and other ASO matters (open subscription list) aso-comment - for comment and input of any kind (no subscription necessary) The ASO website is also now available, at http://www.aso.icann.org, and carries information relating to the ASO, Address Council, and policy matters which may be under consideration; as well as complete archives of the above mailing lists. At this time the Address Council is seeking participants in the ASO process, and encourages all interested parties to subscribe to the mailing lists above. For information on how to subscribe, please visit the ASO website. We look forward to your participation! Paul Wilson for the ASO Address Council. ______________________________________________________________________ Paul Wilson, Director-General, APNIC http://www.apnic.net ph/fx +61 7 3367 0490/82 - ---------------------------------------------------------------------- See you at APRICOT 2000! 28 Feb - 2 Mar http://www.apricot2000.ne.kr - ---------------------------------------------------------------------- ------- End of Forwarded Message From hph at infostream.no Thu Feb 17 11:37:27 2000 From: hph at infostream.no (Hans Petter Holen) Date: Thu, 17 Feb 2000 11:37:27 +0100 Subject: ASO General Assembly and Call for ICANN Board nominations Message-ID: <003301bf7933$6cfbd680$e204e1c3@asp.infostream.no> ANNOUNCEMENT: ASO General Assembly for 2000 and Call for ICANN Board nominations The Address Council of the Address Supporting Organisation is pleased to announce the first ASO General Assembly meeting, to be held on Friday 19 May 2000, in Budapest, Hungary. This meeting will be hosted by RIPE NCC alongside the RIPE-36 meeting, and will be open to all parties with an interest in ASO policy matters. A detailed meeting agenda will be published in due course on the ASO web site, at http://www.aso.icann.org In compliance with the ASO MoU (http://www.aso.icann.org/docs/aso-mou.html), the Address Council and ICANN hereby call for nominations to the ICANN Board, of candidates to fill vacant ASO seats on the ICANN board as they become vacant. The first such seat scheduled to become vacant is currently occupied by Mr. Pindar Wong, who will stand down on 2 November 2000 (the 12 month anniversary of his appointment). However, candidates nominated at this time may also be chosen to fill seats which become vacant before or after this time. Note that appointments to the ICANN board must satisfy the geographic diversity constraints specified in section 3c of the ASO MoU. Any individual may be nominated within this process, with the exception of any official of a national government or a multinational entity established by treaty or other agreement between national governments (ICANN Bylaws Art. V., Sec 5.). Self-nominations are permitted. Nominations should be sent by email to and should state the following details : A. Nominee details 1. Full name 2. Organisational affiliation 3. Email address 4. Physical address 5. Country of residence 6. Telephone contact 7. Biography B. Details of nominating individual 1. Full name 2. Organisational affiliation 3. Email address 4. Country of residence Nominations must be submitted in English and must be received by the ASO Secretariat before 0900 GMT 19 April 2000 (30 days prior to the General Assembly meeting). After nomination all nominees will be contacted via email to confirm their willingness to serve as an ICANN Director. If the nominee is not contactable via email then the nomination will not be confirmed, and nominee must explicitly confirm the nomination for the nomination to be considered confirmed. All confirmed nominations will be listed on the ASO web site (see http://www.aso.icann.org) as soon as they are confirmed. Those wishing to express support for any individuals who have been nominated should use the "ICANN Board - Support of Nomination" Form which will be made available on the ASO web site. The list of nominated individuals and the supporting comments will be passed to the Address Council after all nominees are confirmed, and prior to the General Assembly meeting on 19 May 2000. More information regarding the GA and nominations process will be posted to the ASO web site (http://www.aso.icann.org) in due course. END ______________________________________________________________________ Paul Wilson, Director-General, APNIC http://www.apnic.net ph/fx +61 7 3367 0490/82 ---------------------------------------------------------------------- See you at APRICOT 2000! 28 Feb - 2 Mar http://www.apricot2000.ne.kr ---------------------------------------------------------------------- * on-line archive: http://aso.icann.org/wilma-bin/wilma/aso-announce * * To unsubscribe: send "unsubscribe" to aso-announce-request at aso.icann.org * * on-line archive: http://aso.icann.org/wilma-bin/wilma/aso-policy * * To unsubscribe: send "unsubscribe" to aso-policy-request at aso.icann.org * From engin at ripe.net Thu Feb 17 17:44:54 2000 From: engin at ripe.net (Engin Gunduz) Date: Thu, 17 Feb 2000 17:44:54 +0100 (CET) Subject: inetnum conversion Message-ID: Dear colleagues, RIPE NCC will be converting the legacy inetnum objects which are in old classful notation into classless range notation. We provide the list of inetnum objects to be converted during this process at: http://www.ripe.net/ripencc/pub-services/db/in_conversion/ There are 16404 such inetnums in the RIPE whois database, so we have divided them in four parts, but the list is available also as a big single file. The list contains the classful notation, new classless notation and the netname of the inetnums. The conversion is planned to take place on 26-27 February. You can check the list for your inetnum objects. If you detect a problem, please contact . Also, please send your comments about the conversion to the list, Regards, Engin Gunduz RIPE NCC Database Group ----------------------- From maldwyn at ripe.net Fri Feb 18 17:52:11 2000 From: maldwyn at ripe.net (Maldwyn Morris) Date: Fri, 18 Feb 2000 17:52:11 +0100 Subject: PGP for mails to and from RIPE NCC hostmaster Message-ID: <200002181652.RAA09166@birch.ripe.net> Hi, We will be presenting the proposal below at the LIR-WG at RIPE 35. Comments are most welcome. Cheers, Olaf and Maldwyn -- The use of PGP for the encryption and authentication of e-mails to and from the RIPE NCC hostmaster mailbox. Olaf M. Kolkman Maldwyn G.T. Morris February 2000. -------------------- A. Introduction The RIPE NCC has received requests to enable customer Local Internet Registries ( LIRs ) to use PGP for authentication and encryption of e-mails to hostmaster at ripe.net. We have tried to identify the possible uses for PGP in communication between the LIRs and the RIPE NCC hostmaster mailbox and tried to determine what risks and operational difficulties there are in using PGP for both the LIRs and the RIPE NCC. In this document we will present our ideas and a possible implementation. We assume that the reader is familiar with PGP and the related protocols and terminology. Note that: - we are not security protocol experts; we welcome all comments and will, in a later stage of the design, involve security experts. - the use of the proposed technology would be optional for our customer LIRs. -------------------- B. Uses of PGP. For e-mail exchange between the RIPE NCC and the LIRs we identify four possible uses. 1. Encryption of e-mails to the RIPE NCC. Means LIRs can send company confidential information to the RIPE NCC without the risk of it being read when traversing the Internet. 2. Authentication of e-mails from the RIPE NCC. Means LIRs can be sure the mail came from the RIPE NCC. Non-repudiation of signed mails is also a benefit for the LIR in case of conflicts. 3. Encryption of e-mails to the LIR. Means LIRs can send company confidential information to the RIPE NCC without the risk it being read when traversing the Internet when included in RIPE NCC replies. 4. Authentication of e-mails from the LIR. Means it is much harder for a 3rd party to impersonate a LIR. Items 1 and 2 are relatively easy to implement. The RIPE NCC needs to publish the public RIPE NCC key and needs to design an internal infrastructure that prevents unauthorised persons from using the private RIPE NCC key. LIRs will be able to make use of these methods without contacting the RIPE NCC to arrange it in advance. More on the design of the RIPE NCC internal infrastructure in section C.1. and C.2. below. Items 3 and 4 are more difficult to implement. Here the RIPE NCC has to be sure that a certain key did indeed originate from the LIR the mail purports to be from. To use these methods, LIRs will have to give RIPE NCC their public keys in advance and in section D below we describe a protocol for key exchange that makes it difficult to impersonate a LIR. The RIPE NCC will not sign any of the public keys of the LIRs i.e. it will not become a Certification Authority. -------------------- C Protocols and implementation for items 1 and 2: Encryption of e-mails to the RIPE NCC and authentication of e-mails from the RIPE NCC. C.1. The LIR's side. not need to have it own key-pair it only needs to obtain suitable software and RIPE NCC's public key to encrypt messages to RIPE NCC or authenticate messages from RIPE NCC. C.2. The RIPE NCC side. The RIPE NCC will publish its public key on its ( secure ) webserver. We will allow further authentication of our public key by reading its fingerprint at the RIPE meeting, printing the fingerprint on the invoices we send or by other broadcast methods. The RIPE NCC does not want to share its private key among multiple employees, but on the other hand the RIPE NCC does not want to revoke individual keys whenever employees take on other functions. We have chosen to use one RIPE NCC key for company-wide authentication and decryption. The RIPE NCC will keep its private key on a dedicated internal signing server. Using strong authentication methods ( probably SSH ), RIPE NCC employees will be able to open an authenticated connection to the box that will perform a decryption or a signing operation. The request will be logged to leave an audit trail. The signing server will need to be highly secured. To prevent possible long-term damage if the machine ever gets compromised, the RIPE NCC key will expire every n-years. A key revoking procedure, which will include a public message, will be in place. Using this setup we can ensure individual RIPE NCC employees ( except for the limited set of people having system level access to the server ) will not be able to read the private RIPE NCC key. We also have the flexibility to control who can sign and decrypt RIPE NCC mail. -------------------- D. Protocols and implementation for items 3 and 4: Encryption of e-mails from the RIPE NCC and authentication of e-mails to the RIPE NCC. Before describing the protocol and implementation details in section D.1. and D.2. some general remarks and requirements. Currently, authentication is based on mail addresses and the reg id contained in the e-mails, and on the common sense of the RIPE NCC hostmasters. After RIPE NCC implements this part of the project, LIRs will have to be able to choose to use PGP to authenticate themselves to the RIPE NCC. Once they have made that choice the RIPE NCC will not accept non-PGP authenticated communication from that particular LIR. The most important application is to prevent impersonation. Therefore we need a procedure to assure ourselves that a public key belongs to the LIR which is claiming to have sent the e-mail. If a malicious third party ( Mallet ) tries to submit a public key in the name of a LIR ( zz.alice ) then a number of things can go wrong: - Once we start using Mallet's key, zz.alice's non-authenticated messages will not be accepted by the RIPE NCC. - RIPE NCC might start sending zz.alice information encrypted with Mallet's key which zz.alice will not be able to read and Mallet might also intercept this traffic and extract confidential information. To prevent the LIR having to use "group" keys we have set the requirement that a LIR should be able to add and revoke keys for their employees. D.1. LIR keys and key exchange protocol. We are studying two methods for key exchange and we will have a security expert look at this before implementation. In both methods of key exchange the LIR will need to begin by creating a public/private key pair, we refer to these as the LIR's Master keys. The key exchange method ( see below ) defines how these Master keys are authenticated. Once the Master key has been authenticated, the LIR can create keys for their employees. The employees' public keys must be signed by the LIR's Master key and sent to the RIPE NCC before they can be used for mails to RIEP NCC. The LIR's Master key can be used: - for authentication of mails to hostmaster at ripe.net - as a decryption key for mails from the RIPE NCC. - for adding and revoking employee's keys with the RIPE NCC - to tell the RIPE NCC that the LIR no longer wishes to use PGP authentication. The LIR's employees' keys can only be used: - for authentication of mails to hostmaster at ripe.net - as a decryption key for mails from the RIPE NCC. In this way the LIR has control over who is permitted to communicate with the RIPE NCC. First proposed key exchange method. We use a secret ('billing-secret'), sent with the paper invoice that the LIR receives by surface mail. The LIR will send us an e-mail signed using its private Master key and containing the 'billing-secret' and its public Master key. Once we receive the key we will send a confirmation to the LIR contact address and from then on we will only allow PGP authenticated communication with that LIR. Using this method we put trust in the billing address to be correct and the surface-mail not being intercepted. Second proposed key exchange method. The LIR will sign the public Master key with the private Master key and send this signed public Master key to the RIPE NCC. The RIPE NCC will use the LIR's public Master key to check the signature and then send a secret string to a LIR contact. The LIR contact will reply to the RIPE NCC with a mail containing the secret signed with the Master key. From the moment the RIPE NCC receives the secret back we will only allow PGP authenticated communication with that LIR. Using this method we put our trust in the fact that the contact information is correct and that the e-mail to the LIR cannot be blocked and intercepted In both methods it could happen that just before doing the key exchange our malicious friend Mallet changed the the contact details using the current weak authentication method. This could result in Mallet impersonating LIR zz.alice. We think the chance of this happening is small. Being aware of this vulnerability in the protocol we can, if in doubt, use other methods to convince ourselves that the LIR's Master key actually comes from zz.alice. We think the extra costs involved in using these methods preclude their use in every case. There is a risk that the LIR's Master key gets lost and if that happens we will have to use an off-band mechanism to revoke the LIR's key. This may involve for example, a fax with the LIR's letterhead and a phone call to the LIR contact. D.2. RIPE NCC's implementation. RIPE NCC will implement this using dedicated key rings or a keyserver. So as not to risk RIPE NCC being seen as a Certification Authority the key ring or keys server will be for internal use only. The interface to it will be a mail robot. This is to prevent people uploading unneeded keys. The hostmaster mail robot will test if PGP encryption or authentication is used and will bounce non-PGP authenticated mails from those LIRs who use PGP authentication. Once mails are processed by the robots they are believed to be authenticated as coming from the LIR whose reg id is contained in the e-mail. The robot will also decrypt encrypted incoming messages on arrival. We will think further about whether encryption of outgoing e-mails should be the default or only an option ( for LIRs who have sent us their public keys ). The local copies of all communication will be kept in plaintext, with appropriate access permissions. -------------------- E. Final remarks. We are thinking of using OpenPGP for the basis of this project. The RIPE NCC will not support LIRs in setting up and or maintaining (Open)PGP but we will produce a general guide that should clearly explain what they need to do. PGP might, because of local law, not be available to all LIRs. From hph at infostream.no Sat Feb 19 00:26:14 2000 From: hph at infostream.no (Hans Petter Holen) Date: Sat, 19 Feb 2000 00:26:14 +0100 Subject: Strengthening the management of the lir-wg Message-ID: <017c01bf7a69$d1e58d20$e506e1c3@asp.infostream.no> Dear Working Group, I have found myslef spending the better part of the nights doing ICANN Address Council work rather than RIPE local ir work or even sleeping :-) I was thinking that maybe it would be a good idea to form a small group to support the chair and the work that needs to be donebbbbbbbbb. Tasks for thw group would for instance be - follow discussions on the mailinglist - summarize and try to conclude when possible - keep track on our actionlists, follow up on other people - prepare issues for the lir-wg meeting from my own experience this kind of work is invaluable training in a proffesional career :-) We could discuss this further in Amsterdam next week. -hph From hph at infostream.no Tue Feb 22 02:06:56 2000 From: hph at infostream.no (Hans Petter Holen) Date: Tue, 22 Feb 2000 02:06:56 +0100 Subject: Draft Agenda for lir-wg at RIPE 24 - second draft Message-ID: <006b01bf7cd1$21075140$a9ec5c8b@asp.infostream.no> Dear working Group, as the first draft was made for the plenary presentation at RIPE 34 it has been out for a while at http://www.ripe.net/ripe/wg/lir/r35-draftagenda.html Here is an updated second draft. Please approach me with additional items to the agenda. 1. Admin scribe, participant list, charter, mailinglists 2. Agenda 3. Meet the RIPE NCC hostmasters 4. RIPE 34 minutes actions 5. Reports from the Registries RIPE NCC APNIC ARIN ICANN Status of the Latin and AFRI NiCs 6. Report from the address council 7. The policy making process 8. Establish final selection procedure for the address council 9. Domain objects in the database 10. PGP authentication 11. WG management 12.. AOB Joint Lir-wg / IPv6 WG: B. Comments on the Provisional Assignment on Allocation of IPv6 addresses document (ipv6-wg & lir-wg) - Why is a dial-up link treated differently - should such users get a /48 or a /64 ?!? - Public or private addresses recommendation for point-to-point links - What constitutes 80% utilization ?!? (I am looking for a volunteer from the RIPE NCC for an introduction on the issues - other speakers are also welcome to volunteer) From ripe-dbm at ripe.net Tue Feb 22 12:39:20 2000 From: ripe-dbm at ripe.net (RIPE Database Administration) Date: Tue, 22 Feb 2000 12:39:20 +0100 Subject: RIPE DB service outage. Message-ID: <200002221139.MAA00599@birch.ripe.net> Dear Colleagues, Due to a regretable oversight, the following message was not sent to this list last night. Due to a crash of our whois server, we had to stop the updates and re-index the data. There is no need to resend your updates. The updates are queued and they will be processed later. We are also going to upgrade the main server so that it can cope better with the ever growing load. The whois query service has been switched to our backup server, therefore the response time is slower than usual. The latest news is that the re-indexing process has finished and we are currently working on the main server itself. We anticipate that the full service will be restored sometime later today. We shall keep you informed. If you have anymore questions, please contact . Regards, A. M. R. Magee ______________ RIPE NCC From ripe-dbm at ripe.net Tue Feb 22 17:39:04 2000 From: ripe-dbm at ripe.net (RIPE Database Administration) Date: Tue, 22 Feb 2000 17:39:04 +0100 Subject: RIPE DB service restored Message-ID: <200002221639.RAA17355@birch.ripe.net> Dear Colleagues, We wish to announce that the whois and update service of the RIPE Database has returned to normal. Currently, the queue of updates is being processed. We expect this queue to be cleared later this evening. Thank you for being patient. You will find that the service level of the RIPE Database has been improved. If you have questions, please contact . If you have any questions, please don't hesitate to contact . Regards, Daniele Arena ____________________________ RIPE Database Administration. From nils at work.de Tue Feb 22 23:53:12 2000 From: nils at work.de (Nils Jeppe) Date: Tue, 22 Feb 2000 23:53:12 +0100 Subject: RIPE DB service restored In-Reply-To: <200002221639.RAA17355@birch.ripe.net> Message-ID: Yes, one question; why haven't you announced taking down the DB? I find this unacceptable, some of us have to work with it you know? We have customers which need new Person objects, new Domains, etc. etc. Now, I understand perfectly if there are emergency maintainances or whatever, but don't just switch it off for an entire day without at least letting us know! How much effort would it have been if you had written a seven line email explaining that you have to take the DB down, and why? It's not like you're some kind of Internet Dictatorship or IP God which can do as it pleases; the RIPE NCC takes care of this stuff on the behalf of the LIRs and is financed by the LIRs, so this heavy-handed approach is really not something I appreciate. Best wishes, Nils Jeppe On Tue, 22 Feb 2000, RIPE Database Administration wrote: > > Dear Colleagues, > > We wish to announce that the whois and update service > of the RIPE Database has returned to normal. Currently, the > queue of updates is being processed. We expect this queue to > be cleared later this evening. > > Thank you for being patient. You will find that the service > level of the RIPE Database has been improved. If you > have questions, please contact . > > If you have any questions, please don't hesitate > to contact . > > Regards, > > Daniele Arena > ____________________________ > RIPE Database Administration. > > - ----------------------------------------------------------------- - n at work Internet Informationssysteme GmbH Tel +49 40 23880900 Spaldingstrasse 160d Fax +49 40 23880929 20097 Hamburg, Germany http://www.work.de/ From zsako at banknet.net Wed Feb 23 14:10:35 2000 From: zsako at banknet.net (Janos Zsako) Date: Wed, 23 Feb 2000 14:10:35 +0100 (MET) Subject: RIPE DB service restored Message-ID: <200002231310.OAA29838@banknet.banknet.net> > From owner-lir-wg at ripe.net Wed Feb 23 13:47:01 2000 > From: Nils Jeppe Dear Nils, > Yes, one question; why haven't you announced taking down the DB? I find > this unacceptable, some of us have to work with it you know? We have > customers which need new Person objects, new Domains, etc. etc. Now, I > understand perfectly if there are emergency maintainances or whatever, but > don't just switch it off for an entire day without at least letting us > know! How much effort would it have been if you had written a seven line > email explaining that you have to take the DB down, and why? > > It's not like you're some kind of Internet Dictatorship or IP God which > can do as it pleases; the RIPE NCC takes care of this stuff on the behalf > of the LIRs and is financed by the LIRs, so this heavy-handed approach is > really not something I appreciate. I guess the RIPE community in general does not appreciate YOUR approach (at least I do not). :(( Please find below the mail the RIPE NCC sent out BEFORE they turned updates off. I guess you have not been at the RIPE meetings and did not follow the work the RIPE NCC has been doing in the last many years. Otherwise I do not think you would make a remark like the above. Best regards, Janos > > > Best wishes, > Nils Jeppe > > > On Tue, 22 Feb 2000, RIPE Database Administration wrote: > > > > > Dear Colleagues, > > > > We wish to announce that the whois and update service > > of the RIPE Database has returned to normal. Currently, the > > queue of updates is being processed. We expect this queue to > > be cleared later this evening. > > > > Thank you for being patient. You will find that the service > > level of the RIPE Database has been improved. If you > > have questions, please contact . > > > > If you have any questions, please don't hesitate > > to contact . > > > > Regards, > > > > Daniele Arena > > ____________________________ > > RIPE Database Administration. > > > > ----- Begin Included Message ----- From ripe-dbm at ripe.net Mon Feb 21 19:05:18 2000 From: ripe-dbm at ripe.net (RIPE Database Administration) Date: Mon, 21 Feb 2000 19:05:18 +0100 Subject: Updates to the RIPE whois database stopped Message-ID: <200002211805.TAA21983@birch.ripe.net> Dear All, Due to a crash of our whois server which we experienced last Saturday we are stopping the updates tonight and we are going to reindex the data. There is no need to resend your updates. The updates will be queued and they will be resumed tomorrow. We are also going to upgrade the main server so that it can cope better with the ever growing load. The whois query service will be switched to our backup server, therefore the response time will be slower than usual. If you have any questions, please don't hesitate to contact . Regards, Marek Bukowy ____________________________ RIPE Database Administration. ----- End Included Message ----- From nils at work.de Wed Feb 23 15:11:33 2000 From: nils at work.de (Nils Jeppe) Date: Wed, 23 Feb 2000 15:11:33 +0100 Subject: RIPE DB service restored In-Reply-To: <200002231310.OAA29838@banknet.banknet.net> Message-ID: Hello Janos, I do not subscribe to the db-wg so I never received the message you forwarded. I also didn't say I don't appreciate the work the RIPE NCC does. I have been to one Ripe Meeting, it was great and the RIPE-People are cool. I also stated quite clearly in my email that I understand perfectly if a server goes down, even unexpected. It happens. But PLEASE find the time to send an email out to people. It is NOT too much to ask for. RIPE managed to send the "we're back" message to the lir's, so why not the "we're going down" message? Surely you can't expect everybody to subscribe to the RIPE DB WG List. I don't have time to filter through a million emails a day just in case there's a problem and someone only announces it to one of the many RIPE Mailing Lists. I sent email to ncc at ripe.net and promptly got the reply that yes, there were DB problems, but they were only supposed to tell people who ask specifically about it. Hence my "Dictatorship" comment. RIPE and RIPE NCC are not closed like a government, who lives in secrecy and hides all problems from everybody, as a gov't would hide a nuclear accident or something. I apologize if I sounded a little harsh, that wasn't quite my intention, but my original point still stands. RIPE NCC manages to create an incredibly bureacracy in other fields, and fails to create a simple "trouble ticket". This is not good. Best wishes, Nils On Wed, 23 Feb 2000, Janos Zsako wrote: > > From owner-lir-wg at ripe.net Wed Feb 23 13:47:01 2000 > > From: Nils Jeppe > > Dear Nils, > > > Yes, one question; why haven't you announced taking down the DB? I find > > this unacceptable, some of us have to work with it you know? We have > > customers which need new Person objects, new Domains, etc. etc. Now, I > > understand perfectly if there are emergency maintainances or whatever, but > > don't just switch it off for an entire day without at least letting us > > know! How much effort would it have been if you had written a seven line > > email explaining that you have to take the DB down, and why? > > > > It's not like you're some kind of Internet Dictatorship or IP God which > > can do as it pleases; the RIPE NCC takes care of this stuff on the behalf > > of the LIRs and is financed by the LIRs, so this heavy-handed approach is > > really not something I appreciate. > > > I guess the RIPE community in general does not appreciate YOUR > approach (at least I do not). :(( > > Please find below the mail the RIPE NCC sent out BEFORE they turned > updates off. > > I guess you have not been at the RIPE meetings and did not follow the work > the RIPE NCC has been doing in the last many years. Otherwise I do not think > you would make a remark like the above. > > Best regards, > Janos > > > > > > > > Best wishes, > > Nils Jeppe > > > > > > On Tue, 22 Feb 2000, RIPE Database Administration wrote: > > > > > > > > Dear Colleagues, > > > > > > We wish to announce that the whois and update service > > > of the RIPE Database has returned to normal. Currently, the > > > queue of updates is being processed. We expect this queue to > > > be cleared later this evening. > > > > > > Thank you for being patient. You will find that the service > > > level of the RIPE Database has been improved. If you > > > have questions, please contact . > > > > > > If you have any questions, please don't hesitate > > > to contact . > > > > > > Regards, > > > > > > Daniele Arena > > > ____________________________ > > > RIPE Database Administration. > > > > > > > > > ----- Begin Included Message ----- > > >From owner-db-wg at ripe.net Mon Feb 21 18:35:59 2000 > Delivered-To: lists-db-wg-out at lists.ripe.net > Received: (qmail 26581 invoked by uid 66); 21 Feb 2000 18:05:21 -0000 > Message-Id: <200002211805.TAA21983 at birch.ripe.net> > To: db-wg at ripe.net > Subject: Updates to the RIPE whois database stopped > From: RIPE Database Administration > X-Organization: RIPE Network Coordination Centre > X-Phone: +31 20 535 4444 > X-Fax: +31 20 535 4445 > Date: Mon, 21 Feb 2000 19:05:18 +0100 > Sender: owner-db-wg at ripe.net > Precedence: bulk > Content-Length: 652 > X-Lines: 25 > Status: RO > > > Dear All, > > Due to a crash of our whois server which we experienced last Saturday we > are stopping the updates tonight and we are going to reindex the data. > > There is no need to resend your updates. The updates will be queued > and they will be resumed tomorrow. We are also going to upgrade the > main server so that it can cope better with the ever growing load. > > The whois query service will be switched to our backup server, therefore > the response time will be slower than usual. > > If you have any questions, please don't hesitate > to contact . > > Regards, > > Marek Bukowy > ____________________________ > RIPE Database Administration. > > > > > > > ----- End Included Message ----- > > - ----------------------------------------------------------------- - n at work Internet Informationssysteme GmbH Tel +49 40 23880900 Spaldingstrasse 160d Fax +49 40 23880929 20097 Hamburg, Germany http://www.work.de/ From joao at ripe.net Wed Feb 23 16:25:04 2000 From: joao at ripe.net (Joao Luis Silva Damas) Date: Wed, 23 Feb 2000 16:25:04 +0100 (CET) Subject: RIPE DB service restored In-Reply-To: Message-ID: Dear Nils, sorry to hear we have caused you some much problems. As the situation was we needed to perform an emergency shutdown of the update process to prevent corruption of the database after we detected some problems after a system crash. We did try to reach the community by sending out a mail to db-wg. We later realized that, contrary to the norm, we did not cc the lir-wg. We did send out a message (included below) to the lir-wg a few hours later trying to correct the situation. We realize this not what should have been done, but we are humans. During the outage, our home page (http://www.ripe.net) also had a note notifying the event. We do our best to try to keep a good service running and inform everyone affected when it is not possible to do so. What we mean by the reply you got from ncc at ripe.net is that mailbox replies only to requests and does not spam everyone. We use several wg lists to try to reach the interested parties. I hope you will accept our apologies and we promise to work harder to avoid circumstances like this in the future. ********** Begin included message Dear Colleagues, Due to a regretable oversight, the following message was not sent to this list last night. Due to a crash of our whois server, we had to stop the updates and re-index the data. There is no need to resend your updates. The updates are queued and they will be processed later. We are also going to upgrade the main server so that it can cope better with the ever growing load. The whois query service has been switched to our backup server, therefore the response time is slower than usual. The latest news is that the re-indexing process has finished and we are currently working on the main server itself. We anticipate that the full service will be restored sometime later today. We shall keep you informed. If you have anymore questions, please contact . Regards, A. M. R. Magee ______________ RIPE NCC ********** End included message Yours sincerely, Joao Damas Head of external services RIPE NCC From schiefne at mail.berlin.contrib.net Wed Feb 23 17:31:08 2000 From: schiefne at mail.berlin.contrib.net (Carsten Schiefner) Date: Wed, 23 Feb 2000 17:31:08 +0100 (MET) Subject: RIPE DB service restored In-Reply-To: <200002231310.OAA29838@banknet.banknet.net> from "Janos Zsako" at Feb 23, 2000 02:10:35 PM Message-ID: <200002231631.RAA25027@mail.berlin.contrib.net> > I guess the RIPE community in general does not appreciate YOUR > approach (at least I do not). :(( > > Please find below the mail the RIPE NCC sent out BEFORE they turned > updates off. > > I guess you have not been at the RIPE meetings and did not follow the work > the RIPE NCC has been doing in the last many years. Otherwise I do not think > you would make a remark like the above. > > Best regards, > Janos Fully agreed here. And BTW: RTFM (where 'M' stands for 'Mail[s]' here...) Greetings, -C. -- Carsten Schiefner mailto:carsten.schiefner at tcpip-gmbh.de TCP/IP GmbH, Berlin (Germany) http://www.tcpip-gmbh.de Phone: +49.30.443366-0 Fax: +49.30.443366-15 Mobile: +49.172.5425797 TCP/IP GmbH runs the Contrib.Net backbone http://www.contrib.net ====================================================================== From engin at ripe.net Fri Feb 25 15:46:37 2000 From: engin at ripe.net (Engin Gunduz) Date: Fri, 25 Feb 2000 15:46:37 +0100 (CET) Subject: inetnum conversion In-Reply-To: Message-ID: Dear colleagues, Since we didn't get any comments/objections about this issue, we will be performing inetnum conversions in the early hours of 26 February, Saturday. Best regards, Engin Gunduz RIPE NCC Database Group ----------------------- On Thu, 17 Feb 2000, Engin Gunduz wrote: > > Dear colleagues, > > RIPE NCC will be converting the legacy inetnum objects which are in old classful > notation into classless range notation. We provide the list of inetnum > objects to be converted during this process at: > > http://www.ripe.net/ripencc/pub-services/db/in_conversion/ > > There are 16404 such inetnums in the RIPE whois database, so we have divided > them in four parts, but the list is available also as a big single file. The > list contains the classful notation, new classless notation and the netname of > the inetnums. > > The conversion is planned to take place on 26-27 February. > > You can check the list for your inetnum objects. If you detect a problem, > please contact . > > Also, please send your comments about the conversion to the list, > > > Regards, > Engin Gunduz > > RIPE NCC Database Group > ----------------------- > > > From engin at ripe.net Mon Feb 28 10:08:00 2000 From: engin at ripe.net (Engin Gunduz) Date: Mon, 28 Feb 2000 10:08:00 +0100 (CET) Subject: inetnum conversion In-Reply-To: Message-ID: Dear colleagues, As announced, we have converted all legacy inetnum objects in RIPE whois database into classless format, without any problem. The conversion took place on 26 February, saturday. We have sent notifications to the maintainers of the converted objects. Please do not hesitate to contact for any problems or comments, Regards, Engin Gunduz RIPE NCC Database Group ----------------------- On Fri, 25 Feb 2000, Engin Gunduz wrote: > > Dear colleagues, > > Since we didn't get any comments/objections about this > issue, we will be performing inetnum conversions in the > early hours of 26 February, Saturday. > > Best regards, > > Engin Gunduz > > RIPE NCC Database Group > ----------------------- > > > > On Thu, 17 Feb 2000, Engin Gunduz wrote: > > > > > Dear colleagues, > > > > RIPE NCC will be converting the legacy inetnum objects which are in old classful > > notation into classless range notation. We provide the list of inetnum > > objects to be converted during this process at: > > > > http://www.ripe.net/ripencc/pub-services/db/in_conversion/ > > > > There are 16404 such inetnums in the RIPE whois database, so we have divided > > them in four parts, but the list is available also as a big single file. The > > list contains the classful notation, new classless notation and the netname of > > the inetnums. > > > > The conversion is planned to take place on 26-27 February. > > > > You can check the list for your inetnum objects. If you detect a problem, > > please contact . > > > > Also, please send your comments about the conversion to the list, > > > > > > Regards, > > Engin Gunduz > > > > RIPE NCC Database Group > > ----------------------- > > > > > > > >