- db-wg - mailman.ripe.net

mnt-lower attribute not allowed?
by Schmitz＠rus.uni-stuttgart.de 04 Oct '96

04 Oct '96

Dear colleagues, yesterday I tried to apply the hierarchical authorisation scheme on route objects. However, I did not succeed. As an example, have a look at this: route: 193.174.0.0/15 descr: DFN-AGG-1 origin: AS1275 mnt-by: DFN-MNT mnt-lower: DFN-MNT changed: poldi(a)dfn.de 950907 changed: noc(a)noc.dfn.de 961001 source: RIPE password: ... resulted in: Update FAILED: [route] 193.174.0.0/15 route: 193.174.0.0/15 descr: DFN-AGG-1 origin: AS1275 mnt-by: DFN-MNT changed: poldi(a)dfn.de 950907 changed: noc(a)noc.dfn.de 961001 source: RIPE *ERROR*: attribute "mnt-lower" unknown in route object Is this just an error in typing (I took the same spelling as given in the RIPE database 2.0 workshop), or is hierarchical authorisation not done for route objects (in the workshop there was only an example for inetnum objects), or is it just not implemented yet? If it was implemented only for inetnum objects I do not see any reason why it should not be also possible for route objects. Could anybody please give a hint? Regards Joachim _____________________________________________________________________________ DFN Network Operation Center, Dr. Joachim Schmitz, (finger help(a)noc.dfn.de) >>>>>> mailto: noc(a)noc.dfn.de <<<<<< Rechenzentrum Universitaet Stuttgart, Allmandring 30, D-70550 Stuttgart Phone: 0711-685-5810, 0711-685-5576, FAX +711 6788363 (business hours) EMERGENCY phone +711 1319 139 with answering machine and pager _____________________________________________________________________________

4 3

Hierarchical Authorisation.
by RIPE Database Administration 02 Oct '96

02 Oct '96

Hi, Joachim ! Hierarchical authorisation is currently available for inetnum and domain objects. >From the HELP & HOWTO document: - You can protect against people *creating* (only creating) objects direct (one level) below in the hierarchy of an object type (only for 'inetnum:/domain:' objects) by using your maintainer in a 'mnt-lower:' attribute. The authorization method of this maintainer object will then be used upon creation of any object direct below the object that contains the 'mnt-lower:' attribute. This is also mentioned in the Release Notes of the new software. Hope this helps. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

1 0

More attributes for indexing?
by Steven Bakker 02 Oct '96

02 Oct '96

Hi folks, At the last RIPE meeting there was some discussion about which attributes would be useful to keep indices on. Well, since our office move last weekend, I came up with a (rather predictable) one: $ whois -i ad "Lockton House" % ignored attribute "address" since it is not indexed as a reference % no attributes specified for -i query $ _ Dang! It would be nice to have an index on address, although such an index might become veeerrrry large, due to the fact that you can specify multiple "address" attributes per object; dunno. Any thoughts? Cheers, Steven

4 3

Re: interesting person entry...
by Wilfried Woeber, UniVie/ACOnet 27 Sep '96

27 Sep '96

=> I personally feel that this should be done through the config file: give => every attribute a property of allowed empty lines or not. For example => 'remarks:' lines can be read easier when they may contain empty lines => while empty rev-srv: lines are useless. => I roughly agree about the approach, but see below. > Wilfried: I suggest a collection of all attributes should be analyzed > to see where empty lines are useful and where not. I currently do not > have an overview of all attributes but I feel that > - single ones > - attributes used as reference (e.g. tech-c) > - attributes necessary for administrative database purposes (e.g. changed > or source) > must not be empty (just as it came to my mind). Agreed. > I wonder how many > attributes might be left over which could carry empty lines. I feel that > the address attribute should not have empty lines. However, empty lines > could be useful as David noted on the remark attribute. I think all the lines where syntax checking is being done should *not* allow empty lines. To some degree I can see the usefulness of *single* empty lines within a *block* of attributes that allow free format text. Currently remark:, trouble:, and address: comes to my mind - and maybe a few more. But even then, the optical effect that is described can easily be obtained by e.g. putting a "." or "-" as the only character into the value field. I suppose that would remove some complexity from the software to support this "cosmetic sugar". Thus it would be my personal proposal to disallow empty lines altogether (empty in the sense of an attribute having no value supplied). Your input is very welcome, and yes, that could be put onto the draft agenda for RIPE-26 if there is no clear consensus or any strong 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 --------------------------------------------------------------------------

2 1

interesting person entry...
by Schmitz＠rus.uni-stuttgart.de 26 Sep '96

26 Sep '96

Dear colleagues, dear Ambrose, by accident I discovered a person entry which in its form is definitely not wanted: *pn: Stefan Seiz *ad: Herdweg 73 *ad: \ ... > 128 empty address lines!!! *ad: / *ad: 70174 Stuttgart *ad: Germany *ph: +49 711 18748-0 *fx: +49 711 18748-32 *em: index(a)schwaben.com *nh: SSE2-RIPE *ny: noc(a)ecrc.de *ch: wer(a)ecrc.de 951115 *so: RIPE I am in no position to decide whether the entry was done including these empty lines or whether this is an error of the database software. I think a check should be implemented during acceptance of new database objects (or updates) which - removes empty input lines (or fields which do contain nothing but white space) - afterwards checks whether all mandatory fields for the object are filled in should be done (actually I expect such a test to be performed anyway...) Could anybody please check what is wrong here? Thank you! Joachim _____________________________________________________________________________ DFN Network Operation Center, Dr. Joachim Schmitz, (finger help(a)noc.dfn.de) >>>>>> mailto: noc(a)noc.dfn.de <<<<<< Rechenzentrum Universitaet Stuttgart, Allmandring 30, D-70550 Stuttgart Phone: 0711-685-5810, 0711-685-5576, FAX +711 6788363 (business hours) EMERGENCY phone +711 1319 139 with answering machine and pager _____________________________________________________________________________

