- ripe-list - mailman.ripe.net

RIPE and EBONE-93
by Marten Terpstra 08 Sep '92

08 Sep '92

The following I ask on behalf of the EBONE as a request to the RIPE community. The EAT would like to get the RIPE peoples wish-list for Ebone 93, Proposals, ideas or any other input is welcome. Please send any reply to Berhard Stockman (boss(a)ebone.net) of Peter Lothberg (roll(a)stupi.se) or to the whole list if you think it is of general interest. They will compile it into a document, which will be presented at the ECCO meeting coming Monday. Time is rather limited, so please send in any ideas before Friday noon, so that the Berhard and Peter will have time to compile it into something. Among matter of interest that need input are - Financial models for EBONE - High speed pilot on EBONE - AUP free implementation of Transatlantic links - Multicast support in EBONE - Other subjects ? Peter and Bernhard will appreciate any ideas/suggestions that you may have. Thanks all, -Marten

1 0

Re: FYI: Someone wants to build a monopoly.
by Peter Lothberg 07 Sep '92

07 Sep '92

> > matsb(a)sics.se writes: > > PS > > > > I am not saying anything about the need for the open structure to > > allow for routing arbitration for ALL providers et c...) > > > Mats, > > could you share with us what this means. Do you think it is not necessary or > that it *is* necessary? Do you think it is achievable. > > I think it is necessary and achievable and that the right place to do it > is RIPE. > > Daniel Daniel is right, Ripe just have to add X25, and 55 man staff to move papers around. -:) -Peter

1 0

FYI: Someone wants to build a monopoly.
by Peter Lothberg 07 Sep '92

07 Sep '92

