September 2000 - lir-wg - mailman.ripe.net

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

ANNOUNCEMENT: Public Release of Asused
by Maldwyn Morris 22 Sep '00

22 Sep '00

Hi, The RIPE NCC are pleased to announce the release of a new public version of Asused - this is Version 3.52. Asused is a tool to check and summarise address space registered in the RIPE database. For a given list of allocations the tool prints various information concerning the allocations and the assignments they contain. The software is written in standard Perl 5 and uses several Perl modules. It was written and tested on BSD/OS 3.1, but should work with any modern UNIX-like operating system. All the files needed are stored in this file: ftp://ftp.ripe.net/tools/asused-3.52.tar.gz or alternatively, just: ftp://ftp.ripe.net/tools/asused-latest.tar.gz You will need to use gzip and tar to extract them, then please follow the instructions in the README file. The changes since Version 3.51 are: * No longer designated as beta software. * Fixed problem with huge free address space reports, caused by bug in the Whois DB - "-Tin" returns rev-srv: A.B.C.D fields as well. * Fixed problem with RIPEWhois.pm module, which didn't return anything on some Linux'es. Was reported several times, visible effect was: FATAL ERROR: ERROR: 10.65.0.0/19 No allocation object in DB, inetnum found * Fixed small compatability problem - some systems don't let to use IO::Socket::INET directly, so, turned that into "use IO::Socket". * Put the CPAN IO module IO-1.20.tar.gz into extra/ directory, as some Perl distributions come with outdated modules and CPAN suggests perl5.6.0 as an update :> * Added --free flag to show only free address space list. * Produce a warning if a registry doesn't have mnt-lower attribute on it's allocation. * Fixed the case that --status didn't report assignments with missed status lines and gave incorrect balance. Thanks to the following people for bug reports and suggestions: Elmar K. Bins Jean-Francois Stenuit Dominic Mitchell Daniel N. Rasmussen Johannes Dagemark Timur Bakeyev of RIPE NCC did the programming. We are keen to receive your further feedback on this software - please address your comments and/or suggestions to me. Cheers, Maldwyn Morris maldwyn(a)ripe.net Software Manager RIPE NCC

1 0

LIR-WG Plenary report
by Hans Petter Holen 15 Sep '00

15 Sep '00

Dear workinggroup, As we ran seriously out of time both in the workinggroup itself and in the plenary report, I am posting my slides for you all to view for the full report. It will soon also be up on the RIPE web site. http://home.online.no/~hph/RIPE Sincerely, Hans Petter Holen

1 0

Re: IAB/IESG Recommendations on IPv6 Address Delegation
by Turchanyi Geza 13 Sep '00

13 Sep '00

Fred, I would like to add a few comments and a proposal to your marvellous summary. (Even if it is very difficult to say anything at this stage). Comments: 1, The IPv6 address scheme might be valid for two centuries or even longer, and not only for 50 years. 2, The proposed "sparce allocation for subsribers (sites)", "dence allocation for providers (networks)" should work very well for customers, however, not necessarly for providers. You mentioned already the multihoming issues. There is an other open issue: how to scale effectively the routing. Proposal: I suggest adding a clause to your summary: ADDRESS ALLOCATION POLICY will be reviewed every five years. If different address allocation policy will be set up for any reason, then all subscribers and providers having already address space should adopt themselves to the new policy within TEN years, the latest. If they do not adopt, their not properly allocated address space will be blocked from the global routing. Many thanks for your time, best regards, Geza Turchanyi

2 1

Discussion: Address Council election procedures
by Hans Petter Holen 13 Sep '00

13 Sep '00

