- db-wg - mailman.ripe.net

Re: Proposal for db change
by Wilfried Woeber, UniVie/ACOnet 17 Apr '97

17 Apr '97

Hi John! Thank's for raising that issue. = davidk(a)isi.edu writes: = * = * John, = * = * I am afraid that the people that forget the "source:" field are the same = * people that send a "source: RADB/MCI/whatever" to the RIPE database. You = * will thus get more consistency problems if those people find out about = * the possibility to omit the "source:" field. We are dealing with a set of = * logical different databases and I think that it is better that people = * *know* about this to avoid all the possible confusion about where their = * data is stored and mistakes made by people that have to deal with more = * databases then just the RIPE one. = =The letting them know would occur when they recieve warnings, or in =the case of an incorrect "source:" have the update fail. One of the reasons why we insist on a source: field is the dream(?) of eventually having a system where we can submit updates to our local/favourite/whatever registry (db update mechanism) and have the update automatically forwarded to the "correct" registry. Of course, it's still a dream... I'd like to get input whether the user community would prefer more "comfort" locally and to trade in some future functionality... =People are clearly told that they need to put in a source field in the =documents, the ones I see most are where people forget to add a source =field, even if they know about the different databases. They just =forget, a warning should be enough for these people to remember =next time. I tend to agree. = * Another problem is that many people don't really like the automatic = * fiddling with their objects which also makes it very hard to do things = * (in the future) like signing objects by the user itself and storing them = * as-is including the signature in the database. = =We do this already with some fields. inetnum gets changed if they =send in ... = =inetnum: 194.0.1.0 = =or = =inetnum: 194.0.1.0/24 = =... to = =inetnum: 194.0.1.0 - 194.0.1.255 That's an interesting aspect. (Actually, only the "classful" update would be expanded, isn't it?) Which indeed adds another facette to an authentication environment ;-) But we might be able to solve that by disallowing "classful" *updates* as soon as we offer authentication. Please note that I don't see a problem in *replacing* any existing "classful" object by a signed new object. Or do I miss something? >The changed field can also be fiddled with, i.e if the date is in >the future. I think this should be solved while implementing the automatic UTC (and source) tagging. As soon as we have that in place, I do no longer see a reason to touch any user-supplied data in the changed field(s). >These are both cases where the database needs a particular format >and can therefor make the change. I would suggest that the "source:" >could be a similar case. > >Is there a reason that I am missing why the "source:" differs >from these when it comes to "signatures" etc. That's true. Although I'd like to limit "automatic" modifications, anyway. > * On the other hand I really like this since I am a lazy person and I have > * to admit that I have a local db running as my address book that does > * exactly the thing that you propose ... Me too! (Ok, get these flame throwers set up :-) Honestly, how about offering that for as long as there is no authentication interaction? As soon as we hit the wall we might have a solution ready or we might have to *not* offer that comfort for signed or checksummed updates? Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------

2 1

Proposal for db change
by John LeRoy Crain 17 Apr '97

17 Apr '97

Hello folks, I was sitting here getting annoyed at people who forget to add "source:" fields when I had a thought; Would it be useful to have the "source:" field added automatically when people forget it? I am assuming here that all updates to auto-dbm(a)ripe.net should contain "source: RIPE". The update could take place and a warning could be issued. _______________________ Warning "source:" field missing The field "source: RIPE" has been added to your object. _______________________ My experience is that many people forget to add "source:" fields and the objects get rejected. As the field should always be the same would it not be useful to update it and generate a warning? Your opinions would be appreciated, Kind regards, John Crain RIPE NCC

2 3

Re: Tools based on whois -t output.
by Wilfried Woeber, UniVie/ACOnet 14 Apr '97

14 Apr '97

