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

RIPE20 - DRAFT AGENDA
by RIPE NCC Staff 12 Jan '95

12 Jan '95

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

1 0

Re: A Small Announcement
by Mike Norris 06 Jan '95

06 Jan '95

>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

1 0

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

04 Jan '95

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

1 0

REMINDER RIPE Meeting -- REMINDER RIPE Meeting -- REMINDER RIPE Meeting
by RIPE NCC Staff 04 Jan '95

04 Jan '95

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(a)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. ---------------------------------------------------------------------

1 0

Self Assignments
by Daniel Karrenberg 03 Jan '95

03 Jan '95

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

1 0

Comments on " Guidance in the Assignment of Internet Numbers"
by Daniel Karrenberg 03 Jan '95

03 Jan '95

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

3 3

More draft-iab-assignment-guidance-00.txt
by Daniel Karrenberg 03 Jan '95

03 Jan '95

------- Forwarded Message Date: Tue, 03 Jan 1995 19:50:42 +0900 From: David Conrad <davidc(a)keio.jp.apnic.net> To: iab(a)isi.edu cc: apnic-staff(a)apnic.net, apnic-wg(a)nic.ad.jp, iepg(a)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 <Daniel.Karrenberg(a)ripe.net> Sender: dfk(a)ripe.net To: David Conrad <davidc(a)keio.jp.apnic.net> Cc: iab(a)isi.edu, apnic-staff(a)apnic.net, apnic-wg(a)nic.ad.jp, iepg(a)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(a)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

1 0

Re: Comments on " Guidance in the Assignment of Internet Numbers"
by Daniel Karrenberg 03 Jan '95

03 Jan '95

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

1 0