Hi Folks, The intention of this mail is to give you a short update of the current efforts taking place at the RIPE NCC with respect to database development and maintenance and to gather your input in setting our priorities for the spring of '97 which to our great relief is finally showing its face - even here in Amsterdam! As promised, we are hard at work getting the components in place to give you verbose object descriptions with a new whois flag. You can expect an announcement for this service in the very near future. Simultaneously, we are working on a number of bug fixes and minor requests. For example, we now allow the use of 4 digit years in the changed field. As promised, we are working towards a complete and revised version of the RIPE database documentation (ripe-153) which will include some new sections and appendices as well as reflect the feedback received from the user community. The comments received to date have been greatly appreciated and will be reflected in the next version. Feedback is still welcome and desired, so if you've got comments, do send them along. To prioritize our further activities in the spring of 1997, we would appreciate your input on the direction of database development which is most important in your view. At the meeting of the Database working group at the RIPE-26 meeting in January, I gave a presentation on the current list of open issues regarding the RIPE database. The slides in which the various items are described are posted in the following places: http://www.ripe.net/meetings/ripe/ripe-26/pres/db-update/ ftp://ftp.ripe.net/ripe/presentations/ripe-m26-orange-dbupdate.ps.gz At that meeting, noone could think of items of concern which were not already on the list. During the course of the discussion, we classified each issue as one of: A) just do it, and B) needs further discussion I promised to post the items under (A) for priority setting and under (B) for discussion. In this mail, I'd like to ask for your input on which items in the "To do" category (A) have your highest priority. To prevent excessive traffic, please send your response directly to me (orange@ripe.net). I will post the results I've received in the week of March 17, and the corresponding action plan we will follow at the NCC during the coming months. Greetings, Carol ------------------------------------------------------------------- * * * V O T E H E R E * * * In the following, I give a short description of each work item. The numbering is consistent with those in the presentation slides. Thus there are gaps in the numbering for those open issues which need further discussion (B). In the following list, please assign a score to *exactly 5* of the items. Give a 1 to that which is most import to you, 2 to the next most important 3 4 5 for what you would like to see, but with a lower priority. You can use each of the above scores exactly once in the list below. If you have any questions, just send them to me. ________________________ | | Please respond before * Friday, March 14, 1997 * |________________________| Here is the list then: [ ] 3. Check the content of admin-c field during the creation and modification of objects to assure the content refers to a person object (and not a role). [ ] 4. Take steps to remove obvious garbage (e.g. "see remarks") from the admin-c, tech-c, and zone-c fields. In general, such fields should contain a valid NIC handle referring to a person or role object. However, which NIC handles are valid is not always obvious in a global registry and that definition falls under one of the open issues. [ ] 7. Hierarchical authorization in the routing registry. Note: this item depends on a clear definition on how the hierarchy should be defined. It was however decided that as soon as the Routing WG comes with a definition with which they are satisfied, it should "just be" implemented, without further discussion by the Database WG. [ ] 8. Hierarchical notification in the routing registry. This would be a notification method which would allow someone to be notified when routes are announced. Please see notes under number 7 above. [ ] 9. Currently insufficient information is sent to the person in a "notify" field when an object is modified by that person. It was decided that complete information on the modification should be sent to the person in the notify field, regardless of the options used to send it, and regardless of who made the changes. This is primarily to facility consistent administrative services. If the person in the notify field made the update, only one message should be sent, but it should contain all information. [ ] 12. Implement (borrow) extended as-in/as-out features described by Cengiz Alaettingoglu in the RPSL draft: ftp://ftp.ripe.net/internet-drafts/draft-ietf-rps-rpsl-00.txt [ ] 13. In response to whois queries, show the name associated with the NIC handle admin-c, tech-c, and zone-c fields. [ ] 17. When objects are created or updated, check the validity of all referenced objects, before accepting the modification. [ ] 21. Logging of syntax errors to collect information which might be used to improve the user interface. [ ] 22. Track object history including UTC time zone, and as accurately as possible, who made the change. [ ] 23. Define and implement a referral mechanism for TLDs. [ ] 24. Verbose object descriptions with "whois -tv". This is underway, and on the list for completion. [ ] 25. Syntactic cleanup: remove ripe-181 line continuation.