= "Mike Norris" <mnorris(a)hea.ie> writes: = * = * Good idea, Ambrose. I presume the asterisk is a = * place-holder and will appear in the case of attributes = * that are neither look-up nor inverse keys? = =Yes. The aim is to make the output easier to read. I =suppose an "-" character or a blank space could be used =instead. I will think about it. I'd ask you to come up with a somewhat consistent format. A blank by itself doesn't sound like a good idea from the SW engineering point of view. How about having the brackets anyway, but no tag inside, or a hyphen, or an asterisk. I think it would be easier to parse in the end, if we can expect a constant number of (non-blank :-) fields. Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------

4 3

Changing rrdb objects in the future
by Joe Abley 14 Apr '97

14 Apr '97

Apologies if this is the wrong forum to bring this up... It would appear that current implementations of the e-mail gateway which lets you update RR records impose a restriction on the date field to prevent people from entering dates that appear to be in the future - records like that are returned with an error. This is a bit of a pain for people in NZ and Australia, who are typically 18-20 hours ahead of RR machines located in the US, and are hence generally the date is a day ahead. It means that every time we make an update to an RR, we have to date the modification with the previous day's date. Now this isn't a really serious problem or anything, but it is annoying. Could the RRDB not store date and time records in (say) UTC, and convert local times supplied with timezones before sanity-checking dates that appear to be in the future? Joe -- Joe Abley <jabley(a)clear.co.nz> CLEAR Communications Ltd Systems Engineer, ISD http://www.clear.co.nz/

3 3

Re: Changing rrdb objects in the future
by Wilfried Woeber, UniVie/ACOnet 14 Apr '97

14 Apr '97

=At 02:46 PM 4/08/97 -0400, you wrote: =>At the last ripe meeting it was agreed to track object history =>including UTC time zone, although I'm not entirely clear what this =>means. Presumebly it means that the changed field will be stamped =>automatically by the db software with utc time and the from =>line of the email. = =That would certainly sort it out. The RIPE-DB WG proposed to have the db update mechanism *automatically* tag objects being updated with a UTC timestamp (and some other data). This data would *not* be under the control of the submitting entity. It is not meant to replace or modify any data in the changed: field as supplied by the submitting entity. This change is already on the RIPE-NCC's to-do-list for implementation. => I think another holdup is the issue of the millenium approaching. =>The current date format (ie, YYMMDD) will be insufficient for those =>future dates. And so this problem must be fixed too. => I would think that YYYYMMDD is an obvious solution. The RIPE DB production software already accepts objects with the extended 8 character format. =That will take care of the y2k problem, but won't help those of us in =unusual time zones... For that we would need something like YYYYMMDDHHMMZZZ =(ZZZ=time zone). This is a bit more of a mouthful, of course. I think local time details (time zones, DST, whatever) should become a non-issue as soon as we get the changed: data decoupled from the UTC time stamps as applied by the db update process? =>The db software =>will be converted from ripe181 to rpsl over the coming 6 months. =>Maybe when the db's are officially changed to rpsl we can update =>the objects from YYMMDD --> YYYYMMDD format. => =>ps Yes, this is exactly the correct forum to bring this up. = =Good :) Although I wonder whether it would be useful and more consistent to convert all the exiting objects from the 6 character to the 8 character format and to expand the 6 character format on the fly during the update processing... Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------

1 0

Tools based on whois -t output.
by RIPE Database Administration 09 Apr '97

09 Apr '97

Hi, all ! We are contemplating changing the output of the "-t" option of "whois" to give more information. Please inform us if you write or use tools based on this output. Example: The current output for "-t person" is person: [mandatory] [single] address: [mandatory] [multiple] phone: [mandatory] [multiple] fax-no: [optional] [multiple] e-mail: [optional] [multiple] nic-hdl: [optional] [single] remarks: [optional] [multiple] notify: [optional] [multiple] mnt-by: [optional] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single] the new output would be person: [mandatory] [single] [look-up key] address: [mandatory] [multiple] * phone: [mandatory] [multiple] * fax-no: [optional] [multiple] * e-mail: [optional] [multiple] [look-up key] nic-hdl: [optional] [single] [look-up key] remarks: [optional] [multiple] * notify: [optional] [multiple] [inverse key] mnt-by: [optional] [multiple] [inverse key] changed: [mandatory] [multiple] * source: [mandatory] [single] * where [look-up key] indicates that you use this attribute as an argument to whois and [inverse key] indicates that you can use the attribute as an argument to whois -i. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

