- db-wg - mailman.ripe.net

Re: FYI: List of current proposals
by Wilfried Woeber, UniVie/ACOnet 20 Jun '96

20 Jun '96

=> The basic obstacle that stopped me to make any progress is to find a => way (protocol, port, lookup key transfer mechanism) to query the db and => then to convince the browser to read the text as html. The best I => managed was gopher and interpretation as text. => Not that useful in the end... = =I want to do the following (as dicussed with you earlier in a private =conversation): = =Make a 'whois -w' that let the whois program behave as cgi-bin script: = =The whois server will return you an html formatted document instead of =regular plain text objects. It's then very easy to put such a 'whois' =program in your cgi-bin directory and here you go... The nice thing about =this the unified presentation of objects in a web based context. =Furthermore, people can use url's to specified objects in the database. Do I read this correctly to expect me (the users wanting access) to install some cgi script on the/a local server to provide that interface? That might drastically limit the usefulness of this approach. I'd prefer something that is more along the lines of the good old to be retired gopher interface - I'd like to give a special port number and have the script run at the whois DB server side. I think we do have all the building blocks in place (like telnet to 43), but this breaks 'cause a telnet opens a separate window from the browser and fails to submit the rest of the url to be treated as a lookup key. On the other hand I haven't had enough time and expertise to try to teach a browser about something like whois://db-server-FQDN:43/lookup-key >Example: > >An html document about the escalation procedures for network outages of >an ISP can point directly to a 'role:' object in the RIPE database. That's exactly one of the applications for that approach. Another one would be to have a domain object point to the URL for the application template. And another one would be to do a "whois help" to give access to documentation. And another to reference person objects for people being regularly updated in the DB... >Shall I add such a feature to my proposal list in addition to the WAIS >interface (with a note that the WAIS interface can be enabled quickly >with some hacks as proposed by Blasco) ? My private opinion is: YES. My DB-WG opinion is: probably, but we didn't have it on the agenda - thus as a proposal for future decision 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 --------------------------------------------------------------------------

3 2

Re: FYI: List of current proposals
by Wilfried Woeber, UniVie/ACOnet 20 Jun '96

20 Jun '96

Hi David ! => => What about the WWW/WAIS interface to the database? = =I will add it to the list. It probably slipped my mind (by my software =engineer perspective) since it is not part of the database software =itself, but a separate project. = =As far as me concerned, it is a very useful addition to the database =interfaces we already have and thus should be high on our priority list =(for the new website). I think that's 2 different issues: - WWW/WAIS access to the information contained in the DB That's probably a separate project that might need some finishing touches from the DB software engineer(s) - WWW/HTML/HTTP functionality in the DB-SW package and the whois-server and whois-client That's from my point of view part of the item to include/provide means to register URLs (in some way or another) in the DB objects. But registering the URL strings itself is not a major problem (we could use a remarks field for that porpose as an interim measure - look at spt1-ripe :-), but the *access* to the objects by way of an http or whois interface is! I haven't found a trick yet to make my browser process an object as html code... For the moment I'd like to concentrate my efforts on the second aspect! David, is there a chance to meet you during the IETF to share some drinks and thoughts? Wilfried.

4 3

Re: FYI: List of current proposals
by David.Kessens＠ripe.net 20 Jun '96

20 Jun '96

Dear Wilfried, Blasco, > Wilfried Woeber, UniVie/ACOnet writes : > > Hi Blasco ! > > => - WWW/HTML/HTTP functionality in the DB-SW package and the whois-server > => and whois-client > => > => That's from my point of view part of the item to include/provide > => means to register URLs (in some way or another) in the DB objects. > => But registering the URL strings itself is not a major problem (we > => could use a remarks field for that porpose as an interim > => measure - look at spt1-ripe :-), > => but the *access* to the objects by way of an http or whois > => interface is! I haven't found a trick yet to make my browser > => process an object as html code... > = > =It is anyway needed to reformat the DB object in HTML. That is exactly > =what the cgi-bin in our software does. We can cooperate to port > =this part of software in a different context (whois ?). > > How did you solve that? do you use plain vanilla whois towards the DB > and dish out html towards the browser? > > The basic obstacle that stopped me to make any progress is to find a > way (protocol, port, lookup key transfer mechanism) to query the db and > then to convince the browser to read the text as html. The best I > managed was gopher and interpretation as text. > Not that useful in the end... I want to do the following (as dicussed with you earlier in a private conversation): Make a 'whois -w' that let the whois program behave as cgi-bin script: The whois server will return you an html formatted document instead of regular plain text objects. It's then very easy to put such a 'whois' program in your cgi-bin directory and here you go... The nice thing about this the unified presentation of objects in a web based context. Furthermore, people can use url's to specified objects in the database. Example: An html document about the escalation procedures for network outages of an ISP can point directly to a 'role:' object in the RIPE database. Shall I add such a feature to my proposal list in addition to the WAIS interface (with a note that the WAIS interface can be enabled quickly with some hacks as proposed by Blasco) ? David K. ---

1 0

RE: FYI: David K. will be leaving the RIPE NCC
by Wilfried Woeber, UniVie/ACOnet 19 Jun '96

19 Jun '96

Hi David ! >Dear all, > >After working for nearly 2 years at the RIPE NCC, I feel it is time for a >change. I have found a new job at ISI (Los Angeles) where I will be >involved with the RA project. I will leave the RIPE NCC at the end of July. As I said previously in a private message, sometimes it's a pity staying behind at the wrong side of the pond... I don't want to add to Mike's general praise - he has worded it much better than I could. Instead I'd like to extend our thanks to you wearing my hat as the RIPE-DB-WG convenor. It was, and still is, a pleasure to work with you, both professionally and personally. All the best for your new position! I sincerely hope to keep in contact and to continue the successful collaboration as close as possible. Again - both personally and professionally! Cheers, 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

FYI: David K. will be leaving the RIPE NCC
by David.Kessens＠ripe.net 19 Jun '96

19 Jun '96

Dear all, After working for nearly 2 years at the RIPE NCC, I feel it is time for a change. I have found a new job at ISI (Los Angeles) where I will be involved with the RA project. I will leave the RIPE NCC at the end of July. As for the RIPE database: We currently plan to bring out the long expected 2.00 release version as soon as possible to keep some time left while I am still at the RIPE NCC in case problems arise. You can soon expect a message from me at the database working group maillist with all the open proposals (as promised during the last RIPE meeting). I would like to thank the RIPE community for their support of and input on my development work on the RIPE database and the reverse delegation tool. I hope that I will be able to collaborate as productively with you in my new job as we have in the past. Kind regards, David K. RIPE NCC ----

4 3

FYI: List of current proposals
by David.Kessens＠ripe.net 19 Jun '96

19 Jun '96

Dear all, I have completed the action point of the RIPE database working group to make a list of active proposals. 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 (included in 2.00 release, if the minutes are published) 4) inverse lookup 5) whois -tv 6) referral mechanism 7) INADDR 8) NEW 9) stronger authorization 10) extended as-in 11) stored/processed attribute 12) name tag 13) url attribute 14) syntactic cleanup You can find a more detailed description below. Please let me 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: half way done Time estimation: long, will be included in 2.00 release 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: half way done Time estimation: medium, will be included in 2.00 release 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, will be included in 2.00 release if the database workinggroup minutes are approved in time 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. 4) inverse lookup Current state: No proposal, nothing 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: nothing done Time estimation: short substitute the <auto-assign(a)ripe.net> mail 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 his implementation required certain external tools seems like they have been addressed What is it? See proposal by Cengiz Alaettinoglu <cengiz(a)ISI.EDU> that 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. Therefor 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. ========

2 2

Route Object Editor: New tool
by Cengiz Alaettinoglu 12 Jun '96

12 Jun '96

Hi, A new tool, roe (route object editor), is available: DESCRIPTION roe is a Tcl/Tk program that lists the routes registered by an AS. roe can be used to find discrepancies between the registered routes and the routes that are actually being routed. roe can be used to find all the holes that are punched in the AS's routes, or all the holes the AS punches in other routes. roe can be used to easily add, delete and update route objects in any IRR registry (hence the name editor). For example, one can register all the routes which are routed but not registered in couple of mouse clicks. It is part of RAToolSet v 3.3.2 and is available at: http://www.isi.edu/~cengiz/software Your feedback and bug reports are greatly appreciated. Thanks. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California http://www.isi.edu/~cengiz

1 0

Re: proposed extensions for as-macro, community names
by Wilfried Woeber, UniVie/ACOnet 11 Apr '96

