October 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

Waitqueue Update
by Axel Pawlik 26 Oct '00

26 Oct '00

Dear LIR-WG list members, The RIPE NCC would like to update you on the progress with regards to the Registration Services wait queue. The possibilities for action as well as consequences have been discussed extensively. Below, please find an overview of actions taken in the last few weeks following the RIPE 37 meeting: - We are giving priority to correctly filled out requests - We are raising Assignment Windows very pro-actively - (this was applied some time prior to RIPE 37 and is now showing results) - We are less strict with documentation being totally complete - We are stricter with members who have not read the documentation - We are dispatching incoming requests more efficiently, balancing the level of experience of hostmasters with the complexity of the requests. Apart from the immediate dealings with the wait queue, we are continuing to hire hostmaster staff. What are the results of the efforts thus far? During week 41 we experienced a peak in the number of tickets in the queue reaching a total of 842. At this time the wait queue in days was fluctuating between 24 - 27 days. Two weeks later, having changed our working pattern as with the actions mentioned above, we are down to 124 tickets in the queue and the wait queue time has dropped to 6 calender days. So, is this the time to rejoice and celebrate? We do not think so. While these are good results and due to the unrelenting effort of my collegues in the Registration Services (including Nurani, Joao and those in other areas supporting them) this is not enough. Naturally, we would like to get the queue down even further, two days is the goal. Equally important is the need to carefully examine what effects this way of working has. Are you getting the service you require? Is the RIPE NCC delivering a service quality that we can be proud of, and can this be sustained? These will be the points we will keep in mind for the coming weeks. Another update can be expected in four weeks time. Regards from windswept Amsterdam, Axel Pawlik Managing Director RIPE NCC

2 1

RENAME a maintainer
by Heidrich Attila 26 Oct '00

26 Oct '00

Hi! Is there any simple way to rename a maintainter object? I'm afraid, I can not simply change the name... Alternatively, can I select all the objects with MNT-BY=<something> ?? How can I change the MNT-BY attribute? Delete, and set up the new one? -- ( Y ) (o-o) www.deltav.hu/~heidrich (")_(")o heidrich(a)mail.deltav.hu X-NCC-RegID: hu.deltav

4 6

RE: RENAME a maintainer
by Wilfried Woeber, UniVie/ACOnet 26 Oct '00

26 Oct '00

>Alternatively, can I select all the objects with MNT-BY=<something> ?? whois -ri mnt-by <your-mnt-obj-name-here> >How can I change the MNT-BY attribute? Delete, and set up the new one? I'd register the new one, move the objects under the control of the new one, double-check, and then delete the old one. Regards, Wilfried.

1 0

Re: national allocations
by Wilfried Woeber, UniVie/ACOnet 20 Oct '00

20 Oct '00

=>> But inetnum has "country" field which is mandatory and if I look for =>> related "route" object, it has "origin" field with AS number. My guess would be that in 9 out of 10 cases (or in 199 out of 200?), the concept of "country" in the Internet is not useful at all. Even if you manage to "properly" look at the geographical aspect, in general it doesn't tell you anything reasonable about connectivity, user community, and the like. Maybe the only exception is the exchange of a set of packets, from a legal point of view, when you are able to positively verify (by some magic) that source, destination and intermediate hops stay within national boundaries. -WW

2 1

national allocations
by Oleg N. Bondarev 19 Oct '00

19 Oct '00

Dear all, i'd like to know - does anybody use allocations list submitted by RIPE NCC in order to automatically extract info about national allocations ? For instance, when we need to define whether current IP-address belongs to RU provider we ask whois <IP-address> | grep "country: *RU" (i guess country field with correct country code presents in all of inetnums) however sometimes it's necessary to know all of IP-addresses that were allocated to national providers, so we've to get allocation file, find only RU entries and furher update our local database. Is there are any ways to know that RU LIR has been added to file ? With respect, --- RIPN Registry center -----

4 5

ROUTING
by Okan Cimen 03 Oct '00

03 Oct '00

HI CAN ANYONE GIVE ME DETAILED ROUTING INFORMATION OF A PI INDEPENDENT FIRM ? OKAN

