- ripe-list - mailman.ripe.net

RIPE 38 Meeting Reminder
by RIPE NCC Meeting Registration 05 Jan '01

05 Jan '01

Dear Colleagues, [ Apologies for duplicate mails ] We would like to remind you that the registration for the RIPE 38 meeting, to be held from 22-26 January, 2001 at: Hotel Krasnapolsky in Amsterdam, is open. * Please note the 50 EUR discount for early registries until 12 January, 2001. More information about this meeting and accommodations can be found on this page: http://www.ripe.net/ripe/meetings/current/ripe-38/index.html On-site registration will open on Monday, 22 January, 2001. Please note the following: - - - - To avoid wait queues at the registration desk on-site we encourage pre-payment by credit card. The registration fee for this meeting is EUR 350.00 (this includes refreshments and lunches) and the dinner fee is EUR 65.00. However, if payment is received before 12 January, 2001, the pre-payment cut-off date, you will receive a pre-registration discount of EUR 50.00. Therefore, the fee for attendees paying before the cut-off date is EUR 300.00 for the meeting and 65.00 EUR for the RIPE dinner event. Confirmation of Registration: For your convenience you can register using our secure website at: https://www.ripe.net/cgi-bin/mtgreg (encrypted form) http://www.ripe.net/cgi-bin/mtgreg (non-encrypted form) If you still prefer not to send your credit card number using an encrypted transfer method, we have prepared a fax form. This form is attached to the acknowledgement of your registration. You will receive a second acknowledgement by e-mail as soon your payment has been processed. In addition, you will find the receipt for your payment in your conference envelope. Participants requiring a visa to enter The Netherlands are advised to begin the required procedures as soon as possible. The RIPE Meeting organisers are pleased to provide letters of invitation to those attendees requiring them. Should you have any further questions, please do not hesitate to contact us at <meeting(a)ripe.net>. Kind regards, Sylvana Wenderhold RIPE Meeting Registrations - - - ------------------------------------------------------------------------- %START Do not change the following field %MTG [ ripe38 ] Please add a value in the 'box' area marked between the square brackets (i.e. "[" and "]" s). If values are already supplied between the brackets, please delete all values except one. PART 1 - Registration Note this is what will be used for your badge and for the attendee list, so please take care to fill it in correctly. 1) Your name Please enter your first name only. Please look at the example and refrain from using all capitals. e.g. John , Mary B. %NAME [ ] Please enter your last name next e.g. Doe %SURNAME [ ] 2) Your Organisation/Institution %ORG [ ] 3) Your Organisation's Complete Postal Address e.g. Singel 258, 1016 AB Amsterdam, The Netherlands %ORGADDR [ ] 4) Your Organisation type e.g. Commercial (com), Government (gov), Association (aso), Educational (edu), Other (oth) (please delete all choices except one) %ORGTYPE [ com / gov / aso / edu / oth ] 5) The NCC Reg-id of your Organisation %REGID [ ] (Only if you represent a Local Internet Registry) 6) Your e-mail address %EMAIL [ ] 7) Country code of organisation e.g. IT FR DE %CTRY [ ] 8) Do you want to attend the Newcomers Introductory Talk ? (please delete one option so your choice is in the form) %INTRO-MTG [ no / yes ] 9) Do you want to attend the EOF? (please delete one option so your choice is in the form) %EOF [ no / yes ] PART 2 - Payment of Registration Fees WARNING!! - Note that sending your credit card information via e-mail is in principle not secure. The payment information will be transmitted in clear via e-mail. If you do not want to do this, please leave your credit card details blank in this form, and send them to us by fax. Please do not forget to mention your name and organisation on the fax, so there will be no risk in us getting confused. Our fax number is: +31 20 535 44 45 1) Method of payment. Payment in advance is greatly preferred. (please delete all choices except one) %PMETH [in advance; credit card / at meeting; credit card / at meeting; cash ] ( *NB: please note aforementioned reduction when paying in advance *) 2) Type of credit card (please delete all choices except one) %CTYPE [ VISA / American Express / Mastercard / Eurocard ] 3) Amount to be paid %AMT [RIPE Meeting only incl. reduction; EUR 300 / RIPE Meeting only excl. reduction; EUR 350 / RIPE Meeting plus RIPE dinner incl. reduction; EUR 365 / RIPE Meeting plus RIPE dinner excl. reduction; EUR 415 ] Payment details sent online cannot be processed after, January 12, 2001 with this form. You are welcome to send in your personal data with this form to register, but the actual payment can then only be made at the meeting itself on January 22-25, 2001. ( again: please choose reduction ONLY when paying in advance ) 4) If you are coming to the RIPE dinner, indicate if you want a vegetarian meal. (please delete one option so your choice is in the form) %VEGGIE [ no / yes ] %END

2 1

RIPE Whois RPSL Migration
by RIPE NCC 04 Jan '01

04 Jan '01

[ Apologies for duplicate mails ] RIPE Whois RPSL Migration The RIPE Database re-implementation project is nearing completion. A key feature of the new database is the implementation of RPSL, to replace the old RIPE-181 standard. RPSL is similar, but not identical, to RIPE-181. The RIPE NCC expects that many programs that use the RIPE Whois database will continue to operate properly without modification. However, some programs may have problems parsing the RPSL format, or be confused by differences in behaviour. We would like to ensure that the transition to RPSL is as easy as possible. Therefore, we are working with the RIPE community to provide resources you can use to check any programs or scripts that you have that use the RIPE Whois database. Please visit our Migration page for further information: http://www.ripe.net/ripencc/pub-services/db/rpsl/index.html This page will be updated regularly with the latest information. We will provide additional tools and information as they become available. The actual timeline of when the RPSL server will replace the existing RIPE-181 server will be decided at the RIPE-38 meeting. If you want input on when the change will occur, then you should either attend this meeting or post your comments on the RIPE DB mailing list. http://www.ripe.net/ripe/meetings/current/ripe-38/index.html http://www.ripe.net/ripe/wg/db/index.html Regards, The RIPE Database Group. RIPE NCC

4 5

Draft Plenary Minutes RIPE 37
by RIPE NCC Meeting Registration 04 Jan '01

04 Jan '01

