- db-wg - mailman.ripe.net

Hierarchical Authorisation in the RR
by Carol Orange 15 May '97

15 May '97

Hi again, Here is another brief proposal for your perusal. This time for an implementation of hierarchical authorization in the Routing Registry. The mechanism described below will implement a hierarchy in the RR for which I believe there is consensus. The ideas in the proposal below were sifted from discussions which took place on the <routing-wg(a)ripe.net> mailing list and in the Routing WG meetings at RIPE-25 and RIPE-26. Please review this if you have time. We are hoping to have a go ahead on this from the Routing and Database WG's at or shortly after RIPE-27. Greetings, Carol Orange RIPE NCC -------------------------------------------------------------------- Hierarchical Authorisation in the RR Proposal for an Implementation Carol Orange, May 1997 At the January meeting of the Routing WG in Amsterdam, various possible hierarchies for authorization in the Routing Registry (RR) were considered. Whereas extensive discussion took place on the extent to which authority can be established in the RR, there was clear agreement that the maintainer of an AS should have authority over what routes are announced with a given aut-num in the "origin:" attribute. In the following, we specify an implementation to support the authority of "aut-num:" maintainers to determine who can announce routes under their AS. The mechanism can be extended as the need arises and consensus on other forms of authorization is achieved. For more information on the discussions leading up to this proposal, see: http://www.ripe.net/wg/routing/haro-d.html. Implementation -------------- If you (or your organization) manages an AS, then you should have authority over the routes announced in your AS. This can be implemented if we: a) add a "mnt-lower:" attribute to the aut-num object b) allow routes to be announced with a given "origin:" by those given authority as defined in the mntner object specified in the "mnt-lower:" attribute of the aut-num object. Example ------- If we add a "mnt-lower:" attribute to the aut-num object of the RIPE NCC, then only those who know what peEw8Gb4xBNqI encrypts can add and remove routes originating in AS3333. ---- aut-num: AS3333 ... mnt-lower: AS3333-MNT ... ---- mntner: AS3333-MNT descr: RIPE-NCC Maintainer ... auth: CRYPT-PW peEw8Gb4xBNqI ... ---- route: 193.0.0.0/23 descr: RIPE-NCC origin: AS3333 ... Summary ------- Other forms of hierarchical authorization and notification can be implemented in the future if a well defined hierarchy can achieve consensus. To provide some initial functionality which may meet the needs of many RR users, we propose to implement the above in the short term.

2 2

Re: whois -v option.
by Steven Bakker 15 May '97

15 May '97

==> From: RIPE Database Administration <ripe-dbm(a)ripe.net> ==> Thu, 15 May 1997 13:02:17 +0200 > To use "whois -v", you will need a new whois client. The new > version of the whois client is available at > > <ftp://ftp.ripe.net/tools/ripe-whois-tools-2.1.tar.gz> And it still goes "boom" when you try to use "whois -v" or "whois -t": kappa-~ & whois -v netnum zsh: 5855 segmentation fault (core dumped) whois -v netnum I have a patch for it (incidentally identical to the one I sent in last September ;-), which I'll attach below. It's basically a tiny error in the argc/argv handling. Cheers, Steven

2 1

X-Notification in the RR
by Carol Orange 15 May '97

15 May '97

