March 2001 - lir-wg - mailman.ripe.net

Summary: Fixed Boundary (/29) Assignments
by Mirjam Kuehne 19 Sep '01

19 Sep '01

Dear LIR-WG, Here is an attempt to summarise the recent discussions on this mailing list regarding possible fixed size assignments. Following a review of the comments, it looks like the majority does not believe that a special assignment policy is needed. Most contributors agreed that there is no need to make a distinction in policy relating to different access methods. All assignments should be made on actual needs and according to the current IP address policies. The comments showed concerns about the administrative procedures required for these kinds of assignments. However, it was felt that these addresses need to be accounted for in some way. A possible way forward would be to initiate discussion surrounding the set of information necessary to justify these assignments while providing an efficient way for the LIRs to provide services to their customers. I realise that I did not touch on every aspect of the discussion but I hope that this is a fair summary in order for you to move forward Looking forward to a continuation of this debate. Best Regards, Mirjam Kuehne RIPE NCC

3 2

Call for agenda items & draft agenda
by Hans Petter Holen 11 Jul '01

11 Jul '01

Dear WG, I would like to bring to your attention the upcoming working group meeting in Bologna, likely to be on Wed May 2nd. Please suggest agenda items that needs to be discussed to the mailinglist. Draft Agenda 1.Admin - scribe, participant list, charter, mailing-lists 2.Agenda 3.RIPE 38 minutes & actions 4.Report from the RIPE NCC Hostmasters by Nurani Nimpuno 5. 17th of May Task force - goal reached or what to do next ? 6. Report from The ASO: AC happenings and GA 7.Closure of the ICANN ad Hoc Group on numbering 8.Election of WG Chair and co-chair Actions from last meeting: 35.4 NCC PGP Key exchange procedure 35.5 NCC Implement PGP for hm 36.5 Chair Assignment window applied on infrastructure 36.6 AP Collect arbitrators 36.7 NCC Keep lir-wg updated on pre RIR address space changes 37.1 WG Further discuss restoring the transparency 37.2 NCC Incorporate IESG/IAB proposal into IPv6 policy 37.3 M17 Work with the RIPE NCC to implement suggestions

1 4

Re: Modifying references to contact info in the RIPE DB
by Wilfried Woeber, UniVie/ACOnet 24 Jun '01

24 Jun '01

Hi Joao! >If the reference is by name then when I query the DB I will get the list of >persons with that name, right? Right. >Whether the object belongs to the person or not is not going to save this >person from being contacted. From the point of view of the database and the >user querying it, the object belongs to that person. Right >The link is via a name. > >Now we substitute the reference by name with a reference by nic handle >pointing to the same person. >What is the difference? > >ALMOST NONE except that: True, for the case where there is a strict one-to-one mapping, e.g the recursion using the name returns *one* object. What do you suggets to do with the case where the recursion, based on the names, returns a *set* of objects? I can see 2 approaches (at least): - do not perform the handle substitution for that referring object and put it on the list of those requiring human intervention - expand the xxxx-c: list (which? the tech-c:?) to refer to *all* objects, but by ref'ing their handles While human beings are quite clever in selecting the "proper" instance of a person: object (by looking at country, address, email,...) a script might be quite clueless with that respect :-) Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB (&NIC) Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 --------------------------------------------------------------------------

3 3

IP Management Tool - Minimum Requirements
by Maldwyn Morris 06 Jun '01

06 Jun '01

