- db-wg - mailman.ripe.net

RIPE-181 to RPSL Migration; Phase 2.
by DB-News 10 May '01

10 May '01

Dear Colleagues, (Apologies for multiple messages). On and from Monday, 14th May, 2001, <auto-dbm(a)ripe.net> shall only accept updates in RPSL format; updates in RIPE-181 format will no longer be accepted. Updates in RIPE-181 format can be sent to <auto-181(a)ripe.net>, where they will be automatically converted to RPSL format. <auto-rpsl(a)ripe.net> will continue to accept updates in RPSL format. The update path for the TEST database will also be changed. In summary, from 14th May, 2001: =============================== RIPE Database: - ------------- <auto-dbm(a)ripe.net> - updates in RPSL format only <auto-rpsl(a)ripe.net> - updates in RPSL format only <auto-181(a)ripe.net> - updates in RIPE-181 format, automatically converted to RP S L format TEST Database: - ------------- <test-dbm(a)ripe.net> - updates in RPSL format only <test-rpsl(a)ripe.net> - updates in RPSL format only <test-181(a)ripe.net> - updates in RIPE-181 format, automatically converted to RP S L format On Monday, 14th May, 2001, we cannot guarantee that an update message sent to <auto-dbm(a)ripe.net> will use a specific update path (RPSL or RIPE-181). Thus, we advise that updates in RIPE-181 format should be sent to <auto-181(a)ripe.net> and that updates in RPSL format should be sent to <auto-rpsl(a)ripe.net>. Please note that from Monday, 15th October, 2001, updates in RIPE-181 format will no longer be accepted by the RIPE Database. Further information is available from 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

can NRTM handle divergent schemas?
by George Michaelson 10 May '01

10 May '01

Hi. Sorry for comparative silence from APNIC, we're back looking at getting the V3 code beyond test-compile state into pilot service. Andy Linton has been looking at this with me and we're now pretty sure the only schema element we don't have in APNIC 181 objects in-hand is the referred-by field. Having worked out its a nic-hdl, we figure that for 'old' data we just make this the existing meta-maintainer for APNIC and can do that easily in ripe2rpsl. But we have this problem about having country: fields in domain/inetnum/person objects. If we modify schema here, re-compile whoisd, are we able to run NRTM feeds to you and have your side strip non-conformant attributes, or is there some relax mode for NRTM where it doesn't care? My reading of code is a bit hazy here. I can't see where you are going to bypass schema checks in NRTM. If thats the case, we'd have to either overload remarks: fields to preserve this data (which is yucky) or you need to revise the RIPE schema. We should be able to take a feed incoming anyway (and would like to do that asap) but we're worried about how you can take a feed back from us if we do the codechange in the defs/* here. cheers -George -- George Michaelson | APNIC Email: ggm(a)apnic.net | PO Box 2131 Milton QLD 4064 Phone: +61 7 3367 0490 | Australia Fax: +61 7 3367 0482 | http://www.apnic.net

2 1

first draft DB-WG minutes, RIPE39 @ BLQ
by Wilfried Woeber, UniVie/ACOnet 09 May '01

09 May '01

