- db-wg - mailman.ripe.net

Re: Domain object template
by Andreas.Knocke＠nic.de 11 Jan '95

11 Jan '95

Hello, a couple of additions to the discussion: > * Can we please drop the possibility of allowing IP numbers here? > * If one of the secondaries of your domain changes IP number, then > * he has the nearly impossible task of finding all these outdated > * references. Bind only allows hostnames here; I think it is a good > * idea to restrict the database in the same way. > * > * => IP numbers were allowed in the previous template then we need > * a general agreement before dropping this possibility... > > Perhaps we should try and completely overhaul the domain object? Why > would we go for small changes when we may need major changes? I somehow agree with the positions Geert Jan and Marten gave, a complete overhaul is probably needed and especially the nserver, IP-address idea was much discussed the last time at the RIPE meeting in Amsterdam (May 1994) with the idea that there is a much more useful place to store it - BIND ! On the other hand there is maybe one useful point to IP-numbers here, for a domain abc.zz with a set of nameservers ns1.abc.zz and ns2.abc.zz which have lost connectivity - a very bad situation, I agree - it might be helpful to find there IP addresses here as well, so I would propose to use it only for nserver within the specified domain. domain: ABC.zz descr: ABC company .... nserver: ns1.abc.zz 194.205.120.3 nserver: ns2.abc.zz 194.205.120.6 nserver: ns.domain.my nserver: foo.bar.com ... Giving the primary first is probably a good idea, but what about 'hidden' primaries. It is I think a common situation for organisation behind a dial-up connection administering there own nameserver (as given in the SOA) with only a set of secondaries published as NS-RR's. This cannot be documented - if one wants to - this way, but maybe with a useful remark: > * => there is a loose binding between names and addresses. > * This attribute can be used if someone'd like to describe it. > * This attribute has been made optional then you use it only > * if you like. > > Hmm, personally I'd bin the attribute..... I think that most of the attributes made optional instead of obsolete could be seen as a compromise we can agree upon as a transitional step until the complete overhaul - if not achieveable at this meeting ? > > admin-c: The admin-c attribute contains the name or the NIC > > I suggest to make mandatory that the administrative contact > should reside on the site itself. Assume that people have outsourced > the 'technical stuff' of their network, then it is likely that the > technical contact is someone belonging to another company, and > it might be difficult to get in touch with the holder of the > domain itself because the address/phone number is different. > > => the admin contact for domains is different from the admin > contact for networks. It is explicitely an administrative > person who can answer to questions about name property, > legal problems, etc... In fact I understand your problem > but I believe the change should be done in the network > template. I totally agree with Geert Jan here, the admin-c should be from the organisation using domain and should be changed if he no longer represents this organisation. I didn't follow the discussion but heard some rumors about mtv.com but this way might be a good start. You have to have the organisation's address and at least one phone number somewhere. Another but important aspect I think would be to find a better (more up to date) example, if it should convince and educate new registries. The current one contains a number of factional errors (I'll append the correct entry at the bottom of this posting) and some discrepancy to it's own explanation for instance the format of the change dates not in format YYMMDD. Finally with the handles and names as key values for person objects 1.2 could be reformulated. Before entering or updating person objects the database should be checked for existing entries which were created as references of other objects (inetnum,...). Care should be taken to keep them up to date, without generating duplicate entries one with and one without a handle. I did it a number of times myself when I started using handles so please don't take it as an accusation to anybody. On the other hand the advent of ripe handles gives us the proper way to create different objects for one person where necessary - e.g. if he has his own domain at home and supports a number of networks or anything else at work. -------------------------------------------------------------------------- domain: uka.de descr: Universitaet Karlsruhe descr: Informatik Rechnerabteilung IRA descr: Am Fasanengarten 5, D-76128 Karlsruhe, Germany admin-c: WZ5-RIPE tech-c: KB49 tech-c: AN45 zone-c: KB49 nserver: iraun1.ira.uka.de nserver: iraux1.ira.uka.de nserver: ns.germany.eu.net nserver: ns.nic.de sub-dom: ira dom-net: 129.13.0.0 192.54.104.0 mnt-by: DE-DOM changed: nipper(a)ira.uka.de 910208 changed: knocke(a)nic.de 941121 source: RIPE person: Werner Zorn address: Universitaet Karlsruhe address: Informatikrechnerabteilung address: Am Fasanengarten 5 address: D-76128 Karlsruhe address: Germany phone: +49 721 608 3981 fax-no: +49 721 699 284 e-mail: zorn(a)IRA.UKA.DE nic-hdl: WZ5-RIPE mnt-by: DENIC-P changed: dfk(a)cwi.nl 900411 changed: rv(a)Informatik.Uni-Dortmund.DE 930704 changed: knocke(a)nic.de 941121 source: RIPE person: Klaus Becker address: Universitaet Karlsruhe address: Informatikrechnerabteilung address: Am Fasanengarten 5 address: D-76128 Karlsruhe address: Germany phone: +49 721 608 3973 fax-no: +49 721 699 284 e-mail: becker(a)ira.uka.de nic-hdl: KB49 mnt-by: DENIC-P changed: nipper(a)xlink.net 940406 changed: knocke(a)nic.de 941121 source: RIPE person: Arnold Nipper address: NTG Netzwerk und Telematic GmbH address: Geschaeftsbereich XLINK address: Vincenz-Priessnitz-Str. 3 address: D-76131 Karlsruhe address: Germany phone: +49 721 9652 0 fax-no: +49 721 9652 210 e-mail: nipper(a)xlink.net nic-hdl: AN45 changed: nipper(a)xlink.net 940616 source: RIPE

1 0

Re: Domain object template
by Dave Morton 11 Jan '95

11 Jan '95

All very good points - I agree with Geert. Dave

1 0

Re: "Dale S. Johnson": # Comment characters in templates
by Wilfried Woeber, UniVie/ACOnet 02 Dec '94

02 Dec '94

= * > which would be processed normally, ie the # lines ignored. They = * > would not end up in the database of course. = * = * > Any major showstoppers here? = * = * = * Well, no objections... this is really simple to implement, and may be = * very useful. = =It should be noted though that from that moment on "#" lines no longer =can be used to end an object. Two objects with only a "#" line between =them will be viewed as one, and will generate a syntax error. = =-Marten I agree that the proposed functionality to allow comments is useful. As to the aspect of separation of objects - well, I think with the invention of the password stuff and with the idea of grabbing the whois template output and writing scripts and the like, we should be asking whether just a blank line is the best way to separate objects... How about an "end: whatever string you like to put here" attribute to be equivalent to a blank line separating objects? Any hard feelings? 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 --------------------------------------------------------------------------

1 0

"Dale S. Johnson": # Comment characters in templates
by Marten Terpstra 29 Nov '94

29 Nov '94

Folks, Dale Johnson from MERIT brings up the issue of allowing "#" style comments in objects between attributes. From an implementation point of view this is *very* simple. Any major objections? The database sw would simply ignore them. Note that they would have to be on a line by themselves, NOT inside an attribute. An example would be: person: Marten Terpstra address: RIPE Network Coordination Centre (NCC) address: PRIDE Project address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: Netherlands # This is some comment phone: +31 20 592 5064 fax-no: +31 20 592 5090 e-mail: Marten.Terpstra(a)ripe.net nic-hdl: MT2 # And this as well notify: marten(a)ripe.net changed: marten(a)ripe.net 941128 source: RIPE which would be processed normally, ie the # lines ignored. They would not end up in the database of course. Any major showstoppers here? -Marten ------- Forwarded Message Date: Mon, 28 Nov 1994 14:49:50 -0500 From: "Dale S. Johnson" <dsj(a)merit.edu> To: Marten(a)ripe.net cc: Tony.Bates(a)ripe.net Subject: # Comment characters in templates Marten, What do you think of the idea of allowing #Comments in templates that are processed by auto-dbm? I bring this up privately because it seems like something that must have caused some discussion before if it isn't all ready implemented. The arguments are the same as for commenting programs: objects (especially aut-num objects) can be huge and complex now. Even if the comments aren't preserved in the storage and output formats, it would make lots of sense for people to keep comments in their original versions on their own machines, and not have to sed these out before they send them to auto-dbm. Is there all ready a history on this question? Or could it be done without discussion? Or if it needs discussion, what list would be appropriate? --Dale ------- End of Forwarded Message

3 3

Re: "Dale S. Johnson": # Comment characters in templates
by Marten Terpstra 29 Nov '94

29 Nov '94

David.Kessens(a)ripe.net writes * Hi Marten, * * I see no problems but is a '#' also allowed after a number of spaces : * * # This is a comment Yup, leading spaces are always ignored. * Do you check the attributes for '#' when sent in ? * Does this generate a warning ? Well, if there is a "#" type comment inside an attribute (ie somewhere inside the value of an attribute) this will generate a syntax error in most cases. Ie something like: person: Marten Terpstra address: ....... phone: +31 20 592 5065 # Preferred phone: +31 20 592 5064 # Backup would spefically NOT be allowed and would generate syntax errors for that attribute. Unless of course the syntax for an attribute allows # chars (I don't think there are any though). -Marten

1 0

RIPE Database Transition T2
by Marten Terpstra 17 Nov '94

17 Nov '94

Dear all, Apologies for this wide distribution but I think it is important enough. This is a reminder that coming Monday the 21st of November, the second and last step of the RIPE database transition will take place. This transition is the transition from network number objects that hold all policy information, to route objects that contain all this information. For more detailed info on what exactly will change and how, please read ripe-123 which is available as: ftp://ftp.ripe.net/ripe/docs/ripe-123.{txt|ps} Especially section 5 explains forthe various RIPE database user groups what is going to change. -Marten

