January 2001 - 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

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

Draft agenda lir-wg: regional issues
by Hans Petter Holen 24 Jan '01

24 Jan '01

Dear lir-wg, here is a draft agenda for tomorrows meeting. My sincere appologies for this late submission. A draft agenda for todays lir-wg global issues will follow shortly. Note that some of the issues have status pending due to lack of confirmation from the speakers. Note also that I have put the issue "management of the working group on the agenda." Here you will have the oportunity to suggest improvements to the running of this wg. Do not forget this is your forum to set and change policy ! Sincerely, Hans Petter Holen 1 Admin - scribe, participant list, charter, mailing-lists 2 Agenda - moved reports top plenary only 3 RIPE 37 minutes & actions 4 Report from the RIPE NCC Hostmasters by Nurani Nimpuno incl. Meet the hostmasters 5 Discussion on service level improvements, 17th of may task force 6 Management of working group x-X-x Break xX-x 7 IPv4 address exhaustion, by Tony Holmes and Paul Mylotte 8 Ip addressing for mobile handsets (to be confirmed) 9 Provider Independent addresses (to be confirmed) 10 36.5 Assignment window applied on infrastructure (to be confirmed) 11 36.7 Transfer of pre RIR address space to LIR 12 Preparing the plenary AC election: candidates, proceudres 13 PGP Key Exchange (to be confirmed) 14 Restoring the transparency (continued, to be confirmed) EOM

1 2

Delays in RIPE Database updates
by RIPE Database Administration 22 Jan '01

22 Jan '01

Dear All, As some of you may have already noted, we are experiencing delays with the processing of updates in the RIPE Database. This is due to the fact that the last week-end, the reindexing of person objects took much longer than expected; in the meanwhile, no updates could be processed, so they remained blocked in the queue. As of now, the updates are being regularly processed. We want to stress the fact that your updates will be eventually processed and there is no need to resend your update messages; this will have the sole effect of adding load to the update queue. To check the current wait time for updates and other operational statistics for the RIPE Whois Database server, please see: http://www.ripe.net/ripencc/pub-services/db/mrtg/whois.html We apologize for any inconvenience this may cause or have caused. If you have any questions, please don't hesitate to contact <ripe-dbm(a)ripe.net>. Regards, Daniele Arena ____________________________ RIPE Database Administration.

1 0

X-NCC-RegID:es.uni2
by Mijangos Rodriguez, Carmen 22 Jan '01

22 Jan '01

Hello: I'm not sure if I can ask the next questions in this mail-box, if It is not possible my apologise. I have some questions: 1) When we ask for a group Address assignment, have we to detail how many objects we are going to create?, or if all the objects have the same netname is enough with one object? 2) When we ask for some Address assignment and a hostmater send us a mail to accept this request, A- We have to create the objects of all this addresses very soon or we have some time to create the objects? How much time? B- Can we combine this approved address with other existing assignments ? 3) About the reverse delegation, we have two objects domain: 37.62.in-addr.arpa .... nserver: m2dnsnet1.net.uni2.es .... domain: 36.62.in-addr.arpa .... nserver: m2dnsnet1.net.uni2.es With this objects when arrive to RIPE a request reverse delegation of this address RIPE send to our "nserver: m2dnsnet1.net.uni2.es" this request. If we create other reverse delegation in RIPE of our addresses for a customer, for example: domain: 255.37.62.in-addr.arpa nserver: "customer_server" nserver: m2dnsnet1.net.uni2.es Now when arrive to RIPE a request reverse delegation of this address, 62.37.225.0 - 62.37.225.255 RIPE send to "customer_server" this request, and the rest of the request of address 62.36.0.0 - 62.37.255.255 are sent to our "nserver: m2dnsnet1.net.uni2.es". Is correct all this?? Thanks in advance Kind regards Carmen Mijangos Carmen Mijangos UNI2 - Técnico de Servicios de datos Dirección Técnica Teléfono : +34 912520972 / Móvil: +34 667493879 e-mail: CMijangosR(a)uni2.es http://www.uni2.es

2 1

URGENT: Database problems?
by Berislav Todorovic 21 Jan '01

21 Jan '01

