- address-policy-wg - mailman.ripe.net

Re: [Nro-comments] Some comments on the text (fwd)
by Hans Petter Holen 16 Oct '03

16 Oct '03

FYI: Some further clearifications on the NRO proposal -hph ---------- Forwarded message ---------- Date: Wed, 15 Oct 2003 22:59:51 +0200 From: Frode Greisen <frode(a)greisen.net> To: sabine jaume <jaume(a)renater.fr>, nro-comments(a)apnic.net Cc: Hans Petter Holen <hpholen(a)tiscali.no>, "Wilfried Woeber, UniVie/ACOnet" <woeber(a)cc.univie.ac.at> Subject: Re: [Nro-comments] Some comments on the text Dear Sabine, > On 14/10/03 8:39, "sabine jaume" <jaume(a)renater.fr> wrote: > Dear all, > > After reading the NRO proposal and the ASO MoU, here are some comments > on the text, which to my opinion need clarification for better > understanding and/or to avoid misunderstanding. > > > NRO Proposal > > Chapter 1 : > The creation of the NRO doesn't need ICANN's acceptance : as far as RIR > sign the agreement it is considered in force. Did I understand it correctly? yes, this is correct. > > The signature includes RIRs who are signatories : what about any new > possible RIR? I would add here a reference to chapter 3 in case a new > RIR wants to sign the agreement later on. As you say, the intention is that new RIRs can join with equal rights. As the text stands, Chapter 3 provides for the inclusion of new RIRs. Just as the situation exists today, the new RIR must meet objective criteria and must sign the MoU. > > Chapter 2 : > This description is fully in line with the operationnal business of RIRs. > > Chapter 4 : > Here I find an inconsistency with chapter 2 : indeed if the NRO has an > operationnal role, how can it also intervene in policy making processes. > This is how I interpret the fact that the NRO Number Council is under > the responsability of the NRO Exec Council (see chapter 6). see comment below. > > Incorporation : under which law? We felt no need to define law and location before a decision to incorporate. This will be agreed by the RIR signatories at that time. > > Chapter 6 : > Here is where policy-making process- and day to day busines of > RIRs are mixed. > What happens if the Number Council makes proposals > following bottom up process which are rejected by the NRO (see comment > on ASO MoU text)? The Executive Council is responsible for external communication but in the (probably most likely) scenario policy ratification is done by ICANN as defined in the ASO MoU and the Executive Council will not make policy. It is only in the stand-alond scenario after and ICANN failure that the Executive council would in reality ratify or reject. The sense of the document is that the Executive council would then act in the role of the ICANN board as far as address policy ratification is concerned and would only base its decision on whether due processes were followed or not. In order to avoid duplication, all the relevant procedures defined in the ASO MoU and its attachment are not also spelled out in the NRO document. In the case of rejection, any dissatisfied party could resort to the appeals process. > > Chapter 7 : > Here the bottom up process should be described. > You may be right. In the scenario where the global policy process is defined in an ASO MoU with ICANN that MoU defines the bottom up process. > > Aren't the ICANN board directors election the Number Council's duties > any more? The Address Council will select ICANN Board members as provided for in the ICANN by-laws and the ASO MoU. When the ASO MoU is agreed to between the RIRs and ICANN, the Numbers Council will become the ASO Address Council and will function under the provisions of the ASO MoU. > > What are the lenghts of each person's term? Can they be renewed? > Can the 2 selected persons be RIR staffed persons? > Good questions. Since there would probably be a transition from the present Address Council to the Numbers Council a staggering would need to be defined but we felt it would be better to have a basic agreement with ICANN and also seeking advice from the present Address Council before getting into defining a system for this. A reasonable assumption would be to get to three year terms like now. RIR staff members may not be elected to either of the two elected seats. An RIR staff member may be appointed by theappropriate RIR Board to the one RIR appointed positon from each region. > > Chapter 9 : > How long will people seat on the Appeals Panel? > Experience from the RIPE NCC arbitration panel shows that the arbiters have not been very busy. My personal preference would be to let the NRO ping the selected representatives about annually, and keep them as long as they are willing and and able and have the desired knowledge. > > Chapter 10 : > In case of an abitration that takes long time : what will happen? Is > there a kind of provision that says that during the time there is no > decision, policies will be applied as they were before the dispute started? > Good point. As usual, the appeals process is institued to seek agreement before a part resorts to a lawsuit. The pressure to avoid suits should be an incentive for the appeals panel to act quickly, however, the circumstances of each situation will dictate deadlines. Therefore, a one size fits all time is not suitable. It may be worth considering, but perhaps difficult to decide in advance for all cases, whether initiation of appeal should have holding effect on the process in question. > > Chapter 11 : > How is an RIR member defined? This is an RIR signatory. Should probably be clarified in the text. > > What is the clause 12b? > Thanks for spotting this! This should say 1.2. > > Chapter 12 : > What are those technical activities : could be a lots of things... > Yes, and as such they must be agreed by the Executive Council. Examples could be mutual data-base backup between RIRs or global whois services. > > Chapter 13 : > Will the RIR members (again to be defined) pay a fee directly to the > NRO, or will this be done via the RIRs existing fundings? > Like above, RIR member in this chapter means NRO signatory. Since the NRO will not have a budget there will be no fees paid to the NRO. All expenditures will be agreed to by the Executive Council. The Secretariat will track the costs and invoice each RIR as appropriate. Just as is the situation today with regards to funds for the ICANN budget and funds to support ASO and ASO AC activities, the RIRs include these expenditures in their individual budgets. In regard to the NRO and the new ASO and and ASO AC we expect the same method of operation. It is expected that these expenditures will be similar to today's situation. > > What is paragraph "a" refering to? > Thanks! As above, letters were changed to numbers in bullet points, so this should be paragraph 13.1. > > ASO MoU > > From the NRO document statements, the Address Council is under the > responsablity of the NRO Exec council, and has RIR appointed members. So > what does "in conjunction with the RIRs" means? > > Again the split between policy making process and operations is > confused, because of the ASO AC being under the responsibility of the > NRO. Indeed point 4 stresses that the RIRs Board do have a policy making > role. > "In conjunction with the RIRs" means that both the Address Council and the RIRs will work together. While it is anticipated that most questions and concerns of the RIRs can be dealt with by the RIR appointed members of the Adress Council, there always exits the possibiliy that additional information may have to be gathered by RIR staffs or the RIR Boards may need to comment. Thanks for your thoughtful questions and comments. For further discussion you may also want to check http://www.ripe.net/ripencc/about/regional/nro-faq.html Frode Greisen RIPE NCC Executive Board Member > > Looking forward to any clarification you can provide, > > Thanks! > > Best regards,