1 0

Database transition step 1 completed
by Marten Terpstra 14 Oct '94

14 Oct '94

Dear all, I am pleased to say that the first step of the RIPE database transition has been succesfully completed yesterday. Up till now, one minor and one major bug have been found and fixed and the database seems stable. Those who daily ftp the ripe database from ftp.ripe.net may have found that it was not there this morning. This was a simple typo in one of my scripts and has been fixed. The ftpable files (the complete database in ripe/dbase/ripe.db and the split versions in ripe/dbase/split) are currently generated at around 5:30 (AM for the US folks ;-) Dutch time, which is currently UTC+1. All database files ara available as uncompressed and compressed (both normal compress and gzip) versions. The generation time can be changed if you think there is a need (earlier, not later). Those who run a secondary copy of the database may find that the latest ftpable database takes much longer to index. This is because the database now includes large provider blocks, and the old software is not good at handling large blocks. The current plan is to have a beta release of the software (with some documentation on the changes) ready this weekend, so you can pick up this software and use it to index the RIPE database. This version will have all of the classless and other features as per the database transition plan (T1). As far as conflicts/problems in the guardian files are concerned, most of them have been resolved. There are some 15 guardian files left with problems. These guardians will be approached to correct these problems. If you have questions/comments/bugs, please report to me personally, or to any of the above lists if you think they are interesting for a larger audience. Regards, -Marten

1 0

New Document available: ripe-123
by RIPE NCC Document Annoucement Service 06 Oct '94

06 Oct '94

New/Revised RIPE Document Announcement -------------------------------------- A revised/new document is available from the RIPE document store. Ref: ripe-123 Title: RIPE Database Transition Plan Author: Tony Bates, Daniel Karrenberg, Marten Terpstra Date: 3 October 1994 Format: PS=70350 TXT=35083 Obsoletes: Obsoleted by: Updates: Updated by: Old: Short content description ------------------------- This document guves full details of the transition plan for the new proposed RIPE database and routing registry objects. Please make sure you are aware of the details in the document including the actual dates. FTP Access ---------- All RIPE documents and Internet RFC`s are available via anonymous FTP from host ftp.ripe.net. Type "ftp ftp.ripe.net". Login with username "anonymous" supplying your email address as the password. After logging in, type "cd ripe/docs/" followed by the command "get filename". The relevant filenames for this document are: ripe-123.txt for the ASCII version ripe-123.ps for the PostScript version Electronic Mail Retrieval of Documents -------------------------------------- Documents can also be retrieved from the RIPE document store using a mail server program. For more information on how to use the program, send email to: mail-server(a)ripe.net with "send HELP" in the body text. RIPE NCC Interactive Information Server --------------------------------------- Type "telnet info.ripe.net". This is a menu driven service allows the document store to be browsed. After reading documents you are prompted as to whether you would like to receive an email copy of the document you have just read. If you would, you simply enter your email address and the document will be mailed to you. Below are details of alternative methods of access. Gopher Access ------------- The same documents are available via a "gopher" server at "gopher gopher.ripe.net". WAIS Access ----------- There is also a "WAIS" server at wais.ripe.net, where there is a WAIS index for RIPE documents "ripe-docs.src" WWW Access ---------- For those who wish to add this home page at the RIPE NCC to their own customized home pages, it can be accessed as: http://www.ripe.net MIME Mail Reader ---------------- Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the RIPE document by FTP or mail server. SEND ripe/docs/ripe-123.txt

1 0

New Document available: ripe-122
by RIPE NCC Document Annoucement Service 06 Oct '94

06 Oct '94

New/Revised RIPE Document Announcement -------------------------------------- A revised/new document is available from the RIPE document store. Ref: ripe-122 Title: Specifying an `Internet Router' in the Routing Registry Author: Tony Bates Date: 3 October 1994 Format: PS=37970 TXT=14242 Obsoletes: Obsoleted by: Updates: Updated by: Old: Short content description ------------------------- This document specifies a simple object for detailing Internet routers with the RIPE routing registry. FTP Access ---------- All RIPE documents and Internet RFC`s are available via anonymous FTP from host ftp.ripe.net. Type "ftp ftp.ripe.net". Login with username "anonymous" supplying your email address as the password. After logging in, type "cd ripe/docs/" followed by the command "get filename". The relevant filenames for this document are: ripe-122.txt for the ASCII version ripe-122.ps for the PostScript version Electronic Mail Retrieval of Documents -------------------------------------- Documents can also be retrieved from the RIPE document store using a mail server program. For more information on how to use the program, send email to: mail-server(a)ripe.net with "send HELP" in the body text. RIPE NCC Interactive Information Server --------------------------------------- Type "telnet info.ripe.net". This is a menu driven service allows the document store to be browsed. After reading documents you are prompted as to whether you would like to receive an email copy of the document you have just read. If you would, you simply enter your email address and the document will be mailed to you. Below are details of alternative methods of access. Gopher Access ------------- The same documents are available via a "gopher" server at "gopher gopher.ripe.net". WAIS Access ----------- There is also a "WAIS" server at wais.ripe.net, where there is a WAIS index for RIPE documents "ripe-docs.src" WWW Access ---------- For those who wish to add this home page at the RIPE NCC to their own customized home pages, it can be accessed as: http://www.ripe.net MIME Mail Reader ---------------- Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the RIPE document by FTP or mail server. SEND ripe/docs/ripe-122.txt

1 0

New Document available: ripe-121
by RIPE NCC Document Annoucement Service 06 Oct '94

06 Oct '94

New/Revised RIPE Document Announcement -------------------------------------- A revised/new document is available from the RIPE document store. Ref: ripe-121 Title: Support for Classless Internet Addresses in the RIPE Database Author: Tony Bates, Daniel Karrenberg, Marten Terpstra Date: 3 October 1994 Format: PS=36698 TXT=14177 Obsoletes: Obsoleted by: Updates: Updated by: Old: Short content description ------------------------- This document details the added support for classless Internet addresses in the RIPE database. It details the change in representation and handling of database objects. FTP Access ---------- All RIPE documents and Internet RFC`s are available via anonymous FTP from host ftp.ripe.net. Type "ftp ftp.ripe.net". Login with username "anonymous" supplying your email address as the password. After logging in, type "cd ripe/docs/" followed by the command "get filename". The relevant filenames for this document are: ripe-121.txt for the ASCII version ripe-121.ps for the PostScript version Electronic Mail Retrieval of Documents -------------------------------------- Documents can also be retrieved from the RIPE document store using a mail server program. For more information on how to use the program, send email to: mail-server(a)ripe.net with "send HELP" in the body text. RIPE NCC Interactive Information Server --------------------------------------- Type "telnet info.ripe.net". This is a menu driven service allows the document store to be browsed. After reading documents you are prompted as to whether you would like to receive an email copy of the document you have just read. If you would, you simply enter your email address and the document will be mailed to you. Below are details of alternative methods of access. Gopher Access ------------- The same documents are available via a "gopher" server at "gopher gopher.ripe.net". WAIS Access ----------- There is also a "WAIS" server at wais.ripe.net, where there is a WAIS index for RIPE documents "ripe-docs.src" WWW Access ---------- For those who wish to add this home page at the RIPE NCC to their own customized home pages, it can be accessed as: http://www.ripe.net MIME Mail Reader ---------------- Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the RIPE document by FTP or mail server. SEND ripe/docs/ripe-121.txt

1 0

New Document available: ripe-120
by RIPE NCC Document Annoucement Service 06 Oct '94

06 Oct '94

New/Revised RIPE Document Announcement -------------------------------------- A revised/new document is available from the RIPE document store. Ref: ripe-120 Title: Authorisation and Notification of Changes in the RIPE Database Author: Daniel Karrenberg, Marten Terpstra Date: 3 October 1994 Format: PS=50496 TXT=28655 Obsoletes: ripe-096 Obsoleted by: Updates: Updated by: Old: Short content description ------------------------- This document represents a major change in the way authorisation and notification of changes and updates in the RIPE database will be done in the future. FTP Access ---------- All RIPE documents and Internet RFC`s are available via anonymous FTP from host ftp.ripe.net. Type "ftp ftp.ripe.net". Login with username "anonymous" supplying your email address as the password. After logging in, type "cd ripe/docs/" followed by the command "get filename". The relevant filenames for this document are: ripe-120.txt for the ASCII version ripe-120.ps for the PostScript version Electronic Mail Retrieval of Documents -------------------------------------- Documents can also be retrieved from the RIPE document store using a mail server program. For more information on how to use the program, send email to: mail-server(a)ripe.net with "send HELP" in the body text. RIPE NCC Interactive Information Server --------------------------------------- Type "telnet info.ripe.net". This is a menu driven service allows the document store to be browsed. After reading documents you are prompted as to whether you would like to receive an email copy of the document you have just read. If you would, you simply enter your email address and the document will be mailed to you. Below are details of alternative methods of access. Gopher Access ------------- The same documents are available via a "gopher" server at "gopher gopher.ripe.net". WAIS Access ----------- There is also a "WAIS" server at wais.ripe.net, where there is a WAIS index for RIPE documents "ripe-docs.src" WWW Access ---------- For those who wish to add this home page at the RIPE NCC to their own customized home pages, it can be accessed as: http://www.ripe.net MIME Mail Reader ---------------- Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the RIPE document by FTP or mail server. SEND ripe/docs/ripe-120.txt

1 0

New Document available: ripe-119
by RIPE NCC Document Annoucement Service 06 Oct '94