11 Apr '96

=> Some issues which seem to require further discussion: => => <string> length => Should we require the <string> to be more than one character => long? That is, should as-macro names such as "AS-A" be => illegal? If we require more characters, how many more => should we require? Alternatively, we could rely on commun- => ity pressure to discourage meaningless names. Don't put "artificial" requirements into the softwre, please. Though we might eventually agree on some operational rules. => => ending characters => Should we require as-macro names to end in an alphabetic => letter or digit? That is, should names such as "AS-ISP_" be => illegal? Alternatively, we could rely on community pressure => to discourage such apparently badly formed names. => No preference - unless there is a *distinct* advantage in implementation to disallow certain character combinations. => case sensitivity => Should the comparisons of as-macro names be case insensi- => tive? That is, should the database software consider the => as-macro name AS-EBONE to be the same as the as-macro name => as-ebone? = =Pick something and let's move on to real problems. I think the whole package is non case sensitive right now. Any specific reason to change that? I'd prefer to stick with *not* being case sensitive. => [....] = =Same here. = =I'm don't favor syntax checking for asthetically pleasing names, but I =don't plan to use really ugly ones either. Go either way. :-) I agree, don't put "style" into syntax rules... 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

1st draft: proposed agenda - DB-WG at RIPE 24, Berlin
by Wilfried Woeber, UniVie/ACOnet 11 Apr '96

11 Apr '96

This is the 1st proposal of a draft agenda for the Database-WG at RIPE 24 in Berlin. **Message to the NCC WG scheduling department: If at all possible - please have the DB-WG meeting slot(s) scheduled near the end of the WG stream(s). Thank you! Apologies if I missed something obvious... As usual, comments, additions, deletions welcome. See you, Wilfried. PS: Please don't be disappointed if I don't respond for the next few days, I'll be back in the office by Sat.20.4. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Draft Agenda: Database-WG, RIPE 24, Amsterdam, NL ------------------------------------------------------ A. Administrative stuff - volunteering of the scribe - WG-agenda bashing B. DB-SW status report by the RIPE NCC - changes since RIPE 23 - experience with new features C. RADBServer report by Gerald Winters (Merit) D. Review of proposed changes in Europe and North America - active proposals - list of activities and/or implementation - priorities and/or resposibilty for development - coordination (if any :-) E. User interfaces - progress with WAIS integration Y. Input from other WGs Z. AOB Draft 1.0, 11-APR-1996, WW. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Re: update: minutes, DB-WG meeting, RIPE-23, Jan.96, Amsterdam
by M.H.Behringer＠dante.org.uk 11 Apr '96

11 Apr '96

>From the minutes: At 12:02 pm 21/3/1996, Wilfried Woeber, UniVie/ACOnet wrote: [...] > The Role: or NOC: object needs more thought and detailed definition. > There is still some uncertainty whether a full-blown new object (with a > handle) is really needed, or whether the person object can be extended. > Input was received from Michael H. Behringer that proposed a common > format for describing contact information, coverage and emergency > preocedures. This object is to be re-visited on the mailing list and a > decision about implementation is being sought on the list. [...] >Wilfried Woeber, Michael H. Behringer: To initiated discussion on the > mailing list about the need and possible format for a role: or > noc: object. I sent out mail on this on 8. March 96, proposing to implement the role object in the DB, because I think it is the "clean" way to implement e.g. AS objects with. My mail led to a true storm of follow-up mails; well, maybe not quite, there was one response from Joachim (thanks!). But as this response was definitely positive, I guess we can conclude that we had 100% agreement on this issue. :-) Can we therefore consider this matter decided? Michael

1 0

proposed extensions for as-macro, community names
by Brian Renaud 09 Apr '96

09 Apr '96

Hello all, I've enclosed below a document which proposes changes to the syntax for the as-macro and community names. I invite your comments. -Brian ================================================================= Proposed Modifications to AS Macro and Community Attribute Syntax ABSTRACT This document describes proposed modifications to the syntax of the as-macro and community attributes. This amends the as-macro syntax described in RIPE-181, Appendix C and the community syntax described in RIPE- 181, Appendix B. 1. Introduction Some ISPs would like to use longer names or structured names for their as-macro and community attribute values. They find these names difficult to read when they use only monocase alphabetic letters. (The syntax specified for these attributes in RIPE-181.) The following extensions to the RIPE-181 syntax provide a richer character set for these attributes. 2. AS-Macro Attribute 2.1. Syntax for as-macro Attribute The revised description and syntax for the as-macro is: as-macro: The name of a macro containing at least two Autonomous Sys- tems grouped together for ease of administration. Format: AS-<string> The <string> must satisfy the following constraints: + It must be at least one character long. + It must contain only upper case letters, lower case letters, digits, underscores (_) or dashes (-). + It must start with an upper case letter or a lower case letter. Note that all comparisons will be case insensitive, so that the database software will consider the as-macro "AS-EBONE" to be the same as the as-macro "as-ebone" 2.2. Examples: as-macro: AS-EBONE as-macro: as-ebone as-macro: AS-ISP-Backbone as-macro: AS-WEST_COAST_POP_1 2.3. Discussion Points Some issues which seem to require further discussion: <string> length Should we require the <string> to be more than one character long? That is, should as-macro names such as "AS-A" be illegal? If we require more characters, how many more should we require? Alternatively, we could rely on commun- ity pressure to discourage meaningless names. ending characters Should we require as-macro names to end in an alphabetic letter or digit? That is, should names such as "AS-ISP_" be illegal? Alternatively, we could rely on community pressure to discourage such apparently badly formed names. case sensitivity Should the comparisons of as-macro names be case insensi- tive? That is, should the database software consider the as-macro name AS-EBONE to be the same as the as-macro name as-ebone? 3. Community Attribute 3.1. Syntax for community Attribute The revised description and syntax for the community is: community: The name of the community. The name of the community should be descriptive of the community it describes. Format: <community-name> The <community-name> must satisfy the following con- straints: + It must be at least one character long. + It must contain only upper case letters, lower case letters, digits, underscores (_) or dashes (-). + It must start with an upper case letter or a lower case letter. + 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 pol- icy expression keywords. (See RIPE-181, Appendix A for a complete list of these keywords.) The keywords that the IETF Routing Policy System (RPS) working group defines for RPSL will be added to this list of keywords. Note that all comparisons will be case insensitive, so that the database software will consider the community WCW to be the same as the community wcw. 3.2. Examples: community: WCW community: ISP-Transit-1 3.3. Discussion Points Some issues which seem to require further discussion: community name length Should we require the community names to be to be more than one character long? That is, should community names such as "x" be illegal? If we require more characters, how many more should we require? Alternatively, we could rely on community pressure to discourage meaningless names. ending characters Should we require community names to end in an alphabetic letter or digit? That is, should names such as "ISP- Backbone_" be illegal? Alternatively, we could rely on com- munity pressure to discourage such apparently badly formed names. case sensitivity Should the comparisons of community names be case insensi- tive? That is, should the database software consider the community name WCW to be the same as the community name wcw?

2 1

Re: bug in the whois/wais query?
by zsako＠banknet.net 04 Apr '96

04 Apr '96