On the topic of > Call for Nominations for Representatives to the ASO Address Council - > RIPE NCC Region We have a some desicions to make at the upcoming meeting on - when to do the elections - how to do the elections > 4. Address Council Nominations Process (...) > Nominations should be sent by email to <nominations(a)ripe.net>, by midnight > CET on 30 September 2000. (...) Due to the timeconstraints we unfortunately have ended up with we cannot hold the election at RIPE 37 but will have to do it at a later stage. We can either delay the election to RIPE 38 next year, or we can do some sort of electronic voting between the RIPE meeting and the to ICANN meeting in november (as the ICANN meeting in november would be a convenient place gather the Address Council for a meeting to hand over responsibilities from the 3 members potentialy leaving their seats.) My understanding of the consensus from the previous meetings was that electronic voting was felt to be not yet widely deployable technology. But we may want to reconcider that with experiences from the ICANN at large election and perhaps from ARINs and APNICs plans. > 5. Address Council Selection Process > - ------------------------------------ > > The process for selection of the nominee to serve on the Address Council > will involve an open election. Due to the 90 day lead time needed for a call > for nominations prior to a RIPE NCC region policy meeting, the selection > process will not be held at the RIPE 37 meeting, 12-15 September 2000, in > Amsterdam. > > Two selection processes have been proposed. The first follows the voting > process outlined in the MoU. The selection procedure would take place at the > RIPE 38 meeting in January 2001 in Amsterdam. The second process currently > being discussed involves implementing an electronic voting procedure as it > would allow for more participation in the selection process and could > bring the process forward. This procedure would be discussed prior to > the RIPE 37 meeting and announced in the LIR-WG meeting. > Hans Petter Holen, LIR-WG Chair, > will initiate discussions about this procedure on the lir-wg mailing list. > > Important Dates: > > 30 September 2000 - deadline for Address Council nominations Sincerely, Hans Petter Holen lir-wg chair

3 5

Draft Agenda LIR-WG 37
by Hans Petter Holen 12 Sep '00

12 Sep '00

1. Admin scribe, participant list, charter, mailinglists 2. Agenda 3. Meet the RIPE NCC hostmasters 4. RIPE 35 minutes actions 5. Reports from the Registries RIPE NCC APNIC ARIN ICANN Status of the Latin and AFRI NiCs 6. Report from the address council 7. Presentations of candidates for the AC election 8. Status of the ICANN ad Hoc group 9. Report from the 17th of may Task Force 11. AOB.

1 2

ANNOUNCEMENT: Beta Version of ASinuse Web Page
by Maldwyn Morris 12 Sep '00

12 Sep '00

Hi, The RIPE NCC are please to announce a Beta Version of the ASinuse Web Page, available via the page: http://www.ripe.net/ripencc/pub-services/np/ris-index.html ASinuse lets users look up any AS number in the RIS database to show its observed peers and the time at which they were observed, and to further query those peers. Please let me know if you have any questions about this web page. Cheers, Maldwyn Morris maldwyn(a)ripe.net Software Manager RIPE NCC

1 0

ANNOUNCEMENT: Rttquery Web Page updated
by Maldwyn Morris 12 Sep '00

12 Sep '00

Hi, The RIPE NCC provides information to its members on the processing of their request tickets via the Rttquery Web Page: http://www.ripe.net/cgi-bin/rttquery This is to let you know that we have updated the page to show the given ticket's relative position in the Wait Queue, where it is put before it is given to a Hostmaster. We also now show customer labels in the ticket's messages. Any text in the Subject of a message between the opening delimiter: #{ and the closing delimiter: #} is displayed next to that message. Please let me know if you have any questions about this web page. Cheers, Maldwyn Morris maldwyn(a)ripe.net Software Manager RIPE NCC

1 0

Topics for todays ICANN ASO workshop at 1700
by Hans Petter Holen 12 Sep '00

12 Sep '00

Dear friends of RIPE; I have asked for a timeslot on this RIPE meeting to have a more informal Worksop style of environment were it is possible for those of you with particular interest in the work going on in the ICANN ASO and in the Address Council in particular. We will of course have a report from the AC in the lir-wg (as usual) and maybe even at the RIPE plenary at the RIPE chairs discretion. My thoughts behind this particular format at this particular meeting is to allow for the possibility of even more preparatory discussions in even more details than we usually have time for. Ideally I would have liked the meeting to happen later in the week, but not even the magic of the RIPE NCC meeting staff was enough for that to happen (we simply have to many competing for the same slots). The following rather broad topics lies on the Address Councils table, and will be discussed by the AC, ICANN and the RIRs at a physical AC meeting in Brisbane just after the APNIC meeting in October. This effort is thus an attempt to seek advice from the community before these discussions to satisfy the basic requirements for openness and transparency. 1) What is global policy ? There are several dimensions to this discussion: - replace RFC 2050 with a ICANN Address policy document - what is the distinction between regional and global policy - do we understand and appreciate the differences between the regional policies ? - differences between v4 and v6 with respect to the last item - what's the role/work mode of the AC ? to make the definite address policy, or to work on issues as they show up - were is the border between a service level contract and policy issues. - are there other operating guidelines for the ICANN - IANA than the global addressing policy ? 2) Revising the MOU In the widest sense: are there things in the present MOU that needs more work and needs to be changed ? 3) Addressing the essence of the ad Hoc committee, i.e. discussing how to best address new addressing needs emerging for 4) How to promote ipv6 ? 5) Emerging RIRs How to enable and support the emerging RIRs to establish regional policy processes ? The discussions in just above an hour needs not be limited to these topics. So, if you have a particular interest in influencing your AC members thinking on these or other matters, be there ! Sincerely, Hans Petter Holen Address Council Chair

