- ripe-list - mailman.ripe.net

Draft Plenary minutes RIPE 32
by RIPE NCC Meeting Registration 19 Apr '99

19 Apr '99

32nd RIPE Meeting Plenary Minutes - DRAFT RIPE 32 Amsterdam, 27, 28 and 29 January 1999 Plenary Session Chair: Rob Blokzijl Scribe: Naomi de Bruyn 1. Opening 2. Agenda 3. Minutes RIPE 31 4. From the Chair (Rob Blokzijl) 5. Report from the RIPE NCC (Mirjam Kuehne) 6. ICANN a. current status (E. Dyson, interim chairperson of the initial ICANN board) b. progress with the address supporting organisation (ASO) (K. Mitchell, chairman RIPE NCC board) c. questions & discussion d. conclusions & next steps 7. Presentation Bob Aiken (Cisco Systems, Inc.) 8. Presentation Ran Atkinson (@Home Network) 9. Working group reports 10. Next meetings 11. AOB 12. Close - 1. - Opening RIPE chair Rob Blokzijl welcomed everyone to the 32nd RIPE meeting. The plenary session was split into two parts, the first part took place on Wednesday afternoon, the second part on Friday morning. Rob expressed that he was honored and pleased to have Esther Dyson with us, interim chairman of the initial ICANN board. Presented would be status reports on the progress of ICANN and discussed would be the role RIPE NCC plays in forming the address supporting organisation (ASO). - 2. - Agenda The agenda was approved. - 3. - Minutes Plenary Session RIPE 31 The minutes of the plenary session were circulated twice. The minutes were approved. - 4. - From the chair Rob Blokzijl presented a graph on RIPE meeting attendees. The first RIPE meeting took place 10 years ago this year. It used to be a 14 attendees meeting of half a day. During the last meeting in Edinburgh 200 + attendees took part. Two thirds of the attendees have a commercial background. Rob is not sure whether this is good or bad. One of these days we should discuss how to improve our current way of working. The meeting attendees statistics will be made available on http://www.ripe.net/ Lots of receptions would take place this meeting, all sponsored. RIPE had been approached by some companies who were interested in sponsoring the RIPE meeting. After some discussion, it was decided that it was probably better if the registration fee for the meeting stays on the level where it covers the meeting costs. We definitely do not want to turn the RIPE meeting into a commercial gathering. However, the social things are now being sponsored. Keith Mitchell, chairman of the board of the RIPE NCC, had an announcement to make. At the end of last year elections took place for members of the executive board. Wilfried Woeber retired, his place was taken by Mike Norris. On behalf of the board Keith thanked Wilfried. His input to re-structuring the NCC was very important. - 5. - Reports from the RIPE NCC (Mirjam Kuehne) Some additional remarks to the presentation which can be found at: http://www.ripe.net/meetings/ripe/ripe-32/pres/ - Statistics Member sizes have shifted to MEDIUM sized members compared to the figures that were shown last time. Although the NCC is usually quite good at projecting the number of registries, we have more MEDIUMs than expected this time. This could be due to the fact that a significant part of SMALL registries are becoming MEDIUM sized. Financially: our debtors have had some problems getting money to us previously, however the situation is now improving. This year will be the first time we have to take action and take services away. We will stop providing reverse delegation to and close the registries we haven't heard from in a long time. We have asked registries to sign a new agreement. More than 200 registries, however still have to sign. We have sent several reminders but will at some point have to react in a similar way as to people that don't pay. - Services We have had some problems with our mail robots which are now resolved. The overall average waiting time is the same. First version of the IP request syntax checking form was presented in the Local IR working group and can now also be found on our website. The NCC would be happy to receive comments and suggestions. http://www.ripe.net/cgi-bin/web141/web141.pl.cgi Ipv6: we have been working with RIRs on a policy proposal document. Everyone's invited to join the discussions on the IPv6 mailinglist. - 6. - ICANN A) Current status (Esther Dyson, interim chairperson of the initial ICANN board) Rob Blokzijl introduced Esther Dyson. ICANN, or the new IANA has been a discussion point in the past RIPE meetings. In the past there was IANA, the late Jon Postell and his crew kept track of crucial items to ensure proper use of the Internet. This worked in the good old days when the Internet was small. For various reasons in the last two or three years people have been discussing if this role, on the one hand, can be formalized a bit more and, on the other hand, to investigate whether all the interests of the industry were covered properly. It's been a long process and a possible new solution is ICANN (Internet Corporation for Assigned Names and Numbers). The various drafts of statutes and bylaws of this organization have been discussed in the past 12 months. Rob noted that for organizations like the RIPE NCC, who had been invited together with the other RIRs to define their role in this environment, it has not been very easy, because the target kept moving. The ICANN corporation consists of two parts. The board of directors (18 members) reflect the two parts of ICANN. 9 members come from the traditional internet sphere (names, numbers, IETF) each will have a mechanism in place to appoint/nominate 3 directors each to the board. The other 9 come from a whole new sphere: the at large members, they are supposed to give fair respresentation of the whole internet industry and the Internet at large. Esther Dyson began her talk by stating that she felt a bit awkward. She wasn't sure what would be interesting for the RIPE meeting participants to hear about, because there is so much going on. She tried to focuss on the things that were immediately relevant. She reminded us that she couldn't speak for the board itself. She could only openly talk about her own opinions. The board does not want to interfere or re-design things that already work well now. What the RIPE community is doing seems to be working and ICANN does not see any reason to wreck and force us into doing things we don't want to do. ICANN is trying to build a structure that takes its ideas from the bottom up rather than making decisions blindly and then imposing them. Most of the people on the board feel that way. The current version of bylaws that is being worked on now has some things that need to be changed, especially vis-a-vis the at large membership. The board is trying to work within those bylaws. It does not want to build something so rigid that it cannot adjust to changing reality. It also does not want to build something so flimsy that our subjects will pass by quickly. As far as the ASO is concerned, the board wants the RIRs to come up with something that works among themselves and then propose it the board. The RIRs represent a consensus of the technical community concerned with addresses on what we want to propose to the ICANN board when such things need to be proposed. We all want to have a minimum of bureauocracy and a minimum of complexity. And we want a maximum of common sense and good will. The RIRs have to come together and define an ASO that will work for everybody involved. For the record; there is no specific requirement for an at large membership of the ASO in the way that there is for an at large membership of ICANN. The board is concerned that questions and objections from the outside world are answered and dealt with fairly. But, they are not trying to define the structure for us. We are an address organization, not a world wide organization that has to deal with lots of other issues. We have to be open to people that have vested interests in the address business but we do not have to be open to people that have vested interest in content control or general issues of privacy etc. The board is trying to define the area in which we operate. Our 3 board members are concerned with general issues that come up to ICANN. The goal also is to see that decisions are not made blindly by the ICANN board without understanding what is involved. That's why they have this bottom-up notion of consensus. Technical proposals by the ASO are expected to be made in an open and transparent process and are to be posted for a month, for fair public comments. This is the point where the whole at large membership comes in. No-one should come and force us to do something that technically is stupid. The ICANN interest is to have the internet continue to operate effectively in the way that it does. We have to be sure that the technical community, from intelligent/ coherent enough input, can persuade people that what we want to do technically makes sense. - b. - Progress with the address supporting organisation (ASO) (Keith Mitchell, Chairman RIPE NCC board) RIPE NCC progress towards an ICANN address supporting organisation. Keith found this a unique moment where all of us were present and able to discuss things. A number of board meetings and phone conferences have taken/will take place before the proposal is put forward. Principles behind the NCC's involvement in this: we want to ensure the success of ICANN. IANA has kept us supported very well throughout its existence. ICANN is clearly the only show in town. We want to be part of success only and not of failure. The changes that will bring the internet into a more formal, more legally recognizable format are necessary. We want to protect the European interest and want to make sure that the unique voice of the greater European community that is RIPE, is looked after and that no other region is in a position of undue influence on ICANN and the Internet as a whole. We also want to make sure that any structure that is created does not cause the addressing area to be sidelined. Quite a lot of work has been done together with APNIC and ARIN. A lot of progress was made during the Geneva meeting in July. There is no consensus yet to make a common proposal, but we hope to reach that soon. One of the major sticky points in getting out this proposal is a slight difference between the RIRs. The ICANN process needs at large representation, we believe that the existing RIPE mechanism provides an adequate oversight over RIPE NCC, at least in the European area. We address most if not all requirements for at large representation and for open and transparent processes, as far as where the address supporting organization is concerned The other two current RIRs do not have open mechanisms in place that are quite comparable to RIPE. We have the benefit of a long standing tradition of transparencey and openness. We will have to work with the other RIRs on an ASO structure that builds on our tradition for Europe while catering to the situations in other parts of the world. That is the current challenge Another outstanding issue is that there are some changes between the version 5 and version 6 bylaws which limited the voting rights of the supporting organization, vis-a-vis the at large membership. Reason is to stop ICANN becoming captive to particular vested interests. We thought there was some other way of doing this. This is not a good time to try and get this changed, if pushed too hard it's not likely to contribute to the overall good. We have discussed this with ICANN and have agreed to differ on it. One of the messages Keith would like to point out is that there should not be any more suprises. He does not think we will see any more major adjustments. It's more about having a transparent, gradual and open process with regards to changes to the current version of the bylaws. There is a deadline on the 5th of February to submit a proposal for supporting organizations. We are not going to achieve that. We want to get some key members, possibly the chief executives of the registries as well, together and thrash out the remaining issues. When we are happy that we have consensus, the proposal will be published for open debate and consultation. A new mailinglist will be created separate from the local-ir list for this purpose. We are optimistic that we can put the ASO together on a proper footing but there still is some work to be done. We are hoping for good input from the community. Rob noted the following: at some point in the process we will have a document that should be submitted to the ICANN board. The ICANN board has a next meeting early March. The proposal has to be submitted before the 5th of February, however this doesn't mean that this is the last chance to submit. The next ICANN meeting will take place at the end of May, so the next deadline is end of April. Keith continued: Is the address allocation process now in limbo? This is not the case! IANA is still functioning for now as it always did. For the intermediate future, funding has also been secured. Everything is currently working as usual until ICANN is properly set up. We have to work hard to get this proposal ready for the address support organization and we need input from the community. Those people that were not in the room during the RIPE meeting will have the opportunity to read the slides and the minutes, these will be published on the mailinglist. - c. - Questions & discussion The chair welcomed Christopher Wilkinson from the European Commission in Brussels. He was invited to give the point of view of the Commission. Christopher started by wishing Esther and the other ICANN board members, present and future, every success in the development of ICANN. He is grateful to the leadership of RIPE NCC and to CENTR for the work they have put in on these matters, together with the private sector in the panel of participants in the intervening months. We have made some significant steps forward. Important: there is no risk of European interest being marginalized in this affair. The commission has been monitoring this process carefully but fairly passively. It is a matter of consensus building within the Internet community and the private sector operators and users of the Internet in the respective sectors which we have heard so much about. Christopher mentioned a few chapter headings of specific public policy interests. - The general principle of balance is representative international participation. - The respect of internet management for the applicability of laws other than US jurisdiction should the need arise. These are relevant to various trademarks competition privacy laws. Christopher was glad to report that the bylaws version as published on 23rd November 1998 is okay. They have been read/approved by the highest legal EU authorities. The ICANN bylaws provide for advisory committees. The membership advisory committee is already working, there are two or three European members there. The Root server Advisory committee is an important component of the long term stability of the route. The European commission has nothing to do with root servers as such, therefore they observe this with a certain detachment. Christopher then talked about the Governmental Advisory Committee. There are Public policy interests in the stability and development of the internet. It has be recognized, it is not a one-off. The commission has taken very seriously the proposal to create a governmental advisory committee. They, and member states are discussing how they think it should be structured and how they should participate . They had another discussion about this in Brussels the day after the plenary session. The general idea is that in the interests of efficiency the governmental committee will be small. It will be structured on a regional basis and the global regions will sort out internally the way in which 5 or 6 members will be designated perhaps on a rotating basis to represent their points of view in this committee. Perhaps in contrast to some of the opinions in the US, in Europe it was felt from the beginning that the international organizations have a legitimate interest in the field. For different reasons, most obvious ones are the ITU: where there is a major development country link and a significant link regarding technical standards. The IETF has a cooperation agreement with the ITU; the world intellectual property organization, which looks likes it is going to emerge as a significant forum for dispute resolution and in particulary for helping the domain name system to avoid unnecessary trademark conflicts. Christopher believes that our public authorities have taken a legitimate interest, have exercised it responsibly and have reached agreement with US governement and with the ICANN board on a number of critical points. The atmosphere and the legal and political framework is well set now for a successful devlopment in the coming years. Rob noted that the Commission and governments are very active in defining their role in the other part of ICANN, the membership at large. With specific interest in the domain name system. He wanted to know if they have any thoughts on/or interest in the ASO. Christopher stated that he is not the only player in this affair. There are 15 governments and several other departments in the Commission, including the internal market and the competition and the legal parts of the Commission are very interested in the way this evolves. The ECs primary objective is to ensure that a workable consensus emerges. Within that framework there is a wide range in each situation of acceptable solutions. Provided they also fulfill the general criteria of international representation and the applicability of international laws should the need arise. Christopher wanted to make a footnote: he has tried to remain agnostic about the incorporation of supporting organizations because he knows it is a legitimate source of discussion within the private sector. He is increasingly of the view personally that it is more difficult to guarantee the regional international representation and the applicability of international laws through three more separate organizations. It would be easier to rely on the structure and political agreements that have been reached within the ICANN framework. Regarding individual membership, it wasn't actually their idea. They assumed that the membership structure would be through associations with entity corporations and other collective bodies. There is a very reasonable case being made in the US for individual memberhsip of ICANN, but Christopher is not convinced that the same argument is equally strong as applied to each of the supporting orgs. But individual membership has to be large enough and geographically well distributed enough to continue to sustain the diversity of geographic representation we have sought. The major stakeholder/constituency that we have identified, that so far is not fully incorporated in the membership structures, are the public services. From museums to schools, from hospitals to local authorities, and from public services who will conduct electronic c ommerce with their customers in the general public, to the availability of governmental information on public websites. This is a big constituancy, a big group of stakeholders. And the public services are putting a lot of money into developing their webpages acquiring internet connectivity and encouraging members customers and users to enter the internet enthusiastically. There are for example projects to put the whole European museum and art gallery content online, accessable to the general public through the internet. There are copyright and protection issues which are being resolved in that process. Chrisopher thinks we need a public services user constituency in addition to the general structure that has emerged to date. Erik Huizer (member of Internet Architecture Board, IAB and chairman of the IETF WG that is working on the Protocol Supporting Organization) asked Christopher what role the ITU-T should play in his vision. Does he think that the ITU-T should have an equal role in the PSO with regards to the IETF? Christopher replied that what he was referring to explicitly, was that the ITU would be a member of the governmental advisory committee. In Minneapolis a few weeks ago at the ITU annual conference, its members adopted a resolution which instructed the secretary general of the ITU to make sure that the organization and its members were associated with the developing framework of internet governance. On the specific issue of the links between PSO and non-IETF standardization interests, Christopher continued to say that there are other people both in the IETF and ITU who can sort this out. He stated that the last thing the commission wants is to have to arbitrate a dispute, particularly in that area. Erik Huizer (as chair of poisson working group IETF) noted that the working group is discussing what the IETF role should be with regards to ICANN. Whether or not they should participate in the protocal standard organization and how the bylaws of this PSO should be and what should be in there, such that the IETF can commit to participating. One of the problems that the working group runs into is that some people think that IETF should be part of the Protocol Support Association. However others think that some other organizations should be allowed in as well. Another discussion point is: should the IETF have it's parameter registration assigned to ICANN which now is done by IANA. The consensus is (in the poisson WG) that they don't want ICANN to register these parameters. They want to keep them out of this and will, seperately from IETF, give a contract to an organization to register these parameters (ISI) Another question is what to do with IPv6 addresses. IPv4 is a "done deal", this has to go to ICANN. The poisson WG are less comfortable with giving IPv6 to ICANN as well. At the moment it is still not clear where we're headed with the assignment of IPv6 addresses. This has been pointed out in lots of discussion for example in the IPv6 working group. Erik asked for the thoughts of the people present in the plenary session. Did they think the IPv6 addresses should be moved directly with IPv4 to ICANN, or should they be kept out of ICANN at first and get comfortable with how these addresses should be assigned between the registries and the IETF. Then solve the technical problems we run into and only after that hand it over. Wilfried Woeber (Vienna university): He could not provide an answer to this but would rather try to extend the question to even IPv4 address space. He wanted to know where the advantage is to move the top level authority of that business to an emerging organization like ICANN which has not found it's place right now. Wilfried continued that in particular when first reading the proposal it tastes like honey, but then you get a different taste. In the sense that interests are pulled in that have nothing to do with IP address distribution. He was a bit worried and did not see the immediate or medium term benefit of spending the effort. We only get the opportunity to defend our case with technical arguments, however there is a certain level which you cannot go beyond with technical arguments. He personally wondered what we are going to get back for all our efforts? Esther replied that the board of ICANN were not asked to come and do this, they got selected and did it willingly. A unified consensus group has to be formed, that can do this, rather then remain comfortably sitting with their eyes closed while other people are talking about this. It is not a war. Please come sit at the 'discussion-table' while you have the opportunity. Rob noted that we want ICANN to be a success. Just like in the past we have very fruitfully worked together with IANA. Rob himself worked on re-structuring IANA. During that process a lot of things happened which we could not have foreseen two years ago. RIPE NCC should concentrate on it's part of the pie, the ASO. RIPE NCC rightfully demands that we don't want all these strange interest groups that have popped up in the naming area, to artificially re-structure our 10 year way of successful working. Rob again asked for more input on the ASO, because this, at the end of the day, will be done by a couple of people who will meet on a global scale and the people who will represent you are the executives of the NCC whom you elected in office. Erik Huizer stated that he wants to support Rob. He thinks Wilfried is right but more and more people are involved and we can't say "don't do this". The IETF is questioning whether they should participate at all in the PSO. Erik's vison is that they should. We make ourselves insignificant by not being there rather then achieving something. Erik continued to say that there are people out there who want to diminish the influence the PSO and ASO have, as much as possible. He strongly advises Keith and the NCC to write to the ICANN Board, saying that we are working on a proposal. Otherwise a silly proposal might get in before us, as being the only proposal. Esther responded to this by saying that the ICANN do have some criteria, they don't have to take just anything that is being put before them. One criterium is broad representation. She does not know of any other group that has a broad representation that is not one of the 3 registries. There may be small interest groups but they have to prove that they represent a large consensus. She agreed that a letter should be put forward. Daniel Karrenberg (speaking for himself) reported that he shared the concerns that Wilfried had expressed, he didn't want to wave them to the side lightly. On the other side, the things we are doing become more visible, more noticeable, subject to interests that are slowly getting into the RIPE community. This needs to be taken into account, also on a global scale. He thinks we need a place where we can have a public process to define global policies for address space allocation and assignment. This already is fairly well covered in Europe by the open process called RIPE and we have the RIPE NCC, which is nicely controlled by membership. We need some kind of framework to make decisions for the internet on a global level. The only two opportunities are: ICANN, or setting up something different. ICANN has gained so much support from important groups, we should very seriously consider working within ICANN and consider another organization only as an absolute last resort. We absolutely do not want to be a "nail in the coffin" of ICANN. Dfk continued (with his NCC hat on) to react to Erik about the IPv6 issue. The NCC has been working with other RIRs on a policy based allocation scheme, this has been discussed in the Local IR and IPv6 working groups. We have to look into how the NCC will manage to be in a situation for the address space issues where we answer to 2 higher authorities, this requires some more thinking. Because IPv6 is still ermerging we don't know what works and what doesn't yet. Dfk thinks we should not put too heavyweight a process in place for making changes along the way. Maybe we can put this as a challenge to ICANN. There is certainly merit in a more lightweight process to start with. We try to make the guidelines such that we don't give away too much of the address space initially, which would limit any room for manoeuvre that we have. We wrote the procedures such that they can be easily adapted. Dfk continued by stating that there certainly is a requirement of the global political process and global authority of IANA to be more flexible in that field than on IPv4. He wanted to get some feedback from the IPv6 people present at the plenary of what they thought. Mike Norris (HEAnet). Mike referred to the aforementioned membership advisory committee of ICANN and pointed out that it is now up and working. It needs to have all the attributes and hallmarks that are features of ICANN itself, it has to be open and transparent and operate with procedures which result in fairness. Because it has been set up we have an opportunity to experience one of these ICANN committees. People, when they try it out, might be pleasantly surprised. They might see that it is something familiar, it looks like a RIPE Working Group. He noted that pointers to the membership advisory committee can be found on the ICANN server. They are publishing their proposals and activities and obviously membership. There is a pretty lively discussion going on on their mailinglist, which is all part of the process. ICANN is working already and there is an opportunity for everyone to see whether they think it is transparent or fair. If you haven't been part of it, you cannot tell if it is fair. http://www.icann.org Esther Dyson informed us that people can subscribe to the mailinglist People shouldn't just take a look, but also try to join in the discussion. Some of the issues discussed here are: who should be the members; should they be organizations or individuals? How do we figure out if these people are real? There are some places (especially in technical area) where people can contribute a great deal in the discussion. The membership committee consists of 12/13 people, their conversations are archived and published. They have a meeting in Singapore on March 2nd, everyone was invited to come. On address issues people are represented throught the ASO. If you want to be represented to ICANN in general, joining the at large membership and helping to define it is something you can do. Rob: some of the speakers have expressed doubt whether we should be involved at all. He proposed a show of hands. As a result of this Rob commented that it was a fair statement people present at the plenary session want ICANN to be a success. During the coming months there will be several meetings of the subsets of the boards of the various RIRs. The remaining issues will be hammered out and we will come up with a proposal on the addres supporting organization. A report will be given on the soon to be opened mailinglist. <aso-discuss(a)ripe.net> It will be a help to Keith and the boards if they could get feedback on this list on whether we really give support to our leadership shaping team. Rob asked the people present if they supported Keith and our elected board in representing their interests in this. Dfk did not think this was the right question. They have legitimacy of their own by being elected. A better question might be: should they continue making an ASO? Rob continued by asking if the people present thought that the kernel or the whole ASO should be made up of the regional registries and should they play an active and strong role there. No one disagreed. Wilfried Woeber wanted to know if people thought it was useful to have at large representation on both the ICANN level and on the SO level and thus having a division of votes or influences as it is proposed right now. Dfk reminded everyone that it was a departure from our tradition to have a show of hands. He was interested in what Wilfried said but it was too complicated an issue to have a yes or no answer to. Dfk continued: over this whole 2 years of discussion that we have reported on, we have seen that the world has changed. We have seen that on the ICANN level and we have seen the influence of what is now the at large membership. He personally believes it is something we should work with and not debate. On the other side, should we have an organziation where we make the global policies on address space allocations and assignments, by others that are not in this room but may have legimate interest. As far as RIPE is concerned: we are open. If somebody has an interest they can find us. Do we need another incarnation of RIPE making address policy on a global level? Do we have a preference for the hierarchical representative and open on the regional level, or do we have a preference on the global, open for everybody level. This is more consise. Rob stated that RIPE/Europe feels that: a) anyone who has a legitimate interest in address policy should be somehow inside the ASO b) we have a very strong preference to have this organization on a regional level. Esther Dyson replied that there is no statement by ICANN that there specifically needs to be an at large membership within the ASO. There is a statement that it needs to be open and there are various ways to interpret that. If a constituent organization is open and transparent that to her was pretty compelling. She continued to say that she takes it upon herself to visit some other regional registries and that she wants to visit the RIRs more regularly. The people should not have to fly everywhere around the world to be heard. The ASO does have to deal with the at large members on the ICANN level Esther was not sure that there is any need for redundancy. Keith Mitchell concurred with what had been said. For clarification he added that he thought we maybe have three options as far as the ASO structure is concerned. 1) we work from the baseline with the existing regional internet registries organizations (such as RIPE NCC through RIPE for example) and assume that we don't need anything else 2) the ASO is comprised of regional registries plus at large members and the members are selected through regional structures. Same kind of thing but have some RIPE people participate directly in the ASO alongside NCC people participating as a registry. [ the first two we are relatively happpy with ] 3) the third option is that the regional registries have representation in the ASO on a regional basis, but that there is a global at large representation. [ we are a bit unhappy with this option ] There is another knob to turn on the latter two of these proposals, which is to say that there is formal participation representatives in the ASO from the open organizations, rather than just from the registries themselves. However, they possibly have less authority than the actual regional registries represent. That's another option which has been kicked around. We have seen these three options from the RIPE NCCs point of view, in order of importance. Keith wanted everyone to have a think about this. He would find it very useful to receive feedback on it. - d. - Conclusions & next steps Keith stated that as far as he could tell a reasonable degree of support was given for progressing on the present basis. We think we've got our house in order and we want to bring that to ICANN and use that as a model for progression. We have a reasonable degree of confidence in the way that we have progressed with the proposed course of action. He wanted to encourage the people present to take the message back and discuss it in their organizations and see if they are happy with what we are doing. Keith expressed thanks to Christopher Wilkinson from the EU for supporting this process. We are getting there and are going to proceed in the basis that we have, but if anyone has any concerns please let us know. Rob thanked Keith and thanked Esther for being present at this RIPE meeting. - 7. - Presentation Bob Aiken (Cisco Systems, Inc.) - 8. - Presentation Ran Atkinson (@Home Network) - 9. - Working group reports. The chairs from the various working groups gave reports on the working group meetings that were held earlier during the week. Summaries of the meetings, provided by the working group chairpersons, are included here. Full minutes of the working groups will be accessible from: http://www.ripe.net/wg/ Routing WG ---------- Chair: Joachim Schmitz JS335-RIPE Attendees: 74 Scribe: Roman Karpiuk Topics: o Report from the RPSL Tutorial (J. Schmitz) o Report from the IETF (J. Schmitz) o Reports on RPSL deployment - ISI/Qwest and overview (D. Kessens) - RIPE NCC (JLS Damas) o Observations in Internet Routing (A. Akvja) o Reality Checking of the RIPE Routing Registry (J. Schmitz) o Cooperations with MBone WG (K. Kayser) Actions: 29.R1 G. Winters, J. Schmitz, NCC Definition of the IRR and an AUP 31.R1 NCC, D. Kessens, J. Schmitz Basic design for an IPv6 IRR 32.R1 NCC/JLS Damas Prepare proposals for ripe-181 -> RPSL transition issues 32.R1 J. Schmitz Write up project proposal for RIPE RR reality checking. Database security taskforce --------------------------- Topics: o draf-ietf-rps-auth-01.txt Discussion of scope and impact on database users. How much security is needed? o Project for prefix/origin authentication at RIPE Discussion of user interface Actions: 32.DSTF1 Supply new RPSWG milestones 32.DSTF2 Precise definition of prefix/origin authentication 32.DSTF3 Analysis of user impact Remark: these actions have a tight schedule attached to it. Next meetings: During the IETF and RIPE 33 Q: Dfk prefix origin auth. Only limited to database or using database to do something in your routing A: Joachim, two sides we definitely want to make sure that the data is secured so that melicious or incidental attacks are avoided. Crack of .. is something we are thinking about. Joachim feels that these proposals still lack a basis of authority the routing reg is a very suitable means to guide this route of security Q: Dfk, if I'm an ISP where can put in my input. Group is very closed. A: Joachim contact me directly. We will definitely use input from community but for now try to keep task force as small as possible. No-one can hide behind the others. Dfk: not critizing is right otherwise get nothing done. Progressing in getting a specification that's very useful but have to make sure ISPs have input. Joachim agreed that we really need input from public. Wilfried: We were scetching out blue print for use. We felt rather comfortable doing that however adding credibility to routing. Would like to ask ISPs or others with interest please contact us. We are seeking knowledge in this field. Or give us suggestions on who we can approach. Will do a check in the may ripe meeting. We do want to propose and implement something that is useful to the community. Mbone WG -------- Chair: Kurt Kayser MBone-WG short report This time the WG session was jointly operated by the Routing-WG and the Mbone-WG. This due to the low feedback from the poll about topics and desired agenda items. It left lots of room for interpretation and in order not to expand the WG-sessions at RIPE meetings too much, Kurt has suggested integrating Mbone as a sub-topic into the Routing-WG, since all signs point towards this as the right direction. Following the motto: 'Put Multicast there where it belongs: Into the Routers. Let Multicast work where 'normal' routing also happens.' There was some discussion what might be the reason for the low response, as one of Kurt's assumptions was that people have no problems... and might be busy currently migrating from DVMRP based Multicast to PIM or native Multicast routing. It seems to the audience that a migration and no problems where mutually exclusive and people wondered... There was a quick poll initiated by Havard Eidnes who's currently using Multicast. There were some hands raised, but after the question "who's using it with a commercial background", there was just one participant from the Astra-Satellite System that claimed to have an application running production Multicast on a commercial level. Conclusions (drawn by Kurt Kayser) basically were, that the Mbone as we know it is changing dramatically (Actually there's even controversy what it stands for: a) The experimental Multicast-Backbone, or b) the DVMRP based tunnel system) Nevertheless there is connectivity between the 'old Mbone' and the new MBGP/native-Multicast/PIM based network located at NASA-Ames. Naturally this poses a bottleneck for traffic that needs to traverse to reach either side of the network wings. Summary: Current workload of the WG does not justify a full time-slot at a RIPE meeting, therefore Kurt asked the community if there are objections to integrate it into the Routing-WG as a sub-topic. People on the mailing-list asked to keep the Mailing-List itself and the Contacts page on the web for Multicast-enabled network administrator up running. If there's desire and enough demand, there shall be no problem to allocate more time to the WG when there is work to be done. Kurt: IMHO: 'The Mbone as we knew it is vanishing - R.I.P. and YES it was RIP based :-) Kurt: PS: Remember Radio-RIX? Database WG ----------- Chair: Wilfried Woeber Attendees: 93 Scribe: Janne Snabb (RIPE NCC) Important note: freezing development for "old" software!? There are proposals to do that right now. Again we want to ask the community to have a discussion and get people to get up and voice their suggestions/comments. Please contact us. Speak up. Questions? Niall O'Reilly suggested that the date of the next RIPE meeting in Vienna (5-7 May 1999) should be the target date for freezing. Wilfried agreed. We have got most of the things we have asked for. There are no other major projects. Everything is done, there might be a tiny bug somewhere, but it will not stop the process. TLD WG ------ Chair: Niall O'Reilly Attendees: 23 Scribe: Hans Niklasson Number of ccTLD Registries represented: 8 Current Actions Overdue minutes Status of whois referral mechanism All closed Workplan Re-organisation needed Some areas to be merged Explicit reference to liaison DNS-WG NIC FR directory project: demo at Vienna Whois referral Presentation by Joao Damas Current implementation is just what is needed RIPE CENTR Progress update from Fay Howard CENTR ExCo now elected CENTR to incorporate in near future RIPE CENTR project to terminate by 30 June 1999 ICANN/DNSO Fay Howard presented current status Fresh approach from IE Registry ICANN pressing for DNSO proposal by 5 Feb 1999 Questions Relationship RIPE & TLD-WG <--> CENTR New Actions: TLD-32.1 [Chair] Update Workplan TLD-32.2 [Chair] Determine DNS-SEC plans and need for support from DNS-WG TLD-32.3 [Chair] Advise DB-WG of number of registries planning to use RIPE whois code TLD-32.4 [Philippe Renaut] Present NIC-FR directory work at Vienna TLD-32.5 [Mike Norris] Co-ordinate review of RIPE-152 Niall wanted to mention in closing thanks to the NCC support people and especially to Fay Howard. EIX EG ------ Chair: Fearghas Mckay Attendees: 55 Scribe: Martin McCarthy http://www.ripe.net/ Test Traffic WG --------------- Chair: Martin McCarthy Scribe: Daniel Karrenberg http://www.ripe.net/ Local IR WG ----------- Chair: Hans-Petter Holen Attendees: +/- 63 Scribe: Eamonn McGuinness Agenda 1. Admin - scribe - participant list - agenda - meet the RIPE NCC hostmasters - mailinglists 2. RIPE 31 - minutes - actions 3. RIPE Reports & Presentations - Registry report by Paula - IPv6 Assignment and Allocation Policy Document - Auditing Activity - Web interface 4. Reports from other registries - APNIC, ARIN, AfriNIC 6. Statistics 7. Tagging IP adresses 8. I/O with other WGs - DB-GW (Tomorrow 1400) - IPv6 see 5. (Tomorrow 1100) - (ICANN (Plenary today 1400)) 9. AOB - PI address space rules - Policies for IP adresses for Cable networks - Policies on assigning multicas adresses Action Points LIR-WG RIPE 32 - NCC: Web interface to RIPE 141. Announce, receive comments, and make source public - NCC: Get IPv6 Guidelines in place - NCC: write up suggestion on lowering AW from /19 - Guy Davies, UUnet: Start discussion on list on max allocation size and internal aggregation needs for large networks - NCC: Make pretty address statistics charts - Poul-Henning: Present proposal on tagging IP addresses for anti SPAM measures - NCC: IP adresses to cable networks Document current IANA policy and align practice with other IRRs - Everybody: Participate in policies for IPv6 discussion How much IP address space is used ? http://www.caida.org/IPv4space/ Hans Petter Holen also wanted us to think about what we want a chair of a Local IR Working Group to be? Send suggestions to Hans or on the mailinglist. Anti-SPAM WG ------------ Chair: James Aldridge Attendees: 40 Scribe: Raza Rizvi (Rednet) Rodney Tillotson <Rodney.Tillotson(a)ukerna.ac.uk> from janet has volunteerd to become new chair. Wilfried: interested in IP tagging thingy. Pushed it to the LIR people and anti-SPAM WG. In which perspecive want to pursue. As soon as anti spam has found their view in this. And then database will be happy to implement it. James anti-SPAM is the place to further discuss it. Wilfried will do that now and then take it from there.. Netnews WG ---------- Chair: Felix Kugler (reported by Gerhard Winkler) Attendees: 19 Scribe: Antony Antony (RIPE NCC) The meeting focused on the groupsync project which aims to establish an improved system to maintain Usenet group lists. A prototype was ready right before the meeting. Betatesting is planned for the period up to RIPE33 with the goal to have a first stable version at that time and to identify helpful modifications. Action summary: closed: A30.N5 groupsync prototype by Jonas Luster, done. A30.N4 flowmaps - whois data support (unclear whether required at all). open: A30.N3 flowmaps - visualization of news traffic flows A31.N1 fill groupsync server with newsgroup data new: A32.N1 test groupsync prototype Details: the minutes are available online on http://www.switch.ch/netnews/wg/ripe32/ripe32.nnwg-minutes DNS WG ------ Chair: Ruediger volk Attendees: 62 Scribe: Lee Wilmot Documents: dummies guide specific reccommendations general bLP - SDA Statistics (gathering), errors obeserved, quality Issues of upcoming software DNS sec upcoming Non problems Y2K IPv6 WG ------- Chair: David Kessens <david(a)qwest.net> Attendees: 120 Scribe: Sabrina Waschke Experimental 6bone network growing fast (exponential) - new initiative for first production backbone: 6ren for more info talk to David. Minor changes for inet6num object proposed by the ripe ncc - discussion of ipv6 allocation guidelines -> discussion will be done by ipv6 working group (mailinglist) please subsribe to mailinglist for your input. Proposal was written by the RIRs (not just ncc) Paula gave presentation on draft - Guidelines are considered to be on the restrictive side. - First goal should be routability not conservation Thomas Trede asked if there is a co-chair. Jan czmok can be co-chair but he wasn't there. Remark: Vesna Manojlovic (RIPE NCC) please subscribe to mailinglist. (moderators ) - 10. - Next Meetings RIPE 33 May 1999 Vienna RIPE 34 Sep 1999 Amsterdam RIPE 35 Jan 2000 Amsterdam RIPE 36 May 2000 Budapest RIPE 37 sep 2000 Amsterdam The chair reminded us all of the hotel situation in Vienna. On the RIPE NCC website you can find the recommendation to book asap. Some hotels are mentioned there. Have a look and book early! - 11. - AOB There was no other business. - 12. - Close The chair thanked everyone for coming and also thanked the RIPE NCC staff for organising the meeting. The chair also thanked the sponsors (Tachyon, Skycache and Carrier1) for the receptions they offered. It certainly improved networking.