3 3

Database Inconsistencies
by Carol Orange 07 Apr '97

07 Apr '97

Hi all, At the January meeting of the RIPE Database WG, I promised to post the reports on RIPE Database inconsistencies produced by the group of students at the Free University last fall. The reports are now on our ftp site and can be found in: "Problem Definition" ftp://ftp.ripe.net/ripe/dbase/info/consistency1.ps ftp://ftp.ripe.net/ripe/dbase/info/consistency1.txt "The RIPE Database: Constraints and possible Solutions" ftp://ftp.ripe.net/ripe/dbase/info/consistency2.ps ftp://ftp.ripe.net/ripe/dbase/info/consistency2.txt Greetings, -- Carol

1 0

"Fake" records in RIPE DB
by RIPE Database Administration 07 Apr '97

07 Apr '97

Hi, Gabor ! I have traced the source of the problem and have contacted those responsible. Thank you for informing us. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

1 0

fake records in RIPE DB
by Gabor Kiss 07 Apr '97

07 Apr '97

Dear Hostmaster, FYI. Last week the following fake records was created in the name of you: inetnum: 194.117.120.201 - 194.117.120.201 netname: SAP-HUNGAROPHARMA descr: Hungaropharma RT country: HU admin-c: VG48-RIPE tech-c: VG48-RIPE status: ASSIGNED PA changed: hostmaster(a)ripe.net 960702 source: RIPE inetnum: 194.117.120.204 - 194.117.120.204 netname: SAP-FOEVAROSI descr: Foevarosi Vizmuevek Rt. country: HU admin-c: SB568-RIPE tech-c: SB568-RIPE status: ASSIGNED PA changed: hostmaster(a)ripe.net 960702 source: RIPE inetnum: 194.117.120.216 - 194.117.120.216 netname: SAP-MMG descr: MMG Automatikai Muevek Rt. country: HU admin-c: TJ308-RIPE tech-c: TJ308-RIPE status: ASSIGNED PA changed: hostmaster(a)ripe.net 960702 source: RIPE inetnum: 194.117.120.231 - 194.117.120.231 netname: SAP-MVM descr: MVM RT. country: HU admin-c: AK625-RIPE tech-c: AK625-RIPE status: ASSIGNED PA changed: hostmaster(a)ripe.net 960702 source: RIPE I think some stronger authentication/authorization method is necessary as well as better education of local registries. :-) Regards Gabor

2 1

Results of vote
by Carol Orange 24 Mar '97

24 Mar '97

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.

1 0

REMINDER - Request for Input
by Carol Orange 13 Mar '97

13 Mar '97

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.

1 0

NCC Update and Request for Input
by Carol Orange 07 Mar '97

07 Mar '97

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.

1 0

route obj & notifications
by Schmitz＠RUS.Uni-Stuttgart.DE 14 Feb '97

14 Feb '97

Dear colleagues, yes, it is me again ;-) asking for comments on another element of hierarchical authorisation for route objects: The idea is to use a prefix based hierarchical scheme just as it is used for inetnum objects. However, it turned out that there are several difficulties in it. So, to get started the consensus at the wg session was: *not* to enforce a prefix based hierarchical scheme until these difficulties are solved, but instead generate notifications only. There are several proposals out there for notifications - to notify only if it is requested (by adding "notify" attributes to objects) - to leave inetnum objects out for the time being until their relation to route objects is clearly defined - notifications should only be done for creation of route objects not for changes or deletions (to prevent mail floods) - probably, the creator of route objects should also be notified of notifications for coordination purposes What are your feelings about this? Yes, no, maybe, missing items? Your comments are welcome! For further reference read/attack/tear apart/abuse the compilation at http://www.ripe.net/wg/routing/haro-d.html Regards Joachim _____________________________________________________________________________ Dr. Joachim Schmitz schmitz(a)noc.dfn.de DFN Network Operation Center Rechenzentrum der Universitaet Stuttgart ++ 711 685 5553 voice Allmandring 30 ++ 711 678 8363 FAX D-70550 Stuttgart FRG (Germany) _____________________________________________________________________________