1 0

RIPE NCC allocations to African LIRs
by leo vegoda 15 Oct '03

15 Oct '03

Dear Colleagues, The RIPE NCC received the IPv4 address range 196.200.0.0/13 from ARIN in October 2003. This range will be used to make allocations and assignments to organisations based in African countries served by the RIPE NCC. This block is part of a /8 also used by ARIN. In order to reduce confusion the RIPE NCC will not assign prefixes longer than a /24 from it. You may wish to adjust any filters you have in place accordingly. More information on the IP space administered by the RIPE NCC can be found on our web site at: <http://www.ripe.net/ripe/docs/smallest-alloc-sizes.html> Kind regards, -- leo vegoda RIPE NCC Registration Services Manager

1 0

Some questions regarding the NRO proposal
by Hans Petter Holen 15 Oct '03

15 Oct '03

Dear all, First of all I would like to congratulate the RIRs with a constructive and solid proposal to move forward. I think the formalization of an organization to help the RIRs act in a coordinated manner is lomg overdue. As a general comment I think the detailed specification of the global policy making process is a step forward. Under the current MOU this is not well defined and clarification of the process should be much welcomed to all involved. In reading the proposal I have some questions, first to the NRO Agreement: 6. NRO Executive council Is there a clear enough division between legislative and executive roles? One of its roles is to ratify and reject global IP number policies. (Legislative), at the same time the Executive council is empowered to sign documents and contracts (executive). Maybe it needs some clarification in the language to make it clearer that the EC simply ratifies that polices has been formed according to process. 7 NRO Number Council ii Composition What is the reason for the proposed composition? The Board of the RIRs are elected by the members of the RIR and the current procedures for electing ASO AC members are that mostly the members elect the council members. The proposal is in reality a combination between a direct and indirect election. What is the advantage of this? Why not revert to just one approach direct or indirect election? a) Election by RIR members b) Election by RIR boards The Council shall under the agreement elect a chair. It may also be necessary to elect co-chairs and a secretary for the Council to maximize its ability to conduct its tasks. Regarding the composition of the two councils: what conflicts of interests exists between the two and the bodies of the RIRs? Are there global conflicts of interests or should this be left to the individual RIRs to decide? Then to the ASO MOU Attachment A: Global Policy Development Process: 4. For some RIRs (RIPE NCC) this introduces a new role to the Board in ratif ying policy proposals. While this may be a good idea - it does require some changes to the regional policy process to be aligned. Best Regards, Hans Petter Holen

2 1

Draft minutes: RIPE 46 Address Policy WG session
by leo vegoda 14 Oct '03

14 Oct '03

Dear Colleagues, Draft minutes from the Address Policy Working Group session at RIPE 46 can be found at: http://www.ripe.net/ripe/wg/address-policy/r46-minutes.html Please check the minutes for errors or omissions. Comments and corrections can be sent directly to this list or to one of the WG chairs personally. Additionally, draft minutes from the LIR Working Group at RIPE 45 are can be found at: http://www.ripe.net/ripe/wg/lir/r45-minutes.html These have not yet been approved and can still be corrected if appropriate. Kind regards, -- leo vegoda RIPE NCC Registration Services Manager

1 0

Call for volunteers: editorial group to revise "Charging by Local Internet Registries" document
by leo vegoda 13 Oct '03

13 Oct '03

Dear Colleagues, Last month at RIPE 46 the RIPE Address Policy Working Group (AP WG) discussed the RIPE document "Charging by Local Internet Registries" (ripe-152). The document was published in 1996 and describes "charging for services by Internet registries and indicates acceptable practice for such charging". It can be found at: <http://www.ripe.net/ripe/docs/chargingbylirs.html> Particular attention was given to the statement that "registries may charge for their administrative and technical services, they may not charge for name space or address space as such; no unit cost or price tag can be attached to a domain name or to an IP address, public or private." It was agreed that an editorial group of volunteers from the community should be formed discuss the document and suggest changes to its text and content. A mailing list has been created for this discussion. The list is open to anyone wishing to participate. If you want to subscribe to the list you can do so via the web interface at: <http://www.ripe.net/mailman/listinfo/ripe-152bis> Additionally, a web archive of the discussion can be found at: <http://www.ripe.net/ripe/mail-archives/ripe-152bis> Kind regards, -- leo vegoda RIPE NCC Registration Services Manager

1 0

Proposed Open Letter to ICANN and Related Documents
by Axel Pawlik 13 Oct '03

13 Oct '03

Dear Colleagues, The Regional Internet Registries (RIR) have published three (3) documents: a. Proposed Open Letter to ICANN from the Regional Internet Registries b. Proposed Agreement between the RIRs to create the Number Resource Organization c. Proposed Agreement between the RIRs (acting through the NRO) and ICANN concerning the Address Supporting Organization These documents are available on a single web page at: http://www.ripe.net/ripencc/about/regional/draft-public-comment.html In order to ensure that RIR members and address communities in every region have the opportunity to comment, the Board of the RIRs have requested that RIRs post the documents for a period of 30 days. The comment period closes at midnight (UTC) on the 22nd October 2003. Each of the RIR Boards will consider the comments as they are received, and each RIR Board intends to make a decision whether to adopt these documents following this comment period. If these documents are adopted by all the RIR Boards, it is the present intention to formally pass the following open letter to ICANN on the 24th of October. On the same date the Boards of the RIRs currently intend to direct their CEOs to sign the MoU concerning the establishment of the Number Resource Organization. All comments should be addressed to: nro-comments(a)apnic.net. The comments will be passed to all the Boards of the RIRs, and will also be published on the web site http://www.apnic.net/nro-comments. Any dialogue that arises from such comments will also be published on this site. Subscription information for the nro-comments mailing list is available at: http://mailman.apnic.net/mailman/listinfo/nro-comments All postings to this mail address (nro-comments(a)apnic.net) are public, and will be published at the following URL: http://www.apnic.net/nro-comments kind regards, Axel Pawlik Managing Director RIPE NCC

