- lir-wg - mailman.ripe.net

RE: Allocations for "always-on" ISPs
by Sykes, Phil 07 Dec '00

07 Dec '00

>> Is there any way to reduce the address space fragmentation >> due to new non contiguous allocations ? > > I guess you need to use up your allocated block quickly > enough to allow you to get the next contiguous block. :) Also worth noting - your initial allocation can be larger than a /20 if you can convince RIPE that it will be needed quickly, and any further allocation will be of a size representative of how quickly you have used your current address space. Thus, if you burn through a /20 in a week, your next allocation will be somewhat larger. The figures for how quickly you have to go to justify larger address blocks are, I guess, not published. Cheers, Phil Sykes, Network Engineer Cable & Wireless Global Network p: +49 89 92699 204 m: +49 172 89 79 727

1 0

Fw: LACNIC 2000 - OPEN LATIN AMERICAN AND CARIBBEAN MEETING ON IP POLICIES.
by Hans Petter Holen 28 Nov '00

28 Nov '00

From: Raul Echeberria/raul raul(a)lacnic.org To: http://www.icann.org/cgi-bin/mbx/rpgmessage.cgi?adhoc;3A225EB600000180 Date/Time: Mon, November 27, 2000 at 1:16 PM GMT LACNIC 2000 - OPEN LATIN AMERICAN AND CARIBBEAN MEETING ON IP POLICIES. Buenos Aires - December 6th, 2000 The Latin American and Caribbean IP address Regional Registry (LACNIC) invites you to participate in the first Open Latin American and Caribbean Meeting on IP Policies (LACNIC 2000), that will be carried out in Buenos Aires - Argentine - the next 6th December. It will be a fundamental event, where all the interested ones will be able to become active participants of the process. There they will be able to express opinions and to contribute to the development of the policies for the administration of the IP space in our region that will be put into operation from next year. LACNIC is the organization that administrates for the Latin American and Caribbean Region (LAC) the IP address space, Autonomous System Numbers (ASN), reverse resolution and other resources, on behalf of the Internet community. It was created by an agreement signed by the entities that represent most of the Internet players of the region (academic sectors, ISP, carriers, NGOs and national IP registries). This undertaking has the support of the world organization of Internet (ICANN) and of the existing Regional IP Registries (ARIN, RIPE, APNIC). If your are interested in participate and want to obtain further information about this meeting, please refer to the website http://www.lacnic.org/ingles/event.html. It will take place at: Hotel Etoile - Salsn Parms, Roberto M. Ortiz 1835, Buenos Aires - Argentina, Phone: 4805-2626, http://www.etoile.com.ar Raul Echeberria LACNIC Interim Board Chairman raul(a)lacnic.org

1 0

Fw: ARIN VII Meeting Announcement
by Hans Petter Holen 28 Nov '00

28 Nov '00

----- Original Message ----- From: "Member Services" <memsvcs(a)arin.net> To: <arin-announce(a)arin.net>; <ppml(a)arin.net> Cc: <arin-board(a)arin.net> Sent: Tuesday, November 28, 2000 10:05 PM Subject: ARIN VII Meeting Announcement > > ARIN PUBLIC POLICY AND MEMBERS MEETING > April 1-4, 2001 > San Francisco, CA > > The spring 2001 ARIN Public Policy and Members Meetings will be > held April 1-4 in San Francisco. Please note several changes in > the format as a result of suggestions made by members and the public > during previous meetings: > > Sunday afternoon tutorials > Monday morning Public Policy & General Session > Monday afternoon working group meetings > Monday evening entertainment > Tuesday morning working group meetings > Tuesday afternoon Public Policy & General Session > Wednesday morning ARIN Members Meeting. > > A call is issued for ARIN and interested community members to > suggest tutorial topics, as well as discussion and agenda items for > all meetings. Among the working groups expected to meet are: The IP > Allocations Working Group, Community Learning and Education Working Group, > IPv6 Working Group, and the Virtual Webhosting Committee. > Submit your ideas and suggestions by mail to: memsvcs(a)arin.net. > > Anyone interested in presenting a tutorial, leading the discussion > of an agenda item, or presenting new technological information to a > working group or general session is welcome to submit their subjects for > consideration. Past tutorials have included IPv4 registration > procedures, an introduction to IPv6, and how to manage allocations. > Submit your ideas by mail to: memsvcs(a)arin.net. > > In conjunction with this bi-annual meeting, ARIN will host the 2nd > Annual ASO General Assembly. This meeting will be open to anyone > wishing to attend, regardless of whether they choose to participate > in the earlier ARIN meetings. Additional information regarding the > meeting agenda will be forthcoming on the ASO web site. > > http://www.aso.icann.org/ > > Please mark ARIN VII on your calendars now and watch for hotel and > registration information in early January. > > Regards, > > Susan Hamlin > Director, Member Services > > > >

