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