2 1

RIPE NCC Regional Meeting, Middle East, Dubai, 7-9 December 2003
by Membership Liason Officer 08 Oct '03

08 Oct '03

Dear Colleagues, The RIPE NCC is pleased to announce the RIPE NCC Regional Meeting, Middle East, to be held 7-9 December 2003 at the Metropolitan Palace Hotel, Dubai, U.A.E. Registration for the Regional Meeting opens 8 October 2003. Attendance to the RIPE NCC Regional Meeting is open and free of charge. However, attendees are responsible to cover their own travel and accommodation costs. To register, please see: http://www.ripe.net/cgi-bin/dubai-reg The RIPE NCC Regional Meeting will focus on Internet resource allocation and Internet management issues including: - How to participate in and influence IP address management policy-making; - The industry self-regulatory open structures and processes used by the RIPE NCC and the global Internet community; - Are we running out of IPv4 address space? - Root name server operations: who is involved? - Domain Name management on the Internet; - The internationalisation of Domain Names. The Regional Meeting draft agenda can be found at: http://www.ripe.net/ripencc/regional-meetings/dubai-2003/plan.html RIPE and the RIPE NCC will explain their roles in the administration of the Internet infrastructure as well as specific aspects in managing and operating the Internet infrastructure. The discussions will be directly related to the particular needs and concerns surrounding these issues in the Middle East region. The current meeting agenda reflects our intentions. However, it requires active participation from the local community to discuss specific issues of the region. The RIPE NCC has reserved several presentation opportunities for those with local knowledge of Internet management and operational issues affecting the Middle East. If your organisation wishes to provide a presentation or suggest a relevant topic, please send your proposal by e-mail to: <contact(a)ripe.net> The RIPE NCC is one of four Regional Internet Registries (RIRs) that provide Internet resource allocation, registration services and co-ordination activities that support the operation of the Internet globally. The RIPE NCC is an independent, not-for-profit membership organisation that provides services to members in its service region currently covering Europe, the Middle East, Central Asia and African countries located north of the equator. Any further questions about the RIPE NCC Regional Meeting, Middle East can be sent directly to: <contact(a)ripe.net>. Regards, Sabrina Wilmot Membership Liaison Officer RIPE NCC

1 0

Revised Draft Document for review: "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region"
by Dominic Spratley 05 Oct '03

05 Oct '03

Dear Colleagues, The RIPE NCC is pleased to announce an updated draft of the revised RIPE IPv4 policy document, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" (currently ripe-234). The major change from the draft published on 21st July is that the existing "status:" attribute values are kept for inetnum objects with the addition of a new value for sub-allocations. The updated draft can be downloaded from the "Drafts" section in the RIPE Document Store, found at: <http://www.ripe.net/ripe/draft-documents/> The major updates to the current policy text in this draft IPv4 policy document are: - Recent policy changes have been incorporated, including the policy allowing assignments for Internet experiments and the sub-allocation policy. - Wording has been improved to make it easier to read. - The explanation of how to use the database has been removed as a separate "RIPE Database User Manual: Getting Started" was published in September last year. - The document now incorporates the text from "Provider Independent vs Provider Aggregatable Address Space" (ripe-127). If the community accepts this document it will replace the existing IPv4 Policy document (ripe-234) and the "Provider Independent vs Provider Aggregatable Address Space" document (ripe-127). Feedback on this document should be sent to the address-policy-wg@localhost mailing list for a period of two weeks. This review period will end on TWO WEEKS FROM ANNOUNCEMENT. Dominic Spratley Registration Services Manager RIPE NCC

2 1

RIPE 46 Meeting Report
by Nick Hyrka 02 Oct '03

02 Oct '03

