January 1996 - db-wg - mailman.ripe.net

RE: Proposal for extended syntax for the 'country:' attribute
by Wilfried Woeber, UniVie/ACOnet 19 Jan '96

19 Jan '96

> maybe there is another solution: migrate the "country" attribute to a > "registry" attribute which should hold the responsible registry name <ripe-104++ speak> I think *allocations* should be tagged with the unique NCC RegID, *assignments* should be tagged by [multiple] country codes. </ripe-104++ speak> I'm reluctant to let go of the well-established use of the country: attribute. I'm looking forward to the time when we might have more flexible selection criteria for the DB, and I think loosing country information isn't a good idea. Wilfried. PS: I'm thinking up some pro.s and con.s later :-) -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------

1 0

RE: Proposal for extended syntax for the 'country:' attribute
by Christian Panigl, ACOnet/UniVie +43 1 4065822-383 19 Jan '96

19 Jan '96

Hi David, maybe there is another solution: migrate the "country" attribute to a "registry" attribute which should hold the responsible registry name Example: inetnum: 193.0.0.0 - 193.255.255.255 country: RIPE will be modified when entering the DB to inetnum: 193.0.0.0 - 193.255.255.255 registry: RIPE inetnum: 193.170.16.0 registry: at.aconet Pros: Solves the problem completely, is politically correct, easy (?) to implement Cons: will break applications which query for the "country" attribute, are there any ? Alternatively you might add the "registry" attribute and obsolte the country attribute. Regards Christian --- Christian Panigl : Vienna University Computer Center - ACOnet --- --- VUCC - ACOnet : -------------------------------------------- --- --- Universitaetsstrasse 7 : Internet: Christian.Panigl(a)CC.UniVie.ac.at --- --- A-1010 Vienna / Austria : Tel: +43 1 4065822-383 (Fax: -170) ---

2 1

Referencing macros within RIPE-DB which are defined in RADB ?
by Christian Panigl, ACOnet/UniVie +43 1 4065822-383 19 Jan '96

19 Jan '96

>Date: Fri, 19 Jan 96 11:55:38 +0100 >From: Bjorn Carlsson <bc(a)sunet.se> > >Hi, > >I have a question. I know that both Vienna and CERN build the as-path lists >automatically. > >GSL (Global Sprintlink) is connecting in Paris shortly, and they announce a >lot of ASes. These ASes are defined in an as-macro which resides in the RADB >and not the RIPE-DB. Will your filter-build programs be able to pick this >macro up from the RADB? Or do they only scan the RIPE-DB? Hi Bjorn, hmm, good question. We are mirroring those split-parts (rt, as) of the RIPE-DB which are needed by "rlc" to our local machine. If it turns out that we also need split-parts of the RADB and they are available by FTP like with RIPE, I don't see any reason why it shouldn't work, as long as the RADB splits have the same format. However, because rlc isn't able to compress as-path lists, I'm still using your nicely compressed "New AS-EBONE + as-path list". >Or rather, do I need to add each new GSL as explicitly to AS-EBONE, or can >I add just AS-GSL? It's an interesting question which should be discussed by the RIPE-DB working group ! Wilfried please take this, unfortunately I won't attend RIPE-23 !!! I have the following general questions in mind: - Is it allowed within the RIPE-DB to reference objects (macros) which are defined in a different RR (e.g. RADB) without duplicating them to the RIPE-DB ? - Is there a mechanism which ensures that object-names (macro-names) are unique ? - What are the implications for the various tools ? Kind regards Christian --- Christian Panigl : Vienna University Computer Center - ACOnet --- --- VUCC - ACOnet : -------------------------------------------- --- --- Universitaetsstrasse 7 : Internet: Christian.Panigl(a)CC.UniVie.ac.at --- --- A-1010 Vienna / Austria : Tel: +43 1 4065822-383 (Fax: -170) ---

2 1

RE: Proposal for extended syntax for the 'country:' attribute
by Wilfried Woeber, UniVie/ACOnet 19 Jan '96

19 Jan '96

>Please advise us. We have the idea that this topic is really something >for an interesting academic debate ;-), I wonder - do you (actually the software :-) currently check against some sort of list? iso3166? Wilfried.

2 1

Proposal for extended syntax for the 'country:' attribute
by David.Kessens＠ripe.net 19 Jan '96

19 Jan '96

Dear all, Recently, we ran into some inconsistencies that resulted from the 'country:' attribute as used in 'inetnum:' objects. Hereby, I want to describe the (small) problems we found and propose possible solutions. Problem description: The RIPE NCC currently gets address space allocated from IANA for assignment to local registries in our working area. This allocated address space needs to registered in the RIPE database. Currently, we fill the country attribute with the value 'EU', but we feel that it is not the right representation since the address space is meant to be used for the whole working area of RIPE. Example: inetnum: 193.0.0.0 - 193.255.255.255 country: EU [ ... stuff deleted... ] The same problem exists for multinational registries that get address space allocated that is used in more then one country. Solutions: Since we are dealing with a small, though highly visible problem we need easy and quick fixes to avoid putting too much work in something that's not really worth it ;-). We present them here in order of our preference: 1) we allow multiple country codes in the 'country:' attribute and allow for multiple line 'country:' code attributes for long lists of country codes. Pros: Solves the problem completely, is politically correct, easy to implement Cons: Might be a little bit overkill, especially if you look at the number of countries in the RIPE area. 2) Make country attribute optional since it doesn't really matter were the address space is used Pros: Solves the problem completely, is politically correct, very easy to implement Cons: We loose some information that might be useful (for what?) 3) We invent new country codes for non-existing entities like EU. Pros: Solves the problem. Cons: not politically correct, we might need to define more names. We get discussions like EU is something else then the RIPE working area that is much bigger. We might need more different codes. We might get funny things when ISO is defining new country codes (that might be the same as our pseudo codes), which happens all to often in Europe and around... 4) A combination of the proposed solutions, e.g. make the attribute optional *and* allow multiple country codes. 5) We leave it as it is Pros: The easiest thing Cons: We keep the inconsistencies Please advise us. We have the idea that this topic is really something for an interesting academic debate ;-), though we feel that we need to do something to solve this problem! David Kessens RIPE NCC