1 0

2nd reminder: RIPE 33 in Vienna
by RIPE NCC Meeting Registration 19 Apr '99

19 Apr '99

Dear Colleagues, [ Apologies for duplicate mails ] We would like to remind you that the registration for RIPE 33 in Vienna: 4 - 7 May 1999, has been opened. Please note that pre-payment facilities end this week, on Friday 23rd April. Please send in your registration/payment details as soon as possible if you wish to benefit from the discount. More information about the meeting and the registration form, can be found on this page: http://www.ripe.net/meetings/ripe/mtg.html The agenda of the 33rd RIPE meeting is attached to this mail. Should you have any further questions, please do not hesitate to contact us at <meeting(a)ripe.net>. Kind regards, Naomi de Bruyn RIPE Meeting Registrations ============================================================================= Meetingrooms in use at the Palais Auersperg: -------------------------------------------- R K = Rosen Kavalier K R = Kronprinz Rudolf M T = Maria Theresien Tuesday 4th May --------------- R K K R MT 9:00 +----------+----------+----------+ 10:30 | EOF | | IPv6 tut | +----------+----------+----------+ 11:00 +----------+----------+----------+ | EOF | RPSL | IPv6 tut | 12:30 +----------+----------+----------+ 14:00 +----------+----------+----------+ | EOF | RPSL | IPv6 tut | 15:30 +----------+----------+----------+ 16:00 +----------+----------+----------+ 16:00+----------+ | EOF | RPSL | IPv6 tut | | Intro | 18:00 +----------+----------+----------+ 17:00+----------+ Wednesday 5th May ----------------- R K K R M T 9:00 +----------+----------+-----------+ 10:30 | LIR | | EIX | +----------+----------+-----------+ 11:00 +----------+----------+-----------+ | LIR | Routing | EIX | 12:30 +----------+----------+-----------+ 14:00 +----------+----------+-----------+ | IPv6 | TLD | DNS | 15:30 +----------+----------+-----------+ 16:00 +----------+----------+-----------+ | IPv6 | TLD | DNS | 17:30 +----------+----------+-----------+ Thursday 6th May ---------------- R K K R M T 9:00 +----------+----------+-----------+ 10:30 | DB | Netnews | SPAM | +----------+----------+-----------+ 11:00 +----------+----------+-----------+ | DB | Netnews |Test Traff.| 12:30 +----------+----------+-----------+ 14:00 +---------------------------------+ | Plenary | 15:30 +---------------------------------+ 16:00 +---------------------------------+ | Plenary | 17:30 +---------------------------------+ Friday 7th May -------------- R K 9:00 +---------------------------------+ | Plenary | +---------------------------------+ 11:00 +---------------------------------+ | Plenary | 12:30 +---------------------------------+ 14:00 +---------------------------------+ | Plenary | 15:30 +---------------------------------+ 16:00 +---------------------------------+ | | 17:30 +---------------------------------+

