Results of vote
- Date: Mon, 24 Mar 1997 19:53:42 +0100
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.
|