1 0

Re: Call for Nominations - ASO Address Council
by Hans Petter Holen 12 Sep '00

12 Sep '00

Just a reminder of the ongoing nominations process, and an invitation to nominees and potential nominees: if you want to use this RIPE meeting to present yourselves to the LIR-wg: Please approach me to get on the agenda or if you are not able to make it to the meeting send me, 2-3 slides worth of presentation. Then I, or somebody of your choosing may present to the wg. Depending on the outcome of the election process discussion there will of course also be time to present the nominees to the list before the election. > 4. Address Council Nominations Process > - -------------------------------------- > > The term of Sabine Jaume who has served as an initial AC member for the past > year has expired. One individual from the RIPE NCC Region will be selected to > serve on the Address Council for a term of three years. The selection will be > made through an open election process, from the set of individuals who have > been nominated within this process. > > Any individual may be nominated, with the exception of any staff member of > any Regional Internet Registry. Self-nominations are permitted. > > Nominations should be sent by email to <nominations(a)ripe.net>, by midnight > CET on 30 September 2000. > > The information included with the nomination is to be in English, and > should¨include: > > Name of Nominee: > Country of residence: > Organisation: > Email Address: > Postal Address: > Biographical information: > Motivation for nomination: > > Name of nominating individual: > Organisation: > Email Address: > > All nominees will be contacted via email to confirm their willingness to > serve on the Address Council. If a nominee cannot be contacted via email, > or does not respond, then their nomination will not be confirmed and they > will not be eligible for election to the Address Council. > > All confirmed nominations will be listed on the RIPE NCC web site after they > are confirmed. All nominees will have the opportunity to submit a written > statement in support of their nomination for publication on the web site. > In addition, others may express support for nominated individuals simply by > completing and submitting the nomination form provided above. (...) > Important Dates: > > 30 September 2000 - deadline for Address Council nominations Regards, Hans Petter Holen lir-wg chair.

1 0

RIPE meeting - wait queue
by Nurani Nimpuno 12 Sep '00

12 Sep '00

Dear all, As you all are aware of, the RIPE meeting is taking place this week in Amsterdam. As the RIPE NCC hostmasters are heavily with the meeting, also using it as an opportunity to meet up with members, you might notice a slight increase in the wait queue for the coming two weeks. We are currently working very hard on reducing the number of requests in the wait queue and will use the resources as efficiently as possible during the meeting in order to minimise any effect on the wait queue. Thank you for your understanding. -- Nurani Nimpuno Registration Services Manager RIPE NCC

1 0

RE: asused question
by kevin.bates＠bt.com 11 Sep '00

11 Sep '00

Greetings Having a "mnt-by" in an object prevents anyone not in the maintainer group from changing the data for that object (i.e. an inetnum). Having a "mnt-lower" in an object prevents anyone not in the maintainer group from changing the data below that object. So, I believe, without the "mnt-lower" in an inetnum, it is possible for anyone to add additional inetnum objects into the RIPE database, below your inetnum record, and for them to put another maintainer into the addition. You could then end up with false records within your assignment that you would be unable to remove. kevin > -----Original Message----- > From: Jeroen Ruigrok van der Werven [SMTP:jruigrok@via-net-works.nl] > Sent: 03 September 2000 12:23 > To: Abdullah Saad Al-Ashry > Cc: lir-wg(a)ripe.net; db-wg(a)ripe.net > Subject: Re: asused question > > -On [20000902 10:05], Abdullah Saad Al-Ashry (abdullah(a)awalnet.net.sa) > wrote: > >When I use the utility "asused" > ftp://ftp.ripe.net/tools/asused-3.5.tar.gz > >It gives me this warning: > >**************** > >Please check the following WARNINGS: > >212.xx.xxx.0 - 212.xx.xxx.255 has mnt-lower xxxx attached > >**************** > > You probably have: > > mnt-by: MNT-BLAH > mnt-lower: MNT-BLAH > > which is ambiguous if memory serves me right. > > Just remove the mnt-lower. > > This is just a guess, since you are paranoia and removed the specifices > of your assignment [for which I really cannot find any justification > actually, the paranoia that is]. > > HTH, > > kind regards, > > -- > Jeroen Ruigrok van der Werven Network- and systemadministrator > <jruigrok(a)via-net-works.nl> VIA Net.Works The Netherlands > BSD: Technical excellence at its best http://www.via-net-works.nl > Come and take a good look deep into these thuggish ruggish eyes. See the > thugstas cry. And I'm askin' the good Lord "Why?" and sigh, He told me we > lived to die...