1 0

route & aut-num objects
by Schmitz＠RUS.Uni-Stuttgart.DE 14 Feb '97

14 Feb '97

Dear colleagues, let's start with a very easy thing near to solution with hierarchical authorisation for route objects: the relation to aut-num objects. A route object references several other objects. Important to us are the references to the maintainer and the aut-num object (both are mandatory attributes of the route object): route: [mandatory] [single] descr: [mandatory] [multiple] origin: [mandatory] [single] ----> points to aut-num object ... mnt-by: [mandatory] [multiple] ----> points to mntner object changed: [mandatory] [multiple] source: [mandatory] [single] The aut-num object also contains a mandatory reference to a maintainer object. Up to now, the maintainers referenced in route object and aut-num object of same origin need not be the same. For hierarchical authorisation it would be nice to introduce a "mnt-lower" attribute in the aut-num object defining which maintainers may create route objects for the AS of the corresponding aut-num object. This allows control of one AS which parties may generate route objects with its origin. We already had consensus in the wg session that this is needed but did not yet decide precisely how to do it. The idea of using a "mnt-lower" attribute came up and I think it is easiest to implement. If there are no objections I will hand on the above proposal for imple- mentation in the database software in two weeks. For further reference read/attack/tear apart/abuse the compilation at http://www.ripe.net/wg/routing/haro-d.html Regards Joachim _____________________________________________________________________________ Dr. Joachim Schmitz schmitz(a)noc.dfn.de DFN Network Operation Center Rechenzentrum der Universitaet Stuttgart ++ 711 685 5553 voice Allmandring 30 ++ 711 678 8363 FAX D-70550 Stuttgart FRG (Germany) _____________________________________________________________________________

1 0

haro...
by Schmitz＠RUS.Uni-Stuttgart.DE 14 Feb '97

14 Feb '97

Dear colleagues, at the routing wg we continue to discuss hierarchical authorisation for route objects. Since there are several issues involved related to the database and its implementation you are welcome to partici- pate in the discussion (we try to keep the database wg mailing list in the Cc). To make it easier to keep track of the discussion I compiled the current state in http://www.ripe.net/wg/routing/haro-d.html and will keep it updated in (more or less) regular intervals. Your comments are welcome. Regards Joachim _____________________________________________________________________________ Dr. Joachim Schmitz schmitz(a)noc.dfn.de DFN Network Operation Center Rechenzentrum der Universitaet Stuttgart ++ 711 685 5553 voice Allmandring 30 ++ 711 678 8363 FAX D-70550 Stuttgart FRG (Germany) _____________________________________________________________________________

1 0

New Document available: RIPE-153
by RIPE NCC Document Annoucement Service 29 Jan '97

29 Jan '97

Revised RIPE Document Announcement -------------------------------------- A revised document is available from the RIPE document store. Ref: ripe-153 Title: RIPE NCC Database Documentation Author: A. M. R. Magee Date: 28 Jan 1997 Format: PS=788414 TXT=137211 Obsoletes: Version 1.2 of the document. Obsoleted by: Updates: Updated by: See also: Short content description ------------------------- This document is an introduction to the use of the RIPE Network Management Database. Items marked with an "*" are still in production. Questions and comments should be sent to <ripe-dbm(a)ripe.net>. Accessing the RIPE document store --------------------------------- You can access the RIPE document store via the World Wide Web; ripe-153 is available at the following URL: http://www.ripe.net/docs/ripe-153.html The RIPE document store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The full filenames of the new documents on the FTP-server are: ripe/docs/ripe-153.ps for the PostScript version ripe/docs/ripe-153.txt for the plain text version Documents can also be retrieved from the RIPE document store using a mail server program. For more information on how to use the program, send email to <mail-server(a)ripe.net> with "send HELP" in the body text.