Attached please find the (still a bit rough) 1st draft for the DB-WG minutes. A big thank you to Shane for taking notes! We are still working on collecting the URLs for the presentations, and on aggregating the open actions - before putting the minutes up on the web as well. Comments and corrections welcome - in particular if you feel mis-quoted or represented as name??. Thank you, regards, 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Draft Minutes, Database Working Group RIPE39 @ Bologna A. Admin stuff - list of participants, scribe Scribe: Shane Kerr - agenda bashing Draft agenda accepted as final - minutes approved - content-wise, action on Wilfried and webmaster(a)ripe.net to insert links to presentations B. Actions From previous meetings - On Joao to present "unique handle proposal" @ ARIN meeting Joao: still needs more work, so it wasn't presented. Randy Bush is going to submit an IETF draft. Wilfried: can the draft be submitted to DB-WG mailing list? Joao: still needs some brush up... Wilfried: can you keep track of this? Joao: yes, Action on Joao to track development of draft and circulate the draft (or a pointer to the draft) on the DB-WG mailing list - On NCC DB Group (Joao) implement "lir-allocated" attribute fo inetnum objects Wilfried: still on the to-do-list, for obvious reasons (DB software reimplementation and RPSL transition) - On Wilfried Start discussion about legacy object migration on the list [ on the agenda ] - On Carsten Specify the "identity override" [ on the agenda ] C. DB Operations Update (Andrei R., RIPE NCC) "RIPE Database Operations Update" Andrei Robachevsky <andrei(a)ripe.net> Outline - Whois Service before migration - Whois Service after the migration - Related service RIPE Whois Service - Database Statistics - Database Operations - <ripe-dbm(a)ripe.net> 3.8 million objects [ graph ] sharp decrease caused by migration of German domains since then # objects grows slight slowdown caused by Austrian and Italian domain migration Distribution by object type [ chart ] Most objects were domain objects Now most objects are person objects (about 85%) Data protection [ graph ] Small number of unmaintained aut-nums Still maintained, but legacy objects that noone can change directly [ graph ] Person object protection - almost 30% unmaintained Wilfried: what about percentage? A: don't know what happened at RIPE 37 to cause numbers so low Wilfried: wasn't there a time when DENIC was requested to withdraw their maintainers? Ulf: needed to protect person objects to prevent someone else from changing them Andrei: *increase* was caused by German migration Ulf: DENIC has CRYPT-PW that every German ISP is supposed to know [ graph ] PGP deployment 2% of objects are PGP protected Domain migration - Domain objects migrated .at February 2001 .it April 2001 - Top 5 529956 .arpa 34334 .sk 11791 .hu 11132 .lt 8682 .lv - CENTR migration information Unreferenced person objects grow to 88% 28 June 2000 only 12% (before German domain migration) Today 88% Two factors: ccTLD's still use RIPE registry as nic-hdl generator a lot of person objects were left behind Personal Data in the DB 3,2 M person objects 66% unreferenced and maintained 22% unreferenced and unmaintained 12% referenced Legal consequences (details in Joao's presentation) Operations - Performance - Queries - Updates - Uptime Queries About 8/sec average [ graph ] Spike in March for Italian domains Spike in January for Austrian domains Needed to find all references Distribution of Queries 48% domains (before domain migration) 32% domains (after domain migration - almost half now IP numbers though) Updates About 5/min average [ graph ] Min/Max values since RIPE-38 Queries: 13 q/sec max, 6 q/sec min Updates: 50427/day max, 10/day min (caused by server slowdown) Update rate by object type [ chart ] Was 54% person [ chart ] Now 65% person after migration 56% are new persons Downtime and Actions Taken - No downtime - Main server performance slowdown 9 March hardware was upgraded to cope with load - Migration 2001-04-23 Deliberate query/update outage for 6 hours Communication with Database Users - Database status http://www.ripe.net/ripencc/pub-services/db/DBstatus.html - Database operational graphs http://www.ripe.net/ripencc/pub-services/db/mrtg/whois.html - FAQ http://www.ripe.net/ripencc/faq/database/ - RIPE-DBM RIPE DBM The Human Face of the Database - Engin Gündüz - Magnus Karlsson - Shane Kerr - Ambrose Magee - Denis Walker Magnus and Denis are new. Unfortunately Ambrose decided to leave RIPE NCC - May is his last month. RIPE-DBM - Activities - User support <ripe-dbm(a)ripe.net> - DB usage monitoring - AUP - NRTM - DB Server Performance Monitoring - Mntner object requests - PGP license requests - proposal to discontinue this service two reasons: 1. licenses are for (old) PGPi version with known bugs 2. new database uses GnuPG, which is open source and compatible <ripe-dbm(a)ripe.net> Typical week 1700 messages - maintainer creation requests (25-36/week) - PGP license requests (1-2/week) - general questions (50/week) etc. lots of country-to-ip mapping questions Whois Service After the Migration - Migration timeline - New Server Operatoipn - Presentation given at Joint DB/Routing WG session: http://www.ripe.net/ripe/meetings/current/ripe-39/presentations.html Migration Timeline - 2 April, ripe-db 3.0 release - 12 April, Advised Mirror switchover 4 servers mirror the new database - 19 April, Migration of the TEST database Dress rehersal of the migration - 23 April, Migration of the RIPE database Migratiopn night that lasted 12 hours 8-page migration manual no real problems - 14 May, default updates switch to RPSL - 15 October, RIPE-181 updates will no longer be accepted New Version of the RIPE Database - Supports RPSL (RFC2622) - extended syntax (for all object types) - new objects and attributes - Supports RPSS (RFC2725) - new authorization rules - Supports RAToolSet (4.7.0) RtConfig -protocol ripe - Code is completely rewritten Server Architecture [ diagram ] Queries per second weeks 14-17 No surprises, even though there were no surprises! Slight decrease, but no explanation [ graph ] Updates per minutes weeks 14-17 Again, no surprises [ graph ] Migration TODO list - still need to resolve minor issues - publish consistent documentation - make ripe-dbase-3.0.1 release - start next generation of DB consistency project - host and support development of RAToolSet Related RIPE Database Services - Database consistency project - Will be postponed until autumn when new version is available - Routing Reality Check - Not much progress since last RIPE meeting - TEST database - now in RPSL format - <test-dbm(a)ripe.net>, RIPE-181 format - <test-rpsl(a)ripe.net>, RPSL format - test-whois.ripe.net, port 43 Summary - The database was successfully migrated to v3.0 - domain migration is almost complete - still 2.5M unreferenced person objects left - things to do - DB consistency project - RRCC project - ripe-dbase-3.1.0 release - DBToolSet (incl. RAToolSet) Questions? Han Wills (Unis): as a multinational, really concerned about the RFC2725 issue. Cannot use it because some objects are in other registries, but they are still in the RIPE database, and security not enabled. Because they have to go to other objects as well, it would be really helpful to have mirroring between the registries. Andrei: we have a workaround to create foreign object - but you're right that security is low another problem is that even if we have a perfect solution, other registries don't implement RFC2725 (yet), so we can't guarantee security, so this depends on collaboration with other registries - we can't do it alone Han Wils: is this high priority? Andrei: we think this is very important - and it breaks the advantage of RFC2725. We're going to discuss this issue in more detail at NANOG, and probably we can find some kind of solution. Han Wils: it would be helpful if you could post some progress to the database working group list APNIC: going to migrate to the database (RIPE v3 code), but about 6 to 9 months behind the RIPE NCC Wilfried: does it make a difference to have the same software deployed in two registries? Joao: the software is not relavent, but right now the new RIPE database software is the only code that implements RFC725. We could solve certain authentication problems, but we would still have one problem with ARIN's authentication/authorization model, which is quite different. ** Wilfried: I'm going to put this on the plate as the Next Big Project. The NCC should find out what the problems are, so we can start working on it. ** Gert Döring from spacenet: Would like to see some sort of synchronous update mechnanism for the database. It might be useful for others as well. Andrei: we appreciate this kind of input. This is on the list for "DBToolSet", so maybe this kind of thing can be done there. Wilfried: thanks to RIPE NCC Andrei: if you have problems, contact us Wilfried's short list of questions: - How many have digital signature technology available everyday? less than half answered - How many use commercial PGP implementation? some - How many use GPG? less - Who would be interested in a workshop or training in PGP? some We'll try to organize some sort of BOF or training for RIPE40 Ulf: who is still using MAIL-FROM? [ laughter ] D. Report from the ReImp/Mig TF (Ulf K., and NCC DB Group) Ulf Kieber: Thanks to RIPE NCC for smooth transition! Basically a short revamp of presentation yesterday 4 different types of problems PGP Update problems - took about 1 day to resolve - 181 translation path does not process PGP correctly Acknowledgement problems - no ack for some updates Conversion problems - minor indentation issues If you have had problems with some updates, please double-check and/or resend updates. NCC should probably discard old update messages, as re-processing them might rol back objects to an older state Wilfried: proposes to close down task force, agreed. E. "Orphaned" person object (Joao) How many attendees are LIR? A fair number Problem with several million unreferenced person objects is that we have a potential legal problem. Certain European Union directives about what you can store in databases. Basically you should not store information about anyone that is not required and directly related to your operations. Not only do we do this, but it is publicly accessible. It's not necessary. There for historical reasons, but not directly related to current operations. This is becoming a big problem. Afraid that the RIPE NCC will be held liable for holding information that it shouldn't. Is this something we should try to fix? If so, when? How? Ulf: internal attribute that marks with timestamp "unused since", after a certain period of time purge the object Joao: but do people think that we want to proceed with deleting these objects? Ulf: usually maintainer objects, and this person would be held responsible ??1: DE registry is planning on deleting all of ours, and they should be deleted. The ccTLD domain registries should pull their person objects. ??2: Kind of "echo" of DE domains, should be made clear that this status is a transitional state. A quick fix would not be very helpful. Wilfried: how do we overlap between unreferenced but maintained and those necessary for DENIC? Joao: let's not just concentrate on DENIC Andrei: 600000 by DENIC, 400000 by (next highest) ??3: DENIC does not accept registration if person object is unmaintained. Joao: problem is not that it is maintained or not, but rather that it is there and not related to other objects in the database. If DENIC is a problem, should we put a deadline? In the meantime, we need to solve the problem. ??4: If person object is unreferenced, we have to remove them ASAP. Send a note to the maintainer? ??2: RIPE NCC should be aware of the problem. Has the RIPE NCC already been the target of data protection authorities? Is this really a problem now or is it just to be watched carefully? Joao: not worried about authorities, but rather individuals complaining Ulf: need an automatic timeout ??3: As soon as object remains unreferenced, delete it. Wilfried: concensus that should only contain data related to the purpose of the database. We have watched the domain name thing for quite a while, (setting a deadline) is helpful. Propose to delete unreferenced objects by June 1, and inform maintainers beforehand. If DENIC (or whoever) can provide documentation of requirement, then RIPE NCC should be safe. Andrei: are we trying to solve only DENIC problem? Joao: no, no, no. We need a clear statement for ALL sources of information like this. Andrei: although DENIC contains most numbers, when DENIC removes objects, we don't expect complaints. For *other* objects, we DO expect complaints. ** Wilfried: put an action on the NCC about what we intend to do -> Joao will generate problem statement, proposals, and target date of June 1. <- ??5: proposes to send e-mail to people, like ARIN did it Ray Plzk (ARIN): we did this, then deleted ???: not useful for generic case where objects are maintained. Do we want to handle the 0.5 million questions about this, and how? F. Enhancements to IRRd to support SQL, Jake K. and Karen W. "A Relational DB Approach to the IRR" Jake Khuon, Global Crossing Gerald Winters, Global Crossing Karen Williams, TimesTen "Yet Another Relational DB Approach to the IRR" :) Gerald did most of coding at Global Crossing Goals - Replacement of the radix tree data structures used by IRRd to store objects with relational tables and an SQL backend database. - Maintain comparable performance Motivations - Flexible query - "Power" of SQL - Can make development of tools simpler - Flexible development platform - hard coded data structures required some hard coded query routines - can make extensions to the database simpler - Some data best represented as relational tables Concerns/Requirements - Performance - Need to compete with speed of in-memory radix structures - Dual datastore philosophy - "Fast path" (IRRd native radix) - "Slow path" (SQL tables) - Some data would have to exist in both - Synchronization problems - Path decision maker routine would add latency - SQL tables only philosophy - Single datastore: data exists in only one place - Would need to be in-memory for speed - Scalability - Needs to handle large number of objects (3+ million) - Needs to model multiple registries - Robustness - Transaction logging - replication System Characteristics - IRRd is now a query/update core server - Both RPSL and RIPE-181 compliant will not handle mixed-datatypes - all in a source must be alike - SQL pass-thru interface - Service front-ends implemented as modules (e.g. email) - TimesTen is the database manager. - No IRRd indexing - A 100% TimesTen relational DB backend What is TimesTen? - An in-memory relational database - 1000% faster than disk-based databases - Standard database features: - SQL2 language and full SQL transaction semantics - Fully durable (always two database copies on disk) - Replication for high availability - Thread-safe General Schema Design - Keep a copy of each object referenced by unique 'ID' Misc_Tbl - All the data to search on kept in auxiliary index tables Pre-Compiled vs. User-Defined Queries - Use pre-compiled queries where feasible for increased performance - IRRd ! queries - ripewhois queries - Allow the user to define queries (SQL select) - select * from mntner_tbl where ... Query Path Overview - Pre-compiled path already bound (msec faster) [ no number brought though ] Whois Query Processing - Use knowledge of object types to speed up lookups by reducing the number of object tabes that must be searched e.g. "rs-..." can only be a route set object - Need radix tree '1-level-less-specific' search capability to support whois queries Radix Lookups - four types - 1 level less specific - all levels less specific - 1 level more specific - all levels more specific - use numeric representation suitable for relational tables first, last, and middle address Radix Lookup Examples - select route from Route_Tbl where FA >= FAr and LA >= LAr and source = '..' Whois Query Processing (continued) - Need secondary indexing to support inverse lookups and person lookups - build an inverse table as index into main table Joao: Database is 1000% faster than disk-based? What would comparison look like if using a RAMdisk or a big cache? Karen: we compare with full caching, we know where our data is. We're still 10x faster! I've seen between 20 and 40x faster at customer sites. Joao: How to implement more or less specific queries. We use a special index external to database. What are the advantages of using full relational model? Jake: When doing updates - with a radix tree, you need to synchronize tree and databases. This was simpler. Cengiz: More specific required radix tree, less specific was no problem. How do you do more specific? Most of the time I just want the keys. Cengiz: Request to implement more specific queries. Antony Antony: to x10, how much memory for 3 million objects Karen: less than 0.5 Gbyte in memory G. Something like a "force:" (or force-delete) attribute. Unable to change a person's *name* on a person object. If not referenced, it is easy to delete, but otherwise have to go through RIPE-DBM mailbox. Want a "force" attribute to specify "I really know what I'm doing" when changing a person name. Is this on the "wish-list" or not? ???: Pretty important to have a way to change a name. Why do we need a special attribute? While I like the attribute, perhaps it is the wrong way. Should just do it! Joao: internally currently not possible. Still some objects with references by name exist, and this prevents it. Something like 4000 objects with references by name. If we can clean up these objects, we can release this artificial constraints. David Kessens: thought was that a typo in the nic-hdl could overwrite the information in a person object Wilfried: if reference by name, change contact to to all nic-hdl list Joao: if by name, kind of undefined, but if by nic-hdl seems like an assignment ???: Add a remark if we do this! [Speaker]: Is this a priority? Santos: Allow to change name of person? If change initial shouldn't handle change as well? Wilfried: that's what we have now! Andrei: two issues: 1. reference by name and cleaning up is important and a good idea 2. releasing primary key constraint - concern is unintentional hijacking of person objects Also from RIPE-DBM point of view, don't see a lot of requests to change these kinds of typos. If really an issue, then we can do it, other wise we can have a more clear procedure. Ulf: 3 persons were left wrong because it was easier than sending to RIPE-DBM. If I could do it myself, then would do it. ???: really not something that should go to a human Joao: I actually support users doing it themselves. Would prefer fixing references and removing restrictions rather than adding a new feature. Wilfried: after unreferenced objects, how many are left? ??2: many objects that reference person by name and not unique Joao: *all* name-based references left are non-unique Wilfried: replace name with however many handles are necessary, plus put in a remarks line ???: force thing is not that bad - because of typos, just a gut feeling because I'll be the one to fix it H. Legacy Object Migration, Richard J. "Early Registration Record Transfers" Richard Jimmerson, ARIN Background 1980's - All IP and AS registrations made by entities under a US Department of Defense contract 1990's - APNIC and RIPE NCC began registering IP and AS numbers for their respective regions Current Situation - Many registrations not maintained by appropriate regional registry - Many organizations have to interact with more than one RIR to modify their registration records - Have difficulty making timely in-addr.arpa updates - The in-addr.arpa zone contains delegations longer than a /8 (/16's and /24's) Goals - Registration records will be maintained in the appropriate RIR database - Organizations will be able to: - interact with a single RIR - make more timely in-addr.arpa updates - in-addr.arpa zone will contain only /8 delegations Tasks - transfer all IPv4 registrations to appropriate RIR - transfer all AS registration to appropriate RIR - establish in-addr.arpa domains Maintaining in-addr.arpa - each RIR will maintain a suite of in-addr.arpa servers - APNIC/RIPE NCC have already deployed - ARIN is testing - non-shared /8 maintained by appropriate RIR - shared /8 maintained by majority record holder RIR coordination efforts - sample dump provided by ARIN in early 2000 - candidate list provided by ARIN 2000-08-22 - companion dump of all network data provided 2000-08-23 - updated/additional data provided 2001-03 "Pre-RIR address space" Mirjam Kuehne, RIPE NCC Related Items - Transfer of DB objects - technically easy - conflicts need to be resolved - Merger algorithm for reverse delegation - techincally easy - ARIN setting up reverse DNS server - start testing in Q2/2001 Current Issues - What determines transfer? - location of network - Conflicts in inetnum objects - Conflicts in person/role objects - What if contact person is not approachable - If in doubt, keep as is? Possible inetnum conflicts 1. Exact match in ARIN and RIPE DB (4325) - override one with the other Wilfried: what do you mean by exact match? Mirjam: address range exact match, not whole object 2. More specific network in RIPE DB (e.g. allocation in ARIN, assignements in RIPE) - keep both? 3. Minor mismatch - override one with the other (latest data?) - human intervention - contact maintainer 4. More specific network in ARIN DB (3060) Next Steps - publish list of objects to be transferred - operators encouraged to actively transfer data - clear procedure needed - try to resolve easy conflicts - try to alert all contacts affected by transfer - find out what operators need to prepare Joao: exact match - solution is override one with the other, but which one? we want suggestions! David Kessens: how much data? Joao: numbers in parenthesis David Kessens: contact those people first, case by case Mirjam: what if can't find? David: then leave as is Wilfried: could label space as "up for reclaim" (joke) David: might be a small group of people Wilfried: what about person objects? It could be messy. Ray Plzak: suggestion: for exact matches, make a synthesis and timestamp the effective data of the merger, and timestamp when the record was created in the ARIN database Ulf: first ask which database do I need to hold my objects Joao: now maintained in ARIN, will be in RIPE NCC Wilfried: got community start thinking about it - please keep us informed! Y. Input from other WG's (From Local-IR) Try to make database transactions more accessible and easy to understand Make it more transparent for the end users Nurani: we spend a lot of time answering questions on how to interact with the RIPE database suggestion of improving documentation perhaps also easier tools (web end or other tools) Wilfried: also not relying on NCC staff for easy-to-answer questions also, can we recruit a small team of individuals to subscribe to a db-help mailing list? Andrei: planning on publishing user manual Wilfried: database working group will take this task on before the next meeting See you again in Prague! ______________________________________________________________________