06 Oct '94

New/Revised RIPE Document Announcement -------------------------------------- A revised/new document is available from the RIPE document store. Ref: ripe-119 Title: RIPE Database Template for Networks and Persons Author: Anne Lord, Marten Tersptra Date: 3 October 1994 Format: PS=46506 TXT=21385 Obsoletes: ripe-050 Obsoleted by: Updates: Updated by: Old: Short content description ------------------------- This document is an update to the network object for the RIPE database. FTP Access ---------- All RIPE documents and Internet RFC`s are available via anonymous FTP from host ftp.ripe.net. Type "ftp ftp.ripe.net". Login with username "anonymous" supplying your email address as the password. After logging in, type "cd ripe/docs/" followed by the command "get filename". The relevant filenames for this document are: ripe-119.txt for the ASCII version ripe-119.ps for the PostScript version Electronic Mail Retrieval of Documents -------------------------------------- Documents can also be retrieved from the RIPE document store using a mail server program. For more information on how to use the program, send email to: mail-server(a)ripe.net with "send HELP" in the body text. RIPE NCC Interactive Information Server --------------------------------------- Type "telnet info.ripe.net". This is a menu driven service allows the document store to be browsed. After reading documents you are prompted as to whether you would like to receive an email copy of the document you have just read. If you would, you simply enter your email address and the document will be mailed to you. Below are details of alternative methods of access. Gopher Access ------------- The same documents are available via a "gopher" server at "gopher gopher.ripe.net". WAIS Access ----------- There is also a "WAIS" server at wais.ripe.net, where there is a WAIS index for RIPE documents "ripe-docs.src" WWW Access ---------- For those who wish to add this home page at the RIPE NCC to their own customized home pages, it can be accessed as: http://www.ripe.net MIME Mail Reader ---------------- Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the RIPE document by FTP or mail server. SEND ripe/docs/ripe-119.txt

1 0

DB-WG Draft minutes, Lisbon
by Wilfried Woeber, UniVie/ACOnet 03 Oct '94

03 Oct '94

This is the draft minutes for the DB-WG meeting in Lisbon. My sincere thanks are due to Havard Eidnes for doing a particularly good job at taking notes. Any comments welcome! Best regards, Wilfried. -------------------------------------------------------------------------------- Draft Minutes from DB-WG meeting at the 19th RIPE meeting, Lisbon ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. Opening Havard Eidnes volunteered to take the minutes. The proposed agenda item "review of DB-WG in the context of a changing RIPE" was moved to the end of the agenda. An item about "review of domain object for in-addr.arpa" was added. 2. The classless database Marten Terpstra from the RIPE NCC gave an orientation of what changes have been implemented and how this can be tested. The major changes are: - Change of representation of IP addresses and ranges in the database, as described in the draft "ripe-clarep" and "ripe-inetnum" documents. There are two new notations, classless prefix such as 192.0.0.0/8 and classless range (currently proposed as e.g. 192.3.2.0 > 192.3.3.255, this covers two class C networks). - Lookups in the new database will return the exact match if it exists, or the first less specific object. There are some options to control the matching: -L return all less specific entries -m return the direct more specific entry -M return all the more specific entries - The database itself has been split into individual files for each object type. - More new query options: -t <type> returns a template or form for the specified object type -T <type> return only objects of the specified type -F do a "fast and raw" return of data, i.e. no post-processing or pretty-printing -S do not add syntactic sugar (such as "accept", "from" etc. in AS object) A beta version of the database software is already up and running. It now consists of some 9000+ lines of Perl code. The software is still undergoing changes to acommodate the updated RIPE-81++ and to add authorization. There is a test server running at rijp.ripe.net which can be used for to become familiar with the bahaviour of the new code. A proposal was made to allow objects to be submitted to this test database, and Marten Terpstra agreed to set it up. These submitted changes will be removed from the database on a daily basis, as the data from the production database is pulled in. Current planning (as of the time of the RIPE meeting) calls for a move to using the new software in early October. The draft documents "ripe-clarep" and "ripe-inetnum" were approved. 3. Authorization Daniel Karrenberg from the RIPE NCC oriented about what changes are being proposed to improve (implement) authorization of updates in the RIPE database. This is being done by introducing: - A "maintainer" (mntner) object describing an entity responsible for a set of objects in the database, and where this maintainer wishes to secure his updates and prevent others from submitting changes to objects maintained by this maintainer going un-noticed. - New attributes: upd-to Send notifications of updates to this address mnt-nfy Basically same as "notify" auth Specifies authentication methods (in "mntner" object) - Authentication methods proposed: NONE no authentication (today's method :-) MAIL-FROM <regexp> update will only be accepted if mail containing a database update originates from an e-mail address matching the regular expression. CRYPT-PW <crypt-str> stores a crypted password, send a "password:" attribute (with the password in clear text) together with each update. A single maintainer can register more than one authentication method. Any individual object can be linked to more than one maintainer entity. The "password:" line(s) in update requests are not considered to be part of an object, thus no password will ever be forwarded by using the notify, mnt-nfy or similar attributes. A question was raised how one could be notified of the creation of new objects in the database. Guardians of communities and ASes will be notified when components are added/changed/removed. Notification will also be given when multiple "route" objects are registered with same key but different origins. However, the addition of a more specific route with a different origin than the immediate less specific route registered, the maintainer/guardian of the AS where the less specific route originates would probably not be notified (this was asked for). 4. inet-rtr (Internet Router) object There had been some recent input from the MBONE group; they wish to use this object to register details about IP multicast routers. However, the inet-rtr object is needed now by the PRIDE tools, so there was consensus that we should approve the doucment as it is. After some more discussions within the MBONE community a written proposal to extend the object is expected before the next RIPE meeting. 5. Database transition The RIPE NCC people summarized the transition issues when going from the old database to the new one. There will be changes in: - schema - procedures - user interface The WHOIS interface and the output from queries will have some changes (e.g. the classless representation is used instead of the old one). The guardian procedures will change; first there has to be an exact match between the entries in the guardian file and the entries in the database. The current database has been cross-checked with the current guardian files, and there are lots of conflicts in this area. When the new database software is put into production, the RIPE NCC will produce "problem" files in each guardian's home directory, and the guardians are strongly encouraged to clear these up before phase II of the database transition. The transition will happen by two "big bangs": B1 and B2. At B1: - the new classless database will be put into production - users of NLC will have to transition to using Merit's ALC program, as NLC will not be upgraded to support the new database. ALC functionality was described as being a superset of NLC. - Guarded objects can be updated under control of the new authorization mechanisms - The RIPE NCC will create prototype "mntner" objects in each guardian's home directory - The RIPE NCC will prepare new "inetnum" and "route" objects in each guardian's home directory Due to logistic concerns, between B1 and B2, updates for networks with allocation and routing information already split into separate objetcs (inetnum/route) will probably not be permitted. At B2: - complete transition to the new database Proposed time schedule: B1: early october B2: 4-6 weeks later The issue of how queries posed in the "old style" would be interpreted ensued -- the question is whether e.g. 128.39.0.0 should be interpreted as 128.39.0.0/32 or 128.39.0.0/16. In most cases the end result will be the same, since the immediate less specific object will be returned, although some expressed the opinion that the latter of the two interpretations would cause less confusion. The RIPE NCC held the opinion that /32 should be used, but apparently this needs to be discussed more. The database aspects of RIPE-81++ were approved (although the range notation may change). A proposal from the RIPE NCC to add "as-name" to the AS object was approved. 6. Domain object for in-addr.arpa Concern was expressed that with the advent of the classless database we may end up registering duplicate information, since the in-addr.arpa delegation hierarchy can now be implemented "properly" by use of the "inetnum" object. After a short discussion it was agreed that the RIPE NCC would review the opinions and come up with a new domain object proposal to cover this. 7. Time stamps in the database The people from Merit had expressed a desire to store more fine-grained time stapm information in the database, and had proposed to do this by adding hhmmss at the end of the "changed" attribute. This was hotly debated and contested from some parties, but there was consensus that there is a need to ensure that older updates stuck in mail queues would not be released later and overwrite more recent update requestss. To solve this, it was decided to add an optional sequence number to the "changed" attribute after the date string. This sequence number can, of course, be derived from local (at the origin of the update) hhmmss information. However, no time semantics of any form are implied. The people from Merit also wished to use this in some situations to produce a "consistency snapshot" of the database at a given time (in retrospect). Again it was contested whether the proposed simple mechanism would solve that issue. There will probably also be a separate new attribute called "stored" or "processed", which will record when the object was actually entered in the RIPE database (local time at the RIPE NCC). 8. RIPE handles This activity has been put on hold due to RIPE NCC overload. RIPE handles can be assigned on a case-by-case basis as the need arises. There are however too little resources available to carry this through together with the imminent database transition. 9. Ownership of objects This issue was overtaken by events, ref. the notify/maintainer changes. 10. Inverse recursion A query for added functionality had been raised; the trigger is the ability to pose a query like the following one: "give me all the objects where person XX is registered as a contact person". Marten Terpstra said this would probably take little time to add to the new database, and he would look into finding the extra time to do this. 11. Data exchange between IRs This has also been put on hold by the RIPE NCC, due to the lack of RIPE handles (see point 8). The advent of rwhois should improve this situation, and the entries for the blocks 193.* and 194.* will point at the whois server at the RIPE NCC. Otherwise a full merge of the databases (basically InterNIC and RIPE NCC) is difficult, since there are many conflicts between these databases outside of the 193.* and 194.* blocks, and who to "trust" in each case is uncertain. 12. CLNS routing registry Put on hold since the need for this is unclear, and the RIPE NCC do not have many resources to put into activity. There has also been a lack of input from the interested parties. Nevertheless, the functionality already implemented will be carried over to the new software and remain usable. 13. Review of DB-WG in the context of a changing RIPE The DB WG chairman expressed a desire to have the possibility to arrange at least a single non-parallel session during each RIPE meeting dedicated to the DB issues, since much of the work in other WGs touch on the DB. 14. AOB None. Meeting closed. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Wilfried.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

RIPE Database playground
by Marten Terpstra 20 Sep '94

20 Sep '94

Folks, As requested at the last RIPE meeting, I have setup a test database for you all to use and get some feeling of how all this works. Some details: - the "inetnum" and "route" objects (new format, ie after the split) will be regenerated every night, and will overwrite any changes/additions you may have sent in. - all other objects remain in the test database - the address to send test data to is: test-dbm(a)ripe.net - there is a whois server running on this database on machine "bwhois.ripe.net", normal whois port 43. - most of the functionaility of ripe-81++, authorisation, inet-rtr and all other docs presented at the RIPE meeting has been implemented. - there are a few things that still need implementation, try: "whois -h bwhois.ripe.net help" for help and open issues. - Bugs/Questions please to me directly (or ripe-dbm), or to the list if you think it is important enough. - most unix type clients will understand extra options (see the help for a complete list) as: % whois -h bwhois.ripe.net -- -L key or % whois -h bwhois.ripe.net "-L key" I will send a similar mail to the local-ir list and all guardians later this week or early next week, you are the first ones to have a go at it. Go! -Marten

1 0

Document update
by Tony Bates 16 Sep '94

16 Sep '94

As agreed at the last RIPE meeting, we have made updates to the following documents and moved them to final draft to be released as RIPE documents on the 30th September. They are as follows RIPE-81++ --------- ftp://ftp.ripe.net/ripe/drafts/ripe-81++.{ps,txt} Classless Representation ------------------------ ftp://ftp.ripe.net/ripe/drafts/clarep.{ps,txt} Authorization ------------- ftp://ftp.ripe.net/ripe/drafts/ripe-auth.{ps,txt} Transition Plan --------------- ftp://ftp.ripe.net/ripe/drafts/db-trans.{ps,txt} Inet-rtr object ---------------- ftp://ftp.ripe.net/ripe/drafts/inet-rtr.{ps,txt} Update to inetnum ----------------- ftp://ftp.ripe.net/ripe/drafts/ripe-inetnum.{ps,txt} Also, find the start of the experimental objects and attributes document for ripe-81++ extensions. ftp://ftp.ripe.net/ripe/drafts/experimental.{ps,txt} This is a placeholder for a more involved document to follow. Please make sure all comments are sent within two weeks. This message will also be sent to all AS and Community guardians. Apologies for any duplication but we want to make sure we reach all parties involved. --Tony, Marten and Daniel.

1 0

Re: 3rd draft agenda for DB-WG in Lisbon
by Victor Reijs 08 Sep '94

08 Sep '94

==> From: Marcel Wiget > > Hi Wilfried, > But, at least spoken for SWITCH, we would like to see a possiblity to > store routing and authority information not only for IPv4 but also for > other network protocols. In January I suggested already on the db-wg list > something like a network protocol address prefix. I don't see a need anymore > for a special CLNS proposal but I see a need for a more general view of > network entries in the RIPE database. > For sure we will need an enhancement to support IP6. All the features > implemented in the new whois server related to CIDR simplifies the usage > for any routing objects based on a longest prefix match ..., and yes, > CLNS falls in this area as well. > I agree, spoken for SURFnet, with Marcel. All the best, Victor

1 0

3rd draft agenda for DB-WG in Lisbon
by Wilfried Woeber, UniVie/ACOnet 08 Sep '94

08 Sep '94

This is the 3 version of the draft agenda for the DB-WG meeting. There has again been a slight rearrangement (thanks for the feedback!). As I'm out of office the week before the meeting - could the NCC please either forward this version to the RIPE-community at large or include/attach it to the RIPE-19 agenda? I'm not sure whether it's a good idea to send it to the full RIPE-List (only?). Any input still welcome! I expect to have access to the net the week before the meeting. See you, Wilfried. 3rd Draft: Agenda for the DB-Working-Group at RIPE-19, Lisbon. -------------------------------------------------------------- 0. Opening (30') . appointment of scribe . amendment/rearrangement of agenda . any admin stuff I . review of DB-WG in the context of a changing RIPE x. The Classless Database (90') S . review of beta (as announced by Marten Terpstra) - new features, interface changes, update mechanism A . (ripe-clarep, ripe-inetnum) document review, and decision A . (ripe-auth) proposed guardian mechanism changes A . (inet-rtr) proposed router object, review and decision S . review of requirements and scheduled changes A . transition aspects x. Database Operations Review (45') A . RIPE-Handles (flag day?) I . any loose ends? (experiences) I . ownership of objects, update, coordination (Daniel Kalchev) I . need for new types of lookup/backlinks? (Havard Eidnes) x. Interworking with other regions (30') S . DB-Exchange (status) S . RWhois, aggrwalk, ... x. CLNS Routing Registry (10') A . status review and decision about further activities Z. AOB Key: I ... Informal discussion S ... review of Status, on-going A ... discussion and Approval requested Supporting documents: ftp://ftp.ripe.net/ripe/drafts/ripe-clarep.txt ftp://ftp.ripe.net/ripe/drafts/ripe-inetnum.txt ftp://ftp.ripe.net/ripe/drafts/inet-rtr.txt ftp://ftp.ripe.net/ripe/drafts/ripe-auth.txt (a "transition document" to be announced by the NCC) -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Wilfried.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

Draft Transition document
by Tony Bates 08 Sep '94

08 Sep '94

Find below the draft of the promised transtition document to incorporate all the proposed features of the new database. This is also available as ftp://ftp.ripe.net/ripe/drafts/db-trans.{txt,ps} We will bring copies of this document to the RIPE as we are so late in getting it out (we will not be doing this for other documents so please take note). Regards and see you in Lisbon, --Tony. RIPE Database Transition Plan DRAFT DRAFT DRAFT Tony Bates Daniel Karrenberg Marten Terpstra Document-ID: ripe-1nn August, 1994 ABSTRACT This paper details a transition plan of the changes needed to move from the current RIPE Database to a RIPE Database that supports classless IP network numbers, authorisation of updates and changes to Routing Registry information. 1. Introduction The RIPE database is about to undergo some major changes. These changes come from a set of documents produced by various RIPE work- ing groups and the RIPE NCC. There are three major changes to the RIPE database that will affect the database in such a way, that a description of the changes and a clear transition plan is needed. These three changes are: o Support for Classless Internet Addresses [1]. o Authorisation and Notification of Changes [2]. o Representation of IP Routing Policies in a Routing Registry [3]. All these three new features of the RIPE database will affect the working of the RIPE Database, from simple things like altered out- put, to more complex things like guarded attributes and objects [4]. The three changes will be dealt with in turn in this document. If you wish to get a quick overview of how this affects you please refer to Section 5. ripe-1nn.txt August, 1994 - 2 - Each of the sections will have points in time attached to them, at which time a certain change will take effect. These points in time are labeled T1 and T2. For some changes that need to be made, a cer- tain "flag day" is needed. On these days some changes will take place that are not backward compatible and must be performed in a "big bang" type of change. These dates are labeled B1 and B2. All changes will be labeled with a Tn and/or a Bn. Table 1 shows the current time estimates for each of these changes. +---------+----------+------+ | Date | Big Bang | Time | +---------+----------+------+ | Now | | T0 | |15-10-94 | B1 | T1 | | 1-12-94 | B2 | T2 | +---------+----------+------+ Table 1: Timescales for transition changes In the sections describing a change, there will be a small section shortly describing the effect this will have on users of the RIPE database. For this document the users have been categorised in four groups: users querying the database, AS and community guardians, maintainers of "inetnum" objects and maintainers of other database information. 2. Support for Classless Internet Addresses There are several aspects pertaining to the introduction of class- less Internet addresses in the RIPE Database as document in [2]. 2.1. Querying the RIPE database To support classless addresses in the RIPE database, one different representation of Internet addresses will be supported for queries to the database. This notation is the prefix/length notation as explained in [1]. Correct queries to the database will be for exam- ple: 192.87.45.0/24 192.87.228.0/23 128.141.0.0/16 193.0.0.132/32 For backward compatibility, "old" style queries will still be sup- ported. They are however internally to the database server trans- formed to a prefix/length notation, after which they are handled as above. This transformation could change the expected output. For example: ripe-1nn.txt August, 1994 - 3 - 192.87.45 will be rewritten internally to 192.87.45.0/32 128.141 will be rewritten to 128.141.0.0/32 193.0.0.0 will be rewritten to 193.0.0.0/32 Other type queries that are supported, but not encouraged are pre- fix/length queries, for which the prefix is not a full dotted quad: 128.141/16 will be rewritten to 128.141.0.0/16 192.87.45/24 will be rewritten to 192.87.45.0/24 For queries where the prefix and the length are incompatible (like 192.87.45.0/8), the length will be used to mask off all extra bits from the prefix. This example will be rewritten to 192.0.0.0/8. % whois -r 193.1.209.0/24 inetnum: 193.1.209.0 netname: NCIR-LAN descr: Local Ethernet descr: National College of Industrial Relations descr: Sandford Road descr: Dublin 6 descr: Ireland country: IE admin-c: Neil Armstrong tech-c: Neil Armstrong connect: RIPE NSF aut-sys: AS1213 changed: mnorris(a)hea.ie 940823 source: RIPE % whois -r 193.1.209.0/8 inetnum: 193.0.0.0 - 193.255.255.255 netname: RIPE-CBLK descr: European Address Block #1 country: EU admin-c: DK58 tech-c: TB230 tech-c: MT2 remarks: delegated changed: testdb(a)ripe.net 940707 source: RIPE The default behavior for the RIPE database will be to respond to the query with an exact match if possible, or otherwise the first less specific match it can find. In most cases this will mean that when queries for host addresses (193.0.0.132/32) one will receive the network block this host is part of as registered in the database (in this case probably 193.0.0.0/24). ripe-1nn.txt August, 1994 - 4 - % whois -r 193.0.0.132/32 inetnum: 193.0.0.0 netname: RIPE-NCC descr: RIPE Network Coordination Centre descr: Amsterdam, Netherlands country: NL admin-c: Daniel Karrenberg tech-c: Marten Terpstra tech-c: Tony Bates aut-sys: AS3333 ias-int: 193.0.0.221 AS1104 ias-int: 193.0.0.157 AS1104 rev-srv: ns.ripe.net rev-srv: ns.eu.net notify: ops(a)ripe.net changed: tony(a)ripe.net 940708 source: RIPE The RIPE NCC will also insert objects that describe a block delega- tion to an Internet Registry into the database. For example the block 193.1.0.0 - 193.1.255.255 delegated to HEANET, will have an associated entry in the database. When one would query a network number from this block that has not been allocated by HEANET yet, the server will respond with the object for the complete block. This means that less queries will result in a "No entries found" answer, but will give some indication of where that specific piece of address space currently resides. The same is true for address blocks 193.0.0.0 - 193.255.255.255 and 194.0.0.0 - 194.255.255.255 dele- gated to the RIPE NCC. % whois -r 193.1.141.0/24 inetnum: 193.1.0.0 - 193.1.255.255 netname: EU-BLOCK-193-1 descr: HEAnet country: IE admin-c: Mike Norris tech-c: Mike Norris remarks: delegated changed: marten(a)ripe.net 930901 source: RIPE The database server will also support some extra features to display the complete list of less specific matches, a list of direct more specific matches, and a list of more specific matches including more specifics of more specifics. The flags to enable these features can be found in the RIPE whois client manual page. All of these changes will take place at once when enabling the soft- ware that supports classless internet addresses at B1. Changes to tools that make use of the database server have to be made before ripe-1nn.txt August, 1994 - 5 - that time. 2.2. Changes to the guardian files Currently all guardians of guarded attributes maintain files on the RIPE NCC database machine. These files are examined once per day and the associated guarded attribute added to all network objects listed in these files. When a network block is found in the database , and not all of the networks in this block are mentioned in a guardian file, this block is split so that only the mentioned networks get the associated guarded attribute. This procedure can no longer work in a classless database for two reasons: o from a block of network numbers it is no longer clear where one network ends and the next one starts. The class A, B and C boundaries no longer apply, so the software cannot make deci- sions any longer on where to split a block if necessary; o a certain network number can appear more than once in the database in different block entries. In normal cases, any net- work number assigned through the NCC will appear at least three times in the database: once in the entry describing the alloca- tion to an end-side or user, once as a block delegation from the NCC to a local registry, and once as a block delegation from IANA to the RIPE NCC. It is therefore impossible for the software to find out which of these blocks should be split and where this guarded attribute should be added. The way this will be solved is to only add guarded attributes to objects if the entry in the guardian file exactly matches the "inet- num" value of an object in the database. Assume we have a guardian file that contains two lines: 192.87.45.0 193.0.0.0 - 193.0.0.5 In this case, the guarded attribute associated with this file will NOT be added to entry "192.87.45.0 - 192.87.46.0", "193.0.0.0 - 193.255.255.0" or any other non-exact match in the database. Since blocks are no longer split, any line in the guardian file that does not correspond to an exact match in the database, will cause a notification mail message to be sent to the guardian with the expla- nation that no match could be found in the database. Because this is a direct effect of the enabling of the classless ripe-1nn.txt August, 1994 - 6 - software, this change will have to be made at B1. This means that all guardians will have to check their files for non-matching entries and correct them. The NCC will assist all guardians that have an account on the NCC database machine by generating a problem file for them. This file will list all entries in their guardian file that are either not present in the database, or entries that are appear in a bigger block in the database. Any non-exact match can therefore easily be spotted. The program producing these files will run every night up till B1. The file generated will be called "problems" and will be put in the home directory of each of the guardians. Guardians are strongly requested to change their guardian files to eliminate any non-exact match before B1. At point B1, non-exact matches can cause a loss of guarded attributes. It should be noted that this transition is an interim measure to be used between T1 and T2. A completely new procedure to guard attributes and objects is outlined in [2] and a transition for that proposal is outlined in the next section. 3. Authorisation and Notification of Changes The RIPE NCC has produced a paper that describes a mechanism to authorise and notify any changes to objects in the RIPE database [2]. Although these changes apply to all objects in the database, there are some transition issues when these mechanisms are used to replace the current guarded attribute and guarded object procedure. The general use of the authentication and notification will be available from T1. 3.1. Guarded Attributes As explained in [4] the current procedure for guarded attributes is that guardians maintain files on the NCC database machine, from which guarded attributes are added to objects to the database. Although this has worked reasonably well for over a year, it can be solved with a more general authentication and notification scheme. This scheme is explained in [2]. The introduction of "route" objects in the RIPE database (see below) removes the necessity of guarded attributes in their current form. The primary reason for having guarded attributes (authenticity guar- antees because of their operational impact) can be solved by the general authentication scheme. The transition issues involved are of a bootstrap nature. This tran- sition plan foresees the generation of routes from existing network numbers. This will be explained in more detail in the next section. When these newly generated routes are to be used they should be properly maintained using the proposed mechanism. To bootstrap this procedure and to ensure that all routes are properly maintained, the NCC will generate an example "mntner" object [2] for all guardians ripe-1nn.txt August, 1994 - 7 - that have an account on the NCC database machine. The information for this object will be placed in a file in each guardian's home directory. The file name will be "mntner". The information in this object will be derived as best as possible from the current guardian information. These objects will be gener- ated once only. The guardian can then change this object in whatever way he/she wishes. The guardian can even decide to already submit the modified "mntner" object generated for them to the database. At B2, all routes that will be generated from the current network numbers will be maintained by the maintainer mentioned in the file generated in the associated guardian accounts. To ensure that all generated routes are properly maintained, only the "mntner" file in each of the guardian's accounts will be used to tag the newly gener- ated routes. The "mntner" object found in this file will also be automatically entered into the database. Guardians that currently maintain multiple files on multiple accounts can decide to only reg- ister with a single "mntner" object. They will have to ensure that the "mntner" objects in all their accounts are equal. For more details see below. The current guardian procedure will be turned off at B2. At that time, the newly generated route objects should all be maintained, and the need for guardians in the current meaning will have disappeared. All guardian accounts and files will be removed shortly after B2. 3.2. Guarded Objects The RIPE database currently has support for guarded objects. These are objects that cannot be updated using the automatic procedure, but need to be manually checked by NCC staff and are then forwarded to the database. Currently the only guarded objects are "community" and "aut-num". This mechanism was put in place to avoid mistakes when updating operationally critical objects like autonomous system objects. It is fairly obvious that this procedure can be replaced using the authentication mechanism described in [2]. At T1, the maintainer mechanism will be enabled and current guarded attributes can start using this mechanism to replace the manual intervention by the NCC currently needed. For a certain time, guarded objects will still be accepted using the old mechanism (mailed to ripe-dbm(a)ripe.net for checking), but whenever a "mnt-by" attribute is present in any guarded object, these objects can be updated automatically. This does however mean it will have to pass the authorisation as specified by the maintainer. 4. Transition to RIPE-81++ There are several important aspects pertaining to the transition of the objects documented in RIPE-81++ [3]. This also includes the related "inet-rtr" object [5]. ripe-1nn.txt August, 1994 - 8 - 4.1. Separation of routing from allocation information This represents a significant change to both the database objects and to actual data in the database. The two database objects affected will be the existing "inetnum" [8] object and the "route" object as detailed in [3]. This will result in some information being moved from the "inetnum" [6] object to "route" object and some information being deleted from the "inetnum" object. If we look at an existing "inetnum" object: inetnum: 192.87.45.0 netname: RIPE-NCC descr: RIPE Network Coordination Centre descr: Amsterdam, Netherlands country: NL admin-c: Daniel Karrenberg tech-c: Marten Terpstra connect: RIPE NSF WCW aut-sys: AS3333 comm-list: SURFNET ias-int: 192.87.45.80 AS1104 ias-int: 192.87.45.6 AS2122 ias-int: 192.87.45.254 AS2600 rev-srv: ns.ripe.net rev-srv: ns.eu.net notify: ops(a)ripe.net changed: tony(a)ripe.net 940110 source: RIPE The routing information contained in the "inetnum" object will now be distributed over two objects like so: ripe-1nn.txt August, 1994 - 9 - inetnum: 192.87.45.0 netname: RIPE-NCC descr: RIPE Network Coordination Centre descr: Amsterdam, Netherlands country: NL admin-c: Daniel Karrenberg tech-c: Marten Terpstra rev-srv: ns.ripe.net rev-srv: ns.eu.net notify: ops(a)ripe.net changed: tony(a)ripe.net 940110 source: RIPE route: 192.87.45.0/24 descr: RIPE Network Coordination Centre origin: AS3333 comm-list: SURFNET remarks: ias-int: 192.87.45.80 AS1104 remarks: ias-int: 192.87.45.6 AS2122 remarks: ias-int: 192.87.45.254 AS2600 changed: dfk(a)ripe.net 940427 source: RIPE The general idea is all routing based information is moved from attributes within the "inetnum" object to the "route" object (1). It is important to note the direct effect this have on the "inetnum" object data. Table 2 below gives a full list of the transitioned attributes. It should also be noted that in an effort to clean up the "inetnum" object at the same time certain attributes will be obsoleted. The effect column has an T for transitioned and an O for obsoleted. +------------------+--------+-----------------+ |inetnum attribute | effect | route attribute | +------------------+--------+-----------------+ |aut-sys | T | origin | |comm-list | T | comm-list | |ias-int | T | remark | |connect | O | | |gateway | O | | |routpr-l | O | | |bdrygw-l | O | | +------------------+--------+-----------------+ Table 2: Affected attributes As can be seen a simple translation can be made and this will be the _________________________ (1) The "ias-int" attributes are preserved as re- marks. See details of "inet-rtr" object for reasoning behind this. ripe-1nn.txt August, 1994 - 10 - last major transition step at time T2. 4.2. Auto-Generation of "Route" and New "Inetnum" objects Clearly, the transitioning of data will require a major flag day where the translation of attributes detailed in Table 2 takes place. This is expected to occur at big bang B2. At point B2 the RIPE NCC will automatically generate both new "route" and "inetnum" objects in line with Table 2 and load them into the RIPE database. It should be noted that these changes will only take place to "inetnum" objects with have an associated "aut- sys" attribute. All "inetnum" objects not containing the aut-sys attribute will have both T and O attributes removed. This may mean the potential loss of comm-list information if there is no corre- sponding aut-sys attribute for the existing "inetnum" object. Between time T1 and T2 the NCC will generate for each guardian account both the translated "inetnum" and "route" objects in the form of files known as: new.inetnum This file will contain a full list of "to be generated" "inet- num" objects. new.route This file will contain a full list of "to be generate" "route" objects. These files will be re-written every night and are purely given to give each guardian of what will happen to any associated object ref- erencing a guarded attribute after B2. The new "route" objects will be automatically split into CIDR [7] compliant aggregates. Below is a simple example of an automatic object split from the current "inetnum" to a new "inetnum" and "route" object. The original "inetnum" is as follows: inetnum: 193.12.128.0 - 193.12.132.0 netname: SE-COMVIS-NET descr: ComputerVision Sweden AB country: SE admin-c: Anders Andersson tech-c: Anders Andersson connect: SWIP aut-sys: AS1257 changed: uffe(a)swip.net 930707 source: RIPE ripe-1nn.txt August, 1994 - 11 - The will be translated to an new "inetnum" object as follows: inetnum: 193.12.128.0 - 193.12.132.0 netname: SE-COMVIS-NET descr: ComputerVision Sweden AB country: SE admin-c: Anders Andersson tech-c: Anders Andersson changed: uffe(a)swip.net 930707 source: RIPE Notice all attributes noted in Table 2 are now removed. The follow- ing two (yes two, because this entry was not CIDR [7] aligned) "route" objects are also generated: route: 193.12.128.0/22 descr: SE-COMVIS-NET origin: AS1257 mnt-by: AS1257-MNT changed: ripe-dbm(a)ripe.net 940829 source: RIPE route: 193.12.132.0/24 descr: SE-COMVIS-NET origin: AS1257 mnt-by: AS1257-MNT changed: ripe-dbm(a)ripe.net 940829 source: RIPE You also see that mnt-by attributes have been added to the "route" objects. This information has been derived from the "maintainer" files in each guardian account (see above for details of this). In this case the guardian of AS1257 named his maintainer object "AS1257-MNT". All other administrative attributes are preserved in both the "inetnum" and "route" objects which exception of the changed field which in the "route" object will just represent the At the time B2, you will also see both the new "inetnum" and "route" objects in the database. If "inetnum" entries are sent into the database with obsoleted attributes the entries will be accepted with the obsoleted attributes removed and a warning sent back indicating the obsoleted attributes have been removed. The auto-generation will happen at a set time at B2. This is a one- time operation and all users of the RIPE database should be aware of this major change. ripe-1nn.txt August, 1994 - 12 - 4.3. The "inet-rtr" object The "inet-rtr" object is an object which can be used to describe any router within an autonomous system [5]. This object can be used as of time T1. One important piece of the "inet-rtr" object is that it will replace the "ias-int" attribute used in the old "inetnum" object. We encourage all users of the "ias-int" attribute to regis- ter new "inet-rtr" object from time T1 onwards. In an effort to pre- serve any loss of "ias-int" information when the auto-generation of "route"'s and "inetnum"'s takes place the ias-int information will be included as a "remarks" attribute in the generated "route" object. Here is a simple example: route: 192.87.4.0/24 descr: EUR-IP origin: AS1755 remarks: ias-int: 192.87.4.17 AS1755 remarks: ias-int: 192.87.4.18 AS1103 remarks: ias-int: 192.87.4.19 AS2121 remarks: ias-int: 192.87.4.20 AS286 remarks: ias-int: 192.87.4.21 AS1104 remarks: ias-int: 192.87.4.22 AS1755 remarks: ias-int: 192.87.4.24 AS1103 remarks: ias-int: 192.87.4.35 AS1128 remarks: ias-int: 192.87.4.27 AS1890 remarks: ias-int: 192.87.4.28 AS3333 changed: ripe-dbm(a)ripe.net 940829 source: RIPE We realise this is non optimal and encourage the use of the "inet- rtr" object from time T1 onwards. 4.4. New "RIPE-81++" Syntax All proposed "ripe-81++" syntax will be accepted after B1 at time T1, with the exception of the changes to "inetnum" and "route" objects which will not be accepted until B2 at time T2 (see section "Auto-Generation of "Route" and New "Inetnum" objects" above for reasoning behind this). The direct effect of this is you will see different whois output. The most important aspect will be the addi- tion of syntactic sugar to the existing "as-in" and "as-out" attributes as well as the ability to use the attributes as well. To highlight this change if we look at a current "aut-num" object a whois query would produce the following: ripe-1nn.txt August, 1994 - 13 - aut-num: AS1104 descr: NIKHEF-H descr: Science Park Watergraafsmeer descr: Amsterdam, The Netherlands as-in: AS1103 100 AS1103 as-in: AS1890 100 AS1890 AS2004 AS288 as-in: AS1888 100 AS1888 as-in: AS2122 200 AS2122 AS2600 as-in: AS2600 100 AS2600 as-in: AS3333 100 AS3333 as-out: AS1103 AS1104 as-out: AS1890 AS1104 as-out: AS1888 AS1104 as-out: AS2122 AS1104 as-out: AS2600 AS1104 as-out: AS3333 AS1104 default: AS1103 100 guardian: ripe-op(a)nikhef.nl admin-c: Rob Blokzijl tech-c: Marten Terpstra remarks: peers with AS2122 and AS2600 are RR test peers notify: tony(a)ripe.net notify: marten(a)ripe.net changed: tony(a)ripe.net 940426 source: RIPE As of B1 the same query will produce: ripe-1nn.txt August, 1994 - 14 - aut-num: AS1104 descr: NIKHEF-H descr: Science Park Watergraafsmeer descr: Amsterdam, The Netherlands as-in: from AS1103 100 accept AS1103 as-in: from AS1890 100 accept AS1890 AS2004 AS288 as-in: from AS1888 100 accept AS1888 as-in: from AS2122 200 accept AS2122 AS2600 as-in: from AS2600 100 accept AS2600 as-in: from AS3333 100 accept AS3333 as-out: to AS1103 announce AS1104 as-out: to AS1890 announce AS1104 as-out: to AS1888 announce AS1104 as-out: to AS2122 announce AS1104 as-out: to AS2600 announce AS1104 as-out: to AS3333 announce AS1104 default: AS1103 100 guardian: ripe-op(a)nikhef.nl admin-c: Rob Blokzijl tech-c: Marten Terpstra remarks: peers with AS2122 and AS2600 are RR test peers notify: tony(a)ripe.net notify: marten(a)ripe.net changed: tony(a)ripe.net 940426 source: RIPE This is an important subtle change and anyone using tools should be aware of this change. To provide some backward compatibility it is possible to use the "-S" flag to the whois server to produce output without the added syntax information. A whois client supporting this flag will also be made available at B1. ripe-1nn.txt August, 1994 - 15 - 5. Visible Changes and Actions Required by User Group The effects of the B1/B2 changes and the actions needed by the dif- ferent groups of RIPE database users are summarised below. This is intended as a check list for members of those user groups. It should be noted most readers of this document will belong to more than one group. 5.1. Routing Registry Guardians This group comprises those who maintain the information in the Rout- ing Registry part of the database: "aut-num" and "community" guardians and guardian file maintainers. This group will see the most changes and need to take some actions. 5.1.1. Between now and B1 Action Change entries in guardian files to exactly match single database objects. 5.1.2. After B1 and before B2 Action Check and update the "mntner" objects generated in the guardian accounts, thus establishing a mapping between guardian files and "mntner" objects. Action Check the file of generated "route" objects and modified "inet- num" objects in the guardian account for errors and report those to the NCC. 5.1.3. After B2 Change Guardian file mechanism is no longer needed and disabled. Change Route objects created. Action Clean up guardian accounts. Action Align any locally stored objects with the split objects. Action Check "route" objects for remarks containing "ias-int" attributes and create "inet-rtr" objects where necessary. ripe-1nn.txt August, 1994 - 16 - 5.2. Local Registries This is the group who maintains "inetnum" objects. They will see the consequences of the "inetnum"/"route" split and will be able to use the new authorisation scheme. 5.2.1. Between now and B1 No changes or actions before B1. 5.2.2. After B1 and before B2 Change Now possible to store multiple "inetnum" objects covering the same address space at different levels. Change All representations decribed in [1] can be used for object sub- mission. Change New authorisation now available. Action Coordinate authorisation on objects maintained by more than one party. Action Prepare for "inetnum"/"route" split especially when storing data locally. Action Check "inetnum" objects for "ias-int" attributes and create "inet-rtr" objects where necessary. 5.2.3. After B2 Change Some attributes obsoleted and some moved to "route" object. Action Align any locally stored objects with the split objects. Action Stop submitting obsolete/moved attributes. 5.3. Maintainers of other Objects This group will basically only see added authorisation features and the need for coordination of this when multiple parties maintain an object. ripe-1nn.txt August, 1994 - 17 - 5.3.1. Between now and B1 No changes or actions before B1. 5.3.2. Change New authorisation now available. Action Coordinate authorisation on objects maintained by more than one party. 5.3.3. After B2 No changes or actions after B2. 5.4. Users of RIPE DB Information This is the group who queries the RIPE whois server and/or uses the database files. 5.4.1. Between now and B1 Action Check and adapt tools for the effects of B1: queries will return less specific matches if no exact match can be found. 5.4.2. After B1 and before B2 Change Network number queries can be classless and return less spe- cific matches if no exact match is found. Change Ability to obtain less and more specific matches on network number queries. Action Check and prepare tools for the effects of B2: "route"/"inetnum" split, obsoleted attributes, new attributes, syntactic sugar returned by default in "aut-num". 5.4.3. After B2 Change Effects of "route"/"inetnum" split will be visible. 6. Results The results from this three phase transition will the following ripe-1nn.txt August, 1994 - 18 - achievements. 1) A fully supported classless database (as of B1). 2) A new and improved authorisation and maintenance mechanism (as of B2). 3) Full support of ripe-81++ features (completed by B2 and most available from B1). As with any transition of this type some change of data is unavoid- able and a number of "big bang" days need to be factored in. How- ever, the end result is a clear improvement to both the RIPE alloca- tion and routing registry. Throughout the whole transition period the RIPE NCC will be available to make emergency changes to data if needed and deemed to be critical. All queries should be directed towards ncc(a)ripe.net. 7. References [1] Bates, T., Karrenberg, D., Terpstra, M., "Support for Classless Internet Addresses in the RIPE Database", DRAFT, May 1994. [2] Karrenberg, D., Terpstra, M., "Authorisation and Notification of Changes in the RIPE Database", DRAFT, Aug 1994. [3] Bates et al, "Representation of IP Routing Policies in a Rout- ing Registry (ripe-81++), DRAFT, August 1994. [4] Bates, T., "Support of Guarded fields within the RIPE Database", ripe-117, July 1994. [5] Bates, T., "Specifying an `Internet Router' in the Routing Reg- istry", DRAFT, July 1994. [6] Lord, A., Terpstra, M., "RIPE Database Template for Networks and Persons", DRAFT, May 1994. [7] Fuller, V et al, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC1519, Septem- ber 1993. [8] Karrenberg, D., "RIPE Database Template for Networks", ripe-050, April 1992. ripe-1nn.txt August, 1994