Dear RIPE NCC colleagues, I'm sure yo have a lot of work to do regarding the forthcoming RIPE Meeting, but can someone, please, take a look on the database update queue? Either the queue is full or the automatic email robot is broken. We sent an update of AS-KPNQWESTRO few times since Friday and no answer we got from the robot. That's 3 (three) days !!!!!!!!! Thanks! 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 -- --- _ _ ____ _ .--. ____ ____ __/_ --- ----- /__/ /___/ /\ / / / | / /___/ /___ / ------ ------ _/ \_ / _/ \/ (__.\ |/\/ /___ ____/ (__. -----

3 2

RE: Announcement: RIPE Whois Database Version 3.0beta2 released
by Sam Mortimer 19 Jan '01

19 Jan '01

> From: Nipper, Arnold [mailto:arnold.nipper@de-cix.net] > Sent: 19 January 2001 14:10 > > rpsl.ripe.net doesn't seem to exist ... > > whois -h whois rpsl.ripe.net Daniele Arena > whois: whois: Unknown host: Datei oder Verzeichnis nicht gefunden > > Let's have a look ... > > ;; ANSWER SECTION: > rpsl.ripe.net. 1d23h59m55s IN CNAME reimp.ripe.net. > reimp.ripe.net. 1d23h59m55s IN CNAME orange.ripe.net. > orange.ripe.net. 1d23h59m55s IN A 193.0.1.239 > > Yeah, don't do that. Don't use CNAME to CNAME. Pls fix, CNAME to CNAME is fine. it's used all the time with reverse DNS. works fine for me. Regards, -Sam.

2 1

Announcement: RIPE Whois Database Version 3.0beta2 released
by RIPE Database Announcements 19 Jan '01

19 Jan '01

Dear All, This mail is to inform you that version 3.0beta2 of the RIPE Whois Database software has been released. This is mainly a bugfix release in respect to the "beta1" version. We remind you that the RIPE Database is about to change its data format, from RIPE181 to RPSL (the Routing Policy Specification Language, see RFC2622). This will affect all object types, including "person", "domain" and "inetnum". We suggest you to start to get used to RPSL and version 3.0 . Please check our RIPE-181 to RPSL Migration page at: http://www.ripe.net/rpsl/ You can test your skills with RPSL and the functionality of the new beta release in the following ways: - Query rpsl.ripe.net at port 43. You will find there exactly the same objects that are in whois.ripe.net, mirrored live and in RPSL format. - If you have any script that runs by querying whois.ripe.net, test it by pointing it to rpsl.ripe.net and make it v3.0-compliant. - Try our CGI interface to the RPSL server: you can find it at http://www.ripe.net/ripencc/pub-services/db/reimp/. - Get to know the new update path: use our "sandbox" database for RPSL updates. Send your updates to <auto-rip(a)ripe.net> and query the corresponding database at rpsl.ripe.net, port 4343 . Remember that in a few months, that's the way the RIPE Database will be running; so the earlier you start working with it, the less likely you are to be unpleasantly surprised later. For those running Near-Real-Time Mirrors of the RIPE Database, please be advised that as soon as the RIPE Database changes its data format, you will not be able to mirror the RIPE Database using the version 2 of the Software, since it is not RPSL-compliant. You will have to upgrade to version 3 to mirror the RIPE Database. Please contact <ripe-dbm(a)ripe.net> for detailed information. Please note that the software is still in a "beta" phase. So we need your feedback! If you happen to find something that looks like a bug when you are testing the RPSL database, don't hesitate... Send us a bug report at <dbrip(a)ripe.net> ! If you want to actively participate to the migration effort, you could join the "RIP migration Task force" and let yourself be heard. Just write to <ripe-dbm(a)ripe.net> and ask to join the Task Force. You can download the latest release of the source code at the following URL: ftp://ftp.ripe.net/ripe/dbase/reimp/ripe-dbase-3.0beta2.tar.gz You can also join a discussion list related to version 3.0 beta of the RIPE Database Software. To subscribe to this list, send a message to <majordomo(a)ripe.net> with the line: subscribe db-beta in the body of your letter. It is a moderated mailing list so some delays in subscription are possible. Regards, Daniele Arena ___________________ RIPE Database Group RIPE NCC

2 1

ANNOUNCEMENT: Tools BOF at RIPE 38
by RIPE NCC Staff 17 Jan '01

17 Jan '01

Dear Colleagues, The RIPE NCC is pleased to announce a 'Tools' BOF to be held at the RIPE 38 meeting in Amsterdam - please see: http://www.ripe.net/ripe/meetings/current/ripe-38/index.html This BOF session has been organised in order to discuss the tools we currently provide for our members, tools we plan to provide in the future and tools our members would like us to provide. 'Tools' refers to both software that the RIPE NCC makes available to its members to run themselves ( such as asused ) and software the RIPE NCC hosts that is used by the membership ( such as the Web page for checking European IP Address Space Request ( ripe-141 ) Forms and the Hostmaster mail robot ). Here is the Draft Agenda for this session: Proposed Agenda for the Tools BOF, RIPE 38 ------------------------------------------ Date: Tuesday 23rd January, 2001 Time: 14:00-15:30 Chair: Maldwyn Morris, Software Manager, RIPE NCC Location: St John I 0. Introduction 1. Existing tools 2. Tools in development 3. Proposals for tools I look forward to welcoming you to this BOF at the upcoming RIPE meeting. Cheers, Maldwyn Morris Software Manager RIPE NCC <swcontact(a)ripe.net>

1 0

None
by Adam Obszynski 16 Jan '01

16 Jan '01

Hello , I want to ask about PI assigned address space. The best example is my own one which good show us bad idea of assigning exactly size than user require.. Today we got very bad organisation in world BGP table.. a lot of bad aggregated prefixes etc.. so carrier providers from day to day 8-) move filter mask to right... now ie. Sprint: http://www.sprint.net/policy/bgp_filters.html: [...] Customers may announce routes as small as /26 for IP address blocks obtained through Sprint. Announcements for blocks obtained from other providers are limited to a /24 or smaller mask (/23, /22 etc.). This applies only to Sprint customers; peers are bound by a much stricter prefix policy. [...] so if RIPE will assing PI requests addresses exactly as written in ripe-141 from we give our clients big chance that they will be filtered. The of course aware about it .. but.. when we have /24 we got 70% chance to filtered with.... ie. /26 we got 40% and less.. so it can effect in one bad situation.. ripe forms written for PI assign policy and requests of /24 or smaller for route security and out customers become unhappy... IMHO one way is change our LAW to be good for mass not for goverment only 8-) so i please you to made some updates and assign PI depend on actually known filtered size in carrier networks... in europe and whole world PS: sorry for my bad english and grammar 8-| here is some sentences from ripe-127 8-) thank you! [bof] [...] Document: ripe-127 Assignment Policies [...] ments etc.. This also implies that assigning PI space prefixes longer than 24 bits is perfectly acceptable if the request does not merit 8 bits of address space to be assigned. [...] Detailed Recommendations [...] Assignment of this address space is valid as long as the criteria for the original assignment are still met. However, assignment of address space does NOT imply that this address space will be ROUTABLE ON ANY PART OF THE INTERNET. It is ____________________________________________________ ripe-127.txt Page 7 [eof] -- Regards, Adam Obszyński ATM Inc. +48-22-5156418

1 0