3 3

interesting person entry... (followup)
by Schmitz＠rus.uni-stuttgart.de 26 Sep '96

26 Sep '96

Dear colleagues, regarding empty input lines in the RIPE database: rubin$ egrep '^\*ad: *$' ripe.db.pn | wc -l 13442 rubin$ egrep '^\*..: *$' ripe.db.* | wc -l 15522 (with the database as of this morning around 2:10 am) I estimate this really should be changed... Regards Joachim _____________________________________________________________________________ DFN Network Operation Center, Dr. Joachim Schmitz, (finger help(a)noc.dfn.de) >>>>>> mailto: noc(a)noc.dfn.de <<<<<< Rechenzentrum Universitaet Stuttgart, Allmandring 30, D-70550 Stuttgart Phone: 0711-685-5810, 0711-685-5576, FAX +711 6788363 (business hours) EMERGENCY phone +711 1319 139 with answering machine and pager _____________________________________________________________________________

1 0

RE: RE: HELP! 'networkupdate', diskussion on short names of attributes
by Markus Bock 20 Sep '96

20 Sep '96

Hi all ! Contents: --------- 1. Thanksgiving for quick response 2. More about the problem with 'networkupdate' 3. Comments on short names of attributes 4. Comments on whois -i option 5. Question on destination for emails in 'RIPE DB' context 1. Thanksgiving for quick response ================================== At first I would like to thank - Wilfried Woeber, UniVie/ACOnet - Geert Jan de Groot, RIPE NCC - Carol Orange, RIPE NCC and specially - David Kessens who gave me quick response to my 'cry for help'. Thank you very much for your suggestions and for taking time to think about that problem with the 'networkupdate' client programm. Below you can read more about the progress in that case. And no, there is no reason to say sorry for a 'delayed response'. I'm pleased about your quick and helpful reactions. Thank you again! 2. More about the problem with 'networkupdate' ============================================= Below i repeat parts of David Kessens answer ... > Hi Markus, > > Markus Bock writes : > > > > For writing database front ends which manipulate and visualisize > > the stored data we want to use the 'networkupdate' program to > > have access to the database from different workstations via LAN. > This function is indeed present for this purpose. Yes, great. I think with the direct network update-method one has many potentialities to develope client-server based applications with a two task architecture like you see in the sketch below (just an example). ----------------- client-area | application | ----------- ----------------- | networkupdate | ----------------- | ^ v | communication drivers & protokolls // // network ======================================== \\ \\ // || VV communication drivers & protokolls | ^ v | ----------------- server-area | DB-server | ----------- | whoisd | ----------------- | | ----------------- / \ / \ ________ ___________ (________) (___________) | DB | | DB | | source | | source | | XXXX | | OWN | -------- ----------- > Maybe I make something wrong or this effect has something to do with > > running under Slowaris 2.5 ... ? > May be, may be not. Could you try the C version of networkupdate > (available from ftp.ripe.net/tools/whois-tools*) and see if the same > problem happens ? Yes I did it. The same problem happens NOT. I performed several tests with the C version and everything is working fine giving the estimated results. Just for information: --------------------- I had to do the following changes inside the makefile of the C versions of the ripe whois tools to compile it successful at our site under Solaris 2.5 with gcc: - define '-DSYSV' added - additional LIBS 'LIBS= -lresolv -lsocket -lnsl' added - changing the syntax to call install # install: ${PROG} # $(INSTALL) -c ${DESTDIR} -s -m 755 ${PROG} networkupdate # $(INSTALL) -c ${MANDIR}/whois.1 -m 444 whois.man > Could you try 'networkupdate -h whois.ripe.net'. You should get a message > back that tells you that you are not authorized to network updates. The > problem is problably in the client side of the software if you don't get > this message. Yes, I did it. - With the perl version I didn't received the message that tells me that I'm not authorized to do network updates. There is an analogical problem like I described in my 'cry for help'. 'networkupdate' terminates immediately. - With the C version I received the estimated message % ERROR: ***You are not authorized to do network updates***. With this results I agree with you that the problem is problably in the client side of the software. I tried to find out what is potentially wrong in the software by taking the examples for a client and a server from L. Walls camel book and comparing it with the RIPE DB SW (I assume that the same mechanisms are used by the RIPE DB SW). But I was still not able to change it in that way that these examples are able to handle the input of multiple lines (I'm not familar with 'command buffering or not' stuff) or to produce an analogical failure like decribed above. So I have no further result with this case. Has anyone tested the perl version of the networkupdate programm succesfully at his site ? If yes, in which enviroment (OS, version, HW etc.) ? > Please contact <ripe-dbm(a)ripe.net> and see if they can help you with > extra debugging code in the whoisd daemon/whois client to do a more > detailed trace of what is happening in the server software. Yes, thank you. I'll do it. > I hope this helps, > David K. > PS Please don't expect any fast responses right now since I am still busy > with moving & am not working yet. I have, however, already built a new > computer & got a ppp account at ISI so I am not completely > disconnected anymore ;-). Yes, thank you again. Your help enables me to go sucessfully on with my work. Also this gives me the opportunity to wish you success and good luck for your future at ISI. 3. Comments on short names of attributes ======================================== First: ------ While testing the RIPE DB for use to store own data objects I examined the following cases: Assume that you have to store 30 or more new database objects with about 300 (or more) new attributes in a (SPLIT) RIPE database (I already did it). Because you will have problems to find sensefull short names for attributes you use a numbering scheme like this: # DB-object dummy A1 ATTR A1 dummy_longname_1 ATTR A2 dummy_longname_2 ATTR A3 dummy_longname_3 # DB-object dummy A1 OBJ A1 ATSQ A1 A2 A3 OBJ A1 MAND A1 OBJ A1 MULT A2 A3 OBJ A1 UNIQ A1 OBJ A1 KEYS A1 Seems ok. *** But be careful. Don't use uppercase letters *** for naming database objects and attributes *** in a SPLIT database. The side effects are that at first everything is working fine (indexing, dbupdate updates via email etc.). The data will be stored correctly. But if you query the database via whois and whoisd you ever get the message that will be displayed if no match was found (have a look in your ripedb-config file). What happened ? After I had a look at the source code of the whoisd I think one can find the explanation in this section # sub findsplitdbs { # local(*keys, @preselection)=@_; # local(@searchdb)=(); # # print STDERR join(" ", keys %CLASSLESSDBS), "\n"; # @preselection=grep($CLASSLESSDBS{$_}, @preselection) if (scalar(grep(/^$VALIDPREFIXKEY$/o, @keys))==scalar(@keys)); # # # # and now we are going to do something really smart... # # and trickey things # local(@upperkeys)=@keys; # grep(tr/a-z/A-Z/, @upperkeys); # # # # see comment below why we need this # local(@tmpkeys,@tmpupperkeys); # local($tmp); and so on. I think that with this the software is not able to find the datafiles, i.e. which are named by this konvention /whereever/it/is/SOURCE.db.OBJECT /whereever/it/is/SOURCE.db.OBJECT.pag /whereever/it/is/SOURCE.db.OBJECT.dir where OBJECT is in uppercase letters. Does somebody agree with me ? Second: ------- Above I wrote about a problem to find sensefull short names if you have to store many new database objects with many (many) attributes. What you have at least for this is a two letter code with all alphabetic characters (in lowercase) and all digits. So you have (26+10) * (26+10) = 1296 (I hope it is correct...) possibilities for short names. This seems to be enough. But you have still the problem to find sensefull short names for a large amount of database objects and attributes. Maybe I see a problem 'where no problem is' but I can assume that in future even the RIPE database (if it will growth by objects and attributes) will reache the border finding sensefull names for short attributes. So my questions are: - Is it possible to use in future only the long names of attributes and objects or - needs this change too much manpower and time ? >From a view of data modelling I think the short names are redundant even if I know that from a view of implementing the database and writing code they are useful (i.e. for doing syntax checks). 4. Comments on whois -i option ============================== Wow ! I really like this option. If you have a somewhat clever data modelling you can realize something like a 'where clause' which is known from SQL. Another thing is that you can realize something like a 'join' over two database objects. You just have to play a little bit around with the 'KEY' and 'REC' terms inside the definition of your database objects. 5. Question on destination for emails ===================================== in 'RIPE DB' context ==================== I don't know if the database working group is the right address to report everthing in context RIPE database. Should one better report only for i.e. problems with implementation and porting the software directly to the database maintainer at RIPE NCC <ripe-dbm(a)ripe.net> ? and on the other side Should one better report only i.e. issues about the database concepts directly to the database working group ? Is there somewhat like a rule for this ? Thanks again ! have a nice day, Markus

2 1

FYI: List of current proposals
by davidk＠ISI.EDU 20 Sep '96

20 Sep '96

Dear all, This is my latest (and last) list of active proposals. There is still appears to be enough work for the new database maintainer(s) ;-). List of current proposals: 1) AUTO NIC handles (included in 2.00 release) 2) Role object (included in 2.00 release) 3) AS macro syntax 4) inverse lookup (included in 2.00 release) 5) whois -tv 6) referral mechanism 7) INADDR 8) NEW (included in 2.00 release) 9) stronger authorization 10) extended as-in 11) stored/processed attribute 12) name tag 13) url attribute 14) syntactic cleanup 15) WWW-WAIS-database interface 16) whois -H, cgi-bin behavior and HTML formatted output 17) reference exist check 18) don't delete referenced objects You can find a more detailed description below. Please let the new database maintainer(s) know if you know of any other proposals that I forgot about, Kind regards, David K. ---- 1) AUTO NIC handles: Auto assignment of NIC handles Current state: DONE Time estimation: long Syntax: nic-hdl: AUTO-#[Initials] where: # - is an arbritary identification number Initials - optional, advises the database software to use initials for the generation of the NIC handle. will cause NIC handles to be generated automatically. The number is needed to give the possibility for autogenerating and referencing more then one person object (that doesn't have a NIC handle yet) under every condition in one RIPE database update. AUTO is used as a prefix to avoid any confusion between real NIC handles and requests for auto generating NIC handles. Example: person: NIC Handle nic-hdl: AUTO-45NH [... stuff deleted ... ] person: Nick Hansson nic-hdl: AUTO-3NH [... stuff deleted ... ] inetnum: x.y.z.0 - x.y.z.255 admin-c: AUTO-45NH tech-c: AUTO-3NH [... stuff deleted ... ] Will assign a NIC handle with Initials NH and the first free number to 'NIC Handle' and NH and the next free number to 'Nick Hansson'. It will also fill these NIC handles in the right attributes of the objects. 2) New role objects Current state: DONE Time estimation: medium Syntax: The definition of the object: - name will be 'role:' - will have the same attributes as a person object - will have a 'tech-c:' and 'admin-c:' attribute - A NIC handle will be generated just as with person objects How to reference the object: - The object can be referenced from 'tech-c' and 'zone-c:' attributes only - recursive lookups go only one level deep 3) AS macro syntax New syntax for community and AS macros Current state: nothing done, need approval of the RIPE minutes first Time estimation: very short New syntax: community: Format: <string> The <stringmust satisfy the following constraints and the constaints for as macros (see below): + It must not start with the any upper or lower case permutations of the character "A" followed by the character "S". That is, the pattern "[Aa][Ss]" is not legal at the start of a community name. + It must not be the same as any of the routing policy expression keywords. (See RIPE-181, Appendix A for a complete list of these keywords.) It can expected that the keywords that the IETF Routing Policy System (RPS) working group defines for RPSL will be added to this list of keywords. as-macro: Format: AS-<string> The <stringmust satisfy the following constraints: + It must be at least two characters long. + It must contain only upper case letters, lower case letters, digits, or dashes (underscores (_) were dropped to avoid confusion between dashes and underscores) + It must start with a letter + It must end with a letter or digit All comparisons will be case insensitive. 4) inverse lookup Current state: DONE Time estimation: medium What is it? Inverse lookup makes it possible to find objects that match a certain key in a specified attribute. Example: whois -i admin-c,tech-c,zone-c DK13-RIPE gives all objects that have DK13-RIPE as their admin-c, tech-c or zone-c. 5) verbose templates/whois -tv Current state: data collection (from the RIPE documents) started Time estimation: short/medium, see note below Notes: - This will probably be a joint project with Merit. - The data collection part takes most time but is needed for some other projects anyway: We need documentation on all our objects for our own documentation, the RPSL IETF working group and future work to get the InterNIC and RIPE syntax synchronized. What is it? Verbose templates are meant to give more information on object templates then we give now. It is intended that 'whois -v -t inetnum' will give the syntax of the attribute (as with 'whois -t'), a short description of the attribute and a 'minimal' regular expression to give a better idea on how the attribute should look like. 6) referral mechanism Current state: No detailed proposal, nothing done Time estimation: short/medium Notes: This is not a agreed on proposal but is interesting to implement for experimenting with the topic, although it is of use for the community even in an experimental phase. More sophistacted designs might come up that will need much more time to implement and can be regarded as separate projects. What is it? We want to have an automatic referral mechanism that will make it possible that RIPE database objects refer to other whois servers and your client can then search that servers automatically. Example: domain: NL refer: WHOIS domain-registry.nl 7) INADDR reverse delegation integration with the RIPE database Current state: nothing done Time estimation: short/medium This proposal will allow for sending your reverse delegation requests directly to the RIPE database. The updated objects are sent to the reverse delegation robot after the update succeeded if a special keyword (INADDR?) is present in the Subject: line of your message. 8) NEW Current state: DONE Time estimation: short substitute the <auto-assign(a)ripe.netmail box by the keyword NEW in the update to the RIPE database. Only new objects will then be accepted for addition to the RIPE daatabase. 9) stronger authorization Current state: No proposals, nothing done, see note Time estimation: ??? Note: - Merit has a mechanism, but it is unclear if it is general enough and might need too much human intervention when dealing with a database as big as RIPE has. Also, import restrictions might disallow us to use Merit's code. No proposals on how to do this exactly are available right now. 10) extended as-in extended as-in/as-out attribute Current state: Proposal circulated, nothing done at RIPE, see note Time estimation: ???, but probably not too long if Brian Renaud's implementation is good. Note: - Brian Renaud (Merit) has made an implementation and has sent it in. I haven't had time to really look at it. It looks promising. Previous concerns that I had because this implementation required certain external tools seems like they have been addressed. What is it? See proposal by Cengiz Alaettinoglu <cengiz(a)ISI.EDUthat is circulated to the RPSL IETF working group mail list. 11) stored/processed attribute Current state: Proposal approved. Nothing implemented yet. Time estimation: short/medium What is it: Attributes added to all objects that contain a time-stamp and serial number. This allows for better knowledge on the history and age of objects. The attributes will also make the near real time mirroring more robust then it is now. In the future features like rolling back and forth to certain database states can be supported but need to be addressed in a separate project. A proposal has been circulated and appoved to the RIPE database working group. 12) name tag handle (Full name of person) data in tech-c/admin-c/zone-c attributes Current state: No detailed proposal has been made yet. Time estimation: short/medium (might be more complicated then expected right now) The proposal makes trouble shooting with disappeared person objects easier (esspecially when person might be located in a different database). The proposal als allows for non-recursive lookups in many cases when the user has enough info when seeing the name only. 13) url attribute Current state: No proposal yet Time estimation: short What is it? Attribute that can be used in any database object for references to any other site by using an url. No exact proposal has been made yet, but the idea seems to be very useful. 14) Syntactic cleanup Current state: Nothing done yet Time estimation: short/medium It is perceived by the user community as well as by the software developers for the routing registry that some of the syntax is unecessary complicated and/or makes more confusion then it solves. Therefore it was decided on the last RIPE meeting to remove the following features: - the ripe-181 line continuation will no longer be supported. People that used it will be asked to update their objects. - The syntactic sugar words will always be mandatory to avoid all kind of interesting problems (for example with deletions). The raw database file will also contain the syntactic sugar. We will announce this change long in advance to the proper lists to give people the chance to make changes to their software if necessary. 15) WWW-WAIS-database interface Current state: running implemention at GARR-NIS available Time estimation: medium What is it? Check out http://www.nis.garr.it/services/whois.html and select: 'Accesso via WAIS al servizio WHOIS' 16) whois -H, cgi-bin behavior and HTML formatted output Current state: design needs to be made Time estimation: short/medium What is it? There are already several whois client CGI scripts available, however many people believe that the HTML formatting could be done at the server side which allows for (more) consistent ouput for the users and immediate availability of new features. 17) reference exist check Current state: hooks are available in the code Time estimation: short/medium, see note below What is it? Checks if the references that are used in an object exist when doing a creation/update of an object. This is a missing feature that is mandatory in any decent database system. Note: a 100% safe check is very difficult to implement (for split databases) in the current code and will take considerable more time then the above estimate. However, the simple test will come very close to 100% and is considered to be enough for now. 18) don't delete referenced objects Current state: hooks are available in the code Time estimation: short/medium, see note below What is it? Checks if an object is referenced by other objects before deleting it. This is a missing feature that is mandatory in any decent database system. Note: a 100% safe check is very difficult to implement (for split databases) in the current code and will take considerable more time then the above estimate. However, the simple test will come very close to 100% and is considered to be enough for now. ========