Hi all, The following is a proposal for a cross notification mechanism in the Routing Registry. I post it for your perusal and hope to discuss it during the Routing WG meeting in Dublin. The initial suggestion was made by Daniel Karrenberg at the Routing WG meeting in January, and discussions with Joachim Schmitz and Wilfried Woeber have helped me work it into the following proposal. Such a mechanism was given a high priority by those who participated in the recent RIPE Database priority survey, so we are hoping to reach consensus on this at or shortly after RIPE-27. Greetings, Carol Orange RIPE NCC ---------------------------------------------------------------------- Cross Notification in the Routing Registry A Proposal Carol Orange, May 1997 At the January meeting of the Routing WG in Amsterdam, various possible hierarchies for authorization in the Routing Registry (RR) were considered. During the discussion, a suggestion was made that "hierarchical notification" would be useful even in cases where authority is not well defined. This suggestion enjoys strong support of both the Routing WG and the Database WG. In the following, we propose a simple cross notification mechanism which will allow routing registry users to be notified of overlapping route announcements in the RR. Route Announcement Notifications in the RR ------------------------------------------ Suppose you announce a route in your address space covering some /24. It may be useful when you make the announcement, to know that the /24 has already been announced in another AS. Likewise, should the user of that address space later decide to become multi-homed, it may be interesting to know that as well. Moreover, overlapping routes are often unintentionally announced in a single AS. In all of these cases, it would be useful to get a notification from the RR. Consider the route object: route: [mandatory] [single] [primary/look-up key] descr: [mandatory] [multiple] [ ] origin: [mandatory] [single] [primary key] hole: [optional] [multiple] [ ] withdrawn: [optional] [single] [ ] comm-list: [optional] [multiple] [ ] advisory: [optional] [multiple] [ ] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] Suppose we add a new field called "x-notify:" (cross-notify) which a) can contain either + a NIC-handle pointing to a person or role object, the email address of which will get the notification; or + a mntner ID pointing to the maintainer who will be notified b) is optional The contact in "x-notify:" will receive an e-mail whenever + a route is announced with overlapping address space + the address range in the route being added (with the "x-notify:" attribute) overlaps any address space currently announced in the RR. Issues ------ Does this cross notification satisfy the needs of network operators? Due to the global nature of the RR, some effort will be involved to provide notifications in a timely manner. What is an acceptable upper bound for cross notifications to be sent out? Using a NIC-handle or mntner for notification is different than the traditional e-mail address. However, it simplifies data maintenance for users significantly.

1 0

nic-hdl mandatory
by RIPE Database Administration 15 May '97

15 May '97

Dear Colleagues, The nic-hdl attribute is now mandatory in the person object. If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

1 0

A DNS Database Referral Mechanism
by Carol Orange 14 May '97

14 May '97