8 7

agenda for joint ipv6/lir-wg session
by David Kessens 08 Sep '00

08 Sep '00

Please see below for the agenda for the joint session of the ipv6 wg and lir wg on ipv6 allocation policies. Thanks, David K. ---- A. Administrative stuff - appointment of scribe - agenda bashing B. Overview of open issues and changes in the new version of the ipv6 allocation policies document (Joao Luis Silva Damas, RIPE NCC) C. Overview of IAB/IESG Recommendations on IPv6 Address Delegation (Bob Hinden) D. Panel discussion with Bob Hinden/Steve Deering/Joao. (and other people that we will approach during the meeting). Z. AOB ---

1 0

RIPE NCC Tools for Members Page
by RIPE NCC Staff 08 Sep '00

08 Sep '00

Dear Colleagues, The RIPE NCC is pleased to inform you that there is a new web page which lists the tools that have been produced by the RIPE NCC for its members' use. These tools are designed to aid members in their interactions with the RIPE NCC Hostmasters. The tools page is available at: http://www.ripe.net/ripencc/mem-services/tools/tools.html Regards, Maldwyn Morris Software Manager RIPE NCC

1 0

Frequently Asked Questions at the RIPE NCC!
by RIPE NCC Staff 08 Sep '00

08 Sep '00

Dear all, We would like to draw your attention to the extended "Frequently Asked Questions" section now available on the RIPE NCC website! This FAQ can be found at the following URL: http://www.ripe.net/ripencc/faq/index.html The purpose of this FAQ is to make information about the RIPE NCC activities and services available in a clear and comprehensible manner. The FAQ is divided into the following five sections: General FAQs New LIR FAQ Registration Services FAQ Database FAQ Reverse Delegation FAQ The FAQ has been further built out with more specific questions, pointers to applicable RIPE documents and links to relevant sections. We have also added the possibility of, through the website, sending in a question that you can not find the answer to in the current FAQ. As a member you should be able to find answers to your specific questions, but we have also aimed to answer the more general questions we frequently receive from end-users, press, LIRs and members of the Internet community as a whole. We hope that this FAQ will aid you in finding the exact piece information that you are looking for on the RIPE NCC website and clarify some of the issues that concern you. Finally, with this FAQ, we also hope to relieve some of the increasingly high workload we are experiencing at the RIPE NCC. With this membership growth, higher demand is placed on resources to educate and support new LIRs. By making this information more easily accessible, the RIPE NCC aims to ensure this support, using the resources in the organisation efficiently, without compromising on the efforts invested in the Allocation of Internet Resources to the RIPE NCC membership. Kind regards, Nurani Nimpuno Registration Services Manager RIPE NCC

1 0

ANNOUNCEMENT: Second Public Beta Release of Asused
by Maldwyn Morris 08 Sep '00

08 Sep '00