Dear Colleagues, [ Apologies for duplicate mails ] Please find below the RIPE 37 draft plenary minutes. The draft plenary minutes are also available on our website at: http://www.ripe.net/ripe/meetings/archive/ripe-37/plenary-minutes.html Kind regards, Sylvana Wenderhold RIPE NCC -------- 37th RIPE Meeting Plenary Session Minutes - Draft RIPE 37 Amsterdam, 12 -15 September, 2000 Plenary Session Chair: Rob Blokzijl Scribe: Sylvana Wenderhold 1. Opening and Welcome 2. The Agenda 3. Minutes from RIPE 36 4. From the Chair 5. Report from the RIPE NCC 6. News from ICANN - Louis Touton 7. IPv6 Address Allocation Policies - Bob Hinden 8. ETSI and its Role in Developing Standards for the Internet -Christopher Corbett 9. Reports from the Working Groups 10. Next RIPE meetings 11. AOB 12. Close 1. Opening and Welcome RIPE Chair Rob Blokzijl welcomed the participants to the RIPE 37 meeting. 2. The Agenda The RIPE meeting participants approved the agenda. 3. Minutes from RIPE 36 The minutes were approved. 4. From the Chair Rob thanked the sponsors of the social events: - GTS (opening reception) - Band-X (social gathering) - AMS-IX (party). He also gave a warm thank you to Patrick de Muynck (also on behalf of Lars Johann Liman) for all hard work he put into preparing the Multicast Tutorial. He thanked Cisco for providing the equipment. 5. Report from the RIPE NCC Axel Pawlik, Managing Director, RIPE NCC introduced himself. Please see the following URL for his presentation: http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/ LIRs: There continues to be a rapid growth of LIRs. The number of LIRs in Africa is growing. Address space usage: The number of request is still going up. IPv6: The RIPE NCC continues to receive requests for IPv6. It is overall relatively quiet in the day-to-day business, but as seen in the working groups there is a lot of work to be done in setting the policies. The RIPE NCC closely co-operates with the other RIRs and the IETF on IPv6 issues. Achievements: Unfortunately, the wait queue has not gone down. After RIPE 36 in Budapest the wait queue went done for a short time period. However, it has gone back up. Axel explained the emergency short-term measures that were used to combat the wait queue. - RIPE NCC ex-hostmasters were recruited to bring the wait queue down. - Overtime work was done by hostmasters. Unfortunately, staff can only work under those measures for a short period. To avoid burn out, the hostmasters are now back to their regular schedule. - Another solution was to ask fellow RIRs to support us and send one or two hostmasters. APNIC sent us Son Thanh Tran and Anne Lord. The RIPE NCC also approached ARIN. They had to decline as they are dealing with a similar situation. As a long-term solution the RIPE NCC is hiring a sufficient number of hostmasters to deal with the peaks periods. In addition, the RIPE NCC is working on the development of tools to automate and streamline the process of registration services. Special attention has been given to improving our documentation, making it easier for LIRs to fill in the required forms: - An RIPE NCC Reference Guide booklet has been developed - The FAQ page has been drastically improved - There is a 'tips' page available to help LIRs with requests - The number of LIR courses has been increased (41 courses for 2000). A closer look is taken into dealing with the responsibilities of documenting past address usage. The May 17 Task Force suggests that part of this responsibility will be on the part of the LIRs. This way they can provide RIPE NCC with accurate information and as a result their request will be easier and quicker to process. The May 17 Task Force had been formed in Budapest to find solutions for the wait queue problem. They will present their findings in Friday's Plenary. Axel informed the attendees that the results offered by the Task Force are interesting and in some cases extreme. The RIPE NCC board supports measures to bring the wait queue down. Axel expressed his contentment about the overwhelming interest in the Tools BoF meeting that was given earlier in the week. RIPE Database: Top-level domain data has gone from the database. In Budapest 57 percent were domain-related objects. This has decreased to below 20 percent. Data Protection: Non-PGP maintainers protect about half of the objects, whereas a tiny amount of data is protected by PGP. RIPE NCC has licenses and Axel urged the attendees to obtain a license. Database re-implementation is practically done. The database is functional. The RIPE NCC is now looking for volunteers to test it. The information about the project can be found at: - http://www.ripe.net/ripencc/pub-services/db/reimp - mailing list db-beta(a)ripe.net - project development team dbrip(a)ripe.net Three million objects are left after the domains went out at the end of June. Queries have levelled off a bit. There are still approximately seven queries per second. Updates have gone up dramatically. External Communications: As Axel had explained in Budapest, the main objective of the external communications is to increase awareness about RIPE and the RIPE NCC: - RIPE NCC staff visited the ETSI offices - RIPE NCC produced a joint press release with the GSM clarifying address space policies resolving any uncertainty regarding the availability of IP address space to support the infrastructure of GPRS roaming services. - RIPE NCC visited some representatives of the french government, one of which is also a member of the Government Advisory Council (GAC) for ICANN. She raised the concern that some countries are having difficulties getting addresses. As a result, the RIRs and Address Council will deliver a presentation at the next GAC meeting. LIR courses: The number of classes will be increased to 41 per year. In the short term to deal with the increase in LIRs the number of participants will increase to 30 per course. New projects: Test Traffic Measurements (TTM): The analysis code has been improved. The RIPE NCC continues to produce new test boxes. There is a draft for the service contract. There are two issues: - As the RIPE NCC is a non-profit organisation, there may be tax implications. - Dealing with the issue of whether TTM users need to be members. The schedule will, nevertheless remain unaltered and the new test boxes will go out in late September. PAM2001: The RIPE NCC staff members have attended PAM2000 in New Zealand. This was the first workshop about Passive and Active Measurement. The next PAM workshop will be held in Amsterdam. There is currently a call for papers. The deadline is mid-November. Please see: http://www.ripe.net/pam2001 if you are interested in participating. Routing Information Service (RIS): There is a new collection point at the LINX. In addition, there is a new database machine. The software has been improved. A nice outcome of this project is that the data is used with the asused tool. Plans for 2001: - Move to a regular service - Add more route collectors - Produce daily reports Routing Registry Consistency Check (RRC): This is a new service. Work has started in August. However, due to the lack of manpower it is not fully launched. The idea is to check the Routing Registry for inconsistencies and to compare the Routing Registry data with the RIS data. DASIST - Deployment Assistance and Support for Internet Security Technology is a mouthful and Axel will be glad to hear suggestions for a better name. The issue is that there are varying and new standards when new products are developed and people don't know what to think of these products. The RIPE NCC wants to be a central point to provide assistance for LIRs. The long-term goal is to offer service through: - Training courses - "how to", FAQ - Evaluate products - Produce tools RIR Co-ordination: There is excellent day-to-day contact with the other RIRs. The topics usually include policy co-ordination and IPv6. Together the RIRs evaluate interesting new requests, such as GPRS and IPv6. ICANN/ASO: - Attended ICANN meeting in Yokohama, Japan. - ASO Address Council Selection (to take place at RIPE 38) in the LIR WG - See http://www.aso.icann.org - New ICANN Director (ASO) Dr. Sang Hyun Kyong (for APNIC region) - New contract draft received from ICANN - MoU Amendment - that aligns terms of office of AC members - working on agreement between ICANN and the root server operators RIPE NCC priorities: - Ensure and further improve stable, reliable and high quality services - Respond to members' needs and develop and propose services as needed - Further increase RIPE NCC and RIPE awareness RIPE NCC next steps: - Further automate internal tools and processes - Complete infrastructure overhaul - Extend tools for members - Update and improve external documentation - Migrate to new DB software - Introduce TTM as service - Further formalise ICANN relations Questions: Rob: Tell us about your report on the input of the activity plan. Axel: At the last RIPE meeting I had asked all working group chairs to provide input. This information has been included in the activity plan and is currently on the website. Please have a look and give me your comments. Rob: The activity plan is a document that will be formally approved by the RIPE community at the Annual General Meeting on October 24, 2000. This meeting is only open for members. In order to participate, you need to register before October 9, 2000. Among the items on the agenda are the approval of the activity plan, the budget and the election of another board member. There were no more questions. Report from Randy Bush: Randy ran a security test during the RIPE meeting; the results were alarming, specially with wireless access. He urges all people to use a secure shell, so that login names and passwords do not get exposed to the world. 6. News from ICANN The slides from the presentation can be found on: http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/ Louis Touton, Vice-President of ICANN, began his presentation by explaining the roles of ICANN. ICANN co-ordinates policies relating to the unique assignment of: - Internet Domain Names - Numerical IP Addresses - Protocol Port and Parameter Numbers And also - Co-ordinates the DNS Root Server System Louis explained the philosophy and goals of the Address Supporting Organisation (ASO). - Address Council (three members from each RIR elected by community) - Responsible for recommendations on global addressing policies - Most issues handled in RIR open policy processes - Keeps alert for situations where a segment of overall Internet community is not being heard - Promotes global consistency where appropriate Some of the issues that the ASO deals with are: - Global vs. Local Addressing Policies - Procedures to be followed in IANA Allocations to RIRs - Net 24 Cable-System Assignment Procedures - IPv6 Allocation Guidelines (IETF Papers) - also at RIPE 37 - Recommendations to ICANN on emerging RIRs - Future IP address needs Following an overview of ICANN/ASO Louis gave the microphone to Hans Petter Holen. Hans Petter urged the RIPE community to give input as it is the community that the Address Council members represent. The current Address Council members from the RIPE NCC region are Sabine Jaume, Wilfried W�ber and Hans Petter Holen. Hans Petter told the audience that the three Address Council members need to know what policies are most important for them to focus on. What kinds of policies does the RIPE community want? He urged the audience to approach them, or post issues to the LIR-WG list (to subscribe, send a mail to majordomo(a)ripe.net) Saubine Jaume took the microphone next. She provided an update from the Address Council. The chart can be seen at: http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/touton-amst… m-14sep00/sld007.html Sabine described the policy development process and the operations of the Address Council. Louis gave a review on the activities of IANA. These figures are also included in his presentation. He concluded by informing the audience of other ICANN activities: - New TLDs - At-Large Membership - Root server system enhancements - Operational Transition (root maintenance, Blackhole, InterNIC, .arpa) - Transition extended for up to one year There were no questions. 7. IPv6 Address Allocation Policies - Bob Hinden His presentation can be found at the following URL: http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations Bob introduced himself as the co-chair of the IPng working group at the IEPG and is employed at Nokia. The enormous success of the Internet has created a lot of problems. The problem is that the allocation of IPv4 address is controlled. Customers cannot always be provided with the number of addresses they ask for. This is the main thing IPv6 focuses on. NAT has extended the life of IPv4. Yet there are still problems: - Breaks IP end-to-end problem - Especially Security - Inhibits the creation of new applications - Barrier to mobile IP communications - Mobile phones without phone numbers? Main features of IPv6: - Larger 128-bit Hierarchical Addresses - Supports much larger Internet (it is four times bigger than IPv4) - Allows Embedded IEEE 802 MAC Address for Auto-Configuration - Plug and Play-Auto Configuration - Other - Enables end-to-end security (IPSEC) via Global Addresses - Efficient general header compression - Incremental Deployment IPv6 Addressing: - It is likely that the address space will never be used up - Currently only 15% is initially assigned, 85% is reserved for future growth (this is especially useful for new technology that may be invented) There are different IPv6 Address Types: - Unicast (one-to-one) - Global - Link-Local - Site-Local (for local communications) - Compatible (IPv4, NSAP) - Multicast (one to many) - Anycast (one of a set, but to the nearest) Routing is essentially the same as IPv6: - Uses same "longest-prefix match" routing as IPv4 CIDR - Straightforward changes to existing IPv4 routing protocols to handle bigger addresses News and status: - Many companies are now using and supporting IPv6 (e.g. BSD, Linux, Solaris 8, and Microsoft and others). - Cisco has announced fall 2000 IOS release with IPv6. - Also, the Third Generation Mobile Protocols (3GPP) requires that now all mobile devices that meet the standard now use IPv6. - Finally, three ISPs have announced commercial IPv6 service trials (NTT, IIJ and SURFnet) - IPv6 included in IPSO (Nokia) 3.3 release Bob showed a list of current IPv6 implementation and IPng standards status. Bob reiterated that there is still a lot of work to be done on IPv6. Approximately six months ago, the RIRs asked the IETF for advice on IPv6 prefix assignment. The IPng working group has discussed this issue in July. The IPv6 directorate has developed a recommendation. This recommendation was approved by the IAB and the IESG and sent to the registries as official comments. The IPng working group in the addressing specification (RFC2374 and RSF 2450) specified that sites that have subnetting should be allocated a /48 prefix: - allows 2(16) subnets - most sites, subscribers this should be enough for all time Issue is size of prefix for smaller sites: - /64 for single subnet sites? - Single host? Mobile phones? - Temporary vs. permanent usage? - How to judge usage? IAB - IESG recommendation: - Recommend /48 fixed boundary for all subscribers - Except: - Very large subscribers (receive multiple /48 allocations) - Transient nodes (receive /64) - No interest in subnetting (receive /64) - Consistent with responsible stewardship of the IPv6 address space The main question: is giving a /48 prefix to every subscriber good utilisation of the IPv6 address space? Is this wasteful? No, because IPv6 has a very large address space: - Aggregatable Unicast Address format supports 45 variable bits - Assuming one /48 prefix per person (utilisation is 0.03%) Please see the presentation for the analysis. We are using only one format prefix of IPv6. The other 84% of the address space in unassigned. If in the future the analysis proves to be wrong, there is the option of imposing more restrictive allocation policies. Transient usage (when you are not connected all the time) - Single dialup nodes that prefer transient addresses - /64 prefix is okay - Subscriber who wants static assignment or plans multiple subnet - /48 even if dialup This has also been discussed in the joint session of the IPv6/LIR. The WG agreed with Bob's analysis and the suggestion to assign a /48 to end sites except in the cases listed above. For more information: http://playground.sun.com/ipng http://www.IPv6forum.com http://IPv6.org There were no questions. 8. ETSI and its role in developing standards for the Internet - Christopher Corbett Please find the presentation at: http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations 9. Reports from the Working Groups Anti-Spam Working Group: 60 participants Scribe: Marcel Duran Chair: Rodney Tillotson Update on spam - more collateral spam - more hiding of websites Update on anti-spam - ORBS disrupted Opt-In Lists - EU endorses Opt-In - Document for marketers Reporting spam - SpamCop not focused enough - Directions to end users Reading mail headers - existing documents gathered Future (& next agenda) - SMS, WAP, cell broadcast, real-time spam Question from the audience: How many ISPs want to do something about spam? Rodney: I have not done research on this, but it is my impression that many ISPs want to do the right thing and battle spam. Question from Wilfried W�ber: Are you aware of any activities to make mail headers more creditable, like signing them? Rodney: I am not aware of people signing them. Routing Working Group / Multicast Application Workshop Joachim began with a short report of the Multicast Workshop. He gave a special thank you to Patrick de Muynck. Patrick took the microphone and said that he enjoyed working on this tutorial. He felt full satisfaction because of the participants' enthusiastic reactions. He enjoyed building more multicast awareness. He thanked RIPE in return, as he had been looking for a platform to promote multicast for a while. He enjoyed working at the offices of the RIPE NCC and its staff; in particular Monica Cortes Sack who had really did a great job. Joachim also thanked Cisco for the equipment they had provided. There were 70 participant and it was very much appreciated. Routing WG: 97 participants Scribe: Marek Bukowy Chair: Joachim Schmitz Slot 1 A. Preliminaries C. RADB Update (G.Winters) E. RIS, Status and Plans (A.Antony, H.Uijterwaal) F. Routing Registry Consistency Project (S.Kerr) G. Study of BGP Convergence (A.Ahuja) H. Internet Routing Table Analysis Update (P.Smith) I. RIPE-210 - Updates with contributions from the audience (C.Panigl, P.Smith) J. Promoting European IP Multicast deployment - Introducing the European IP Multicast Initiative (EuMI) (T.Ballardie) RIPE 37: Routing Working Group Slot 2 Notice: joint session with Database WG! B. RIPE Database Software Re-Implementation and Transition to RPSL (A.Robachevski, J.L.S.Damas) Y. Transition Taskforce: RIPE-181 to new RPSL database - what does it mean - intentions - progress A. Preliminaries - introduction - participants' list - volunteering of scribe - RIPE 36 minutes - agenda bashing - actions from earlier meetings Current Actions 31.R1 on RIPE NCC, D.Kessens, J.Schmitz Basic design for an IPv6 IRR project in RIPE NCC activity plan - done - 32.R1 on RIPE NCC, JLS.Damas Prepare draft document on issues of RIPE-181 to RPSL transition http://www.ripe.net/ripencc/pub-services/db/reimp/new-transition-v3.ps - done - 34.R1 on C.Panigl Provide updates to RIPE-178 RIPE-210 - done - but triggered additional discussion 36.R1 on RIPE NCC During the transition phase to the RPSL software - verify with RADB on their test suites for RPSL implementations - co-ordinate with RADB on consistent mirroring of databases (NRTM) - co-ordinate with RADB on consistent whois interface of databases including irrd - ongoing - There were no questions. Netnews Working Group: 18 participants Scribe: Fotis Georgatos Chair: Dave Wilson 1. Admin - Agenda agreed without changes 2. Review of minutes last meeting - Accepted without changes 3. Flowmaps Presentation by Kai Siering of Mediaways - Geographical maps (2D and 3D) are not helpful - Considered other 2D mappings - newsdist, makefeedmap - Now using Cichlid 3D client-server visualisation package - Data is from Innstats based on article count rather than volume - Appearance depends on thresholds below which feeds are ignored http://newsbone.uu.org/RIPE-37/ 4. NHNS Presentation by Daniel Diaz of Satec http://nh.nhns.net/ - Reflecting Usenet hierarchy in DNS - Now in production under usenet.nhns.net - 472 TLHs included To do: - mechanism to check freshness - port sync to Diablo - delegate! - Promote now, report at RIPE 38 with a view to moving toward standardisation Details: http://www.ripe.net/ripe/wg/netnews/ Mailing list: majordomo(a)ripe.net Chair: dave.wilson(a)heanet.ie There were no questions. LIR Working Group: Approximately 100 participants Scribe: Roger Arcilla Chair: Hans Petter Holen Hans Petter Holen gave Stephen Burley the opportunity to report the findings of the May 17 Task Force, because these findings are the most important issues the LIR working group is currently dealing with. The findings and recommendations can be found in the May 17 Task Force Report: http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/ Stephen stated that the proposed goal of the task force was to propose changes to the policies and procedures for address assignments to ultimately be submitted to LIR working group, with the clarification of best practices and tangible steps to achieving those goals. Stephen gave a detailed explanation of the proposed changes and he requested the consensus of the audience. This resulted in a lively discussion. Stephen asked the attendees for their opinion about creating assignment window and no assignment window differentiation. Comment from the audience: Are you proposing to improve service for the big boys on the back of the new LIRs? Stephen: No, that is not the intention at all. As soon as you get any assignment windows you go to the other queue. Hans Petter: It opens up the possibility of specialisation. Axel: I personally endorse the general outlook. I am prepared to find ways of implement the recommendations. If the audience gives its consensus, I am prepared to take more extreme measure to bring down the wait queue. However, some ideas concern policy changes, which I am uncomfortable to change on my own. So we need consensus. I would like to thank the Task Force for their efforts and for the proposed recommendations. Rob: It looks like these are fire-fighting measures. I hope people are working on a more structural solution. Axel: Once the wait queue is down, I think we have measures to keep it down. Wilfried W�ber (Task Force member): There have been lively discussions within the Task Force about before mentioned objections. I like the idea of hostmaster specialisation. It will improve the efficiency of the whole process. Daniel Karrenberg: Have you considered that these recommendations could endanger the industry's self-regulation? If you propose to change a process that has been established for a purpose in the first place. These measures should indeed be only implemented in extreme situation, or else it will affect the industry's self-regulation. Hans Petter: Let's look at this in a historical perspective. I have the feeling that in the past the assignment window was raised a lot quicker. We have consciously lowered the assignment window over the years, but we have not seen the additional resources that are needed. Daniel: I was making the argument from the appearance. We do not want to give people outside the community the impression that we are very light-hearted about this. Stephen: Our proposed measures are a test. If they don't work we will look at other options. Rob: I suggest that the NCC management take this input into consideration. The final decision is the RIPE NCC's, not of this community. I am looking froward to Axel's report in January. Daniele Bovio (Task Force member): I don't think the NCC can start applying these measures without the backing of this community, because it may create problems with the LIRs that are not as involved. Rob: We need more permanent solutions. We will discuss this further at RIPE 38. Joao Silva Damas suggests as an additional measure to delegate more responsibility to the LIRs, for instance for their records in the RIPE DB. Rob: The message is clear. The Task Force has produced a tool kit and it is up to the RIPE NCC to make sensible use of it. Stephen: The Task Force will meet again before the next RIPE meeting with the NCC to see if these measurements are effective. The Task Force is open to any suggestions from the community. Nurani Nimpuno: A lot of the measures have been taken already. You will not yet see the effect, because they are long-term measures. The task Force was set up to come up with solutions for a radical situation. Hans Petter further discussed the ASO nominations. Voting will take place at the next meeting. Due to time constraints, Hans Petter did not get the opportunity to give a report of the other issues the LIR working group is concerned with. However, a detailed presentation is available: http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/ There were no further questions. EIX Working Group: 90 participants Scribe: David Knight Chair: Fearghas McKay <fm(a)st-kilda.org> 1: IX Reports INEX - Irish Neutral IX INXS - Munich IX CIXP - Geneva IX AMSIX - Amsterdam IX LINX - London INX SFINX - French IX VIX - Vienna IX For the next meeting we hope to have Athens & DecIX presenting as well. More IXs are always welcome. 2: IXP switching wish list - Mike Hughes 3: IX Best Current Practices - Nic Lewis 4: Change in WG Charter "To provide a means for the RIPE ISP community to find out about the status and activities of Internet Exchange Points within the RIPE geographical area" This was changed to: "To provide a means for the RIPE ISP community to: - find out about the status and activities of Internet Exchange Points within the RIPE geographical area - develop Best Current Practice documents - provide operational feedback and guidance to vendors of IX related products and services" 5: I-Point Europe - presentation by Annette Nabavi, CEO. This was followed by a lively and wide-ranging community discussion on their plans for a Europe wide network of IXs. The discussion can be continued on the WG mailing list: <eix-wg(a)ripe.net> Question from the audience: there was a comment of developing an exchange object in the database. Fearghas: We are looking at developing this and working on it. We are building a list of the IXs, as to compare what they do. Test traffic Working Group: 40 participants Scribe: Mark Santcroos Chair: Matthew Robinson Agenda A. Administrative stuff B. Presentation by Henk Uijterwaal on current project and future plans. C. Entries for the competition D. AOB C. Entries for the competition - a staggering number of entries - two entries (from the same person) Entry one: TEMPI - Timing and Exact Measurements of the Performance of the Internet Entry two: TRIPS - Time-Related Internet Performance Service Mottos: 1. "The fundamental things apply / As time goes by" (H. Hupfeld from the movie 'Casablanca') 2. "Sum loquimur, fugit invida Aetas" ("While we speak, envious time flies") (Horace) 3. "O temps! Suspend ton vol." ("Oh time! Halt your flight.") ( A. de Lamartine) Options 1. If we like either of the options we can adopt it. 2. Leave the competition open longer. 3. Change nothing AOB - I would like to stand down as chair - One of my colleagues has agreed to take over - Any offers from the working group? There were no questions. IPv6 Working Group: 106 participants Scribe: Vesna Manojlovic Chair: David Kessens Report of the Joint Session Agenda 1 Statement of current policy draft 2. IAB/IESG recommendations 3. Panel discussion 4. AOB Presentation Jo�o http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/ Presentation Bob Hinden IAB/IESG Recommendations on IPv6 Address Allocation - Bob Hinden http://www/ripe/meetings/archive/ripe-37/presentations/ripe-ipv6-hinden/ We do not have real issue on service provider allocation size. Our recommendation is: /48 fixed boundary for all subscribers. This is consistent with responsible stewardship of the IPv6 Address space. Reasoning: - allocation policies influence the deployment; policies should make deployment easy, not slow - renumbering is (still) not painless or automatic Exceptions: - very large subscribers should get multiple /48:s, or /47 - transient nodes (roaming, dial-up) (/64) - explicitly no interest in subnetting Justifications for fixed boundary: - easy to change ISP:s (does not require restructuring of subnets) - straightforward renumbering - compatible with current multihoming proposals - allows easy growth of subscribers - reduces burden of ISP:s and RIR:s to judge customers' needs - no need for details of customers' networks - no need to judge rates of consumption - no scarcity of subscriber's space: no need for NAT - allows single reverse DNS zone (for all prefixes) Conservation: - does this waste IPv6 address space? No. - this distribution had better H ratio (RFC1715) then many others today - still, only one of the Format Prefixes (001) is going to be used; it leaves 85% of total IPv6 space for future usage and possible stricter policy IPv6 Report Agenda: A - Administrative stuff - - appointment of scribe - - list of attendees - - agenda bashing Chair: David Kessens B - Status of 6bone (David Kessens) C - RPSL & IPv6 D - Transition mechanisms E - News from IPv6 Forum (Juergen Rauschenbach) F - Addressing plan of the real world (Juergen Rauschenbach) G - IPv6 connectivity in the terminal room (Monica Cortes) H - IPv6 native exchange points - - INXS (Munich) I - European developments (input from the audience) J - Future plans for the working group (input from the audience) Z - AOB ============ B - Status of 6bone More than 600 sites connected on the 6Bone with 48 countries (David Kessens) C - RPSL & IPv6 (Joachim Schmitz, routing-wg chair) Joachim announced that project proposal has been submitted for the RIPE activity plan for RPSL extensions with multicast and also IPv6. D - IP Transition Strategies Presented by: Alain Durand Co-chair of the IETF NGtrans WG URL: http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/RIPE37/ E - News from IPv6 Forum (Juergen Rauschenbach) [presentation] F - Addressing plan of the real world By Bernard Tuy and Juergen Rauschenbach G - IPv6 connectivity in the terminal room (Monica Cortes, RIPE NCC) If you have IPv6 configured on your laptop, and are connected to LAN here, you can use IPv6. H - v6 native exchange points The list is getting longer There were no questions. DNS Working Group There was report from the DNS working group. Database Working Group: Approximately 50 participants Scribe: Nigel Titley Chair: Wilfried W�ber Logistics: - scheduling problems => joint session with routing - agenda - thanks you to Nigel for scribing Results: Gerald Winters on IRRD/RPS-Dist =>RFC could benefit from revision Randy Bush on globally unique handles =>action on three RIRs to come up with a proposal RIPE does support this activity =>have to work with ARIN, APNIC on CERT/IRT pointer proposal =>propose object to list and deployment scenarios RIPE NCC on RIP =>status and changes =>Task Force proposed and agreed RIP/Migration TF - co-ordinator: Ulf Kieber - find name, a home, members - define mandate - work with the NCC Input from other working groups: CENTR Tech: Review situation with regard to domain 'exodus' and referral =>maintenance of objects is owners' responsibility (confirmed) =>you have to deal with clean-up anyway There were no questions. CENTR/DNR Working Group There was no report from the CENTR/DNR working group. Tools BoF: 106 participants Scribe: Guy Vegoda Chair: Maldwyn Morris Summary: Scope: Tools for Members' use specifically related to RIPE Local IR activities 1. Existing Tools - Asused* - allocation and assignment usage and consistency - Web141/ip-req-robot* - IP Address request check - ASinuse - AS number lookup - Web147 - AS Number request check - Stt* - mail reply template tool * Sources linked from: http://www.ripe.net/ripencc/mem-services/tools/tools.html 2. Future Tools - Secure Web Page: Reg info edit, 141/147 submit, gandalf - PGP for mails to & from hostmaster(a)ripe.net - as-req-robot - public version of RIPE NCC ticketing system Proposed: - Allocation & Assignment Management Tool? - Easier Member access to RIPE Databases? - Scripts to work with proprietary Address Management Systems? 3. Member Tools - Holger M�nzof of UUNET gave a talk on RICE, their ASNumber/ASMacro Management Tool 4. Whither the BOF? - Discuss requirements on mailing list: lir-wg(a)ripe.net Tools BOFs if a lot to discuss, otherwise RIPE NCC to report in LIR working group. 10. - Next RIPE meetings: RIPE 38 Amsterdam 23-26 January, 2001 RIPE 39 Bologna 30 April - 4 May, 2001 11. - AOB There was no other business to discuss. 12. - Close Rob thanked everyone for attending and hopes to meet all the participants again at the next RIPE meeting in Amsterdam on 23-26 January, 2001.