Hi all, Below is a proposal put together by Wilfried Woeber and myself to address the need for a referral mechanism for domain name queries in the RIPE database. The mechanism is designed to address the immediate needs of those trying to get domain related information, and of DNS administrators trying to provide it. Certainly the mechanism may be adapted with time (see the three options below), however we choose to start with something that can provide the required functionality immediately. We hope to discuss this proposal on the mailing lists and in the database and dns working group meetings in Dublin. Carol Orange RIPE NCC --------------------------------------------------------------------- RIPE Database Referral Mechanism for Domain Queries - A Proposal Carol Orange & Wilfried Woeber, April 1997 ------------------------------------------ In the following, we propose a mechanism for forwarding whois queries to the appropriate database if the RIPE database does not contain the authoritative data for a given tree in the DNS name space or subset thereof. It is thus applicable for the "domain" object only: domain: [mandatory] [single] descr: [mandatory] [multiple] admin-c: [mandatory] [multiple] tech-c: [mandatory] [multiple] zone-c: [mandatory] [multiple] nserver: [optional] [multiple] sub-dom: [optional] [multiple] dom-net: [optional] [multiple] remarks: [optional] [multiple] notify: [optional] [multiple] mnt-by: [optional] [multiple] mnt-lower: [optional] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single] The goal of the mechanism is to provide a means for TLD domain administrators (and other "high-level" domains) to enable users to obtain an authoritative response for a domain object query sent to the RIPE database, regardless of whether the data for the domain is maintained in the RIPE database itself. Algorithm --------- If the following query is submitted to the RIPE database: whois [flags] xxx.yyy.zz the algorithm will work as follows: ------- NAME="xxx.yyy.zz" until (NAME = "") { If object with domain = NAME found, If object contains referral (see "Referral" below) forward query (see "Forward" below) Else return object Else Strip(NAME) (xxx.yyy.zz -> yyy.zz, etc) } NOTES ----- 1. We move up the tree here, and return the next level answer if present. If the query requests "tuintje.cwi.nl" (Piet, do you mind?), they currently get "No entries found ...". In the new mechanism, they would get: domain: cwi.nl . . . mnt-by: NL-DOMREG changed: hostmaster(a)domain-registry.nl 19950227 source: RIPE Moreover, if the object for cwi.nl contains a referral, the query would be passed on to the specified server as explained below. 2. The algorithm will be set off by any query which causes a search in the domain object index. This means any query with "-T domain", or any general query (no -T flag) with something that "looks like a domain". Referral -------- A whois referral can be entered in a "refer" attribute by specifying the type of database in which the data is maintained, and the domain name of the server that should be queried: refer: <type> <host> <port> where <type> is one of RIPE, InterNIC or SIMPLE, indicating which style of whois service is provided. <host> is the DNS name of the whois service. <port> is the TCP port number (optional: 43 is the default). Examples: (CWI again): refer: RIPE domain-registry.nl 43 (InterNIC): refer: InterNIC whois.internic.net (Generic): refer: SIMPLE my.dns.tld Initially queries for the three types of databases shown here would be supported. If RIPE is specified, then the initial query together with all arguments would be passed to the specified whois server. If an InterNIC database is specified, then a query expected by the InterNIC database software would be generated for the specified domain name. The same would be true of "SIMPLE". In that case a simple query for the domain name would be passed on. If in the future, another domain name database is implemented with a given query language, it can be added. Forward ------- If the TLD object contains a whois referral, we can a) query the server, and pass the response to the requester, preceded by a comment of the form: "The following data has been obtained from domain-registry.nl". b) pass the referral to the requester c) send the query to the server with the address of the requester a) has the advantage of giving the user an immediate answer, and requires that only the RIPE database software be modified, not that of the TLD admins. Nothing has to be changed there. a) has the disadvantage that the RIPE server can become a bottleneck. However, local mirrors of referred to databases can be set up on a RIPE NCC server to alleviate this problem. Summary ------- We propose the above mechanism with (option (a) request forwarding) be used for TLD/domain referrals. We believe it will make the domain part of the database more transparent to users and easier to manage for TLD administrators. Acknowledgements ---------------- We would like to thank Chris Fletcher, Daniel Karrenberg, and David Kessens for useful comments.

3 6

Re: A DNS Database Referral Mechanism
by Wilfried Woeber, UniVie/ACOnet 14 May '97

14 May '97

Hi Carol, Blasco, Piet et.al.! >We actually discussed this point a bit in a slightly different light. >An important question is: should the forward type be up to the object >maintainer, to the whois server providing the referral (in this case >RIPE), or the whois client, or end user. > >As proposed here, it is the whois server, but could be modified in the >future to also be the whois client. > I think this touches on a line of discussion that we already began a while ago, but became forgotten later: What's the mechanism and who does maintain (e.g. supply, control, register) the necessary information? >The object maintainer can in fact always prevent automatic request >forwarding by putting the referral information in a remarks field. > >However, if such a mechanism should become popular, then it may be >suitable that whois clients be developed that can parse the refer >field and resend the request to the appropriate server. If we allow >the object maintainer to determine this in the <forward-type> field, >then it actually limits flexibility in the future. When and if we decide to eventually implement that flexibility (and we already had some private exchange on this aspect), then my first reaction would be to move that to some sort of maintainer object!? Initially, given the small set of affected objects, this can probably be sorted out infomally, but as soon as we open the flood gates... >Or is my thinking twisted? I don't think so, but mine might be :-) Wilfried.

1 0

A DNS Database Referral Mechanism
by Wilfried Woeber, UniVie/ACOnet 13 May '97

13 May '97