1 0

IPv6 tutorial
by David Kessens 15 Apr '99

15 Apr '99

Hi, I promised earlier that I would try to organize a tutorial regarding IPv6 for the next RIPE meeting. After sending them a request, Marc Blanchet and Florent Parent, both at Viaginie Inc., CA, were willing to give such a tutorial. The tutorial is scheduled for tuesday, May 5. Attached below is a description. David K. --- ============================================== IPv6 primer IPv6, the next generation IP protocol, is designed to improve scalability, security, ease-of-configuration, and network management. The tutorial will give a brief overview of IPv6 protocol including address architecture, autoconfiguration and management (DNS, routing). We will also discuss about the transition mechanisms have been designed to ease the upgrade to IPv6. An overview of the configuration for routers and workstations with examples will be given: Cisco, FreeBSD, Sun, Windows NT, as well as the Merit MRTd. The tutorial will go over the different steps required to get connected on the 6BONE, including address configuration, routing and the 6BONE registry. The tunnel server is a service that provides a simple way to get connected to the 6BONE. The architecture of the server and examples will be presented. A description of the 6REN initiative, an IPv6 transit service, and the 6TAP project, a service for interconnecting early IPv6 networks, will be presented. This tutorial is not focused on the theory behind the protocol but more on the practical considerations for using and deploying IPv6, so the intended audience is tcp/ip engineers, architects and network admins that want to understand IPv6 and to be able to deploy it. The tutorial will be presented by Marc Blanchet and Florent Parent, both at Viaginie inc., a consulting firm working on network architectures, security and internationalization. Viaginie inc. is responsible with Dalhousie University of the deployment of IPv6 in Canada. Viaginie 6bone site has been on the 6bone since more than 2 years now, is one of the backbone sites and maintains IPv6 links with many international organisations ; it also runs the mirror of the 6bone whois server, the IPv6 mirror of the www.6bone.net, www.6ren.net sites. Viaginie also designed a tunnel server implementation available at http://www.freenet6.net. Marc Blanchet wrote a internet-draft on a flexible method for IPv6 address assignments, soon to be published as an informational RFC and is the author of the concept of the 6tap exchange. ---