1 0

RIPE Region Hostcount for November 2000
by RIPE Hostcount Maintainer 14 Dec '00

14 Dec '00

Dear All, below is the hostcount for November 2000. The table shows an increase since last month of over 1,000,000 (or 9.1%) to a total of almost 12,100,000 hosts in the DNS in Europe and surrounding areas. The 'it' domain shows the highest increase for November with approximately 550,000 hosts more than in October. Background information and more statistics are available at http://www.ripe.net/hostcount/ - Brief Notes on this Hostcount - - the January data had to be reused for uk due to problems with co.uk. since that time. - the October data had to be reused for lu and il due to zone transfer restrictions at the top level. - no details of the number of no response and AXFR block zones are available for de. - the large increase can mostly be attributed to recovered hosts which were lost to the hostcount in previous months, rather than a structural increase. Please see... http://www.ripe.net/ripencc/pub-services/stats/hostcount/faq.html#axfr - Credits - I would like to thank all people who help me to create the hostcount every month by running a local count: ad Joan Marc Lauga am Hrant Dadivanyan at Gerhard Winkler be DNS-BE Registration Office ch Marcel Schneider cy Vasoula Papapetrou cz Jiri Orsag de Peter Koch dk Morten Christensen eg EUN Hostcount Admin es ES NIC fr Annie Renard gr Dimitris Zisiadis hr Ivan Maric ie Mike Norris il Netvision NOC is Marius Olafsson it Maurizio Martinelli Daniele Vannozzi li Marcel Schneider lt Daiva Tamulioniene lu Alain Frieden mk Goran Muratovski mt Robert Sultana no Havard Eidnes pl Mirek Luc pt Joao Pagaime ro Eugenie Staicut ru Andrey Dobrotsvetov sk Lubos Elias sm Maurizio Martinelli Daniele Vannozzi tr METU Hostcount Admin uk Robert Stone Kevin Hoadley If you have any questions, please don't hesitate to contact me. Kind regards, Lee Wilmot RIPE NCC RIPE DNS Hostcount Previous Count : Sat Nov 18 2000 This Count : Tue Dec 12 2000 CY SOA COUNTED DUPL REAL CHANGE ============================================================== ad 518 2360 725 1635 + 555 ae 2205 44645 2224 42421 - 236 al 74 239 26 213 + 41 am 774 3810 1192 2618 - 10 at 124834 676824 193616 483208 + 27928 az 469 1937 374 1563 + 2 ba 253 2955 545 2410 + 33 be 23531 341116 40923 300193 + 403 bg 1124 21560 2574 18986 + 23 bh 20 108 57 51 - 105 by 220 2661 434 2227 - 31 ch 155263 448562 216334 232228 - 5420 ci 238 842 305 537 + 24 cm 38 314 18 296 + 2 cv 19 128 102 26 + 1 cy 748 7929 791 7138 + 40 cz 79029 234404 73113 161291 + 11637 de 2091335 8132113 6125636 2006477 + 83614 dj 18 59 17 42 + 1 dk 166120 539978 213104 326874 - 16676 dz 51 268 32 236 + 80 ee 6686 44957 5850 39107 + 4503 eg 1716 3361 1170 2191 + 49 er 22 248 22 226 + 221 es 15962 377766 21854 355912 + 22882 fi 19709 584793 51704 533089 + 4937 fr 84440 1273601 155261 1118340 + 23869 ga 24 68 32 36 + 4 gb 2 24 0 24 0 ge 362 2118 685 1433 + 14 gg 986 2067 736 1331 + 44 gh 35 361 48 313 + 267 gi 400 1586 110 1476 - 38 gl 655 2806 328 2478 + 7 gn 7 332 137 195 - 2 gr 17584 129172 17739 111433 + 39836 gw 2 21 1 20 0 hr 3504 24986 9382 15604 + 163 hu 29104 169043 48055 120988 + 47059 ie 14957 130671 19868 110803 - 411 il 13601 133761 33901 99860 0 ir 192 1743 359 1384 + 38 is 5296 58713 20035 38678 + 3522 it 361392 1432452 456735 975717 +551691 je 995 1925 552 1373 + 47 ke 987 5494 728 4766 + 140 kg 402 4557 608 3949 + 358 kz 1595 8850 1567 7283 + 262 lb 1 0 0 0 - 3010 li 4485 9288 5288 4000 + 114 lr 10 0 0 0 0 lt 6007 21137 3496 17641 + 810 lu 4979 15736 3922 11814 0 lv 4192 26064 6424 19640 - 179 ma 1118 3639 1976 1663 - 62 mc 342 874 425 449 + 2 mk 641 2007 464 1543 - 78 ml 26 322 25 297 + 4 mt 889 8274 1586 6688 + 18 ng 274 2087 1400 687 + 255 nl 354791 2106760 583848 1522912 +105426 no 39415 486152 36209 449943 - 13338 om 75 5851 2943 2908 - 2 pl 74383 363096 106229 256867 - 39830 pt 7430 78575 15510 63065 + 2143 qa 22 2250 33 2217 + 2159 ro 8518 58382 11808 46574 + 1293 ru 17059 86858 32495 54363 -202405 sa 1667 5499 1814 3685 + 986 se 53545 658420 65896 592524 +344856 si 3848 26406 5121 21285 - 165 sj 1 0 0 0 0 sk 22240 56315 18409 37906 + 239 sl 7 210 0 210 0 sm 263 1033 178 855 + 7 sn 340 2227 397 1830 + 251 su 1469 25010 1819 23191 + 4575 sy 3 18 9 9 0 tj 114 942 676 266 - 378 tm 466 1878 646 1232 - 117 tn 2 83 58 25 + 2 tr 12254 89140 12994 76146 + 5823 ua 15321 86134 52799 33335 - 707 ug 242 392 149 243 - 502 uk 478844 2502998 825052 1677946 0 va 2 9 0 9 0 yu 6266 19881 4393 15488 + 1007 ============================================================== 87 4349049 21612235 9524100 12088135 +1010565 -1 -1591 ======== +1008974 * 'im' was included in the count last month but not this month due to zone transfer restrictions at the top level. It's total contribution to the number of real hosts was 1591.