2 1

2nd draft DB-WG minutes, RIPE39 @ BLQ (v4)
by Wilfried Woeber, UniVie/ACOnet 08 May '01

08 May '01

Attached please find the 2nd draft for the DB-WG minutes (v4). A big thank you to Shane for taking notes, and to Markos, Holger and Carsten for submitting corrections regarding missing names. We are still working on collecting the URLs for the presentations, and on aggregating the open actions - before putting the minutes up on the web as well. Comments and corrections still welcome - in particular if you feel mis-quoted or represented as name??. Thank you, regards, 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Draft Minutes, Database Working Group v4, 08-May-2001 RIPE39 @ Bologna A. Admin stuff - list of participants, scribe Scribe: Shane Kerr - agenda bashing Draft agenda accepted as final - minutes approved - content-wise, action on Wilfried and webmaster(a)ripe.net to insert links to presentations B. Actions From previous meetings - On Joao to present "unique handle proposal" @ ARIN meeting Joao: still needs more work, so it wasn't presented. Randy Bush is going to submit an IETF draft. Wilfried: can the draft be submitted to DB-WG mailing list? Joao: still needs some brush up... Wilfried: can you keep track of this? Joao: yes, Action on Joao to track development of draft and circulate the draft (or a pointer to the draft) on the DB-WG mailing list - On NCC DB Group (Joao) implement "lir-allocated" attribute fo inetnum objects Wilfried: still on the to-do-list, for obvious reasons (DB software reimplementation and RPSL transition) - On Wilfried Start discussion about legacy object migration on the list [ on the agenda ] - On Carsten Specify the "identity override" [ on the agenda ] C. DB Operations Update (Andrei R., RIPE NCC) "RIPE Database Operations Update" Andrei Robachevsky <andrei(a)ripe.net> Outline - Whois Service before migration - Whois Service after the migration - Related service RIPE Whois Service - Database Statistics - Database Operations - <ripe-dbm(a)ripe.net> 3.8 million objects [ graph ] sharp decrease caused by migration of German domains since then # objects grows slight slowdown caused by Austrian and Italian domain migration Distribution by object type [ chart ] Most objects were domain objects Now most objects are person objects (about 85%) Data protection [ graph ] Small number of unmaintained aut-nums Still maintained, but legacy objects that noone can change directly [ graph ] Person object protection - almost 30% unmaintained Wilfried: what about percentage? A: don't know what happened at RIPE 37 to cause numbers so low Wilfried: wasn't there a time when DENIC was requested to withdraw their maintainers? Ulf: needed to protect person objects to prevent someone else from changing them Andrei: *increase* was caused by German migration Ulf: DENIC has CRYPT-PW that every German ISP is supposed to know [ graph ] PGP deployment 2% of objects are PGP protected Domain migration - Domain objects migrated .at February 2001 .it April 2001 - Top 5 529956 .arpa 34334 .sk 11791 .hu 11132 .lt 8682 .lv - CENTR migration information Unreferenced person objects grow to 88% 28 June 2000 only 12% (before German domain migration) Today 88% Two factors: ccTLD's still use RIPE registry as nic-hdl generator a lot of person objects were left behind Personal Data in the DB 3,2 M person objects 66% unreferenced and maintained 22% unreferenced and unmaintained 12% referenced Legal consequences (details in Joao's presentation) Operations - Performance - Queries - Updates - Uptime Queries About 8/sec average [ graph ] Spike in March for Italian domains Spike in January for Austrian domains Needed to find all references Distribution of Queries 48% domains (before domain migration) 32% domains (after domain migration - almost half now IP numbers though) Updates About 5/min average [ graph ] Min/Max values since RIPE-38 Queries: 13 q/sec max, 6 q/sec min Updates: 50427/day max, 10/day min (caused by server slowdown) Update rate by object type [ chart ] Was 54% person [ chart ] Now 65% person after migration 56% are new persons Downtime and Actions Taken - No downtime - Main server performance slowdown 9 March hardware was upgraded to cope with load - Migration 2001-04-23 Deliberate query/update outage for 6 hours Communication with Database Users - Database status http://www.ripe.net/ripencc/pub-services/db/DBstatus.html - Database operational graphs http://www.ripe.net/ripencc/pub-services/db/mrtg/whois.html - FAQ http://www.ripe.net/ripencc/faq/database/ - RIPE-DBM RIPE DBM The Human Face of the Database - Engin Gündüz - Magnus Karlsson - Shane Kerr - Ambrose Magee - Denis Walker Magnus and Denis are new. Unfortunately Ambrose decided to leave RIPE NCC - May is his last month. RIPE-DBM - Activities - User support <ripe-dbm(a)ripe.net> - DB usage monitoring - AUP - NRTM - DB Server Performance Monitoring - Mntner object requests - PGP license requests - proposal to discontinue this service two reasons: 1. licenses are for (old) PGPi version with known bugs 2. new database uses GnuPG, which is open source and compatible <ripe-dbm(a)ripe.net> Typical week 1700 messages - maintainer creation requests (25-36/week) - PGP license requests (1-2/week) - general questions (50/week) etc. lots of country-to-ip mapping questions Whois Service After the Migration - Migration timeline - New Server Operatoipn - Presentation given at Joint DB/Routing WG session: http://www.ripe.net/ripe/meetings/current/ripe-39/presentations.html Migration Timeline - 2 April, ripe-db 3.0 release - 12 April, Advised Mirror switchover 4 servers mirror the new database - 19 April, Migration of the TEST database Dress rehersal of the migration - 23 April, Migration of the RIPE database Migratiopn night that lasted 12 hours 8-page migration manual no real problems - 14 May, default updates switch to RPSL - 15 October, RIPE-181 updates will no longer be accepted New Version of the RIPE Database - Supports RPSL (RFC2622) - extended syntax (for all object types) - new objects and attributes - Supports RPSS (RFC2725) - new authorization rules - Supports RAToolSet (4.7.0) RtConfig -protocol ripe - Code is completely rewritten Server Architecture [ diagram ] Queries per second weeks 14-17 No surprises, even though there were no surprises! Slight decrease, but no explanation [ graph ] Updates per minutes weeks 14-17 Again, no surprises [ graph ] Migration TODO list - still need to resolve minor issues - publish consistent documentation - make ripe-dbase-3.0.1 release - start next generation of DB consistency project - host and support development of RAToolSet Related RIPE Database Services - Database consistency project - Will be postponed until autumn when new version is available - Routing Reality Check - Not much progress since last RIPE meeting - TEST database - now in RPSL format - <test-dbm(a)ripe.net>, RIPE-181 format - <test-rpsl(a)ripe.net>, RPSL format - test-whois.ripe.net, port 43 Summary - The database was successfully migrated to v3.0 - domain migration is almost complete - still 2.5M unreferenced person objects left - things to do - DB consistency project - RRCC project - ripe-dbase-3.1.0 release - DBToolSet (incl. RAToolSet) Questions? Holger Münx (UUnet DE): as a multinational, really concerned about the RFC2725 issue. Cannot use it because some objects are in other registries, but they are still in the RIPE database, and security not enabled. Because they have to go to other objects as well, it would be really helpful to have mirroring between the registries. Andrei: we have a workaround to create foreign object - but you're right that security is low another problem is that even if we have a perfect solution, other registries don't implement RFC2725 (yet), so we can't guarantee security, so this depends on collaboration with other registries - we can't do it alone Holger: is this high priority? Andrei: we think this is very important - and it breaks the advantage of RFC2725. We're going to discuss this issue in more detail at NANOG, and probably we can find some kind of solution. Holger: it would be helpful if you could post some progress to the database working group list APNIC: going to migrate to the database (RIPE v3 code), but about 6 to 9 months behind the RIPE NCC Wilfried: does it make a difference to have the same software deployed in two registries? Joao: the software is not relavent, but right now the new RIPE database software is the only code that implements RFC725. We could solve certain authentication problems, but we would still have one problem with ARIN's authentication/authorization model, which is quite different. ** Wilfried: I'm going to put this on the plate as the Next Big Project. The NCC should find out what the problems are, so we can start working on it. ** Gert Döring from spacenet: Would like to see some sort of synchronous update mechnanism for the database. It might be useful for others as well. Andrei: we appreciate this kind of input. This is on the list for "DBToolSet", so maybe this kind of thing can be done there. Wilfried: thanks to RIPE NCC Andrei: if you have problems, contact us Wilfried's short list of questions: - How many have digital signature technology available everyday? less than half answered - How many use commercial PGP implementation? some - How many use GPG? less - Who would be interested in a workshop or training in PGP? some We'll try to organize some sort of BOF or training for RIPE40 Ulf: who is still using MAIL-FROM? [ laughter ] D. Report from the ReImp/Mig TF (Ulf K., and NCC DB Group) Ulf Kieber: Thanks to RIPE NCC for smooth transition! Basically a short revamp of presentation yesterday 4 different types of problems PGP Update problems - took about 1 day to resolve - 181 translation path does not process PGP correctly Acknowledgement problems - no ack for some updates Conversion problems - minor indentation issues If you have had problems with some updates, please double-check and/or resend updates. NCC should probably discard old update messages, as re-processing them might rol back objects to an older state Wilfried: proposes to close down task force, agreed. E. "Orphaned" person object (Joao) How many attendees are LIR? A fair number Problem with several million unreferenced person objects is that we have a potential legal problem. Certain European Union directives about what you can store in databases. Basically you should not store information about anyone that is not required and directly related to your operations. Not only do we do this, but it is publicly accessible. It's not necessary. There for historical reasons, but not directly related to current operations. This is becoming a big problem. Afraid that the RIPE NCC will be held liable for holding information that it shouldn't. Is this something we should try to fix? If so, when? How? Ulf: internal attribute that marks with timestamp "unused since", after a certain period of time purge the object Joao: but do people think that we want to proceed with deleting these objects? Ulf: usually maintainer objects, and this person would be held responsible ??1: DE registry is planning on deleting all of ours, and they should be deleted. The ccTLD domain registries should pull their person objects. Carsten Schiefner: Kind of "echo" of DE domains, should be made clear that this status is a transitional state. A quick fix would not be very helpful. Wilfried: how do we overlap between unreferenced but maintained and those necessary for DENIC? Joao: let's not just concentrate on DENIC Andrei: 600000 by DENIC, 400000 by (next highest) Marcos Sanz: DENIC does not accept registration if person object is unmaintained. Joao: problem is not that it is maintained or not, but rather that it is there and not related to other objects in the database. If DENIC is a problem, should we put a deadline? In the meantime, we need to solve the problem. ??4: If person object is unreferenced, we have to remove them ASAP. Send a note to the maintainer? Carsten: RIPE NCC should be aware of the problem. Has the RIPE NCC already been the target of data protection authorities? Is this really a problem now or is it just to be watched carefully? Joao: not worried about authorities, but rather individuals complaining Ulf: need an automatic timeout ???: As soon as object remains unreferenced, delete it. Wilfried: concensus that should only contain data related to the purpose of the database. We have watched the domain name thing for quite a while, (setting a deadline) is helpful. Propose to delete unreferenced objects by June 1, and inform maintainers beforehand. If DENIC (or whoever) can provide documentation of requirement, then RIPE NCC should be safe. Andrei: are we trying to solve only DENIC problem? Joao: no, no, no. We need a clear statement for ALL sources of information like this. Andrei: although DENIC contains most numbers, when DENIC removes objects, we don't expect complaints. For *other* objects, we DO expect complaints. ** Wilfried: put an action on the NCC about what we intend to do -> Joao will generate problem statement, proposals, and target date of June 1. <- ??5: proposes to send e-mail to people, like ARIN did it Ray Plzk (ARIN): we did this, then deleted ???: not useful for generic case where objects are maintained. Do we want to handle the 0.5 million questions about this, and how? F. Enhancements to IRRd to support SQL, Jake K. and Karen W. "A Relational DB Approach to the IRR" Jake Khuon, Global Crossing Gerald Winters, Global Crossing Karen Williams, TimesTen "Yet Another Relational DB Approach to the IRR" :) Gerald did most of coding at Global Crossing Goals - Replacement of the radix tree data structures used by IRRd to store objects with relational tables and an SQL backend database. - Maintain comparable performance Motivations - Flexible query - "Power" of SQL - Can make development of tools simpler - Flexible development platform - hard coded data structures required some hard coded query routines - can make extensions to the database simpler - Some data best represented as relational tables Concerns/Requirements - Performance - Need to compete with speed of in-memory radix structures - Dual datastore philosophy - "Fast path" (IRRd native radix) - "Slow path" (SQL tables) - Some data would have to exist in both - Synchronization problems - Path decision maker routine would add latency - SQL tables only philosophy - Single datastore: data exists in only one place - Would need to be in-memory for speed - Scalability - Needs to handle large number of objects (3+ million) - Needs to model multiple registries - Robustness - Transaction logging - replication System Characteristics - IRRd is now a query/update core server - Both RPSL and RIPE-181 compliant will not handle mixed-datatypes - all in a source must be alike - SQL pass-thru interface - Service front-ends implemented as modules (e.g. email) - TimesTen is the database manager. - No IRRd indexing - A 100% TimesTen relational DB backend What is TimesTen? - An in-memory relational database - 1000% faster than disk-based databases - Standard database features: - SQL2 language and full SQL transaction semantics - Fully durable (always two database copies on disk) - Replication for high availability - Thread-safe General Schema Design - Keep a copy of each object referenced by unique 'ID' Misc_Tbl - All the data to search on kept in auxiliary index tables Pre-Compiled vs. User-Defined Queries - Use pre-compiled queries where feasible for increased performance - IRRd ! queries - ripewhois queries - Allow the user to define queries (SQL select) - select * from mntner_tbl where ... Query Path Overview - Pre-compiled path already bound (msec faster) [ no number brought though ] Whois Query Processing - Use knowledge of object types to speed up lookups by reducing the number of object tabes that must be searched e.g. "rs-..." can only be a route set object - Need radix tree '1-level-less-specific' search capability to support whois queries Radix Lookups - four types - 1 level less specific - all levels less specific - 1 level more specific - all levels more specific - use numeric representation suitable for relational tables first, last, and middle address Radix Lookup Examples - select route from Route_Tbl where FA >= FAr and LA >= LAr and source = '..' Whois Query Processing (continued) - Need secondary indexing to support inverse lookups and person lookups - build an inverse table as index into main table Joao: Database is 1000% faster than disk-based? What would comparison look like if using a RAMdisk or a big cache? Karen: we compare with full caching, we know where our data is. We're still 10x faster! I've seen between 20 and 40x faster at customer sites. Joao: How to implement more or less specific queries. We use a special index external to database. What are the advantages of using full relational model? Jake: When doing updates - with a radix tree, you need to synchronize tree and databases. This was simpler. Cengiz: More specific required radix tree, less specific was no problem. How do you do more specific? Most of the time I just want the keys. Cengiz: Request to implement more specific queries. Antony Antony: to x10, how much memory for 3 million objects Karen: less than 0.5 Gbyte in memory G. Something like a "force:" (or force-delete) attribute. Unable to change a person's *name* on a person object. If not referenced, it is easy to delete, but otherwise have to go through RIPE-DBM mailbox. Want a "force" attribute to specify "I really know what I'm doing" when changing a person name. Is this on the "wish-list" or not? ???: Pretty important to have a way to change a name. Why do we need a special attribute? While I like the attribute, perhaps it is the wrong way. Should just do it! Joao: internally currently not possible. Still some objects with references by name exist, and this prevents it. Something like 4000 objects with references by name. If we can clean up these objects, we can release this artificial constraints. David Kessens: thought was that a typo in the nic-hdl could overwrite the information in a person object Wilfried: if reference by name, change contact to to all nic-hdl list Joao: if by name, kind of undefined, but if by nic-hdl seems like an assignment ???: Add a remark if we do this! [Speaker]: Is this a priority? Santos: Allow to change name of person? If change initial shouldn't handle change as well? Wilfried: that's what we have now! Andrei: two issues: 1. reference by name and cleaning up is important and a good idea 2. releasing primary key constraint - concern is unintentional hijacking of person objects Also from RIPE-DBM point of view, don't see a lot of requests to change these kinds of typos. If really an issue, then we can do it, other wise we can have a more clear procedure. Ulf: 3 persons were left wrong because it was easier than sending to RIPE-DBM. If I could do it myself, then would do it. ???: really not something that should go to a human Joao: I actually support users doing it themselves. Would prefer fixing references and removing restrictions rather than adding a new feature. Wilfried: after unreferenced objects, how many are left? Carsten: many objects that reference person by name and not unique Joao: *all* name-based references left are non-unique Wilfried: replace name with however many handles are necessary, plus put in a remarks line Gert: force thing is not that bad - because of typos, just a gut feeling because I'll be the one to fix it H. Legacy Object Migration, Richard J. "Early Registration Record Transfers" Richard Jimmerson, ARIN Background 1980's - All IP and AS registrations made by entities under a US Department of Defense contract 1990's - APNIC and RIPE NCC began registering IP and AS numbers for their respective regions Current Situation - Many registrations not maintained by appropriate regional registry - Many organizations have to interact with more than one RIR to modify their registration records - Have difficulty making timely in-addr.arpa updates - The in-addr.arpa zone contains delegations longer than a /8 (/16's and /24's) Goals - Registration records will be maintained in the appropriate RIR database - Organizations will be able to: - interact with a single RIR - make more timely in-addr.arpa updates - in-addr.arpa zone will contain only /8 delegations Tasks - transfer all IPv4 registrations to appropriate RIR - transfer all AS registration to appropriate RIR - establish in-addr.arpa domains Maintaining in-addr.arpa - each RIR will maintain a suite of in-addr.arpa servers - APNIC/RIPE NCC have already deployed - ARIN is testing - non-shared /8 maintained by appropriate RIR - shared /8 maintained by majority record holder RIR coordination efforts - sample dump provided by ARIN in early 2000 - candidate list provided by ARIN 2000-08-22 - companion dump of all network data provided 2000-08-23 - updated/additional data provided 2001-03 "Pre-RIR address space" Mirjam Kuehne, RIPE NCC Related Items - Transfer of DB objects - technically easy - conflicts need to be resolved - Merger algorithm for reverse delegation - techincally easy - ARIN setting up reverse DNS server - start testing in Q2/2001 Current Issues - What determines transfer? - location of network - Conflicts in inetnum objects - Conflicts in person/role objects - What if contact person is not approachable - If in doubt, keep as is? Possible inetnum conflicts 1. Exact match in ARIN and RIPE DB (4325) - override one with the other Wilfried: what do you mean by exact match? Mirjam: address range exact match, not whole object 2. More specific network in RIPE DB (e.g. allocation in ARIN, assignements in RIPE) - keep both? 3. Minor mismatch - override one with the other (latest data?) - human intervention - contact maintainer 4. More specific network in ARIN DB (3060) Next Steps - publish list of objects to be transferred - operators encouraged to actively transfer data - clear procedure needed - try to resolve easy conflicts - try to alert all contacts affected by transfer - find out what operators need to prepare Joao: exact match - solution is override one with the other, but which one? we want suggestions! David Kessens: how much data? Joao: numbers in parenthesis David Kessens: contact those people first, case by case Mirjam: what if can't find? David: then leave as is Wilfried: could label space as "up for reclaim" (joke) David: might be a small group of people Wilfried: what about person objects? It could be messy. Ray Plzak: suggestion: for exact matches, make a synthesis and timestamp the effective data of the merger, and timestamp when the record was created in the ARIN database Ulf: first ask which database do I need to hold my objects Joao: now maintained in ARIN, will be in RIPE NCC Wilfried: got community start thinking about it - please keep us informed! Y. Input from other WG's (From Local-IR) Try to make database transactions more accessible and easy to understand Make it more transparent for the end users Nurani: we spend a lot of time answering questions on how to interact with the RIPE database suggestion of improving documentation perhaps also easier tools (web end or other tools) Wilfried: also not relying on NCC staff for easy-to-answer questions also, can we recruit a small team of individuals to subscribe to a db-help mailing list? Andrei: planning on publishing user manual Wilfried: database working group will take this task on before the next meeting See you again in Prague! ______________________________________________________________________