1 1

RIPE 33 Meeting in Vienna - Reminder
by RIPE NCC Meeting Registration 12 Apr '99

12 Apr '99

Dear Colleagues, [ Apologies for duplicate mails ] We would like to remind you that the registration for RIPE 33 in Vienna: 4 - 7 May 1999, has been opened. More information about this meeting and the registration form, can be found on this page: http://www.ripe.net/meetings/ripe/mtg.html On-site registration will open on Tuesday, 4th May at 09:00. [ please note that the starting time for the RPSL tutorial on Tuesday has changed, more information about this can be found on our website ] Confirmation of Registration: For your convenience we have prepared a fax form for sending your credit card number. This form is attached to the acknowledgement of your registration and we encourage you to use it when possible. 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. For more details please see: "RIPE Meeting Fees and Refunds" at: http://www.ripe.net/meetings/ripe/meeting-int.html Should you have any further questions, please do not hesitate to contact us at <meeting(a)ripe.net>. Kind regards, Naomi de Bruyn RIPE Meeting Registrations ============================================================================= Registration is also possible and easier online at: http://www.ripe.net/meetings/ripe/form.html %START Do not change the following field %MTG [ ripe33 ] 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. e.g. John , Mary B. %NAME [ ] Please enter your surname next e.g. Doe %SURNAME [ ] 2) Your Organisation/Institution %ORG [ ] 3) Your Organizations Complete Postal Address e.g. Singel 258, 1016 AB Amsterdam, The Netherlands %ORGADDR [ ] 4) The NCC Reg-id of your Organisation %REGID [ ] (Only if you represent a Local Internet Registry) 5) Your e-mail address %EMAIL [ ] 6) Country code of organisation e.g. IT FR DE %CTRY [ ] 7) Do you want to attend the Newcomers Orientation Talk ? (please delete one option so your choice is in the form) %INTRO-MTG [ no / yes ] 8) Do you want to attend the EOF Tutorial ? (please delete one option so your choice is in the form) %EOF-TUTOR [ no / yes ] 9) Do you want to attend the RPSL course ? (please delete one option so your choice is in the form) %RPSL-COURSE [ 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, you will be sent a fax form with the acknowledgement mail that we encourage you to use. 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 ] 3) Card number %CCNUM [ ] 4) Expiry date %CCDATE [ ] 5) Card holders name %CCNAME [ ] 6) Card holders address %CCADDR [ ] 7) Amount to be paid %AMT [RIPE Meeting only incl. reduction; EUR 120 RIPE Meeting only excl. reduction; EUR 170 RIPE Meeting plus RIPE dinner incl. reduction; EUR 175 RIPE Meeting plus RIPE dinner excl. reduction; EUR 225] Your payment cannot be processed after April 23rd, 1999 with this form. You are welcome to send in your personal data with this form to register, but the payment can only be made at the meeting itself on May 4th, 5th, 6th and 7th 1999. ( again: please choose reduction ONLY when paying in advance ) %END