> From owner-db-wg(a)ripe.net Wed Apr 3 19:00:08 1996 Dear David, > > Janos Zsako writes : > > > > I have noticed a problem with a person called Matyas Matyas. > > I needed him in the RIPE database. I queried the database and got: > > > > whois -h whois.ripe.net "Matyas Matyas" > > person: Dedi Matyas > > address: RADCOM Ltd. > > address: 8 Hanechoshet St. Tel-Aviv 69710, Israel > > phone: +972 3 6472694 > > fax-no: +972 3 6474681 > > e-mail: dedi(a)radcom.co.il > > nic-hdl: DM55-RIPE > > notify: lir(a)NetVision.net.il > > mnt-by: NNCC > > changed: steiff(a)NetVision.net.il 960225 > > source: RIPE > > > > I therefore registered the following person: > > > > person: Matyas Matyas > > address: HotSoft Tirgu Mures - ROMANIA > > address: O.P. 1, C.P. 172 > > address: 4300 Tirgu Mures - Romania > > phone: +40 65 16 65 16 > > fax-no: +40 65 16 62 90 > > e-mail: matyi(a)hotsoft.vsat.ro > > nic-hdl: MM200-RIPE > > notify: ncc(a)banknet.net > > changed: zsako(a)banknet.net 960403 > > source: RIPE > > > > I queried the database in the same way and I got the same result as the first > > time! > > > > Therefore I suspected the person had been registered earlier and I queried > > the database with the WAIS option (through telnet info.ripe.net). > > I looked for the word "Matyas" and I got three results, one of them was the > > object below: > > > > person: Matyas Matyas > > address: HotSoft Tirgu Mures - ROMANIA > > address: O.P. 1, C.P. 172 > > address: 4300 Tirgu Mures - Romania > > phone: +40-65-166516 > > fax-no: +40-65-166290 > > e-mail: matyi(a)hotsoft.vsat.ro > > nic-hdl: MM184-RIPE > > changed: alina(a)u1.ici.ro 960326 > > source: RIPE > > > > and two irrelevant person objects, but the person with the NIC-handle > > MM200-RIPE was not there! > > I got a similar result with a different keyword ("matyi" from the e-mail > > address) and again got MM184-RIPE, but not MM200-RIPE. > > > > Is this normal (did I miss something) or is this a bug? > > (I see two different problems which might have the same cause: > > - why does the whois not give me both MM184-RIPE and MM200-RIPE as an answer to > > the 'whois -h whois.ripe.net "Matyas Matyas"'? > > - why does the WAIS not give me the person object MM200-RIPE? > > ). > > > > I could explain however the behaviour of the WAIS query by the fact that it > > does not search the "real" database, but a copy of it, which is updated in > > bigger chunks. Is this the explanation for the second problem? > > Correct, WAIS gets updated only once a day. We can should be able to see > the object tomorrow. > > > I find no explanation for the first problem though... > > I think that we are dealing with a 'feature' and possibly a bug (I need > to investigate this in more detail to be sure). > > The database uses the following algoritm to find an object: > > - break up the search key on space boundaries: > > Matyas Matyas ----> (Matyas, Matyas) Thank you for your detailed answer. I think I have now better delimited the problem, which seems to be a _bug_ also after the explanation you gave. Based on your description of the algorithm I would definitely assume that the result of the query whois -h whois.ripe.net "Matyas Matyas" should be the same as the result of the query whois -h whois.ripe.net Matyas Am I correct? The problem is that they are NOT the same! The correct result is provided only by the second query. :( The first one _excludes_ only the correct answers, instead of _returning_ only those values? This looks like a condition written in a negated form... Best regards, Janos > > - Then it looks for objects that match the keys > > Dedi Matyas (Dedi, Matyas) > > Example: > > Matyas -> 3,5,10 > Dedi -> 5 > > - It returns the objects that are pointed by all the keys (not one of > them) but ignores keys that don't reference anything: > > Thus a query for: > > Matyas Matyas > > will give you back any objects that have a Matyas key (objects 3,5,10) > > and > > Dedi Matyas > > will give you object 5 (not 3 & 10) > > > It looks like the database gives consistent output except for the > following case: > > $ whois -r Matyas Matyas > > person: Dedi Matyas > > because the above described algoritm should give you all objects that have > a key Matyas and should give the same result as the following query: > > $ whois -r Matyas > > person: Dedi Matyas > ... > person: Matyas Matyas > ... > person: Matyas Matyas > ... > > > I made some completely new code for this part of the RIPE database in my > own time but it is far from production quality but the problem is on the > list (This code also solves the 'too many hits' problem for people with > very common first and last names). > > Note that it is recommended to do your first search with a not too refined > key: You cannot always be sure that people that registered a person had > the same idea of the first name of a person (only initials, full name). > > Thanks for noticing and informing me of this problem. It will certainly > be looked into, > > Kind regards, > > David Kessens > RIPE Database maintainer > ---- >

2 1

bug in the whois/wais query?
by zsako＠banknet.net 03 Apr '96

03 Apr '96

Hello, I have noticed a problem with a person called Matyas Matyas. I needed him in the RIPE database. I queried the database and got: whois -h whois.ripe.net "Matyas Matyas" person: Dedi Matyas address: RADCOM Ltd. address: 8 Hanechoshet St. Tel-Aviv 69710, Israel phone: +972 3 6472694 fax-no: +972 3 6474681 e-mail: dedi(a)radcom.co.il nic-hdl: DM55-RIPE notify: lir(a)NetVision.net.il mnt-by: NNCC changed: steiff(a)NetVision.net.il 960225 source: RIPE I therefore registered the following person: person: Matyas Matyas address: HotSoft Tirgu Mures - ROMANIA address: O.P. 1, C.P. 172 address: 4300 Tirgu Mures - Romania phone: +40 65 16 65 16 fax-no: +40 65 16 62 90 e-mail: matyi(a)hotsoft.vsat.ro nic-hdl: MM200-RIPE notify: ncc(a)banknet.net changed: zsako(a)banknet.net 960403 source: RIPE I queried the database in the same way and I got the same result as the first time! Therefore I suspected the person had been registered earlier and I queried the database with the WAIS option (through telnet info.ripe.net). I looked for the word "Matyas" and I got three results, one of them was the object below: person: Matyas Matyas address: HotSoft Tirgu Mures - ROMANIA address: O.P. 1, C.P. 172 address: 4300 Tirgu Mures - Romania phone: +40-65-166516 fax-no: +40-65-166290 e-mail: matyi(a)hotsoft.vsat.ro nic-hdl: MM184-RIPE changed: alina(a)u1.ici.ro 960326 source: RIPE and two irrelevant person objects, but the person with the NIC-handle MM200-RIPE was not there! I got a similar result with a different keyword ("matyi" from the e-mail address) and again got MM184-RIPE, but not MM200-RIPE. Is this normal (did I miss something) or is this a bug? (I see two different problems which might have the same cause: - why does the whois not give me both MM184-RIPE and MM200-RIPE as an answer to the 'whois -h whois.ripe.net "Matyas Matyas"'? - why does the WAIS not give me the person object MM200-RIPE? ). I could explain however the behaviour of the WAIS query by the fact that it does not search the "real" database, but a copy of it, which is updated in bigger chunks. Is this the explanation for the second problem? I find no explanation for the first problem though... In case I missed something please excuse me for polluting your mailbox and taking your time... Best regards, Janos PS. I will delete the person MM200-RIPE next week, but I want to leave it there for the moment in case somebody wishes to investigate the problem.

2 1

new bug fix release of prtraceroute
by David.Kessens＠ripe.net 28 Mar '96

28 Mar '96

Hi all, After getting tired of the requests why prtraceroute didn't do what people hoped it should do, I fixed some of the bugs... (and found some new ones). It's highly recommended to upgrade since this release also does a better job in skipping funny modern objects that caused the impression that the whole Internet was in AS1800... and yes the software runs with perl5 now. The code is available from: ftp://ftp.ripe.net/pride/tools/prtraceroute-2.0beta4.tar.gz If you have any further questions, please don't hesitate to contact me again, Kind regards, David Kessens ---- New in 2.0 BETA 4 1. new quad2int routine due to perl5 problems with bit shifts and some other minor perl5 fixes This version is supposed to work with perl5 now Note that the other PRIDE tools don't!!!! 2. removed hardcoded SOCKSTREAM (for Solaris) and port value 3. The tool skips now route objects with origin=AS0 4. The tool skips now route objects with prefix 'x.x.x.x/0-5' 5. The inet-rtr lookup works again (did nobody notice that the RIPE whois server doesn't support use of two '-T' options...) 6. More robust code for interfacing with different versions of traceroute. Note that more robust doesn't mean good code, there is still some work left... 7. The AS macro expansion didn't work with AS lists that contained other AS macros 8. The policy evaluator had a bug which has been worked around. ------

1 0

update: minutes, DB-WG meeting, RIPE-23, Jan.96, Amsterdam
by Wilfried Woeber, UniVie/ACOnet 21 Mar '96

21 Mar '96

This is the updated minutes of the RIPE-23, Jan.96, DB-WG meeting. Corrections submitted by David Kessens wrt "network updates" and "security" have been included. Best regards, Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Draft Minutes: Database-WG, RIPE 23, Amsterdam, NL ------------------------------------------------------ 0. Administrative stuff Kurt Kayser, ECRC, volunteered to take notes. The WG meeting was split into two sessions - part 1 to deal with currnt topic, problems and ideas - part 2 the more traditional stuff The proposed WG-agenda was accepted. 1. Databases and registries B. Manning's review of the 192.0.0.0/8 address range prompted a brief discussion of where the authoritative information should be maintained. The general feeling was that networks used in Europe should be documented in the RIPE-DB. [ A comment was received after the WG-meeting to ask the Internic (and other registries?) to expand the standard referral text ("The InterNIC Registration Services Host contains...") to include pointers to the RIPE-DB and maybe other registry sources. ] From the user's point of view it would be very convenient to send updates to a "local" database and have the software forward the message(s) to the appropriate database(s) according to the source: attribute. Currently the RIPE-NCC holds copies of the following databases: RA, MCI, APNIC, CA*Net - but NOT the InterNIC. While things are to improve with the introduction of the shadow-dbs, mirror copies are always sort of out-dated by definition. RIPE intends to have a 10min delay. Other problems identified: - uniqueness of names / keys across different databases - lookup and processing of entries from more than one DB (e.g. evaluate AS-Macros from different DB...) -> minority problem for the time being. - quality control on information, . like duplicate entries alert, . automatic handle assignment, . semantics for more than one person object for a given individual . Registry ID information is maintained manually, this might change by building links to objects in the public database. 2. User interface(s) - access to the data in a more clever (selective) way by WAIS and/or WWW. A. Blasco Bonito and Paolo Bevilacqua have a test-version available for a WWW interface that supports logical AND and OR of keys. - whois "help" gives on-line documentation hypertext version being considered - An on-line survey form is available via the RIPE-NCC web pages, you are invited to use it to describe your wishes for access to data kept at the RIPE-NCC. - RADB/Merit has a web interface for queries and updates, although this obviously works for auth: NONE or MAIL-FROM only - proposal: put a pointer to whois "help" into ripe-104++ 3. Authorization and Security DFK reports that development work is on the action list (PGP facilities to be integrated) but there is still a severe lack of resources. Additional help is needed to make real progress, because design work is necessary first. Th Key management would most probably be done according to the Merit approach. We might benefit from (Euro-)CERT activities? In more general terms, if we want to see development progress faster than in the past, then we have to come up with clearly defined needs and a proposal for a devlopment project with additional resources. 4. DB-SW report David Kessens offered the traditional database software report. The slides can be obtained from ftp://ftp.ripe.net/ripe/presentations/ripe-m23-david-DB-REPORT.ps.gz Another set of slides for the In-Addr-Check handling is available from ftp://ftp.ripe.net/ripe/presentations/ripe-m23-david-DNS-INADDRCHECK.ps.gz - beta version V1.1 that allows (close to) real-time mirroring is available. At the time of writing these minutes (4-MAR-1996) the distribution is at ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-1.1beta2.tar.gz - requests to run a mirror copy are to be sent to ripe-dbm(a)ripe.net - other changes include . support for the BSD DB package . a password controlled mechanism to overrule normal security mechanisms (e.g. for adding maintainers and the like) . "network updates" are now fully supported by the RIPE-DB SW. Fully supported means: "If your address is in the RIPE-DB access list" However, this is a very powerful method and currently does not provide enough data for the logs to track down problems. For further study, before being made available to the community at large. . less memory consumption In conjunction with the mirror capability, the software has to keep track of individual object creations and updates. The mechanism that is currently used is not suitable for long-term consistency (because the sequntially increasing values are expected to suffer from wrap-around, eventually). Thus a stored: attribute was proposed and accepted. stored: <NEW | UPD> <Date> <Time> <Serial> Inclusion of the authorisation method used and the source of the update was then asked for. DFK is going to circulate a detailed proposal. In general the NCC proposes to use a keyword based mechanism on the subject: line of DB update messages to request special processing. This should eventually obsolete the multiple e-mail addresses, like auto-assign(a)ripe.net, which are not widely known and their use is not always properly enforced. 5. Hierarchical authorization Implementation of hierarchical authorization is initially planned for . domain name space . IP-Address-Ranges for registries . origin AS for routes Moving the description of the hierarchy and the transactions allowed at a particular level to a maintainer object was preferred over an alternate method of using a scope: attribute. 6. Handles, Object review Eventually the assignment of NIC-Handles (more precisely: RIPE handles) is being implemented. David shall circulate a propsal about the logic and the semantics to the mailing list. Reverse lookup (for person objects, at least) is being worked on. The country: attribute is being redefined to allow multiple lines with multiple values, to better reflect the real scope of an entity (like address blocks from a regional registry, AS numbers, etc.) The Role: or NOC: object needs more thought and detailed definition. There is still some uncertainty whether a full-blown new object (with a handle) is really needed, or whether the person object can be extended. Input was received from Michael H. Behringer that proposed a common format for describing contact information, coverage and emergency preocedures. This object is to be re-visited on the mailing list and a decision about implementation is being sought on the list. The proposal for an extension of the inet-rtr: object was briefly discussed. The original intent was to allow for a description of Mbone routers. However, extending the concept could be very useful for describing all sorts of peerings, like Mbone, IP-over-IP, IPnG, and the like. Due to the fact that there is already a couple of tools which read the peer: attributes, it might be wise to not change the peer: attribute as currently defined (but to eventually make it obsolete) and to invent a new attribute with the peering protocol ID as the first element, the address as the second element and then the specific information. To be discussed in more detail on the mailing list. url: it was agreed to add a new (optional) attribute to all objects to allow for inclusion of URLs. The details to be worked out after some more tests. Format could either be plain HTML or general URI syntax. 7. Input from other WGs Already covered (see inet-rtr: for Mbone) 8. AOB None. Meeting closed. ________________________________________________________________________________ List of new actions: Daniel Karrenberg: To circulate a detailed proposal for the stored: attribute. David Kessens: To circulate a detailed proposal for the automatic handle assignement. Wilfried Woeber, Michael H. Behringer: To initiated discussion on the mailing list about the need and possible format for a role: or noc: object. Wilfried Woeber: To initiated discussion on the mailing list about the extension of the inet-rtr: object. WW, 21.3.96

1 0

RE: polling for ripe dbase software changes (fwd)
by Wilfried Woeber, UniVie/ACOnet 19 Mar '96

19 Mar '96

Hi Cengiz, hi David! >We would like to hear the opinion (positive or negative) of the RIPE >database working group on the following proposals *before* changes are >made to any of the RIPE database implementations. We might want to >discuss things at the RIPE database working group session at the next >RIPE meeting in Berlin. Well, before I can develop an opinion, I'd be interested in the motivation and/or expected benefits for the proposed modifications. My first *feeling* (note, nothing more than a feeling!) is that things that belong to an external representation and a user interface should not be part of the data stored in some database. Another aspect might be multi-language support. Of coure, you can translate the syntactic sugar into syntactic salt :-) BTW, my feeling (again) with regard to the continuation stuff is that it might make sense to improve things. As it stands right now, it is not really simple to comprehend (for humans). Give me more input, then I can make up my mind. Best regards, Wilfried.

2 1

polling for ripe dbase software changes (fwd)
by David.Kessens＠ripe.net 19 Mar '96

19 Mar '96

Dear all, We would like to hear the opinion (positive or negative) of the RIPE database working group on the following proposals *before* changes are made to any of the RIPE database implementations. We might want to discuss things at the RIPE database working group session at the next RIPE meeting in Berlin. Kind regards, David Kessens RIPE NCC ---- > Cengiz Alaettinoglu writes : > From owner-rr-impl Wed Mar 13 20:11:16 1996 > Date: Wed, 13 Mar 1996 11:12:08 -0800 > Posted-Date: Wed, 13 Mar 1996 11:12:08 -0800 > Message-Id: <199603131912.AA16151(a)cat.isi.edu> > From: Cengiz Alaettinoglu <cengiz(a)ISI.EDU> > To: rr-impl(a)ripe.net > Subject: polling for ripe dbase software changes > X-Organisation: USC / Information Sciences Institute > X-Phone: +1 (310) 822 1511 x219 > X-Fax: +1 (310) 823 6714 > > > Hi folks, > > RA is considering: > 1) for db-update to bounce back objects which uses ripe-181 style > line continuations as error. > 2) making the sugar words mandatory on as-in/out, i.e. from to > announce accept. > 3) not deleting these sugar words from the objects while storing them > into the database file (and not reinserting them on whois). > > We would like to know, if there is a strong opinion against > this. Particularly, we would like to know if things would break in > your site if we did this. > > Thanks. > > Cengiz > > -- > Cengiz Alaettinoglu Information Sciences Institute > (310) 822-1511 University of Southern California > http://www.isi.edu/~cengiz