Date: Mon, 31 Aug 1992 14:34:34 +0200 From: ullmann(a)dfn.dbp.de Subject: EBONE integration scenario To: ou(a)rare.nl Message-id: <920831143433*/S=ullmann/PRMD=dfn/ADMD=dbp/C=de/@MHS> X400-Received: by mta relay.surfnet.nl in /PRMD=surf/ADMD=400net/C=nl/; Relayed; Mon, 31 Aug 1992 14:35:44 +0200 X400-Received: by /PRMD=GmD/ADMD=DbP/C=DE/; Relayed; Mon, 31 Aug 1992 14:34:27 +0200 X400-Received: by /PRMD=DFN/ADMD=DBP/C=DE/; Relayed; Mon, 31 Aug 1992 14:34:34 +0200 X400-Originator: ullmann(a)dfn.dbp.de X400-Recipients: ou(a)rare.nl X400-Mts-Identifier: [/PRMD=DFN/ADMD=DBP/C=DE/;dfnberlin2251920831143434-GXm] X400-Content-Type: P2-1984 (2) X-Envelope-to: HWG OU-SC, 24 August 1992 Report to the OU shareholder meeting on the EBONE integration scenario ====================================================================== I. Task: The OU Steering Committee (OUSC) had the task to identify an ------- integration scenario for the IP service which is presently been organised under the name EBONE. During that discussion a statement from th EBONE management committee has been sent to the OUSC (see annex 2). This document describes a possible scenario to incorporate EBONE in the OU Business Plan. The General Assembly is asked to decide upon this scenario as the answer to the statement of the EBONE management committee. II. External Material Used: -------------------------- 1) Ebone Line and Site Installation Specification Ebone Action Team (B.Stockman); 24 February 1992; 2) Management and Operation of the Ebone B.Stockman; 13 April 1992; 3) Ebone '92 IP Routing Model T.Bates, P.Lothberg; June 1992. While 1) gives an overview on the technical details, 2) deals with operational management procedures and 3) indicates the construction principles of the Ebone configuration. In addition to this material facts and figures about Ebone have been supplied by several members of the Ebone Management Committee (Dennis Jennings and Kees Neggers). These figures are the basis of the cost analysis described in Annex 1. III. Results: ------------ 2. General OU Multiprotocol Service It is proposed that the OU should in the context of the Multiprotocol Backbone Service (MPBS) offer three different types of access: a) native X.25 (through access points P1i, i=1,2,3...; see fig.1); b) native IP - pilot version through EMPP (through access points P2i, i=1,2,3...); c) native IP - through the existing Ebone structure (through access points P3i, i=1,2,3...). The commercial conditions for P1i and P2i are described in the umbrella contract between PTT Telecom and -at present- RARE. Both IP offerings are connected via two interface boxes (IF1 and IF2); the whole MPBS of the OU can then be viewed in the following way: +----------------------MPBS box----------------------+ I +-----------------EMPP box-----------------+ I P11---o----I I----o---P21 . I I . . I I . P1i---o----I I----o---P2j I +------------------------------------------+ I I I I I I +-----+ +-----+ I I I IF1 I I IF2 I I I +-----+ +-----+ I I I I I I +------------------------------------------+ I I I +-------------Ebone Kernel-----------+ I I I I I I I----o---P31 I I I I I . I I I I I . I I I I I----o---P3k I I +------------------------------------+ I I I +-----------------Ebone box----------------+ I +----------------------------------------------------+ fig.1 General OU Multiprotocol Service According to 1) the Ebone Kernel box comprises at present the following configuration with the line# taken from 1): Stockholm Amsterdam CERN +-----2.2--------------*-------2.1-------* I I 2.3 2.5 *-------------------2.4------------------* London Montpellier fig.2 Ebone Kernel box After an initial period the OU will base its IP service offering on one system, and it will take the results of the EMPP evaluation into account in its choice of system. Until that moment customers are free to choose which IP services they want to buy, EMPP and/or Ebone. 3. Organisational Structure The OU will sell the IP service based on EBONE (P3i) to customers on a contractual basis. That implies towards the customers that the EBONE system is exactly specified in advance and can only be changed in agreement with the parties affected by these changes. The OU will subcontract suppliers of lines and sites that houses and manages Ebone Boundary Systems (EBS). It is recommended to keep these contractual relations as light weight as possible as far as a) the formal relation between the OU and the EBS sites respectively, b) the OU and the organisations responsible for the lines, c) the OU and the organisation that employs the operational staff are concerned. It is assumed that operational procedures are taken from existing descriptions. 4. Quality of Service Guarantees It is recognized that the service provided through the Ebone structure has no well defined quality of service parameters and there are no guarantees for which the customer of the OU can make responsible either the OU or one EBS site or one organisation in charge of line provision or provision of operational staff. The Ebone consortium will be invited to describe on short term the present service levels as good as possible in order to allow the OU management to define the actions required to maintain these service levels. 5. Cost Analysis and Tariffs In Annex 1 a model is presented describing the present Ebone box in terms of backbone lines, gateways, access lines, equipment and staff; all based on a number of assumptions. These assumptions have been communicated with some members of the Ebone Management Committee but not yet with the other participants in Ebone. For that reason these assumptions have a preliminary character. The model is more or less the same as the model used for the OU business case. After the assumptions it is built up in three parts: the requested access services from the customers, the costs of the services and the allocation of costs (tariffs). The methodology used for the allocation of costs is equivalent with the one used in the RARE- PTT Telecom contract for the EMPP box. The tariffs for the IP services provided through the EMPP- and Ebone structures are different and not cross-subsidized. A warning has to be made that it is not possible to make a straight comparison in terms of price and performance between EMPP IP services and Ebone IP services due to the lack of service level guarantees within Ebone. 6. Customer Base The OU will accept present Ebone customers as customers of the OU provided that: a - the purpose and usage of the connection is in line with the OU mission statement and b - no third party traffic, neither international nor national, is allowed without written permission from the OU management. 6. Migration After an initial period the OU will base its IP service offering on one system. This initial period will end as soon as this intended single systeem has demonstrated its operational capabilities and is able to supply the customers with the same or better services against the same or better prices. After this initial period the OU management will decide upon the migration scenario. The costs for the migration from the Ebone to the final MPBS production phase are seen as transition costs which has to be covered by a (special) OU budget line. These costs comprise for example parallel lines etc. It must be possible to cancel lines at the shortest possible time; i.e. Ebone backbone and access lines have to be based on contracts for an initial period of at most one year with a cancellation period afterwards of at most three months. 7. Clearing of Costs Based on the cost allocation scheme in Annex 1 the OU will invoice in advance on a quarterly basis the Ebone customers for who the tariff is higher than the total of accepted costs. The OU will reimburse in the second month of the actual quarter the Ebone customers for who the tariff is lower than the total of the accepted costs. Based on this clearing method the working capital needed by the OU to accept the commercial responsibility for the Ebone services will not exceed 200 KECU. Annex 1 Operational Unit Ebone Cost Analysis 1993 (in ECU) ----------------------------------------------------------- 1. Assumptions 1.1 Backbone: Status Link Speed Real Accept. Covered by: Aug. 92 costs costs Operat. Stockholm-Amsterdam 512 275000 275000 NORDUnet Operat. Amsterdam-Geneva 512 270000 270000 SURFnet Operat. Geneva-Montpellier 256 141000 141000 RENATER On ordr Montpellier-London 256 147000 147000 RENATER Operat. London-Stockholm 256 178000 178000 NORDUnet 100% of real costs will be accepted. Total accepted costs backbone: 1011000 1.2 Gateways: Status Location Speed Real Accepted Covered by: costs costs Planned EMPP-London 256 0 100000 JANET Planned EMPP-Amsterdam 256 N/A 0 PTT/Telecom Operat. HEPnet-Geneva 512 N/A 0 CERN 100% of the (virtual) gateway costs EMPP London will be accepted. Gateway costs EMPP Amsterdam will be carried by EMPP. Gateway costs HEPnet CERN will be carried by CERN. HEPnet is for 1993 accepted as a peer connection to Ebone. Total accepted costs gateways: 100000 1.3 Access lines: Status Link Speed Real Accept. Covered by: Aug. 92 costs costs Operat. Amsterdam Madrid 64 82700 62025 Rediris On ordr Amsterdam Munich 128 98600 73950 ECRC On ordr Amsterdam Vienna 128 107600 80700 ACOnet Unknown Geneva-Athens 64 80000 60000 ARIANEt Operat. Geneva-Tel Aviv (*) 64 40725 40725 ILAN On ordr Geneva-Vienna 256 182500 136875 ACOnet Operat. Montpellier-Crete 9.6 42600 31950 GREARN Operat. Montpellier-Leuven 64 44200 33150 Univ.Leuven 75% of costs will be accepted; 25% is regarded as local loop. (*) Tel Aviv half channel European side is 100% accepted. Total accepted costs access lines: 519375 1.4 Equipment: There are at present four Ebone Boundary Systems (EBS) plus one at CERN. Investments per EBS are 30000; depreciation in 4 years; maintenance 10% per annum. Costs local equipment CERN will be carried by CERN. Accepted depreciation costs: 30000 p/a Accepted maintenance costs: 12000 p/a Depreciation costs and maintenance costs are at present covered by several parties. 1.5 Staff: Central staff: 2 fte, 50000/fte. Costs 100000 covered by NORDUnet. Local staff per EBS: .25 fte, 50000/fte. Costs 37500 covered by EBS sites. 100% operational staff costs will be accepted but local staff CERN will be carried by CERN. Total accepted costs staff: 137500 2 Requested services 2.1 Relative weights access speeds: speed access points 9.6 0.5 64 1 128 1.8 256 3.5 512 6 1000 8 2000 11.4 2.2 Present customer demand: Customer access 1993 points status NORDUnet 512 6 OK SURFnet 512 6 OK JANET 256 3.5 ? RENATER 256 3.5 OK EARN 64 1 ? EUnet 64 1 ? ACOnet 128 1.8 ? ACOnet 256 3.5 ? Rediris 64 1 OK upgrade planned Un.Leuven 64 1 ? GREARN 9.6 0.5 ? ILAN 64 1 ? ECRC 128 1.8 OK SWITCH 256 3.5 ? Total points 36.1 3. Costs Accepted costs: Backbone lines 1011000 Gateways 100000 Access lines 519375 Equipment 42000 Central staff 100000 Local staff 37500 Total accepted costs: 1809875 Total accesspoints 36.1 Costs per accesspoint: 50135 4. Tariffs Proposed tariff 1993: Customer tariff 93 minus accepted costs to pay: per annum backb./ access equipm./ gateway lines staff NORDUnet 300810 453000 110500 -262690 SURFnet 300810 270000 44000 -13190 JANET 175473 100000 12500 62973 RENATER 175473 288000 12500 -125027 EARN 50135 50135 EUnet 50135 50135 ACOnet 90243 80700 9543 ACOnet 175473 136875 38598 Rediris 50135 62025 -11890 Un.Leuven 50135 33150 16985 GREARN 25068 31950 -6882 ILAN 50135 40725 9410 ECRC 90243 73950 16293 ARIADNE 50135 60000 -9865 SWITCH 175473 175473 total 1809875 1111000 519375 179500 0 Annex 2: Statement EBONE MC --------------------------- The Operational Unit Steering Committee received in July 1992 the following message from the Ebone Management Committee: " The Ebone MC has addressed the continuation of the Ebone '92 IP service for 1993. Ebone MC has noted the plans and progress in setting up the OU and the OU's intention to provide a pan-European multi-protocol backbone service. Ebone MC has concluded that to be able to secure a proper continuation of IP backbone services in Europe it will be necessary to continue the current IP services at least until mid 1993. The Ebone MC is keen on optimising the transition process from the current situation to a single pan-European multi-protocol backbone service and on minimising the organisational overhead involved. Therefore, the Ebone MC offers to propose to the Ebone participants that the Operational Unit takes up full organisational and commercial control over the Ebone '93 IP services as soon as possible. This proposal is conditional to the OU being prepared to continue the operation of the Ebone IP technical infrastructure until the intended MPBS has demonstrated its operational capabilities to replace it."

