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.
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.
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(a)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.