2 1

draft minutes, DB-WG meeting, RIPE-23, Jan.96, Amsterdam
by Wilfried Woeber, UniVie/ACOnet 11 Mar '96

11 Mar '96

This is the draft minutes of the RIPE-23, Jan.96, DB-WG meeting. Better late than never :-( Apologies for the excessive delay. Many thanks to Kurt Kayser from ECRC Munich, for taking notes - all the typos are mine... In order to make the minutes more consistent, the sequence of the discussion is not accurately preserved for all aspects. Any additions, clarifications appreciated! Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Draft Minutes: Database-WG, RIPE 23, Amsterdam, NL ------------------------------------------------------ 0. Administrative stuff Kurt Kayser, ECRC, volunteered to take notes. The WG meeting was split into two sessions - part 1 to deal with currnt topic, problems and ideas - part 2 the more traditional stuff The proposed WG-agenda was accepted. 1. Databases and registries B. Manning's review of the 192.0.0.0/8 address range prompted a brief discussion of where the authoritative information should be maintained. The general feeling was that networks used in Europe should be documented in the RIPE-DB. [ A comment was received after the WG-meeting to ask the Internic (and other registries?) to expand the standard referral text ("The InterNIC Registration Services Host contains...") to include pointers to the RIPE-DB and maybe other registry sources. ] From the user's point of view it would be very convenient to send updates to a "local" database and have the software forward the message(s) to the appropriate database(s) according to the source: attribute. Currently the RIPE-NCC holds copies of the following databases: RA, MCI, APNIC, CA*Net - but NOT the InterNIC. While things are to improve with the introduction of the shadow-dbs, mirror copies are always sort of out-dated by definition. RIPE intends to have a 10min delay. Other problems identified: - uniqueness of names / keys across different databases - lookup and processing of entries from more than one DB (e.g. evaluate AS-Macros from different DB...) -> minority problem for the time being. - quality control on information, . like duplicate entries alert, . automatic handle assignment, . semantics for more than one person object for a given individual . Registry ID information is maintained manually, this might change by building links to objects in the public database. 2. User interface(s) - access to the data in a more clever (selective) way by WAIS and/or WWW. A. Blasco Bonito and Paolo Bevilacqua have a test-version available for a WWW interface that supports logical AND and OR of keys. - whois "help" gives on-line documentation hypertext version being considered - An on-line survey form is available via the RIPE-NCC web pages, you are invited to use it to describe your wishes for access to data kept at the RIPE-NCC. - RADB/Merit has a web interface for queries and updates, although this obviously works for auth: NONE or MAIL-FROM only - proposal: put a pointer to whois "help" into ripe-104++ 3. Authorization and Security DFK reports that development work is on the action list (PGP facilities to be integrated) but there is still a severe lack of resources. Additional help is needed to make real progress, because design work is necessary first. Th Key management would most probably be done according to the Merit approach. We might benefit from (Euro-)CERT activities? In more general terms, if we want to see development progress faster than in the past, then we have to come up with clearly defined needs and a proposal for a devlopment project with additional resources. 4. DB-SW report David Kessens offered the traditional database software report. The slides can be obtained from ftp://ftp.ripe.net/ripe/presentations/ripe-m23-david-DB-REPORT.ps.gz Another set of slides for the In-Addr-Check handling is available from ftp://ftp.ripe.net/ripe/presentations/ripe-m23-david-DNS-INADDRCHECK.ps.gz - beta version V1.1 that allows (close to) real-time mirroring is available. At the time of writing these minutes (4-MAR-1996) the distribution is at ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-1.1beta2.tar.gz - requests to run a mirror copy are to be sent to ripe-dbm(a)ripe.net - other changes include . support for the BSD DB package . better security for "network updates" . less memory consumption In conjunction with the mirror capability, the software has to keep track of individual object creations and updates. The mechanism that is currently used is not suitable for long-term consistency (because the sequntially increasing values are expected to suffer from wrap-around, eventually). Thus a stored: attribute was proposed and accepted. stored: <NEW | UPD> <Date> <Time> <Serial> Inclusion of the authorisation method used and the source of the update was then asked for. DFK is going to circulate a detailed proposal. In general the NCC proposes to use a keyword based mechanism on the subject: line of DB update messages to request special processing. This should eventually obsolete the multiple e-mail addresses, like auto-assign(a)ripe.net, which are not widely known and their use is not always properly enforced. 5. Hierarchical authorization Implementation of hierarchical authorization is initially planned for . domain name space . IP-Address-Ranges for registries . origin AS for routes Moving the description of the hierarchy and the transactions allowed at a particular level to a maintainer object was preferred over an alternate method of using a scope: attribute. 6. Handles, Object review Eventually the assignment of NIC-Handles (more precisely: RIPE handles) is being implemented. David shall circulate a propsal about the logic and the semantics to the mailing list. Reverse lookup (for person objects, at least) is being worked on. The country: attribute is being redefined to allow multiple lines with multiple values, to better reflect the real scope of an entity (like address blocks from a regional registry, AS numbers, etc.) The Role: or NOC: object needs more thought and detailed definition. There is still some uncertainty whether a full-blown new object (with a handle) is really needed, or whether the person object can be extended. Input was received from Michael H. Behringer that proposed a common format for describing contact information, coverage and emergency preocedures. This object is to be re-visited on the mailing list and a decision about implementation is being sought on the list. The proposal for an extension of the inet-rtr: object was briefly discussed. The original intent was to allow for a description of Mbone routers. However, extending the concept could be very useful for describing all sorts of peerings, like Mbone, IP-over-IP, IPnG, and the like. Due to the fact that there is already a couple of tools which read the peer: attributes, it might be wise to not change the peer: attribute as currently defined (but to eventually make it obsolete) and to invent a new attribute with the peering protocol ID as the first element, the address as the second element and then the specific information. To be discussed in more detail on the mailing list. url: it was agreed to add a new (optional) attribute to all objects to allow for inclusion of URLs. The details to be worked out after some more tests. Format could either be plain HTML or general URI syntax. 7. Input from other WGs Already covered (see inet-rtr: for Mbone) 8. AOB None. Meeting closed. ________________________________________________________________________________ List of new actions: Daniel Karrenberg: To circulate a detailed proposal for the stored: attribute. David Kessens: To circulate a detailed proposal for the automatic handle assignement. Wilfried Woeber, Michael H. Behringer: To initiated discussion on the mailing list about the need and possible format for a role: or noc: object. Wilfried Woeber: To initiated discussion on the mailing list about the extension of the inet-rtr: object. WW, 4.3.96.

5 4

Re: Internet Draft Submission (fwd)
by Gabor Kiss 23 Feb '96

23 Feb '96

> > George Eddy writes : > >From eddy(a)ISI.EDU Thu Feb 22 22:12:26 1996 > Date: Thu, 22 Feb 96 13:07:22 PST > Posted-Date: Thu, 22 Feb 96 13:07:22 PST > Message-Id: <9602222107.AA16189(a)kit.isi.edu> > From: George Eddy <eddy(a)ISI.EDU> > To: rps(a)ISI.EDU > Subject: Internet Draft Submission > Geographic Location Extension to Ripe-181 > 3.2 Direct and Indirect Location > > This method proposes the addition of a ``location'' attribute to the > aut-num as in 3.1. This attribute could directly hold the LocString, or > the name of a ``location'' object. The location object could be defined > as: > > location: [mandatory] [single] > loc-string: [mandatory] [single] > descr: [optional] [multiple] > notify: [optional] [multiple] > mnt-by: [optional] [multiple] > changed: [mandatory] [multiple] > source: [mandatory] [single] > > Using the example in section 3.1, we would have the following: > > aut-num: AS8800 > location: IrvineCA > ... > > and the object ``IrvineCA'' would be: > > location: IrvineCA > loc-string: 33 40 10n 117 49 20w 10m > descr: Example location object in Irvine, CA. > notify: eddy(a)isi.edu > mnt-by: MAINT-EXAMPLE > changed: eddy(a)isi.edu 960220 > source: EXAMPLE > > The loc-name could be any string desired by the creator. Dear Eddy, Can two or more AS-es share the same location object? How to coordinate the loc-name assignments. In Europe tipically there are more then one AS within the same city. They will race for the simple name of the city. Just like for domain names. :-/ Maybe the RIPE predefine location objects for the main cities. Regards Gabor

2 1

Internet Draft Submission (fwd)
by David.Kessens＠ripe.net 23 Feb '96

23 Feb '96

> George Eddy writes :

2 1

Internet Draft Submission
by George Eddy 22 Feb '96

22 Feb '96

Internet Draft Rusty Eddy Expires August 27, 1996 USC/ISI draft-ietf-rps-location-00.txt February, 1996 Geographic Location Extension to Ripe-181 Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 1. Introduction This document describes two proposals for specifying geographic location of a database objects such as an Autonomous System (AS). This information could be used by mapping tools that provide geographic maps of the Internet topology. Two alternatives are documented here, the first proposal uses a new attribute added to a database object. The attribute provides longitude, latitude and size information. The second method also uses a new location attribute added to the database object, this new attribute contains the name of a location object that we propose. The two methods describe direct and indirect location information respectively. 2. Format of Location String The format of the geographic ``location string'' or LocString will be a single string consisting of the latitude, longitude and optionally the size. The latitude and longitude are each represented by one to three integers corresponding to degrees, minutes and seconds, with a direction appended to the final integers of the latitude and longitude. If minutes and/or seconds are not provided values of 0 will be assumed and size will default to 0, a point. The directions are north, south, east and west. Rusty Eddy Expires August 27, 1996 [Page 1] Internet Draft Geographic Location Extension to Ripe-181 February, 1996 For example, the LocString for Irvine, California is: 33 40 10n 117 49 20w 10m Representing 33 degrees, 40 minutes and 10 seconds north latitude, and 117 degrees, 49 minutes and 20 seconds west longitude with a 10 meter encompassing circle. Informally the LocString would be of the form: "LA [MM [SS]](n|s) LO [MM [SS]](e|w) [SIm]" Where, LA and LO are integers representing the degrees latitude and longitude, respectively. MM is an integer representing the number of minutes. SS is an integer representing the number of seconds. The characters 'n', 's', 'e', 'w' and 'm' are literals corresponding to north, south, east, west and meters, respectively. 3. Proposals for AS Geographic Location The following proposals are similar, the first suggests a new attribute to the Ripe-181[1] aut-num object, the second also suggests new aut-num attribute and a new ``location'' object. The following examples use the aut-num object, however, they may be equally applied to the as-macro, inet-rtr or route objects as well. Attributing locations to these other database objects would provide the geographic topology internal to an AS, which may represent reality more accurately. 3.1 Direct Location This method proposes a new aut-num attribute, ``location''. This attribute is a single, optional attribute: aut-num: [mandatory] [single] ... location: [optional] [single] The ``location'' attribute will contain a LocString. For example, say AS8800 is an ISP in Irvine, California, it's aut-num could contain the following: aut-num: AS8800 location: 33 40 10n 117 49 20w ... 3.2 Direct and Indirect Location This method proposes the addition of a ``location'' attribute to the aut-num as in 3.1. This attribute could directly hold the LocString, or Rusty Eddy Expires August 27, 1996 [Page 2] Internet Draft Geographic Location Extension to Ripe-181 February, 1996 the name of a ``location'' object. The location object could be defined as: location: [mandatory] [single] loc-string: [mandatory] [single] descr: [optional] [multiple] notify: [optional] [multiple] mnt-by: [optional] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single] Using the example in section 3.1, we would have the following: aut-num: AS8800 location: IrvineCA ... and the object ``IrvineCA'' would be: location: IrvineCA loc-string: 33 40 10n 117 49 20w 10m descr: Example location object in Irvine, CA. notify: eddy(a)isi.edu mnt-by: MAINT-EXAMPLE changed: eddy(a)isi.edu 960220 source: EXAMPLE The loc-name could be any string desired by the creator. 4. Problems One obvious problem with using geographic layout inherent to networks, is that they often span large geographic areas, this is true of many ISPs. When attributing a location to an AS, one must pick a single location to be representative of the AS. The internal topology of an AS may be mapped geographically when a location attribute has been added to the inet-rtr or route objects. 5. Conclusion The motivation for providing geographic locations was prompted by the development of the Internet Routing Registry (IRR) visualization tool (IRRv) as a possible method for topological layout. Methods for obtaining the LocString are beyond the scope of this document, however, it should be noted that RFC 1876[2] specifies a means for containing location information in Domain Name System. Also worth noting is a ``Geographic Nameserver'' at http://www.mit.edu:8001/geo, that derives its information from the Geographic Nameserver database on martini.eecs.umich.edu. Rusty Eddy Expires August 27, 1996 [Page 3] Internet Draft Geographic Location Extension to Ripe-181 February, 1996 Work in this area will proceed if the community finds this feature useful. 6. Thanks Although we have never spoke, I would like to thank, Juergen Schoenwaelder (schoenw(a)ibr.cs.tu-bs.de) for the development of scotty/tkined, which IRRv is based on and the example geographic layout script. Thanks also to Cengiz Alaettinoglu for suggestions that led to these proposals. [1] T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. Karrenberg, M. Terpstra, and J. Yu. Representation of IP Routing Policies in a Routing Registry. Technical Report ripe-181, RIPE, RIPE NCC, Amsterdam, Netherlands, October 1994. [2] C. Davis, P. Vixie, T. Goodwin, and I. Dickinson. A Means for Expressing Location Information in the Domain Name System, RFC 1876, January 1996. Author's Present Address Rusty Eddy Information Sciences Institute University of Southern California Marina del Rey, CA 90292 e-mail: eddy(a)isi.edu

1 0

Re: draft NOC/role object proposal
by M.H.Behringer＠dante.org.uk 26 Jan '96

26 Jan '96

David, Thanks for starting the discussion on this. I have some input to this, see below. Unfortunately I won't be able to come to the RIPE WG-sessions, but Steven Bakker will be there. At 5:17 pm 26/1/1996, David.Kessens(a)ripe.net wrote: >Dear all, > >We have the creation of NOC/role object as one of the action points for >the RIPE NCC. However, after consulting numerous people we seemed to have >agreed upon something where we don't have any specification for ;-(. >Therefore, I am now doing a proposal for how the object could look like. >Note that this proposal is a real draft due to my personal ignorance of >your real needs in this area and the time that went by when we last >discussed the contents of this object for the last time... > > >Problem description: > >We see more and more person objects in the database that are apparently >not persons but referrals to help desks or ISP NOCs. The problem with the >usage of person objects for this matter is that the person object isn't >really designed for this and that in certain cases we require certain >objects to point to real persons for accountability reasons. Usage of >non-persons in person objects undermines therefore the usability of the >RIPE database. However, it is quite obvious that there is a need for such >an object, especially for larger organizations. > > >Proposal: > > >Since the object will be derived from the 'person:' object I will only >describe *all* the differences between the 'person:' object and the >'role:' object. > > >Attributes that are not used: > > >person: - for obvious reasons >nic-hdl: - a NIC handle is by definition assigned to persons and not > to organizations. Since we don't expect too many people > using this object it seems reasonable that we don't use a > number as a unique identifier. If we will need it in the > future we can add it. > > >Additional attributes: > >role: - the name of the object itself > >admin-c: - as in 'mntner' objects >tech-c: - as in 'mntner' objects > > We could decide to leave the 'tech-c:' out, since what's > the point in having a technical contact for a > administrative object only anyway ? I think we should not distinguish. A "person:" attribute would do, I think (however you call it, eg tech-c; the point is: *one* such object). Besides, this is mainly for NOCs and such (at least this is what we would use it for), so it would be technical people on it anyway only. But I think we need more attributes. Basically the role object needs to reflect what you need to know about something like a NOC: Who's in it (as you say), how to contact (might be derived from the other attributes), but also: What are the out-of-hours procedures. There are several possible ways to include that. I would propose something like: role: [mandatory] [single] address: [mandatory] [multiple] (as in person) phone: [mandatory] [multiple] ( " ) fax-no: [optional] [multiple] ( " ) e-mail: [optional] [multiple] ( " ) trouble: [optional] [multiple] (this is needed for trouble contact) (see below) person: [mandatory] [multiple] (this should be handles, obviously) (I see you used tech-c for this purpose, that is basically the same) remarks: [optional] [multiple] (as in person) notify: [optional] [multiple] ( " ) mnt-by: [optional] [multiple] ( " ) changed: [mandatory] [multiple] ( " ) source: [mandatory] [single] ( " ) What was actually the difference between notify and mnt-by? Do we need both? If feel quite strongly that we need something where you can specify the procedure to get in touch with the "role". This could be for example: trouble: Working days 0900-1700 CET: phone: xxx trouble: Working days 0900-1700 CET: e-mail: xxx trouble: Working days 0900-1700 CET: fax: xxx trouble: other times: phone: xxx trouble: other times: pager: xxx trouble: other times: mobile phone: xxx trouble: if all fails: phone: xxx trouble: NOTE: Please always try the phone before paging us! ... and so on. I don't think it is adviseable to be too precise in the specification, as there are certainly folks out there who want to put in notes like above. Thus one attribute like this "trouble" with free content would do. The reason why I think we still need such an attribute: We would like to be able to automatically derive contact procedures from the RIPE DB, to use it as a list. Of course we can also put it in the remarks, but I think one of the reasons for this object is to have this sort of attribute. > > >How to reference the 'role:' object from an object: > > >Here we can opt for two different solutions: > >1) We can allow people to use the 'role:' object in tech-c/zone-c > attributes (not in admin-c, this one can only point to a human due to > our current assignment criteria) > >2) Use a special attribute. The attribute will be an optional, single > line attribute for all objects that currently have an > 'admin-c:/tech-c:/zone-c:' attribute defined (including the role/NOC > object if desired. Note that this can cause undesired loops...): > > Example: > > preferred-contact: > > Please advise on better and shorter names, but that makes clear that > it is intended that a customer first checks with NOC/role object > people. I strongly feel that we should go away from specifying individuals in the other objects such as "route" or "as-num". But obviously not everybody will do that. Therefore I would suggest to use the tech-c: attribute for that. It makes perfect sense to say "tech-c: DFN-NOC" for example. Admin can stay, I don't have a strong view on that. The special attribute you propose in 2) makes it only more complicated, and it doesn't actually give us anything, does it? Hopefully people will not do something like specifying persons *and* a role as tech-c's in one object, but it shouldn't create problems either, you only might get a person twice as output. > > >How does the lookup work: > >The RIPE database can be configured for objects that have references to >other objects in such a way that it will also show the referenced objects >when querying an object with referenced other objects. Since the NOC >object itself can have references to persons/roles, it seems best to do >such a recursive lookup only one level deep whenever we find a NOC/person >object referenced. > >Examples: > >$ whois 193/8 > > inetnum: 193.0.0.0 > admin-c: DK13-RIPE > tech-c: RIPE-NOC > [...] > > person: David Kessens > nic-hdl: DK13-RIPE > [...] > > role: RIPE-NOC > tech-c: DK58 > [...] > >and > >$ whois RIPE-NOC > > role: RIPE-NOC > tech-c: DK58 > [...] > > person: Daniel Karrenberg > nic-hdl: DK58 > [...] Agree. Looks fine. Basically with the role object the goal is to get away from individuals, so the one-level limited recursion makes perfect sense, imo. > > >We hope that this draft is useful enough for you all to let us define a >sound proposal for the NOC/role object. Please make as many >amendments/added features as you want and that you think is needed for >the object, > >Kind regards, > >David Kessens >RIPE NCC What do others think? Michael