1 0

RIPE Region Hostcount for March 1999
by RIPE Hostcount Maintainer 08 Apr '99

08 Apr '99

Dear All, below is the hostcount for March 1999. The table shows an increase since last month of over 215,000 (or 2.7%) to a total of almost 8,430,000 hosts in the DNS in Europe and surrounding areas. The be domain shows the highest increase for March with approximately 72,000 hosts more than in February. Background information to the hostcount and more statistics are available at http://www.ripe.net/statistics/hostcount/ - Brief Notes on this Hostcount - A problem with the data collection for uk meant that we had to use the same data as last month for that TLD. New this month is a beta version of new statistics generated from the hostcount data, (link from the URL given above). These show, for example, that almost all of the new hosts in be came within the 34 zones with 1000+ hosts. - Credits - I would like to thank all people who help me to create the hostcount every month by collecting data locally: ad Joan Marc Lauga at Gerhard Winkler be DNS-BE Registration Office ch Marcel Schneider cy Vasoula Papapetrou cz Jiri Orsag de Peter Koch dk Morten Christensen es Susana Gayo fr Annie Renard gr Dimitris Zisiadis hr Ivan Maric ie Mike Norris il Shuki Kenan is Marius Olafsson it Maurizio Martinelli Daniele Vannozzi li Marcel Schneider lt Daiva Tamulioniene mk Goran Muratovski mt Robert Sultana no Havard Eidnes pl Mirek Luc pt Armando Domingues ro Eugenie Staicut ru Andrey Dobrotsvetov sk Lubos Elias sm Maurizio Martinelli Daniele Vannozzi tr Yener Yigit 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 : Fri Mar 5 1999 This Count : Wed Apr 7 1999 CY SOA COUNTED DUPL REAL CHANGE ============================================================== ad 279 988 381 607 + 1 ae 374 18208 505 17703 - 547 al 13 130 13 117 - 44 am 149 1253 176 1077 + 245 at 34260 242882 67543 175339 + 5457 az 83 434 42 392 + 29 ba 89 887 87 800 + 33 be 15514 332407 33093 299314 + 71759 bf 10 372 76 296 + 10 bg 749 14801 1271 13530 + 565 bh 29 1536 126 1410 + 4 bj 12 89 13 76 - 3 by 160 1315 266 1049 + 30 cf 2 8 0 8 0 ch 57438 330595 72433 258162 - 3013 ci 114 694 70 624 - 8 cm 7 168 3 165 + 1 cv 10 33 16 17 + 1 cy 568 4788 152 4636 - 90 cz 27493 110819 18231 92588 + 4827 de 287855 2253602 718466 1535136 + 15722 dj 3 11 2 9 0 dk 74273 381763 69691 312072 + 1675 dz 22 137 14 123 + 42 ee 2814 27739 2034 25705 + 545 eg 959 2836 343 2493 - 65 er 1 0 0 0 0 es 13583 334566 17687 316879 + 15717 fi 11056 484026 16819 467207 - 747 fo 208 909 52 857 + 4 fr 35136 633661 70747 562914 + 68241 ga 14 49 25 24 + 7 gb 2 27 0 27 0 ge 58 778 27 751 - 91 gg 184 258 173 85 + 8 gh 16 354 58 296 + 3 gi 117 656 316 340 + 11 gl 247 2532 479 2053 + 7 gn 2 9 0 9 + 1 gq 6 12 7 5 0 gr 7338 62251 6012 56239 + 2315 gw 2 21 1 20 0 hr 2392 16805 3651 13154 + 342 hu 8231 114453 14280 100173 - 1367 ie 7307 68585 7467 61118 - 181 il 9286 149230 27519 121711 + 2031 im 1 0 0 0 - 95 iq 1 0 0 0 0 ir 74 942 84 858 + 57 is 2013 26575 1528 25047 + 272 it 54694 424326 64939 359387 - 67291 je 180 192 86 106 + 8 jo 418 1113 414 699 + 25 ke 343 2254 638 1616 + 216 kg 58 1795 143 1652 + 18 kz 411 3052 582 2470 + 59 lb 1031 3292 847 2445 - 1481 li 969 2184 890 1294 + 109 lr 5 0 0 0 0 lt 1725 12148 1027 11121 + 426 lu 2175 9604 1341 8263 + 430 lv 1338 19594 3732 15862 + 413 ma 381 2515 461 2054 + 5 mc 235 621 193 428 - 2 md 580 1401 379 1022 + 536 mk 450 1595 213 1382 + 33 ml 17 198 8 190 + 2 mt 357 5821 452 5369 + 3749 ne 17 133 6 127 + 27 ng 196 671 459 212 + 27 nl 67030 758201 76730 681471 + 66532 no 23698 351345 20552 330793 + 2107 om 24 2898 10 2888 0 pl 22200 196879 44667 152212 + 4343 pt 7885 72599 10337 62262 + 2449 qa 28 862 8 854 + 236 ro 2676 31410 3974 27436 + 7080 ru 19161 241926 57545 184381 + 3660 sa 292 1595 480 1115 + 393 se 33644 458905 38331 420574 + 8409 si 3862 25096 2950 22146 - 771 sj 1 0 0 0 0 sk 7647 31256 6810 24446 + 874 sl 7 73 0 73 + 73 sm 81 340 15 325 + 15 sn 77 930 236 694 + 16 su 1440 29752 1805 27947 - 6 sy 4 1 0 1 0 td 6 8 4 4 0 tj 140 784 548 236 + 21 tm 1641 2943 1818 1125 - 98 tn 1 68 44 24 + 3 tr 7711 61124 5912 55212 + 723 ua 2522 34338 12508 21830 + 561 ug 17 136 10 126 + 2 uk 165451 1819214 307118 1512096 0 uz 162 661 273 388 - 16 va 2 8 0 8 0 ye 31 40 14 26 + 1 yu 2432 10089 1288 8801 + 1166 ============================================================== 100 1036007 10251184 1822776 8428408 +218793

