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

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