1 0

draft NOC/role object proposal
by David.Kessens＠ripe.net 26 Jan '96

26 Jan '96

Dear all, We have the creation of NOC/role object as one of the action points for the RIPE NCC. However, after consulting numerous people we seemed to have agreed upon something where we don't have any specification for ;-(. Therefore, I am now doing a proposal for how the object could look like. Note that this proposal is a real draft due to my personal ignorance of your real needs in this area and the time that went by when we last discussed the contents of this object for the last time... Problem description: We see more and more person objects in the database that are apparently not persons but referrals to help desks or ISP NOCs. The problem with the usage of person objects for this matter is that the person object isn't really designed for this and that in certain cases we require certain objects to point to real persons for accountability reasons. Usage of non-persons in person objects undermines therefore the usability of the RIPE database. However, it is quite obvious that there is a need for such an object, especially for larger organizations. Proposal: Since the object will be derived from the 'person:' object I will only describe *all* the differences between the 'person:' object and the 'role:' object. Attributes that are not used: person: - for obvious reasons nic-hdl: - a NIC handle is by definition assigned to persons and not to organizations. Since we don't expect too many people using this object it seems reasonable that we don't use a number as a unique identifier. If we will need it in the future we can add it. Additional attributes: role: - the name of the object itself admin-c: - as in 'mntner' objects tech-c: - as in 'mntner' objects We could decide to leave the 'tech-c:' out, since what's the point in having a technical contact for a administrative object only anyway ? How to reference the 'role:' object from an object: Here we can opt for two different solutions: 1) We can allow people to use the 'role:' object in tech-c/zone-c attributes (not in admin-c, this one can only point to a human due to our current assignment criteria) 2) Use a special attribute. The attribute will be an optional, single line attribute for all objects that currently have an 'admin-c:/tech-c:/zone-c:' attribute defined (including the role/NOC object if desired. Note that this can cause undesired loops...): Example: preferred-contact: Please advise on better and shorter names, but that makes clear that it is intended that a customer first checks with NOC/role object people. How does the lookup work: The RIPE database can be configured for objects that have references to other objects in such a way that it will also show the referenced objects when querying an object with referenced other objects. Since the NOC object itself can have references to persons/roles, it seems best to do such a recursive lookup only one level deep whenever we find a NOC/person object referenced. Examples: $ whois 193/8 inetnum: 193.0.0.0 admin-c: DK13-RIPE tech-c: RIPE-NOC [...] person: David Kessens nic-hdl: DK13-RIPE [...] role: RIPE-NOC tech-c: DK58 [...] and $ whois RIPE-NOC role: RIPE-NOC tech-c: DK58 [...] person: Daniel Karrenberg nic-hdl: DK58 [...] We hope that this draft is useful enough for you all to let us define a sound proposal for the NOC/role object. Please make as many amendments/added features as you want and that you think is needed for the object, Kind regards, David Kessens RIPE NCC

