About RIPE | Contact  | Search | Sitemap    
Homepage RIPE  
RIPE Community Mail Archives
search  
     
RIPE Navigation Ends
About RIPE Maillists
Maillists Archive
Global Lists
Non Active Lists
RIPE NCC Navigation Ends
Next Section
<<< Chronological >>> Author Index    Subject Index <<< Threads >>>

Results of vote

  • From: Carol Orange < >
  • 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.



  • Post To The List:
<<< Chronological >>> Author    Subject <<< Threads >>>
 

Next Section
     About RIPE | Site Map | LIR Portal | About the RIPE NCC | Contact | © RIPE Community. All rights reserved.
RIPE.NET Homepage LIR Portal RIPE Community