(Apologies for duplicate mails.) RIPE 46 Meeting Report Dear Colleagues: The RIPE 46 Meeting was held from 1 - 5 September 2003 at the Grand Hotel Krasnapolsky, Amsterdam, the Netherlands. There were a total of 307 attendees comprised of the RIPE NCC membership, the RIPE community and government representatives. Attendees also included representatives from APNIC, ARIN, AfriNIC, LACNIC and ICANN. HIGHLIGHTS ========== Highlights of RIPE 46 included the open discussion on the services of the RIPE NCC during the first session of the RIPE NCC Services Working Group; a presentation on current RIPE NCC services and plans for 2004 by Axel Pawlik, Managing Director, RIPE NCC; an AfriNIC update; and an update on the changes to Test Traffic Measurement. The European Operators Forum (EOF) featured a full-day tutorial on Voice over Internet Protocol (VoIP) and ENUM that included an overview of current technologies and a focus on practical deployment aspects such as gateways, security, provisioning and use of the new ENUM standards. Geoff Huston, Telstra, gave a presentation on IPv4 Address Lifetime Expectancy. The RIPE NCC would like to thank SURFnet, BIT, FLAG Telecom and KPN EuroRings for the support they provided to the meeting. SUMMARY ======== ADDRESS POLICY ============== - Hans Petter Holen, Chair, requested community involvement to help revise ripe-152 ("Charging by Local Internet Registries") if necessary. - The RIPE NCC will resubmit the IPv4 policy document for community review. - There was a discussion on PI/PA issues and whether the distinction is still valid. - It was agreed that a more formal process was needed for the policy development process. Address Policy Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#ap DATABASE ======== - Wilfried Woeber, Chair, will co-ordinate with the RIPE NCC to prepare a document summarising the basic assumptions about the use of the RIPE Database. - "status:" attribute values will change. Current efforts aim at consistency between the RIRs and having easy to understand values. - The organisation object proposal received positive feedback from the working group, with suggestions for other features. - The RIPE NCC will implement X.509 authentication before the next RIPE Meeting. Database Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#db TEST TRAFFIC MEASUREMENTS (TTM) ========================= - As of 1/1/2004 changes will be made to the TTM service contract: Fees will be lowered, all data will be made public with lightweight Acceptable Use Policy (AUP). - Bandwidth measurements: tests showed that results are not conclusive enough so the TTM service will wait before delivering this new product. TTM Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#tt ANTI-SPAM ========= - Rodney Tillotson, Chair, will post a proposal to the Anti-Spam mailing list regarding methods to improve finding abuse contacts in the RIPE Database. Anti-Spam Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#anti-spam IPv6 === - The 6BONE phase-out was discussed. The next milestone will be 01/01/2004 when new allocations stop. - Discussion on the separation of the identifier and locater functions of IP addresses in regards to IPv6 multihoming. IPv6 Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#ipv6 TECHSEC ======== - Community feedback was requested on the requirements needed to secure large scale IP infrastructure especially around CLI interface requirements. - The RIPE NCC presented a report on DNSSec status, DISI achievements since RIPE 45 and the impact of signing on zone size. - George Jones, Mitre, gave a presentation on operational security requirements including the history and current status of the requirements, related work, next steps and milestones. - Baiba Kaskina, TERENA, gave a presentation on Euro CSIRT developments that included details on the CSIRT Task Force, the countries involved, the projects and deliverables. - NLNetLab presented an update on Fonkey and PKI-related developments in IETF. TechSec Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#techsec EIX == - Support was expressed for aligning and harmonising IPv6 address space policy regarding IXPs with other RIRs and existing IPv4 policies. - Reports were presented by 11 European IXPs in Europe that showed a trend of steady growth, use of GE instead of FE and wide deployment of IPv6. - Discussion of the Inter-Provider Traffic Analyzer that uses past data and statistical calculations to detect anomalies in traffic patterns. - EIX presentations were given on the anycast deployments of the "F" and "K" root servers by ISC and the RIPE NCC. EIX Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#eix DN* === - From the merging of the former DNS Working Group and DNR Forum it was concluded that one working group is sufficient to deal with everything related to Domain Names. A new name/charter will be discussed on the mailing list. - Jaap Akkerhuis, DN* Co-Chair, will organise a "DNS Related Issues" document. - Peter Koch, DN* Co-Chair, talked about how firewall vendors could make mistakes handling DNS communication issues. DN* Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#dn RIPE NCC SERVICES ================ - Axel Pawlik noted that the RIPE NCC will present more details in next year's RIPE NCC budget. - There were comments on the current RIPE NCC services, whether they benefit the entire community and whether a 'pay per service' system could be an option. - There was discussion about the need for a more transparent evaluation of RIPE NCC activities and how they benefit the community. RIPE NCC Services Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#ncc TUTORIALS ========= - The RIPE NCC staff presented the RIPE NCC IP Request Tutorial. It explained address space assignment and allocation procedures in the RIPE NCC region: http://www.ripe.net/ripe/meetings/ripe-46/tutorials/ip-request/ - A full-day tutorial on VoIP and ENUM was presented during the European Operators Forum (EOF). For more information about the EOF at RIPE 46 see: http://www.ripe.net/ripe/meetings/ripe-46/eof.html RIPE MEETING WEBCASTING ======================= - The third phase of RIPE Meeting webcasting trials was held at RIPE 46. Recordings of certain sessions from RIPE 46, including the Plenary, have been archived and can be accessed at: http://www.ripe.net/ripe/meetings/ripe-46/webcast.html HOSTMASTER CONSULTATION CENTRE (HCC) ==================================== - The RIPE NCC Hostmaster Consultation Centre was open at RIPE 46, allowing RIPE NCC Members to discuss issues relating to their business directly with RIPE NCC Hostmasters. Later consultation hours, as introduced at RIPE 44, were continued. "MEET & GREET" =============== - The RIPE NCC's "Meet & Greet" was available for first-time RIPE Meeting attendees at RIPE 46. "Meet & Greet" introduces newcomers to the meetings, to key attendees of the RIPE community and to social events throughout the week. More information can be obtained by contacting the RIPE NCC's Pepa Tejedor Carnicero at <meet-greet(a)ripe.net>. RIPE 46 REFERENCE PAGE ====================== - A complete list of RIPE 46 sessions, tutorials and presentations can be found at: http://www.ripe.net/ripe/meetings/ripe-46/index.html RIPE NCC GENERAL MEETING ======================= - The RIPE NCC General Meeting 2003 was held Friday, 5 September 2003, adjacent to the RIPE 46 Meeting, at the Hotel Krasnapolsky in Amsterdam. For the highlights from the RIPE NCC General Meeting 2003, please see: http://www.ripe.net/ripencc/about/gm/gm2003/highlights.html RIPE 47 ====== - RIPE 47 will be held in Amsterdam, the Netherlands, from 26 - 30 January 2004. Information on RIPE 47 will soon be made available at: http://www.ripe.net/ripe/meetings/ripe-47/ NEW LOCAL INTERNET REGISTRIES (LlRs) - PLEASE NOTE LIRs who signed up after 1 January 2002 are entitled to two (2) free tickets to attend the next RIPE Meeting. The tickets cover the meeting fee only and do not apply to the RIPE dinner, travel or hotel accommodation. More information on the new LIR tickets can be found at: http://www.ripe.net/ripe/meetings/new-lir.html For more information, contact <meeting(a)ripe.net>. END

1 0

Re: [address-policy-wg] Re: [ncc-services-wg] Request Forms: upda ted and available on LIR Portal
by Kinder, Klaus 02 Oct '03

02 Oct '03

Hi, Ludger Bornhorst is on vacation but we have discussed this matter before he send this mail. Here two notes from my point of view: you wrote: The RIR->LIR level has the AW to express a given level of trust. I quite agree with you: You could use policies in a narrow interpretation or in a scope of interpretation in addition with your know how in cases of ip-address management, both is possible and essential. But you couldn't find this scope in ripe-283 e.g. #[EQUIPMENT DESCRIPTION]#, I think that's the problem. Or is this scope in addition to your AW an unwritten policy? you wrote: please don't feed the buerocracy. I can assure you that's not our target. From our point of view policies should give all parties, here the LIR's, a general Framework and not a straitjacket. mit freundlichen Grüßen/with best regards Klaus Kinder _________________________________________ Deutsche Telekom T-Com Headquarters Network Information Center Local Internet Registry Ammerländer Heerstr. 138, D-26129 Oldenburg +49 441 234 - 4530 (phone) +49 441 234 - 4589 (fax) E-Mail: Klaus.Kinder(a)telekom.de

1 0