1 0

Hierarchical authorization proposal
by David.Kessens＠ripe.net 26 Jan '96

26 Jan '96

Dear all, We are already talking for quite some time about a hierarchical authorization scheme for objects in the RIPE database that need protection against creating objects in somebody else's address/domain space. Hereby, I want to describe the requirements for such a new feature and two possible solutions. Problem description: Currently, we see more and more problems with objects that are (usually by accident) created in another registries address space or problems with domain objects where people think that a domain is delegated to them when they have send a domain object to the RIPE database. It seems that, since we are using to much time for this kind of issues, the time has arrived that we need to solve the problem. Requirements: Objects that are directly located in a predefined hierarchy under a certain object need an extra authorization step before they can be created. The authorization step should be defined by the object that is located in the hierarchy directly above the object. The authorization step will be done on all objects that are located directly above the object if we have more then one object directly above the object (this should generally not be the case). The hierarchical authorization step seems not to be needed (yet) for updating/deleting an object in the hierarchy. However, the design should be able to be extended in such a way that this feature can be added in the future if the need arises. Currently we are dealing with three hierarchies: 1) Domain space hierarchy The definition of the domain hierarchy is straight forward: A domain consists of text strings concatenated with dots An domain is 'above' another domain when all text strings match with the other domain from the right and they are not the same. An domain is 'directly above' another domain when it is above the other domain and differs only with one text string. The definition for '(directly) below' another domain follows from the definition for above: An domain is '(directly) below' another domain when the other domain is above the domain. Example: 'x1.office.ripe.net' is below 'ripe.net' 'x1.office.ripe.net' is directly below 'office.ripe.net' 'ripe.net' is above 'x1.office.ripe.net' 'office.ripe.net' is directly above 'x1.office.ripe.net' 2) IP address space range hierarchy for 'inetnum:' objects An IP address space range is a little bit more complicated since we can have overlapping ranges: A range is 'above' another range when the range is larger then the other range and it overlaps it completely. A range is 'directly above' another range when it is the smallest possible range that is still above the object. The definition for '(directly) below' another range follows from the definition for above: A range is '(directly) below' another range when the other range is above the range. People might consider that there exists a problem when we are dealing with partially overlapping ranges (not possible with prefix notation ranges but are possible with normal IP address space range notation). However, the definition handles this problem gracefully: a range can only below or above another range when they overlap each other *completely*. Example: In IP address space range notation: '194.0.0.0 - 194.255.255.255' is 'above' '194.5.20.0 - 194.5.20.255' '194.5.20.0 - 194.5.23.255' is only 'directly above' '194.5.20.0 - 194.5.20.255' when there are no other ranges that are bigger and also 'above' '194.5.20.0 - 194.5.20.255'. '194.5.20.0 - 194.5.20.255' is 'below' '194.0.0.0 - 194.255.255.255' '194.5.20.0 - 194.5.20.255' is only 'directly below' '194.5.20.0 - 194.5.23.255' when there are no other ranges that are 'above' '194.5.20.0 - 194.5.20.255' and 'below' '194.5.20.0 - 194.5.23.255'. In prefix notation ranges: '194/8' is 'above' '194.5.20/24' '194.5.20/22' is only 'directly above' '194.5.20/24' when there are no other ranges that are bigger and also 'above' '194.5.20/24'. '194.5.20/24' is 'below' '194/8' '194.5.20/24' is only 'directly below' '194.5.20/22' when there are no other ranges that are 'above' '194.5.20/24' and 'below' '194.5.20/22'. 3) Route object hierarchy At first sight a 'route:' object has the same hierarchy as for 'inetnum:' objects. However, a 'route:' object has in fact a two level hierarchy: The origin AS object is always the object directly above a certain 'route:' object. An all route objects with a given origin are always directly below the origin AS object. Proposed solutions: 1) New attribute for hierarchical organized objects: Add an optional multiple line attribute to hierarchical organized objects that points to the maintainer object which authorization scheme will be used when an object will be created 'directly below' the object. mnt-lower: MAINTAINER [ ( CREATE & CHANGE & DELETE ) ] MAINTAINER - The maintainer that defines the authorization scheme to be used when an object 'directly below' in the hierarchy from the object, that has defined this attribute, will be created in addition to the authorization schemes that are defined in the to be created object itself. The maintainer will optionally be followed by a specification upon which events the authorization needs to be used: CREATE - perform the authorization step when an object is created 'directly below' the object. CHANGE - perform the authorization step when an object is changed 'directly below' the object. DELETE - perform the authorization step when an object is deleted 'directly below' the object. When no events are specified, the default behavior will be used, that is: perform the authorization only upon creation of objects directly below the object. This attribute is optional for objects that have a hierarchy defined. Currently, there is a hierarchy defined for: 'domain', 'route' and 'inetnum' objects. Multiple attributes may be defined and will mean that at least one of the authorization methods as mentioned in the referenced maintainers should allow the database update. Example: RIPE can have the following object: inetnum: 194.0.0.0 - 194.255.255.255 descr: RIPE - ALLOCATED BLOCK mnt-by: RIPE-NCC-MNT mnt-lower: RIPE-NCC-MNT (CREATE | DELETE) RIPE can allocate address space to a local registry and hand over the authority for the address space below. Note that the registry can not delete or create it's allocated address space object but may change it's contents. inetnum: 194.10.0.0 - 194.10.255.255 descr: ALLOCATED BLOCK to LOCAL REGISTRY mnt-by: LOCAL-REGISTRY-MNT mnt-lower: LOCAL-REGISTRY-MNT (CREATE | DELETE) Then the registry can register it's customers as follows: inetnum: 194.10.3.0 - 194.10.3.255 descr: CUSTOMER of local registry The customer may change their object but cannot create/delete it: 2) New attribute for maintainer object: Another solution would be to add an optional multiple line 'scope:' attribute to the maintainer object that will specify that the authorization scheme should be used when objects are created, changed or deleted 'directly below' the object that references the maintainer. At first glance, this solution looks attractive but will not allow for hand-over of authority as can be done in the first proposal. scope: WORKINGAREA [ ( CREATE & CHANGE & DELETE ) ] WORKINGAREA - Can be LOCAL or LOWER. LOCAL is the default behavior and is the same as the 'maintainer' object currently works. LOWER would do the authorization step when objects are created, changed or deleted directly below the hierarchical object that references the maintainer. CREATE, CHANGE, DELETE will work as specified in the previous proposal. Note that it will also extend the possibilities for the maintainers when used in LOCAL mode (the way maintainers work now): 'LOCAL (CREATE & CHANGE & DELETE)' matches the current maintainer behavior. The attribute is optional for maintainer objects. We could decide to allow the use of this attribute also for the hierarchical organized objects. It will then override the default behavior as specified in the maintainer object. The attribute can be used twice: one time for the LOCAL scope and one time for the hierarchical authorization method (LOWER). Example: RIPE can have the following object: inetnum: 194.0.0.0 - 194.255.255.255 descr: RIPE - ALLOCATED BLOCK mnt-by: RIPE-NCC-MNT mntner: RIPE-NCC-MNT scope: LOCAL (CREATE & CHANGE & DELETE) scope: LOWER (CREATE & DELETE) RIPE can allocate address space to a local registry and hand over the authority for the address space as below. Note that the registry can not delete or create it's allocated address space object but may change it's contents. inetnum: 194.10.0.0 - 194.10.255.255 descr: ALLOCATED BLOCK to LOCAL REGISTRY mnt-by: LOCAL-REGISTRY-MNT mntner: LOCAL-REGISTRY-MNT scope: LOCAL (CREATE & CHANGE & DELETE) scope: LOWER (CREATE & DELETE) Then the registry can register it's customers as follows: inetnum: 194.10.3.0 - 194.10.3.255 descr: CUSTOMER of LOCAL registry The customer may change their object but cannot create/delete it: Discussion: Both proposals solve the problem. Both proposals will have the same implementation complexity. But there of course also some differences: Proposal 1: This solution is probably clearest and easiest to the user by using a special attribute in the objects in the hierarchy itself instead of hiding it in the maintainer object. Of course this is also the weakness: a maintainer object that looks the same may behave differently depending on the context in which it is used. Also, when we introduce the new scheme many objects need an update (this might be an advantage or an disadvantage depending on how you view things...). Furthermore, most objects will again get an extra attribute defined. Proposal 2: The mechanism is hidden for the user and therefore might be less clear. The maintainer object will be the only object that defines authorization policies. We can introduce the mechanism rapidly by just adding an attribute to the maintainer object (In RIPE's case: we only need to add an attribute to our maintainer object to protect the whole RIPE database against unauthorized allocations/assignments in our space). We don't get extra attributes defined for the normal objects. Note that we think that we should choose the best mechanism, even if introducing might be somewhat more complex. The extra workload for proposal one seems not that much more. Expected implementation problems: Implementation for the IP address space notation ranges that are used in 'inetnum' objects will not be trivial due to the internal workings of the database for 'classless' lookups. You probably don't know the details but for the people that are interested: The IP address space ranges are internally converted to prefix notation. When, they don't fit in one prefix, more prefixes are generated. In that case we can get in trouble with overlapping objects that might be found as directly above instead of the correct object. I think it is possible to solve but it will needs some more work then expected at first sight. Please let us know if there exist better solutions or that changes are needed, or just make your choice! David Kessens RIPE NCC

