- lir-wg - mailman.ripe.net

local hostcounts
by Mirjam Kuehne 15 Feb '95

15 Feb '95

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

1 0

Re: EUnets - again
by Daniel Karrenberg 07 Feb '95

07 Feb '95

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(a)eu.net > > To: Steve Druck <VUSTEVE(a)weizmann.weizmann.ac.il> > > 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(a)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

2 4

Re: finger for 'handle'
by Geert Jan de Groot 30 Jan '95

30 Jan '95

Hi Hakan, I wasn't very clear on this at the RIPE-meeting; sorry for that. You can check for the next free handle (using your name as example) with something like: finger handle.hh(a)whois.ripe.net Which should give back something like: First free handle: HH19-RIPE Note that this does NOT 'reserve' HH19-RIPE, as discussed in the meeting. This works with sunos 4.1.3 finger, BSDI 1.1 and 2.0 finger. Hope this helps, Geert Jan (copied in local-ir since more people are probably interested; I'll make something better as soon as I have some spare cycles) ---- On Mon, 30 Jan 1995 14:47:12 +0100 Hakan Hansson wrote: > I can't get the finger command in my client to work: > % finger hh handle(a)whois.ripe.net > (as suggested at the RIPE meeting) > ... using the finger client included in SUNOS 4.1.3.

1 0

A response to your comments
by The Internet Architecture Board 26 Jan '95

26 Jan '95

All - the IAB thanks you for your comments on our draft. We have discussed your concerns, and are actively re-drafting the document now. Once that has been completed, we would appreciate your further comments, should there be any. We wanted to take this opportunity to respond to some of the specific points that were raised (paraphrased). 1) "Were there substantiated rumours of denial of address allocations for legitimate requests?" We had heard rumours. However, these rumours were unsubstantiated. Since there were rumours which might be undermining the credibility of certain registries, the statement is meant to clarify that the registries do allocate unique addresses to organisations which request unique addresses according to the current guidelines specified in RFC 1466. 2) "What is the intent of this statement by the IAB?" Daniel stated it very succinctly: "The existence of private address space (RFC1597) shall not prevent any enterprise to obtain public address space according to the allocation criteria (currently RFC1466) if they wish to." We were not attempting to alter the operation or applicability of RFC1466. 3) "RFC1466 is unrealistic. What is being done about it?" We believe that action is being taken to revise 1466 via the same channels through which it was originally drafted - a new draft will be circulated via the Engineering and Planning Groups, and then into the IETF via the CIDRD working group. We depend on your assistance to those drafting that revision. We share your sentiment that the IPv4 address space is a scarce resource that must be conserved. We appreciate your endeavours along those lines. However we also stress that universal connectivity is also an important aim, and that anything which tends to detract from that needs careful examination. We understand that those two viewpoints are to some extent contradictory, and that a careful balancing act is needed to achieve both results to the fullest extent possible. We do not claim this is easy. In particular, with respect to RFC1597, another RFC that we believe needs some revision to clarify its applicability, we understand the potential uses of the mechanisms it proposes, however believe that we must take much care before encouraging or mandating its use. It is a reasonable thing for registries to bring the existence of RFC1597 to the attention of applicants for large amounts of IPv4 address space; however, careful wording is needed for any such notification. In particular, pronouncements should avoid implying that a requester may not receive a unique address allocation. It may be indicated that RFC1597 allocates lots of address space that can be used without constraints, whereas unique addresses will only be allocated to serve the real documented needs of the organisation. Also, the drawbacks of 1597 addresses should be made very plain and perhaps a pointer to RFC1627 given as well. The registries should take care to offer this as information, not advice, and leave the choice to the applicant. 4) "Does the IAB feel that RFC 1466 should be revised?" Yes. RFC 1466 is referenced since it is the only published criteria by which requests should be judged. 5) "Is the intent of the IAB to disallow registries from obtaining additional information?" No. 6) "Is it the intent of the IAB to disallow registries from recovering reasonable costs?" No. However, registries tend to have a de facto monopoly in their region so we feel strongly that any charges should be as low as possible. In the ideal world we would prefer users to have a choice of registries. 7) "Can the IAB express their views on the impact of the policies defined in the draft statement on the aggregation of address space into provider-based address blocks or does the IAB feel such aggregation is not a significant concern due to the impending implementation of IPv6?" We appreciated that address aggregation effectiveness may be reduced if addresses are not always allocated by a site's current provider. However, this decrease in effectiveness will be most noticeable in more local scopes, and decrease as the distance from the site increases. For instance, a site obtaining a number from any of several registries in Australia might be unable to aggregate routes at its provider's interface to the rest of the Internet, but the aggregation could possibly happen as the route leaves Australia, if not before. CIDR aggregation need not be perfect to be effective. How any of this will apply to IPv6 is yet to be seen. 8) "Are you stating that it is acceptable for registries to decline to allocate space if an organisation does not implement VLSMs?" This is something that should be discussed in the revision of RFC1466. One opinion may be that this may depend on the amount of address space the organisation requires, and how much difference the implementation of VLSM's would make to that requirement. It may be that the correct response is to allocate the amount of address space that would be reasonable if VLSM's were in use, and then allow the organisation to decide whether to do the work necessary to make VLSM's possible, or live with partial global connectivity. If we have failed to answer a question that has been posed concerning the draft, please feel free to resend your question. Once again, thanks for your input. kre, for the IAB.