4 4

Data Communications - Aug 1992 issue
by Hank Nussbacher 07 Sep '92

07 Sep '92

Cover story of August 1992 issue of Data Communications is: Internet Europe Is Commercial Traffic in the Stars? As usual Data Communciations does a very good job on the topic. Hank Nussbacher

2 1

Re: Data Communications - Aug 1992 issue
by Dave Morton 07 Sep '92

07 Sep '92

>Cover story of August 1992 issue of Data Communications is: > >Internet Europe >Is Commercial Traffic in the Stars? > >As usual Data Communciations does a very good job on the topic. > >Hank Nussbacher > Yes - true - especially the bit about stopping the EC gravy train... Dave

1 0

RIPE meeting - agenda (draft)
by k13＠nikhef.nl 02 Sep '92

02 Sep '92

Draft Agenda 13th RIPE meeting ============================== The following points have been brought up as items for discussion in the plenary sessions of the forthcoming RIPE meeting. Of course, the standard items will also be there: minutes, action points, working group reports, etc. People who have further suggestions, please let us know a.s.a.p. A copy of the meeting announcement is also attended to this message. 1. RIPE position paper 2. RIPE and RARE - the technical program - report from the RARE CoA 3. EBONE progress report 4. EMPB IP services 5. RIPE NCC - report - the future of 6. Global Address Assignement 7. IP Registration form - can we have a common format among all NICs ============================================================================== R I P E meeting announcement ============================= This is to announce that the 13th RIPE meeting will take place: dates: 30 September 14:00h - 18:00h 1 October 09:00h - 18:00h 2 October 09:00h - 16:00h place: Ecole Nationale Superieure des Telecommunications (Telecom Paris) 46, rue Barrault Paris 13 metro: - Place d'Italie, or - Corvisart NOTE: - In order to facilitate the logistics of the meeting, could you please give notice of your coming a.s.a. possible to anne(a)ripe.net and NOT TO THE LIST. - old hands: please bring your RIPE badge - newcomers: please provide the following info for your badge: + full name + affiliation + country to the above address. Agenda: a detailed agenda will be mailed the first week of September. Don't hesitate to suggest topics of interest. Appended to this announcement: - how to reach the meeting place - hotels in Paris ############################################################################## How to reach the Ecole Nationale Superieure des Telecommunications ================================================================== - Take the RER-B to Chatelet from the airport. - Transfer to Line 7, direction Mairie d'Ivry/Villejuif. Don't get lost, it's a bit of a labyrinth. - Get off at the metro station Place d'Italie. - Exit onto "rue Bobillot". - Walk south-west down rue Bobillot until you come to the second set of traffic lights and a church on the right-hand corner. - Turn left and walk west on rue Tolbiac. - After 4 short blocks, you will find yourself standing in front of a large, fairly modern apartment build with a highly visible "La Poste" sign in front. - Turn right up the street (rue Barrault), go 20m, and you will be standing in front of the main entrance of the school. - Directions will be posted inside. ############################################################################### Hotels in Paris, conveniently reachable from the meeting place: Name/Price Address Phone Fax =========================================================================== Hotel Urbis 177, rue de Tolbiac 45.80.16.60 45.80.95.80 FF 350 75013 Paris TIM Hotel 22, rue Barrault 45.80.67.67 45.89.39.63 FF 360 75013 Paris Pullman St-Jacques 17, bd St-Jacques 40.78.78.40 45.88.43.93 FF 1015 75014 Paris Hotel Etchegarry 43, rue Broulebaide 43.36.22.41 FF unknown 75013 Paris All phone and fax numbers should be read as: +33 1 <quoted number>