1 0

RIPE Region Hostcount for October 2000
by RIPE Hostcount Maintainer 23 Nov '00

23 Nov '00

Dear All, below is the hostcount for October 2000. The table shows a *decrease* since last month of over 160,000 (or %1.5) to a total of around 11,080,000 hosts in the DNS in Europe and surrounding areas. The ru domain shows the highest increase for October with approximately 210,000 hosts more than in September. Background information and more statistics are available at http://www.ripe.net/hostcount/ - Brief Notes on this Hostcount - - the January data had to be reused for uk due to problems with co.uk. since that time. - the September data had to be reused for il, it and nl due to various collection problems. - Credits - I would like to thank all people who help me to create the hostcount every month by running a local count: ad Joan Marc Lauga am Hrant Dadivanyan at Gerhard Winkler be DNS-BE Registration Office ch Marcel Schneider cy Vasoula Papapetrou cz Jiri Orsag de Peter Koch dk Morten Christensen eg EUN Hostcount Admin es ES NIC fr Annie Renard gr Dimitris Zisiadis hr Ivan Maric ie Mike Norris il Netvision NOC is Marius Olafsson it Maurizio Martinelli Daniele Vannozzi li Marcel Schneider lt Daiva Tamulioniene lu Alain Frieden mk Goran Muratovski mt Robert Sultana no Havard Eidnes pl Mirek Luc pt Joao Pagaime ro Eugenie Staicut ru Andrey Dobrotsvetov sk Lubos Elias sm Maurizio Martinelli Daniele Vannozzi tr METU Hostcount Admin uk Robert Stone Kevin Hoadley If you have any questions, please don't hesitate to contact me, but please try the FAQ first... http://www.ripe.net/hostcount/faq.html Kind regards, Lee Wilmot RIPE NCC RIPE DNS Hostcount Previous Count : Fri Oct 13 2000 This Count : Sat Nov 18 2000 CY SOA COUNTED DUPL REAL CHANGE ============================================================== ad 495 1781 701 1080 - 57 ae 2045 44720 2063 42657 + 1393 al 66 197 25 172 + 6 am 762 3512 884 2628 + 96 at 120007 641635 186355 455280 + 11103 az 402 1927 366 1561 + 11 ba 277 2946 569 2377 + 27 be 23581 346326 46536 299790 + 2907 bg 1109 21266 2303 18963 + 3036 bh 55 515 359 156 - 1137 by 207 2638 380 2258 + 30 ch 148996 444583 206935 237648 - 774 ci 227 784 271 513 + 41 cm 38 318 24 294 + 2 cv 17 121 96 25 0 cy 713 7877 779 7098 - 99 cz 77139 218136 68482 149654 - 2259 de 1977558 7694624 5771761 1922863 + 1484 dj 17 57 16 41 + 1 dk 163159 569977 226427 343550 + 11531 dz 55 182 26 156 - 336 ee 6344 44099 9495 34604 + 737 eg 1638 3221 1079 2142 - 57 er 1 5 0 5 0 es 18875 358042 25012 333030 - 22882 fi 19135 577829 49677 528152 + 157 fr 83213 1246665 152194 1094471 + 39797 ga 23 64 32 32 + 1 gb 2 24 0 24 0 ge 332 2028 609 1419 + 61 gg 916 1945 658 1287 + 23 gh 14 55 9 46 - 301 gi 448 2214 700 1514 + 138 gl 632 2781 310 2471 + 15 gn 7 333 136 197 0 gr 11413 82819 11222 71597 - 20557 gw 2 21 1 20 0 hr 3315 24087 8646 15441 + 296 hu 20195 135448 61519 73929 - 28614 ie 14688 130753 19539 111214 + 1030 il 13601 133761 33901 99860 0 im 459 1932 341 1591 + 15 ir 170 1647 301 1346 - 184 is 5095 54237 19081 35156 - 2581 it 179395 626691 202665 424026 0 je 922 1799 473 1326 + 21 ke 913 5328 702 4626 + 3561 kg 369 4172 581 3591 - 45 kz 1519 8485 1464 7021 + 954 lb 963 3925 915 3010 + 611 li 4213 8891 5005 3886 + 114 lr 10 0 0 0 0 lt 5736 20042 3211 16831 + 1718 lu 4979 15736 3922 11814 + 730 lv 3961 25833 6014 19819 + 964 ma 1061 3605 1880 1725 + 25 mc 320 810 363 447 + 9 mk 631 2042 421 1621 + 159 ml 35 326 33 293 + 51 mt 871 8230 1560 6670 + 80 ng 255 1635 1203 432 + 295 nl 320304 1947310 529824 1417486 0 no 39897 503670 40389 463281 + 307 om 71 5845 2935 2910 + 27 pl 72521 402925 106228 296697 + 3444 pt 7229 73531 12609 60922 - 7874 qa 24 139 81 58 - 14 ro 8125 56565 11284 45281 - 170 ru 62584 441299 184531 256768 +211298 sa 1564 4159 1460 2699 + 76 se 33224 284960 37292 247668 -382948 si 3714 26318 4868 21450 - 66 sj 1 0 0 0 0 sk 21012 55236 17569 37667 + 7426 sl 7 210 0 210 + 4 sm 247 1014 166 848 + 13 sn 324 1958 379 1579 + 19 su 1320 20067 1451 18616 - 4562 sy 3 18 9 9 + 1 tj 397 1733 1089 644 - 20 tm 467 1963 614 1349 + 9 tn 2 78 55 23 - 4 tr 9329 81025 10702 70323 + 2023 ua 14076 81377 47335 34042 + 981 ug 221 876 131 745 + 5 uk 478844 2502998 825052 1677946 0 va 2 9 0 9 0 yu 6103 18695 4214 14481 - 126 ============================================================== 88 4005208 20059660 8980499 11079161 -166804