1 0

RIPE NCC office closed on Friday 2nd April and Monday 5th April
by RIPE NCC Staff 01 Apr '99

01 Apr '99

Dear Colleagues, [ Apologies for duplicate mails ] Please note that the RIPE NCC office will be closed on: Friday 2nd April and Monday 5th April, due to public holidays. This means that there will be no-one in the office on those days to reply to your e-mails and phonecalls. The office will be open again on Tuesday 6th April. Kind regards, Naomi de Bruyn RIPE NCC

1 0

RIPE 33 Meeting Announcement
by RIPE NCC Meeting Registration 17 Mar '99

17 Mar '99

Dear Colleagues, [ Apologies for duplicate mails ] It is our pleasure to announce that registration for the 33rd RIPE meeting is open. RIPE 33 will be held from 4 - 7 May 1999 at: Palais Auersperg, Vienna, Austria and is hosted by the Vienna University Computer Center (VUCC). The RIPE 33 registration form and meeting information can be found at: http://www.ripe.net/meetings/ripe/mtg.html On-site registration will open on Tuesday, 4th May. Please note: - 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 170.00 (this includes refreshments and lunches) and the dinner fee is EUR 55.00. However, if payment is received before the 23rd April 1999 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 120.00 for the meeting and 55.00 EUR for the RIPE dinner event. Confirmation of Registration: For your convenience we have prepared a fax form for sending your credit card number. This form is attached to the acknowledgement of your registration and we encourage you to use it when possible. 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. For more details please see: "RIPE Meeting Fees and Refunds" at: http://www.ripe.net/meetings/ripe/meeting-int.html Participants requiring a visa to enter Austria 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, Naomi de Bruyn RIPE Meeting Registrations ============================================================================= Registration is also possible and easier online at: http://www.ripe.net/meetings/ripe/form.html %START Do not change the following field %MTG [ ripe33 ] 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. e.g. John , Mary B. %NAME [ ] Please enter your surname next e.g. Doe %SURNAME [ ] 2) Your Organisation/Institution %ORG [ ] 3) Your Organizations Complete Postal Address e.g. Singel 258, 1016 AB Amsterdam, The Netherlands %ORGADDR [ ] 4) The NCC Reg-id of your Organisation %REGID [ ] (Only if you represent a Local Internet Registry) 5) Your e-mail address %EMAIL [ ] 6) Country code of organisation e.g. IT FR DE %CTRY [ ] 7) Do you want to attend the Newcomers Orientation Talk ? (please delete one option so your choice is in the form) %INTRO-MTG [ no / yes ] 8) Do you want to attend the EOF Tutorial ? (please delete one option so your choice is in the form) %EOF-TUTOR [ no / yes ] 9) Do you want to attend the RPSL course ? (please delete one option so your choice is in the form) %RPSL-COURSE [ 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, you will be sent a fax form with the acknowledgement mail that we encourage you to use. 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 ] 3) Card number %CCNUM [ ] 4) Expiry date %CCDATE [ ] 5) Card holders name %CCNAME [ ] 6) Card holders address %CCADDR [ ] 7) Amount to be paid %AMT [RIPE Meeting only incl. reduction; EUR 120 RIPE Meeting only excl. reduction; EUR 170 RIPE Meeting plus RIPE dinner incl. reduction; EUR 175 RIPE Meeting plus RIPE dinner excl. reduction; EUR 225] Your payment cannot be processed after May 23rd, 1999 with this form. You are welcome to send in your personal data with this form to register, but the payment can only be made at the meeting itself on May 4th, 5th, 6th and 7th 1999. ( again: please choose reduction ONLY when paying in advance ) %END