1 0

Proposal for the stored/processed attribute (action 19.12)
by David.Kessens＠ripe.net 19 Jan '96

19 Jan '96

Dear all, When I published the release notes of the RIPE database v1.1 beta version I also made some small notes regarding the format of the serial numbers that are needed for the (nearly) real-time mirroring of the RIPE database. Though, I know that you all like debating I didn't get any reactions :-(. Therefore I would like to stir up the discussion somewhat by highlighting the point (again) and formulate a (not the) proposal. If I understand our action list correct, the proposal will also make the historic action point on Marten Terpstra (19.12) about the 'stored:/processed:' attribute obsolete. What is (nearly) real-time mirroring support: The RIPE database software now labels all incoming (atomic) updates with an ever increasing serial number and stores the updates. It is now possible to retrieve all the changes to the database every ten minutes by use of a program that has been added to the RIPE database distribution. Before using the program it is required that you ask the people that maintain the database server near you (at RIPE: <ripe-dbm(a)ripe.net>), to be put in an accessslist. We haven't had any major problems with the beta version software (so far) except for some small bugs and support files that needed some more explanation. We are now using the software for a mirror server at RIPE and plan to change the roles of mirror and backup somewhere at the end of January. Also, some registries (GARR-NIS, SWITCH, ANS) have already such a mirror server running. Problem description: The current real-time mirroring system stores all updates together with an ever increasing serial number in separate files. Although it works, it doesn't allow for growth (computers tend not to be able to handle ever increasing integer values). Also other features like building a history of an object are not possible and system failures are difficult to handle. From the start of the real-time mirror project we intended to first get the thing working and to make a design that would make adding these features possible. Since it appears to work now, I want to publish a proposal. There are two important things that needs to be addressed: - We need a reliable and unique serial number. - We want to be able to roll back *and* forth to a random date/serial by using the collection of all updates Proposal: We add a 'stored:' attribute to every object in the database that will contain the following information: stored: (NEW|UPD) DATE TIME serialnumber NEW|UPD - are we dealing with a new object or is it already updated once ? DATE - YYYYMMDD date of storing including the leading 19 or 20 TIME - time in HH:MM.SS, UTC time zone SERIAL - serial number to avoid updates with same time & date This should be an (nearly) ever increasing number. It could start from 0 for every date & time combination, but then we still need another ever increasing number for finding out if we missed updates or not. Of course every detail is open to discussion, I just wrote down one of the possibilities. In addition to the stored attribute we need a 'replaced:' attribute that will point to the object that it replaced and will thus nearly have the same syntax: replaced: SOURCE DATE TIME SERIAL We add the SOURCE here, for the time when we start integrating the different registry databases. Furthermore, we need to decide if we want to have both attributes to be visible when doing a whois query, one of them visible or all hidden except when using a special option. As always, please advise! David Kessens RIPE NCC

1 0

RE: Unauthorized modifications of RIPEDB
by Wilfried Woeber, UniVie/ACOnet 15 Jan '96

15 Jan '96

Looking at this incident with my DB-WG hat on - = > Last week the following new 219 domains appeared in RIPEDB. = > I can't believe that all of European TLD administrators = > registered this domains at the same time. Moreover with and without CO. I wonder who's going to remove these mis-leading entries? ...could become an interesting game if this becomes popular :-) Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------

2 1

FYI: RIPE DB and Domain Names
by Daniel Karrenberg 15 Jan '96

15 Jan '96

------- Forwarded Message Date: Mon, 15 Jan 1996 10:23:15 +0100 From: Daniel Karrenberg <Daniel.Karrenberg(a)ripe.net> Sender: dfk(a)ripe.net To: Domain registration staff <hostmaster(a)sztaki.hu> cc: ripe-op(a)ripe.net Subject: Unauthorized modifications of RIPEDB > Domain registration staff <hostmaster(a)sztaki.hu> writes: > Dear NCC, > > > Last week the following new 219 domains appeared in RIPEDB. > I can't believe that all of European TLD administrators > registered this domains at the same time. Moreover with and without CO. There are two basic problems here: 1) Confusion about the role of the RIPE database in *domain names*. The database is not authoritative about domain names. It is just informational for these. The authoritative registry of domain names for TLDs is kept by TLD administrators. They are encouraged use the ripe database to make their registry accessible. This is *not* mandatory. 2) Lack of authorisation in the RIPE database for the *creation* of objects. As David Kessens has pointed out already we are working on this. Once this is implemented TLD administrators can control the creation of objects within their namespace. This is the top priority database development item at the moment. We are also working on a simple referral method so that TLD administrators can run their own whois services, as the NL TLD administrator does. Until these problems are solved the RIPE database can be nothing more than informational about TLDs. Oncve they are solved TLD administrators have the means to keep their data clean if they wish. Daniel ------- End of Forwarded Message

1 0