Hello everyone, Guy wrote: > > I am officially asking Mal to please repost the > current requirements back up on this list. [...] Happy to oblige. Cheers, Maldwyn Morris Software Manager RIPE NCC -- Hi, Following a presentation of an IP Management Tool by Guy Vegoda at the last RIPE Meeting Tools BOF, interest was expressed in the development of an Open Source version of such a tool and I agreed to use the lirwg list to try and draw up Requirements for this. Hopefully this can be refined into something that we can then begin writing Specifications for. Please remember that these are *Requirements* - i.e. what the users want the tool to do. Please confine remarks to this area and avoid mixing in the *Specifications* - i.e. how those requirements will be met - which we will come to, in good time. It should also be emphasised that we would at this stage like to concentrate on _minimum_ requirements for a simple tool, such that it would be useful to a large number of LIRs. I think we can use these Minimum Requirements to produce something that may or may not include more advanced features as well, knowing that we would at least have covered the basic needs. Comments on this process and the document are most welcome, and we would also like a good name. Thanks to Guy Vegoda, Leo Vegoda and Nigel Titley for their help in drawing up this document, and especially to Guy for presenting his tool. Cheers, Maldwyn Morris Software Manager RIPE NCC -- Minimum Requirements for an IP Management Tool ---------------------------------------------- 0. Introduction Guy Vegoda presented an IP Management Tool at the Tools BOF at RIPE 38 [1]. This document is an attempt to specify the minimum requirements for a similar tool, with the aim of producing an Open Source version for anyone who wants to use it. Below, I address 1. General Points about the project, 2. The Requirements themselves, 3. External Constraint that must be considered, and 4. A list of References. 1. General Points Name: Let's use IPMT ( IP Management Tool ) as a placeholder for now. Users: We will target as users 'The Hostmaster staff of Local Internet Registries which are Customers of the RIPE NCC and who need to manage their IP Allocations and Assignments and the requests for same that they send to the RIPE NCC' [phew]. We will call one of these people a 'LIRHostmaster' and their organisation an 'LIR'. It may also be useful to other people in other organisations to do other things, but that will not influence the requirements. Open Source: We will release this software under the LGPL licence [2]. We use this instead of GPL [3] because this means we will remain able to using non-GPL'ed libraries, should that prove necessary. The RIPE NCC is happy to support this project, but of course its Open Source nature means anyone else can use the code to begin their own Open Source project. We are also happy about that. IPV6: We would be foolish not to consider the possibility of using this tool for managing IPV6 addresses and writing it such that this is possible, but we think it will be useful even if it does not and do not consider IPV6 support a requirement. 2. Requirements General functionality: IPMT should provide the LIRHostmasters with list, create, update, and delete access to information regarding their LIR's IPV4 allocations. These actions must be undoable where necessary. Basic validity checks will be performed on all input. IPMT should provide the LIRHostmasters with list, create, update, and delete access to information regarding their LIR's IPV4 assignments. These actions must be undoable where necessary. Basic validity checks will be performed on all input. IPMT should allow the LIRHostmasters to receive requests for IPV4 assignments from the customers of their LIR and allow them to process them. IPMT should allow LIRHostmasters to send well-formatted email requests for new IPv4 assignments to the RIPE NCC and allow the LIRHostmasters to receive and process responses from the RIPE NCC. IPMT should allow LIRHostmasters to send well-formatted email requests for new IPv4 allocations to the RIPE NCC and allow the LIRHostmasters to receive and process responses from the RIPE NCC. User Interface: LIRHostmasters should be able to conveniently access IPMT functions from a wide range of Desktop Operating Systems, possibly including non-modern, non-Unix-like ones. A GUI interface is the minimal acceptable convenience level. A less-convenient interface to IPMT for more complex functions and administration is acceptable. 3. External constraints The RIPE NCC only accepts requests for new IPv4 Assignments and Allocations via email to hostmaster(a)ripe.net and replies only via email [4]. IPV4 Assignment requests must be in RIPE 141 format [5]. Requests for new IPV4 Allocations have no special format. LIRHostmasters handle customer requests for Assignments via telephone, email and web pages. IPMT must have access to the RIPE DB [6] or a local mirror thereof. 4. References [1] http://www/ripe/meetings/archive/ripe-38/index.html [2] http://www.gnu.org/copyleft/lesser.html [3] http://www.gnu.org/copyleft/gpl.html [4] http://www.ripe.net/ripencc/mem-services/registration/status.html [5] http://www.ripe.net/ripe/docs/ripe-141.html [6] http://www.ripe.net/ripencc/pub-services/db/

3 2

Management of the working group
by Hans Petter Holen 04 Apr '01

04 Apr '01

Dear lir-wg, as just expressed at the wg meeting, I think it is appropriate to suggest some formalities for the wg to elect its chairs. My proposal is as following: 1) Open nominations on the lir-wg mailinglist 2) Optional discussion and support statements 3) Election of chair and 1-2 co chairs at the next lir-wg meeting in Bologna. 3b) The election to be performed either open ballot or by secret ballot if demanded by one or more participants at the meeting 3c) The election to be confirmed by consensus by the wg after the election result have been duly counted by a counting team from the audience. 4) That we perform such an election annualy to ensure the community support to the wg chairs. As the meeting expressed support towards such an idea, I would like to hear the opinions of the wg on theese matters before proceeding. Sincerely, Hans Petter Holen lir-wg Chair