1 0

proposal for inet-rtr obj extensions, for multicast, etc.
by Wilfried Woeber, UniVie/ACOnet 18 Sep '96

18 Sep '96

Dear all, (to complete a long-standing RIPE action and to make progress) please find below a modified version of a document (originally by Erik-Jan Bos) which then was describing a multicast router in a routing registry. This version proposes a more generalized approach and tries to discuss some implications, benefits and compatibility issues. It is up for discussion in the relevant RIPE working groups - in particular Routing, Mbone, (IPv6??) and DataBase. Of course any input and suggestions welcome! I would like to have your comments before and at the RIPE 25 Meeting, as well as on the mailing lists. Apologies for any rough edges, inconsistencies, omissins and typos. I'm sure we're going to change and improve this text (if this is at all perceived as a useful exercise) and before it could eventually become a RIPE Document. Best regards, 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 -------------------------------------------------------------------------- --- Start of document Generalized Description of Peering Relations in a Routing Registry Erik-Jan Bos, Wilfried Woeber Document ID: ripe-nnn September, 1996 [ adapted and extended from a previous proposal titled: ] [ ] [ A Multicast Router in the Routing Registry ] [ Erik-Jan Bos ] [ Document ID: ripe-nnn ] [ May, 1995 ] **** DRAFT ** WORK IN PROGRESS ** DRAFT **** ABSTRACT This document describes an extension and generalization of concepts as documented in ripe-122 (Specifying an "Internet Router" in the Routing Registry) by which it becomes possible to define peering relations in a very general way. This approach should in particular be understood to support documentation and debugging of "overlay networks" and regular routing protocol peerings at the same time. Originally this work was started to acommodate the description of a multicast capable Internet router within a routing registry. Comments and suggestions received at RIPE DB-WG sessions and private input led to the proposal to generalize the functionality. In addition to the inet-rtr specific attributes we propose the inclusion of a url: attribute, which is already proposed as an extension to all defined objects. 1. Introduction With the growing of the Mbone worldwide, managing the Mbone becomes a complex task. The multicast-bone is already suffering from problems that used to be present in the unicast-bone several years ago, such as routing coordination (and the lack of scoping of announcements). While the Mbone is currently a focus of interest, activity, growth and coordination efforts, we expect the general concept of an overlay network that needs routing coordination to become a general issue (e.g. IPv6 tunnels). Today, registries are available for administering policies and routes and routers [1]. Tools are availble [2,3] for checking and analyzing the real world against what is registered. The Mbone in particular, and other "overlay networks" in general, could and should benefit from these technologies coming from the unicast world. The features of the specification described in this document will be usable e.g. in the RIPE Data Base, after review by the RIPE Data Base WG. After implementation tools could be developed for mapping and analyzing the various different peering environments and/or overlay meshes. Furthermore, administrative details (such as contact person) and operational information (e.g. NOC info as described in role objects) are easily administered by well known procedures and become easily retrievable. Further discussion of the basic concepts led to the idea of generalizing this approach to cater for registering all sorts of peerings, with the dynamic exchange of routing information being a secondary issue. A long-term goal should be to provide the level of configuration and debugging support that is already available for maintaining external unicast routing to a broader range of routing domains. 2. Multicast routers versus unicast routers An "Internet Router" or a "gateway" in the current version of IP (IPv4) can be defined as follows [4]: "Gateways in the Internet form a cooperative, interconnected structure. Datagrams pass from gateway to gateway until they reach a gateway that can deliver the datagram directly." This definition can be applied to both unicast and multicast routers. Since both a unicast and multicast router are fulfilling the "Internet Router" function for different natures of traffic, there is no need for a special routing registry data base object. Moreover, both functions could be present in the same box. 3. A Router specification a multi-protocol router in the Internet Because an Internet Router - can perform different types of routing at the same time, e.g. . IP unicast routing . multicast routing using DVMRP tunnels or PIM . IPv4/IPv6 or "general purpose" tunnels - in many situations there are defined or potential interactions between the routing domains documentation of these facts should be possible in the routing registry. 3.1 A Simple Router Object, IPv4-only, Current Definiton Each router is uniquely defined by by its object name, also known as the fully qualified domain name. Below is an example of a internet router object, specifying a general purpose unicast router: inet-rtr: broodjeham.surfnet.nl localas: AS1103 ifaddr: 192.87.106.102 255.255.255.192 ifaddr: 192.87.4.99 255.255.255.0 peer: 161.53.2.1 AS2108 BGP4 admin-c: Erik-Jan Bos tech-c: Henk Steenman notify: netmaster(a)surfnet.nl changed: Erik-Jan.Bos(a)surfnet.nl 950505 source: RIPE Several pieces of important information are present in this object as described in ripe-122. First of all there is the FQDN of the router, acting as object name. The Home Autonomous System Number is shown, which (currently) is only meaningful in the context of external IP routing. Furthermore, the ifaddr:-lines show that this router has two interfaces, connected to two different networks, and the masks used on these networks. Finally the peer attribute records the IP (Version 4) address for an external BGP peering and lists peering specific information, eg. the localas: of the peer router (AS2108) and the type and version of the EGP used (BGP4). 3.2 A Router for IPv4 and DVMRP, extending the current structure For a moment, let us assume that this box is at the same time used as a multicast router and has a DVMRP tunnel configured. One of the approaches would be to define a dedicated attribute to describe this configuration, say mpeer: for multicast peering. The router object would then look like the following example: inet-rtr: broodjeham.surfnet.nl localas: AS1103 ifaddr: 192.87.106.102 255.255.255.192 ifaddr: 192.87.4.99 255.255.255.0 peer: 161.53.2.1 AS2108 BGP4 mpeer: 192.87.108.13 16 1 admin-c: Erik-Jan Bos tech-c: Henk Steenman notify: netmaster(a)surfnet.nl remarks: SURFnet Multicast router changed: Erik-Jan.Bos(a)surfnet.nl 950505 source: RIPE While all the previously defined and well-known attributes would remain unchanged, the newly invented mpeer: line would be used to describe a DVMRP peering and showing it's peer's IP address, the treshold and metric. Again, the format and interpretation of the entries beyond the IP (Version 4) address would be specific for that attribute. The advantage of that approach is that there is no need to change the definition of exiting attributes, which in turn preserves the functionality of any tools written to understand the specific information. However, there is a couple of major disadvantages when proceeding in that direction - the most important ones being that - the object's definition and schema has to be changed whenever a new attribute for a differnet kind of peering is proposed - frequent changes of the objects schema would lead to incompatible versions of the software - eventually having a sizeable number of different attributes for the various peerings leeds to congestion of the namespace for attribute tags and (probably) to confusion and errors on the human part of the system - and (maybe the most important thing) there is currently no way to describe peerings that do not use IPv4 addresses to identify the peer, e.g. IPv6 and some other protocols 3.3 The Generalization of the Peer Description Concept Because of these reasons given in 3.2 we propose to change the concept of the peering description to become more general and extensible by moving the peering protocol identifier into the first part on the line and deriving the format and meaning from that. Thus the example object used here would look like the following: inet-rtr: broodjeham.surfnet.nl localas: AS1103 ifaddr: 192.87.106.102 255.255.255.192 ifaddr: 192.87.4.99 255.255.255.0 g-peer: BGP4 161.53.2.1 AS2108 g-peer DVMRP 192.87.108.13 16 1 admin-c: Erik-Jan Bos tech-c: Henk Steenman notify: netmaster(a)surfnet.nl remarks: SURFnet Multicast router changed: Erik-Jan.Bos(a)surfnet.nl 950505 source: RIPE Changing the object's schema in that way raises the issue of backwards compatibility versus "cleanliness" (tools) and compatibility of possibly different versions of the software deploied at different registries. 3.4 Backwards Compatibility Discussion For the backwards compatibility we propose to define a new attribute g-peer, "generalized peering description", and eventually make the peer: attribute obsolete - as soon as the tools have been converted to understand the new format. The disadvantage is the coexistence and/or duplicate registration of BGP4 specific information in peer: and/or g-peer: lines. An alternate approach would be to stick with the peer: attribute for the BGP4 specific information and to specify all other types of peering in g-peer: attributes. While this may be an advantage in the short term, it might add complexity for the tools in the long run by requiring them to understand different attribute formats. For the different software version issue we propose to have the implementation treat any unknown peering type (and the rest of the line) as a remark. This situation should generate a warning at the time of registration or update, and there should probably a switch to instruct the software to suppress the warning or do more stringent tests. We specifically ask the maintainers of tools which are currently relying on the peer: attribute, and the RIPE- and Internet-Community in general, for guidance about these issues! All other attributes would remain as already defined for a routing registry [1]. See next chapter for the syntax definition and concepts for extension. 4. Multiprotocol Router Syntax Definition An object for a router capable of maintaining different routing protocol (or tunnel) peerings in parallel is defined here. Each of the possible attributes are shown, on a single line. The second column defines whether the attribute must be present [mandatory] of could be present [optional]. The third column defines whether exactly one line is allowed [single] or that more than one line of the same attribute is allowed [multiple]. In case an attribute has more lines than one, the name of the attribute must be repeated on each line. inet-rtr: [mandatory] [single] localas: [mandatory] [single] ifaddr: [mandatory] [multiple] peer: [obsolete] [multiple] g-peer: [mandatory] [multiple] admin-c: [mandatory] [multiple] tech-c: [mandatory] [multiple] notify: [optional] [multiple] remarks: [optional] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single] Each attribute has the following syntax: inet-rtr: The fully qualified domain name of the router. localas: The Autonomous System to which the router belongs. [Note: For the time being this is specific for the IPv4 external routing domain. It might even be useful to move that information to a g-peer: BGP4 entry?!] ifaddr: An interface IPv4 address of the router. [Note: the current draft of this proposal does not deal with necessary or desirable changes for IPv6.] peer: obsolete, potentially useful until RR tools are changed! g-peer: A peering of the router with another router, indicating the protocol and any protocol-specific information. [Note: please refer to the next section for the protocols being proposed in this draft and the proposed mechanisms for extension] Format: <protocol-ID> <peer address> <additional information> Examples: g-peer: DVMRP 192.87.108.13 16 1 g-peer: BGP4 161.53.2.1 AS2108 g-peer: IPv6-TUN IPv6-Address IPv6-specific Status: mandatory, multiple instances allowed. admin-c: Full name or uniquely assigned NIC-handle of a contact person for administrative matters. tech-c: Full name or uniquely assigned NIC-handle of a contact person for technical matters. notify: An e-mail address to which notifications of changes to this object should be send. remarks: Remarks or comments, for clarification purposes only. changed: The e-mail address and date of a change. source: Source of the information. 4.1 Discussion of Application Use of this approach has already been discussed for BGP4: g-peer: BGP4 <remote-peer address> <peer AS> example: BGP4 192.87.4.6 AS2122 localAS AS2121 or even g-peer: BGP4 <remote-peer address> <peer AS> [localAS <ASnumber>] DVMRP g-peer: DVMRP <remote-peer address> <metric> <thresh> example: DVMRP 192.87.4.6 192.87.108.13 16 1 IP-over-IP g-peer: IPv4-TUN <remote-peer address> example: IPv4-TUN 192.87.4.6 or g-peer: IPv6-TUN <remote-peer address> example: IPv6-TUN IPv6-Address 4.2 Extensions * t.b.s. * [ The gist of it should be that future extensions could be incorporated by simply editing a software configuratin file to define additional protocol types and supplying the syntax checking rules. To be discussed in more detail. ] 5. Acknowledgements This specification, being an addition to ripe-122, leans on the specification done by the author of ripe-122. Credits go to Tony Bates. Furthermore, the RIPE Mbone-WG has already done some reviewing of a previous version of this document and they receive credits as well. We are grateful for detailed suggestions received from David Kessens (ISI, then with the RIPE-NCC) and Steve Richardson (Merit). 6. Security considerations Security is not considered in this document. 7. References [1] Bates, Tony, "Specifying an Internet Router in the Routing Registry", ripe-122, October 1994. On-line at URL: ftp://ftp.ripe.net/ripe/docs/ripe-122.txt [2] PRIDE Tools Release 1. On-line at URL: ftp://ftp.ripe.net/pride/tools/pride-tools-1.tar.Z [3] Merit Inc. RRDB Tools. On-line at URL: ftp://rrdb.merit.edu/pub/meritrr [4] Douglas Comer, "Internetworking with TCP/IP", Prentice-Hall, 1988. ISBN: 0-13-470188-7. --- End of document --------------------------------------------------------------------------------