1 0

ripe-60 phased out
by Marten Terpstra 06 Sep '94

06 Sep '94

Folks, I have the pleasure to announce that as of tomorrow morning all occurences of boundary gateways and routing privileges will be removed from the RIPE database. This means that ripe-60 has finally been phased out completely. -Marten

1 0

2nd draft agenda for DB-WG in Lisbon
by Wilfried Woeber, UniVie/ACOnet 31 Aug '94

31 Aug '94

Dear folks, this is the *2nd* draft agenda for the Lisbon Database-WG meeting. Thanks for the input received so far! I tried to - slightly rearrange the individual items - key the topics indicating the type of activity expected - provide a list of references to have ourselves prepared :-) Any feedback appreciated! Wilfried. -------------------------------------------------------------------------------- 2nd Draft: Proposed Agenda for the DB-Working-Group at RIPE-19, Lisbon. ----------------------------------------------------------------------- 0. Opening (30') . appointment of scribe . amendment/rearrangement of agenda . any admin stuff I . review of DB-WG in the context of a changing RIPE x. The Classless Database (60') S . review of beta (as announced by Marten Terpstra) S . review of requirements and scheduled changes A . (ripe-clarep, ripe-inetnum) document review, and decision x. Database Operations Review (60') A . (ripe-auth) proposed guardian mechanism changes A . (inet-rtr) proposed router object review and decision A . RIPE-Handles (flag day?) I . any loose ends? (experiences) I . ownership of objects, update, coordination (Daniel Kalchev) I . need for new types of lookup/backlinks? (Havard Eidnes) x. Interworking with other regions (30') S . DB-Exchange (status) S . RWhois, aggrwalk, ... x. CLNS Routing Registry (10') A . status review and decision about further activities Z. AOB Key: I ... Informal discussion S ... review of Status, on-going A ... discussion and Approval requested Supporting documents: ftp://ftp.ripe.net/ripe/drafts/ripe-clarep.txt ftp://ftp.ripe.net/ripe/drafts/ripe-inetnum.txt ftp://ftp.ripe.net/ripe/drafts/inet-rtr.txt ftp://ftp.ripe.net/ripe/drafts/ripe-auth.txt (a "transition document" to be announced by the NCC) -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Wilfried.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

1st draft agenda for DB-WG in Lisbon
by Wilfried Woeber, UniVie/ACOnet 31 Aug '94

31 Aug '94

Dear folks, attached is the *1st* attempt on a draft agenda for the Lisbon Database-WG meeting. Due to the fact that I'll leave Vienna on Monday the 5th of September, I'd ask for comments, suggestions, etc. before Friday to allow for distribution of the next draft agenda to the ripe-list before Monday 5th. This draft is based on the assumption that (again) the ripe-81++ stuff will be reviewed by the Routing-WG (Jean-Michel?). Could the NCC people please point me to the items that need a decision in Lisbon (if any). I'd like to try for one more (and actually maybe for the last time) to get a WG scheduling agreed that allows active participation by a reasonable number of interested people to really facilitate consensus and decisions... Any feedback appreciated! Wilfried. -------------------------------------------------------------------------------- 1st Draft -- 1st Draft -- 1st Draft Draft agenda for the DB-Working-Group at RIPE-19, Lisbon. --------------------------------------------------------- 0. Opening (30') . appointment of scribe . amendment/rearrangement of agenda . any admin stuff . review of DB-WG in the context of a changing RIPE x. The Classless Database (60') . review of beta (as announced by Marten T.) . review of requirements and scheduled changes . document review (ripe-clarep, ripe-inetnum) . discussion and decision x. Database Operations Review (60') . potential guardian mechanism changes . RIPE-Handles . any loose ends? (experiences) . ownership of objects and update responsibility and coordination (Daniel K.) . need for new types of lookup/backlinks? (Havard E.) x. Interworking with other regions (30') . DB-Exchange (status) . RWhois, aggrwalk, ... x. CLNS Routing Registry (10') . status review and decision about further activities Z. AOB -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Wilfried.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 --------------------------------------------------------------------------