6 10

RE: Another issue related to the migration
by Lu, Ping 03 Apr '01

03 Apr '01

Andrei, The existing ripe2rpsl tool will automatically translate "AS-" to "ASN-" for the aut-num object and I think "ASN-" is more meaningful than "AS_". Best Regards. Ping Lu Cable & Wireless Global Network Tools and Analysis Group, USA W: +1-703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: Andrei Robachevsky [mailto:andrei@ripe.net] > Sent: Thursday, March 29, 2001 11:10 AM > To: db-wg(a)ripe.net; routing-wg(a)ripe.net; Migration TF; lir-wg(a)ripe.net > Subject: Another issue related to the migration > > > Dear Colleagues, > > [Apologies for duplicate messages] > > One issue related to RIPE-181 to RPSL migration escaped our > attention and has > not been discussed. It is related to reserved prefixes that > cannot appear in > object names according to RPSL specification (RFC2622) which says: > > "Names starting with certain prefixes are reserved for > certain object types. > Names starting with "as-" are reserved for as set names. > Names starting with > "rs-" are reserved for route set names. Names starting with > "rtrs-" are > reserved for router set names. Names starting with "fltr-" > are reserved for > filter set names. Names starting with "prng-" are reserved > for peering set > names." > > Unfortunately "as-name:" attribute is an object name in RPSL > and we have 133 > aut-num objects with as-name starting with reserved 'AS-' prefix. > > Our suggestion how to deal with these objects is: > > 1. Send a message to the maintainers of these objects asking > them to change the > name to avoid conflict with RPSL specification. > 2. Give two-week notice period after which ripe-dbm will > convert non compliant > as-names using the following mapping: AS-ASNAME -> AS_ASNAME. > > This is more a "cosmetic" change as as-name is not even a > lookup key in the RIPE > Database. > > Your comments and suggestions are appreciated. > > Best regards, > > > Andrei Robachevsky > DB Group Manager > RIPE NCC >

2 1

RIPE Database Software V3.0 compliance test.
by DB-News 30 Mar '01

30 Mar '01

Dear Colleagues, If you have software that works with RIPE Database Software, then you should make sure that it works with Version 3.0, which will be put into production next month. Compliance tests are available at: http://www.ripe.net/ripencc/pub-services/db/rpsl/usercl.html More information about Version 3.0 of the RIPE Database Software and how it will affect you is available at: http://www.ripe.net/rpsl/ If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, A. M. R. Magee -------------- Database Group RIPE NCC

1 0

RE: Another issue related to the migration
by Hallgren, Michael 29 Mar '01

29 Mar '01

Hi, > > > Dear Colleagues, [...] > > Our suggestion how to deal with these objects is: > > 1. Send a message to the maintainers of these objects asking > them to change the > name to avoid conflict with RPSL specification. > 2. Give two-week notice period after which ripe-dbm will > convert non compliant > as-names using the following mapping: AS-ASNAME -> AS_ASNAME. > > This is more a "cosmetic" change as as-name is not even a > lookup key in the RIPE > Database. Yes. Agree. Been hinting customers to trash/modify such names prior to migration date - not knowing whether or not such conflict would be treated auto-magically... Regards Michael > > Your comments and suggestions are appreciated. > > Best regards, > > > Andrei Robachevsky > DB Group Manager > RIPE NCC > -- Michael Hallgren, Eng., Teleglobe, MH2198-RIPE

1 0

Another issue related to the migration
by Andrei Robachevsky 29 Mar '01

29 Mar '01

Dear Colleagues, [Apologies for duplicate messages] One issue related to RIPE-181 to RPSL migration escaped our attention and has not been discussed. It is related to reserved prefixes that cannot appear in object names according to RPSL specification (RFC2622) which says: "Names starting with certain prefixes are reserved for certain object types. Names starting with "as-" are reserved for as set names. Names starting with "rs-" are reserved for route set names. Names starting with "rtrs-" are reserved for router set names. Names starting with "fltr-" are reserved for filter set names. Names starting with "prng-" are reserved for peering set names." Unfortunately "as-name:" attribute is an object name in RPSL and we have 133 aut-num objects with as-name starting with reserved 'AS-' prefix. Our suggestion how to deal with these objects is: 1. Send a message to the maintainers of these objects asking them to change the name to avoid conflict with RPSL specification. 2. Give two-week notice period after which ripe-dbm will convert non compliant as-names using the following mapping: AS-ASNAME -> AS_ASNAME. This is more a "cosmetic" change as as-name is not even a lookup key in the RIPE Database. Your comments and suggestions are appreciated. Best regards, Andrei Robachevsky DB Group Manager RIPE NCC