Hi, The RIPE NCC are pleased to announce the release of a second public beta version of Asused. Asused is a tool to check and summarise address space registered in the RIPE database. For a given list of allocations the tool prints various information concerning the allocations and the assignments they contain. The main changes have been to tidy the code and to merge the code ( and version number ) for our internal tool with that of the public version. The only part missing from the public version is now that which performs checks using information that is proprietary to our members. We have also fixed some bugs in the software found by internal and external users: * Free space at the beginning of an allocation was not handled correctly * Some overlapping assignments were being missed. * Assigned address space was not always calculated correctly. * Overlaps caused more than 100% usage. Thanks for the bug reports. The software is written in standard Perl 5 and uses several Perl modules. It was written and tested on BSD/OS 3.1, but should work with any modern UNIX-like operating system. All the files needed are stored in this file: ftp://ftp.ripe.net/tools/asused-3.5.tar.gz You will need to use gzip and tar to extract them, then please follow the instructions in the README file. We are keen to receive your feedback on this software - please address your comments and/or suggestions to me. Cheers, Maldwyn Morris maldwyn(a)ripe.net Software Manager RIPE NCC

1 1

New "helpdesk" mailbox for members! <lir-help@ripe.net>
by RIPE NCC Staff 08 Sep '00

08 Sep '00

Dear all, We are happy to inform you of a newly created mailbox within the RIPE NCC! The following mailbox is available for all RIPE NCC members to use: <lir-help(a)ripe.net> To accommodate some wishes raised within the RIPE NCC membership, this mailbox has been set up to serve as a form of "helpdesk" within the Registration Services, available to RIPE NCC members only. The purpose of the <lir-help(a)ripe.net> mailbox is offer assistance and help to our members, further facilitating the process of requesting IP Address Space from the RIPE NCC and communicating useful information. The mailbox is responded to by experienced RIPE NCC hostmasters and will be given priority over more general questions to ensure a fast and accurate answer to your queries. As a member you can use this mailbox for general policy questions as well as very specific questions related to a particular on-going request. PLEASE NOTE: As it is restricted for members only, it is important to include the Reg-Id of your organisation in all mails sent to <lir-help(a)ripe.net>. (The Reg-Id can be included in either the subject line or the body of the message.) Any mails that do not include a valid Reg-Id will be bounced to allow the hostmasters to concentrate on member questions, ensuring a fast response time for <lir-help(a)ripe.net>. We hope that you find this mailbox useful and we look forward to any feedback you may have! Kind regards, Nurani Nimpuno Registration Services Manager RIPE NCC

1 0

RE: Changing inetnum objects
by kevin.bates＠bt.com 08 Sep '00

08 Sep '00

Hi About a year ago we (an enterprise registry) had a similar issue with a number of assignments. Following discussion with the hostmasters. We used the RIPE141.txt process as the "conditions" of the original assignment had or seemed to have changed and thus virtually audited the address space usage of the gaining and loosing party. For what it is worth we ensured both parties agreed. Also if I remember correctly when the inetnum and/or the netname was changed this had an effect on the rvse delegation assignment and so that had to be "re-agreed" with the hostmasters. kevin > -----Original Message----- > From: Herbert Baerten [SMTP:herbert@hostit.be] > Sent: 08 September 2000 08:56 > To: lir-wg > Subject: Changing inetnum objects > > > Question: > > can one company foo.com request its LIR to change the company's inetnum > (netname, description, tech-c) so it appears to belong to another company > bar.com? > If yes: who should this request come from (the original requester? > management?)? > If no: what if foo.com is somehow related to bar.com (e.g. foo.com is a > parent or daughter of bar.com)? Suppose bar.com has taken over the > internet > activities from foo.com? > > Is there a document describing procedure to follow in such cases? > > tia > Herbert > > -- > HB5351 > Herbert Baerten > Network Manager @ HostIT Benelux

1 0

ISP Survey in Network Magazine
by dgreenfi＠cmp.com 07 Sep '00

07 Sep '00