3 2

Testing classless database
by Marten Terpstra 30 Aug '94

30 Aug '94

Folks, As you may have guessed, we have put quite some work over the last few months into getting the RIPE database classless. We currently have a beta implementation running, with the idea that we will switch to this software shortly after the RIPE meeting. We would like you to have a look at the whois server we currently have running on my workstation rijp.ripe.net. If you have some time, please fire off some queries to this machine to see if the server responds like you would expect it to respond. A few things: - the new server is slightly slower than the current one. This mainly because of the classless lookups, and the fact that the database is no longer kept in one file, but seperate files per object type, each with their own index. Also the server uses data on a remote file system. - although the server supports more and less specific lookups for networks, the current client you may have will not support this. A new client will be given out as soon as this has been properly tested at the NCC. - you can now specify network lookups of the forms: 192.87.45.1 192.87.45.1/32 ie host addresses are recognized, and prefix/length lookups are recognized. The old style queries like "128.141" are still supported as well. - the default behaviour for network queries is that the server will give an exact match if available or the first less specific match for this query. So for host or subnet queries, the server will output the classful network mostly. - the test database is aligned with the real database for most of the data. We have also put in quite some test data like the ripe-81 routes and some inet-rtr objects. Please use this database only for testing, not for authoritative output. Because we are still working on all this, the new objects may sometimes show up and sometimes not. - we have also generated objects for the class C blocks that we have delegated to local IRs. So, for queries of non-assigned numbers, you should get the class C block they come out of. Basically we would like to get an idea from you that we have not changed the look and feel of the server in a way that may cause tools you may have that use the whois server to fail. If you find any problems, please direct them to me personally. Cheers, -Marten PS Please note you have to do: whois -h rijp.ripe.net <query> to get the new database software to respond.