1 0

Re: European IP requests - template
by bob＠informatics.rutherford.ac.uk 02 Sep '92

02 Sep '92

Daniel Karrenberg <Daniel.Karrenberg(a)net.ripe> writes: > After giving it some thought I strongly believe that we should go for a > European IP network number *registration* form and eventually for a > worldwide one. I agree. If others on this list think it's worthwhile, I'll circulate the form we use, plus the reasoning for its design, as input. If RIPE does come up with a useable "standard" form, we'll switch to using it. (This is a bit of a pain at this stage, as it'll mean a change to our documentation, but I'd consider the longer term benefits worth the short term extra work.) Regards, Bob Day JIPS

2 1

RIPE DNS Hostcount August 1992
by Marten Terpstra 02 Sep '92

02 Sep '92

All, Hostcount once more. Again a nice increase of almost 10,000, to 221951. The only one country going down a bit is Hungary, due to unreachable nameservers. We welcome Great-Brittain (.gb) in the European networking scene ;-) Unfortunately due to a mistake, the files with all zone output are unavailable this time. They will return next month. Some people have suggested that parts of this hostcount could be done distributed, to get more accurate figures, and keep network load as low as possible. I am happy to discuss a scheme for this at the next RIPE meeting. Some people have requested to have the history of the hostcounts distributed with the hostcount every month, to keep track of what has passed over the months/years. You can find the previous hostcounts below the hostcount for August. Unfortunately, some of the counts are missing, mainly in the period when I did this still at NIKHEF. Also some of the earliest counts may not be as reliable as the last year or so. Much has changed to the program. Enjoy, -Marten RIPE DNS Hostcount Previous Count : Mon Aug 3 1992 This Count : Mon Aug 31 1992 CY SOA COUNTED DUPL REAL CHANGE ============================================================ al 1 0 0 0 0 at 161 6831 26 6805 + 277 be 17 1512 55 1457 + 20 bg 1 0 0 0 0 by 0 0 0 0 0 ch 58 17888 106 17782 + 762 cs 10 686 62 624 + 624 de 855 48533 917 47616 + 1788 dk 72 3117 43 3074 + 295 dz 0 0 0 0 0 ee 1 37 0 37 + 37 es 149 3891 57 3834 + 115 fi 131 17018 150 16868 + 1005 fr 293 19343 180 19163 + 390 gb 1 1 0 1 + 1 gr 41 612 135 477 + 113 hr 0 0 0 0 0 hu 3 33 0 33 - 66 ie 22 667 4 663 + 37 is 8 447 1 446 + 46 it 176 5166 192 4974 + 122 il 40 2897 51 2846 + 65 lt 1 0 0 0 0 lu 5 79 1 78 0 lv 1 0 0 0 0 nl 260 21567 369 21198 + 937 no 299 15041 172 14869 + 625 pl 49 676 11 665 + 271 pt 47 1407 22 1385 + 60 ro 0 0 0 0 0 se 318 21912 175 21737 + 878 si 1 0 0 0 0 su 125 26 0 26 + 10 tn 2 9 0 9 + 1 ua 0 0 0 0 0 uk 306 39764 4493 35271 + 1316 va 0 0 0 0 0 yu 2 13 0 13 0 ============================================================ 3456 229173 7222 221951 + 9729 History Oct 1990 31724 Nov 1990 33665 Dec 1990 29230 Jan 1991 43832 Feb 1991 - Mar 1991 44506 Apr 1991 46948 May 1991 - Jun 1991 63267 Jul 1991 - Aug 1991 73069 Sep 1991 92834 Oct 1991 104824 Nov 1991 129652 Dec 1991 - Jan 1992 - Feb 1992 161434 Mar 1992 167939 Apr 1992 170050 May 1992 182528 Jun 1992 196758 Jul 1992 213017 Aug 1992 221951

