From Daniel.Karrenberg at ripe.net Tue Jan 3 10:17:45 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 03 Jan 1995 10:17:45 +0100 Subject: Comments on " Guidance in the Assignment of Internet Numbers" Message-ID: <9501030917.AA22721@ncc.ripe.net> Dear colleagues serving as targets (e.g. IAB), a happy, successful and healthy new year to you all! A few comments on "Guidance in the Assignment of Internet Numbers" from a practitioner follow. First of all let me read back to you what I think you want to say: "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." I will work from the assumption that this is true. If there is any other specific and inportant point that you want to make I would be interested to hear it. Unfortunately in saying this more verbosely, you say some things that will make the registries' life in delegating and assigning address space efficiently and CIDRised more difficult than necessary. I would like you to realise this. It might be wise to reduce the number of words to something closer to the above. Detailed comments: > Abstract > > The IAB suggest that while RFC 1597 establishes reserved IP address > space for the use of private networks which are isolated and will > remain isolated from the Internet, any enterprise which anticipates > external connectivity to the Internet should apply for a globally > unique address from an Internet registry, or a service provider. This should read: ".... isolated from the Internet, any enterprise should obtain globally unique addresses for all those hosts which are anticipated to have direct network layer connectivity external to the enterprise." I also do not like the distinction between "Internet registry" and "service provider". We prefer to talk about Internet registries only. The RIPE NCC is a Regional Registry whereas service providers can become Local Registries if they wish. (Ceterum censeo: The InterNIC RS in my view is just another Regional Registry which also happens to do some administrative things for IANA. Regional Registries operate under the authority of IANA and not the InterNIC's.) > Regional Registries have agreed to comply with the guidelines > established by RFC 1466 and therefore, if an organization meets the > size requirement for the requested address(es) and submits an > engineering plan, the organization has fulfilled the necessary > requirments. The Regional Registry will make the allocation based on typo > the established criteria. Do you really want to say that the following qualifies for 512Cs: "Hi, I represent DFK MegaNetwork Ltd. etc. pp. We are going to implement an enterprise network with 508 subnetworks which we have conveniently divided among our 50 sites in 10 countries as follows: country a 0-99 site aa 0-9 site ab 10-19 site ac 20-29 ... country b 100-199 site ba 100-109 ... ... test lab 500-507 Each network has 0 hosts now and will have 20 hosts operational on it on average within 1 month from now. We are buying all those hosts at the moment. Some of the subnets will have close to 200 hosts on it. For technical reasons we cannot use VLSMs or subnetting. We need public address space because all of the hosts might have external connectivity in the future. We are starting implementation in 10 days and would appreciate an assignment of 512 class C network numbers before then. Kind Regards S.T. and A.R.D. Text Consultants" I would at least say that "... submits an engineering plan documenting reasonable attention to conservation of address space and a realistic deployment schedule." Also what is missing is that use of currently assigned address space should be documented. Otherwise they can do this twice a year. What this really shows is that RFC1466 needs a rework. I am still prepared to lay the groundwork to this, but it should be done by IANA and all Regional Registries *together*. > The preconditions defined in RFC 1466 are limited to number of hosts > and subnets as well as an engineering plan if the request deviates > from the standard criteria. There is no requirment that an applicant > must have selected a network service provider prior to applying for > an IP address. The lack of being the customer of a network service > provider is insufficient reason for a Regional Registry to deny an > applicant's request for an IP address. The Internet registries must > honor an enterprise's request for a globally unique IP address > provided that the request meets the other conditions used to > deterimine the appropriate size of address block to allocate. That is fine with me. As an undertone I hear an implication that this has happened. This is not good to leave in. Is the RIPE NCC accused of this? Of course there may be a charge associated with processing the request. The way I see it going in Europe is that free assignment of address space will rapidly go away. You will have to pay for the service. The standard way will be thru a Local Registry. These usually are service providers. They will have a choice to offer address space assignment service without IP serice associated with it. The NCC (Regional Registry) will also offer this service at a high cost to set a ceiling price and to prevent is from being innundated with small transactions. This is my personal vision. Consensus building is in progress. > RFC 1597 establishes reserved IP address space for the use of private > networks which are isolated and will remain isolated from the > Internet. Any enterprise which anticipates external connectivity to > the Internet should apply for a globally unique address from an > Internet registry, or a service provider. See above (language about expected network layer connectivity). > RFC 1597 documents a way that private enterprises may assure that > their networks will remain segregated from the Internet. The > addresess designated in RFC 1597 will not be routed by the Internet. > > The IP addresses of RFC 1597 are not meant to be used as temporary > addresses for enterprises which plan to connect to the Internet at a > later date when the enterprises have selected network service > providers. See above (language about expected network layer connectivity). > If an enterprise desires a unique IP address, the > registries are instructed to assign such an address without > conditions with regard to service provider selection. > > Any organization which anticipates having external connectivity is > encouraged to apply for a globally unique IP address. Whereas the See above (language about expected network layer connectivity). > globally unique address is insufficient to guarantee global > connectivity, globally unique addresses are necessary to > differentiate between destinations on the Internet. (Un)fortunately in a few hours I am leaving for two weeks of vacation to a place without telephone service. There is no Internet either in the whole country which is not large enough to appear on Larry's maps. It would be coloured green if it was. I am glad such places do still exist. ;-) I would apreciate if the draft was updated in the direction of my comments. I would certainly be disturbed if the RFC was published before February and the next RIPE meeting. Daniel From Christian.Huitema at sophia.inria.fr Tue Jan 3 10:39:18 1995 From: Christian.Huitema at sophia.inria.fr (Christian Huitema) Date: Tue, 03 Jan 1995 10:39:18 +0100 Subject: Comments on " Guidance in the Assignment of Internet Numbers" In-Reply-To: Your message of "Tue, 03 Jan 1995 10:17:45 +0100." <9501030917.AA22721@ncc.ripe.net> Message-ID: <199501030939.AA15228@mitsou.inria.fr> Daniel, Thanks for your detailed comments. I believe that we agree on the two goals of developping connectedness and using the address space reasonably. It may well be that the IAB praise connectedness above all, while down in the trenches you have fight off a number of unreasonable demands. There is one phrase in the example you give which rings a lot of alarm bells. "For technical reasons we cannot use VLSMs or subnetting." This is just unacceptable; the goal of connectedness cannot be achieved without supporting CIDR, i.e. both subnetting and supernetting. The reference to RFC 1466 in the draft already imply this technical requirement; it may be a good idea to explicitly restate it. Christian Huitema From Daniel.Karrenberg at ripe.net Tue Jan 3 10:42:03 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 03 Jan 1995 10:42:03 +0100 Subject: Comments on " Guidance in the Assignment of Internet Numbers" In-Reply-To: Your message of Tue, 03 Jan 1995 10:17:45 MET. Message-ID: <9501030942.AA22954@ncc.ripe.net> It has been suggested to me to add for the record: While European Internet Registries routinely advise requestors that private address space (RFC1597) exists, it is our policy to assign globally unique address space as soon as the requestor states that - they know about private address space and - that it is unsuitable for their needs. A simple statement suffices, but we want both documented. Of course we also point out to those requestors with large requests based on administrative convenience that they will have to make a trade off: Private addres space gives them a lot of room to play with no global network layer connectivity. Public address space gives them the possibility of global connectivity at the expense of having to be more efficient in address space usage. The important point is that the first time they say "we know, we need public space" they get what the request merits according to the assignment criteria. Daniel From davidc at keio.jp.apnic.net Tue Jan 3 12:12:44 1995 From: davidc at keio.jp.apnic.net (David Conrad) Date: Tue, 03 Jan 1995 20:12:44 +0900 Subject: Comments on " Guidance in the Assignment of Internet Numbers" In-Reply-To: Your message of "Tue, 03 Jan 1995 10:39:18 +0100." <199501030939.AA15228@mitsou.inria.fr> Message-ID: <199501031112.UAA02987@keio.jp.apnic.net> Christian, >Thanks for your detailed comments. I believe that we agree on the two >goals of developping connectedness and using the address space >reasonably. It may well be that the IAB praise connectedness above >all, while down in the trenches you have fight off a number of >unreasonable demands. In my opinion, it is not so much unreasonable demands, although APNIC receives many requests that would definitely fall within any definition of unreasonable, as the criteria which the registries must operate are very ill-defined and do not reflect the circumstances of today's Internet. Further, there appears to be at least two minds when it comes to the issues of conserving address space and CIDRization. I feel that the registries, being heavily involved with the group that is interested in conservation and aggregation, have become significantly more concerned with the reducing address space wastage and encouraging CIDR than the draft statement would indicate the IAB feels is appropriate. >There is one phrase in the example you give which rings a lot of >alarm bells. "For technical reasons we cannot use VLSMs or >subnetting." This is just unacceptable; the goal of connectedness >cannot be achieved without supporting CIDR, i.e. both subnetting and >supernetting. Are you stating that it is acceptable for registries to decline to allocate space if an organization does not implement VLSMs? >The reference to RFC 1466 in the draft already imply this technical >requirement; Does it? Or are you indicating you feel RFC 1466 implies this technical requirement? >it may be a good idea to explicitly restate it. I feel that it would be in the best interests of the entire Internet if many of the assumed policies, some of which are hinted at within the draft statement, are made explicit. The registries are in the unenviable position of playing judge and jury for most assignments and this role is performed with varying degrees of rigor globally. It would seem clear to me that at the very least, RFC 1466 should be revised before this draft statement is made into an RFC. Regards, -drc From Daniel.Karrenberg at ripe.net Tue Jan 3 13:22:44 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 03 Jan 1995 13:22:44 +0100 Subject: More draft-iab-assignment-guidance-00.txt Message-ID: <9501031222.AA24267@ncc.ripe.net> ------- Forwarded Message Date: Tue, 03 Jan 1995 19:50:42 +0900 From: David Conrad To: iab at isi.edu cc: apnic-staff at apnic.net, apnic-wg at nic.ad.jp, iepg at iepg.org Subject: draft-iab-assignment-guidance-00.txt Hi, I have a few questions regarding the recently submitted draft 'draft-iab-assignment-guidance-00.txt'. I have included relevant text above the specific questions, so the context can be understood. I apologize in advance for the length of this message as I know you all are very busy people, but this document may have *very* significant impact on the operation of APNIC and I feel it is important to fully understand the intent. >From draft-iab-assignment-guidance-00.txt: ... With the advent of RFC 1466 and RFC 1597 the criteria for the allocation of unique IP numbers and the reservation of unique IP numbers have been defined. ... Q1) Does the IAB feel RFC 1466 completely defines the criteria under which the registries may allocate space? Q2) Does the IAB feel the criteria in RFC 1466 addresses the issues of accurate host and subnet estimates for service providers? ... if an organization meets the size requirement for the requested address(es) and submits an engineering plan, the organization has fulfilled the necessary requirments. The Regional Registry will make the allocation based on the established criteria. The preconditions defined in RFC 1466 are limited to number of hosts and subnets as well as an engineering plan if the request deviates from the standard criteria. ... Q3) Would it be possible for the IAB to explicitly define their view of "engineering plan" within the context of this document? Q4) I would note that there appears to be a contradiction here with respect to the need for engineering plans, the first paragraph implies the requirement regardless of conformance to the 1466 criteria, the second paragraph implies the requirement only if the criteria are violated. In the view of the IAB, which of these two alternatives is the correct one? ... The Internet registries must honor an enterprise's request for a globally unique IP address provided that the request meets the other conditions used to deterimine the appropriate size of address block to allocate. ... Q5) Is it the intent of the IAB to disallow registries from obtaining additional information which attempt to verify the validity of the 24 month host and subnet estimates, even if the request falls within the RFC 1466 criteria? Q6) Is it the intent of the IAB to disallow registries from recovering reasonable costs for the allocation of address space and the operation of the registry as a pre-requisite for obtaining the address space? ... Any organization which anticipates having external connectivity is encouraged to apply for a globally unique IP address. ... Q7) Can the IAB express their views on the impact of the policies defined in the draft statement on the conservation of address space, or does the IAB feel conservation of address space is not a significant concern due to the impending implementation of IPv6? Q8) 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? Thank you for your time and best wishes for the New Year. Regards, - -drc ------- End of Forwarded Message ------- Date: Tue, 03 Jan 1995 13:21:44 +0100 From: Daniel Karrenberg Sender: dfk at ripe.net To: David Conrad Cc: iab at isi.edu, apnic-staff at apnic.net, apnic-wg at nic.ad.jp, iepg at iepg.org Subject: Re: draft-iab-assignment-guidance-00.txt In-Reply-To: Your message of Tue, 03 Jan 1995 19:50:42 +0900. <199501031050.TAA02928 at keio.jp.apnic.net> ------- The questions David raises are quite to the point and highlight the fact that patching things by way of an additional RFC here and there will not work and rather make things worse because there inevitably will be contradictions and possible misinterpretations. On the other hand totally "hard-coded" assignemnt criteria are not useful either. There must be some room for judgement on the part of the registries. The conclusion has to be that if the IAB wants to direct address space assignment they have to come up with a revised RFC1466 with input from IANA, the registries (and that includes registries operated by ISPs) as well as the community at large. As I have indicated in the past, the RIPE NCC is quite willing to contribute to that effort. on behalf of the RIPE community, I would be very disappointed if the IAB decides to go ahead with publishing the draft as is. I will forward detailed comments I have made to the IAB to the IEPG separately. Regards Daniel Karrenberg Manager RIPE NCC From Daniel.Karrenberg at ripe.net Tue Jan 3 13:51:52 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 03 Jan 1995 13:51:52 +0100 Subject: Comments on " Guidance in the Assignment of Internet Numbers" In-Reply-To: Your message of Tue, 03 Jan 1995 10:39:18 MET. <199501030939.AA15228@mitsou.inria.fr> Message-ID: <9501031251.AA24528@ncc.ripe.net> > Christian Huitema writes: > > There is one phrase in the example you give which rings a lot of alarm > bells. "For technical reasons we cannot use VLSMs or subnetting." This > is just unacceptable; the goal of connectedness cannot be achieved > without supporting CIDR, i.e. both subnetting and supernetting. The > reference to RFC 1466 in the draft already imply this technical > requirement; it may be a good idea to explicitly restate it. 1) If you read RFC1466 section 4.3 it can be (and freuqntly is) read to say the opposite. The draft can be read to say that just sending any odd engineering plan is sufficient. 2) To me it is more alarming that obviously in this case someone has made a nice, administratively convenient (note the powers of 10) addressing plan with a lot of room for growth. It is probably also more the product of planning (imagination) than reality. We receive a lot of those. While we do not have an executive arm to go investigate whether the plans are real, we can at least ask them for a deployment plan and then give them the address space they really need for two years realistically expected growth. Do you want us to continue doing that? If yes, give us the policy to be able to do it. If no, our assignment rate will increase by at least an order of magnitude. Ceterum censeo: RFC1466 esse rescribendam! Daniel From Daniel.Karrenberg at ripe.net Tue Jan 3 14:16:47 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 03 Jan 1995 14:16:47 +0100 Subject: Self Assignments Message-ID: <9501031316.AA24796@ncc.ripe.net> Because of several recent delevopments I would like to remind local registries that they should be careful when assigning address space to themselves, i.e. their own company or subsidiaries. You should be 200% sure that you make these assignments according to the current guidelines and that you do not give yourself more favourable terms than you would have given another organisation. It should also go without saying that you should file the documentation required and be able to produce it on request. If you have any doubt, the NCC will be happy to review your assignments. In fact I am proposing to the local-IR WG to make review by the NCC mandatory for self assignments. Daniel From ncc at ripe.net Wed Jan 4 12:14:03 1995 From: ncc at ripe.net (RIPE NCC Staff) Date: Wed, 04 Jan 1995 12:14:03 +0100 Subject: REMINDER RIPE Meeting -- REMINDER RIPE Meeting -- REMINDER RIPE Meeting Message-ID: <9501041114.AA01758@ncc.ripe.net> Dear Attendees, If you are planning to attend the coming RIPE meeting, please help us by registering for the meeting as soon as possible. This really helps in planning enough food, coffee and seats for everyone ie. if you want food register NOW :-) Below is a revised announcement for the meeting with pointers to all the information you need (which is in the document store), including information about hotels and the new public transport timetables. We plan to announce a draft agenda 2 weeks prior to the meeting. There will be a separate announcement next week about the RIPE Meeting Evening Dinner which will be held on Thursday 26th January. Kind regards, David Kessens RIPE NCC -------------------------------------------------------------------------- R I P E meeting announcement (reminder) ======================================= (This announcement can also be viewed using "finger meeting at ncc.ripe.net") This is to announce that the 20th RIPE meeting will take place: Dates: 25th January, 1995 begin: 09:00 26th January, 1995 27th January, 1995 end: 16:00 NOTE: as decided at the 19th RIPE meeting, a new format of the meeting schedule will be in place. This means that the Working Group and special interest group sessions will be scheduled for January 25 (full day) and January 26 (09:00-12:30). The plenary RIPE meeting will take place January 26 (14:00-18:00) and January 27 (09:00-16:00). Venue: CWI Kruislaan 413 1098 SJ Amsterdam The Netherlands Host: NIKHEF Registration: Please use the registration form to give notice of your coming as soon as possible. The Registration form can be obtained from : ftp://ftp.ripe.net/ripe/Next-Meeting/ripe20.registration Agenda: The draft agenda will be published 2 weeks before the meeting starts. It will be available at : ftp://ftp.ripe.net/ripe/Next-Meeting/ripe20.draft.agenda General Information: -------------------- Currency information (941214): 1 UK pound = Hfl 2.76 1 ECU = Hfl 2.14 1 US$ = Hfl 1.76 Details of hotels in Amsterdam close to meeting venue can be obtained from : ftp://ftp.ripe.net/ripe/Next-Meeting/ripe20.hotels Directions to the meeting place - How do I get there : ftp://ftp.ripe.net/ripe/Next-Meeting/ripe20.transport (This file is also appended to this document since it changed a lot) I recommend you also to take a look in the README and CHANGES file. The README file contains a short description about the files available in the ftp directory, the CHANGES file contains information about updates of the general information regarding the meeting : ftp://ftp.ripe.net/ripe/Next-Meeting/README ftp://ftp.ripe.net/ripe/Next-Meeting/CHANGES ================================================================== CWI/NIKHEF - The RIPE meeting venue: How do I get there? ----------------------------------------------------------------------- To ease any possible confusion, two postscript maps can be found in the RIPE document store. One shows the bus and tram stops around the meeting site and the other is a more general map of the area. Both maps are available at: ftp://ftp.ripe.net/ripe/Next-Meeting/area-map.ps ftp://ftp.ripe.net/ripe/Next-Meeting/area-map.ps.Z ftp://ftp.ripe.net/ripe/Next-Meeting/local.transport-map.ps ftp://ftp.ripe.net/ripe/Next-Meeting/local.transport-map.ps.Z From Amsterdam airport (Schiphol): o Take the train from the airport railway station to the Central Railway station. From the Central Railway station: o Take tramway number 9 till the stop at the corner of Middenweg and Kruislaan (15 min ride) o Walk down the Kruislaan in the direction of the railway bridge. Cross under the bridge and continue. Take the 2nd entrance left and proceed to the entrance marked NIKHEF-H. (15 min walk all together). or o Take bus 22 in the direction 'Indische Buurt' to the stop at the 'Muiderpoort Station' and take bus 66. From the RAI Railway station: o From the RAI station take the city bus number 69 or CN bus number 169 in the direction `Amstel Station'. From the Amstel Railway station: o From the Amstel station take the city bus number 15 the direction `Muiderpoort Station' to the stop on the corner of Kruislaan and Linnaeusparkweg (15 min ride, ask the driver where to get of) or proceed to 'Muiderpoort Station' and take bus 66. o Walk down the Kruislaan in the direction of the railway bridge as described above. From the Muiderpoort Railway station: o Take bus 66. Taxi from the airport: o 15 min ride o fl. 50 appr. Other connections to and from the NIKHEF site: tram 6 from Leidseplein tram 10 to Leidseplein tram 14 to and from Dam Square bus 66 to and from Muiderpoortstation Timetable bus 66 >From Muiderpoortstation (Monday - Friday): 7.20 7.40 8.00 8.20 8.40 9.00 9.20 9.40 10.10 10.40 11.10 11.40 12.21 12.51 13.21 13.51 14.21 14.51 15.21 15.51 16.11 16.31 16.51 17.11 17.31 17.51 18.11 >From NIKHEF to Muiderpoortstation (Monday - Friday): 7.28 7.48 8.08 8.28 8.48 9.08 9.28 9.48 10.18 10.48 11.18 11.48 12.28 12.58 13.28 13.58 14.28 14.58 15.28 15.58 16.18 16.38 16.58 17.18 17.38 17.58 18.18 ===================================================================== Public Transport - how much does it cost and where can I get tickets? --------------------------------------------------------------------- Tickets of 15 strips (trippenkaart' costing Hfl. 11,-) can be bought in Post Offices, railway stations and cigarette shops. Tickets of 2 and 3 strips can be bought on the bus or the tram but they are much more expensive. You have to validate the ticket yourself in the metro stations and in the trams (except on lines 4, 6, 7, 10, 12 and 13). In the buses the driver will validate the ticket. Amsterdam is divided into zones: the old city is in zone entrum' whereas CWI is in zone st'. You need to count how many zones you will be travelling through (from the centre - CWI is 2 zones) and count up that number of strips on your ticket + 1 extra. So in the above example you will need to stamp the 3rd strip. In case of overflow you stamp the last strip of the first ticket and start counting the remaining strips on the next ticket. Confused? Ask any member of the local organizing committee. Warning: BEWARE of pickpockets in crowded places. --------------------------------------------------------------------- From mnorris at dalkey.hea.ie Wed Jan 4 17:26:03 1995 From: mnorris at dalkey.hea.ie (Mike Norris) Date: Wed, 4 Jan 1995 16:26:03 GMT Subject: Draft agenda for mtg at RIPE 20 Message-ID: <9501041626.AA25142@dalkey.hea.ie> Please see the following draft agenda for the meeting of the Local IR WG meeting at RIPE 20. Many of the items and sub-items are suggestions from Daniel Karrenberg, who hopes to have supporting documentation ready by 20th January. He has also asked Rob Blokzijl, RIPE chairman, to reserve a slot on Thursday morning, additional to the slot on Wednesday afternoon, should we wish to avail of it. I reckon we're going to need both time slots, together with the intervening reflective period, to process quite a large agenda. Comments and ideas are very welcome. Cheers. Mike 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 - European regional registry (NCC) - 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. AOB From mnorris at dalkey.hea.ie Fri Jan 6 17:07:30 1995 From: mnorris at dalkey.hea.ie (Mike Norris) Date: Fri, 06 Jan 95 16:07:30 +0000 Subject: A Small Announcement In-Reply-To: Your message of "Thu, 05 Jan 95 17:08:32 GMT." <9501051708.AA02559@felix.ukerna.ac.uk> Message-ID: <9501061607.AA28709@dalkey.hea.ie> >Which leads me of course to the most vital matter. I really ought to >have negotiated my proposal properly in advance, but I can't remember >the name of the UK Prime Minister, and I can't spell the name of the >equivalent post in Eire. Anyway, in the spirit of the current UK-Irish >cooperation (sometimes known (wrongly in my view) as Anglo-Irish >cooperation), I propose that: > > (i) I (on behalf of the UK, and hoping for support from Demon, EUnet >GB, PIPEX and others) submit a limerick to mark the occasion of Tony's >move; > (ii) Mike Norris (on behalf of Eire, and with support from Irish >Operators everywhere) give the Limericks WG Report at the next meeting. As a possible stand-in for Tony, I'm flattered by Phil, except only I can't do the stint, lest A conflict of interests Once and for all proves I'm phoney. Mike From ncc at ripe.net Thu Jan 12 16:10:08 1995 From: ncc at ripe.net (RIPE NCC Staff) Date: Thu, 12 Jan 1995 16:10:08 +0100 Subject: RIPE20 - DRAFT AGENDA Message-ID: <9501121510.AA06940@ncc.ripe.net> 20th RIPE Meeting Amsterdam, 25-28 January 1995 Preliminary Agenda ------------------ Dear Colleagues, Below you will find a first shot at the agenda for the 20th RIPE meeting. As always, it is a proposed agenda: please let me know of any changes and/or additions you might want to propose. In view of the fact that quite a few people that have registered so far will be attending their first RIPE meeting ever, I have introduced a new phenomena: "An Introduction to RIPE" This session will take place on the Wednesday morning from 10:00h till 12:00h. The aim is to introduce RIPE, the RIPE NCC, their working formats and relationships, etc. It is strongly recommended that first timers do participate in this session. Of course, old hands are equally welcome ;-) A first try at scheduling the working group sessions will be distributed as a seperate mail. Last, but not least, a traditional RIPE dinner will be organised on Thursday evening. Again, this will be seperately announced. See you all in Amsterdam, Rob Blokzijl 20th RIPE Meeting Amsterdam, 25-28 January 1995 Preliminary Agenda ------------------ o Opening and Welcome o Adoption of the Agenda o Minutes of the 19th RIPE Meeting o Outstanding Action Items o RIPE NCC Report o RIPE NCC Finances o PRIDE: Final Report o INTERNIC Report o TERENA Introduction o IETF Report o IPv6 o Working Group Reports o Next Meetings o AOB o Closing From mnorris at dalkey.hea.ie Thu Jan 12 16:53:29 1995 From: mnorris at dalkey.hea.ie (Mike Norris) Date: Thu, 12 Jan 1995 15:53:29 GMT Subject: Draft agenda for mtg at RIPE 20 Message-ID: <9501121553.AA08022@dalkey.hea.ie> 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 From hostmaster at ripe.net Thu Jan 12 18:17:07 1995 From: hostmaster at ripe.net (RIPE NCC Hostmaster) Date: Thu, 12 Jan 1995 18:17:07 +0100 Subject: IMPORTANT NOTICE Message-ID: <9501121717.AA00189@ncc.ripe.net> 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 From poole at eunet.ch Thu Jan 12 18:57:33 1995 From: poole at eunet.ch (Simon Poole) Date: Thu, 12 Jan 1995 18:57:33 +0100 (MET) Subject: IMPORTANT NOTICE In-Reply-To: <9501121717.AA00189@ncc.ripe.net> from "RIPE NCC Hostmaster" at Jan 12, 95 06:17:07 pm Message-ID: <199501121757.SAA08750@chsun.eunet.ch> > > > 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. > We were just going to ask too, they want an incrediable amount of address space here too. Simon From dinner at ripe.net Fri Jan 13 11:15:16 1995 From: dinner at ripe.net (RIPE NCC Staff) Date: Fri, 13 Jan 1995 11:15:16 +0100 Subject: ANNOUNCEMENT: Dinner 20th RIPE Meeting Message-ID: <9501131015.AA04982@ncc.ripe.net> * 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 at 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 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 From ncc at ripe.net Fri Jan 13 14:38:59 1995 From: ncc at ripe.net (RIPE NCC Staff) Date: Fri, 13 Jan 1995 14:38:59 +0100 Subject: RIPE20: Draft meeting schedule Message-ID: <9501131339.AA06610@ncc.ripe.net> 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 From ncc at ripe.net Mon Jan 16 16:58:34 1995 From: ncc at ripe.net (RIPE NCC Staff) Date: Mon, 16 Jan 1995 16:58:34 +0100 Subject: Invitation to join the RIPE CDS Message-ID: <9501161558.AA27861@ncc.ripe.net> 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 . With my best regards Milan Sterba Convenor of the RIPE connectivity WG From Stephan.Biesbroeck at belnet.be Mon Jan 16 17:22:48 1995 From: Stephan.Biesbroeck at belnet.be (Stephan.Biesbroeck at belnet.be) Date: Mon, 16 Jan 1995 17:22:48 +0100 (MET) Subject: Invitation to join the RIPE CDS In-Reply-To: <9501161558.AA27861@ncc.ripe.net> from "RIPE NCC Staff" at Jan 16, 95 04:58:34 pm Message-ID: <9501161622.AA04029@mahler.belnet.be> RIPE NCC Staff wrote : > http://www.ripe.net/cds.html For those that want to try this : I think the correct URL is http://www.ripe.net/ripe/cds.html > You are willcome to send questions, CDS factsheets or HTML pointers to > . > With my best regards > Milan Sterba > Convenor of the RIPE connectivity WG > -- Stephan Biesbroeck Tel: +32(0)2-2383470 stephan at belnet.be Fax: +32(0)2-2311531 Service Support Team of the Belgian National Research Network, BELNET From ncc at ripe.net Fri Jan 20 13:53:28 1995 From: ncc at ripe.net (RIPE NCC Staff) Date: Fri, 20 Jan 1995 13:53:28 +0100 Subject: RIPE20 : Terminal room facilities Message-ID: <9501201253.AA04005@ncc.ripe.net> 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 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 From ncc at ripe.net Fri Jan 20 13:56:37 1995 From: ncc at ripe.net (RIPE NCC Staff) Date: Fri, 20 Jan 1995 13:56:37 +0100 Subject: RIPE meeting special request Message-ID: <9501201256.AA04058@ncc.ripe.net> 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 From woeber at cc.univie.ac.at Tue Jan 24 15:42:00 1995 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 24 Jan 1995 15:42:00 MET Subject: Address allocation, local procedures for review Message-ID: <0098AF29.7DE70AD8.4@cc.univie.ac.at> 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 at 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 -------------------------------------------------------------------------- From iab at ISI.EDU Thu Jan 26 01:14:26 1995 From: iab at ISI.EDU (The Internet Architecture Board) Date: Thu, 26 Jan 1995 11:14:26 +1100 Subject: A response to your comments Message-ID: <1302.791079266@munnari.OZ.AU> 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. From GeertJan.deGroot at ripe.net Mon Jan 30 18:24:26 1995 From: GeertJan.deGroot at ripe.net (Geert Jan de Groot) Date: Mon, 30 Jan 1995 18:24:26 +0100 Subject: finger for 'handle' In-Reply-To: Your message of "Mon, 30 Jan 1995 14:47:12 MET." <199501301342.OAA23688@nic.tip.net> Message-ID: <9501301724.AA12241@ncc.ripe.net> 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 at 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 at whois.ripe.net > (as suggested at the RIPE meeting) > ... using the finger client included in SUNOS 4.1.3.