1 0

Re: AS searching
by Andrei Robachevsky 01 May '01

01 May '01

Dear Hank, Hank Nussbacher wrote: > > I have read over all the documentation and still can't figure out how to > search the RPSL for aut-num objects that have either import or export lines > with ASnnnn. Can anyone give me an example? > Unfortunately, this is not possible via whois queries, as import/export are not lookup attributes. However, you can use "raw text search" to do this. Please try it at http://www.ripe.net/cgi-bin/ripedbsearch. > Thanks, > Hank Regards, Andrei Robachevsky DB Group Manager RIPE NCC

1 0

RE: RETRY: as-set syntax errors ?
by Low, Adam 27 Apr '01

27 Apr '01

Works fine, Many thanks! > -----Original Message----- > From: Engin Gunduz [mailto:engin@ripe.net] > Sent: 27 April 2001 14:49 > To: Low, Adam > Cc: 'kieber(a)gatel.net'; db-wg(a)ripe.net > Subject: RE: RETRY: as-set syntax errors ? > > > > Hi Adam, > > This was a problem in the update path and is fixed yesterday. Now > you should be able to update as-sets (and other object with descr > attributes) with multiple descr attributes. > > Sorry for any inconvenience, > > Best regards, > > Engin Gunduz > RIPE NCC Database Group > > > On Fri, 27 Apr 2001, Low, Adam wrote: > > > Thanks, do you think this is a mistake in the template or > bug in the database ? > > > > > -----Original Message----- > > > From: kieber(a)gatel.net [mailto:kieber@gatel.net] > > > Sent: 27 April 2001 13:46 > > > To: ALow(a)Prioritytelecom.com > > > Cc: db-wg(a)ripe.net > > > Subject: Re: RETRY: as-set syntax errors ? > > > > > > > > > Low, Adam writes: > > > > Sure but the template suggests multiple descr fields > are allowed ? > > > > > > > > descr: [mandatory] [multiple] [ ] > > > > > > > > If this isnt the case, the template should ideally be changed to > > > > avoid confusion. > > > > > > You are right. I didn't cross-check the template, sorry. > > > > > > > > -----Original Message----- > > > > > From: kieber(a)gatel.net [mailto:kieber@gatel.net] > > > > > Sent: 24 April 2001 20:49 > > > > > To: ALow(a)Prioritytelecom.com > > > > > Cc: db-wg(a)ripe.net > > > > > Subject: Re: RETRY: as-set syntax errors ? > > > > > > > > > > > > > > > Low, Adam writes: > > > > > > I seem to be having problems sending in an update for the > > > > > > following object, I've double checked it and I must be > > > > > > missing something, any suggestions ? > > > > > > > > > > > > Update FAILED: Syntax error in object > > > > > > as-set: AS-PRIORITY > > > > > > descr: Priority Telecom AS Macro > > > > > ^^^^^ > > > > > > descr: AS13646 and Global Customers > > > > > ^^^^^ > > > > > > members: AS13646 > > > > > > > > > > > ***Error: single-valued attribute descr occurs > multiple times. > > > > > > > > > > As it says, the descr: attribute is allowed only once in > > > an as-set. > > > > > > > > > > > The only differences to the previous object are the changed > > > > > > fields and the addition of AS10160. > > > > > > > > > > As as-sets are automatically converted from as-macros and > > > descr: was > > > > > allowed multiple times in as-macros you need to get rid of the > > > > > conflict now. > > > > > > -- > > > Ulf Kieber email: kieber(a)gatel.net > > > Network Engineer voice: +49-69-299896-21 > > > Global Access Telecommunications, Inc. fax : +49-69-299896-40 > > > internet solutions for business www : www.gatel.net > > > > > >