1 0

Re: IAB's proposals in response to the work of the ROAD group
by Denis.Russell＠newcastle.ac.uk 02 Sep '92

02 Sep '92

Re: X-Mail-Interface: Macintosh Eudora (Ac.Comp.Centr.Utrecht) Date: Wed, 2 Sep 1992 09:33:46 +0100 To: raresec(a)rare.nl From: raresec(a)rare.nl Subject: Re: IAB's proposals in response to the work of the ROAD group Cc: ripe(a)ripe.net, iptag(a)jnt.ac.uk ... >>Since there has been only one (positive) reaction so far, may I conclude >>that RIPE as a whole is supporting the IAB position? I am wondering >>how many people have read it and thought "If I don't oppose it is clear >>that I agree". So please if you are in favour or of RIPE supporting this, >>send me a personal mail message. I'll count them and report back to the list. >> >>Daniel > >Daniel, > I don't think that I can either support or oppose the IAB position. >...etc... I sent that message to ripe and iptag ages ago now. The date on my copy of the outgoing message is: Date: Thu, 9 Jul 1992 14:14:36 +0100 It is a bit weird seeing it reappear after such a delay. It also makes my comments therein seem a little strange. A lot has happened since then. Where has the message been? Denis.

1 0

Re: IAB's proposals in response to the work of the ROAD group
by raresec＠rare.nl 02 Sep '92