1 0

Inverse Query Failures
by Daniel Karrenberg 17 Jan '97

17 Jan '97

I was asked to look into invers queries going wrong in order to determine which additional indices might be useful. I looked at 5245997 recent queries 6236 (0.11%) of which were reverse. Of these 1428 (24.72%) failed because no match could be found and 461 (7.39%) failed because either no attribute name was given or an attribute name which does not have an inverse index was given. Unfortunately no more details are logged about the latter type of failures. We will change that a.s.a.p. and report back if there are signigficant findings. I have looked at the data that was logged and could detect no clear trends pointing to the need for additional indices. Daniel

1 0

RE: Immediate - Date in Changed field
by Wilfried Woeber, UniVie/ACOnet 17 Jan '97

17 Jan '97

Hi DB-folks! On a slightly different aspect, and assuming that we change things anyway... How about running the RIPE-DB (and maybe gradually all the others :-) on a UTC basis, according to some recent suggestions? Just for a sneak preview on one of the small agenda items for the DB WG :-) Wilfried. ~~~~~~~~~~ Dear Database WG members, We have been requested to ease the restrictions on the date in the "changed" attribute to allow for dates with 4 digit years specifically those starting with "19" and eventually "20". For obvious reasons, we agree with this proposition. However, we also understand that some of you may have software which presumes the date has the yymmdd format. If anyone has a serious problem with this change, please notify me personally (orange(a)ripe.net) before the end of the week. If we don't hear any show stoppers before the end of the week, we will proceed. Thereafter, the following will be acceptable formats: 19yymmdd 20yymmdd (eventually) yymmdd Thanks for your ear, -- Carol Orange --------------------------------------------------------------------------------

7 6

Re: hierarchical route objects, part 1
by Schmitz＠RUS.Uni-Stuttgart.DE 16 Jan '97

16 Jan '97

