NCC Update and Request for Input

Hi Folks,

The intention of this mail is to give you a short update of the
current efforts taking place at the RIPE NCC with respect to database
development and maintenance and to gather your input in setting our
priorities for the spring of '97 which to our great relief is finally
showing its face - even here in Amsterdam!

As promised, we are hard at work getting the components in place to give 
you verbose object descriptions with a new whois flag. You can expect 
an announcement for this service in the very near future. Simultaneously, 
we are working on a number of bug fixes and minor requests. For example, 
we now allow the use of 4 digit years in the changed field. 

As promised, we are working towards a complete and revised version of the 
RIPE database documentation (ripe-153) which will include some new
sections and appendices as well as reflect the feedback received from the 
user community. The comments received to date have been greatly appreciated 
and will be reflected in the next version. Feedback is still welcome
and desired, so if you've got comments, do send them along.

To prioritize our further activities in the spring of 1997, we would
appreciate your input on the direction of database development which 
is most important in your view.

At the meeting of the Database working group at the RIPE-26 meeting in
January, I gave a presentation on the current list of open issues regarding 
the RIPE database. The slides in which the various items are described
are posted in the following places:

http://www.ripe.net/meetings/ripe/ripe-26/pres/db-update/
ftp://ftp.ripe.net/ripe/presentations/ripe-m26-orange-dbupdate.ps.gz

At that meeting, noone could think of items of concern which were not 
already on the list. During the course of the discussion, we classified 
each issue as one of:

A) just do it, and
B) needs further discussion

I promised to post the items under (A) for priority setting and under 
(B) for discussion. In this mail, I'd like to ask for your input on 
which items in the "To do" category (A) have your highest priority. 
To prevent excessive traffic, please send your response directly to me 
(orange at ripe.net). I will post the results I've received in the week 
of March 17, and the corresponding action plan we will follow at the NCC 
during the coming months. 

Greetings,

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 	* Friday, March 14, 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.