1 0

Re: New Proposal
by Janos Zsako 29 Mar '01

29 Mar '01

> From owner-lir-wg(a)ripe.net Thu Mar 29 14:42:22 2001 > From: Stephen Burley <stephenb(a)uk.uu.net> Stephen, > I would like to here your comments on the following proposal. After > being in an audit and getting a list as long as my arm of broken objects > in the DB it turned out that the majority of the objects where pre RIPE > and not subject to the same checks. I therefore propose that all > inetnums without a status (being pre-RIPE there is no status) should be > marked with a new status of PR (Pre RIPE) and therefore be ignored by an > audit tool. Also all other objects prior to ripe should be flagged so as > to be ingnored in an audit, making it much easier to see what really > needs fixing. I think the idea of marking such inetnums is very good. I am just wondering whether "no status" really means "pre RIPE". I suspect it is not the case, as Daniel's document was discussed on the mailing list in May 1995 (and is dated 30 June 0995), while RIPE NCC did perform allocations much earlier as far as I remember. So my point is that the term "pre RIPE" may be misleading. What about "status: UK"? (UK for UnKnown :)) ) Janos

4 3

New Proposal
by Stephen Burley 29 Mar '01

29 Mar '01

Hi I would like to here your comments on the following proposal. After being in an audit and getting a list as long as my arm of broken objects in the DB it turned out that the majority of the objects where pre RIPE and not subject to the same checks. I therefore propose that all inetnums without a status (being pre-RIPE there is no status) should be marked with a new status of PR (Pre RIPE) and therefore be ignored by an audit tool. Also all other objects prior to ripe should be flagged so as to be ingnored in an audit, making it much easier to see what really needs fixing. Your thoughts and comments please. -- ------------------------------------------------------------------------ Stephen Burley "If patience is a virtue, and ignorance is bliss, UUNET EMEA Hostmaster you can have a pretty good life [SB855-RIPE] if you're stupid and willing to wait" ------------------------------------------------------------------------

5 5

Re: New Proposal
by Janos Zsako 29 Mar '01

29 Mar '01

> From owner-lir-wg(a)ripe.net Thu Mar 29 16:39:45 2001 > To: Janos Zsako <zsako(a)banknet.net> Stephen, > > I am just wondering whether "no status" really means "pre RIPE". > > I suspect it is not the case, as Daniel's document was discussed > > on the mailing list in May 1995 (and is dated 30 June 0995), while > > RIPE NCC did perform allocations much earlier as far as I remember. > > But in a classful enviroment. Correct. > > So my point is that the term "pre RIPE" may be misleading. > > > > What about "status: UK"? (UK for UnKnown :)) ) > > UK = United Kingdom Sure, this is why I put the smiley there. > What about CA = Classful Allocation Yes, this may be the right term, although it is not strictly related to this (if inetnum has status attribute it does not mean it is a classless allocation or assignment as classful allocations and assignments continued for another year or so after ripe-127 was published). "No status" means pre-ripe-136, dated May 1996 (as this is the document that made the status attribute mandatory) and classless assignments did start only after ripe-136 indeed, as far as I remember. Janos

1 0

Routing Workshop
by RIPE NCC Staff 29 Mar '01

29 Mar '01