RE: [address-policy-wg] Re: [ncc-services-wg] Request Forms: upda ted and available on LIR Portal
by Bornhorst, Ludger 25 Sep '03

25 Sep '03

Hi Christian, > The question is how complex an evaluation must be? The facts needed to > evaluate a normal IP requests are simply the number of nodes needing a > public IP address. In case one or more nodes needs more than 1 IP address > then documentation is needed to explain why to exceed the normal rules, also > in case the expected growth pr. year exceeds 100%. Yes, but I don't have any problem to ask endusers about their (planned) hardware and to document their needs in the way we've done it since several years now, like "We have 20 PC's, 5 routers, 200 dial-in-ports and so on..." This general information will (in most cases) be sufficient to evaluate IP requests. > It would of course be easier to falsify the number of nodes than to falsify > the documentation, but in case an end user intends to falsify information in > order to get more IP addresses than justifyable, then I don't see any easy > way to prevent this. Right, but there are still enduser who don't know about classless addressing. That means they are asking for "Class-C" nets just because they think its hip. So I think it's responsibility of the LIR's to tell this endusers about CIDR and its outcomes. And, yes I agree: If an enduser wants to cheat at you, I can't see a way to prevent this. > I would find it reasonable if larger requests still required some form of > documentation, for example /24 and above. But it would of course still be > very important for all LIRs to stress that the information received from the > enduser must be correct. ACK! This way it would be possible to serve the main part of the customers at a simple level and only ask reasonable questions (hardware documentation) if the request exceeds a certain level. I would like to stress that the /24 border should be the maximum limit of "freedom" given here. Maybe it's better to decrease this "HW-documentation-border" down to /25 or /26 ? What do you think? mit freundlichen Gruessen/with best regards Ludger Bornhorst ______________________________________________________________________ Deutsche Telekom AG T-Com Headquarters Network Information Center Ammerlander Heerstr. 138, D-26129 Oldenburg Hotline +49 441 234 4581 (phone) +49 800 3301180 +49 441 234 4589 (fax) +49 800 3301179 ludger.bornhorst(a)telekom.de (mail) dk.call-center(a)telekom.de

2 1

Re: [address-policy-wg] Re: [ncc-services-wg] IPv6 applications (was: Request Forms: updated and available on LIR Portal)
by Gert Doering 02 Sep '03

02 Sep '03

Hi, On Tue, Aug 26, 2003 at 12:57:13PM +0200, Dominic Spratley wrote: > You both made several points and I hope I can explain our thinking on them > for you. We think these new forms represent a change in the way we provide > services to LIRs so we've addressed this answer to the NCC Services WG list. > We don't think they represent a change to the RIPE community's policy. Actually, I tend to disagree, at least for some parts. Which is why I've put the APWG list back into the CC: (sorry for duplicates). Some of the criticism voiced is that the NCC is asking questions and enforcing rules that are more strict than what the policy demands - and this is certainly relating to policy. [..] > You asked about the requirement for a network diagram to be supplied when > requesting an IPv6 allocation. There are two reasons for this. Firstly, the > RIPE NCC has not yet made yet 250 IPv6 allocations. Our experience with IPv6 > networks is limited and we need network operators to show us how they intend > to use IPv6 address space in their networks. I agree with the assessment that "more experience for the NCC is a good thing". On the other hand, many startup IPv6 deployments are extremely trivial ("one access server with 1000 DSL circuits, serving /48s to DSL end users" would certainly qualify for the policy requirements). So I don't think it's appropriate to enforce this "you send us an interesting picture, otherwise you won't get an IPv6 allocation" approach. Make it optional. > Secondly, the current IPv6 > policy does not allow stockpiling of IPv6 address space. One way of > distinguishing a genuine request from one that is intended for stockpiling > reasons is to request a diagram showing how the address space will be used. > It doesn't have to be a a fancy diagram. It's also fine to fax a hand-drawn > diagram instead of sending one by e-mail. When we have more experience with > IPv6 I expect we will make the diagram optional. This is "conservationism striking again", and this is BAD. The idea behind the current policy is "make IPv6 address blocks available to anybody who is asking for them" (and can reasonably claim 200 future IPv6 customers). For that, you don't *need* a fancy network, so why do you have to demonstrate it at all? What are you worrying about? Address wastage is really not a problem right now. Obstacles on the way to IPv6 deployments are a problem, and we don't want the NCC to be an obstacle. Now come and flame me :-) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55575 (56535) SpaceNet AG Mail: netmaster(a)Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299

2 1

Re: [ncc-services-wg] Request Forms: updated and available on LIR Portal
by Sascha Lenz 02 Sep '03

02 Sep '03