I thought this might be of interest to some..... Network Magazine is planning a survey of European ISPs for its November issue. If you work for an ISP who sells to business users, consider taking 10 minutes to fill out the survey below. Why spend the time ? Simple. It's about eyeballs, as in potential customer eyeballs. Network Magazine is the only global monthly focusing on the development of large scale corporate networks. The network managers who read Net Mag are heavily involved with selecting and purchasing the IP services their companies will use. Although most are located out region, many are looking at buy services within Europe. Participating in this article is an easy way to get valuable face time (or print time as it were) with these key decision makers who normally may not be exposed to the local press. Need another reason? How about this. The first three folk who get me a survey get taken out for dinner at Interop Paris (November 6-8). Ahhh, I can smell that food now. Delivery for the feature survey is by Monday at the latest. There's a bit more time on the ISP Index. You can deliver that one by end of next week. The food deal only applies to the feature. All the best, David Greenfield International Technology Editor QUESTIONS General 1. Company Name: 2. URL: 3. If you are owned or affiliated with any organizations that might be of interest to our readers, please provide those details here. 4. Who do you see as your major competition 5. Contact name (not for publication) 6. Contact phone number and email addresss (not for publication) Geographic Coverage: 1. Please list the countries/regions where you provide Internet access. Pricing for Access Services Please provide the monthly and installation charges for the following service and itemize the amounts below. Prices should include all fees except for line charges. If line charges must be cited then please use a 5 kilometer access circuit. 1. E1 2. 256 Kbits/s 3. ISDN 4. DSL (specify speeds) 5. What are the major components driving the cost of the Internet connection (not including the access circuit)? Services Offered Please indicate the services that you provide. Check all that apply a. Dialup b. Dialup with roaming c. Internet Access (fixed line) d. Content Hosting (dedicated servers) e. Content Hosting (shared servers) f. Intranet (design; host) g. Extanet (design; host) h. E-Commerce (design; host) i. Other (specify) Service Level Agreements (SLAs) If you provide any SLAs please describe them and the penalties if they aren't met. Infrastructure 1. Who are your upstream providers for connectivity to the US? 2. Where (NAPs or countries) do you connect with them? 3. In which NAPs do you have a physical presence? --------------------------------------------------------------------------------------------------------- NETWORK MAGAZINE Incorporating Data Communication Magazine International Office #2 Chai Taib, Entrance A, Suite 6 Jerusalem, 95405, Israel v: +972-2-651-9742 e: dgreenfi(a)cmp.com http://www.cmp.com

1 0

mnt-lower and asused
by Joao Luis Silva Damas 06 Sep '00

06 Sep '00

Hi, there is nothing wrong with having your own mnt-lower on your allocation/assignment objects. The warning was the product of a small internal misunderstanding that wasn't much of a hassle when the tool was only for internal use, so it went unnoticed. asused public is being modified to only issue warnings when the mnt-lower has the RIPE NCC HM maintainer, not your own. You are encouraged to use mnt-lower in your own objects since that gives you better control over registrations in the address space allocated to you. The new release should be coming out very soon. Regards, Joao Damas RIPE NCC

3 2

RE: Ticket handling at the RIPE NCC
by Stefan.Gasteiger＠Gendorf.de 06 Sep '00

06 Sep '00

It would be fine if rttquery could also display *how long* the wait queue is ("...there are n requests to be served before you..."). Would that be possible? Stefan Gasteiger SG5599-RIPE I+K Betrieb (zertifiziert nach DIN EN ISO 9001) InfraServ Gendorf Tel.: +49 8679 7 5599 Fax: +49 8679 7 39 5599 Mobiltel.: +49 172 8649205 E-Mail: Stefan.Gasteiger(a)gendorf.de > -----Original Message----- > From: Nurani Nimpuno [mailto:nurani@ripe.net] > Sent: Friday, September 01, 2000 5:34 PM > To: lir-wg(a)ripe.net; Local Internet Registries in Europe > Subject: Ticket handling at the RIPE NCC > > > Dear all, > > Prior to sending a mail to the lir-wg regarding an on-going request, > I would like to encourage you to check the actual status of your > request. This can be done at the following URL: > http://www.ripe.net/cgi-bin/rttquery The wait queue is indeed high and you may have to wait up to two weeks before an *initial* response from the hostmasters at the RIPE NCC. However, once your ticket is being processed, you normally get a reply within one working day. So if you are waiting for the reply to an on-going request for more than a couple of days, it is highly possible that the RIPE NCC has responded to your request and is waiting for additional information from you before proceeding further with the request. If you have checked the status of your request using the rttquery and you have in fact not received notification from the RIPE NCC, please do not hesitate to contact us through the <hostmaster(a)ripe.net> mailbox, including the ticket number of your on-going request. By including the ticket number of your on-going request, you will *not* be put at the bottom of the wait queue and can expect a prompt reply. I hope this clarifies how your tickets are handled by the RIPE NCC. Kind regards, Nurani Nimpuno Registration Services Manager RIPE NCC

2 1

May 17 Task Force Findings / Recommendations
by Stephen Burley 05 Sep '00

05 Sep '00