1 0

RIPE Meeting fee increase 2001
by RIPE NCC Meeting Registration 22 Nov '00

22 Nov '00

Dear Colleagues, [ Apologies for duplicate mails ] We would like to inform you that the RIPE meeting fees will increase for the year 2001. The reason for this increase is that the RIPE meetings have become a five day event and the increase will ensure cost recovery. The fees for 2001 will be as follows: RIPE Meeting only including reduction; EUR 300 RIPE Meeting only excluding reduction; EUR 350 RIPE Meeting plus RIPE dinner including reduction; EUR 365 RIPE Meeting plus RIPE dinner excluding reduction; EUR 415 Sincerely, Bettina Schroeder Office Manager RIPE NCC

1 0

RIPE 38 Meeting Announcement
by RIPE NCC Meeting Registration 22 Nov '00

22 Nov '00

Dear Colleagues, [ Apologies for duplicate mails ] It is our pleasure to open registration for the RIPE 38 meeting, to be held from 22-26 January, 2001 at: Hotel Krasnapolsky, in Amsterdam. More information about this meeting and accommodations can be found on this page: http://www.ripe.net/ripe/meetings/current/ripe-38/index.html On-site registration will open on Monday, 22 January, 2001. Please note the following: - - - - To avoid wait queues at the registration desk on-site we encourage pre-payment by credit card. The registration fee for this meeting is EUR 350.00 (this includes refreshments and lunches) and the dinner fee is EUR 65.00. However, if payment is received before 12 January, 2001, the pre-payment cut-off date, you will receive a pre-registration discount of EUR 50.00. Therefore, the fee for attendees paying before the cut-off date is EUR 300.00 for the meeting and 65.00 EUR for the RIPE dinner event. Confirmation of Registration: For your convenience you can register using our secure website at: https://www.ripe.net/cgi-bin/mtgreg (encrypted form) http://www.ripe.net/cgi-bin/mtgreg (non-encrypted form) If you still prefer not to send your credit card number using an encrypted transfer method, we have prepared a fax form. This form is attached to the acknowledgement of your registration. You will receive a second acknowledgement by e-mail as soon your payment has been processed. In addition, you will find the receipt for your payment in your conference envelope. Participants requiring a visa to enter The Netherlands are advised to begin the required procedures as soon as possible. The RIPE Meeting organisers are pleased to provide letters of invitation to those attendees requiring them. Should you have any further questions, please do not hesitate to contact us at <meeting(a)ripe.net>. Kind regards, Sylvana Wenderhold RIPE Meeting Registrations - - - ------------------------------------------------------------------------- %START Do not change the following field %MTG [ ripe38 ] Please add a value in the 'box' area marked between the square brackets (i.e. "[" and "]" s). If values are already supplied between the brackets, please delete all values except one. PART 1 - Registration Note this is what will be used for your badge and for the attendee list, so please take care to fill it in correctly. 1) Your name Please enter your first name only. Please look at the example and refrain from using all capitals. e.g. John , Mary B. %NAME [ ] Please enter your last name next e.g. Doe %SURNAME [ ] 2) Your Organisation/Institution %ORG [ ] 3) Your Organisation's Complete Postal Address e.g. Singel 258, 1016 AB Amsterdam, The Netherlands %ORGADDR [ ] 4) Your Organisation type e.g. Commercial (com), Government (gov), Association (aso), Educational (edu), Other (oth) (please delete all choices except one) %ORGTYPE [ com / gov / aso / edu / oth ] 5) The NCC Reg-id of your Organisation %REGID [ ] (Only if you represent a Local Internet Registry) 6) Your e-mail address %EMAIL [ ] 7) Country code of organisation e.g. IT FR DE %CTRY [ ] 8) Do you want to attend the Newcomers Introductory Talk ? (please delete one option so your choice is in the form) %INTRO-MTG [ no / yes ] 9) Do you want to attend the EOF? (please delete one option so your choice is in the form) %EOF [ no / yes ] PART 2 - Payment of Registration Fees WARNING!! - Note that sending your credit card information via e-mail is in principle not secure. The payment information will be transmitted in clear via e-mail. If you do not want to do this, please leave your credit card details blank in this form, and send them to us by fax. Please do not forget to mention your name and organisation on the fax, so there will be no risk in us getting confused. Our fax number is: +31 20 535 44 45 1) Method of payment. Payment in advance is greatly preferred. (please delete all choices except one) %PMETH [in advance; credit card / at meeting; credit card / at meeting; cash ] ( *NB: please note aforementioned reduction when paying in advance *) 2) Type of credit card (please delete all choices except one) %CTYPE [ VISA / American Express / Mastercard / Eurocard ] 3) Amount to be paid %AMT [RIPE Meeting only incl. reduction; EUR 300 / RIPE Meeting only excl. reduction; EUR 350 / RIPE Meeting plus RIPE dinner incl. reduction; EUR 365 / RIPE Meeting plus RIPE dinner excl. reduction; EUR 415 ] Payment details sent online cannot be processed after, January 12, 2001 with this form. You are welcome to send in your personal data with this form to register, but the actual payment can then only be made at the meeting itself on January 22-25, 2001. ( again: please choose reduction ONLY when paying in advance ) 4) If you are coming to the RIPE dinner, indicate if you want a vegetarian meal. (please delete one option so your choice is in the form) %VEGGIE [ no / yes ] %END