1 0

RE: RETRY: as-set syntax errors ?
by Low, Adam 27 Apr '01

27 Apr '01

Thanks, do you think this is a mistake in the template or bug in the database ? > -----Original Message----- > From: kieber(a)gatel.net [mailto:kieber@gatel.net] > Sent: 27 April 2001 13:46 > To: ALow(a)Prioritytelecom.com > Cc: db-wg(a)ripe.net > Subject: Re: RETRY: as-set syntax errors ? > > > Low, Adam writes: > > Sure but the template suggests multiple descr fields are allowed ? > > > > descr: [mandatory] [multiple] [ ] > > > > If this isnt the case, the template should ideally be changed to > > avoid confusion. > > You are right. I didn't cross-check the template, sorry. > > > > -----Original Message----- > > > From: kieber(a)gatel.net [mailto:kieber@gatel.net] > > > Sent: 24 April 2001 20:49 > > > To: ALow(a)Prioritytelecom.com > > > Cc: db-wg(a)ripe.net > > > Subject: Re: RETRY: as-set syntax errors ? > > > > > > > > > Low, Adam writes: > > > > I seem to be having problems sending in an update for the > > > > following object, I've double checked it and I must be > > > > missing something, any suggestions ? > > > > > > > > Update FAILED: Syntax error in object > > > > as-set: AS-PRIORITY > > > > descr: Priority Telecom AS Macro > > > ^^^^^ > > > > descr: AS13646 and Global Customers > > > ^^^^^ > > > > members: AS13646 > > > > > > > ***Error: single-valued attribute descr occurs multiple times. > > > > > > As it says, the descr: attribute is allowed only once in > an as-set. > > > > > > > The only differences to the previous object are the changed > > > > fields and the addition of AS10160. > > > > > > As as-sets are automatically converted from as-macros and > descr: was > > > allowed multiple times in as-macros you need to get rid of the > > > conflict now. > > -- > Ulf Kieber email: kieber(a)gatel.net > Network Engineer voice: +49-69-299896-21 > Global Access Telecommunications, Inc. fax : +49-69-299896-40 > internet solutions for business www : www.gatel.net >

2 1

RE: RETRY: as-set syntax errors ?
by Low, Adam 27 Apr '01

27 Apr '01

Hi Ulf, Sure but the template suggests multiple descr fields are allowed ? descr: [mandatory] [multiple] [ ] If this isnt the case, the template should ideally be changed to avoid confusion. Thanks, Adam > -----Original Message----- > From: kieber(a)gatel.net [mailto:kieber@gatel.net] > Sent: 24 April 2001 20:49 > To: ALow(a)Prioritytelecom.com > Cc: db-wg(a)ripe.net > Subject: Re: RETRY: as-set syntax errors ? > > > Low, Adam writes: > > I seem to be having problems sending in an update for the > > following object, I've double checked it and I must be > > missing something, any suggestions ? > > > > Update FAILED: Syntax error in object > > as-set: AS-PRIORITY > > descr: Priority Telecom AS Macro > ^^^^^ > > descr: AS13646 and Global Customers > ^^^^^ > > members: AS13646 > > > ***Error: single-valued attribute descr occurs multiple times. > > As it says, the descr: attribute is allowed only once in an as-set. > > > The only differences to the previous object are the changed > > fields and the addition of AS10160. > > As as-sets are automatically converted from as-macros and descr: was > allowed multiple times in as-macros you need to get rid of the > conflict now. > > -- > Ulf Kieber email: kieber(a)gatel.net > Network Engineer voice: +49-69-299896-21 > Global Access Telecommunications, Inc. fax : +49-69-299896-40 > internet solutions for business www : www.gatel.net >

2 1

The status of the migration iissues
by Andrei Robachevsky 26 Apr '01

26 Apr '01

Dear Colleagues, As some of you might have noticed, several problems showed up after the migration. Let me present an update on their status: 1. PGP signed messages sent to <auto-rpsl(a)ripe.net> didn't pass authorization checks This was fixed on 24th of April. Please note that PGP signed updates cannot be processed by <auto-dbm(a)ripe.net>. Until 14th of May, <auto-dbm(a)ripe.net> processes updates in RIPE-181 format and automatically translates them into RPSL, which voids PGP signatures. 2. Conversion problems of updates sent to <auto-dbm(a)ripe.net> Problematic objects were: - Objects with syntax errors - Indented objects (containing leading whitespace) In both cases objects were not converted to RPSL and user received an empty acknowledgement. This was fixed today, 26th of April. Please note that <auto-dbm(a)ripe.net> cannot reproduce all the behaviour of the v2 database. In particular, empty attribute is treated as a syntax error and Routing Policy System Security authorization rules apply. We strongly recommend you to switch to updates in RPSL format as soon as possible. Also note, that <auto-dbm(a)ripe.net> will process updates in RIPE-181 format until 14th of May. After that, updates in RIPE-181 format should be sent to the new address, <auto-181(a)ripe.net>, and <auto-dbm(a)ripe.net> will accept only RPSL syntax. 3. Due to above problems some of the updates were not processed. If you haven't received an acknowledgement from the database one day after you sent your update we would kindly ask to re-send it. We apologize for any inconvenience these problems caused. We are working on some minor problems and rely on your understanding. Please visit the "Migration Issues" link on the "Database Status" page (http://www.ripe.net/ripencc/pub-services/db/issues.html) for the up-to-date information. Regards, Andrei Robachevsky DB Group Manager RIPE NCC

3 2

whoisRIP -k
by Frank Bohnsack 26 Apr '01

26 Apr '01

hi, it seems that the new whois client doesn't support the -k option (open/close session (persistent connection)). after a query the connection is holding but the 'client' get no feedback after new queries. i tried this by 'telnet whois.ripe.net 43' and it's works fine. any comments ?! cheers frank

2 1

RETRY: as-set syntax errors ?
by Low, Adam 24 Apr '01

24 Apr '01

Hi, I seem to be having problems sending in an update for the following object, I've double checked it and I must be missing something, any suggestions ? Update FAILED: Syntax error in object as-set: AS-PRIORITY descr: Priority Telecom AS Macro descr: AS13646 and Global Customers members: AS13646 members: AS8758, AS9831, AS8928, AS12684 members: AS12708, AS15426, AS12825, AS4783, AS17108 members: AS9847, AS1742, AS13315, AS11, AS6395 members: AS10160 members: AS-GLOBIX members: AS-GRIDNINE members: AS-NILDRAMUS members: AS-MUNDI members: AS-ELIMNET members: AS-DREAMLINE members: AS-TRUESERVER members: AS-BDXNLBUYERS members: AS-BROADWING tech-c: PTNO1-RIPE admin-c: PTHM1-RIPE notify: hostmaster(a)prioritytelecom.com mnt-by: AS13646-RIPE-MNT changed: alow(a)prioritytelecom.com 20010330 changed: alow(a)prioritytelecom.com 20010402 changed: alow(a)prioritytelecom.com 20010410 changed: alow(a)prioritytelecom.com 20010421 changed: alow(a)prioritytelecom.com 20010424 source: RIPE ***Error: single-valued attribute descr occurs multiple times. The only differences to the previous object are the changed fields and the addition of AS10160. Thanks, Adam _____________________________________________________________ Adam J. Low Tel: +31 20 778 2740 Senior Network Architect Fax: +31 20 778 8601 Priority Telecom Corporate Email: alow(a)prioritytelecom.com

2 1

RE: RETRY: as-set syntax errors ?
by Low, Adam 24 Apr '01

24 Apr '01

The template allows multiple descr fields ? as-set: [mandatory] [single] [primary/look-up key] descr: [mandatory] [multiple] [ ] members: [optional] [multiple] [ ] mbrs-by-ref: [optional] [multiple] [inverse key] remarks: [optional] [multiple] [ ] tech-c: [mandatory] [multiple] [inverse key] admin-c: [mandatory] [multiple] [inverse key] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] > -----Original Message----- > From: Low, Adam [mailto:ALow@Prioritytelecom.com] > Sent: 24 April 2001 20:36 > To: 'db-wg(a)ripe.net' > Subject: RETRY: as-set syntax errors ? > > > Hi, > > I seem to be having problems sending in an update for the > following object, I've double checked it and I must be > missing something, any suggestions ? > > Update FAILED: Syntax error in object > as-set: AS-PRIORITY > descr: Priority Telecom AS Macro > descr: AS13646 and Global Customers > members: AS13646 > members: AS8758, AS9831, AS8928, AS12684 > members: AS12708, AS15426, AS12825, AS4783, AS17108 > members: AS9847, AS1742, AS13315, AS11, AS6395 > members: AS10160 > members: AS-GLOBIX > members: AS-GRIDNINE > members: AS-NILDRAMUS > members: AS-MUNDI > members: AS-ELIMNET > members: AS-DREAMLINE > members: AS-TRUESERVER > members: AS-BDXNLBUYERS > members: AS-BROADWING > tech-c: PTNO1-RIPE > admin-c: PTHM1-RIPE > notify: hostmaster(a)prioritytelecom.com > mnt-by: AS13646-RIPE-MNT > changed: alow(a)prioritytelecom.com 20010330 > changed: alow(a)prioritytelecom.com 20010402 > changed: alow(a)prioritytelecom.com 20010410 > changed: alow(a)prioritytelecom.com 20010421 > changed: alow(a)prioritytelecom.com 20010424 > source: RIPE > ***Error: single-valued attribute descr occurs multiple times. > > The only differences to the previous object are the changed > fields and the addition of AS10160. > > Thanks, > Adam > _____________________________________________________________ > > Adam J. Low Tel: +31 20 778 2740 > Senior Network Architect Fax: +31 20 778 8601 > Priority Telecom Corporate Email: alow(a)prioritytelecom.com >

