January 1995 - lir-wg - mailman.ripe.net

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

IMPORTANT NOTICE
by RIPE NCC Hostmaster 12 Jan '95

12 Jan '95

Dear Local-IR'ers, Societe Generale is an Enterprise Registry coordinating address space for their enterprise. We have received a message from a local-ir that they have applied for additional address space to them and intend to contact other local registries across Europe for address space. Please note that as an Enterprise Registry they should only be in touch with the RIPE NCC for additional address space. If you receive a request from them, please forward it to us. Many thanks, Anne Lord RIPE NCC

2 1

Draft agenda for mtg at RIPE 20
by mnorris＠dalkey.hea.ie 12 Jan '95

12 Jan '95

Many thanks to all who enhanced the draft agenda I circulated last week. The current draft (see below) is still open to comments and ideas, but it looks like our meeting is going to need two time slots (Wed afternoon and Thu morning). I hope this is OK with the RIPE Chairman. RIPE 20 - 25-27 January 1995 Local IR Working Group D R A F T A G E N D A 1. Preliminaries - select a minute-taker - agree agenda, times 2. RIPE 19 - minutes - actions 3. Reports from registries - presentation from the Internic (Kim Hubbard) - European regional registry (NCC) - registries in technologically developing countries - other registries, significant events 4. Charging in 1995 - contributors committee decisions - later developments (or lack thereof) - charging model 1995 - billing procedures - different service levels 5. Future charging models - 1996 needs to be more usage based - charging by local IRs - general issues, problems, solutions - the future of last-resort registries 6. Training - audience - materials - delivery (WWW?) 7. Revision of ripe-104 - slow start of registries (assignment window) - very small enterprises (VSEs, from EJB) - last resort issues 8. Revision of network number form 9. Global registry coordination 10. Reverse domains - counts, errors - administration 11. Tools 12. RIPE handles 13. AOB Cheers. Mike Norris

1 0