From training at ripe.net Thu Apr 4 16:40:48 1996 From: training at ripe.net (RIPE NCC Training) Date: Thu, 04 Apr 1996 16:40:48 +0200 Subject: Local IR Workshop Message-ID: <9604041440.AA08036@ncc.ripe.net> Dear Local IR's, At the last RIPE Meeting in Amsterdam it was decided to have a Local Internet Registries workshop again in addition to the normal Local IR WG Meeting. The purpose of this workshop is to discuss operational procedures and experiences among LIRs as well as between LIRs and the NCC. The workshop will not be minuted and details about experiences discussed will be kept in strict confidence. The workshop is *not* intended for formal discussions and decisions about procedures as these things are done by the Local-IR working group. This workshop will be organised in conjunction with the 24. RIPE Meeting in Berlin. It will be held on Monday, 24th of April approximately from 9am til 12 am. The workshop is open exlusively for Local IR staff. To have a useful and interactive workshop the attendance is limited to 40 people. In case the workshop is oversubscribed we will limit attendance to one attendee per LIR on a "first-come-first-served" basis. Therefor we advise you to reply asap if you are interested to attend this workshop. We will send out (electronic) tickets to registrants. Only people with ticket will be admitted to the workshop. Preliminary Agenda: - ripe-104++ - how to adopt policy changes in daily operations - reverse delegation - tools - war stories Details of the exact venue and schedule will be distributed later to the registrants. If you have further questions, please don't hesitate to ask. Kind Regards, Mirjam Kuehne Manager NCC Registration Services =========================================================================== Our handling of ALL meeting registrations is fully automated. To register for the workshop, please complete the registration form and send it to . PLEASE FILL THIS OUT AS SPECIFIED. Please add in a value in the `box' area marked between the square brackets (i.e. "[" and "]" s). Note this is what will be used for your badge if you have requested one and for the attendee list so please take care to fill it in correctly. You will receive a notification message that your request has been processe d. If however, you have any questions about the meeting or your registration form, please send your completed form to . %START PART 1 - Registration 1) Your name Enter First name, Last name in FULL (remember this is on list and badge) e.g. John Doe Mary-Beth Walton %NAME [ ] 3) Your Organisation/Institution %ORG [ ] 4) Your e-mail address %EMAIL [ ] 5) Country code of organisation e.g. IT FR DE %CTRY [ ] %END From ncc at ripe.net Tue Apr 9 16:59:43 1996 From: ncc at ripe.net (RIPE NCC) Date: Tue, 09 Apr 1996 16:59:43 +0200 Subject: RIPE23: Draft Minutes available: ripe-m-23 Message-ID: <9604091459.AA20254@ncc.ripe.net> RIPE Minutes Announcement ------------------------- The RIPE23 minutes are now available from the RIPE document store : -------------- next part -------------- FTP Access ---------- All RIPE minutes (and more) are available via anonymous FTP from host ftp.ripe.net. Type "ftp ftp.ripe.net". Login with username "anonymous" supplying your email address as the password. After logging in, type "cd ripe/minutes/" followed by the command "get filename". The relevant filenames for this document are: ripe-m-23.txt for the ASCII version ripe-m-23.ps for the PostScript version Electronic Mail Retrieval of Documents -------------------------------------- Documents can also be retrieved from the RIPE document store using a mail server program. For more information on how to use the program, send email to: mail-server at ripe.net with "send HELP" in the body text. RIPE NCC Interactive Information Server --------------------------------------- Type "telnet info.ripe.net". This is a menu driven service allows the document store to be browsed. After reading documents you are prompted as to whether you would like to receive an email copy of the document you have just read. If you would, you simply enter your email address and the document will be mailed to you. Below are details of alternative methods of access. Gopher Access ------------- The same documents are available via a "gopher" server at "gopher gopher.ripe.net". WWW Access ---------- For those who wish to add this home page at the RIPE NCC to their own customized home pages, it can be accessed as: http://www.ripe.net MIME Mail Reader ---------------- Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the RIPE document by FTP or mail server. -------------- next part -------------- SEND ripe/minutes/ripe-m-23.txt From training at ripe.net Wed Apr 10 17:27:35 1996 From: training at ripe.net (RIPE NCC Training) Date: Wed, 10 Apr 1996 17:27:35 +0200 Subject: Announcement for Local IR Training Course in Budapest Message-ID: <9604101527.AA06874@ncc.ripe.net> * * * Announcement * * * Local Internet Registries Training Course Date: Friday 10th May, 1996 Time: 0900 - 1700 Venue: Budapest, Hungary (Further details about the location will be announced at a later time). -------------- next part -------------- Course Audience --------------- The target audience for this course is personnel of European Local Internet Registries that contribute to the RIPE NCC. Material Covered ---------------- The course is a one day introduction on Internet name, address and routing policy registration procedures in Europe. It also teaches how to query and use the information registered for operational purposes. This includes the following material and activities: o Overview of name, address and routing registration procedures. o Responsibilities of both RIPE NCC and Local IR's to each other. o Wider context of the Delegated Registry system and relevant issues (IPv4 address depletion, CIDR) and how this relates to IP requests. o How to use the RIPE NCC Database. o Use of AS numbers, Routing Registry concepts and an introduction to using PRIDE tools. o DNS feedback on commor errors, how to request delegations, and pointers to useful tools. We again stress that this course will *not* teach Local Registries on how to run their business as Internet Service Providers. It is clearly focussed on registration procedures and the interaction between the RIPE NCC and local IR's. A detailed outline is appended below. The course itself will include lunch and will be free. This of course does not include your travel and subsitence ;-). How to Register --------------- Please send an RSVP to if you would like to attend the course. If you have previously approached us about attending this course, we ask you to confirm that you (or a colleague) will be attending. Registrations will be accepted on a first come, first served basis. If the course is oversubscribed, we will give priority to local IRs who have most recently paid the signup fee. If it is still oversubscribed, we will accept only one person per new local registry. We will provide additional course dates as necessary. If a number of local registries so request, we will present courses at other European locations. If you would like a local course or have any questions or suggestions, please do not hesitate to contact us. The RIPE NCC Training Team: Mirjam Kuehne, Carol Orange --- Course Outline -------------- We will provide a slidebook and a reader on the day of the course, as well as electronically. It is planned to make detailed documentation available in the form of a guide much like the PRIDE guide. The program will divide the actual content into the following sections: 1. Introduction For those unfamiliar with the Delegated Internet Registry system and the RIPE NCC, this section will give a historical overview of how we have arrived at today's model of operation and why training of local IR's is a much needed activity. 2. IP Registry procedures This section will clarify the procedures between the RIPE NCC and local IR's with respect to requests for IP address space. It will take a step by step approach on how to complete documentation, the kind of information that is required, what the "handholding" procedure is, how to deal with very large requests, and very small requests, and more generally what criteria the RIPE NCC and local IR's use for their customers in the context of CIDR and IPv4 address depletion. 3. RIPE NCC Database This section will explain what the RIPE NCC Database is and how it fits into the scheme of other registry databases. It will cover how to create and update RIPE NCC Database objects and will explain how to query the database. 4. Routing Registry procedures This section will examine AS numbers, when you need them and how to request them. This will be set within the context of how AS numbers are used as part of the RIPE Routing Registry. Understanding the basic principles behind the Internet Routing Registry and how registering your policy is an important element in the global schema. This section will also include a brief introduction to the PRIDE tools and how they can be useful to you. 5. DNS procedures Where to request forward and reverse domain delegation. Which documentation should be completed. How reverse domain delegation requests are processed at the RIPE NCC (with a useful tool). We will also take a look at common errors in setting up DNS with respect to relevant RFCs and RIPE recommendations. Feedback Please! Throughout the course there will be ample chance for feedback and discussion with an emphasis for you to tell us how we can improve ;-). -------------- next part -------------- %%%%%%%%%%% PLEASE NOTE %%%%%%%%%%% Our handling of ALL course registrations is fully automated. To register for the course, please complete the registration form and send it to . Please send only the registration form in your reply and edit out all other text. Add in a value in the `box' area marked between the square brackets (i.e. "[" and "]" s). If you have any questions about the training course or your registration form, please contact us at . You will receive a notification message that your request has been processed. Many thanks, and look forward to seeing you, RIPE NCC Training Team ---------------------------------------------------------------------------- %START PART 1 - Registration 1) Your name Enter First name, Last name in FULL e.g. John Doe Mary-Beth Walton # NAME [ ] 2) Your Registry ID (format: country-code.) # REG [ ] 3) Your e-mail address # EMAIL [ ] 4) The course you plan to attend (date and location) # COURSE [ Friday 10th May 1996, Budapest, Hungary ] %END From training at ripe.net Tue Apr 16 12:11:22 1996 From: training at ripe.net (RIPE NCC Training) Date: Tue, 16 Apr 1996 12:11:22 +0200 Subject: Reminder: Local IR Workshop in Berlin Message-ID: <9604161011.AA19590@ncc.ripe.net> Dear Local IR's, We would like to remind you of the Local-IR workshop in Berlin next week. There are still some places free. ---------- At the last RIPE Meeting in Amsterdam it was decided to have a Local Internet Registries workshop again in addition to the normal Local IR WG Meeting. The purpose of this workshop is to discuss operational procedures and experiences among LIRs as well as between LIRs and the NCC. The workshop will not be minuted and details about experiences discussed will be kept in strict confidence. The workshop is *not* intended for formal discussions and decisions about procedures as these things are done by the Local-IR working group. This workshop will be organised in conjunction with the 24. RIPE Meeting in Berlin. It will be held on Monday, 24th of April approximately from 9am til 12 am. The workshop is open exlusively for Local IR staff. To have a useful and interactive workshop the attendance is limited to 40 people. In case the workshop is oversubscribed we will limit attendance to one attendee per LIR on a "first-come-first-served" basis. Therefor we advise you to reply asap if you are interested to attend this workshop. We will send out (electronic) tickets to registrants. Only people with ticket will be admitted to the workshop. Preliminary Agenda: - ripe-104++ - how to adopt policy changes in daily operations - reverse delegation - tools - war stories Details of the exact venue and schedule will be distributed later to the registrants. If you have further questions, please don't hesitate to ask. Kind Regards, Mirjam Kuehne Manager NCC Registration Services =========================================================================== Our handling of ALL meeting registrations is fully automated. To register for the workshop, please complete the registration form and send it to . PLEASE FILL THIS OUT AS SPECIFIED. Please add in a value in the `box' area marked between the square brackets (i.e. "[" and "]" s). Note this is what will be used for your badge if you have requested one and for the attendee list so please take care to fill it in correctly. You will receive a notification message that your request has been processe d. If however, you have any questions about the meeting or your registration form, please send your completed form to . %START PART 1 - Registration 1) Your name Enter First name, Last name in FULL (remember this is on list and badge) e.g. John Doe Mary-Beth Walton %NAME [ ] 3) Your Organisation/Institution %ORG [ ] 4) Your e-mail address %EMAIL [ ] 5) Country code of organisation e.g. IT FR DE %CTRY [ ] %END From mnorris at dalkey.hea.ie Tue Apr 16 12:19:11 1996 From: mnorris at dalkey.hea.ie (Mike Norris) Date: Tue, 16 Apr 1996 11:19:11 +0100 Subject: Local IR mtg - draft agenda Message-ID: <9604161019.AA28105@dalkey.hea.ie> Please see the following draft agenda for the meeting of the Local IR WG meeting at RIPE 24. The meeting is scheduled for 14:00 - 15:30 on Monday 22nd April, but I will ask for more time if people feel we need it. Comments and ideas are very welcome. Cheers. Mike RIPE 24 - 22-24 April 1996 Local IR Working Group D R A F T A G E N D A 1. Preliminaries - (auto?)select a minute-taker - agree agenda, times 2. RIPE 23 - minutes - actions outstanding 3. Reports from registries - European regional (RIPE NCC) - other registries, significant events, war stories - other regionals 4. IP Address Space Assignment Procedures - ripe-104 - supporting documentation 5. Charging by Local IRs - RIPE NCC charging model - paper by Karrenberg and Norris 6. Training - RIPE training courses - Local IR workshop 7. Input/Output with other Working Groups - Database - Routing - DNS - NetNews - other 8. Global registry coordination 9. Reverse domains - counts, errors - administration 10. AOB From training at ripe.net Tue Apr 16 12:42:49 1996 From: training at ripe.net (RIPE NCC Training) Date: Tue, 16 Apr 1996 12:42:49 +0200 Subject: Announcement for Local IR Training Course in Amsterdam Message-ID: <9604161042.AA20111@ncc.ripe.net> * * * Announcement * * * Local Internet Registries Training Course Date: Monday 20th May, 1996 Time: 0900 - 1700 Venue: Amsterdam, The Netherlands Amsterdam Airport Schiphol Conference Centre -------------- next part -------------- Course Audience --------------- The target audience for this course is personnel of European Local Internet Registries that contribute to the RIPE NCC. Material Covered ---------------- The course is a one day introduction on Internet name, address and routing policy registration procedures in Europe. It also teaches how to query and use the information registered for operational purposes. This includes the following material and activities: o Overview of name, address and routing registration procedures. o Responsibilities of both RIPE NCC and Local IR's to each other. o Wider context of the Delegated Registry system and relevant issues (IPv4 address depletion, CIDR) and how this relates to IP requests. o How to use the RIPE NCC Database. o Use of AS numbers, Routing Registry concepts and an introduction to using PRIDE tools. o DNS feedback on commor errors, how to request delegations, and pointers to useful tools. We again stress that this course will *not* teach Local Registries on how to run their business as Internet Service Providers. It is clearly focussed on registration procedures and the interaction between the RIPE NCC and local IR's. A detailed outline is appended below. The course itself will include lunch and will be free. This of course does not include your travel and subsitence ;-). How to Register --------------- Please send an RSVP to if you would like to attend the course. If you have previously approached us about attending this course, we ask you to confirm that you (or a colleague) will be attending. Registrations will be accepted on a first come, first served basis. If the course is oversubscribed, we will give priority to local IRs who have most recently paid the signup fee. If it is still oversubscribed, we will accept only one person per new local registry. We will provide additional course dates as necessary. If a number of local registries so request, we will present courses at other European locations. If you would like a local course or have any questions or suggestions, please do not hesitate to contact us. The RIPE NCC Training Team: Mirjam Kuehne, Carol Orange --- Course Outline -------------- We will provide a slidebook and a reader on the day of the course, as well as electronically. It is planned to make detailed documentation available in the form of a guide much like the PRIDE guide. The program will divide the actual content into the following sections: 1. Introduction For those unfamiliar with the Delegated Internet Registry system and the RIPE NCC, this section will give a historical overview of how we have arrived at today's model of operation and why training of local IR's is a much needed activity. 2. IP Registry procedures This section will clarify the procedures between the RIPE NCC and local IR's with respect to requests for IP address space. It will take a step by step approach on how to complete documentation, the kind of information that is required, what the "handholding" procedure is, how to deal with very large requests, and very small requests, and more generally what criteria the RIPE NCC and local IR's use for their customers in the context of CIDR and IPv4 address depletion. 3. RIPE NCC Database This section will explain what the RIPE NCC Database is and how it fits into the scheme of other registry databases. It will cover how to create and update RIPE NCC Database objects and will explain how to query the database. 4. Routing Registry procedures This section will examine AS numbers, when you need them and how to request them. This will be set within the context of how AS numbers are used as part of the RIPE Routing Registry. Understanding the basic principles behind the Internet Routing Registry and how registering your policy is an important element in the global schema. This section will also include a brief introduction to the PRIDE tools and how they can be useful to you. 5. DNS procedures Where to request forward and reverse domain delegation. Which documentation should be completed. How reverse domain delegation requests are processed at the RIPE NCC (with a useful tool). We will also take a look at common errors in setting up DNS with respect to relevant RFCs and RIPE recommendations. Feedback Please! Throughout the course there will be ample chance for feedback and discussion with an emphasis for you to tell us how we can improve ;-). -------------- next part -------------- %%%%%%%%%%% PLEASE NOTE %%%%%%%%%%% Our handling of ALL course registrations is fully automated. To register for the course, please complete the registration form and send it to . Please send only the registration form in your reply and edit out all other text. Add in a value in the `box' area marked between the square brackets (i.e. "[" and "]" s). If you have any questions about the training course or your registration form, please contact us at . You will receive a notification message that your request has been processed. Many thanks, and look forward to seeing you, RIPE NCC Training Team ---------------------------------------------------------------------------- %START PART 1 - Registration 1) Your name Enter First name, Last name in FULL e.g. John Doe Mary-Beth Walton # NAME [ ] 2) Your Registry ID (format: country-code.) # REG [ ] 3) Your e-mail address # EMAIL [ ] 4) The course you plan to attend (date and location) # COURSE [ Monday 20th May 1996, Amsterdam, The Netherlands ] %END From mnorris at dalkey.hea.ie Tue Apr 16 12:51:37 1996 From: mnorris at dalkey.hea.ie (Mike Norris) Date: Tue, 16 Apr 1996 11:51:37 +0100 Subject: Charging by local IRs - draft paper Message-ID: <9604161051.AA28158@dalkey.hea.ie> This closes Action 21.3 on Daniel Karrenberg and me and is for discussion at next week's Local IR meeting. Cheers. Mike Norris ripe-xxx Charging by Local Internet Registries 1. Abstract ------------ This paper deals with charging for services by Internet registries, and indicates acceptable practice for such charging. It identifies name- and address-space as finite resources with no intrinsic value; as such, direct costs cannot be ascribed to such space. It also makes recommendations for the operation of European registries in general, and additionally for those with monopoly positions. 2. Internet services --------------------- In Europe as elsewhere, providers offer a range of services relating to Internet access. These include Internet connectivity, the provision of applications to end-users, design, consultancy and training services, as well as system services such as IP registration, DNS, routing and packet forwarding. With some identifiable exceptions (to which we shall return), there is generally an open market in the provision of such services. On the supply side, there is freedom to enter the market, to compete for business, and to charge for services in order to stay in business. In this context, it is acceptable practice for Internet service providers (ISPs) to charge for services such as domain registration, routing services, packet forwarding and IP services. On the demand side, the general plurality of service providers means that the customer has a choice; if not satisfied with the terms of one supplier, she can take her business to another. 3. Registries and Resources ---------------------------- Two of the above services involve the assignment of finite resources to customers; these are domain name space and IPv4 address space. They are managed and assigned by registration agencies, respectively domain name registries and IP registries. By themselves, these resources have no intrinsic value; their worth is only realised in conjunction with the provision of Internet access. Thus, while registries may charge for their administrative and technical services, they may not charge for namespace or address space as such; no unit cost or price tag can be attached to a domain name or to an IP address, public or private. This principle must be made clear to the market in general and to the customer in particular. The customer must be aware of precisely what she is getting from the registry, whether it is paid for or not. Where there is a charge, the customer must not be under the illusion that this translates into a unit cost per resource assigned. Finally, the customer must accept the terms under which name or address space is assigned. In the case of IP address space, these include the contractual term that the assignment is only valid for so long as the criteria of the assignment are valid [ref 1]. As soon as the original criteria no longer apply, the address space must be returned without penalty or premium to the assigning registry. 4. Special Case Registries --------------------------- As indicated above, there are certain exceptions to the market principle in the Internet registration services. These occur where, by virtue of their location in the hierarchy of Internet registration, certain registries find themselves in a monopoly position. In the case of namespace, this applies to top-level domain (TLD) registries (in Europe, these are all country registries), as well as certain administratively unique second-level domain registries (such as .co.uk, .ac.at etc). When it comes to IP address allocation, regional registries constitute monopolies within the communities they serve. In Europe, one instance is the RIPE NCC, registry for the European region [ref 2]. Other possible examples are the last resort (non-provider) IP registries, although nowadays the customer has an alternative to their services. It is important that there be transparency in the procedures and accounts of such "special case" registries. They must not generate, nor be seen to generate, excessive profits by virtue of their monopoly position. 5. Recommendations ------------------- To meet with the objectives outlined in this paper, it is recommended that **all** registries: - publish their operating procedures; - publish details of the services they offer and the conditions and terms that apply, including scales of tariffs if applicable; - explicitly publish the fact that they do not sell name or address space as such. As for **"special case"** registries as defined above, it is recommended that where such a registry charges for service, it should, in addition to complying with the recommendations listed above: - relate charges to costs of operation and apply all revenues to such costs; - regularly publish a budget of its anticipated operating costs and revenue; - publish guidelines and apply these uniformly; - ensure equality of access to registration services; - achieve consensus within the community it serves as to the disposal of any profits; - regularly publish accounts of income and expenditure; - refrain from using their unique position as leverage in any other business venture. Daniel Karrenberg and Mike Norris 15th April 1996 References ---------- [1] "European Internet Registry Policies and Procedures" by Orange, C., Kuehne, M., Karrenberg, D. (ripe-104, 1996) [2] "RIPE NCC - Delegated Internet Registry" (ripe-112, 1994) From ncc at ripe.net Wed Apr 17 19:01:08 1996 From: ncc at ripe.net (RIPE NCC Staff) Date: Wed, 17 Apr 1996 19:01:08 +0200 Subject: RIPE24: reminder Message-ID: <9604171701.AA23513@ncc.ripe.net> Dear RIPE members, If you want to attend the 24th RIPE meeting, please subscribe to before Friday morning 9:00 if you haven't done so yet! Thank you! more info available from ftp://ftp.ripe.net/ripe/Next-Meeting. Appended below are the announcement with some changes and the registration form. **************************************************************** Changes: - Starting time is 14:00 instead of 10:00! - More information about directions to the venue - Info about public transport tickets - More pointers to WWW information R I P E meeting announcement ============================ (This announcement can also be viewed using "finger meeting at ncc.ripe.net") This is to announce that the 24th RIPE meeting will take place: Dates: 22nd April, 1996 start: 14:00 23rd April, 1996 24th April, 1996 end: 15:30 (*) * times subject to change (may vary +/- 1 hour). For exact times, look at ftp://ftp.ripe.net/ripe/Next-Meeting/announcement shortly before the meeting. Venue: Mathematics building of the Technical University of Berlin Strasse des 17. Juni 136 10623 Berlin (Plenary session will take place in room # MA005) Host: DFN Registration: Please use the registration form (which will follow in a separate mail) to give notice of your coming as soon as possible. General meeting overview: ------------------------- - Monday 22nd from 14:00-18:00, and Tuesday 23rd from 09:00-12:30, there will be various RIPE working groups sessions. The schedule of this meeting is not known yet. - Tuesday 23rd, 14:00-18:00 and Wednesday 24th, 09:00-15:30 (*), the plenary session will take place, with reports from the RIPE NCC, reports from the working group meetings and other presentations. Directions to the meeting venue: -------------------------------- The closest bus- and 'U-Bahn' (subway) stop is 'Ernst-Reuter-Platz'. From airport Berlin-Tegel, you can take express bus X9 there. (X9 leaves very close to the most right exit of the main hall of Tegel airport.) From airport Berlin-Schoenefeld, you can best first go to the international railway station 'Zoologischer Garten'. (Taking train S9 is probably the best way.) From the station 'Zoologischer Garten', you can take the subway U2 in direction Ruhleben; Ernst-Reuter-Platz is the first stop. (Or you could also walk from 'Zoologischer Garten' to the meeting venue.) The mathematics building where the meeting is held, is on the north side of the 'Strasse des 17. Juni'. Public Transport tickets: ------------------------- Tickets can be bought from machines at every station. 'Kurzstrecke' (short ride) tickets are only vald for a certain number of stops; the exact area should be specified at the bus/U-Bahn stops. Prices: Kurzstrecke einfach (1 ride): DM 2,50 Sammelkarte (4 rides): DM 8,50 2-hours-ticket (1 ride): DM 3,90 Sammelkarte (4 rides): DM 13,00 24-hours-ticket: DM 16,00 48-hours-ticket: DM 29,00 7-days-ticket: DM 40,00 General information: -------------------- Currency : 1 UK pound = DM 2.25 1 ECU = DM 1.85 1 US$ = DM 1.47 More information about Berlin on the Web: ----------------------------------------- A lot of information can be found at: <> http://www.city.net/countries/germany/berlin/ <> http://www.kulturbox.de On http://www.kulturbox.de/cgi-bin/berlininfo?&pq=m11 you will find a map of the direct vincinity of the meeting site, which is marked 'Grosser Horsaal'. <> http://www.informatik.hu-berlin.de/BIW/ is all in German, but http://www.informatik.hu-berlin.de/BIW/verkehr gives a nice map of public transport facilities *********************************************************************** 24th RIPE meeting Registration reservation form Berlin, Germany April 22nd-24th, 1996 %%%%%%%%%%% PLEASE NOTE %%%%%%%%%%% Our handling of ALL meeting registrations is fully automated. To register for the meeting, please complete the registration form and send it to . PLEASE FILL THIS OUT AS SPECIFIED. Please add in a value in the `box' area marked between the square brackets (i.e. "[" and "]" s). Note this is what will be used for your badge if you have requested one and for the attendee list so please take care to fill it in correctly. You will receive a notification message that your request has been processed. If however, you have any questions about the meeting or your registration form, please send your completed form to . ============================================================================== %START PART 1 - Registration 1) Your name Enter First name, Last name in FULL (remember this is on list and badge) e.g. John Doe Mary-Beth Walton %NAME [ ] 2) I will need the RIPE NCC staff to come up with a badge for me (Fill in Y if you do not have a badge yet, or if you have given it to the NCC staff to keep until the next meeting. Fill in N if you will bring your old badge to the meeting yourself.) %BADGE [ ] 3) Your Organisation/Institution %ORG [ ] 4) Your e-mail address %EMAIL [ ] 5) Country code of organisation e.g. IT FR DE %CTRY [ ] %END From ncc at ripe.net Wed Apr 17 21:42:39 1996 From: ncc at ripe.net (RIPE NCC Document Annoucement Service) Date: Wed, 17 Apr 1996 21:42:39 +0200 Subject: New Document available: ripe-128++ Message-ID: <9604171942.AA26347@ncc.ripe.net> New/Revised RIPE Document Announcement -------------------------------------- A revised/new document is available from the RIPE document store. Short content description ------------------------- ripe-128++ is the new set of forms local IRs should use when submitting IP address space assignment requests to the RIPE NCC for review. They implement the policies written up in the ripe-104++ document in which which local IR address space assignment policies are defined. The forms are accompanied by a set of instructions and examples. Please review these forms as soon as possible and send your comments to , or bring them to the RIPE-24 Local IR Working Group meeting in Berlin where they will be on the agenda for comment/approval. -------------- next part -------------- FTP Access ---------- All RIPE documents and Internet RFC`s are available via anonymous FTP from host ftp.ripe.net. Type "ftp ftp.ripe.net". Login with username "anonymous" supplying your email address as the password. After logging in, type "cd ripe/drafts/" followed by the command "get filename". The relevant filenames for this document are: ripe-128++.txt for the ASCII version ripe-128++.ps for the PostScript version Electronic Mail Retrieval of Documents -------------------------------------- Documents can also be retrieved from the RIPE document store using a mail server program. For more information on how to use the program, send email to: mail-server at ripe.net with "send HELP" in the body text. RIPE NCC Interactive Information Server --------------------------------------- Type "telnet info.ripe.net". This is a menu driven service allows the document store to be browsed. After reading documents you are prompted as to whether you would like to receive an email copy of the document you have just read. If you would, you simply enter your email address and the document will be mailed to you. Below are details of alternative methods of access. Gopher Access ------------- The same documents are available via a "gopher" server at "gopher gopher.ripe.net". WWW Access ---------- For those who wish to add this home page at the RIPE NCC to their own customized home pages, it can be accessed as: http://www.ripe.net MIME Mail Reader ---------------- Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the RIPE document by FTP or mail server. -------------- next part -------------- SEND ripe/drafts/ripe-128++.txt From 100444.1242 at CompuServe.COM Thu Apr 18 11:21:59 1996 From: 100444.1242 at CompuServe.COM (cis) Date: 18 Apr 96 05:21:59 EDT Subject: New Document available: ripe-128++ Message-ID: <960418092159_100444.1242_BHG133-1@CompuServe.COM> ---------- Forwarded Message ---------- From: RIPE NCC Document Annoucement Service, INTERNET:ncc at ripe.net TO: "Local IR Working Group", INTERNET:LOCAL-IR at RIPE.NET CC: (unknown), INTERNET:STAFF at RIPE.NET (unknown), INTERNET:ORANGE at RIPE.NET DATE: 17/04/96 21:03 RE: New Document available: ripe-128++ Sender: owner-local-ir at ripe.net Received: from ncc.ripe.net (ncc.ripe.net [193.0.0.129]) by arl-img-3.compuserve.com (8.6.10/5.950515) id UAA18686; Wed, 17 Apr 1996 20:22:30 -0400 Received: by ncc.ripe.net id AA26355 (5.65a/NCC-2.33); Wed, 17 Apr 1996 21:42:44 +0200 Received: from voldragen.ripe.net by ncc.ripe.net with SMTP id AA26347 (5.65a/NCC-2.33); Wed, 17 Apr 1996 21:42:39 +0200 Message-Id: <9604171942.AA26347 at ncc.ripe.net> To: "Local IR Working Group" Cc: staff at ripe.net, orange at ripe.net From: RIPE NCC Document Annoucement Service Subject: New Document available: ripe-128++ Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" X-Phone: +31 20 592 5065 X-Fax: +31 20 592 5090 Date: Wed, 17 Apr 1996 21:42:39 +0200 Sender: Carol.Orange at ripe.net ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-Description: Document Announcement New/Revised RIPE Document Announcement -------------------------------------- A revised/new document is available from the RIPE document store. Short content description ------------------------- ripe-128++ is the new set of forms local IRs should use when submitting IP address space assignment requests to the RIPE NCC for review. They implement the policies written up in the ripe-104++ document in which which local IR address space assignment policies are defined. The forms are accompanied by a set of instructions and examples. Please review these forms as soon as possible and send your comments to , or bring them to the RIPE-24 Local IR Working Group meeting in Berlin where they will be on the agenda for comment/approval. ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-Description: Retrieval Methods FTP Access ---------- All RIPE documents and Internet RFC`s are available via anonymous FTP from host ftp.ripe.net. Type "ftp ftp.ripe.net". Login with username "anonymous" supplying your email address as the password. After logging in, type "cd ripe/drafts/" followed by the command "get filename". The relevant filenames for this document are: ripe-128++.txt for the ASCII version ripe-128++.ps for the PostScript version Electronic Mail Retrieval of Documents -------------------------------------- Documents can also be retrieved from the RIPE document store using a mail server program. For more information on how to use the program, send email to: mail-server at ripe.net with "send HELP" in the body text. RIPE NCC Interactive Information Server --------------------------------------- Type "telnet info.ripe.net". This is a menu driven service allows the document store to be browsed. After reading documents you are prompted as to whether you would like to receive an email copy of the document you have just read. If you would, you simply enter your email address and the document will be mailed to you. Below are details of alternative methods of access. Gopher Access ------------- The same documents are available via a "gopher" server at "gopher gopher.ripe.net". WWW Access ---------- For those who wish to add this home page at the RIPE NCC to their own customized home pages, it can be accessed as: http://www.ripe.net MIME Mail Reader ---------------- Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the RIPE document by FTP or mail server. ------- =_aaaaaaaaaa0 Content-Type: message/external-body; access-type="anon-ftp"; name="ripe-128++.txt"; directory="ripe/drafts"; site="ftp.ripe.net" Content-Type: text/plain; type="text" Content-Description: FTP ASCII version ------- =_aaaaaaaaaa0 Content-Type: message/external-body; access-type="mail-server"; server="mail-server at ripe.net" Content-Type: text/plain; type="text" Content-Description: Have mail-server send document SEND ripe/drafts/ripe-128++.txt ------- =_aaaaaaaaaa0 Content-Type: message/external-body; access-type="anon-ftp"; name="ripe-128++.ps"; directory="ripe/drafts/"; site="ftp.ripe.net" Content-Type: application/postscript; type="postscript" Content-Description: FTP PostScript version ------- =_aaaaaaaaaa0-- From mnorris at dalkey.hea.ie Sat Apr 20 16:33:59 1996 From: mnorris at dalkey.hea.ie (Mike Norris) Date: Sat, 20 Apr 96 15:33:59 +0100 Subject: (Fwd) Last Call: INTERNET REGISTRY IP ALLOCATION GUIDELINES to BCP Message-ID: <9604201433.AA02774@dalkey.hea.ie> ------- Forwarded Message Return-Path: owner-cidrd at aarnet.edu.au Received: from IETF.cnri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id DAA00357 for ; Sat, 20 Apr 1996 03:08:03 +1000 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa15673; 19 Apr 96 13:00 EDT To: ;@IETF-Announce; Cc: cidrd at iepg.org From: IESG Secretary Subject: Last Call: INTERNET REGISTRY IP ALLOCATION GUIDELINES to BCP Reply-To: iesg at ietf.org Date: Fri, 19 Apr 96 13:00:30 -0400 Sender: scoya at CNRI.Reston.VA.US Message-Id: <9604191300.aa15673 at IETF.CNRI.Reston.VA.US> The IESG has received a request from the CIDR Deployment Working Group to consider "INTERNET REGISTRY IP ALLOCATION GUIDELINES" for the status of BCP. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg at cnri.reston.va.us or ietf at cnri.reston.va.us mailing lists by May 3, 1996. ------- End of Forwarded Message From training at ripe.net Wed Apr 24 09:55:16 1996 From: training at ripe.net (RIPE NCC Training) Date: Wed, 24 Apr 1996 09:55:16 +0200 Subject: Local IR Training Course Budapest - Registration Closed Message-ID: <9604240755.AA19870@ncc.ripe.net> Dear Local IR's, The registration for the Local IR Training course in Budapest, 10th May 1996 has now been closed. As the course was oversubscribed, we were regrettably, not able to accept everyone. As soon as we have scheduled additional Training Courses, we will announce them to . If your registration could not be accepted this time, please register again for the next course to confirm your continued interest in attending. If you are interested in having a course in your country for a number of local IR's, we would be happy to do this. To discuss this further, please send mail to . Kind regards, Naomi de Bruyn RIPE NCC Training Team From Carol.Orange at ripe.net Fri Apr 26 09:35:05 1996 From: Carol.Orange at ripe.net (Carol Orange) Date: Fri, 26 Apr 1996 09:35:05 +0200 Subject: ripe-128++ Message-ID: <9604260735.AA18260@ncc.ripe.net> Dear Local IR's, Last week, we posted a new set of forms to be used when submitting IP address space assignment requests to the RIPE NCC for review, along with a request for comments. The forms are used to collect information as required by the policies stated in the first four sections of the ripe-104++ document. These policies were approved by the local IR working group when it met at the RIPE 23 meeting in January, 1996. We have received some useful input on the form design. In addition, we have received a number of requests that the forms be finalized and published as soon as possible. To this end, we encourage you to submit any comments or requests regarding the forms before the: Deadline for comments: May 1, 1996 Comments received after this date cannot be included in the revision. Please review the ripe-128++ document, and send your comments to this list for discussion. If your input is of an editorial nature, you can just send it to me . Thanks to those who have already provided useful input. Greetings, -- Carol Orange From MAILER-DAEMON at obelix.tele.net Fri Apr 26 08:58:17 1996 From: MAILER-DAEMON at obelix.tele.net (Mail Delivery Subsystem) Date: Fri, 26 Apr 1996 08:58:17 +0200 Subject: Internet access in Zimbabwe Message-ID: <2.2.32.19960426065817.00687e0c@mail.tele.net> Hello, this is Volkmar Hintze from Germany. Can You help me? I have the following problem. A friend of mine will work in Zimbabwe for two years. He will start his job in september or october this year. Now I'm looking for opportunities to get in E-Mail contact with him. Are there any opportunities to get an user account in Harare (university or commercial)? My friend will live 500 kilometres south of Harare near the borders to South Africa and Mozambik. I hope that somebody will receive this mail. Greetings from Europe Volkmar via hintze at d.zumtobel.co.at From mnorris at dalkey.hea.ie Fri Apr 26 11:12:45 1996 From: mnorris at dalkey.hea.ie (Mike Norris) Date: Fri, 26 Apr 1996 10:12:45 +0100 Subject: Charging by local IRs Message-ID: <9604260912.AA08122@dalkey.hea.ie> Please see the following paper on "Charging by Local Internet Registries". This was enhanced by the Local IR working group and adopted by RIPE earlier this week as a brief statement of current practice in Europe, together with some guidelines for registries. I'm sending this to the Local IR and the DNS lists, and will also copy the European TLD administrators, so apologies for multiple instances of the same mail. Your comments and suggestions are always welcome. Regards. Mike Norris Charging by Local Internet Registries ripe-xxx 1. Abstract This paper deals with charging for services by Internet registries, and indicates acceptable practice for such charging. It identifies name- and address-space as finite resources with no intrinsic value; as such, direct costs cannot be ascribed to such space. It also makes recommendations for the operation of European registries in general, and additionally for those with monopoly positions. 2. Internet services In Europe as elsewhere, providers offer a range of services relating to Internet access. These include Internet connectivity, the provision of applications to end-users, design, consultancy and training services, as well as system services such as IP registration, DNS, routing and packet forwarding. With some identifiable exceptions (to which we shall return), there is generally an open market in the provision of such services. On the supply side, there is freedom to enter the market, to compete for business, and to charge for services in order to stay in business. In this context, it is acceptable practice for Internet service providers (ISPs) to charge for services such as domain registration, routing services, packet forwarding and IP services. On the demand side, the general plurality of service providers means that the customer has a choice; if not satisfied with the terms of one supplier, she can take her business to another. 3. Registries and Resources Two of the above services involve the assignment of finite resources to customers; these are domain name space and IPv4 address space. They are managed and assigned by registration agencies, respectively domain name registries and IP registries. By themselves, these resources have no intrinsic value; their worth is only realised in conjunction with the provision of Internet access. Thus, while registries may charge for their administrative and technical services, they may not charge for namespace or address space as such; no unit cost or price tag can be attached to a domain name or to an IP address, public or private. This principle must be made clear to the market in general and to the customer in particular. The customer must be aware of precisely what she is getting from the registry, whether it is paid for or not. Where there is a charge, the customer must not be under the illusion that this translates into a unit cost per resource assigned, nor that the transaction is an indefinite transfer of ownership of the merchandise. Finally, the customer must accept the terms under which name or address space is assigned. In the case of IP address space, these include the contractual term that the assignment is only valid for so long as the criteria of the assignment are valid [ref 1]. As soon as the original criteria no longer apply, the address space must be returned without penalty or premium to the assigning registry. 4. Special Case Registries As indicated above, there are certain exceptions to the market principle in the Internet registration services. These occur where, by virtue of their location in the hierarchy of Internet registration, certain registries find themselves in a monopoly position. In the case of namespace, this applies to top-level domain (TLD) registries (in Europe, these are all country registries), as well as certain administratively unique second-level domain registries (such as .co.uk, .ac.at etc). When it comes to IP address allocation, regional registries constitute monopolies within the communities they serve. In Europe, one instance is the RIPE NCC, registry for the European region [ref 2]. Other possible examples are the last resort (non-provider) IP registries, although nowadays the customer has an alternative to their services. It is important that there be transparency in the procedures and accounts of such "special case" registries. They must not generate excessive profits by virtue of their monopoly position. 5. Recommendations To meet with the objectives outlined in this paper, it is recommended that all registries: - publish their operating procedures; - publish details of the services they offer and the conditions and terms that apply, including scales of tariffs if applicable; - explicitly publish the fact that they do not sell name or address space as such. As for "special case" registries as defined above, it is recommended that where such a registry charges for service, it should, in addition to complying with the recommendations listed above: - relate charges to costs of operation and apply all revenues to such costs; - regularly publish a budget of its anticipated operating costs and revenue; - publish guidelines and apply these uniformly; - ensure equality of access to registration services; - aim to achieve consensus within the community it serves as to the disposal of any surplus revenues; - regularly publish accounts of income and expenditure; - refrain from using their unique position as leverage in any other business venture. Daniel Karrenberg and Mike Norris 22nd April 1996 References 1. "European Internet Registry Policies and Procedures" by Orange, C., Kuehne, M., Karrenberg, D. (ripe-104, 1996) 2. "RIPE NCC - Delegated Internet Registry" (ripe-112, 1994) From training at ripe.net Fri Apr 26 14:59:54 1996 From: training at ripe.net (RIPE NCC Training) Date: Fri, 26 Apr 1996 14:59:54 +0200 Subject: Local IR Training Course Amsterdam - Registration Closed Message-ID: <9604261259.AA25857@ncc.ripe.net> Dear Local IR's, The registration for the Local IR Training course in Amsterdam, 20th May 1996 has now been closed. As the course was oversubscribed, we were regrettably, not able to accept everyone. As soon as we have scheduled additional Training Courses, we will announce them to . If your registration could not be accepted this time, please register again for the next course to confirm your continued interest in attending. If you are interested in having a course in your country for a number of local IR's, we would be happy to do this. To discuss this further, please send mail to . Kind regards, Naomi de Bruyn RIPE NCC Training Team From HANK at VM.TAU.AC.IL Sun Apr 28 06:55:34 1996 From: HANK at VM.TAU.AC.IL (Hank Nussbacher) Date: Sun, 28 Apr 96 06:55:34 IST Subject: Charging by local IRs In-Reply-To: Message of Fri, 26 Apr 1996 10:12:45 +0100 from Message-ID: <9604280401.GA05555@nikhefh.nikhef.nl> On Fri, 26 Apr 1996 10:12:45 +0100 you said: > Charging by Local Internet Registries > > ripe-xxx ... >5. Recommendations >To meet with the objectives outlined in this paper, it is recommended that >all registries: > > - publish their operating procedures; > > - publish details of the services they offer and the conditions and > terms that apply, including scales of tariffs if applicable; Why not have these procedures and national policies hyperlinked into this document, or have RIPE act as a repository for such docs such that countries exploring this area can compare "notes" with what other countries do? Hank From Piet.Beertema at cwi.nl Mon Apr 29 11:33:02 1996 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Mon, 29 Apr 1996 11:33:02 +0200 Subject: Charging by local IRs In-Reply-To: "Your message of Sun, 28 Apr 96 06:55:34 IST " <9604280401.GA05555@nikhefh.nikhef.nl> Message-ID: <9604290933.AA01525=piet@kraai.cwi.nl> >5. Recommendations >To meet with the objectives outlined in this paper, it is recommended that >all registries: > > - publish their operating procedures; > > - publish details of the services they offer and the conditions and > terms that apply, including scales of tariffs if applicable; Why not have these procedures and national policies hyperlinked into this document, or have RIPE act as a repository for such docs such that countries exploring this area can compare "notes" with what other countries do? Hyperlinking documents in a national language into some international document is pretty useless. The same goes for putting the stuff in a central repository. The best compromise would be a short description in English of the procedures and policies, provided that is made very clear that said description does *not* formally take the role of the original documents. Piet From Daniel.Karrenberg at ripe.net Mon Apr 29 12:07:29 1996 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 29 Apr 1996 12:07:29 +0200 Subject: European Data in the InterNIC Database Message-ID: <9604291007.AA22934@ncc.ripe.net> Dear Mark, as you know the RIPE community has a long standing concern about the consistency of the information available from the InterNIC whois service and the RIPE NCC whois service. The information describing European entities in the RIPE database is consistently found to be more up-to-date than data registered at the InterNIC. Both the InterNIC and the RIPE NCC have been trying to get the exchange of information to work for more than three years with little success due to lack of resources on both sides. At the same time we observe an increasing number of instances where data about European entities obtained to the InterNIC whois service is causing confusion and delays in Internet trouble shooting. Some of this is due to new and relatively unexperienced NOC staff in many places. Today it becomes extremely important that people are referred to the correct information. The RIPE local-IR working group has discussed this problem at its recent meeting in Berlin. Since making our databases consistent has not worked despite our long standing intentions, the RIPE community now asks you to remove data describing European entities from the InterNIC database as soon as possible. The InterNIC whois server should not return data and contact info about these. Most importantly this concerns address space information of 192.162.0.0 - 192.162.255.255 192.164.0.0 - 192.168.255.255 193.0.0.0 - 195.255.255.255 and AS number information of 1877 - 1901 2043 2047 2107 - 2136 2585 - 2614 2773 - 2822 2830 - 2879 3154 - 3353 5377 - 5631 If possible the InterNIC whois server should return a text pointing to whois.ripe.net if these objects are queried. It should never return more specific data. Could you please inform us when this will be implemented. We hope that you understand the importance of this to the smooth operation of the Internet as a whole. This request is not intended as a critique on the InterNIC's services or staff. It is just a logical consequence of the existence of multiple regional Internet registries and the difficulties in creating a globally synchronised database. I hope that after all we will succeed in achieveing such a global database, but until then we have to take measures to prevent confusion. Thank you in advance for your help with this issue. Daniel From Daniel.Karrenberg at ripe.net Mon Apr 29 12:25:18 1996 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 29 Apr 1996 12:25:18 +0200 Subject: Charging by local IRs In-Reply-To: Your message of Mon, 29 Apr 1996 11:33:02 +0200. <9604290933.AA01525=piet@kraai.cwi.nl> References: <9604290933.AA01525=piet@kraai.cwi.nl> Message-ID: <9604291025.AA23302@ncc.ripe.net> > Piet Beertema writes: > > Hyperlinking documents in a national language into some > international document is pretty useless. I do not agree. Someone local searching for the document may find it through the international document. Why don't you let the user decide? > The best > compromise would be a short description in English of > the procedures and policies, provided that is made very > clear that said description does *not* formally take the > role of the original documents. That would be excellent service o course. Daniel From barry at singnet.com.sg Mon Apr 29 09:20:09 1996 From: barry at singnet.com.sg (Barry Raveendran Greene) Date: Mon, 29 Apr 1996 15:20:09 +0800 Subject: Last Call: INTERNET REGISTRY IP ALLOCATION GUIDELINES to BCP Message-ID: <01BB35DF.AD9DCE00@ts900-4508.singnet.com.sg> TO: IESG and AP Internet Community, The IESG has received a request from the CIDR Deployment Working Group to consider "INTERNET REGISTRY IP ALLOCATION GUIDELINES" for the status of BCP. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg at cnri.reston.va.us or ietf at cnri.reston.va.us mailing lists by May 3, 1996. As the draft stands now, Singapore Telecom would be against this document being forwarded to become an Internet Best Common Practice (BCP) status (i.e. an Internet operational standard). The draft as it stands, reflects policies that promote and encourage a US Centric Internet infrastructure and enshrines the position of a few large US ISPs will then dominate the rest of the world. This endangers the development of domestic Internet infrastructures in the Asia Pacific Region and penalizes the Asia Pacific Region for doing a good job at keeping it's assigned blocks (202 and 203) within acceptable utilization AND routing levels. ALL ASIA PACFIC readers who are CCed on this message are highly encouraged to download this draft document at: ftp://ds.internic.net/internet-drafts/draft-hubbard-registry-guidelines-01.txt and forward your position by May 3! Please do so otherwise, a major global Internet policy will be forced on you (just reply to this message). If you agree or disagree with this draft moving to BCP status, please send an E-mail message to: iesg at cnri.reston.va.us or ietf at cnri.reston.va.us. All voices and comments count! I know that the team who put together the draft worked hard to get to this point. 80% of the draft is excellent, but it still needs more work. Below are some of my comments. Later, I will submit proposed changes formally to the authors. Barry Raveendran Greene Deputy Director SingNet/STIX Planning and Operation Singapore Telecom ================================================================= SINGAPORE TELECOM PRELIMINARY COMMENTS Section 2 - Allocation Framework As it stands in this draft, a new ISP in country X will have to get their IP addresses from their upstream provider. Most ISPs in AP have their upstream provider in the United States, therefore this would mean getting your addresses from the US provider. Getting it from THE US provider means that country X will be ENSLAVED to that ISP and that country to the upstream provider. If country X then wishes to move to another cheaper upstream provider they will have to RENUMBER the whole country. Since everyone agrees that the Internet is critical to business (i.e. the Internet as the foundation for the GII) , you will see how this policy has a direct impact on the ECONOMY of countries. One counter argument to this would be that this ISP in country X should have multi-homed right away. However, we know that those who say so are obviously not aware of the prices ISPs outside of the US need to pay to get there. Today, we are seeing two large US ISPs trying to promote this policy on new Asia Pacific ISPs who are unaware of the current APNIC policies (which are working). They are pushing their IP addresses on these national ISPs. A year from now, when the lease circuit contracts are terminated, that AP ISP who may wish to move to another upstream provider, will now have to renumber all the networks under that AP ISP. This it would be disastrous for that ISP to renumber, therefore, they have no choice but to be stuck to their original US upstream provider. Having now a captured customer, the US ISP can raise prices anytime. Hence, you can see how this policy only promotes US commercial interest above the interest of a global Internet infrastructure. Those in the CIDR community, should remember, that we are only talking about ONE routing entry per Asia Pacific ISP. APNIC (202-203) has NOT been a problem. We are keeping our act together. This draft penalizes ISPs in the APNIC region for doing a great job at keeping 202 - 203 from become a problem for the rest of the world. There is therefore NO REASON to change things in AP. Section 3.0 Comments are similar to the above. The only exception would be that if this draft is forward to BCP, Singapore Telecom will push APNIC to move from the current "slow start" policy to a default /18 for ALL NEW ISPs in countries in the AP region. This will be done through section 6 "Right to Appeal" on the basis of best interest of a global Internet and to insure each country has the flexibility to develop its domestic Internet infrastructure in a way that would make since for them. Please note that in Asia Pacific, these domestic Internet infrastructures are also called National Information Infrastructures (NIIs). Asia Pacific governments sees NIIs as a critical tool to continued economic growth. This draft threatens the autonomy and flexibly to choose what makes since for their country. The counter to this would be for each nation to form their own registry. But as we (in the AP region) know, this is a painful process. It takes time for national NICs to be formed, is it is feasible to form them at all. National NICs are not a solution. Section 3.3 Previous Assignment History. This section is out prevent companies like IBM, HP, and other old allocations of the class A space from getting more addresses. The result is to hamstring the Asia Pacific Internet community. Business relationships in Asia Pacific and very complex, interrelated, and competitive. Example, if you trace Asia Pacific country X's ISP corporate parentage, you will find that they all lead to one of several interrelated holding companies. Yet, all of country X's ISPs are cut throat competitive. You find similar relationships all other countries in the AP region. My colleague at JPNIC has also commented on this section from the JP perspective. This section of the draft does not consider any other business culture that the US. As a result, it will cause more problems and disruption then solve. ---------- From: IESG Secretary[SMTP:iesg-secretary at ietf.org] Sent: Saturday, April 20, 1996 1:01 AM To: IETF-Announce:; Cc: cidrd at iepg.org Subject: Last Call: INTERNET REGISTRY IP ALLOCATION GUIDELINES to BCP The IESG has received a request from the CIDR Deployment Working Group to consider "INTERNET REGISTRY IP ALLOCATION GUIDELINES" for the status of BCP. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg at cnri.reston.va.us or ietf at cnri.reston.va.us mailing lists by May 3, 1996. From Daniel.Karrenberg at ripe.net Mon Apr 29 14:21:22 1996 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 29 Apr 1996 14:21:22 +0200 Subject: European Data in the InterNIC Database In-Reply-To: Your message of Mon, 29 Apr 1996 12:07:29 +0200. <9604291007.AA22934@ncc.ripe.net> References: <9604291007.AA22934@ncc.ripe.net> Message-ID: <9604291221.AA02507@ncc.ripe.net> > Daniel Karrenberg writes: > 192.164.0.0 - 192.168.255.255 Oops I forgot that we "donated" 192.168/16 to private address space. Take that out please. Sorry ;-). Also add 1101-1200 to the AS number range. Daniel From NOREILLY at cclana.ucd.ie Mon Apr 29 16:13:37 1996 From: NOREILLY at cclana.ucd.ie (Niall O'Reilly) Date: Mon, 29 Apr 1996 15:13:37 +0100 (BST) Subject: Charging by local IRs Message-ID: <35D2210224@cclana.ucd.ie> > > > Piet Beertema writes: > > > > Hyperlinking documents in a national language into some > > international document is pretty useless. > >I do not agree. Someone local searching for the document >may find it through the international document. >Why don't you let the user decide? Aontai/m le Daniel. Ik ben met Daniel mee eens. I agree with Daniel. Niall O'Reilly From woeber at cc.univie.ac.at Mon Apr 29 16:15:48 1996 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Mon, 29 Apr 1996 16:15:48 MET Subject: Charging by local IRs Message-ID: <009A196F.9724F76A.1@cc.univie.ac.at> = > Piet Beertema writes: = > = > Hyperlinking documents in a national language into some = > international document is pretty useless. = =I do not agree. Someone local searching for the document =may find it through the international document. =Why don't you let the user decide? While I do not want to comment on the usefulness of this approach - I'm certainly worried with the logistics. How would you keep the links "healthy" in the long run and the referred-to documents up-to-date? . Either store the documents where they are maintained --> broken links, eventually. . Or store the documents alongside with the parent doc at the RIPE-NCC --> non-trivial to make the access "secure" and at the same time resonably comfortable to ensure regular updates. = > The best = > compromise would be a short description in English of = > the procedures and policies, provided that is made very = > clear that said description does *not* formally take the = > role of the original documents. = =That would be excellent service o course. Nice to have, I agree. Otoh, I don't really understand the rationale to register a name in country when there is nobody available to cope with a local-language document... (Yes we keep getting such requests more frequently these days :-) =Daniel Wilfried. -------------------------------------------------------------------------- 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 Daniel.Karrenberg at ripe.net Mon Apr 29 16:26:55 1996 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 29 Apr 1996 16:26:55 +0200 Subject: Charging by local IRs In-Reply-To: Your message of Mon, 29 Apr 1996 16:15:48 +0700. <009A196F.9724F76A.1@cc.univie.ac.at> References: <009A196F.9724F76A.1@cc.univie.ac.at> Message-ID: <9604291426.AA05790@ncc.ripe.net> > "Wilfried Woeber, UniVie/ACOnet" writes: > . Either store the documents where they are maintained > --> broken links, eventually. I do not expect much volatility in this area. Also the new setup of the RIPE docstore will note this as it happens and it can be fixed quickly. > . Or store the documents alongside with the parent doc at the RIPE-NCC > --> non-trivial to make the access "secure" and at the same time > resonably comfortable to ensure regular updates. This is slightly more involved and therefore 2nd choice. > Nice to have, I agree. > > Otoh, I don't really understand the rationale to register a name in > country when there is nobody available to cope with a local-language > document... > (Yes we keep getting such requests more frequently these days :-) This is why I say 'nice service'. It is not required and as Piet says can be just some explanations which are explicitly a summary and not formally binding. It can be useful however for someone making an overview of what is required for -say- a pan-European company. In this case they do not need to have n documents translated just to produce the overview. Daniel From Roderik.Muit at ripe.net Mon Apr 29 16:50:15 1996 From: Roderik.Muit at ripe.net (Roderik Muit) Date: Mon, 29 Apr 1996 16:50:15 +0200 Subject: TLD admin mailinglist Message-ID: <9604291450.AA06269@ncc.ripe.net> It has been said a few times at the 24th RIPE meeting in Berlin that a mailinglist for Top Level Domain adminstrators has not been created yet. (Action point 23.2 was still considered open.) This is not true, however. The mailinglist was set up in the week after the 23rd RIPE meeting. The announcement of this has been sent to the DNS working group mailinglist. ====== From svl at csl1.csl-gmbh.net Tue Apr 30 09:08:22 1996 From: svl at csl1.csl-gmbh.net (Siegfried Langenbach) Date: Tue, 30 Apr 1996 09:08:22 +200 (MESZ) Subject: Charging by local IRs In-Reply-To: <35D2210224@cclana.ucd.ie> Message-ID: On Mon, 29 Apr 1996, Niall O'Reilly wrote: > Date: Mon, 29 Apr 1996 15:13:37 +0100 (BST) > From: Niall O'Reilly > To: Daniel Karrenberg , Piet.Beertema at cwi.nl > Cc: dns-wg at ripe.net, local-ir at ripe.net > Subject: Re: Charging by local IRs > > > > > > Piet Beertema writes: > > > > > > Hyperlinking documents in a national language into some > > > international document is pretty useless. > > > >I do not agree. Someone local searching for the document > >may find it through the international document. > >Why don't you let the user decide? > > Aontai/m le Daniel. Ik ben met Daniel mee eens. > I agree with Daniel. eu tamben sou de accordo com daniel. ich stimme daniel auch zu. > > Niall O'Reilly > > ______________________________________________________________________ MfG = Regards http://www.csl-gmbh.net Siegfried Langenbach / CSL GmbH / Voice 049 2104 93850 Fax 938555 ______________________________________________________________________ From bonito at nis.garr.it Tue Apr 30 10:26:26 1996 From: bonito at nis.garr.it (Antonio_Blasco Bonito) Date: Tue, 30 Apr 96 10:26:26 MET DST Subject: TLD admin mailinglist In-Reply-To: <9604291450.AA06269@ncc.ripe.net>; from "Roderik Muit" at Apr 29, 96 4:50 pm Message-ID: <199604300826.KAA03227@cuori.nis.garr.it> Quoting from Roderik Muit's message: > > > It has been said a few times at the 24th RIPE meeting in Berlin that a > mailinglist for Top Level Domain adminstrators has not been created yet. > (Action point 23.2 was still considered open.) > > This is not true, however. The mailinglist was set up in the week > after the 23rd RIPE meeting. The announcement of this has been sent to > the DNS working group mailinglist. I'm sorry, I cannot explain why but I lost that mail. Also anybody who might have got it wasn't prompt to remember that during the WG meeting in Berlin. Anyway, thank you very much. The list is there so let's start using it... During the last meeting I proposed myself as a sort of list administrator who could take care of subscriptions/deletions and such. I understand from Geert-Jan's message that RIPE-NCC is willing to take care of that. I then propose the following actions: - get from Guy Davies the addresses of all the people who answered the TLD questionnaire. - add them to the list - send to each one of them a short welcome message After that start the list activity asking the list members about the inclusion of IANA and xxx-NICs. BTW, I personally agree about that. Blasco > ====== > > > >From geertj at ripe.net Thu Feb 1 19:28:32 1996 > Received: from office.ripe.net by ncc.ripe.net with SMTP > id AA08699 (5.65a/NCC-2.31); Thu, 1 Feb 1996 19:28:32 +0100 > Message-Id: <9602011828.AA08699 at ncc.ripe.net> > To: dns-wg at ripe.net > Cc: kre at munnari.oz.au > Subject: New mailing list: tld-admin at ripe.net > From: Geert Jan de Groot > X-Organization: RIPE Network Coordination Centre > X-Phone: +31 20 592 5065 > Date: Thu, 01 Feb 1996 19:28:31 +0100 > Sender: GeertJan.deGroot at ripe.net > > > As requested at the last RIPE meeting, I have set up a new mailing list > for TLD administrators: tld-admin at ripe.net. > This is a closed mailing list; per request of the WG, only people > who are maintaining a TLD are allowed to subscribe. > > As we need to verify requestor's affiliation, please send subscription > requests to tld-admin-request at ripe.net including the name of the TLD > you are administering. Please keep in mind that we need to verify things > by hand and therefore some time may lapse processing requests. > > The maillist is archived, but again only privately so if you need a > copy of the archive, please ask tld-admin-request at ripe.net. > > I'd like the TLD-admins to consider if they feel it is a good idea > that the parties listed in RFC1591 (IANA, APNIC, InterNIC and RIPE NCC) > are also allowed to subscribe or if the list should be restricted > to TLD admins only. > > Let's party! > > Geert Jan > > -- ---------- ---------- Antonio-Blasco Bonito E-Mail: bonito at nis.garr.it GARR - Network Information Service c=it;a=garr;p=garr;o=nis;s=bonito c/o CNUCE - Istituto del CNR Tel: +39 50 593246 Via S. Maria, 36 Fax: +39 50 904052 I-56126 PISA Telex: 500371 CNUCE I Italy Url: http://www.nis.garr.it/nis/staff/bonito.html ---------- ---------- From GeertJan.deGroot at ripe.net Tue Apr 30 13:03:02 1996 From: GeertJan.deGroot at ripe.net (Geert Jan de Groot) Date: Tue, 30 Apr 1996 13:03:02 +0200 Subject: TLD admin mailinglist In-Reply-To: Your message of "Tue, 30 Apr 1996 10:26:26 +0700." <199604300826.KAA03227@cuori.nis.garr.it> Message-ID: <9604301103.AA08144@ncc.ripe.net> [Please send follow-ons only to dns-wg at ripe.net - only one list is sufficient I guess] On Tue, 30 Apr 96 10:26:26 MET DST Antonio_Blasco Bonito wrote: > Anyway, thank you very much. The list is there so let's start using > it... During the last meeting I proposed myself as a sort of list > administrator who could take care of subscriptions/deletions and such. > I understand from Geert-Jan's message that RIPE-NCC is willing to take > care of that. I then propose the following actions: > > - get from Guy Davies the addresses of all the people who answered the > TLD questionnaire. > - add them to the list > - send to each one of them a short welcome message > > After that start the list activity asking the list members about the > inclusion of IANA and xxx-NICs. BTW, I personally agree about that. Things have progressed a little beyond that. The mailing list is set up, and maintained at the RIPE NCC. About 25 people have subscribed. There was consensus to invite IANA to the list. Traffic has been a bit low recently. People still wanting to subscribe can send a request to tld-admin-request at ripe.net. Please include your credentials (as in 'I am the administrative contact for country xxyyzz') as it is a closed list (by request), and we need to verify the requestors. A mailing list archive is maintained by the RIPE NCC and available to the subscribers by request. Geert Jan From woeber at cc.univie.ac.at Tue Apr 30 14:45:24 1996 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 30 Apr 1996 14:45:24 MET Subject: Charging by local IRs Message-ID: <009A1A2C.20CEF21A.15@cc.univie.ac.at> Daniel said: = > "Wilfried Woeber, UniVie/ACOnet" writes: = > . Either store the documents where they are maintained = > --> broken links, eventually. = =I do not expect much volatility in this area. Also the new setup of =the RIPE docstore will note this as it happens and it can be fixed quickly. = = > . Or store the documents alongside with the parent doc at the RIPE-NCC = > --> non-trivial to make the access "secure" and at the same time = > resonably comfortable to ensure regular updates. = =This is slightly more involved and therefore 2nd choice. I stil think that it would be much simpler to put any relevant urls into the TLD-objects in the RIPE-DB, either in a remark: attribute or in the (proposed) url: attribute. Wilfried. BTW, technical curiosity: how do you intend to keep track of dangling pointers in the "new RIPE Web"? Carol mentioned that aspect briefly in the plenary report but didn't go into details... -------------------------------------------------------------------------- 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 --------------------------------------------------------------------------