1 0

as-set syntax errors ?
by Low, Adam 24 Apr '01

24 Apr '01

Hi, I seem to be having problems sending in an update for the following object, I've double checked it and I must be missing something, any suggestions ? as-set: AS-PRIORITY descr: Priority Telecom AS Macro descr: AS13646 and Global Customers members: AS13646 members: AS8758, AS9831, AS8928, AS12684 members: AS12708, AS15426, AS12825, AS4783, AS17108 members: AS9847, AS1742, AS13315, AS11, AS6395 members: AS10160 members: AS-GLOBIX members: AS-GRIDNINE members: AS-NILDRAMUS members: AS-MUNDI members: AS-ELIMNET members: AS-DREAMLINE members: AS-TRUESERVER members: AS-BDXNLBUYERS members: AS-BROADWING tech-c: PTNO1-RIPE admin-c: PTHM1-RIPE notify: hostmaster(a)prioritytelecom.com mnt-by: AS13646-RIPE-MNT changed: alow(a)prioritytelecom.com 20010330 changed: alow(a)prioritytelecom.com 20010402 changed: alow(a)prioritytelecom.com 20010410 changed: alow(a)prioritytelecom.com 20010421 changed: alow(a)prioritytelecom.com 20010424 source: RIPE The only differences to the previous object are the changed fiels and the addition of AS10160. Thanks, Adam _____________________________________________________________ Adam J. Low Tel: +31 20 778 2740 Senior Network Architect Fax: +31 20 778 8601 Priority Telecom Corporate Email: alow(a)prioritytelecom.com

1 0

PGP authentication in the RIPE Database.
by RIPE Database Administration 24 Apr '01

24 Apr '01

Dear Colleagues, PGP updates are now possible again in the RIPE Database. We traced the source of the problem to a subtle bug. Currently, PGP signed messages encoded in quoted-printable text are not supported, but if anyone feels strongly about this, then this mailing list is the appropriate place to discuss it. If you have questions about the operation of the RIPE Database or the software, please contact <ripe-dbm(a)ripe.net>. Regards, A. M. R. Magee ______________ RIPE NCC

2 1

draft agenda routing/joint routing&db wg RIPE 39
by SchmitzJo＠aol.com 24 Apr '01

24 Apr '01

Dear colleagues, please find enclosed the first draft of the agenda for the session of the routing working rgoup at RIPE 39, Bologna. The session will be held Wednesday, 2-May, 14:00 Routing WG session Due to the importance of the subject and because it is affecting both working groups we are having again a joint session of the routing and database groups on the same day in the 2nd afternoon slot. Wednesday, 2-May, 16:00 Joint routing/db WG session I would also like to direct your attention to two interesting tutorials: For more information on these two tutorials, please refer to the RIPE meeting web pages. Monday, 30-Apr, 9:00 Full day tutorial on MPLS by Clarence Filsfils (Cisco) Tuesday, 1-May, 9:00 Half day tutorial on the RAToolSet by Cengiz Allaettinoglu (Packetdesign) As usual comments, additions, changes to the agenda of the Routing WG welcome! ---- R I P E 3 9 B O L O G N A Routing Working Group Session A. Preliminaries (Joachim Schmitz) (5min) - introduction - participants' list - volunteering of scribe - agenda bashing - RIPE 37 minutes - actions from earlier meetings B. Cengiz Allaettinoglu: Observations on ISIS Convergence (30min) C. Philip Smith: Update on RIPE-210 (Route Flap Damping) (20min) - update - discussion D. Henk Uijterwaal: Update from the RIS Project (15min) Joint Session with the Database WG E. Andrei Robachevsky: Migration to the new RIPE database (20min) F. Cengiz Allaettinoglu: Application of the RAToolSet (open end) Y. Input from other WGs Z. AOB ---- Thanks Joachim --- JS395-RIPE -- standard disclaimer ---

1 0

draft agenda (v1), for DB-WG meeting, RIPE 39, Bologna
by Wilfried Woeber, UniVie/ACOnet 23 Apr '01

23 Apr '01

Dear DB-WG list members, fellow chair persons, dear "meeting" account! Attached please find the 1st draft, proposed agenda for the DB-WG Meeting in Bologna, IT. As usual, comments, suggestions and additions are welcome. As a test (please let me know what you think!), any updates to the draft agenda and some supporting information can be found at http://members.aon.at/netcraft/DB-WG/d-agenda.html Looking forward to see many of you in Bologna, Wilfried. ______________________________________________________________________ Proposed Agenda for the Database Working Group Meeting RIPE-39, April 30-May 4 2001, Bologna, IT 1. Draft Wednesday, May 2nd, 2001 16:00 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Part 1: Joint Session with Routing-WG Thursday, May 3rd, 2001 09:00 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Part 2: DB-WG Meeting A. Administrative stuff (WW, chair) . volunteering a scribe . list of participants . agenda bashing . minutes distributed B. Actions Items . C. DB operations update (RIPE NCC, Andrei Robachevsky) 20min D. Report from Re-Implementation/Migration TF (tentative, Ulf Kieber, DB Group) 15 min E. "orphaned" person objects, potential legal implications (RIPE NCC, Joao LS Damas) 15 min F. Enhancements to IRRd to support an SQL backend, et.al. (Global Crossing and TimesTen, Jake Khuon) 30 min G. 'force:' attribute for changing a 'person:' object (tcpip-gmbh, Carsten Schiefner) 15 min H. Legacy object migration from ARIN to RIPE NCC (& APNIC) (tentative, N.N.) 20 min PI.Y. Input from other WGs . PI.Z. AOB: . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WW, 23-Apr-2001 19:20 UTC _________________________________:_____________________________________ 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

PGP auth?
by Gert Doering 23 Apr '01

23 Apr '01

Hi, with the old RIPE DB, PGP auth did only work with "inline" signatures (the "classic" PGP way), not with "MIME/multipart" signatures (the way "mutt" does them, and maybe other programs, and as this e-mail is signed). I remember that the new DB software was supposed to do MIME, and also MIME/multipart PGP, but it didn't work when I tried that ("request denied, forwarded to maintainer"). Could you please elaborate what the current state regarding MIME and/or PGP support is? thanks, Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster(a)Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299

2 1

Re: New DB and line continuation?
by Andrei Robachevsky 23 Apr '01

23 Apr '01