02 Sep '92

>Since there has been only one (positive) reaction so far, may I conclude >that RIPE as a whole is supporting the IAB position? I am wondering >how many people have read it and thought "If I don't oppose it is clear >that I agree". So please if you are in favour or of RIPE supporting this, >send me a personal mail message. I'll count them and report back to the list. > >Daniel Daniel, I don't think that I can either support or oppose the IAB position. I have been following the Big-Internet discussion for a few weeks now, and I still don't believe that I sufficiently understand all the issues to give a considered opinion. This applies both to "purely technical" issues, and "mainly operational/political" issues, and all issues in between. (I'm not even sure this is a one-dimensional space :-)). There does not even seem to be any consensus on Big-Internet on how urgently "a solution" is required. Although the need for a solution to the class-B shortage is widely recognized, there is a wide diversity of opinion about how much time interim solutions like CIDR would buy, and thus exactly how urgent the, a, next stage is. The IAB proposals produced a deluge of opinion and dissent on Big-Internet and Ietf over the last weekend. Discounting the bigotry :-), some hard issues emerged. For example, of the two urgent matters, address exhaustion and routing table explosion, there is nothing in the IAB proposal about routing table explosion (i.e. routing aggregation, etc), and Jon Crowcroft has pointed out that if certain accepted NSAP allocation schemes are assumed, then only 5 bytes of CLNS addressing are left. Some believe that adopting CLNP to get 5 addressing bytes rather than 4, and no solution to routing table explosion doesn't look like a good way forwards. This has lead onto a discussion of exactly what the IAB proposal actually means. One extreme is "CLNP standard exactly, together with accepted NSAP allocation", another extreme is "well take IP as a starting point and CLNP is a step forward. Where do we go from there", and, needless to say, all points in between. There have been various messages trying to clear up this confusion, and discussing the implication of various points in this spectrum of interpretation. The above is not deliberately my opinion, but an attempt to summarise my understanding of a very active list. The discussion archives of a little while ago contained 884474 bytes, and that is just for this month. Most of it must be the message storm over the IAB proposal. I must have missinterpreted something if not many things. Please refer back to Big-Internet for the actual discussion. I believe that it is extremely important and urgent that a short-term fix be put into place - presumably CIDR. I believe that it is also extremely important and urgent to decide on the next steps. It is urgent enough that we will probably have to choose a pragmatic "interim" next step that might fall short of a "theoretical best" (though some believe that the next change to the Internet will have to be the last). However, I believe that it is *not* yet clear that "adopting CLNP" - whatever that actually means, is the best choice. It might actually be completely irrelevant. I would hope that the undoubted discussion at next week's IETF will generate more light than heat. (After all, our Internet community prides itself in that doesn't it? That's why we are more successful than others, isn't it?). Only coming OUT of the IETF can we hope to make a decision on this. While it would be nice to be able to take a recommendation in, I don't believe we should. "If you can keep your head when all about are losing their's..." Kipling. Sorry for the long message. Denis. PS Wish I was going to the IETF - sounds like it will be very interesting. :-( Denis Russell email: Denis.Russell(a)Ncl.AC.UK Computing Service Tel: (+44) 91 222 8243 The University Fax: (+44) 91 222 8232 Claremont Road Telex: 53 65 4 UNINEW G Newcastle upon Tyne NE1 7RU ENGLAND

1 0