CALL FOR APPLICATIONS Routing Workshop, Amsterdam, The Netherlands, 7-11 May 2001 Dear Colleagues, A Routing Workshop will be provided for RIPE NCC staff on 7-11 May 2001 in Amsterdam, The Netherlands by Cisco Systems. This is a call for applications for 14 places still available in the workshop. This workshop will be provided free of charge and includes lunches. PLEASE NOTE: Travel and accommodation are not provided or reimbursed. Who should Attend: The target audience for this course is persons in the ISP community with a basic familiarity of Cisco Systems equipment. This is a technical workshop and most suitable for those persons who are now or will soon be building or operating a wide area TCP/IP base Internet Service Provider (ISP) network or Internet eXchange Point (IXP) with international and/or multi-provider connectivity. Prerequisites: Cisco IOS fundamentals; user level UNIX and possibly some system administration and; some use of network design, preferably TCP/IP based. * Preference for this course will be given to those individuals that come from developing countries (i.e. Central Europe, Central Asia, Africa and The Middle East) Cisco Systems will select 14 participants to attend the tutorial based on the information provided in the application form enclosed below. WORKSHOP SCOPE: --------------- - Techniques for design, set-up, and operation of a metropolitan, regional or national ISP backbone network. This includes advanced OSPF, BGP4 and policy based routing. - IOS Essentials every ISP should be doing. The hidden secrets that all key NSPs have been using for years but not telling anyone (ie: competitive advantage. - Techniques for multiple connections to the Internet (multihoming), including connections to IXPs, NSP and transoceanic Internet links. - Techniques for the design, set-up and operation of a metropolitan, regional or national IXPs - Techniques to achieve optimal performance and configuration from a Cisco backbone router. This includes routing scalability, network design and configuration techniques. - Examples from a case study from successful ISPs who are making use of many of the workshop techniques. COURSE LOCATION: --------------- The course will take place at The Groot Industrieele Club, Dam 27, Amsterdam, The Netherlands The instructors for the Workshop will be Philip Smith and Duncan Rogerson. IMPORTANT DATES: --------------- * The deadline for application submissions: 11 April 2001. * Acceptance notification to selected candidates: 16 April 2001 * Routing Workshop - 7-11 May 2001 For further information about the Cisco ISP workshop please contact: Joao Silva Damas Chief Technical Officer RIPE NCC E-mail: joao(a)ripe.net ====== ROUTING WORKSHOP - APPLICATION FORM * Please submit your application form by email to <joao(a)ripe.net> with the following text as the subject: Routing Workshop First Name: Last Name: Nationality: Contact Information: - postal address: - Tel/Fax number: - email address: CV detailing ISP experience [max 200 words]: ======

1 0

IMPT
by Guy Vegoda 22 Mar '01

22 Mar '01

OK, lets get this IP tool sorted out quicky. I'm gonna set a deadline of Friday 30th of March for anyone who cares to send in their minimal requirements. After this, we will move on to specification for exactly two weeks. At the end of this period, those who wish to volunteer to do any coding will have a window to do so, and within this group, dicussions about implimentation will begin. Sorry if this seems a little bossy; it is. I just know that unless somebody gives it a kick start, this thing will fade into oblivion. There's no reason why it should do this as it could be so good. I am officially asking Mal to please repost the current requirements back up on this list. All those who would like to change, insert or delete a requirement, can then email with their changes. If you want something in, say so, and why, explicitly.. If you just say "Well, it might be nice if...", then it wont get stuck in. We need concrete, minimal requirements, that the working group can vote on. Hope this sparks some interest, Looking forward to hearing from people, Thanks everyone very much, Guy -- Guy Vegoda \ guy(a)vegoda.org *Please do not send html* NIC: GUY-RIPE \ guy(a)cryptography.org.uk *attachments* Unix, Linux Hobbyist \ +44(0)20 7961 8318 (work) www.thenakedfrenchman.com \ +44(0)958 469 532 (cell)

1 0

FW: LIR Registration
by Tramnitz＠t-online.de 20 Mar '01

20 Mar '01

I sent the mail below to ncc(a)ripe.net and didnt get an answer up to now, so I'm wondering if anyone in this list may help or could give us some notes. tia >>>>>>>>>>>>>>>>>>>>>>>> Dear Ladies and Gentlemen, we plan to become LIR in the very near future and have some questions concerning registration and status issues. Currently we deploy VPN-connections over WANs and the internet for customers, including centralized internet-gateway and hosting services. As we grow, the needs of our customers grow exponentially, forcing us to provide redundant internet-access at our internet-gateway and hosting location here in Berlin. For this need, we plan to connect to (in the first step) two upstream providers and get an fully internet-routable addressblock. As you state in Ripe-Document 142 the use of PI-address-space in an AS would be suitable for this, but as you say in the same document you do not guarentee the ability to route this address-space in the whole internet. But exactly this guarantee is what we need to provide our customers the service-level-agreements they expect. So we can't only use this PI-address-space but instead become LIR and get our own allocated address space in an order of magnitude that is routed in the internet. Our question is now, what is the real difference between enterprise LIR and small provider LIR? We do not plan to assign customers address-space besides RFC1819 nets for LAN-2-LAN connections through VPNs but only assign addresses for hosting, housing and VPN-Connections through the internet. The second question is, if we would get *at all* an addressblock /19 if we cant show up a plan that we will use an certain amount of this address in e.g. 48 months which will be true in our current considerations. Sincerely, Christian Tramnitz

2 1

Re: IP Management Tool - Minimum Requirements
by Guy Vegoda 06 Mar '01

06 Mar '01

> Would there not be intellectual property difficulties if you > wrote a similar system for another company? > > Niall > > (Interested but also enmeshed in IP problems) I guess that depends on how similar you mean by similar (-: I don't think IPMT will be anything like Robo-Bijal, code-wise. (Not least because: (1) I will not be the only coder, (2) Manuel's IP libraries are open source, (3) It will probably support IPv6, which Robo-Bijal doesn't, and (4) I would like to do it in OO perl. ) So should hopefully all work out. Guy -- Guy Vegoda \ guy(a)vegoda.org *Please do not send html* NIC: GUY-RIPE \ guy(a)cryptography.org.uk *attachments* Unix, Linux Hobbyist \ +44(0)20 7961 8318 (work) www.thenakedfrenchman.com \ +44(0)958 469 532 (cell)

2 1

RIPE RPSL transition date set!
by SchmitzJo＠aol.com 05 Mar '01

05 Mar '01

Hello all, following up on our last call for comments on the RPSL transition for the RIPE database, we did not receive any mails or information which may have delayed the transition. In contrast, we received a set of supportive mails. Accordingly, the transition to RPSL will now follow the outlined dates: o 23-Apr-2001: switching to the RPSL database *** now set *** - All objects are automatically converted to RPSL format - Queries return RPSL only - Mirroring follows new format and rules at whois.ripe.net, port 4444 - RPSL formatted updates can be submitted to auto-rpsl(a)ripe.net - RIPE-181 updates are still accepted at auto-dbm(a)ripe.net, but are autmatically converted to RPSL - RFC2725 (Routing Policy Security System) rules apply throughout o 14-May-2001: exchanging mail addresses for submitting RIPE181 and RPSL-formatted updates - auto-dbm(a)ripe.net only accepts RPSL updates - RIPE-181 updates are still possible but now go to auto-181(a)ripe.net and are automatically converted to RPSL (again, RFC2725 rules apply here as well) o 15-Oct-2001: RIPE-181 updates are no longer accepted For further reading, please refer to the migration web page http://www.ripe.net/rpsl We will continue to update you prior to the dates detailed above. Thanks - the RIPE NCC and the chairmen of Routing: Joachim Schmitz DB: Wilfried Woeber LIR: Hans Peter Holen

1 1

Re: Refuse een assignment because it 'cannot' be routed?
by Wilfried Woeber, UniVie/ACOnet 05 Mar '01

05 Mar '01

To continue that (cute | silly | pick-your-choice) analogy... => I only want a fixed frontdoor (1 fixed IP address), but I am trying to force => my landlord into letting me have it without paying tripple rent, by asking => the government (RIPE) to give me a building permission to install more => doors. Not because I want more doors, but to keep the landlord from moving => my single door every day :) => = =Hi, = = Hmm... this analogy isn't correct. RIPE is not the government in this. =RIPE, or your local LIR can give you a door (address assignment), but =you still need to get a permit from the local counsil to place it =(Getting your service provider to actually route it). = =One of the things your local LIR may require before selling you a door =is having a permit. Buying the door somewhere else (RIPE) does not =automagically entitle you to a permit. ...what we are seeing in reality, though, is something like the "government" (the RIPE NCC) coming back with a question about the colour and style of the door. And - depending on your answer - either going ahead issuing a _permanent_ permit for e.g. an Ethernet- or leased-line-style door ("static"), but limiting the validity of the permit for an xDSL- style or dial-up door to as long as you, or someone from your family, happens stay at home ("dynamic"). As soon as you go to work, or even worse - take a couple of days off, duhh!!! - you have to submit another application for installing a door. And, the "government", suggests to the manufaturers of the doors (and/or to the landlord), to give you a call on the phone every, say, 8 hours, to confirm that you haven't left for shopping (physicly) or turned to RTFM (virtually/mentally logging off). That's exactly what happens to me, back home, with my ADSL link being dropped every 8 hours by the ISP *on purpose*, because the NCC sort of "suggests" to the ISPs to use dial-up ratio mechanisms for 24x7 xDSL, flat rate billing. Very clever, indeed, in particular when someone tries to do stuff that is security-aware. But I have beaten that one to death before (technology independence of assignment rules). Sigh... Wilfried. _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Träume darf man nicht verbieten, sonst werden sie Wirklichkeit...

3 3

Re: RIPE: last call for comments RPSL transition
by SchmitzJo＠aol.com 02 Mar '01

02 Mar '01

Dear Christian, you wrote: > well I'd say go for it. Thank you for your support. > But let me kindly ask for the following thingies: > > since the RIPE-NCC is now in charge of the maintenance of the RAtoolset > please make sure that there's a release available (specifically > RTconfig) which is fully compatible with the RIPE RPSL server by mid of > March 2001 latest. I believe that this request is more than legitimate, and that the NCC is hearing you very well - after all it is in all our interest to have this running. > > It appears that this might be available already (since Feb20 ?), > however, the link to > > "RtConfig Patch for the RAToolSet" of the "RPSL Migration" homepage is > broken. This is currently worked on, as I hear. > > In addition, any clear links to concise How2do documents on RAToolSet > and RtConfig would be appreciated. On the one hand, I think the best source for that still is http://www.isi.edu/ra/RAToolSet/ On the other hand, we will have a tutorial on the RAToolSet during RIPE39. This has been confirmed by now, and I believe that additional documentation will become available around it. Thanks Joachim --- JS395-RIPE -- standard disclaimer ---

1 0

Re: RIPE: last call for comments RPSL transition
by SchmitzJo＠aol.com 02 Mar '01

02 Mar '01

Dear Ping Lu, you wrote: > We had a lively discussion about the RPSL transition during the RIPE-38 > meeting. This is correct, and I very much appreciate the input you provided during our joint working group session. > Well, if we can't fight them then the best thing to do is to join them. Do I need to be worried now? I never considered this to be a fight ;-) > With the company's support behind us, we (Cable & Wireless Global) as a > legacy LIR (used to be MCI) > would like to work with RIPE to help the RPSL transition. > > CW will adopt a similar schedule as RIPE's to transform our Routing Registry > into the new RPSL format. > This will probably make all the mirroring LIRs' job much easier and > hopefully all the downstream ISPs happier (only the RPSL format to deal > with). > > So GO FOR IT. I welcome your approval. I believe I do not exaggerate stating that you can count on the support from the RIPE community and the NCC in particular in the transition effort. Thanks Joachim --- JS395-RIPE -- standard disclaimer ---

1 0

Refuse een assignment because it 'cannot' be routed?
by Herbert Baerten 02 Mar '01

02 Mar '01

Dear colleagues, in the discussion about assigning fixed address space to residential always-on customers, I concluded that most ISPs are eager to provide their customers with this service, even using it as a weapon in the competition battle. However in some countries apparently the contrary is going on. All ISPs there offer 2 classes of DSL service: cheap subscriptions (low traffic, dynamic ip, no options) on one hand and an expensive 'pro' contract (high traffic volume, static ip, router etc.) on the other. Now a customer would like to get a static ip but does not want the router, large volume etc so he does not want to pay 4 times as much per month (real-life example) just to get a static ip. If the customers sends a RIPE-141 request to the ISP, can the ISP assign a range but not route it to the customer? Can it refuse the request on the grounds that it cannot route the assigned range to a dynamic ip? Or is the ISP obliged to assign a range and route it (no matter how, presumably by assigning the customer a static ip anyway) ? With or without additional (reasonable?) cost to the customer? tia best regards, Herbert -- HB5351 Herbert Baerten Network Manager HostIT Benelux

4 7

RE: RIPE: last call for comments RPSL transition
by Christian Panigl, ACOnet/VIX/UniVie 01 Mar '01

01 Mar '01

Hi Joachim, well I'd say go for it. But let me kindly ask for the following thingies: since the RIPE-NCC is now in charge of the maintenance of the RAtoolset please make sure that there's a release available (specifically RTconfig) which is fully compatible with the RIPE RPSL server by mid of March 2001 latest. It appears that this might be available already (since Feb20 ?), however, the link to "RtConfig Patch for the RAToolSet" of the "RPSL Migration" homepage is broken. In addition, any clear links to concise How2do documents on RAToolSet and RtConfig would be appreciated. Thanks and kind regards CP --- ---------------------------------------------------------------------- --- --- Christian Panigl : Vienna University Computer Center - ACOnet --- --- VUCC - ACOnet - VIX : -------------------------------------------- --- --- Universitaetsstrasse 7 : Mail: Panigl(a)CC.UniVie.ac.at (CP8-RIPE) --- --- A-1010 Vienna / Austria : Tel: +43 1 4277-14032 (Fax: -9140) --- --- ---------------------------------------------------------------------- ---

2 1

RE: RIPE: last call for comments RPSL transition
by Lu, Ping 01 Mar '01

01 Mar '01

Hi, Joachim, We had a lively discussion about the RPSL transition during the RIPE-38 meeting. Well, if we can't fight them then the best thing to do is to join them. With the company's support behind us, we (Cable & Wireless Global) as a legacy LIR (used to be MCI) would like to work with RIPE to help the RPSL transition. CW will adopt a similar schedule as RIPE's to transform our Routing Registry into the new RPSL format. This will probably make all the mirroring LIRs' job much easier and hopefully all the downstream ISPs happier (only the RPSL format to deal with). So GO FOR IT. Ping Lu Cable & Wireless Global Network Tools and Analysis Group, USA W: +1-703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: SchmitzJo(a)aol.com [mailto:SchmitzJo@aol.com] > Sent: Friday, February 16, 2001 6:46 PM > To: routing-wg(a)ripe.net; db-wg(a)ripe.net; lir-wg(a)ripe.net; > local-ir(a)ripe.net > Cc: andrei(a)ripe.net; joao(a)ripe.net; hph(a)a.sol.no; > woeber(a)cc.univie.ac.at; schmitzjo(a)aol.com > Subject: RIPE: last call for comments RPSL transition > Importance: Low > > > Hello all, > > as you are aware, we are preparing the migration of the RIPE database > software to support and deploy the new RPSL format. The required steps > have been discussed in depth on various occassions (for references, > see end of mail). > > We are now preparing the most important step, really > transitioning from > old > RIPE-181 to new RPSL format: > > proposed transition date is 23-Apr-2001. > > This step, once taken, will not be reversed. The majority of the user > community takes a neutral role, while some want an earlier, > and a few a > later > date for migration. During the joint session of Routing and DB WG at > RIPE38, > the chairmen of both WGs were tasked to file a last call for > comments on > that > date, in particular whether there are serious, unresolvable > technical or > operational problems which would benefit from a slightly > longer warning > period. > > According to consensus at the session: If you are convinced that the > transition date as proposed would lead to significant operational > problems, please explain and justify why within the next 2 weeks: > > deadline for transition comments: 1-Mar-2001 > > Only well founded reasoning (including an educated guess > about the time > and resources required to resolve the issue) shall be accepted by the > community in order to consider postponing the transition. > > With the discussion about the migration going on for quite > some time, and > information available from various places, we do not expect a > delay, but > we would want to give everybody a last opportunity to comment. > > To summarize the dates, we are looking at: > > o 23-Apr-2001: switching to the RPSL database > - All objects are automatically converted to RPSL format > - Queries return RPSL only > - Mirroring follows new format and rules at > whois.ripe.net, port 4444 > - RPSL formatted updates can be submitted to auto-rpsl(a)ripe.net > - RIPE-181 updates are still accepted at auto-dbm(a)ripe.net, > but are autmatically converted to RPSL > - RFC2725 (Routing Policy Security System) rules apply throughout > > o 14-May-2001: exchanging mail addresses for submitting > RIPE181 and RPSL- > formatted updates > - auto-dbm(a)ripe.net only accepts RPSL updates > - RIPE-181 updates are still possible but now go to > auto-181(a)ripe.net > and are automatically converted to RPSL (again, > RFC2725 rules apply > here as well) > > o 15-Oct-2001: RIPE-181 updates are no longer accepted > > For further reading, please refer to the migration web page > http://www.ripe.net/rpsl > or for the discussion during the joint session of the DB/Routing WGs > please review the minutes. > > For technical specifications of RPSL please refer to > - rfc2622: "Routing Policy Specification Language (RPSL)" > Status: PROPOSED STANDARD, > - rfc2650: "Using RPSL in Practice" > Status: INFORMATIONAL > - rfc2725: "Routing Policy System Security" > Status: PROPOSED STANDARD > > Thanks a lot - the RIPE NCC and the chairmen of > Routing: Joachim Schmitz > DB: Wilfried Woeber > LIR: Hans Peter Holen > >

2 1