1 0

RIPE NCC Web Services interruption warning
by RIPE NCC Staff 17 Nov '00

17 Nov '00

Dear Members, Today, Friday, 17 November, starting at 12:00pm (CET) we are re-arranging our internal network. From that time on there may be a few brief interruptions of some of our web-based services. Some of the robots might also not respond immediately, however, since mails will be queued there is no need to resend messages if you do not get a prompt auto-answer. In the evening the situation should be stable again. The whois server and the web-interface to the whois server should remain fully operational. If you notice glitches with any of our services please bear with us and try again later. Thanks, Olaf Kolkman Operations Manager RIPE NCC

1 0

ASN Allocation questions
by Graham Burke 20 Oct '00

20 Oct '00

Hi this maillist has always been very helpful in the past so hopefully it can help answer a query i've got. Basically we are a registered Lir with our own /19 range however we have been bought over by another company which also has its own allocation - both /19s are registered in our respective names, We are now in the position where we want to combine the networks and multihon to a couple of upstream providers and have geographically deceided to use one range for the North and the other for the south. I know that we must have at least 2 carriers lined up before applying which is no problem- How do Ripe view this with regard to assigning a single AS number? hope this makes sense, any comments appreciated Many Thanks Graham -- Network System Administrator NSL (Internet) Ltd, 26 Forth Street, Edinburgh, EH1 3LH, UK tel + 44 (0)131 477 8215 fax + 44 (0)131 477 8223 http://www.nsl.net

