From Daniel.Karrenberg at ripe.net Tue Feb 7 05:51:53 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 07 Feb 1995 05:51:53 +0100 Subject: EUnets - again In-Reply-To: Your message of Mon, 06 Feb 1995 07:08:53 +0200. <950206.071812.+0200.VUSTEVE@WEIZMANN.WEIZMANN.AC.IL> Message-ID: <9502070451.AA04861@ncc.ripe.net> To whom it may concern, Late last Friday Simon Poole of EUnet/CH lodged a serious complaint against the RIPE NCC which was given wide circulation. Since I start hearing about this from different directions and I am unable to find out the exact circulation given to the original complaint I have to give this message a wider circulation than probably necessary. If you are a recipient who has not seen or heared about the original complaint, please accept my apologies and read no further. To the others I apologise for the lengthy message but such matters are rarely simple enough to fit into one paragraph. With kind Regards Daniel Karrenberg RIPE NCC ------ Glenn, Simon, After a thorough investigation of the matter I conclude that the complaint by Simon refenced below is toally unjustified. The complaint is referring to a telephone conversation which certainly did not refer to a specific request and was otherwise not substantial enough to be logged at the NCC which is standard procedure. For more details about the specific case, see the enclosure. We have *certainly* not stated that "the request has been dropped" because -as you know- we do not drop requests as a matter of policy. We have *certainly* not stated that "EUnet/CH have not paid their bills" because EUnet/CH has not received any bills from us and it is our policy not to discus such issues with third parties. There also were *certainly* no questions about a specific request as we would have then logged the call in order to return it. Since the communication concerned was by phone and not substantial enough to be logged, or for names to be noted on both sides, it is difficult to reconstruct what has happened in detail. Noone at the NCC recalls having had the particular conversation. We handle quite a few such calls per day. The most probable scenario is that the caller asked about a standard message which we send since February 1st, incorrectly identified his request as being sent via the *EUnet/CH* local registry (not the Last Resort registry) and was correctly told that his request would be processed on a "time permitting" basis because EUnet/CH does not presently contribute to the NCC funding. Maybe language difficulties played a part in misunderstanding here. This case falls into a familiar pattern: - Consultant starts project, requests address space - NCC asks for more information / suggests less address space - nothing happens for several weeks (more than 2 months in this particular case, certainly not "roughly two weeks") - Consultant passes deadline, resends request (sometimes slightly modified) - Consultant starts calling NCC on a daily basis In this situation any excuse for the lack of progess is good enough for consultant. We have had some very unhappy customers (of consultants) calling us with the most bizarre stories. The NCC deliberately dropping requests is one of the more "boring" excuses I have heared in cases like this. So I have to conclude that we have *certainly* not made the statements you complain about. I find it *very* inappropriate to give such complaints wide circulation including the TERENA Executive and Secretary General before raising them with the NCC. I take personal exception with the fact that it was given such circulation *without even notifying the NCC itself*!. All this makes me conclude that it is not a genuine complaint, but mud slung in a political battle. I would apreciate if complaints would be raised with us first, before being given a wide circulation. My staff will be happy to investigate any problems and as you know I am always available in the unlikely event you find their response inadequate. I would also apreciate if you could give this response the same circulation within EUnet as Simon's original complaint. With kind Regards Daniel Karrenberg RIPE NCC Manager Enc: Results of request investigation Fri, 18 Nov 1994 14:31:03 +0100 Request received. Tue, 22 Nov 1994 09:58:00 +0100 Requested background information from CH Last Resort registry. No response to date. Tue, 22 Nov 1994 19:25:52 +0100 Requested further information/justification from consultant. No reponse to date. Wed, 1 Feb 1995 11:46:23 +0100 Received similar (same) request directly by fax from other consultant (same consultancy company) without any justification (1 page). This request does not refer to the original one more than 2 months earlier *at all*. Therefore it is classified as a new request from an "individual" not channeled through a registry. Thu, 02 Feb 1995 14:12:00 +0100 Standard response sent that individual requests are in the "time permitting" queue. The requests have been handled correctly: The first one is waiting for information from the requestor. The second one is waiting in the "time permitting" queue until it can be processed. Now that we know that they are probably the same, we will combine them and continue to process it as coming via the CH Last Resort registry. > > From: Glenn.Kowack at eu.net > > To: Steve Druck > > Subject: recently uncovered (unpleasant) surprise > > Date: Sun, 05 Feb 1995 18:25:27 +0100 > > > > Steve, > > I received this mail from Simon Poole, managing director of > > EUnet-Switzerland: > > > > _______ > > From: poole at eunet.ch (Simon Poole) > > Subject: Re: EUnet and the RIPE NCC.... > > Date: Fri, 3 Feb 1995 18:43:59 +0100 (MET) > > > > As you may know we run the registry of last resort for > > Switzerland, a community service which cost us a lot > > of money and gives us a tiny bit of PR. > > > > Roughly two weeks ago our staff member that handles the > > registry stuff forwarded a request for a class B to > > the NCC, the organisation that requested the address > > is neither a customer or in any other way related to us. > > > > Today our staff tried to find out what had happened > > to the request, and heard the following from the > > client: the Ripe NCC had decided to drop the request > > because we (EUnet/CH) had not paid their bills. > > > > This is obivously from any perspective outrageous....... > > > > Simon > > _______ > > > > I am now very concerned. This is unreasonable and entirely > > outside of the spirit of your and my discussion last week. > > Last week's announcement was sufficiently dismaying, since > > it was handed to us as a fait accompli. Now we're confronted > > with at another nasty surprise, this one a past action. Are > > there more surprises waiting in the wings? I've got some very > > very unhappy directors, including at my national networks. > > > > What the hell is going on? > > > > -Glenn From poole at eunet.ch Tue Feb 7 09:00:04 1995 From: poole at eunet.ch (Simon Poole) Date: Tue, 7 Feb 1995 09:00:04 +0100 (MET) Subject: EUnets - again In-Reply-To: <9502070451.AA04861@ncc.ripe.net> from "Daniel Karrenberg" at Feb 7, 95 05:51:53 am Message-ID: <199502070800.JAA14895@chsun.eunet.ch> > To whom it may concern, > > Late last Friday Simon Poole of EUnet/CH lodged a serious complaint > against the RIPE NCC which was given wide circulation. Considering the fact that EUnet sent this request directly to exactly one external responsible person and did not make our complaint public in any form, I can only assume that you are trying to make a preemptive strike. As you know, I spent a significant amount of time yesterday verifying the story and have come to the conclusion that the story related to me by my staff is true in all essential parts (in the impression created on the consultant). Some of the fuzziness in what was originally related to me, may be attributed to our staff member being extremely embarrassed and shocked after receiving the call from the consultant. I do not doubt that the (wrong) impression created on the consultant may be due to misunderstandings and to language difficulties, which can be attributed to a new and inexperienced member of your staff and to the consultant being under pressure. However this can not be our problem, what effects us are the net results of this situation however they may have arised. And to recapitulate, the consultants impression was: - EUnet AG owes the NCC money and had not paid. - his request was not being processed because of the above. And while you may try to argue away all responsibility, you can not deny that the NCC delibertly put procedures in place (and has made statements), that have a high risk of leading to such "misunderstandings". Simon Poole EUnet AG, Managing Director From Daniel.Karrenberg at ripe.net Tue Feb 7 09:47:08 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 07 Feb 1995 09:47:08 +0100 Subject: EUnets - again In-Reply-To: Your message of Tue, 07 Feb 1995 09:00:04 MET. <199502070800.JAA14895@chsun.eunet.ch> Message-ID: <9502070847.AA06147@ncc.ripe.net> > poole at eunet.ch (Simon Poole) writes: > > And while you may try to argue away all responsibility, you can not deny > that the NCC delibertly put procedures in place (and has made statements), > that have a high risk of leading to such "misunderstandings". We have not deliberately created a wrong impression about EUnet AG. We have not even carelessly created a wrong impression about EUnet AG. You have accused us - *behind our back* - *to a wide audience* - without verifying your facts first - without asking us for a reaction first of doing both. This is mudslinging. The victim of mudslinging has no choice but to react publicly, otherwise something always sticks. The procedures we have had to put in place and the reasons for it are a totally different subject. This ends the discussion as far as I am concerned. Daniel From poole at eunet.ch Tue Feb 7 10:43:47 1995 From: poole at eunet.ch (Simon Poole) Date: Tue, 7 Feb 1995 10:43:47 +0100 (MET) Subject: EUnets - again In-Reply-To: <9502070847.AA06147@ncc.ripe.net> from "Daniel Karrenberg" at Feb 7, 95 09:47:08 am Message-ID: <199502070943.KAA21288@chsun.eunet.ch> Daniel writes: > We have not deliberately created a wrong impression about EUnet AG. > > We have not even carelessly created a wrong impression about EUnet AG. Again, the only thing I care about is that a member of our staff got a phone call on Friday afternoon from an unhappy consultant stating that his request was not being processed because we hadn't paid our bills to Ripe. Except if you accuse me of being a liar and fabricating the story, there is no denying the above fact. How he got that impression I can only deduct from what he told me on the phone yesterday, but he -did- get it from the NCC. > You have accused us > > - *behind our back* > - *to a wide audience* We took this privately to your immediate formal superior, you went public. > - without verifying your facts first The facts have been double checked (we might disagree on what the actual incident is). > - without asking us for a reaction first We asked your superior for a reaction, nothing else. Simon From Daniel.Karrenberg at ripe.net Tue Feb 7 10:49:21 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 07 Feb 1995 10:49:21 +0100 Subject: EUnets - again In-Reply-To: Your message of Tue, 07 Feb 1995 10:43:47 MET. <199502070943.KAA21288@chsun.eunet.ch> Message-ID: <9502070949.AA06867@ncc.ripe.net> > poole at eunet.ch (Simon Poole) writes: > > > You have accused us > > > > - *behind our back* > > - *to a wide audience* > > We took this privately to your immediate formal superior, you went public. You took it to my immediate formal superior's superior. Small detail, but still escalated out of proportion. You did not take it up with me first. You must have given it wider circulation because I received questions about it from several parties not on the quoted messages, some of which inside EUnet. > > - without verifying your facts first > > The facts have been double checked (we might disagree on what the actual > incident is). You did that *after* making the complaint. This really closes it now. Daniel From Mirjam.Kuehne at ripe.net Wed Feb 15 11:06:04 1995 From: Mirjam.Kuehne at ripe.net (Mirjam Kuehne) Date: Wed, 15 Feb 1995 11:06:04 +0100 Subject: local hostcounts Message-ID: <9502151006.AA18866@ncc.ripe.net> Dear Local IR's, As suggested during the last RIPE Meeting in Amsterdam I want to encourage you to do your hostcount locally. The advantage is that the data is more up to date. It lowers the traffic and transmission errors. Till now the following countries count their hosts locally: ie, uk, de, gr, cy, at, pt Next month fr will join. The only things you need to do are: 1. to run host (available as ftp://ftp.ripe.net/tools/dns/host.tar.Z) 2. to run a shell script like: #!/bin/sh host -lav -s 10 -L 999 pt. > pt.output 2> pt.error 3. to make these two files gzipped available somewhere for me to pick it up. I hope this will encourage you to count your hosts locally. If you have any further questions don't hesitate to contact me. Best regards, Mirjam RIPE NCC From Mirjam.Kuehne at ripe.net Wed Feb 15 11:06:04 1995 From: Mirjam.Kuehne at ripe.net (Mirjam Kuehne) Date: Wed, 15 Feb 1995 11:06:04 +0100 Subject: local hostcounts Message-ID: <9502151006.AA18866@ncc.ripe.net> Dear Local IR's, As suggested during the last RIPE Meeting in Amsterdam I want to encourage you to do your hostcount locally. The advantage is that the data is more up to date. It lowers the traffic and transmission errors. Till now the following countries count their hosts locally: ie, uk, de, gr, cy, at, pt Next month fr will join. The only things you need to do are: 1. to run host (available as ftp://ftp.ripe.net/tools/dns/host.tar.Z) 2. to run a shell script like: #!/bin/sh host -lav -s 10 -L 999 pt. > pt.output 2> pt.error 3. to make these two files gzipped available somewhere for me to pick it up. I hope this will encourage you to count your hosts locally. If you have any further questions don't hesitate to contact me. Best regards, Mirjam RIPE NCC From Daniel.Karrenberg at ripe.net Wed Feb 15 12:06:05 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 15 Feb 1995 12:06:05 +0100 Subject: RIPE NCC Request Tracking and Ticketing Message-ID: <9502151106.AA19545@ncc.ripe.net> Deear Colleagues, We hav now reached the point where we have to streamline request processing at the NCC even further. This necessitates the introducion of tickets. I have written up a proposal on how to do things from our point of view which tries to explain *why* we need certain things. I would apreciate feedback from you about this as early as possible. If you have any questions, please do not hesitate to contact me. Regards Daniel Karrenberg RIPE NCC Manager RIPE NCC Request Tracking and Ticketing A Proposal Daniel Karrenberg Manager RIPE NCC February 15th 1995 1. Introduction The RIPE NCC is now processing a substantial amount of requests from local registries as well as individuals. Many of these requests require multiple interactions with the customer (requester) before they can be completed. In addition the NCC has to process requests with different levels of service since February 1st 1995. This situation makes it necessary to formalise request tracking and introduce a ticketing system to keep track of requests. This will improve the speed of processing as well as reduce the resources necessary to establish the context when processing requests. It is hoped it will also improve service to the customer by giving quick and automated infor- mation about the status of a particular request. 2. Registry Identification Each European Local Internet Registry has been assigned a registry Identifier. This ID consists of the two letter ISO3166 country code of the country the registry is esta- blished in followed by a dot and a unique, hopefully descriptive, name for the registry. Registry IDs can be found in ftp://ftp.ripe.net/ripe/registries/, in fact they are identical to the file names in this directory. In order to make an unambiguous link back to the requesting registry and to establish the priority of a request it is necessary that the registry ID is quoted on all messages dealing with requests to the NCC. Where possible we suggest to include it in an RFC822 header line of the messages concerned. The suggested format is: - 2 - X-NCC-RegID: nn.example Where it is impossible to modify the RFC822 header, this line can also be included in the body of the message. Failure to include the registry ID in messages dealing with requests may delay processing as the message may be treated on a "time-permitting" basis if a registry cannot readily be identified. 3. Ticketing The RIPE NCC will assign a unique ticket to each request as it is first received at the NCC. This ticket will be quoted by the NCC on each message to the customer dealing with the request. It should also be quoted by the customer in mes- sages about this request sent to the NCC. The format of the ticket is he string "NCC#", followed by the last two digits of the year the ticket was issued, fol- lowed by a four digit ticket number, e.g. NCC#944711 Tickets should be quoted exactly like this. The letters NCC and the hash sign form an integral part of the ticket. The ticket format is designed with the following criteria in mind: + It has to be syntactically detectable when imbedded in text such as "In reference to tickets NCC#941234 and NCC#946789 we would like to ...". + It has to be easily quotable out of band like "Hey, can you hand me the file about NCC (ninetyfour) twelve thirtyfour please.". + It has to be representable in basic E-Mail and in other means of written communication. Tickets are simply identifiers for a specific request and have no semantic meaning of their own with regard to pro- cessing priority, sequence of receipt at the NCC, resource assignment or anything else. Where possible we suggest to include tickets in an RFC822 - 3 - header line of the messages concerned. The suggested format is: X-NCC-Ticket: NCC#941234 Where it is impossible to modify the RFC822 header, this line can also be included in the body of the message. If desired the ticket number can also be included in text near the top of the body of the message. Failure to include the ticket number in messages concerning ongoing requests will cause additional delays in processing as NCC staff will have to manually identify the ticket con- cerned and add it to the message. Messages received without reference to a ticket may also cause a new ticket to be assigned and later merging to an existing ticket will cause delay. 4. Alternative Embeddings Where it is too cumbersome to include two separate lines for the registry ID and the ticket in a message, the information can be combined on a single line like this: X-NCC-Request: nn.example NCC#941234 5. Self Ticketing For registries who keep their own tickets on requests the NCC is willing to consider to allow self ticketing of requests. We would suggest to use a format consisting of the registry ID, a hash sign and a number, e.g. nn.example#123456 but we are flexible w.r.t. the ticket format as long as it is unique and satisfies the criteria mentioned above. If the need arises we will also investigate methods to cross reference ticket numbers of different systems as necessary. This may mean that we will have to carry multiple tickets for each request. The above suggestion is intended to minimise the need for that. Please contact the NCC if you would like to use self ticket- ing. From GeertJan.deGroot at ripe.net Wed Feb 15 13:45:56 1995 From: GeertJan.deGroot at ripe.net (Geert Jan de Groot) Date: Wed, 15 Feb 1995 13:45:56 +0100 Subject: Ticketing In-Reply-To: Your message of "Wed, 15 Feb 1995 10:01:49 MET." <9502150901.AA18301@ncc.ripe.net> Message-ID: <9502151245.AA20868@ncc.ripe.net> On Wed, 15 Feb 1995 10:01:49 +0100 Daniel Karrenberg wrote: > Where possible we suggest to include tickets in an RFC822 > header line of the messages concerned. The suggested format > is: > X-NCC-Ticket: NCC#0000 > > Where it is impossible to modify the RFC822 header, this > line can also be included in the body of the message. If > desired the ticket number can also be included in text near > the top of the body of the message. This is easy to do for MH (what we use), but other mailers may have problems with this (I know UCB mail has). Maybe it is better to prepend this in the Subject line, like this: Subject: Request for a class B becomes Subject: NCC#4711 Request for a class B Another advantage is that the ticket automatically gets copied without any effort, while with new headers, 'something' has to be done to copy them in, and as Murphy dictates, it will be forgotten every once a while.. Comments? Should the registry-ID be on the subject line too? Geert Jan From Daniel.Karrenberg at ripe.net Wed Feb 15 13:59:38 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 15 Feb 1995 13:59:38 +0100 Subject: Ticketing In-Reply-To: Your message of Wed, 15 Feb 1995 13:45:56 MET. <9502151245.AA20868@ncc.ripe.net> Message-ID: <9502151259.AA20992@ncc.ripe.net> > Geert Jan de Groot writes: > ... > Maybe it > is better to prepend this in the Subject line, like this: > Subject: Request for a class B > becomes > Subject: NCC#4711 Request for a class B > > Another advantage is that the ticket automatically gets copied > without any effort, while with new headers, 'something' has > to be done to copy them in, and as Murphy dictates, it will > be forgotten every once a while.. This automatism is very appealing indeed. I have changed the relevant text to read: "Where possible we suggest to include tickets at the beginning of the RFC822 Subject: header line of the messages concerned, e.g: Subject: NCC#941234 Address space Request for BigNet Ltd. The RIPE NCC will use this embedding when assigning ticket numbers. If this is not possible the ticket number can also be included in text near the top of the body of the message." I have deleted the "Alternative Embeddings" paragraph because it is then no longer needed. > Should the registry-ID be on the subject line too? This is not really necessary and will leave little space for meaningful text in the subject line. Anyone have problems with this? Daniel From Mirjam.Kuehne at ripe.net Wed Feb 15 16:50:05 1995 From: Mirjam.Kuehne at ripe.net (Mirjam Kuehne) Date: Wed, 15 Feb 1995 16:50:05 +0100 Subject: new expiry date for ripe-124 Message-ID: <9502151550.AA23684@ncc.ripe.net> Dear Local IR's, As you might have noticed the RIPE document ripe-124 (EUROPEAN IP NETWORK NUMBER APPLICATION FORM & SUPPORTING NOTES) is expired on December, 31st 1994. Unfortunately we had no time yet to revisit it carefully. Since we receive a lot of queries concerning this issue we decided to set the expiry date to 30-June-1995 without changing the document. The document number did not change either! It is still ripe-124. We hope we are able to revisit the document during that time. The document EUROPEAN AUTONOMOUS SYSTEM NUMBER APPLICATION FORM & SUPPORTING NOTES (ripe-109) is expired as well. This document is currently under revision. We hope we can publish it soon. For the time being ripe-109 is valid and can be used. Best regards, Mirjam Kuehne RIPE NCC From GeertJan.deGroot at ripe.net Sun Feb 19 20:06:05 1995 From: GeertJan.deGroot at ripe.net (Geert Jan de Groot) Date: Sun, 19 Feb 1995 20:06:05 +0100 Subject: Hardware problems at the RIPE NCC Message-ID: <9502191906.AA00415@ncc.ripe.net> Ticket Number: - Ticket Status: open Ticket Type: unscheduled Ticket Source: RIPE NCC Ticket Scope: RIPE NCC Site/Line: RIPE NCC Ticket Owner: ops at ripe.net Problem Fixer: Geert Jan de Groot Ticket Opened: 950217 21:47 UTC Problem Started: 950217 21:00 UTC Closed: Ended: Problem Description: Due to the failure of 2 (two) harddisks at the RIPE NCC on the same day, it seems we may have lost mail sent to the various role accounts on Friday. Also, whois.ripe.net has been offline on Friday for an hour (sorry). Affected: RIPE NCC role accounts: mail which arrived between 950217 00:00 UTC and 950217 22:00 UTC may be lost (we still have the sendmail logs) RIPE auto-dbm updates were deliberately delayed until machines are in full working order, but will be processed shortly. If you have not received an ack by Monday morning, please re-submit the update. We have been unable to send this ticker earlier, because the mail aliases were also on one of the disks involved.. Actions: Install replacement harddisk on whois.ripe.net on Monday (downtime is expected to be < 5 minutes). Restore disk contents of 950217 0:00 (last dump date) for NCC role accounts. Investigate sendmail logs for possible lost mail, and send individual messages, if possible. Restore role account transaction records for 950217 as far as possible. LOCAL-REGISTRIES: if possible, re-send your mail sent on Friday with RESEND in the subject line. Install some garlic in the engine room ;-) While we make dayly backups (of course!), the crash happened 21 hours after the last backup, and those 21 hours includes a full working day. I can't think of a better way to guard against these exceptional circumstances. Time to fix: RIPE NCC operations should be back to normal by the time you read this, but us staff has to determine what mail has been lost. As a result, we might not respond immediately to messages on Monday. I expect to be able to do the harddisk swaps with minimal disruption. From hostmaster at ripe.net Mon Feb 20 14:52:28 1995 From: hostmaster at ripe.net (RIPE NCC Hostmaster) Date: Mon, 20 Feb 1995 14:52:28 +0100 Subject: Hardware problems at the NCC Message-ID: <9502201352.AA04495@ncc.ripe.net> Dear Local-IR's, As you heard already from Geert Jan we had some hardware problems on friday. It is fixed now and the NCC is working normally again :-) But we might have lost some messages on friday. We tried to restore as much as possible from back up tapes but unfortunately there is a difference betweeen back up and reality ;-) We ask you kindly to resend the whole correspondance you had with us on friday: messages you have sent to us and - if possible - also messages you have received from us on friday. In this way we hope to keep our archives complete and avoid gaps in the communication between you and us. Please include the keyword RESEND in the header of the resent messages. We thank you very much for your understanding and your help and appologise for any inconveniences this may cause. Best regards, RIPE NCC staff From mnorris at dalkey.hea.ie Tue Feb 21 13:10:36 1995 From: mnorris at dalkey.hea.ie (Mike Norris) Date: Tue, 21 Feb 1995 12:10:36 GMT Subject: Draft minutes of meeting at RIPE 20 Message-ID: <9502211210.AA16679@dalkey.hea.ie> RIPE 20, Amsterdam January 25-27th, 1995 Chairman : Mike Norris 2nd draft - Local IR working group minutes 1. Introduction Mike Norris, the chairman welcomed the participants to the Local IR meeting. Anne Lord volunteered as scribe to take the minutes. The group met twice, for 1.5 hours each meeting. Proposed alterations to the agenda are below: - start with items 1, 2 and 3 on the agenda - follow item 3 with item 12. (will be reported as per scheduled agenda order) 2.1 RIPE 19 minutes There were no changes to the minutes as previously circulated. 2.2 RIPE 19 actions 18.3 done : Geert Jan de Groot Investigate monthly publication of error files on reverse zone files, similar to the host count error files. 19.2 closed : Mike Norris At the 20th meeting to raise the training of local IR's as a topic for discussion. 19.3 open : Daniel Karrenberg To make an inventory document of the problems associated with charging for address space. 19.4 closed : Daniel Karrenberg To recirculate draft proposal on use of private address space for VSE's not connecting to the Internet. Circulate proposal to the WG mailing list. 19.5 closed : RIPE NCC To organise a meeting between regional registries, with representatives from the RIPE local - IR working group. 19.6 closed : Geert Jan To document new attribute "status" proposed to describe whether a network is delegated, reserved or assigned. 19.7 open : RIPE NCC Circulate revised ripe-115 to the local-ir mailing list for comments. 19.8 open : Daniel Karrenberg To prepare specification for the format of the list of service providers. 3. Reports from Regional Registries There was an open invitation to all local registries to contribute under this agenda item. 3.1 Kim Hubbard - InterNIC Kim Hubbard reported on the IP registry activities of the InterNIC, giving also some background information about how their operation is organised. Overview statistics: - 3 staff handle 3000 - 4000 requests per month. - Each staff member handles approx 20-30 telephone calls per working day. - They handle approximately 5000/month allocations and assignments to ISP's. - 2000/month single and small block assignments. - Class B assignments are running at 20/month. This has been quite stable for some time. Address Justifications requested: class B's - min 10% utilisation expected - subnet mask plans - network diagrams class C's - CIDR blocks to ISP's gradual increase in allocations "handholding" procedure will be initiated in the future. - subnetting plans - host/subnet counts The procedure of referring small ISP's to larger ones for address space will change. Additional Services by IP Numbers Group - shared WHOIS project approximately 2000 reassignments/month - inverse address registration approximately 500 delegations/month - AS number allocation approximately 60/month currently not a lot of justification is required by requestors Current Issues facing the InterNIC - rfc1597/1627 policy on encourage its usage or not - single low host requests - "portable" addresses - ISP allocation guidelines - ISP's want to see these in writing - registry guidelines - the InterNIC is working with other Regional Registries in this area to coordinate and streamline efforts A copy of the presentation can be found in the presentations directory: ftp://ftp.ripe.net/ripe/presentations/xxxxxx kim nagged 3.2 RIPE NCC Report - Daniel Karrenberg The slides of Daniels presentation were part of the RIPE NCC Report which was presented in the plenary session, which are available from ftp://ftp.ripe.net/ripe/presentations/xxxxx nag dfk Overall the statistics shown in the report reflect the expected linear growth of the Internet with respect to DNS, the number of local IR's, It is expected that there will be around 240 local IR's by the end of 1995. The current breakdown is as follows: Enterprise Registry: 14 Last Resort Registry: 31 Provider Registry: 103 of which: 17 are large 29 are medium 57 are small It is clear that the growth curve of the number of new local registries in increasing. The new registries require more and more support and guidance and are a significant load factor on the RIPE NCC. However, the up side is that they should provide more income in the long term. The number of incoming messages to hostmaster is increasing and is now averaging around 37 messages a day. The workload and growth is such that this now accounts for more than 50% of staff time, leaving very little time for other needed activities. The staff situation is improving - now 4.5 FTE's, but is not enough to cope with the pace of growth. With reference to the invoicing for 1994, some erroneous bills have been sent for which Daniel apologised. In terms of activities over the last quarter, the RIPE NCC is just "keeping up". A better billing mechanism has been implemented, new classless db is running well, there has been internal reorganisation and new staff have to be trained. In the questions that followed, Daniel made it clear that the workload of the registry work was such that it had become clear that there was a need for a ticketing system that integrated with mail was needed. On this there was a request to the participants for input - Mark Kosters of the InterNIC has developed an in-house tool that might be useful although it is still under development. There was a question concerning the criteria for local registries: whether they were still the same as those stated in ripe-104. In response, Daniel noted that because of the very high number of new local registriess, the procedures for management of the address space with respect to the local registries has been tightened. Basically now, all new registries follow a "handholding" procedure with an assignment window of 0 which increments to larger amounts over time. Ripe-104 will be revised to reflect this. There was also a question regarding the newer "Enterprise Registries" and who qualifies in this respect. Enterprise Registries are those which coordinate the address space deployment for an organisation. One of the criteria to determine "eligibility" is the existence of a large corportate networking division within that Enterprise. It was felt that written guidelines were needed in this respect and that these should go into the next revision of ripe-104. 3.3 Local Registries Report Wilfried Woeber, had previously circulated to the list some questions concerning the policy on reallocation of address space in the light of an ACOnet customer who reallocated addresses. This is quite clearly undesirable. Wilfried said that he would put a clear message in the ACOnet application form in an attempt to prevent this, and urged other local registries to do likewise. 4. Charging in 1995 The charging model for 1995 is fixed. It was agreed at the RIPE contributors meeting held on September 21st, 1994. The workplan for 1995 and the expenditure budget of 407,000 ECU were presented at the meeting and both were unanimously accepted. The current status of the budget is that 30% of the planned expenditure has not yet been raised for 1995. During 1995, paying registries will receive a service level above non-paying registries. As from February 1st registries that have committed in writing will get a priority service. To speed up paperwork, the RIPE NCC will accept a committment to pay from a registry as though it is a formal agreement. This is only until February 28th, 1995. There were a number of comments and questions from the audience regarding the financial status of the RIPE NCC and the billing arrangements. Funders were encouraged to use the if they had any queries. There was a question concerning unfair competition from service providers who are not funding the RIPE NCC and therefore do not have the same financial committments. Daniel commented that he cannot determine who is and who is not a service provider, nor who is or who is not a registry. He can only control the service level they receive. 5. Future charging models Daniel Karrenberg reported on the current thinking for future changes to the funding model. The NCC Contributors Committee have discussed and approve a system of usage based charging in 1996. For this to be in place from 1996 onwards, it is vital that the discussions begin soon. Critical decisions need to be made regarding the metrics to be used, the percentage basis of the "usage" based fee. Input is sought from the local registries themselves and the discussion on the local-ir at ripe.net mailing list should begin between now and the next RIPE meeting in Rome. Concern was expressed that public bodies and government funded IP services will need to know their expected costs ahead of the financial year. 6. Training Given the overhead that the new registries are now putting on the RIPE NCC, it is clear that is now a need for some registry "induction" or training to take place. It was agreed at the contributors last year in September, that the start up fee would be used to provide some of the resources for this activity. The proposed medium for the training is the WWW. All local registries are asked to provide any material if they have in-house material themselves that is applicable. Action: Mike Norris To send mail to the list asking for input on the content of the training material. It was agreed that the focus of the training would not be "how to be a service provider" but on the functions of a local registry, especially with respect to RIPE interaction. 7. Revision of ripe-104 Very Small Enterprises - VSE's Previously circulated to the mailing list was a document by Daniel Karrenberg describing a proposed method of handling requests from VSE's whose address space assignment utilisation rates are very low. There was no feedback to the document so the discussions have died. Briefly, the document proposed the following : - if no outside connectivity and low host numbers, dont assign unique address space. - when VSE's do connect, ISP's are recommended to use dynamic address space assignment. Wilfried Woeber commented that the ideas presented in the paper sounded sensible, but he was concerned that he lacked a thorough understanding of the technical implications. It was agreed that an "applications document" was needed to accompany this proposal and to circulate the draft of this document to the list. Action: Daniel Karrenberg To draft outline "applciations document" to support the proposed plan on how to deal with address space requests from VSE's Action: Mike Norris To recirculate to the local-ir at ripe.net mailing list the document on VSE's as drafted by Daniel Karrenberg. Slow start of registries - Assignment Window In the next revision of this document, there will be a description of the "handholding" procedures and the sliding window mechanism which is now applied to all new registries. Daniel Karrenberg announced that a number of registries, in the past, have assigned excessive amounts of address space to their own organisations. This practice clearly does not follow the procedures for address space assignment and is not in the interests of conserving address space. After some discussion it was agreed that local IR's will themselves have a self-assignment window, with a threshold of either 4 or 8 class C`s which they can assign to themselves without review. Anything higher than this, must be submitted to the RIPE NCC for review. Daniel expressed a preference for a window of 4 class C's. Future of Last Resort Local IR's Last Resort IR's are not currently being charged for RIPE NCC services, because they provide valuable support function to the RIPE NCC. In the future, 2 options present themselves: o last resort IR's charge for their services like any other ISP and multiple ISP's may co-exist. They could be called "provider independant" registries o The distinction between last resort and other registries will disappear as all will be providing a chargeable service. This brings up the issue of the "ownership" of address space. The discussion of portable address space within the IANA is currently very topical. The IANA says that *unless* a contractual arrangement with the customer is made, by the ISP, the customer retains the right to take the address space with them if they change ISP. To try to negate this trend, ISP's could make a charge for out-of-block routing announcements. The customer is faced with the choice of a price/ renumbering trade-off. 8. Revision of European IP network number form (ripe-124) - There was a request that the supporting text for the admin-c: contact person asks that the contact person is available at the site of the network. 9. Global Coordination Daniel Karrenberg reported that both the InterNIC and the AP-NIC procedures with respect to address space assignments are in line with the RIPE NCC. However, the IANA does still make large assignments (which the InterNIC has to carry out). It is felt by all Regional Registries that rfc1466 is in need of revision. On Friday 27th January, 1995, a meeting has been scheduled between all the Regional Registries to discuss and align policies as well as draft a revision of rfc1466. Action: Mike Norris To circulate to the local-ir at ripe.net mailing list a summary of the meeting between the Regional Registries. 10. Reverse domains This is reported previously by Geert Jan de Groot under 18.3 11. Tools - Geert Jan reported that 70% of the reverse domain delegation requests contain errors in their set up and are returned to the sender. The French NIC is developing a tool (Christophe Chaillot) which does some error checking. The tool will be distributed once it is finished. - Daniel Karrenberg asked the audience how many people were using the stt tool developed at the RIPE NCC. No-one admitted to using it. 12. Database issues 12.1 RIPE handles Geert Jan gave a short presentation on the use of RIPE handles and how they can be generated using the tool that he has developed. The tool uses finger to find the first free handle in the RIPE database. Action: Geert Jan de Groot: to summarise the RIPE handle tool and to distribute to the local-ir at ripe.net mailing list. 12.2 Use of "person" object The use of the person object was clarified. The admin-c: contact should be a person and the tech-c: contact can be a NOC. 13. AOB Billing There is a directory ftp://ftp.ripe.net/ripe/new-registry which contains all the billing relevant documentation. Daniel Karrenberg asked everyone to note that the format of some of the information in this directory has changed recently. Part of the registry database maintained by the RIPE NCC has "billing information". Please note that if you are a member of the EU, you should quote your VAT number otherwise you will be charged +17.5% extra. If you have any doubts about the billing data we hold about your organisation please dont hesitate to check with to ensure that our data is correct and up to date. From mnorris at dalkey.hea.ie Wed Feb 22 12:28:05 1995 From: mnorris at dalkey.hea.ie (Mike Norris) Date: Wed, 22 Feb 95 11:28:05 +0000 Subject: Draft minutes of meeting at RIPE 20 Message-ID: <9502221128.AA18087@dalkey.hea.ie> Benoit is obviously right about this, and I'm sorry for letting the error slip through. I'll ask the scribe to change the minutes accordingly. (OK, David?). Mike ------- Forwarded Message Return-Path: Benoit.Grange at inria.fr Received: from vespucci.inria.fr (vespucci.inria.fr [128.93.2.27]) by ftp.inria.fr (8.6.8/8.6.6) with ESMTP id PAA23003; Tue, 21 Feb 1995 15:51:39 +0100 Received: (from grange at localhost) by vespucci.inria.fr (8.6.8/8.6.6) id PAA15477; Tue, 21 Feb 1995 15:47:50 +0100 Date: Tue, 21 Feb 1995 15:47:50 +0100 From: Benoit Grange Message-Id: <199502211447.PAA15477 at vespucci.inria.fr> To: mnorris at dalkey.hea.ie Cc: nic at nic.fr In-Reply-To: <9502211210.AA16679 at dalkey.hea.ie> (mnorris at dalkey.hea.ie) Subject: Re: Draft minutes of meeting at RIPE 20 Status: O Hello, thank you for the minutes of the local-ir meeting. I have seen a small error in the following paragraph: 11. Tools - Geert Jan reported that 70% of the reverse domain delegation requests contain errors in their set up and are returned to the sender. The French NIC is developing a tool (Christophe Chaillot) which does some error checking. The tool will be distributed once it is finished. I think the name for the author of this tool should be mine (Benoit Grange). Mr Chaillot is working at France Telecom and not in the french Nic. By the way, this tool is getting closer to a release line, but I still have to implement other language support (It is in french today). I will send an e-mail in the group when it will be ready. - -- Benoit Grange NIC France E-Mail: nic at nic.fr Personnal E-Mail : Benoit.Grange at inria.fr ------- End of Forwarded Message From hostmaster at ripe.net Wed Feb 22 18:40:40 1995 From: hostmaster at ripe.net (RIPE NCC Hostmaster) Date: Wed, 22 Feb 1995 18:40:40 +0100 Subject: Alert: Banque Nationale de Paris Message-ID: <9502221740.AA20456@ncc.ripe.net> Hi, We have received requests for IP address space from various sources for the Banque Nationale de Paris, in various countries. Since it looks like they are shopping around, and they already have a substantial amount of address space, we would like you to refer them to the RIPE NCC if they apply at your registry. Thank you. Geert Jan From Philip.Hammersley at PLUS.umi-at.at Wed Feb 22 21:15:09 1995 From: Philip.Hammersley at PLUS.umi-at.at (Philip.Hammersley at PLUS.umi-at.at) Date: Wed, 22 Feb 1995 21:15:09 +0100 Subject: Betr.: Alert: Banque Nationale de Paris In-Reply-To: <9502221740.AA20456@ncc.ripe.net> Message-ID: Thanks for the warning. If they come to us we will inform you. Regards, plus.at From G.Huston at aarnet.edu.au Thu Feb 23 00:52:01 1995 From: G.Huston at aarnet.edu.au (Geoff Huston) Date: Thu, 23 Feb 1995 10:52:01 +1100 Subject: Draft minutes of meeting at RIPE 20 Message-ID: <199502222352.KAA09626@nico.aarnet.edu.au> > 11. Tools > > - Geert Jan reported that 70% of the reverse domain delegation > requests contain errors in their set up and are returned to > the sender. The French NIC is developing a tool (Christophe > Chaillot) which does some error checking. The tool will be > distributed once it is finished. > >I think the name for the author of this tool should be mine (Benoit >Grange). Mr Chaillot is working at France Telecom and not in the >french Nic. > >By the way, this tool is getting closer to a release line, but I still >have to implement other language support (It is in french today). I >will send an e-mail in the group when it will be ready. have a look at http://www.aarnet.edu.au/aunic/inaddr-template.html (yes it's in english - but the procedure does the checks for correct configuration of the nominated servers) Geoff