1 0

Current Vacancies at the London Internet Exchange
by Keith Mitchell 11 Mar '99

11 Mar '99

The London Internet Exchange (LINX) is a not-for-profit association operating the UK national Internet Exchange Point, and provides service to and represents over 60 of the largest Internet Service Providers in the UK and Europe. As part of the growth of the LINX, there is a requirement to fill several positions. These are based at the LINX office in central Peterborough (Cambridgeshire), though all positions will require frequent travel to London. This is an opportunity to be at the heart of the UK Internet industry, with a unique neutral perspective. Candidates are sought for 3 of the following roles: - Operations Manager - Regulation Officer - Network Engineer - Sales and Marketing Executive (exactly which positions are filled will depend on the balance between the skills of the applicants and existing employees). We regret we are unable to offer assistance obtaining any work permits or visas candidates may require to work in the UK/EU. For more information, see: http://www.linx.net/vacancies.html Applications should include a full CV, and should be sent preferably as hardcopy to: The London Internet Exchange Geneva House 3 Park Road Peterborough, Cambs. PE1 2UX England, UK Fax: +44 1733 353929

1 0

RIPE Region Hostcount for February 1999
by RIPE Hostcount Maintainer 06 Mar '99

06 Mar '99

Dear All, below is the hostcount for February 1999. The table shows a (tiny!) increase since last month of over 8,000 (or 0,1%) to a total of around 8,200,000 hosts in the DNS in Europe and surrounding areas. The uk domain shows the highest increase for February with approximately 44,500 hosts more than in January. - Brief Notes on this Hostcount - The increase this month is so small because the situation in fr has again changed dramatically. We estimate that the several huge zones which were newly included last month were not countable this month, resulting in the loss of around 160,000 hosts. - Other Ways to Obtain the Hostcount - All this data can also be found at http://www.ripe.net/statistics/hostcount/ The translation of the country codes can be found at ftp://ftp.ripe.net/iso3166-countrycodes - Credits - I would like to thank all people who help me to create the hostcount every month by counting hosts locally: ad Joan Marc Lauga at Gerhard Winkler be DNS-BE Registration Office ch Marcel Schneider cy Vasoula Papapetrou cz Jiri Orsag de Peter Koch dk Morten Christensen es Susana Gayo. CSIC-RedIRIS fr Annie Renard gr Dimitris Zisiadis hr Ivan Maric ie Mike Norris il Shuki Kenan is Marius Olafsson it Maurizio Martinelli Daniele Vannozzi li Marcel Schneider lt Daiva Tamulioniene mk Goran Muratovski mt Robert Sultana no Havard Eidnes pl Mirek Luc pt Armando Domingues ro Eugenie Staicut ru Andrey Dobrotsvetov sk Lubos Elias sm Maurizio Martinelli Daniele Vannozzi tr Yener Yigit 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 : Thu Feb 4 1999 This Count : Fri Mar 5 1999 CY SOA COUNTED DUPL REAL CHANGE ============================================================== ad 257 929 323 606 0 ae 369 18816 566 18250 - 197 al 13 181 20 161 + 90 am 144 968 136 832 + 75 at 32092 235079 65197 169882 + 2453 az 79 404 41 363 - 70 ba 84 845 78 767 + 152 be 14444 259158 31603 227555 + 10865 bf 11 363 77 286 + 79 bg 702 14744 1779 12965 + 938 bh 28 1530 124 1406 + 480 bj 12 92 13 79 + 26 by 142 1260 241 1019 - 10 cf 2 8 0 8 + 2 ch 54953 323952 62777 261175 + 11545 ci 132 708 76 632 + 5 cm 7 167 3 164 - 1 cv 9 17 1 16 0 cy 691 4922 196 4726 - 871 cz 25300 104569 16808 87761 - 278 de 244838 2112930 593516 1519414 + 40387 dj 3 11 2 9 0 dk 70969 373726 63329 310397 + 9155 dz 20 92 11 81 - 3 ee 2711 27178 2018 25160 + 582 eg 914 2886 328 2558 + 28 er 1 0 0 0 - 1 es 12969 318757 17595 301162 - 7275 fi 10646 484332 16378 467954 - 2933 fo 186 900 47 853 + 307 fr 32972 529738 35065 494673 -128827 ga 12 42 25 17 + 7 gb 2 27 0 27 0 ge 60 889 47 842 + 51 gg 172 246 169 77 + 4 gh 14 348 55 293 + 27 gi 99 921 592 329 + 1 gl 228 2488 442 2046 + 66 gn 2 8 0 8 0 gq 5 11 6 5 0 gr 6852 59449 5525 53924 + 821 gw 2 21 1 20 0 hr 2240 16194 3382 12812 + 4888 hu 7885 115474 13934 101540 + 2289 ie 7089 68585 7286 61299 + 1959 il 8666 141137 21457 119680 + 2641 im 192 143 48 95 + 5 iq 1 0 0 0 0 ir 77 891 90 801 - 37 is 1896 26258 1483 24775 - 383 it 52335 491940 65262 426678 + 12796 je 164 179 81 98 + 10 jo 387 1083 409 674 + 189 ke 326 2029 629 1400 + 58 kg 55 1770 136 1634 + 81 kz 401 2966 555 2411 + 270 lb 1264 4802 876 3926 + 50 li 897 2016 831 1185 + 22 lr 5 0 0 0 0 lt 1612 11643 948 10695 + 528 lu 1982 9198 1365 7833 + 82 lv 1258 18874 3425 15449 + 431 ma 359 2585 536 2049 + 62 mc 222 606 176 430 + 5 md 126 670 184 486 + 28 mk 401 1538 189 1349 + 244 ml 17 196 8 188 0 mt 335 2043 423 1620 - 232 ne 14 105 5 100 + 22 ng 172 611 426 185 - 16 nl 63000 686089 71150 614939 - 25326 no 22814 348506 19820 328686 + 9522 om 24 2898 10 2888 + 1 pl 21045 187790 39921 147869 + 312 pt 7602 69650 9837 59813 + 875 qa 28 624 6 618 0 ro 2303 23388 3032 20356 - 6006 ru 18212 235483 54762 180721 + 12954 sa 221 1010 288 722 - 101 se 32469 448036 35871 412165 - 1086 si 3731 25771 2854 22917 - 74 sj 1 0 0 0 0 sk 7258 30069 6497 23572 + 501 sl 1 0 0 0 0 sm 74 322 12 310 - 15 sn 72 881 203 678 + 15 su 1418 29737 1784 27953 + 537 sy 4 1 0 1 0 td 6 8 4 4 0 tj 138 734 519 215 + 50 tm 1624 3018 1795 1223 + 9 tn 1 61 40 21 + 4 tr 7816 60273 5784 54489 + 7864 ua 2296 32695 11426 21269 + 661 ug 17 129 5 124 + 3 uk 165451 1819214 307118 1512096 + 44573 uz 196 750 346 404 - 15 va 2 8 0 8 0 ye 29 36 11 25 + 9 yu 2401 8865 1230 7635 - 58 ============================================================== 100 963780 9823294 1613679 8209615 + 8881