1 0

Address allocation, local procedures for review
by Wilfried Woeber, UniVie/ACOnet 24 Jan '95

24 Jan '95

Dear all, I was encouraged by a couple of friends to submit the follwoing text to a wider audience for discussion and review. I would be very interested in receiving your thoughts or comments. Maybe we can shortly touch this at the WG meeting, as well. Here we go... Wilfried. -------------------------------------------------------------------------------- >What has not yet been mentioned I noticed is the even worse situation of >customers changing provider and thus splitting CIDR blocks. In effect its >the same as AUP/non-AUP allocation above. This will also have an affect >on routing table size - what to do in these cases ? Well, I'm currently doing the design for an update to our (ACOnet Local-IR's) "official" letter that goes with any newly allocated address. In addition to the obvious and local stuff (mailing lists, DB update, and so on) I plan to include the following rules: - the addresses are allocated for (eventually) connecting to *ACOnet*. - address space must not be given away to "third parties" without the prior knowledge and explicit consent of the ACOnet Local-IR. It may however be used to connect other organisations downstream in tree-structured approach - as long as the technical and organisational responsibility remains with the original recipient of the address space. - should (for whatever reasons) the connection not be implemented with ACOnet, then both ACOnet and any other service provider involved may request the re-numbering of this site, allowing a reasonable timeframe for achieving this. - there are some more things to be added which are referring to necessary steps to actually request, obtain (and in some cases pay) for the connection and band-width used which are not relevant for the Local-IR point of view. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------

1 0

RIPE meeting special request
by RIPE NCC Staff 20 Jan '95

20 Jan '95

Dear All, I would like to ask your help at the forthcoming RIPE meeting. I am "retiring" from the minute-taking task at this and future RIPE meetings :-). Instead, David Kessens our new colleague will be doing this. Since this is his first time, I will of course be helping him, but it would be great if everyone who is giving a presentation could coordinate with David and with the Working Group chairs so that the task of collecting all the information for the minutes is made easier for him. Your help is much appreciated. (aplogies to anyone who gets this message twice) Kind Regards, Anne RIPE NCC

1 0

RIPE20 : Terminal room facilities
by RIPE NCC Staff 20 Jan '95

20 Jan '95

Terminal-room facilities during the RIPE-meeting. ------------------------------------------------- Time allowing, we will provide a terminal room during the RIPE meeting. There will be a number of ASCII terminals connected to a terminal-server (hef-ts1.nikhef.nl or hef-ts2.nikhef.nl), which will allow for telnet access. We will also provide ethernet tap points for laptop computers. 10base2 and 10baseT will be provided. 110V will be available too, on request of some of our guests from other continents. We will assign static IP addresses to persons to avoid having to reconfigure their machines. People in need of a 'permanent' IP address for the time of the meeting should send a message to <ncc(a)ripe.net> with 'Terminalroom' in the subject; the addresses will be assigned on-site. People that need to have access lists changed should allow access from 192.16.199.0/24 and 193.0.0.0/24. Printer access will be provided via an uuencoded-file-via-mail gateway. Unfortunately, Apple localtalk access cannot be provided, sorry. We're not trying to match an IETF terminal room, but if you have special requests in this area, please send them to us. Kind regards, Geert Jan de Groot

1 0

Invitation to join the RIPE CDS
by RIPE NCC Staff 16 Jan '95

16 Jan '95

Dear RIPE NCC contributor, I would like to inform you that the RIPE NCC in cooperation with the RIPE Connectivity working group maintains an archive where all RIPE NCC contributors are kindly invited to publish information about their connectivity and offered services. The RIPE informations services are widely used and therefor the RIPE NCC servers are a good place to publish such kind of information to reach a wide Internet audience. According to the decision of the last RIPE meeting the Connectivity Document Store (CDS) can contain plain text information and maps of your network or it can only contain an HTML pointer to information stored on your own server. You can get more information about the CDS and hints about the proposed structure of published information on http://www.ripe.net/cds.html You are willcome to send questions, CDS factsheets or HTML pointers to <cds-editor(a)ripe.net>. With my best regards Milan Sterba Convenor of the RIPE connectivity WG <milan_sterba(a)hp7100.desk.hp.com>