1 0

Draft v 1.0 minutes lir-wg RIPE 37
by Hans Petter Holen 21 Nov '00

21 Nov '00

Please send me your comments, updates & corrections. Many thanks to Roger for providing theese minutes. -hph Minutes of the LIR Working Group session of the RIPE 37 Meeting held at the Grand Ballroom of the Krasnapolsky Hotel in Amsterdam on September 13, 2000 -------------------------------------------------------- Chair: Hans Petter Holen Scribe: Roger Arcilla, RIPE NCC AGENDA 1. Admin scribe, participant list, charter, mailinglists 2. Agenda 3. Meet the RIPE NCC hostmasters 4. RIPE 36 Minutes Actions 5. Report from the RIPE NCC Hostmasters by Nurani Nimpuno 5. Reports from the other registries APNIC (ARIN sends their apologies) (ICANN) (Status of the LACNIC and AFRI NiCs) 6. Report from the Address Council by Hans Petter Holen, Wilfried Woeber, Sabine Jaume 7. Restoring the Transparency by Masataka Ohta 8. Report from the 17th of may Task Force by Stephen Burley 9. PGP for hostmaster(a)ripe.net. (35.4 and 35.5) by Olaf Kolkman 10. Election procedures for the Address Council 11. Presentations of Candidates for the AC election 12. Status of the ICANN ad Hoc group 13. RIPE 174 Abitravtion Philip Bridge, Nextra (Schweiz) AG 14. AOB. Note that issues concerning IPv6 policy will be discussed in a separate session. =========================================================================== 2. Agenda: The Chair, Hans Petter Holen, noted that he has sent the "3rd Draft Agenda LIR-WG 37" shown above to the mailing list <lir-wg(a)ripe.net>. Since he has received no suggestions for changes, it is considered approved by the body. 4. RIPE 36 Minutes: Hans Petter Holen called the attention of the body that the minutes of RIPE 36 has been in the RIPE NCC web site for sometime after the RIPE 36 Meeting in Budapest in May 2000. No one has proposed any changes or corrections. It is declared approved by the body. 5. Report from NURANI NIMPUNO, RIPE NCC Registration Services Manager http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/ Some points NOT in the slide presentation: * Nurani introduced the RIPE NCC Hostmasters one by one. * The May 17 in the name "May 17th Task Force" was after the National Day of Norway when the task force was formed during the RIPE 36 Meeting in Budapest, Hungary held from May 16 to 19, 2000. (The Chair of the LIR Working Group comes from Norway.) * At the end of the slide presentation, Nurani asked if there are any questions from the audience. HANS Petter Holen recalled that during the RIPE 36 in Budapest, the problem of the wait queue was also taken up and proposals presented to solve the problem. He also expressed understanding of the enormous problems faced by Registration Services of RIPE NCC as indicated in the presentation of Nurani. NURANI Nimpuno indicated that RIPE NCC is exerting its utmost with regards the problem of the wait queue; hiring more Hostmasters, patiently training them, and the Software department programming more tools to automate the processes involved in evaluating IP assignment requests. Furthermore, Nurani explained that intense efforts have been made to target the newer LIRs that often are not completely familiar with the relevant policies and procedures by improving documentation, further developing an FAQ and a TIPS page and by creating a Helpdesk Mailbox. The hope is that by making the information more available to the members it will reduce the educational workload on the Registration Services. Nurani also reported that RIPE NCC has had several fruitful discussions with the May 17th Task Force which resulted in many useful suggestions. However, these proposals are waiting for the input from the LIR Working Group before they can be implemented and have an actual effect. She acknowledged that the effects of some of these efforts may not be immediately visible to the membership and indeed the wait queue is still higher than normal. However she did express the confidence that these combined efforts will have its effect in the long term. (APPLAUSE after the presentation and additional statement of Nurani Nimpuno) 5. Report from other Regional Internet Registries: APNIC: Report from GERARD ROSS, Documentation Manager of Asia Pacific Network Information Centre. http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/ Some points NOT in the slide presentation: * APNIC has expanded its staff by more than 3 times during the last 18 months, from 6 staffmembers to 21. * While here for the RIPE 37 Meeting in Amsterdam, he had extensive talks with Paul Rendek (RIPE NCC Communications Officer) for closer coordination and cooperation between APNIC and RIPE NCC. (APPLAUSE after the APNIC presentation) ARIN: MIRJAM KUEHNE (Head of External Relations of RIPE NCC) said that ARIN (American Registry for Internet Numbers) has sent its apologies that it could not send a delegate to the RIPE 37 Meeting. - -------------------------------------- 7. RESTORING THE TRANSPARENCY - -------------------------------------- Presentation with slides by MASATAKA OHTA, Ph. D, Research Associate at the Computer Center of Tokyo Institute of Technology. http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations//address/ind ex.html NOTE: There was a line up of speakers before the microphone and a barrage of questions after Mr. Ohta's presentation, which stimulated a lively and spirited discussion on the ideas he presented. STEPHEN BURLEY: "That is suicide!" [Mr. Ohta's proposal]. "Why? Why limit an already limited resource to a few ISP/providers using IPv4. In other words, use up all the IP's left and force people to use IPv6. Rather like digging up all the coal left in the world to force people to use gas power stations. It is not a practical suggestion and IPv6 will naturally be taken up as systems become ready and services (mobile) demand more space for valid uses. "We are forcing people into a corner in which they have no choice" MASATAKA OHTA: "I am just giving incentive, but if you call it 'forcing people', then Usage Based Allocation, which you are using, is forcing people to use NAT." GUY VEGODA: On the need to speed up IPv6 take up, I'd say that IP preservation is working. It is not currently a huge problem as the amount of space that exists will last well into an era of IPv6. If it ain't broke - don't fix it. Augment it, perhaps, as the IPv6 technology will not replace IPv4, certainly not at the beginning. The number of entities that will refuse to renumber, even in an environment of IPv6 deployment will cause a widespread use of v4 to v6 translation. When the technology has been proved stable and is cost efficient, the rapid depreciation and turnover of routing hardware will mean that it is slowly implemented as part of a natural course of events. Most LIRs, if they have not already, are soon seeing that the lifespan of a technology five or ten years ago is already plummeting to, in many cases, less than three years. Technology will naturally be replaced, and we know that the equipment manufacturers will be moved by market forces to implement IPv6, when the market is ready. Certainly, Juniper as of this moment have not announced any IPv6 equipment. If IPv6 is forced, it'll be a rushed job. We do not want to force the issue. Where the technology is so far unfinished, buggy and incomplete, if we were to deploy it now, you just KNOW that it would cause havoc. Many people want NAT for reasons other than IP preservation. It is a useful form of security, fire-walling and IP masquerading. Many customers want NAT for their own reasons. Therefore, they should be allowed to make use of the technology. Since customers do not want it yet, there is a certain lack of point in forcing LIRs to "switch over". I am telling you now, there is no way that you are going to get every small network in Europe or the world to renumber. In essence, IPv6 will come when its ready, and to begin with, as an extension to IPv4, not a replacement. It is my opinion that because of the safety net that NAT provides, and because of the familiarity of IPv4, that it would always be preferable to suffer a long IPv6 implementation curve, than to suffer the consequences of too hasty an implementation. Another SPEAKER: It is not good to consume IPv4 address space quickly. MASATAKA OHTA: "It will be consumed anyway. What is important is to consume it wisely." Another SPEAKER: We should wait for a while because it's not yet time. MASATAKA OHTA: "It is the time." WILFRIED WOEBER: "My statements are neither in support of the recommendations of Mr. Ohta in the draft, nor are they meant to criticise the draft. I urge everyone in the community to read the draft, as it clearly describes some fundamental issues in today's IPv4-based Internet. "In response to Stephen Burley's comments on fairness, I think that the current approach to IPv4 address distribution is intrinsically unfair, when taking into account that someone has a "Class A" address sitting on a shelf, or some smaller university has got hold of a Class B in the past, while we bug the new kids on the block to demonstrate the need for a, say, /26. "In particular, the thoughts expressed by Mr. Ohta in the draft become even more interesting when seen in the light of the presentations and assertions during Tuesday's (Sept. 12) mobile communications stream at the European Operators' Forum." (APPLAUSE after presentation and Q & A part of Mr. Ohta.) - ------------------------------------------------------------------------- 8. Report from the 17th of May Task Force Presentation with slides by STEPHEN BURLEY of the May 17th Task Force - ------------------------------------------------------------------------- http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/ BEFORE the presentation, Hans Petter Holen, LIR Working Group Chair, explained the background of the formation of the May 17 Task Force, among which is the improvement of services to the membership. AFTER his presentation, Stephen Burley of the May 17 Task Force asked the audience if they have any ideas regarding the proposals in the presentation, and encourage them to present them at the meeting. The proposals on a FLEXIBLE ASSIGNMENT WINDOW and AUTOMATIC APPROVALS of IP address space request after a certain number of days in the wait-queue drew several responses, some of them are quoted below. Several participants and speakers had an extended discussion and exchange of ideas and arguments on the merits and demerits of the proposals. Some called for caution and time to study the matter. Some asked more questions, "Is that the best way to go." Some agreed with the proposals, that the flexible Assignment Window is the way to go forward. Some suggested to get the opinions of RIPE NCC Hostmasters. STEPHEN BURLEY called for a consensus on the proposals the Task Force presented. The Task Force was not set up, he said, to answer all questions; it will act as a catalyst and help in finding solutions to the problems of the community. NURANI NIMPUNO recalled that since the RIPE 36 Meeting in Budapest, some of the proposals from the May 17 Task Force have been implemented, like the setting up of the LIR Help Mailbox, improving documentation, creating a Hostmaster Centre at the RIPE meeting, etc. Radical proposals like a flexible Assignment Window, she said, could be discussed further but would need the approval from the LIR Working Group before it could be implemented by the RIPE NCC. JOHN LEROY CRAIN: (Concerning the proposal of the May 17 Task Force) "The idea of a flexible Assignment Window needs serious reconsideration. Those that have an Assignment Window of 0 should not be raised. The fact that they have a zero Assignment Window shows that they need all their requests reviewed. To audit all of the tagged requests, after the fact, will actually create more work for the Hostmasters and if they turn out to be unjustified assignments then returning the address space is not an option. Commercial bodies cannot take back services from a customer easily. "The issue of Allocations being delayed is technically solvable with ease. Allocation requests are easily identifiable and could be moved to the top of the wait queue. That assumes though that this is what the community wants. "The idea of having Local Internet Registries actively pre-check their data before requesting allocations, keeping their house in order, is one I support. This will lessen the work of Hostmasters and reduce the wait queue." ANA SUSANJ: (RIPE NCC Hostmaster) With regards the proposal for a flexible Assignment Window and also the 5-day automatic approval, I would like to express the concern that this might be open to abuse. It wouldn't be difficult for a Registry to get its Assignment Window raised by sending a few /25 requests for a /23. This way they: 1. increase the number of approvals in their registry records 2. increase the number of tickets in the wait queue 3. from 2, it follows that this can bring us to 5+ days long wait queue 4. from 3, this would take us to automatic approvals 5. automatic approvals would lead to a low wait queue in the beginning, but it follows that from this Hostmasters would have many more auto-approved tickets to audit. ANNELOES VAN AARST: (RIPE NCC Hostmaster) With regard to the proposal for automatic approvals, I would like the Task Force to take security into consideration. As long as the PGP signing for Hostmaster mails is not in place, the only way to check if a request is from a valid contact person - at the moment - is checking the address of the sender manually. It would be very bad if automatic approvals would be sent to non-contacts, or even worse end users. (APPLAUSE after presentation and Q & A session) - ------------------------------------------------ 9. PGP for Hostmaster(a)ripe.net Presentation with slides by OLAF KOLKMAN - ------------------------------------------------ http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/ Question-and-Answer after the presentation: DAVID PRATT: Is it possible to use two Master keys, one as a backup stored off-line and one for regular communication. If one of the Master keys gets compromised then the ability to communicate still exists. OLAF KOLKMAN: It's suggested to store the Master Key off-line and use a slave key in the day-to-day communication. This has the same effect. NOTE: Although the WaveLAN setup was outside the scope of his talk, Olaf issued the warning that WaveLAN is not a trusted environment, that it is a shared medium where passwords in-the-clear are not safe. (APPLAUSE after presentation and Q & A of Olaf Kolkman) - -------------------------------------------------- 10. Election procedures for the Address Council Presentation with slides by HANS PETTER HOLEN - -------------------------------------------------- At this point, the time alloted for the LIR Working Group session was up. It was suggested that important matters not taken up due to lack of time be presented at the Plenary Session.