1 0

RIPE NCC Test-boxes and Test Traffic Measurements Service
by Henk Uijterwaal (RIPE-NCC) 20 Oct '00

20 Oct '00

Dear colleagues, (Apologies for any duplicate mails). The New Projects group at the RIPE NCC is pleased to announce that 25 new test-boxes have been delivered, tested and are ready to be installed at your site. More test-boxes will be assemble as soon as these 25 machines have been shipped. These test-boxes measure delays and losses on the Internet by sending time-stamped packets to each other. A more detailed description is available in RIPE document 209 (see below). At this moment, we are also moving the Test Traffic Measurements from an experimental product to a regular membership service offered by the RIPE NCC. Under this service, the RIPE NCC will operate the test-box and analyze the measurement data for you. With the introduction of this service, 2 restrictions will be removed: * The TTM service will be available to everybody interested, not just the current LIR members, * Any organization can apply for more than 1 test-box, and, for example, install a box at every major PoP. Another change is that you will have to pay for the hardware of the boxes. A test-box currently costs 2750 Euro. This includes the installation costs, but does not include shipping, taxes and import/export duties. The RIPE NCC has been asked to introduce a service fee (of approximately 3000 Euro/Year) for the operation of the boxes. However, for tax-reasons, it is currently not possible to do this. Therefore: * There will be NO service fee for the remainder of 2000 and the first months of 2001. For those of you familiar with the project, it is worth noticing that the hardware of the boxes has been improved. The most important change is in the design of the antenna. In the new machines, the HF-unit has been moved to the antenna, thus eliminating the need for expensive coax cable between the antenna and the test-box itself. Instead, regular CAT-5 cable can be used and cable lengths of (at least) 200 to 300 meters are possible. Also, the boxes have more CPU and memory available and this feature will be exploited in the future do other measurements and analyze the data on the box, thus reducing the time between data-taking and availability of the results. In short, this means: * Easier installation * More freedom in installing the antennas. If you are interested in hosting a test-box, please start by reading the following documents, all available from the test-traffic web-site at http://www.ripe.net/test-traffic/: * RIPE-209, "Providing Test Traffic Measurements as a membership service". This document describes the model the RIPE-NCC will use for selling the test-boxes and the related service for operating them. * RIPE-214, "General Terms to the RIPE-NCC Test Traffic Measurements and Test-Box Purchase Agreement". This document contains the contract used to sell the test-boxes. It is the translation of RIPE-209 into "legalise". * RIPE-168 (Version 2.1 or later). This is the installation guide for the test-boxes. The current document is somewhat outdated, in particular the section on the antenna installation. An update will be published early November. A document that is presently being written is a "2 page glossy summary" of RIPE-209, describing the advantages of hosting a test-box for your manager. If you are interested in hosting one or more test-boxes, please fill out the application sheet at http://www.ripe.net/test-traffic/Host_testbox. If anything is unclear or you have questions that are not answered in the documents, do not hesitate to contact us. The application procedure has become a little more complex than before, but still shouldn't take much more than a few minutes to complete. Sites that have already expressed interest in hosting a box will be contacted in a separate mail. As announced before, we will give the existing test-box hosts a possibility to upgrade your hardware. This will announced, when we are ready to do this, in a separate mail. There is no deadline for applying. Applications will be processed in the order as they come in and processed as soon as our production schedule permits. If you have any questions about this project, please do not hesitate to contact me. Kind regards, Henk Uijterwaal ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(a)ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.535-4414, Fax -4445 1016 AB Amsterdam Home: +31.20.4195305 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ A man can take a train and never reach his destination. (Kerouac, well before RFC2780).

1 0