REMINDER - Request for Input

[Carol Orange <Carol.Orange@localhost]

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.