Hi again, Last Friday, I posted a message requesting your input on the database activities at the RIPE NCC in the coming months. Tomorrow was set as the deadline to respond. As the input to this point has not been overwelming, I thought I'd send you a reminder, and give you all the weekend to consider. The deadline has now been moved forward to Monday, March 17, 1997. Greetings and good weekend, -- 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 * Monday, March 17, 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.