>Subject: A DNS Database Referral Mechanism >Date: Tue, 13 May 1997 10:44:31 +0200 >From: Carol Orange <Carol.Orange(a)ripe.net> Dear Carol! >Hi all, > >Below is a proposal put together by Wilfried Woeber and myself to >address the need for a referral mechanism for domain name queries in >the RIPE database. Thank you very much for putting that into proper wording and having it distributed to the groups. I feel it is appropriate to add that, while Carol and me did some finishing and sanity checking, we already received a considerable amount of very valuable comments and ideas from quite a few others. A big thank you to all of them! I thus urge the community to have a focussed discussion of the proposal, leading to a conclusion and implementation decision at the DNS & DB-WG meeting(s) is Dublin. Thanks, 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

NIC-Handle Mandatory.
by RIPE Database Administration 06 May '97

06 May '97

Dear Colleagues, >From 15th May, new person objects must have a NIC-handle. Normally, RIPE nic-hdl's are used. RIPE format NIC-handle's may be obtained using the "AUTO-1" process (see below). If a person being registered in the RIPE database currently holds a registered NIC-handle assigned by the the InterNIC or the APNIC, it can be used as the NIC-handle in the RIPE database person object. If, in conjunction with the work on registry database exchange taking place in the RIDE working group of the IETF, the list of databases, and in particular the list of acceptable NIC-handles should be expanded or otherwise modified, the above statement will of course be modified accordingly. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration. How to get a RIPE NIC-Handle ------------------------- You can get a RIPE NIC-handle by putting the following in the NIC handle field of the person object update: nic-hdl: AUTO-1 OR nic-hdl: AUTO-1YourInitials The second case advises the database software to use YourInitials (no more then 4 characters) for build- ing the NIC handle while the first case asks the database software to find the initials itself. You can use the same identifiers (AUTO-1 or AUTO-1YourInitials) in the same update message in other objects as a reference. The database software will then fill in the freshly assigned NIC handles in the objects. Note that you can also use other numbers (example: AUTO-2) so that you can update more person objects and objects that reference the persons in one E-mail message. Example: domain: over.ripe.net admin-c: AUTO-1 tech-c: AUTO-2 [ ... stuff deleted ...] person: Ambrose Magee nic-hdl: AUTO-1 [ ... stuff deleted ...] role: RIPE DBM nic-hdl: AUTO-2 [ ... stuff deleted ...] N.B. To obtain a NIC-handle for a role object, use the same procedure as for a person object. Further information is available from: <http://www.ripe.net/docs/ripe-153.html> <ftp://ftp.ripe.net/ripe/docs/ripe-153.ps> <ftp://ftp.ripe.net/ripe/docs/ripe-153.txt>

1 0

Inaddr Robot <auto-inaddr@ripe.net>
by Carol Orange 22 Apr '97

22 Apr '97

Dear All, First off, my apologies to all who get more than one copy of this message. I'm hoping not to miss anyone who may be effected. As many of you may know, we have long been planning to more fully automate our inaddr robot <auto-inaddr(a)ripe.net>. Well, we've gotten around to it and are happy to announce we will soon be doing almost all processing automatically, with just a touch of human intervention at the end to make certain our robot behaves as expected. The result will be a substantial reduction in rather tedius work for the NCC staff, and consistent short response times (one working day) for inaddr requests. The new robot, programmed by Mal Morris, will be installed on *** Tuesday, May 6, 1997 *** It is essential that users take the following changes into account: 1. The domain or inetnum database object must be in the RIPE database before the request is submitted to <auto-inaddr(a)ripe.net>. 2. As is required in ripe-140 (Section 3.4.2), the "status" field must be filled in properly for any inetnum associated with the request. The robot will complain and fail if either of these does not hold. We hope the new robot serves you well, Carol

1 0

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

18 Apr '97

David, => 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? = =Please, don't get me wrong: I don't have a problem with John's proposed =feature but I wanted to make clear which trade-offs are made and that =there are certainly a few disadvatages involved that might not be obvious =at first sight. that was perfectly understood here. Cheers, 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

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