1 0

Draft v1.0 minutes from ASO meeting at RIPE 37
by Hans Petter Holen 21 Nov '00

21 Nov '00

Please submitt comments, additions & corrections to me. -hph ICANN ASO Meeting Informal meeting to discuss general ASO agenda Tuesday 12 September 2000 / RIPE 37 DRAFT MEETING NOTES Chair: Hans Petter Holen Scribe: Gerard Ross, APNIC Start 17.30 What is global policy? - Discussion of what constitutes global policy and what ASO needs to do, for example should it be rewriting RFC-2050 and publishing it as ASO#1. - Another possible role to discuss is the question of reviewing and aligning regional policies. IPV6Policies - Discussion of the role ASO should play in IPV6 policy and implementation. - WW - gave background to the development and redevelopment of the IPV6 allocation principles - WW said he sees no need for the ASO to get involved with this as the process is going well. It would only be necessary if the regions all disagreed - HPH sees ASO role to make sure IPV6 policy is duly debated in the regions and that IETF and IAB etc talk to RIRs. - Discussion that ASO has responsibility only if other process breaks down - DK added that if 3 RIRs agree on something completely different to IETF then there may still be a need for ASO to step in. Other issues Should ac do anything to speed introduction for IPV6 - DK said this is not within the terms of reference of the ASO. - Discussion that it is not the role of ASO to dictate business model of RIRs - HPH said it could be the ASO's role if the RIRs business model (eg fees) unreasonably influences the implementation of the policy. - WW said ASO not in business of favouring one technology over another. Very reluctant to interfere with RIR business model unless significant complaint from community that access becomes greatly harder on region compared to others - HPH said perhaps ASO should help to present a more consistent statistical picture of address consumption - Question raised as to the border between RIR/ICANN service agreements and global policy. - HPH said maybe ASO should produce annual report with useful figures. DK urged caution about releases figures that have not been comprehensively and accurately gathered. - There was a suggestion it would be OK to publish a preliminary report properly labeled as such and that this would be a good basis for building future better annual reports. Creating such a report gives community info needed for considering whether to start reclaiming address space. - WW stressed that only role of ASO is to document the situation but decisions flowing from the statistics are the responsibility of the RIRs. Emerging RIR - Generally agreed that this issue is global policy. - WW gave background. Said that the document is stable. Not formally submitted to ICANN yet. Plan is to publish and call for comments. - HPH noted that although it is a not an issue in this matter, there needs to be a way of determining whether issues are actually global policy issues or not. Miscellaneous - WW noted that communication within ASO has been improving and is quite good. Reasonably good communications channel with ICANN is now in place. Currently no real open issue that requires attention. Wrap up - Discussion that this format appears to be quite useful for working through issues before taking matters to the plenary. - General feeling from floor that this sort of meeting is of value for getting people with an interest and understanding of this area together. Close 18.30