1 0

Input to the AC from the ASO workshop at RIPE 37
by Hans Petter Holen 03 Oct '00

03 Oct '00

Dear Address Council, As chair of the lir-wg, http://www.ripe.net/ripe/wg/lir/index.html the RIPE open forum where policy is made I am writing you this open letter. The purpose of this note is to update you all on the input gathered from our region. It is an open letter to work as a startingpoint for a broader discussion on the same topics in all of the addressing community. This would provide valuable input to the planned workshop to be held between the AC, the RIRs and ICANN in Brisbane later this year. (This initiative was first suggested in Budapest and later discussed at the AC phone conferences, please refer to the minutes for more information: http://www.aso.icann.org/docs/) At RIPE 37 I called for a special workshop in order to bring those especially interested in ASO matters together with the AC representatives from our region for closer discussion. The announcement of the issues I brought to the meeting can be found at http://www.ripe.net/ripe/mail-archives/lir-wg/20000701-20001001/msg00150.htm l Some 20-30 people showed up including Address Council members - Sabine Jaume, Wilfried Woeber, and myself. 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 official minutes from this meeting will be posted shortly, but a brief summary is as follows: * The distinction between regional and global address policy needs to be set * The AC needs to understand and appreciate the differences between each of the regional policies * There is interest in harmonizing the core procedures and requirements of the various Regional Registries with regard to LIRs applying for and obtaining IP address space. * The Address Council should proactive set the agenda for global policy development. * IPv4 address exhaustion - the AC should work with the RIRs and the ICANN IANA to produce comparable statistics on address space consumption. Care should be taken to first produce solid data, then diagnose, and finally seek the proper cure. * The AC should not see it as its role to promote IPv4 over IPv6 or vice versa. * The AC should look further into addressing the concerns that initiated the ad Hoc committee * It was also expressed satisfaction with the ASO annual meeting in Budapest and further interest inntrest in more opportunities to meet and discuss global addressing policy with the address council. It was suggested to me publicly and privately that the AC sould seek to hold an open meeting in conjunction with the ICANN annual meeting later this year. The agenda of such a meeting should consist of not only reporting from the work done by the AC and the ASO but also provide open discussions on addressing issues including the ad Hoc group issues, global policy development and several legacy addressing issues. A well prepared meeting with invited speakers as well as a discusion panel is likely to bring more insight into the issues in front of us. Such a meeting would in my opinion serve as an important step in the ongoing process of seeking global consensus. We have started the discussion regionally at RIPE 37, the ARIN policy meeting and the upcoming APNIC policy meeting. Thereafter the AC, RIRs and ICANN will work further on some issues, present and discuss them at the ICANN annual meeting before seeking final consensus at all the regions mailinglists and upcoming policy meetings. I would by this ask the chair of the address council to bring these suggestions to the address councils next phone conference. Sincerely, Hans Petter Holen RIPE lir-wg Chair, the open forum where policy is made.

2 2

This is too much!
by Berislav Todorovic 02 Oct '00

02 Oct '00

Folks, If I remember well, we talked about some improvements on the last RIPE Meeting, regarding the request waiting queue length. We then heard the information from RS manager that the waiting queue was 7-10 days long. OK - that's acceptable. However, this: >> This ticket is 25 days old and the oldest ticket in the Wait Queue >> is 26 days old. is seriously bad performance! Hope it will improve soon, though. ;-) By the way, a nice MRTG/RRD graph of waiting queue length weekly and monthly statistics would be really nice to have. Regards, Beri --------- Berislav Todorovic, Network Engineer --------- ------- KPNQwest N.V. - IP NOC (formerly EUnet NOC) ------- ---- Wilhelmina van Pruisenweg 78, 2595 AN Den Haag, NL ---- --- Phone: +31-70-379-3990; Mobile: +31-651-333-641 --- -- Email: beri(a)kpnqwest.net <=> beri(a)EU.net -- --- _ _ ____ _ .--. ____ ____ __/_ --- ----- /__/ /___/ /\ / / / | / /___/ /___ / ------ ------ _/ \_ / _/ \/ (__.\ |/\/ /___ ____/ (__. -----

2 2