May 17 WG Meeting, 07/21/2000 Proposed Agenda: 1. Scope and goal of discussion 2. Description of current procedures for obtaining address space, assignment windows, approvals 3. New LIR growth 4. Assignment window 5. Response time and emergency measures 6. Usage Criteria 7. Category priorities 8. accessibility and communication 9. tools List of attendees Nurani Joao Anne Wilfred Stephen Barbara Daniel Sabine Gert 1. Scope and goals of discussion Propose changes to policies and procedures for address assignments to ultimately be submitted to LIR WG, with the clarification of best practices and tangible steps to achieving those goals. This group will not determine how RIPE NCC internally achieves those goals. 2. Current status of procedures a. Process includes sanity checks that may be delegated to LIRs b. Previously no automatic review of Assignment window, now auto reminders in place, made difficult by no flagging of good/bad tickets, no record of why assignment window was denied i.e.. The quality of the LIR requests will be flagged so a more informed decision of the AW status can be made. c. Wait queue due mostly to under staffing combined with significant increase in new LIR growth. d. Improving ripe-141 instructions (ripe-185) may cut down on common time-consuming errors. Although the form provides the hostmasters with enough detail to approve/decline a request it is very sparse on helpful comments for the engineer/customer filling in the details. 3. New LIRs a. Nurani provided information on how many new LIRs are being added, current rate is ~80/month b. Who is becoming an LIR? Should we actively discourage LIR's some how? Raise the setup fee? See 3d. c. LIRs are coming in a at a much faster rate than previously, ask RIPE to review resources consumed in supporting LIRs and whether it would be appropriate to create a specialized group for dealing with LIR applications, education, etc. d. Also, review new LIR fees to see if they cover resources consumed by the application and education process, a new LIR takes up more time and resources than does a large well established registry with experienced Hostmaster. But this creates a problem when the same country with more than one registry uses the same engineers how do you justify charging them more? and how do you track the experienced engineers, we could end up creating a market for exirienced RIPE hostmasters. 4. Assignment window a. Safety net would provide a certain measure of business performance, problem is that safety nets can be abused if not implemented properly. b. Flexible assignment window offers more security from abuse and a traceable audit. c. This becomes a problem of registration accuracy and address conservation, random audits difficult to perform. d. Consensus is that some process of flexible assignment windows will be appropriate to implement but it will have an upper limit. e. Run the db audit at the time of the assignment window increase, with all errors fixed for qualification. This would take the place of audits at each assignment approval request. This could also be part of the LIR's responsibility to provide a valid clean audit, rather than the hostmaster running it. It is also a measure of whether they are really competent and deserve a larger AW. 5. Category priorities: should different categories of request have different priorities in the queue? i.e. contact requests are not the same as IP requests but how do you decide how important each type is? a. once we reach our goal of having a reasonable wait queue, this issue becomes moot. b. if we reach a point where queue exceeds maximum point, then prioritization becomes useful. c. should be looked at in conjunction with response time measures. 6. Accessibility a. Phone help desk runs into problems of accessibility for language and cost factors b. Possible to set up email help desk as a test mode, possibly a three month trial c. Translation of ripe-142 and ripe-185 and other supporting address space documents to other languages to improve communication and education for LIRs. 7. Response time a. Flexible assignment windows when acceptable limit is exceeded. b. When a ticket is in the queue for longer than the target RTT, then certain simplification efforts would kick in. These could be with multiple levels of intervention, and could be invisible to the LIR as a separate process. c. Once a ticket hits the maximum RTT, a special response would occur, which would be marked as unique and auditable and the special response should be capped at a certain level (e.g. /22, or number of approvals per LIR, or other set criteria) d. RTT is defined as getting meaningful response from hostmaster (the initial human response) to ticket request, and should apply for each iteration of reply, not for overall ticket assignment e. The limiting criteria can be described as: Response times. 1-2 days - Normal and acceptable 3-4 days - Request simplification processes put in place. Or AW +1 applied on temp basis below /22 5+ days - Auto approval with auditable response on all requests in queue over 4 days up to /22 8. Usage Criteria /20 criteria a. When an LIR gets a /20 as an initial allocation, they may run into a utilization issue at the 80% mark (12.8 used, 3.2 available) with one customer able to eat this space up an LIR could end up with no IP's to assign till more allocated. Again this is only with a high wait queue once the queue is under control this also becomes moot. b. Proposal is that if the growth is happening in a very short amount of time, the utilization level could be set at an amount smaller than 80%, offering a buffer for growth. So if an LIR can show fast take up at less than 80% the rest of the /19 will be allocated. 9. Tools a. db audit tool for LIRs to run before submitting requests for allocations thus removing the need for Hostmasters to run exhaustive audits when the problems are caused by the LIR. In other words get your house in order before even coming back to RIPE NCC for more space. b. Improved user interface to forms such as the 141 syntax checker. 10. Feedback useful for evaluating the changes proposed are the collection of statistics regarding IP assignments, LIR growth, and other elements impacting this process. This should be done on a continuous basis with a web page resource for the community. 11. We will distribute minutes to the TF, then distribute them to the LIR WG and we will prepare a presentation for the September RIPE NCC meeting. Your Fellow RIPE Members May17TF