Dear Berislav, Berislav Todorovic wrote: > > On Mon, 23 Apr 2001, DB-News wrote: > > >> The new version of the RIPE Database is now up and running! > >> All objects have been automatically converted to RPSL and loaded into > >> the new version of the Database. > > Congratulations! However, I have a question: > > When an attribute needs multiple lines to be described, the standard > RPSL format requires the attribute name to be mentioned once, while > successive lines are separted by spaces or commas (like you defined > in the transition document as well). It used to be like that in the > previous version of rpsl.ripe.net. However, right now, it seems to > me there is a strange RIPE-181/RPSL mix in place. See example: > Indeed, we tried to introduce as little changes to objects look as possible, while staying RPSL compliant. In fact, RPSL defines members attribute as: Attribute Value Type as-set <object-name> mandatory, single-valued, class key members list of <as-numbers> or optional, multi-valued <as-set-names> which means that one can have multiple 'members:' attribute, each of them may have a list of members separated by commas. So, formally there is no RPSL syntax violation. You can update your object to make it look like in RADB, both examples are accepted and valid in the RIPE database. Regards, Andrei > * RADB and old REIMP.RIPE (standard RPSL): > > [beri@nix00 ~]$ rwhois -h whois.ra.net as-kq > as-set: AS-KQ > descr: KPNQwest European routes > Formerly AS-EUNET AND NOT AS-EUNETQWEST > members: AS286, AS719, AS1136, AS1137, AS1213, > AS1234, AS1889, AS1891, AS1902, AS2043, > AS2049, AS2110, AS2135, AS2857, AS3220, > ... > > * RIPE (new format, RPSL): > > as-set: AS-KQ > descr: KPNQwest European routes > descr: Formerly AS-EUNET AND NOT AS-EUNETQWEST > members: AS286, AS719, AS1136, AS1137, AS1213, AS1234, AS1889 > members: AS1891, AS1902, AS2043, AS2049, AS2110, AS2135, AS2857 > members: AS3220, AS3246, AS3262, AS3265, AS3286, AS3324, AS3333 > members: AS3347, AS3615, AS5385, AS5399, AS5403, AS5407, AS5419 > > While some of you might think this is not important, this is VERY > important to some of us who make scripts for automating our tasks with > the RIPE DB. > > Can anyone explain the reason of this RPSL syntax violation? Thanks! > > 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 -- > --- _ _ ____ _ .--. ____ ____ __/_ --- > ----- /__/ /___/ /\ / / / | / /___/ /___ / ------ > ------ _/ \_ / _/ \/ (__.\ |/\/ /___ ____/ (__. ----- -- Andrei Robachevsky DB Group Manager RIPE NCC

1 0

update problems with auto-dbm@ripe.net
by Frank Bohnsack 23 Apr '01

23 Apr '01

Dear colleagues, Our last aut-num update doen't accepted from auto-dbm(a)ripe.net ;-( It seems that there is a problems with password authentification and/or legacy RIPE-181 attributes. Please let me know whats wrong ... cheers Frank > -----Original Message----- > From: RIPE Database Management [mailto:ripe-dbm@ripe.net] > Sent: Monday, April 23, 2001 11:04 AM > To: mz(a)de.uu.net > Subject: Re: LONGACK AS1270 > > > > Acknowledgement message from database software > > > Your e-mail: > >> From: "Martin Ziegler" <mz(a)de.uu.net> >> Cc: >> Subject: LONGACK AS1270 >> Date: Mon, 23 Apr 2001 11:04:47 +0200 >> Msg-Id: <GMEGIAOLKNDLPJFCBJGLKEDDCCAA.mz(a)de.uu.net> > > has been processed by the automatic update procedure at the RIPE NCC. > Diagnostic output follows: > > ------------------------------------------------------------------------ > > > Update FAILED: Syntax error in object > password: ******** > ***Error: syntax error > ***Error: Unknown class encountered. > > Update FAILED: Syntax error in object > ***Error: syntax error > aut-num: AS1270 > as-name: UUNET-DE > descr: UUNET Germany > as-in: from AS517 100 accept AS-KQ > as-in: from AS553 100 accept AS-BELWUE > as-in: from AS680 100 accept AS-DFNTOWINISP > as-in: from AS1273 100 accept AS-ECRC > as-in: from AS1275 100 accept AS1275 > as-in: from AS1889 100 accept AS1889 > as-in: from AS2125 100 accept AS2125 > as-in: from AS2686 100 accept AS-IGNEMEA > as-in: from AS2871 100 accept AS-ISION > as-in: from AS3257 100 accept AS-NACAMAR AS5459 AS-NDH > as-in: from AS3320 100 accept AS-DTAG > as-in: from AS3569 100 accept AS3569 > as-in: from AS3573 100 accept AS3573 > as-in: from AS5378 100 accept AS-INSNET > as-in: from AS5401 100 accept AS-POP > as-in: from AS5427 100 accept AS-CONTRIBNET > as-in: from AS5430 100 accept AS-MOBILCOM > as-in: from AS5496 100 accept AS-WIREHUB > as-in: from AS5521 100 accept AS-CITYLINE > as-in: from AS5539 100 accept AS-SPACENET > as-in: from AS5549 100 accept AS-TELENOR > as-in: from AS5605 100 accept AS5605 > as-in: from AS5621 100 accept AS-CPSEUROPE > as-in: from AS5627 100 accept AS5627 > as-in: from AS6705 100 accept AS-PROFI > as-in: from AS6735 100 accept AS-SDTDECIX AS-SDTMAEF > as-in: from AS6754 100 accept AS-VIA > as-in: from AS8072 100 accept AS8072 > as-in: from AS8196 100 accept AS-NETSCALIBURDE > as-in: from AS8208 100 accept AS-CAMELOT > as-in: from AS8220 100 accept AS-COLT > as-in: from AS8298 100 accept AS-IDNET > as-in: from AS8319 100 accept AS-IXREGIO > as-in: from AS8351 100 accept AS8351 > as-in: from AS8354 100 accept AS8354 > as-in: from AS8360 100 accept AS8360 > as-in: from AS8373 100 accept AS8373 > as-in: from AS8379 100 accept AS-CYBERNETEU > as-in: from AS8397 100 accept AS-ZETNET > as-in: from AS8422 100 accept AS-NETCOLOGNE > as-in: from AS8442 100 accept AS8442 > as-in: from AS8469 100 accept AS-PIRONETNDH > as-in: from AS8477 100 accept AS-TESIONGLOBAL AS-SWCMGLOBAL > as-in: from AS8602 100 accept AS8602 > as-in: from AS8650 100 accept AS-TLI > as-in: from AS8735 100 accept AS8735 > as-in: from AS8767 100 accept AS-MNETDE > as-in: from AS8794 100 accept AS8794 > as-in: from AS8827 100 accept AS8827 > as-in: from AS8852 100 accept AS-GINKO > as-in: from AS8864 100 accept AS8864 > as-in: from AS8879 100 accept AS8879 > as-in: from AS8925 100 accept AS-TEUTOCLIENTS > as-in: from AS8939 100 accept AS-ADTECH > as-in: from AS8950 100 accept AS8950 > as-in: from AS8957 100 accept AS8957 > as-in: from AS9007 100 accept AS9007 > as-in: from AS9059 100 accept AS9059 > as-in: from AS9066 100 accept AS-BCC > as-in: from AS9067 100 accept AS9067 > as-in: from AS9072 100 accept AS-NEFKOM > as-in: from AS9099 100 accept AS9099 > as-in: from AS9164 100 accept AS9164 > as-in: from AS9175 100 accept AS9175 > as-in: from AS9188 100 accept AS9188 AS9067 > as-in: from AS11660 100 accept AS11660 > as-in: from AS12288 100 accept AS12288 > as-in: from AS12291 100 accept AS12291 > as-in: from AS12292 100 accept AS-TRANSKOM > as-in: from AS12313 100 accept AS-VERSATELDE AS-VERSATELCUSTDE > as-in: from AS12331 100 accept AS12331 > as-in: from AS12343 100 accept AS12343 > as-in: from AS12355 100 accept AS12355 > as-in: from AS12371 100 accept AS12371 > as-in: from AS12379 100 accept AS12379 > as-in: from AS12437 100 accept AS12437 > as-in: from AS12466 100 accept AS12466 > as-in: from AS12470 100 accept AS12470 AS-TLKNET AS15909 > as-in: from AS12531 100 accept AS12531 > as-in: from AS12532 100 accept AS-DIZ > as-in: from AS12555 100 accept AS12555 > as-in: from AS12574 100 accept AS12574 > as-in: from AS12581 100 accept AS-TOPSNET > as-in: from AS12595 100 accept AS12595 > as-in: from AS12598 100 accept AS12598 > as-in: from AS12610 100 accept AS12610 > as-in: from AS12612 100 accept AS12612 > as-in: from AS12625 100 accept AS12625 > as-in: from AS12638 100 accept AS12638 > as-in: from AS12643 100 accept AS12643 > as-in: from AS12647 100 accept AS12647 > as-in: from AS12664 100 accept AS12664 > as-in: from AS12678 100 accept AS12678 > as-in: from AS12722 100 accept AS12722 > as-in: from AS12796 100 accept AS12796 > as-in: from AS12813 100 accept AS-WORNET > as-in: from AS12853 100 accept AS12853 > as-in: from AS12857 100 accept AS12857 > as-in: from AS12886 100 accept AS-LEWTELNET > as-in: from AS12888 100 accept AS12888 > as-in: from AS12892 100 accept AS12892 > as-in: from AS12899 100 accept AS12899 > as-in: from AS12915 100 accept AS12915 > as-in: from AS12916 100 accept AS12916 > as-in: from AS12919 100 accept AS12919 > as-in: from AS12930 100 accept AS12930 > as-in: from AS13003 100 accept AS13003 > as-in: from AS13006 100 accept AS13006 > as-in: from AS13012 100 accept AS13012 AS15456 > as-in: from AS13039 100 accept RS-NEW > as-in: from AS13040 100 accept AS13040 > as-in: from AS13043 100 accept AS13043 > as-in: from AS13045 100 accept AS13045 AS15790 > as-in: from AS13083 100 accept AS13083 > as-in: from AS13090 100 accept AS13090 AS15492 > as-in: from AS13101 100 accept AS-TNG > as-in: from AS13129 100 accept AS-GAT > as-in: from AS13152 100 accept AS13152 > as-in: from AS13157 100 accept AS13157 > as-in: from AS13237 100 accept AS13237 > as-in: from AS13247 100 accept AS13247 > as-in: from AS13270 100 accept AS13270 > as-in: from AS15374 100 accept AS15374 > as-in: from AS15392 100 accept AS15392 > as-in: from AS15438 100 accept AS15438 > as-in: from AS15465 100 accept AS15465 > as-in: from AS15486 100 accept AS15486 > as-in: from AS15563 100 accept AS15563 > as-in: from AS15579 100 accept AS15579 > as-in: from AS15622 100 accept AS15622 > as-in: from AS15698 100 accept AS15698 > as-in: from AS15709 100 accept AS15709 > as-in: from AS15763 100 accept AS15763 > as-in: from AS15781 100 accept AS15781 > as-in: from AS15813 100 accept AS15813 > as-in: from AS15889 100 accept AS15889 > as-in: from AS15894 100 accept AS15894 > as-in: from AS15904 100 accept AS15904 AND AS9115 > as-in: from AS15933 100 accept AS15933 > as-in: from AS15968 100 accept AS15968 > as-in: from AS15987 100 accept AS15987 > as-in: from AS16038 100 accept AS-COMCITY > as-in: from AS16103 100 accept AS-NETZTECHOUT > as-in: from AS16126 100 accept AS16126 > as-in: from AS16148 100 accept AS16148 > as-in: from AS16152 100 accept AS16152 > as-in: from AS16233 100 accept AS16233 > as-in: from AS16356 100 accept AS16356 > as-out: to AS517 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS553 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS680 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS1273 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS1275 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS1889 announce ANY > as-out: to AS2125 announce ANY > as-out: to AS2686 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS2871 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS3257 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS3320 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS3569 announce ANY > as-out: to AS3573 announce ANY > as-out: to AS5378 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS5401 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS5427 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS5430 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS5496 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS5521 announce ANY > as-out: to AS5539 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS5549 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS5605 announce ANY > as-out: to AS5621 announce ANY > as-out: to AS5627 announce ANY > as-out: to AS6705 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS6735 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS6754 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS8072 announce ANY > as-out: to AS8196 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS8208 announce ANY > as-out: to AS8220 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS8298 announce ANY > as-out: to AS8319 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS8351 announce ANY > as-out: to AS8354 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS8360 announce ANY > as-out: to AS8373 announce ANY > as-out: to AS8379 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS8397 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS8422 announce ANY > as-out: to AS8442 announce ANY > as-out: to AS8469 announce ANY > as-out: to AS8477 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS8602 announce ANY > as-out: to AS8650 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS8735 announce ANY > as-out: to AS8767 announce ANY > as-out: to AS8794 announce ANY > as-out: to AS8827 announce ANY > as-out: to AS8852 announce ANY > as-out: to AS8864 announce ANY > as-out: to AS8879 announce ANY > as-out: to AS8925 announce ANY > as-out: to AS8939 announce ANY > as-out: to AS8950 announce ANY > as-out: to AS8957 announce ANY > as-out: to AS9007 announce ANY > as-out: to AS9059 announce ANY > as-out: to AS9066 announce ANY > as-out: to AS9067 announce ANY > as-out: to AS9072 announce ANY > as-out: to AS9099 announce ANY > as-out: to AS9164 announce ANY > as-out: to AS9175 announce ANY > as-out: to AS9188 announce ANY > as-out: to AS11660 announce ANY > as-out: to AS12288 announce ANY > as-out: to AS12291 announce ANY > as-out: to AS12292 announce ANY > as-out: to AS12313 announce ANY > as-out: to AS12331 announce ANY > as-out: to AS12343 announce ANY > as-out: to AS12355 announce ANY > as-out: to AS12371 announce ANY > as-out: to AS12379 announce ANY > as-out: to AS12437 announce ANY > as-out: to AS12466 announce ANY > as-out: to AS12470 announce ANY > as-out: to AS12531 announce ANY > as-out: to AS12532 announce ANY > as-out: to AS12555 announce ANY > as-out: to AS12574 announce ANY > as-out: to AS12581 announce ANY > as-out: to AS12595 announce ANY > as-out: to AS12598 announce ANY > as-out: to AS12610 announce ANY > as-out: to AS12612 announce ANY > as-out: to AS12625 announce ANY > as-out: to AS12638 announce ANY > as-out: to AS12643 announce ANY > as-out: to AS12647 announce ANY > as-out: to AS12664 announce ANY > as-out: to AS12678 announce ANY > as-out: to AS12722 announce ANY > as-out: to AS12796 announce ANY > as-out: to AS12813 announce ANY > as-out: to AS12853 announce ANY > as-out: to AS12857 announce ANY > as-out: to AS12886 announce ANY > as-out: to AS12888 announce ANY > as-out: to AS12892 announce ANY > as-out: to AS12899 announce ANY > as-out: to AS12915 announce ANY > as-out: to AS12916 announce ANY > as-out: to AS12919 announce ANY > as-out: to AS12930 announce ANY > as-out: to AS13003 announce ANY > as-out: to AS13006 announce ANY > as-out: to AS13012 announce ANY > as-out: to AS13039 announce ANY > as-out: to AS13040 announce ANY > as-out: to AS13043 announce ANY > as-out: to AS13045 announce ANY > as-out: to AS13083 announce ANY > as-out: to AS13090 announce ANY > as-out: to AS13101 announce ANY > as-out: to AS13129 announce AS-UUNETDE AS-UUNETEUDE (AS702 AND UUNETEUDE) > as-out: to AS13152 announce ANY > as-out: to AS13157 announce ANY > as-out: to AS13237 announce ANY > as-out: to AS13247 announce ANY > as-out: to AS13270 announce ANY > as-out: to AS15374 announce ANY > as-out: to AS15392 announce ANY > as-out: to AS15438 announce ANY > as-out: to AS15465 announce ANY > as-out: to AS15486 announce ANY > as-out: to AS15563 announce ANY > as-out: to AS15579 announce ANY > as-out: to AS15622 announce ANY > as-out: to AS15698 announce ANY > as-out: to AS15709 announce ANY > as-out: to AS15763 announce ANY > as-out: to AS15781 announce ANY > as-out: to AS15813 announce ANY > as-out: to AS15889 announce ANY > as-out: to AS15894 announce ANY > as-out: to AS15904 announce ANY > as-out: to AS15933 announce ANY > as-out: to AS15968 announce ANY > as-out: to AS15987 announce ANY > as-out: to AS16038 announce ANY > as-out: to AS16103 announce ANY > as-out: to AS16126 announce ANY > as-out: to AS16148 announce ANY > as-out: to AS16152 announce ANY > as-out: to AS16233 announce ANY > as-out: to AS16356 announce ANY > remarks: Community definitions > remarks: > remarks: Communities for incoming customer routes > remarks: > remarks: Community Definition > remarks: ============================================== > remarks: 1270:80 Set LocalPref within AS1270 to 80 > remarks: 1270:120 Set LocalPref within AS1270 to 120 > remarks: > admin-c: OD3-RIPE > tech-c: AT51 > notify: neteng(a)de.uu.net > remarks: Peering requests should be send to peering(a)de.uu.net > mnt-by: AS1270-MNT > changed: mz(a)de.uu.net 20010423 > source: RIPE > ***Error: syntax error > ***Error: Unknown class encountered. > > RIPE Database Maintenance Department (Automatic Section) > -- Frank Bohnsack email fb(a)de.uu.net UUNET, A Worldcom Company phone +49 (0)231 972-1495 EMEA Access & Backbone Networks fax +49 (0)231 972-1188 Team Dortmund web www.de.uu.net

2 1

auto-rpsl@ripe.net MIME parser problem and auth failure
by Daniel Roesen 23 Apr '01

23 Apr '01

Hi, the auto-rpsl(a)ripe.net robot MIME parser doesn't understand quoted-printable encoding. I think it should. Second, all our updates are failing with "authorisation failed". Our objects are protected by a maintainer object with PGP-Auth. I guess there is a problem with signature verification Best regards, Daniel Roesen -- Entire Systems GmbH - Ferbachstrasse 12 - 56203 Hoehr-Grenzhausen, Germany InterNIC-Handle: ES1238-ORG RIPE-Handle: ESN10-RIPE Tel: +49 2624 9550-55 GnuPG/PGP Key-ID: 0xBF3C40C9 http://www.entire-systems.com/noc/noc-key.asc GnuPG/PGP Fingerprint: 1F3F B675 1A38 D87C EB3C 6090 C6B9 DF48 BF3C 40C9

1 0

Re: New DB and line continuation?
by RIPE Database Administration 23 Apr '01

23 Apr '01

Hi, Berislav Todorovic, Thank you for reporting this. We are investigating. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, A. M. R. Magee ______________ RIPE NCC Berislav Todorovic <beri(a)kpnqwest.net> writes: * On Mon, 23 Apr 2001, DB-News wrote: * * >> The new version of the RIPE Database is now up and running! * >> All objects have been automatically converted to RPSL and loaded into * >> the new version of the Database. * * Congratulations! However, I have a question: * * When an attribute needs multiple lines to be described, the standard * RPSL format requires the attribute name to be mentioned once, while * successive lines are separted by spaces or commas (like you defined * in the transition document as well). It used to be like that in the * previous version of rpsl.ripe.net. However, right now, it seems to * me there is a strange RIPE-181/RPSL mix in place. See example: * * * RADB and old REIMP.RIPE (standard RPSL): * * [beri@nix00 ~]$ rwhois -h whois.ra.net as-kq * as-set: AS-KQ * descr: KPNQwest European routes * Formerly AS-EUNET AND NOT AS-EUNETQWEST * members: AS286, AS719, AS1136, AS1137, AS1213, * AS1234, AS1889, AS1891, AS1902, AS2043, * AS2049, AS2110, AS2135, AS2857, AS3220, * ... * * * RIPE (new format, RPSL): * * as-set: AS-KQ * descr: KPNQwest European routes * descr: Formerly AS-EUNET AND NOT AS-EUNETQWEST * members: AS286, AS719, AS1136, AS1137, AS1213, AS1234, AS1889 * members: AS1891, AS1902, AS2043, AS2049, AS2110, AS2135, AS2857 * members: AS3220, AS3246, AS3262, AS3265, AS3286, AS3324, AS3333 * members: AS3347, AS3615, AS5385, AS5399, AS5403, AS5407, AS5419 * * While some of you might think this is not important, this is VERY * important to some of us who make scripts for automating our tasks with * the RIPE DB. * * Can anyone explain the reason of this RPSL syntax violation? Thanks! * * 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 -- * --- _ _ ____ _ .--. ____ ____ __/_ --- * ----- /__/ /___/ /\ / / / | / /___/ /___ / ------ * ------ _/ \_ / _/ \/ (__.\ |/\/ /___ ____/ (__. ----- * *

1 0

New RPSL Query of aut-num objects
by Sascha E. Pollok 23 Apr '01

23 Apr '01

Dear Folks, apologies if this has been discussed before or is considered not being relevant to most of you but if I do a query like below, the main difference (beside the new RPSL-look-and-feel of course) is that the as-block: object is shown AND that there is one space missing as a separator between field-descriptors and the content of the field compared to all other objects. Again, this might be irrelevant to most of you that do /(\S+)\s+(.*)/ or whatever but I just wanted to ask. Regards, Sascha ----------- % whois AS12731 as-block: AS12288 - AS13311 descr: RIPE NCC ASN block remarks: These AS numbers are further assigned by RIPE NCC remarks: to LIRs and end-users in the RIPE NCC region remarks: Please refer to RIPE Document ripe-185 remarks: and RIPE Document ripe-147 admin-c: NN32-RIPE tech-c: OPS4-RIPE mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT changed: hostmaster(a)ripe.net 20010423 source: RIPE aut-num: AS12731 as-name: IPHH descr: IPHH Internet Port Hamburg GmbH descr: Global AS Routing-Policy import: from AS3300 action pref=100; accept ANY AND NOT {0.0.0.0/0}

1 0

Fwd: BLOCK: RIPE
by Christian Panigl, ACOnet/VIX/UniVie 23 Apr '01

23 Apr '01

Hmmm, reasonable diligence or epidemic paranoia ? Just got this one forwarded, thought it might be worth letting you know ... Cheers CP ================================ X-Mailer: Forte Agent 1.8/32.548 Message-ID: <6uu6ets5102thcbdrigof2l7urtmd2gmjl(a)4ax.com> Date: Sun, 22 Apr 2001 20:48:13 -0400 From: Daniel Norton <danorton(a)SUESPAMMERS.ORG> To: SPAM-L(a)PEACH.EASE.LSOFT.COM Reply-To: Daniel Norton <danorton(a)SUESPAMMERS.ORG> Sender: Spam Prevention Discussion List <SPAM-L(a)PEACH.EASE.LSOFT.COM> Organization: . Subject: BLOCK: RIPE RIPE's database is down for an indeterminate period of time. Since it might be impossible to determine an abuse contact address without the RIPE database, you might wish to consider blocking all RIPE traffic until they get things back in order. Here are the RIPE IP address ranges: 24.132/14 62/8 139.20/14 139.24/14 139.28/15 141.0/10 141.64/12 141.80/14 141.84/15 145.224/12 145.240/13 145.248/14 145.252/15 145.254/16 149.202/15 149.204/16 149.206/15 149.208/12 149.224/12 149.240/13 149.248/14 150.254/16 151.13/16 151.14/15 151.16/12 151.32/11 151.64/12 151.80/15 151.3/16 151.4/15 151.82/16 151.91/16 151.92/15 151.95/16 160.216/14 160.220/16 160.44/14 160.48/12 163.156/14 163.160/12 164.0/11 164.32/13 164.40/16 164.128/12 171.16/12 171.32/15 192.106.196/23 192.162/16 192.164/14 192.71/16 193/8 194/8 195/8 198.17.117/24 212/8 213/8 217/8 -- Daniel Norton ----- End of forwarded message from Daniel Norton -----

3 2

Migration of the TEST database is completed
by Andrei Robachevsky 23 Apr '01

23 Apr '01

Dear Colleagues, The TEST database has been successfully migrated to v3 software. All objects in the TEST database were converted to RPSL compliant format. You can continue using the TEST database till 14 May as follows: - <test-dbm(a)ripe.net> mail robot accepts updates in RIPE-181 format with some limitations. - <test-rpsl(a)ripe.net> mail robot accepts updates in RPSL format. After that day changes in robots' functionality will follow the plan fro the production database. Please see http://www/ripencc/pub-services/db/rpsl/announcement.html and http://www/ripencc/pub-services/db/rpsl/index.html for more information. Finding objects in the TEST Database: Do whois -h test-whois.ripe.net <Search String> e.g. whois -h test-whois.ripe.net PB3-TEST The whois options that work in the RIPE Database also work in the TEST Database. We invite you to try them. Regards, Andrei Robachevsky DB Group Manager RIPE NCC

3 3

First phase of the migration to the new RIPE Database is completed
by DB-News 23 Apr '01

23 Apr '01

Dear Colleagues, The new version of the RIPE Database is now up and running! All objects have been automatically converted to RPSL and loaded into the new version of the Database. The first phase of the migration has been successfully completed. The following mail robots accept updates to the RIPE Database: <auto-dbm(a)ripe.net> - updates are accepted in RIPE-181 format and automatically translated into RPSL. However, several restrictions apply to such updates: empty and misspelled attributes are not allowed, PGP auth is not supported. Also, RPSL authorization rules apply. <auto-rpsl(a)ripe.net> - updates are accepted in RPSL format. This setup will be in place till 14 May, 2001. For more information about the migration please visit http://www.ripe.net/ripencc/pub-services/db/rpsl/announcement.html and http://www.ripe.net/ripencc/pub-services/db/rpsl/index.html Best Regards, Andrei Robachevsky DB Group RIPE NCC

1 0