2 1

RIPE20: Draft meeting schedule
by RIPE NCC Staff 13 Jan '95

13 Jan '95

Folks, please find below the preliminary scheduling of the various meetings for the coming RIPE event. Comments are welcomed, but please realise that scheduling parallel meetings is one of the most complicated problems known to mankind :-) See you in Amsterdam, Rob 20th RIPE Meeting Amsterdam, 25-27 January 1995 Preliminary Meeting Schedule ---------------------------- Wednesday 25 January 1995 ------------------------- 09:00 - 10:45 EOF 10:00 - 10:45 Introduction to RIPE and the RIPE NCC 10:45 - 11:15 B R E A K 11:15 - 12:30 EOF 11:15 - 12:30 Introduction to RIPE and the RIPE NCC 12:30 - 14:00 L U N C H 14:00 - 15:30 + NIDUS + Local IR (1) 15:30 - 16:00 B R E A K 16:00 - 18:00 + Mbone + Database (1) + DNS Thursday 26 January 1995 ------------------------ 09:00 - 10:30 + Local IR (2) + Routing 10:30 - 11:00 B R E A K 11:00 - 12:30 + Connectivity + Database (2) 12:30 - 14:00 L U N C H 14:00 - 15:30 Plenary RIPE Meeting 15:30 - 16:00 B R E A K 16:00 - 18:00 Plenary RIPE Meeting 20:00 - ... D I N N E R Friday 27 January 1995 ---------------------- 09:00 - 10:30 Plenary RIPE Meeting 10:30 - 11:00 B R E A K 11:00 - 12:30 Plenary RIPE Meeting 12:30 - 14:00 L U N C H 14:00 - 16:00 Plenary RIPE Meeting

1 0

ANNOUNCEMENT: Dinner 20th RIPE Meeting
by RIPE NCC Staff 13 Jan '95

13 Jan '95

* ANNOUNCEMENT * * ANNOUNCEMENT * * ANNOUNCEMENT * * ANNOUNCEMENT * * 20th RIPE Meeting Dinner Thursday, January 26th, 1995 Amsterdam Venue: Haesje Claes Spuistraat 273-275 Amsterdam Time: 20:00 Last date for reservations: Friday 20th January 1995 The RIPE Evening Dinner will be held in the "Haesje Claes". This restaurant is a traditional Dutch restaurant with a history dated back to 1520. Below is our traditional Dutch dinner (sort of). If you want to attend this dinner, please would you complete the form below and we will make the reservation for you. Please note that it will NOT be possible to attend the dinner without first making a reservation. This time we are limited to specific number of places and we have to let the restaurant know how many of each dish to prepare. If you would like to bring a guest with you, they are very welcome, but please complete a separate form for them. See you at the dinner, David Kessens RIPE NCC PS. New forms can be obtained from : ftp://ftp.ripe.net/ripe/Next-Meeting/ripe20.dinner.announce OR by using : finger dinner(a)ripe.net OR by using the form provided at the end of this mail. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The menu for the dinner is as follows: -**- Aperitif Drink -**- Smoked eel OR Mushrooms fried with sweet pepper and onions -**- Fried salmon fillet lobstersauce OR Tournedos peppersauce -**- Appledumpling with cinnamon ice and sauce -**- Dutch cheese plate -**- Coffee and bonbons -**- *Cost of the dinner will be DFL 70,- *Please note that the price of the dinner includes 3 drinks/person. Please reply to <dinner(a)ripe.net> if you would like to have a place reserved for you at the dinner. Unfortunately you will not be able to attend without prior registration, so please let us know asap. - - - - - - - - - - - - -- - - - - - - -- - - - - - - -- - - - - - -- 20th RIPE Meeting, Amsterdam Evening Dinner 26th January, 1995 %START 1) Your name # NAME [ ] 2) Your e-mail address # EMAIL [ ] 3) Please indicate if you are a vegetarian or have special dietary needs. If yes please enter Y in the box below. If no please enter N in the box below. # SPECIAL_DIET [ ] Please indicate the diet you need : You can use more lines as long the description starts and ends with a bracket. (I am a vegetarian so don't worry you lonely vegeatrians out there ;-)) # SPECIAL_DIET_DESCRIPTION [ ] 4) Please specify your starter with an "S" or an "M" in the brackets. S = Smoked eel M = Mushrooms fried with sweet pepper, onions and pepper # STARTER [ ] 5) Please specify your main course with an "F" or "T" in the brackets. F = Fried salmon fillet lobstersauce T = Tournedos peppersauce # MAIN_COURSE [ ] %END

1 0