1 0

Alternative nic-hdl reference syntax?
by Havard Eidnes 29 Aug '94

29 Aug '94

Hi, see the attached which contains my original question/suggestion and Tony's response. My main motivation for wanting this is to make it easier to see the references when a subset of the database is presented (without having to follow the nic-hdl cross-references). Such a superset might be an overview of all the objects a given person is registered as contact (either admin- or tech-) for. I have plans to make people more aware of the fact that they are registered as contacts and their roles and responsibilities in connection with this (e.g for the domain objects, where I have my own set of roles and responsibilities I want to make them aware of). I agree that what I am asking for is syntactic sugar, and that "pulling up" the names instead of the NIC handles in the objects could be done by my "database extraction" tool rather than having it implemented in the database. I do however not think that I myself had the idea for the syntax for the reference (in tech-c and admin-c), but I can't think of where I have seen it suggested before. This is merely to suggest the issue and not put too much pressure behind it; I can take "no" for an answer. Oh, yes, while on a bordering issue I probably should mention this (although it is beginning to deviate from the main issue in this letter, modify Subject line if you respond to this): The description of what kind of roles and responsibilities the contact persons are supposed to have are IMHO a bit imprecisely defined. This may be intentionally, but then again it may not. I personally would be happy with a better clarification on this point (I am referring to the descriptions in the documents ripe-50 etc., I'm sorry that I haven't kept track of whether the new database documents are out yet). - Havard