1 0

RIPE Action 21.9: Fwd: E-J B: Draft doc m.cast router in routing reg.
by Wilfried Woeber, UniVie/ACOnet 25 Jan '96

25 Jan '96

FYI, this is the original proposal as circulated by Erik-Jan Bos. -Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Subject: Draft document multicast router in routing registry From: Erik-Jan Bos <erik-jan.bos(a)surfnet.nl> Date: Sun, 07 May 1995 11:49:46 +0200 Mbone-EU, please find below a first version of a document describing a multicast router in a routing registry. I would like to have your comments and we can discuss it at the next Mbone WG meeting. I realize some of you might not have a chance to read it before the meeting. Well... here it is, I'll try to bring copies to the meeting. See you in Rome. --- Start of document 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 addition to ripe-122 (Specifying an "Internet Router" in the Routing Registry) in which it is possible to define a multicast capable Internet routing within a routing registry. 1. Introduction With the growing of the Mbone worldwide, managing the Mbone becomes a complex task. The multicast-bone is starting to suffer from problems that used to be present in the unicast-bone several years ago, such as routing coordination. 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 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 Mbone. Furthermore, administrative details (such as contact person) are easily administered by well known procedures and easily retrievable. 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. Multicast router specification Since an Internet Router can perform both types of routing, this fact should be registerable in the routing registry. 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 multicast router: inet-rtr: broodjeham.surfnet.nl localas: AS1103 ifaddr: 192.87.106.102 255.255.255.0 ifaddr: 192.87.4.99 255.255.255.0 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 Several pieces of important information are present in this object. First of all there is the FQDN of the router, acting as object name. The Home Autonomous System Number is shown, which for a multicast router is merely for identification purposes only. Furthermore, the ifaddr:-lines show that this router has two interfaces, in two different networks. Finally, the DVMRP peers are shown with IP address, treshold and metric. All other attributes are common to other objects already defined for a routing registry [1]. For exact syntax definition see next chapter. 4. Multicast router Syntax Definition The multicast capable router object is defined here. Each of the possible attributes are shown, on a single line. The second column defined 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] mpeer: [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. ifaddr: An interface IPv4 address of the router. mpeer: A multicast peering of the router. Format: <mpeer address> <mpeer treshold> <mpeer metric> Example: mpeer: 192.87.108.13 16 1 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. 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 done reviewing of this document and they receive credits as well. 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 __ Erik-Jan. --------------------------------------------------------------------------------

1 0