Dear Curtis, you wrote: > > > Here is an example. The registries approve of the top level blocks, > > > that is the aggregates (or blocks that should be announced as > > > aggregates). Whoever the aggregate is allocated to creates the top > > > level route object and can delegate below that. For example, ANS has > > > 207.24/14. There were two route objects needed to handle multihomed > > > (a /22 and a /24) prefixes. The usual way a provider would delegate > > > would be to reference more than one maintainer in the route object > > > (the provider and the customer, and probably the other provider if the > > > route object had a unique origin AS). > > > > > This scheme sounds reasonable but it raises the question of coordination > > among different registries... > > I would not expect to see the same address space allocated by more > than one registry. All registries would have a top level 0/0 route > object which prevents registry of bogons. RIPE would have a hierarchy > under 0/0 and the RA would have a hierarchy tracking InterNIC assigned > addresses. I would not expect the two to overlap, therefore there is > no real coordination problem beyond initial setup or new blocks > allocated to a registry. > This is more difficult than it looks from the beginning. As an example we ourselves register all our objects (inetnum, routes, persons...) in RIPE database (because we are in Europe). However, among others we peer with MCI and MCI insists on having route objects in their registry in order to allow routing. If the route objects are secured by hierarchical authorisation in the RIPE database we would also like to have them secured in the MCI registry. Following the scheme above MCI would have to include inetnums (while it is a pure routing registry) *and* would have to generate top level route objects allowing specific access by us to our route objects (this is a very tiring job especially regarding "the swamp" 192.x). Of course, they could copy from RIPE database... (ask them why they don't...) I guess, this problem may only be resolved by the GRR (which is yet to come) From the ongoing disussion I conclude for myself (at the current state of the discussion) that we can not impose a strict security mechanism at the time being without breaking too many things. Maybe, I am too dumb to see a simple solution which might be just at hand... I will summarise the things said here on the mailing list for the routing wg session next week and try to think some more about it (I guess, Daniel was right from the start when he said that we should begin with a bare notification mechanism...) Regards Joachim _____________________________________________________________________________ Dr. Joachim Schmitz schmitz(a)noc.dfn.de DFN Network Operation Center Rechenzentrum der Universitaet Stuttgart ++ 711 685 5553 voice Allmandring 30 ++ 711 678 8363 FAX D-70550 Stuttgart FRG (Germany) _____________________________________________________________________________

2 1

An AUP for the RIPE DB ?!
by Daniel Karrenberg 16 Jan '97

16 Jan '97

Another short discussion paper. As you see I'd like to keep this general issue separate from the immediate measures discussed in the other paper. Again comments are welcome. Daniel Some Toughts about an Acceptable Use Policy for the RIPE Database Scope This is a discussion paper intended to lay the groundwork for the development of a more explicit acceptable use policy (AUP) for the RIPE database. Motivation For the past six years we have been able to avoid the issue of codifying acceptable use of the RIPE database because the user community was limited. Conventions and peer pressure were sufficient to prevent abuse. This is changing rapidly. Therefore I believe we have to develop a written AUP and enforce it. Format As with any AUP is it difficult to anticipate any potential usage. It is even impractical to codify something for all usages that can be envisioned. In our case a good approach would be to list a number of common usages that are clearly acceptable, such as searching for contact points in case of operational problems or access by routing policy tools. Subsequently we can list a number of usages that are clearly not acceptable such as obtaining addresses for mass mailings or unauthorised changing of data. I think it will be rela- tively easy to obtain consensus about that. One can then state that any use which is comparable to one of those listed falls under the policy for the listed use. Any use not comparable at all will need to be determined by the database WG and added to the AUP. Enforcement If we have a written AUP and consensus that it should be enforced the NCC can get legal advice on how to best enforce it. However I would like to have the AUP defined first because otherwise thinking about enforcement tends to be less effective and also influences our goals, e.g. the desired AUP. Further Steps I'd like to see some discussion and resolution on two issues: Is an explicit AUP needed? and Is the format sug- gested above appropriate?

1 0

Preventing Abuse of Postal&Email Address Info
by Daniel Karrenberg 16 Jan '97

16 Jan '97

Dear colleagues, below you find a short discussion paper with concrete proposals to address some abuse of the RIPE DB which we start seeing. It is input for that point at the meeting next week. Comments welcome. Daniel Short Term Measures to Protect Postal and E-Mail Address Information in the RIPE Database Against Abuse Scope This is a discussion paper about immediate measures to pro- tect postal and e-mail address information stored in the RIPE database against abuse. Mass mailings are the kind of abuse we are focussing on. There is consensus that these activities clearly constitute abuse of the RIPE database. An general acceptable use policy is a separate issue that needs to be addresses separately. Current Situation The database can currently be accessed by WHOIS, WAIS and as FTPable files. A copyright notice appears at the top of the FTPable files: Copyright (c)1992/.../1997 by Daniel Karrenberg and TERENA Restricted rights. Except for agreed Internet operational purposes, no part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, recording, or otherwise, without prior permission of the RIPE NCC on behalf of the copyright holders. Any use of this material to target advertising or similar activities are explicitly forbidden and will be prosecuted. The RIPE NCC requests to be notified of any such activities or suspicions thereof. The access methods most suitable to obtain mass mailing data are the FTP and WAIS access methods. New Trend During first six years of operation no significant abuses of the database have come to our attention. In the past few months however there have been at least two instances where addresses from the have been sold or otherwise re-dis- tributed to address mailings. The NCC has taken appropriate action in these cases. I believe that this is a significant trend and we have to take measures to prevent such abuse in the future. In the following paragraphs I will outline pos- sible measures to that end. Assert Copyright More Prominently Currently the database copyright is asserted only in the FTPable files. Therefore any user of data obtained via other services may claim not to be aware of the copyright. In past discussions I have argued against cluttering WHOIS output with copyright notices. In the light of developments I now recommend to insert a one line copyright notice at the top of each WHOIS response roughly like: % Copyright (c)1997, see http://www.ripe.net/.... for details I have not checked yet whether this is sufficient notice in terms of legal procedures. However a user can then no longer claim ignorance. A similar solution needs to be implemented for the WAIS service. Remove Person Objects from FTP Access Person objects should be removed from public FTP access. This means both removing the person.db file and the person objects from the ripe.db file. The main purpose of these files is to allow mirroring of the database and convenient local access for various purposes. The mirroring function- ality has to be maintained differently. See below for details. The convenience of other uses in my opinion does no longer justify the potential for abuse this convenient public access has. Of course individual access can be granted if the user has a valid reason and agrees not to further distribute. Restrict Access if Abuse is Suspected I would like the database WG to explicitly authorise the NCC to restrict access to the database if abuse is suspected. The restrictions I envisage are artificial exponential delays if query patterns suggest abuse and blocking access for individual users as an ultimate measure. Of course any such measures will be reported back to the database WG. Consequences for Mirror Sites All these measures have little effect if any mirror site does not implement them. Therefore I propose that mirror sites will have to agree formally to implement any restric- tions the RIPE NCC has to implement. Further the mirror sites will have to change the procedure to obtain the person information to a restricted method. Further Steps I encourage everyone to critically read the proposals above and give me feedback, especially on aspects not considered. I ask the database WG to endorse the measures proposed and to give guidance on how they should be published, i.e. does this need to be written up as a RIPE document or is it suf- ficient in the database WG minutes/archives.

1 0

Re: hierarchical route objects, part 1
by Schmitz＠RUS.Uni-Stuttgart.DE 16 Jan '97

16 Jan '97

Dear Curtis, dear David, you both wrote: > > > Your black hat example is also flawed. At the top of the heirachy can > > > be 0/0 registered to IANA and withdrawn (not announced). The > > > registries themselves can have top level objects below that. In order > > > to make any changes, you need to have been given authorization from a > > > higher level. You can then assign authorization to lower blocks to > > > other parties. > > > > This works for IP network objects since the registries need to add these > > objects manually anyway. > > > > This is not that obvious for 'route' objects. Are you proposing that the > > registries have to approve (manually) all the route objects that are > > in the route hierarchy directly below their own allocated space ? > > Tie the hierarchy to the inetnums. Continue to flog the InterNIC for > non-participation in the IRR. The maintainer of a database such as > the RADB that uses InterNIC as the number registry may have to take > InterNIC data (ftp) and load it into inetnum records. I wonder about the effort necessary to do this. Moreover, we should not forget about pure routing registries - they would be forced to include inetnums as well (and I wonder whether they are willing to do so) > > An inetnum references one or more maintainer (in mnt-by). To create a > route object, you must satisfy one of the criteria: > > 1. You must be in the maintainer field in a less specific route > object (used to create route objects for more specific prefixes; > hopefully these get aggregated somewhere ). > > 2. You must be in a maintainer for the exact inet-num and for the > AS that you are putting in the route object (used after the > initial top level route object is created). > > Once a top level route object is created, a more specific route object > can be created and the mnt-by field can reference more than one > maintainer. > > Here is an example. The registries approve of the top level blocks, > that is the aggregates (or blocks that should be announced as > aggregates). Whoever the aggregate is allocated to creates the top > level route object and can delegate below that. For example, ANS has > 207.24/14. There were two route objects needed to handle multihomed > (a /22 and a /24) prefixes. The usual way a provider would delegate > would be to reference more than one maintainer in the route object > (the provider and the customer, and probably the other provider if the > route object had a unique origin AS). > This scheme sounds reasonable but it raises the question of coordination among different registries... Regards Joachim _____________________________________________________________________________ Dr. Joachim Schmitz schmitz(a)noc.dfn.de DFN Network Operation Center Rechenzentrum der Universitaet Stuttgart ++ 711 685 5553 voice Allmandring 30 ++ 711 678 8363 FAX D-70550 Stuttgart FRG (Germany) _____________________________________________________________________________

2 1

RIPE-26, DB-WG, Proposed Agenda, 2nd Draft
by Wilfried Woeber, UniVie/ACOnet 15 Jan '97

15 Jan '97

Dear all! This is the 2nd draft of the proposed agenda for the January 1997 DB-WG Meeting in Amsterdam. I forgot to include the proposed DB copyright item in the 1st draft, my apologies. There's a couple of additional minor changes. As usual any and all comments and input appreciated. See you in Amsterdam, Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Proposed Agenda for the Database Working Group Meeting RIPE-26, January 1997, Amsterdam 2nd Draft, 8.1.1997 A. Administrative stuff (W. Woeber, chair) - volunteering of the scribe - WG-agenda bashing B. DB-SW status report by the RIPE NCC (DB-SW maintainers, RIPE-NCC) - recent changes - recent bug fixes and development (if any) - feedback and experience C. RIPE-DB copyright (D. Karrenberg, RIPE NCC) - proposal to include copyright line in whois output D. Report on DB evaluation by VUA - consistency - usage E. Reports (D. Kessens, ISI) - on RPSL - on 'ride' (registry data exchange format) F. Documentation (DB-SW maintainers, RIPE-NCC) - current status, progress, review, test-driving - availability G. New functionality, proposals, reports - IPv6 object proposal (D. Kessens, ISI) - hierarchical authorisation for route: obj (J. Schmitz, DFN NOC) (**note: this item might be discussed in the Routing-WG and consequently be moved to agenda item Y.) - short report on improving DB security and authentication (**to be confirmed, J. Schmitz, DFN NOC) - extension for inet-rtr: obj (tentatively, W.Woeber/E.J.Bos/et.al.) - extending the list of attributes that can be used in -i lookup? - improved url handling (in HTML interface) - handling of timestamps (changed:, different time-zones, UTC,...) - report on/review of the consolidated wish-list Y. General input from other WGs Z. AOB -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------

4 4

Person-Objects with multiple adresses + phones
by Nacamar AS Guardian 15 Jan '97

15 Jan '97

Hello, there are a number of persons with multiple _entries_ in the RIPE-Database, because they have multiple _adresses_, and I think, this is not handled well with our current implementation. To make this more acceptable for such people, something like the following should be possible: >>> person: Thomas Peters remarks: -- #1 - Main office: address: Thomas Peters address: Nacamar Data Communications GmbH address: Frankfurter Strasse 141 address: D-63303 Dreieich address: Germany phone: +49 6103 9901 14 fax-no: +49 6103 9901 18 e-mail: info(a)nacamar.net remarks: -- #2 - South office: address: Thomas Peters address: Herd-Weg 8 address: D-69198 Schriesheim OT. Ursenbach address: Germany phone: +49 6220 9111 25 fax-no: +49 6220 9111 259 e-mail: peters(a)nacamar.net remarks: -- #3 ... nic-hdl: TP65-RIPE ... <<< This applies too for people working as tech-c for several companies. It should be possible for each address-block to have its own phone/fax/eMail with it. As I understand the operation of the database now, all phone-numbers etc. are collected together, so the relationship to the addresses are lost. Best Regards, HaJo Gurt ------------------------------------------------------------------- Nacamar Network Administration NACAMAR Data Communications guardian(a)nacamar.net Frankfurter Str. 135-141 D-63303 Dreieich +49 6103 9901 ?? Voice Germany +49 6103 9901 18 FAX gurt(a)nacamar.de -------------------------------------------------------------------

4 3

Re: again: hierarchical route objects
by Schmitz＠RUS.Uni-Stuttgart.DE 15 Jan '97

15 Jan '97

Dear all, was my last mail too long? I did not yet see any comments... (or is it that disgusting :-( I hope not ;-) Regards Joachim _____________________________________________________________________________ Dr. Joachim Schmitz schmitz(a)noc.dfn.de DFN Network Operation Center Rechenzentrum der Universitaet Stuttgart ++ 711 685 5553 voice Allmandring 30 ++ 711 678 8363 FAX D-70550 Stuttgart FRG (Germany) _____________________________________________________________________________

1 0