1 0

A summary of changes of RIPE-81++ from last RIPE meeting
by Tony Bates 26 Aug '94

26 Aug '94

This is the promised summary of changes of document to help focus discussion at the forthcoming RIPE meeting. URL: ftp://ftp.ripe.net/ripe/drafts/ripe-81++.changes.txt -- Text version URL: ftp://ftp.ripe.net/ripe/drafts/ripe-81++.changes.ps -- PS version --Tony. Summary of changes in RIPE-81++ from previous RIPE Meeting. Tony Bates 23rd August, 1994 1. Introduction In an effort to focus discussion for the forthcoming RIPE meeting in Lisbon in September I have made a brief outline of the changes to the RIPE-81++ draft from the last RIPE meeting. It is divided into two sections; basic and major changes. The major changes section will be most relevant for the forthcoming RIPE meeting and in par- ticular the RIPE routing working group. The latest RIPE-81++ draft is available from: URL: ftp://ftp.ripe.net/ripe/drafts/ripe-81++.{ps,txt} 2. Basic Agreed Changes This sections details the changes that were agreed and have been fully incorporated into the current draft of RIPE-81++. All the changes are with respect to the RIPE-81++ proposal tabled at the RIPE meeting in Amsterdam in May, 1994. In each case only very brief detail is given as these changes have been agreed by consensus. Network Lists. Add the use of network lists in the routing policy expression com- ponent. This will be in the form proposed by Merit. i.e. list of nets separate by commas within braces: { 35.0.0.0/8, 192.87.45.0/24 } Extension to "default" attribute There is a set of additional OPTIONAL components added to the default attribute. See RIPE-81++ for more details. - 2 - Syntactic SUGAR We added in the additional reserved words to make the syntax clearer. NOTE: the reserved words will all be in lower-case to dis- tinguish them from special policy keywords and communities. Here is a summary of current SUGAR to add and where. accept announce exclude from to transit Examples of the usage of the reserved words are: as-in: from neighborAS accept route as-out: to neighborAS announce route as-exclude: exclude ASpath to destination as-transit: transit ASpath to destination default: from neighborAS accept route default: to neighborAS announce route Note: that as-transit is an experimental attribute. See below. Network Representation We used the "prefix length" notation documented in the classless proposal paper. i.e. 35.0.0.0/8 192.87.45.0/24 "as-reject" changed to "as-exclude" The text remained the same. The name of the attribute changed. 3. Major Changes This section details the major changes with respect to the draft - 3 - presented at the RIPE meeting in Amsterdam in May, 1994. The "component" attribute is gone The component attribute was dropped as it was deemed to be too com- plex to understand and too difficult to maintain and guard. The out- come of this is two new attributes and one new object that facili- tate the functionality of the component attribute 1) withdrawn attribute Often is is useful to show a route that has been withdrawn from the routing table. The has become very important now that CIDR is deployed as service providers start to withdraw more specific routes from an aggregate. 2) hole attribute For tools in can be very useful to indicate "holes" in a CIDR aggregate where there is currently no expected connectivity. 3) inet-rtr object This allows you to detail the interfaces of a router as well as the AS the router belong to. This is extremely useful for routes/networks which fall into the category of what used to be called "inter-as networks" described by the proposed to be obsoleted "ias-int" attribute in the "inetnum" object. This object is described in: Bates, T., "Specifying an `Internet Router' in the Routing Registry", July, 1994. DRAFT. URL: ftp://ftp.ripe.net/drafts/inet-rtr.{ps,txt} The "interas-in" and "interas-out" attributes. This is an additional set of attributes added to detail local poli- cies between any two ASes which have more than one interconnecting link. This description is necessary only if the ASs are connected in more than one way and the routing policy and differs at these two connections. Example: LINK1 193.0.1.1 +----------+ 193.0.1.2 | | AS1------AS2== ==AS3-----AS4 | | 193.0.1.5 +----------+ 193.0.1.6 LINK2 - 4 - Descriptions of interas policies do not replace the global pol- icy described in as-in, as-out and other policy attributes which always describes the global policy between the two ASes. The interas-in/out attributes only specify local variations to the glo- bal policy described in the other attributes. If the global policy mentions more routes than the local policy then local preferences for these routes are assumed to be equal for all links. A simple extendable syntax has been defined for this additional information. For details of this refer to the ripe-81++ draft. Possible outstanding issues with interas-in/interas-out A major discussion point came from these attributes The ordering There were two styles of ordering proposed. A) interas-in: <my id> [from] ASxx <neighbor id> <pref> <pol- icy> B) interas-in: [from] ASxxx <my id> <neighbor id> <pref> <pol- icy> Fortunately, an executive decision has been made by the chair of the RIPE routing group to go with option B. The main reason behind this is for consistency with the as-in and as-out attri- butes. Clarification of evaluation of operators. Some text has been added to clarify the ordering of how the logical operators are evaluated in routing policy expressions and what they actually mean. It was recognised that ripe-81++ was weak on this point. This text is taken verbatim from the ripe-81++ draft: .... <routing policy expression> can take the following formats. 1. A list of one or more ASes, AS Macros, Communities or Net- work Lists. A Network List is a list of network numbers in prefix length format, separated by commas, and surrounded by curly brackets (braces, i.e. `{' and '}'). Examples: - 5 - as-in: from AS1103 100 accept AS1103 as-in: from AS786 105 accept AS1103 as-in: from AS786 10 accept AS786 HEPNET as-in: from AS1755 110 accept AS1103 AS786 as-in: from AS3333 100 accept {192.87.45.0/16, 128.141.0.0/16} 2. A set of KEYWORDS. The following KEYWORD is currently defined: ANY this means anything the neighbour AS knows. 3. A logical expression of either 1 or 2 above The current logical operators are defined as: AND OR NOT This operators are defined as true BOOLEAN operators even if the operands themselves do not appear to be BOOLEAN. Their operations are defined as follows: Operator Operation Example OR UNION AS1 OR AS2 | +-> all routes in AS1 or AS2. AND INTERSECTION AS1 AND HEPNET | +-> a route in AS1 and belonging to community HEPNET. NOT COMPLEMENT NOT AS3 | +-> any route except AS3 routes. Rules are grouped together using parenthesis i.e "(" and ")". The ordering of evaluation of operators and there associa- tion is as follows: Operator Associativity () left to right NOT right to left AND left to right OR left to right - 6 - NOTE: if no logical operator is given between ASes, AS- macros, Communities, Network Lists and KEYWORDS it is implicitly evaluated as an `OR' operation. The OR can be left out for conciseness. However, please note the opera- tors are still evaluated as below so make sure you include parentheses whenever needed. To highlight this here is a simple example. If we denoted a policy of for example; from AS1755 I accept all routes except routes from AS1, A2 and AS3 and you enter the following as-in line. as-in: from AS1755 100 accept NOT AS1 AS2 AS3 This will be evaluated as: as-in: from AS1755 100 accept NOT AS1 OR AS2 OR AS3 Which in turn would be evaluated like this: (NOT AS1) OR AS2 OR AS3 -> ((ANY except AS1) union AS2) union AS3) --> (ANY except AS1) This is clearly incorrect and not the desired result. The correct syntax should be: as-in: from AS1755 100 accept NOT (AS1 AS2 AS3) Producing the following evaluation: NOT (AS1 OR AS2 OR AS3) -> (ANY) except (union of AS1, AS2, AS3) Which depicts the desired routing policy. Note that can also be written as below which is perhaps somewhat clearer: as-in: from AS1755 100 accept ANY AND NOT (AS1 OR AS2 OR AS3)

1 0

More modification to RIPE-81++
by Tony Bates 24 Aug '94

24 Aug '94

Unfortunately, a couple of small changes needed to be made to the RIPE-81++ draft. The changes concern the semantics, ordering and associativity of the logical operators defined for the routing policy expression syntax. My thanks to Cengiz Alaettinoglu at ISI for pointing this out to me. The other change was to make the local-rid and remote-rid fields mandatory in the interas-in/interas-out attributes to avoid ambiguity in the syntax. This I hope to be the last change before the RIPE meeting. The latest draft is available as: URL ftp://ftp.ripe.net/ripe/drafts/ripe-81++.ps URL ftp://ftp.ripe.net/ripe/drafts/ripe-81++.txt I will not include a copy of the text this time ;-). Please also note I will send a very brief summary of changes document out on Friday to help focus discussion at the RIPE meeting. --Tony.

1 0