Hi All, Recently I sent out a message requesting your input regarding the prioritization of the on the RIPE Database work items on the NCC to do list. We received input from 16 of the 133 members (12%) on the db-wg mailing list, and would like to thank those who participated for giving us input. Based on your responses, the list of work items should be performed in the following order. The votes have been weighted according to the preference shown for an item. item votes priority ---- ----- -------- 17. [36] 1 9. [33] 2 8. [30] 3 23. [28] 4 22. [25] 5 7. [21] 6 13. [18] 7 12. [17] 8 4. [10] 9 21. [8] 10 3. [6] 11 25. [1] 12 The list is attached again below for reference. We will be working in the order specified above during the coming months and will report on our progress at the Dublin meeting. We may deviate from this order from time to time when it will speed up our progress significantly. It's quite useful to know what your priorities are. To gather this information more effectively in the future, we'd also like any input or suggestions you may have on the manner that this poll was conducted. For example: Do you like being polled on these matters? Was the voting mechanism clear and easy to follow? Do you have suggestions to improve it? Any input you have will be taken into account in the future. -- Carol --------------------------------------------------------------------- The list of items is now labeled with the priority from the list above (the number in [] is the priority with [1] being the top priority, and [12] being the lowest). RIPE NCC Database Work List --------------------------- [11] 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). [9] 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. [6] 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. [3] 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. [2] 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. [8] 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 [7] 13.In response to whois queries, show the name associated with the NIC handle admin-c, tech-c, and zone-c fields. [1] 17.When objects are created or updated, check the validity of all referenced objects, before accepting the modification. [10] 21.Logging of syntax errors to collect information which might be used to improve the user interface. [5] 22. Track object history including UTC time zone, and as accurately as possible, who made the change. [4] 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. [12] 25. Syntactic cleanup: remove ripe-181 line continuation.