2 1

Fwd: Re: About db-wg minutes
by Wilfried Woeber, UniVie/ACOnet 18 Sep '96

18 Sep '96

Dear all ! As you might know, we lost the notes for the Berlin DB-WG meeting due to a nasty act of theft. So much for the hospitality of a university... I think (hope) that the notes provided by David Kessens have already been circulated. Unfortunately I'm under too much pressure these days to do a thorough investigation. Thus, just to make sure, here it is (again?). Thanks David ! See you next week in Amsterdam, Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I include below my draft for the minutes. Feel free to change them according to your personal needs (we talk later about the bribes), See you, David K. ---- Database Working Group Chair: Wilfried Woeber Scribe: Hans Petter Holen 1. Administrative stuff Hans Petter Holen volunteered to take notes on his notebook. However his notebook computer was stolen right before he was able to E-mail the minutes to the chairman. Therefore the minutes are reengineered as best as possible by Wilfried Woeber and David Kessens. The proposed WG-agenda was accepted. 2. DB-SW report David Kessens offered the traditional database software report. The slides of the presentation can be obtained from: ftp://ftp.ripe.net/ripe/presentations/ ripe-m24-david-DB-REPORT.ps.gz The database has grown by 25 % in 3 months time. A new more powerfull 1.1 version is ready although not published yet since it still lacks some small pieces before it can be released as a non-beta version. Most interesting new features in addition to the already known new features are: - Hierarchical authorization for the creation of 'domain:' and 'inetnum:' objects - the extended country attribute syntax is implemented - inetnum objects can finally be sent in prefix notation - line continuation with a '\' is supported - many changes to ease installation - many bug fixes The hierarchical authorization needed some decisions to be taken by the community on how the hierarchy of the objects would be defined: The following was decided: For 'domain:' objects: - creation of TLD domain objects need intervention of the RIPE NCC - the parent object is the biggest domain that still completely matches the domain of the object to be added. For 'inetnum:' objects: - objects can be created automatically if no parent object could be found For 'route:' objects: [ Wilfried, I need some help here, my notes are not clear ... ] No final decisions were made since all proposals had disadvantages - Do the authorization as specified in the 'mnt-by:' attribute in the origin AS of the route object. Problem: People can still create route objects with other origin ASs It seems that we need some more thinking before we can come up with a nice solution. Automatic NIC handle generation: A proposal was done with special keywords AUTO and a different syntax for more experienced users that would want to have a bit more control. It was perceived that this was unnecessary complicated. We finally found a solution that provides a single mechanism for dealing with all easy and more complicated cases: nic-hdl: AUTO-#[Initials] where: # - is a random number Initials - optional, advises the database software to use initials for the generation of the NIC handle. will cause NIC handles to be generated automatically. The number is needed to give the possibility for autogenerating and referencing more then one person object under every condition in one RIPE database update. AUTO is used as a prefix to avoid any confusion between real NIC handles and requests for auto generating NIC handles. Role objects We finally reached agreement on the role object. The definition of the object: - name will be 'role:' - will have the same attributes as a person object - will have a 'tech-c:' and 'admin-c:' attribute - A NIC handle will be generated just as with person objects How to reference the object: - The object can be referenced from 'tech-c' and 'zone-c:' attributes only - recursive lookups go only one level deep Finally we decided on a proposal by Cengiz to clean up some syntactic problems in the routing registry part of the software: - the ripe-181 line continuation will no longer be supported. People that used it will be asked to update their objects. - The syntactic sugar words will always be mandatory to avoid all kind of interesting problems (for example with deletions). The raw database file will also contain the syntactic sugar. We will announce this change long in advance to the proper lists to give people the chance to make changes to their software if necessary. 3. RADBServer report by Gerald Winters [ for wilfried or Gerald Winters <gerald(a)merit.edu>, his slides were not on the Merit ftp server ] 4. Extended syntax for communities and as macros [ Wilfried: please check the conditions, I was not sure if we decided on a minimal length of the string ] Recently Brian Renaud posted a proposal to the RIPE database working group on an extension of the possible characters that could be used for communties and as macros. Gerald Winters presented the proposal to the RIPE database working group and asked for input of the working group on some unresolved minor issues. The working group found consensus on the following new syntax: community: Format: <string> The <string> must satisfy the following constraints and the constaints for as macros (see below): + It must not start with the any upper or lower case permutations of the character "A" followed by the character "S". That is, the pattern "[Aa][Ss]" is not legal at the start of a community name. + It must not be the same as any of the routing policy expression keywords. (See RIPE-181, Appendix A for a complete list of these keywords.) It can expected that the keywords that the IETF Routing Policy System (RPS) working group defines for RPSL will be added to this list of keywords. as-macro: Format: AS-<string> The <string> must satisfy the following constraints: + It must be at least two characters long. + It must contain only upper case letters, lower case letters, digits, or dashes (underscores (_) were dropped to avoid confusion between dashes and underscores) + It must start with a letter + It must end with a letter or digit All comparisons will be case insensitive. The slides of the presentation can be obtained from: ftp://ftp.ripe.net/ripe/presentations/ ripe-m24-renaud-DB-syntax.ps.gz 5. www interface based on WAIS by Antonio Blasco Bonito Blasco presented a new user interface for the world wide web developed at GARR-NIS. The underlying technology was based on WAIS. The interface provides interesting features that are not possible with the current 'whois' or WAIS interface like looking up arbitrary strings but with a higher level of granularity then we are used to; per object type and OR'ed and AND'ed searches are possible. Furthermore, the software automatically detects URL's in the objects and generates a pointer to the site in the URL. The slides can be obtained from: ftp://ftp.ripe.net/ripe/presentations/ ripe-m24-bonito-DB-waisinterface.ps.gz The community expressed their interest in the interface and asked the RIPE NCC to implement this software as soon as possible even when the interface would not always be consistent with the layout of the new RIPE web interface. Carol Orange told that the RIPE NCC would try to integrate the interface with the new web site, but that the resources are very limited and that the interface would need to wait until the launch of the new RIPE website. 6. Review of active proposals and priorities David Kessens showed a slide on the proposals that were done in the past. Since the meeting was running out of time, it was then decided that David would send a list of active proposals to the mailing list and to provide a mechanism for the community to decide on the priorities. 7. AOB None. Meeting closed. List of new actions: Action 24.? on David Kessens Implement the automatic NIC handle assignment in the RIPE database with the syntax as decided as decided on during this working group session. Action 24.? on David Kessens Send a list of active proposals to the mailing list and provide a mechanism for the community to decide on the priorities --------------------------------------------------------------------------------

1 0