- db-wg - mailman.ripe.net

TEST database.
by RIPE Database Administration 04 Oct '96

04 Oct '96

Dear Colleagues, The test version of the RIPE database is back on-line. Requests for maintainer objects in the test database should be sent to <ripe-dbm(a)ripe.net>. This is to be changed in the near future. Participants in the RIPE Database 2.0 Workshop during the recent RIPE meeting had test objects and maintainers created for them in the test database. If you wish these objects to remain in the test database, please send a message to <ripe-dbm(a)ripe.net> as soon as possible. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

1 0

Re: mnt-lower attribute not allowed?
by Wilfried Woeber, UniVie/ACOnet 04 Oct '96

04 Oct '96

Hi Steven et.al. ! => => The AS object that matches the origin AS of a route object could be the => parent object of the route object, but then people are still able to put => route objects in with another origin AS which might not be desired by the => owner of the non-portable CIDR address space. Furthermore, a second => hierarchy exists: the IP prefix tree. => => You might want to try to formulate a proposal that is not too => complicated and also addresses the concerns of most people ... = =How about making the inetnum object the parent of the route object? =I think it would make sense to allow the "owner" of the inetnum to create =the route objects.. I'm not convinced that this is the way to go. For two major reasons: - in many environments the routing is handled differently from the address allocation. In particular, where filters or other things are (semi-)automatically derived from objects in the DB, it's certainly not feasable to have the customers ("owner" of the address space) change things without coordination. If they do, it might not reflect reality at all or it might interfere with local logistics. And there's the issue of porting PA address space for a limited amount of time to a different ISP. - I think we should come up with a concept that works as well outside the RIPE-coordinated address space and the central registry concept. I think we should . come up with a solution that works for routing-registries that do not include an address registry in the same DB, . find a solution that works uniformly across all parts of the address space (A, B, C-19[3-5], TWD, et.al.) = You can also keep the owner in the "notify:" field of =the route object, so once you delegate maintenance of the route object to =someone else, you can still keep track of what's happening with it. = =Or does this sound ludicrous? No, it made me think, thus it was a very useful approach :-) I'd favour an approach that is (conceptually) similar to the handling of domain objects - something like an upstream search based on the AS #. Although I haven't a clear picture of how it could work in reality, because the "tree" is certainly less well-defined than in the DNS namespace. 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

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

04 Oct '96

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

4 3

Hierarchical Authorisation.
by RIPE Database Administration 02 Oct '96

02 Oct '96

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

1 0

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

02 Oct '96

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

4 3

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

27 Sep '96

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

2 1

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

26 Sep '96

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

3 3

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

26 Sep '96

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

1 0

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

20 Sep '96

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

2 1

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

20 Sep '96

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

1 0