1 0

Looking for sites interested in hosting a test-box
by Henk Uijterwaal (RIPE-NCC) 01 Mar '99

01 Mar '99

Dear colleagues, The Test-Traffic Project group is pleased to announce that 20 new test-boxes have been delivered, tested and are ready to be installed at topologically interesting places around Europe. These test-boxes measure the delays on the network by sending time-stamped packets to each other. More information about the Test-Traffic Project can be found on the home-page of the Test-Traffic Project at http://www.ripe.net/test-traffic. If you are interested in hosting a test-box, please start by reading the RIPE documents 168 (version 2.1, February 1999) and 179, which should contain everything that you need to know about hosting a test-box at your site. Both documents are available from the Test Traffic project home-page. If your site can meet all requirements, please fill out the application sheet at http://www.ripe.net/test-traffic/Host_testbox. If anything is unclear or if your site is interested in hosting a test-box but cannot meet all requirements, do not hesitate to contact us. Sites that have already expressed interest in hosting a box will be contacted in a separate mail. It is our goal to distribute the test-boxes amongst topologically interesting places, while at the same time keeping the location of the test-boxes manageable from an operational point of view. Also note that the number of test-boxes is limited. This means that we may decide that we will not install a test-box at your site even though you applied for one. There is no deadline for applying. We plan to review all applications in the week after the IETF (March 19) and let the interested sites know which sites will receive a test-box. Installation of the boxes will start in the first week of April. We will continue to accept applications until all test-boxes have been installed. 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 ------------------------------------------------------------------------------ The Committee (...) was unable to reach a consensus that substantial merit was lacking. Thus, the appeal was deemed meritorious. (Orlando NABC #19).

1 0