Hay, On Thu, Aug 21, 2003 at 04:02:16PM +0200, Dominic Spratley wrote: > Hi Daniel, > > I hope I can clarify some of your points below: actually i didn't really want to get into this discussion, but it looks like _noone_ else has anything to say about the issues Daniel raised? Than can't be since he is right in most points. > At 03:37 AM 8/21/2003 +0200, Daniel Roesen wrote: [...] most points have been more-or-less clearified by Dominic's answer, but: > >- [EQUIPMENT DESCRIPTION] > > > > This requirement _can't_ be meant serious. We're not on April 1st, > > are we? The silliness of such information requirement was already > > recognized within the IPv6 allocation realm, so why introducing it > > now again for IPv4? > > This is a difficult one as it does require the LIR to do more preparation on > their side. The less time a Hostmaster spends sending E-mails asking > for additional information, the sooner the LIR gets their requested resource. > Asking for the type of equipment used really helps the Hostmaster > understand what and why IP addresses are being requested. ... i still have a problem here if that should be a "must provide this information". I have no much problems with questions like "why-pi" or "routing-reasons" because they can obviously be answered with standard phrases (which renders them useless again, but if RIPE NCC sees that many "bad" requests from many LIRs (aren't they trained?), it's OK for me, no much work, no stupid questions). BUT... information like the equipment being used or a network plan or so _must_ be optional information, not _required_ information. It can't be that a company is _required_ to make statements about their network and equipment if they want to have IP-Adresses! (and no, RIPE doesn't always qualify for receiving such information). Besides that it's way too much work to fill that in seriously for big requests, and doesn't really make sense for small requests. This should be _optional_ information in cases where it's needed to explain an unusual request, whatever, "we have only one machine but it has 500 IP Adresses due to this and that special purpose which can't be handled otherwise due to these and those hardware and software limitations". Is it really only me who is of that opinion, or noone recognized this problem or doesn't think it's a problem? Or isn't it meant as _required_ information anyways and a "N/A" is enough in most cases as answer to this part of the request? ...curious. The reason i noticed that this might get a problem was due to the unholy [...] #[REQUIRED INFORMATION]# [...] % % 2. Please provide a network diagram in PostScript or JPEG % format showing your IPv6 network. Submission instructions % can be found in the RIPE document "Supporting Notes for the % Initial IPv6 Allocation Request Form in the RIPE NCC Service % Region" found at: % % http://www.ripe.net/ripe/docs/ipv6-support-initial.html % % The diagram should indicate expected completion dates of % construction as well as how much IPv6 address space is % expected to be used in each subnet. % % [...] in the (old and new) IPv6 Initial Allocation request form. Since it says "required information" there, i already assumed that it might get a problem to get the IPv6 Allocation for us without providing this one. But i didn't see the point in doing so if i can make our network plans clear in text form, and explain the reasons why a network diagram for an IPv6 network is _completely_useless_ in general at the moment and especially in our case. Though, even on my 2nd mail on that request i just got the reply from some RIPE Hostmistress that "the inability to provide this network topology map calls into question the need for the IPv6 addresses being requested.". At the moment i'm really mad about this. We are currently prevented from deploying IPv6 addresses immediately because i don't have any Windows PC with Viso or something at hand, let alone the time to paint a very useless topology of our IPv6 overlay network, though i explained it in detail in text. (Not to mention that the statement that an active LIR which assigns IPv4 addresses for years is questioned that it will assign IPv6 addresses just because it doesn't like to waste time on painting network maps of some routers and tunnels is VERY doubiously to me.) Why the hell is such information _required_? Information about what equipment being used and a network topology map on a picture might be additional information at best. I fear that IP(v4) request will be denied or at least delayed in future if the RIPE Hostmasters are gonna complain about missing or unsatisfying information about the equipment in the future, too. That's not acceptable i think. But i might be wrong, we're realatively small and don't have that many requests in general, i just wonder why noone of the "big LIRs" sees this problem? You all have AWs that big that you don't care about filling in RIPE forms anyways and have payed managers to paint network diagrams all day? *hint* :) > >Further, the term "peer" is used in a very unclear way in the ASN > >request form and the supporting notes. > > > >Formerly, one uplink and one peer (commercial term) were enough to > >justify an ASN, as this constitutes a "unique routing policy". The > >ASN request form allows this interpretation of "peering partners" > >with "peering" in the technical sense. BUT the supporting notes > >specifically mention the requirement for two peers to "ensure that the > >organisation is multihomed". For me, multihoming means to have at least > >two _upstreams_. This would be a more stricter policy than before. > >What was the real intention behind these phrases? These documents > >should be very specific in the usage of "peer". It might be interpreted > >technically or commercially, each implying different constraints. > >I suggest changing the wording from "peer" to "upstream" in order to > >avoid ambiguities. > > Again this is a good point. However I don't think that either term is > appropriate for all situations. When writing these documents we used > the word peer as we wanted to emphasise it was the routing policy which > was important. So, the policy didn't change to "you have to have two _upstreams_ to get an ASN" but it's only a language-confusion here? P.S.: I think this discussion belongs to the address-policy-wg, not ncc-services-wg? Sorry for crossposting, remove the latter in any replies if i'm right. -- ========================================================================== = Sascha 'master' Lenz SLZ-RIPE slz(a)baycix.de = = NOC BayCIX GmbH = = http://www.noc.baycix.de/ * PGP public Key on demand * = ==========================================================================

4 7

Re: [address-policy-wg] WG Charter
by Hans Petter Holen 01 Sep '03

01 Sep '03

> Hans Petter, > > I would also mention the role of the working group in > - co-ordinating policies with other RIRs > - address policy issues that have to do with IANA/ICANN What about: The Address Policy WG develops policies relating to the management and registration of Internet resources (currently IPv4, IPv6 and AS Numbers) by the RIPE NCC and its LIRs within the RIPE NCC service region. It also co-ordinates policies with the other RIR communities and liaises with the IANA and ICANN on address policy issues. The Address Policy WG meets three times a year at RIPE meetings and has an open (publicly archived) mailing list. Anyone with an interest in Internet numbering issues is welcome to observe, participate and contribute to the WG. -hph

4 4

Fwd: selling ip:s? (kf)
by Katri 28 Aug '03

28 Aug '03

>Hello, I would like rise the question about selling ip-addresses... > >Let me present two exampled: >1. ISP A has offeres adls that includes static 1 ip-address, but if the >customer needs more ip:s > they will apply for this and pay a sum of X krona per ip-adress they > receive. > ISP B also offeres adsl that inclued 1 ip-address, and when the > customer needs more ip:s > they will have to change the service in order to receive more ip:s, > since the adsl service is > only offered with 1 ip-address and approved from RIPE NCC to be done > in this way. > How should ISP B compare and offer the same amount of ip-addresses > without "getting > into trouble"? > >2. ISP A has a customer who has received /24 from which they share out >addresses > and their customers can receive more addresses for a sum of X krona. > > I understand that we are not allowed to sel our ip-addresses but what > about > our customers customer? Is there anything preventing this from > happening and > is there something documented? > >Regards Katri >Tele2/Swipnet IP Registry >Local Internet Registry >__________________________________________________________ > >Tele2/SWIPnet Tel: 08 5626 40 08 >Box 62 Fax: 08 5626 42 10 >164 94 Kista Email: ip(a)swip.net >SWIP-RIPE SWIPNET-LIR-MNT >__________________________________________________________

2 1

Re: [address-policy-wg] Summary of the PI Task Force's recent discussions
by Wilfried Woeber, UniVie/ACOnet 26 Aug '03

26 Aug '03

>Hay, > >On Thu, Aug 21, 2003 at 02:42:05AM +0200, Daniel Roesen wrote: >> On Mon, Aug 11, 2003 at 08:19:46AM +0200, leo vegoda wrote: >> > Below is a summary of the recent discussions on the PI TF mailing list. >> >> As the pi-tf mailing list seems to have been closed (at least I'm unable >> to subscribe - pi-tf-request(a)ripe.net bounces as unknown), I guess >> further discussion should take place here (which makes some sense). > >Closed, yes. I don't think so, pls. see below. Wilfried. ______________________________________________________________________ From: Mally Mclane <mally(a)ripe.net> To: pi-tf(a)ripe.net Subject: [pi-tf] This list has moved to mailman Date: Tue, 26 Aug 2003 09:26:26 +0200 Dear Colleagues, We have moved this list to mailman, in an attempt to cut down on the spam that was entering it. The list will function exactly as before, and the archives will still be available in the same space. You can edit your personal options at: http://www.ripe.net/mailman/listinfo/pi-tf If you notice any oddities, please contact <ops(a)ripe.net>. Regards, Mally Mclane RIPE NCC - Operations --------------------------------------------------------------------------------

4 3

Summary of the PI Task Force's recent discussions
by leo vegoda 26 Aug '03

26 Aug '03

Dear Colleagues, Below is a summary of the recent discussions on the PI TF mailing list. The policy for portable address space is on the draft agenda for the Address Policy WG's session at RIPE 46 on 3 September. Kind regards, -- leo vegoda RIPE NCC Registration Services Manager A summary of the PI TF's initial discussions was agreed and posted to the <lir-wg(a)ripe.net> mailing list on 6 May 2003. It can be found at: http://www.ripe.net/ripe/mail-archives/lir-wg/2003/msg00265.html Gert Döring presented on the discussion at the RIPE 45 LIR WG session. His slides can be found at: http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-lir-pi-tf. pdf At RIPE 45 there was an agreement that the Task Force should continue its work. There was also an agreement that the PI policy is tied to the qualifying criteria for an initial IPv4 allocation. Discussion focused around a straw-man proposal to make four related policy changes. The proposed changes are outlines below along with a summary of comments received on them. 1. Reduce the minimum allocation size from /20 to /21 - There was some support for this point. There were requests for /21 allocations to come from a new and separately identified address blocks. 2. Remove the requirement to show an immediate need for 25% of the allocated address space (a /23 in this case) - There was no objection to this point. It was pointed out that with a lower barrier to entry the overhead of checking each requester is ready to use 512 IP addresses straight away would be unlikely to be equal to the value of the work. 3. No longer assign PI (Portable) address space to End Users - There some support for to this point. The issue of Root DNS Servers was raised but it was noted that all Root DNS Servers operating in this region already have address assignments. 4. End Users requiring a portable address block could become an LIR and receive a /21 allocation. - There was some support for this point. The costs of operating an LIR were raised as an issue. It was also noted that everyone may become an LIR. There is no barrier to membership of the RIPE NCC. There was a suggestion for a one-time service fee. There were also some additional comments: It was noted that if the policy allows for address allocations based on other criteria than prior demonstrated need some providers may filter those allocations. It was also noted that the RIPE NCC cannot provide any guarantee as to whether address space will or will not be routed of filtered by network operators. Some statistics were requested and provided for the first half of 2003: ASN assignments: 599 Allocation: 377 PI Assignments: 408 Number of /20s allocated per month for the same period: 200301 7 200302 20 200303 14 200304 16 200305 35 200306 24 Finally, it was noted that there is a requirement for globally unique addresses that will not be routed on the Internet.

9 14

Re: [address-policy-wg] Transferring InterNIC space from ARIN Database to other RIR datab ases
by Niall O'Reilly 20 Aug '03

20 Aug '03

On Wednesday, Jul 30, 2003, at 22:42 Europe/Dublin, Hans Petter Holen wrote: > Hmm, we did form a special task force for this matter to work with the > RIPE NCC with the process etc. (References in Leos message) > > As chair of this working group I would really like to know what more we > can do to interact more closesly with the community - please feel free > to > suggest to the list or approach me personally with suggestions ! Hans Petter, Thanks for your encouraging words. I've been away for a couple of weeks and am still mining the e-mail mountain. During second half of July, I've had some off-list exchange with Leo, and found him really eager to be helpful. I still have some sense of the "blind man and elephant" problem, in both directions. As I'm not involved in a LIR, I missed the formation of the task force. In addition, I couldn't travel to Barcelona. In any case, a TF involving LIR-WG and RIPE-NCC is likely (as seems FWIS to be actually the case) to focus on managing the production line rather than on managing customer expectations. It's worth bearing in mind that ERX customers are likely, for the same historical reasons by which they have become ERX customers, to be involved directly with the RIR rather than via their ISP as LIR. [ Hmm, the emergence of the Address Policy WG seems to be just what I needed. ] It seems to me that a useful view of the ERX project and its progress would be a set of graphs derived from a table like the one below; needless to say, my numbers can't be related to reality except by co-incidence. Reporting Period (Month or Qtr) 2003.01 2003.02 ... Estimated work (contact count) 8000 8251 ... (estimate may evolve) Estimated work (network count) 215 216 ... Completed work (contact count) 0 57 ... Completed work (network count) 0 16 ... The graphic would show clearly, for two different measures of the work involved, both the estimated and (cumulative) completed work at each reporting instant. The gap between the estimated and completed work would show how much was left to be done. Hopefully, the curves would converge! I haven't been able to find such a simple overview in the material I've located on the web, or in the nice Member Update which Leo has kindly had sent to me. I think presentation of this kind of information would help customers anticipate ERX progress in the foreseeable, rather than indefinite, future. It would also be useful to know in what order the different /8 blocks are to be dealt with, what criteria have led to choosing this order, and how soon each /8 is expected to be finished, at least as planned at present. I expect that the plan may evolve in the light of experience, and that some blocks of space will prove more troublesome than others. There may be scope for taking advantage of the usual 80/20 result/effort ratio. I expect that the information I would like to see presented must already be in use to manage the project, and so should not require significant extra effort to prepare. It's probably a good idea for me to say that I'm just looking for information, not trying to paint anyone into a corner. [ As you can probably guess, I'm really only interested in 137.43/16, 8-) ] I hope these suggestions help. I expect to come to Amsterdam for the first week in September, and look forward to seeing some nice graphs! Best regards, Niall O'Reilly PS. FWIS: From where I sit.

2 1

Re: [address-policy-wg] IP Addressing policy on personal contact info (kf)
by Michael.Dillon＠radianz.com 20 Aug '03

20 Aug '03

>and I would like to discuss on how we should do with personal contact >information in the RIPE db. The db should only contain the contact information of people who are ready, willing and able to communicate regarding network issues and who are able to act on that communication. This means that much of the existing contact information in the db would disappear and LIRs would formally have the responsibility of relaying communications to their downstream networks. Some of these downstream networks MAY still be in the db but the network contacts MUST agree to be listed and MUST agree to be ready, willing and able to communicate regarding network issue and MUST be able to act on that communication. This would clean most of the useless garbage out of the db, solve the privacy issues, and focus the LIR's attention on the true purpose of the db. The RIPE db is not a general purpose telephone book, it is a contact directory for a specific purpose which is required by TCP/IP internetworking activity. There is no point in including contact data for people who are not ready, willing and able to communicate or who are not able to take any action. RIPE has a direct relationship with LIRs so there is the possibility to force them to have someone who is ready, willing and able to communicate and able to take action. Some LIRs may choose to force their customers to also provide such a contact person, but there is nothing wrong if an LIR chooses to be the direct contact for all of their customers. --Michael Dillon

6 6

Draft agenda Address Policy Working Group RIPE 46
by Hans Petter Holen 20 Aug '03

20 Aug '03

Dear WG; Here are some items for a draft agenda, please send me comments as soon as possible; - wg-charter - policy process - PI policy - initial IPv4 allocation size - RIR- IANA relationship and procedures - RIPE-152 Charging by local registries - Final revised IPv4 policy

5 9

Re: [address-policy-wg] Re: ICANN vs RIPE NCC, was Re: Summary of the PI ......
by Bovio＠aol.com 19 Aug '03

19 Aug '03

In a message dated 11/08/03 17:51:19 W. Europe Daylight Time, daniel.karrenberg(a)ripe.net writes: > I have not stopped listening to concrete ideas about improving the RIPE > NCC. > > I am still here at the RIPE NCC working and listening. Of course the > bureaucratic developments you sneer at *do* happen to some degree. This > is inevitable and both you and I know it. The ability of individuals > like you and me to influence things immediately and directly is reduced. > Of course I personally I do not agree with all things the RIRs do and > more often I do not agree with *how* things are done. > > What seems to divide us is that I still work to improve the 'least of > all evils' structure and you sneer at it providing no alternative. > I would hope that more people will chose the former instead of the latter. > I also hope that people still see the relative mertis and the > differences in legitimacy that exist between the various organisations. > Sneering at the RIPE NCC without suggesting either alternatives or > improvements does not help. > I stand 100% with Daniel here. I can't speak for the others RIRs but I strongly believe the RIPE-NCC has made significant efforts in the recent past to listen to its membership, streamline procedures, and positively react to constructive criticism. There is more work to do, no doubt about it, but I can't see how flaming on mailing lists helps. Whomever has concrete ideas: I propose we move this discussion to the ncc-services-wg list/group, that was created exactly for this purpose. Daniele

8 15

Web archive of PI Task Force now available
by RIPE NCC WebMaster 18 Aug '03

18 Aug '03

Dear Colleagues, As requested, the RIPE NCC has made the discussions of the PI Task Force available as a web archive. You can find the archive at: http://www.ripe.net/ripe/mail-archives/pi-tf/ The PI Task Force was established by the LIR WG at RIPE 44. Its purpose is to review the policy for Provider Independent (PI) address space. Regards, RIPE NCC Webmaster www.ripe.net ==================

1 0

Draft: "status:" re-evaluation
by Shane Kerr 15 Aug '03

15 Aug '03

All, We recently proposed changes to the "status:" attribute values in the RIPE Database: http://www.ripe.net/ripe/draft-documents/status-attributes.html We have received input from APNIC on the subject. They proposed a simpler layout, and we think their suggestion makes sense. However, we would like to go forward with a slightly modified version that incorporates the "organisation" object we are working on. In the meantime, we do not want to delay the implementation of the Sub-Allocation policy. For that reason we'd like to have an interim status attribute value for that. Proposal: Add "SUB-ALLOCATED PA" to the allowed "status:" values. "SUB-ALLOCATED PA" inetnum object may have an "ALLOCATED PA" or an "LIR-PARTITIONED PA" less specific inetnum object. A range of IP's can only have a single "SUB-ALLOCATED PA" in it. That is, you cannot sub-allocate twice. -- Shane Kerr RIPE NCC

6 9

Policy making process
by Hans Petter Holen 15 Aug '03

15 Aug '03

Dear working group, In the beginning there was no documented process of making policy. At some point I started outlining the process in http://www.ripe.net/ripe/wg/lir/howto_develop.html The experience since then is that a couple of elements should be added to this - not necessarily to make a biger or more complicated process, but with the incentive to make the process more open and more transparent. * Proposals should be circulated in writing to the mailinglist in advance of the meetings. Currently we have started calling for contributions and requestion proposals. * There should be detailed technical discussion on the mailinglist before a proposal can be adapted * All policies should be published as RIPE documents * All RIPE documents setting new policies should be published as drafts before becoming final -hph

1 1

IP Addressing policy on personal contact info (kf)
by Katri 14 Aug '03

14 Aug '03

Hello, I saw at RIPE 44 LIR WG Session regarding IP Addressing policy for always-on (residential broadband) Leo said the following: L.V : This should be registered in the database. If it's a residential user, their personal contact information cannot be registered in most countries due to the Data Protection laws. The Database object could then point to contact data at the ISP without identifying customer by name. This should be discussed by the WG if anyone is concerned by this. and I would like to discuss on how we should do with personal contact information in the RIPE db. I don´t only mean residential braodband services but all kind of services that might be available to customers. Should we or should we not register personal contact information that might conflict with Data Protection laws in some countries? How has it been solved earlier? What sort of criterias/ rules should we as an ISP have for the contact data? Regards Katri Forsberg Tele2/Swipnet IP Registry Local Internet Registry __________________________________________________________ Tele2/SWIPnet Tel: 08 5626 40 08 Box 62 Fax: 08 5626 42 10 164 94 Kista Email: ip(a)swip.net SWIP-RIPE SWIPNET-LIR-MNT __________________________________________________________

1 0