1 0

Address Space Waiting Time...
by Feico Dillema 04 Sep '00

04 Sep '00

Hello, I filed a first request for address space for a new LIR about a week ago. Ticket number is NCC#2000085969 and it's still in the waiting queue. Can any of you give me a hint on what the average queuing time is at the moment? My boss is getting a bit nervous as it is on the critical path for meeting some deadlines, and I'd like to be able to tell him whether he can relax or should panic... Thanks, Feico.

3 3

asused question
by Abdullah Saad Al-Ashry 04 Sep '00

04 Sep '00

Hi, When I use the utility "asused" ftp://ftp.ripe.net/tools/asused-3.5.tar.gz It gives me this warning: **************** Please check the following WARNINGS: 212.xx.xxx.0 - 212.xx.xxx.255 has mnt-lower xxxx attached **************** Could anybody explain this. Regards; ---------------------------------------------------------------------- Abdullah Saad M. Al-Ashry Al Faisaliah Internet Services and Technology Est. (AwalNet) Tel: +966-1-4600111 x 311 Fax: +966-1-4601110

3 2

Re: ripe-db question
by Christian Storch 02 Sep '00

02 Sep '00

You're right! That number space wasn't registrated at RIPE - you have to look at ARIN: http://www.arin.net/cgi-bin/whois.pl?queryinput=NETBLK-SPRINT-CDF4C7 The AS of omnitel looks like the first upstream provider of Omnitel was SprintLink (USA) and the second is Telianet (Sweden). So the address space 205.244.196.0/24 seems to be registrated by SprintLink at ARIN. Later it becomes an LIR at RIPE and so on... So I think for that you would have to ask all RIR's for your purpose: RIPE, ARIN and APNIC. And you won't get always the right answer for your geographical question I think. Christian ---------- | Von: Andrius Kasparavicius <andrius(a)andrius.org> | An: Christian Storch <storch(a)infra.net> | Cc: 'mediaWays Hostmaster' <hostmaster(a)mediaways.net>; lir-wg(a)ripe.net; db-wg(a)ripe.net | Betreff: RE: ripe-db question | Datum: Samstag, 2. September 2000 14:01 | | On Wed, 30 Aug 2000, Christian Storch wrote: | | > Take a look at http://www.ripe.net/ripencc/mem-services/general/allocs4.html. | > - Perhaps that page could solve your question. | | hmm, look at lt.Omnitel: | lt.omnitel (OMNITEL Net) | 19951120 194.176.32/19 ALLOCATED PA | 19971010 195.22.160/19 ALLOCATED PA | 19990913 212.47.96/19 ALLOCATED PA | | querry ripe database for 205.244.196.0/24 or for 205.244.197.0/24 | | route: 205.244.197.0/24 | descr: OMNITEL | descr: Joint Lithuanian-USA Closed Stock Company | descr: Vilnius, Lithuania | descr: GSM communications and data networks | origin: AS5522 | mnt-by: AS5522-MNT | changed: daiva(a)kaunas.omnitel.net 19970605 | source: RIPE | | route: 205.244.196.0/24 | descr: OMNITEL | descr: Joint Lithuanian-USA Closed Stock Company | descr: Vilnius, Lithuania | descr: GSM communications and data networks | origin: AS5522 | mnt-by: AS5522-MNT | changed: daiva(a)kaunas.omnitel.net 19970605 | source: RIPE | | | it mean's that in allocation list, is not all ip blocks allocated to | LIR's. Why? | | Andrius

1 0