1 0

Update from Marina Del Rey: New TLDs
by Hans Petter Holen 17 Nov '00

17 Nov '00

a small message from Marina del Rey, a couple of hours a go the ICANN board of directors instructed its staff to enter into negotiations on the following new top-level domains in addition to the three well known .com .net .org .biz JVTeam .info Afilias .name Global Name Registry .pro RegistryPro .museum MDMA .aero SITA .coop NCBA More Information can be found at http://www.icann.org/ ---- If you want to see the presentation I gave to the ICANN public forum on Wednesday morning you may view this video clip: http://cyber.law.harvard.edu/scripts/rammaker.asp?s=cyber&dir=icann&file=ica nn-111500&start=00-51-10&end=01-01 the slides can be found at http://cyber.law.harvard.edu/icann/la2000/archive/presentations/aso-presenta tion.htm Sincerely, Hans Petter Holen ICANN Address Council Chair http://hph.online.no/ASO/

3 3

Proposed change to AS Numbers
by adrian.pauling＠bt.com 17 Nov '00

17 Nov '00

For information. Whilst there has been much work done for IPv6 to establish a new protocol which is less likely to run out of number space, the IETF are now working on updating BGP to increase the possible number of Autonomous Systems. >From the RIPE 37 meeting, there were a couple of statistics people who weren't present should be aware of; Globally 51% of IPv4 address space is allocated, of which 61.8% is actually advertised routes on the Internet (hence 38.9% is 'missing'). Globally AS numbers 30% are assigned, of which 46% are not actually advertised on the Internet. This was the situation in September 2000. http://www.apnic.net/stats/bgp/ may be of further interest. Adrian F Pauling AFP1-RIPE : uk.btent BT Business Services - Information Systems Engineering Tel: +44 1926 851992 Mob: +44 7802 904877 http://www.bt.com -----Original Message----- From: Philip Smith [mailto:pfs@cisco.com] Sent: 16 November 2000 19:55 To: apops(a)lists.apnic.net Subject: [apops] Fwd: I-D ACTION:draft-chen-as4bytes-00.txt Given the current growth in ASN assignments around the globe, this is appropriate reading for everyone in the region. philip -- >To: IETF-Announce:; >From: Internet-Drafts(a)ietf.org >Reply-to: Internet-Drafts(a)ietf.org >Subject: I-D ACTION:draft-chen-as4bytes-00.txt >Date: Thu, 16 Nov 2000 06:27:03 -0500 >Sender: nsyracus(a)cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : BGP support for four-octet AS number space > Author(s) : E. Chen, Y. Rekhter > Filename : draft-chen-as4bytes-00.txt > Pages : 4 > Date : 15-Nov-00 > >Currently the Autonomous System number is encoded in BGP as a two- >octets field. This document describes extentions to BGP to carry the >Autonomous System number as a four-octets field. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-chen-as4bytes-00.txt > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-chen-as4bytes-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv(a)ietf.org. >In the body type: > "FILE /internet-drafts/draft-chen-as4bytes-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <20001115091521.I-D(a)ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-chen-as4bytes-00.txt > ><ftp://ftp.ietf.org/internet-drafts/draft-chen-as4bytes-00.txt> * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request(a)apnic.net *

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

Short update from Marina del Rey
by Hans Petter Holen 16 Nov '00

16 Nov '00

Dear addressing community, The presentations I gave at todays ASO input forum at the ICANN meeting in Marina del Rey can be found at http://home.online.no/~hph/ASO/ They will also shortly appear at the ASO website. As constructively discussed at todays workshop, I would like to use the oportunity to invite you all to actively contribute to the formation of a list of issues that should be of special concern to the addresing comunity over the years to come. My personal thoughts of what needs to be on such a list can be found at the end of my presentation refered above. As also mentioned at todays meeting, we are likely to hold our annual meeting in conjuction with the ARIN VII policy meeting shortly to be anounced, likely to be some time in April. We would also like to see proposals to presentation on issues you would like to present at the upcoming GA, and even at our upcoming regional policy meetings. Please send your suggestions to the list or to any of the address council members. Sincerely, Hans Petter Holen Address Council Chair

1 1

Asused Results by Email
by RIPE NCC Staff 15 Nov '00

15 Nov '00

Dear Members, We are pleased to announce that you can now request that the output of the Asused program, run on your registry's allocations, be sent to a registry contact by email. The Asused program's output shows invalid objects, assigned objects and the usage rate in your allocations. Fixing any problems Asused spots will help speed up the processing of the requests for address space that you send to the RIPE NCC. The output will be sent to the 'e-mail:' contact(s) of your registry, as listed here: http://www.ripe.net/ripencc/mem-services/general/indices/index.html You can request the Asused email from the web page: http://www.ripe.net/cgi-bin/webasused.pl.cgi or by sending a mail with headers 'Subject: SENDASUSED' and 'X-NCC-Regid: <regid>' to hostmaster(a)ripe.net . You can also download and run Asused yourself - see: http://www.ripe.net/ripencc/mem-services/tools/index.html Cheers, Maldwyn Morris Software Manager RIPE NCC

1 0