- db-wg - mailman.ripe.net

RE: Default behaviour for referred domain queries
by Mike Norris 06 Oct '98

06 Oct '98

In coincidence with your input, the db-wg also found that whenever the server shows data from a remote server instead of the local data in response to a query, the response should be preceded by a notice clearly informing the user that the information being displayed is coming from another server that contains the authoritative data. Right. It was also noted that the original proposal did not provide a way to look at the "local" object if it contained a refer attribute. In order to avoid potential confusion from a mode of operation where two objects are displayed, it would be better to provide a whois flag (-R was agreed) that would disable the referral and show the local object. Bear in mind that there could be multiple referrals involved i.e. the process is recursive. Suppose the query is for a third-level domain, that the second-level domain is referred from the RIPE DB to a TLD registry server, and that the target domain is referred onward from the TLD server to an ISP's whois server. Now what will the -R flag deliver - the local object in the RIPE DB? That'll give you the coordinates of the TLD server, which you again query with -R to get the ISP 'local' object. Regards. Mike

1 0

Default behaviour for referred domain queries
by Niall O'Reilly 05 Oct '98

05 Oct '98

I'ld like to give input as requested on this topic. For the TLD people who may have missed the DB session, here is first a brief description of how the referral feature works. I don't know the details at this stage. When a request is received by the "central" server for a domain object marked (locally) for referral, the query is referred to the authoritative server and the data from the authoritative server is returned to the client. If the domain object requested is not found on the "central" server, the specified domain name is truncated (successively, if necessary ?) until a higher-level domain is found to be marked for referral, and the query is then referred to the authoritative server for that (higher-level) domain. The following suggestions seem to be almost agreed, but need to be written down. By default, the response returned to the client for a referred query should include the following elements: Alert that referral has been used Response from authoritative server I expect that the authoritative response will include a copyright and/or AUP banner from the authoritative server, but this is the responsibility of the authoritative registry, and not of the registry providing the referring server. I expect that a 'verbose mode' will provide a response including the following elements: Response from referring server as if no referral was used, including referring registry's standard (C)/AUP banner Alert that referral is spin effect for the domain in question Response from authoritative server Whichever of the modes described above is used, it should be possible to specify whether recursive lookup and display of related person/role (and in future, nameserver) objects is to be done. IHTH, Niall

2 2

Re: NIC handle writeup
by Wilfried Woeber, UniVie/ACOnet 02 Oct '98

02 Oct '98

[ Apologies for prematurely pressing send. It's Friday afternoon :-( ] => "%" still has mail-related connotations though, although far less so than => "@". => => How about ":"? JA39:APNIC.NET doesn't look like an e-mail address or a DNS => name. It does however look slightly remotely like a URL ;) = = ":" not only has URL significance, its also used w/ IPv6 in the = address. IMHO a poor choice. I don't think that we're going to find any character which isn't badly overloaded already... => Or have I misunderstood the point you were making? = = I think so. Back up a bit and take the 10,000m view. Yup: why do we need a special character at all? Grab a handle, which simply must not contain the "." character, and extend that with the DNS-part as proposed. Done. And it is known to work (DNS SOA record) My good old WW144 would then simply become WW144.INTERNIC.NET. = There are three classes of Internet intangibles that = can be delegated, ASN's, Prefixes, Port numbers. (there = are others, but these will do for this purpose) = = The recipiants of these delegations can be people (admin-c/tech-c), = hosts (HST), organized groups (mntner & role accounts) While this is probably off-topic, I suppose you are mixing organisations and contact information here... = I could make the case that the mntner:, admin-c:, tech-c:, = mnt-by:, nic-hdl:, and the HST (C8-HST) are all, in a very = real sense, NIC HANDLEs. They specify a relationship between = Internet resources and those who are authorized to manage the = delegation relationship. I have to disagree. - We do have mechanisms to describe the privilege(s) for maintaining objects. - And we do have mechanism to get in touch with persons (or helpdesks or NOCs) for operational purposes. = Here, I expect that the handle: = = WM110 = WM110-NSI = WM110-ARIN = = all reflect me, first under the SRI-NIC, then Internic/NSI, then = ARIN. I would hope the design of NIC-handles would allow migration = of data between registries as well as allow for a deeply nested = registration heirarchy. What we've learned from past (failed) attempts: - don't try to mix the issue generating globally unique identifiers with - the issue of data exchange between registries As soon as we've sorted out the first one, we can try to work on the second one. Having the first one done is not going to interfere with solving the other issue, I suppose :-) Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB (&NIC) Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 --------------------------------------------------------------------------

1 0

Re: NIC handle writeup
by Wilfried Woeber, UniVie/ACOnet 02 Oct '98

02 Oct '98

From: MX%"bmanning(a)ISI.EDU" 25-SEP-1998 20:56:00.16 To: MX%"jabley(a)clear.co.nz" CC: MX%"db-wg(a)ripe.net" Subj: Re: NIC handle writeup From: bmanning(a)ISI.EDU Subject: Re: NIC handle writeup To: jabley(a)clear.co.nz (Joe Abley) Date: Fri, 25 Sep 1998 11:50:08 -0700 (PDT) CC: db-wg(a)ripe.net > "%" still has mail-related connotations though, although far less so than > "@". > > How about ":"? JA39:APNIC.NET doesn't look like an e-mail address or a DNS > name. It does however look slightly remotely like a URL ;) ":" not only has URL significance, its also used w/ IPv6 in the address. IMHO a poor choice. > > > The only thing that > > > really matters is if we can find the data and that it improves the > > > current situation. > > > > Thats two things. While desirable, the thing that I thought > > NIC handles did was to identify an entity that was responsible > > for some delegated level of responsibility. > > > > This could be a host, person, role, or organization that > > accepted the responsibility over some delegated Internet > > resources (numbers & lables). > > In ripe-181 the habit seems to have been to put contact fields (tech-c, > admin-c) in every record where contact was appropriate, so contact details > via NIC handles are immediately available. In other words, the drill down > path of (for example) inetnum -> netname -> admin-c/tech-c isn't necessary > since there are direct relationships inetnum -> admin-c and inetnum -> tech-c. > > Has this changed significantly in RPSL, so that it is now important to have > netname-type fields which have registry-internal and registry-external > representation? > > Or have I misunderstood the point you were making? I think so. Back up a bit and take the 10,000m view. There are three classes of Internet intangibles that can be delegated, ASN's, Prefixes, Port numbers. (there are others, but these will do for this purpose) The recipiants of these delegations can be people (admin-c/tech-c), hosts (HST), organized groups (mntner & role accounts) I could make the case that the mntner:, admin-c:, tech-c:, mnt-by:, nic-hdl:, and the HST (C8-HST) are all, in a very real sense, NIC HANDLEs. They specify a relationship between Internet resources and those who are authorized to manage the delegation relationship. > > So each of these things would > > have an unambigious lable that could be tied to an assignment > > of responsibility. Those lables should be consistant, regardless > > of where they are listed. They should also have some token that > > indicates the listing origin and may include a method for > > determining the level of trust on the listing. Here, I expect that the handle: WM110 WM110-NSI WM110-ARIN all reflect me, first under the SRI-NIC, then Internic/NSI, then ARIN. I would hope the design of NIC-handles would allow migration of data between registries as well as allow for a deeply nested registration heirarchy. --bill -------------------------------------------------------------------------------- Return-Path: <owner-db-wg(a)ripe.net> Received: from ns2.univie.ac.at by access.cc.univie.ac.at (MX V4.1 VAX) with SMTP; Fri, 25 Sep 1998 20:55:55 MET-DST Received: from postman.ripe.net (postman.ripe.net [193.0.0.199]) by ns2.univie.ac.at (8.8.8/8.8.8) with SMTP id UAA56164 for <woeber(a)cc.univie.ac.at>; Fri, 25 Sep 1998 20:55:54 +0200 Received: (qmail 918 invoked by alias); 25 Sep 1998 18:55:23 -0000 Delivered-To: lists-db-wg-out(a)lists.ripe.net Received: (qmail 916 invoked by uid 66); 25 Sep 1998 18:55:23 -0000 Posted-Date: Fri, 25 Sep 1998 11:50:08 -0700 (PDT) Message-ID: <199809251850.AA08047(a)zed.isi.edu> In-Reply-To: <19980925102909.B15327(a)clear.co.nz> from "Joe Abley" at Sep 25, 98 10:29:09 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-db-wg(a)ripe.net Precedence: bulk

1 0

Re: NIC handle writeup
by Havard.Eidnes＠runit.sintef.no 25 Sep '98

25 Sep '98

> I think that there will be problems with "@" as the > seperator. It's too much like a viable email address. I > applaude the use of the domain name on the right and a > domain specific unique handle on the left, the concern is > the seperator. Howabout something like "%"? I fully agree. Another option could be ":". Then there is the already established practice of using "-" (as in RIPE's case), I don't see what's so terribly wrong with that. Making NIC handles into something which could be mistaken for an e-mail address just leads to confusion. (No, I don't think it's such a great idea to provide automatic mail forwarding service by the registry.) I also don't think it's such a great idea to use domain names to identify the origin of the data; I think a separate name space should be used instead, e.g. one which could provide more permancence. (As Bill mentioned, what do you do when a registry closes down and its corresponding domain name is subsequently removed?) - Håvard

3 2

Slides from RPS Authorization and Replication Talks
by Cengiz Alaettinoglu 24 Sep '98

24 Sep '98

Hi, As some of you already requested, my slides, both on authorization and IRR distribution, are available at: http://www.isi.edu/~cengiz/talks/ RPSL tutorial slides are available at: http://www.isi.edu/ra/rps/training/ Regards. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute http://www.isi.edu/~cengiz University of Southern California

1 0

Re: Cc: in <auto-dbm> replies
by Steven Bakker 14 Sep '98

14 Sep '98

>>>>> On Fri, 11 Sep 1998, "j" == johnpc(a)xs4all.net wrote: j> The return address from auto-dbm is already something else, not auto- j> dbm itself (it's not nobody, it is in fact a human whose "d" key must j> get more sore than the fire button in a cheap shoot-em-up game from j> all the bounces). (You might've noticed by actually looking at an j> auto-dbm reply! :) j> However, if you start copying Cc: lines, you're in trouble. Think j> about it a little and you'll figure it out. Like: To: johnny(a)rotten.net Cc: auto-dbm(a)ripe.net I agree that replying to Cc: is not a good idea, I'd prefer to use Reply-To:, but note that even then it's still possible to "sewiously scwew up", although accidental screw ups are less likely. However, since the From:- address on a auto-DBM reply is always the same, can't you filter out:- "To: auto-dbm" & "From: ripe-dbm" -> bitbucket Or am I missing something extremely obvious here? Like, does the "ripe-dbm" account ever need to send update messages to "auto-dbm"? Furthermore, the classic way of detecting mail loops is by looking at the "Received:" headers. Your MTA should be able to handle that all by itself, no need to program the RIPE DB for it... Of course, none of the above would protect you from forwarders that strip/modify headers... :-( Cheers, Steven

1 0

whois output and the "changed" line.
by RIPE Database Administration 11 Sep '98

11 Sep '98

Dear Colleagues, Recently, the output of our whois server was modified; the "changed" information is not shown by default. To see it, the new "-c" flag must be used. This requires using the new RIPE whois client. The "changed" information was removed from the default output of whois after a discussion on the mailing list of the RIPE Database Working Group. This discussion was about the funtionality of the "changed" line. A long-term replacement for it (i.e. timestamping of updates) is planned. However, there is the possibility that the existing "changed" lines can be accidently deleted from objects. When users want to update an object, they do a whois look-up and re-direct the output into a temporary file. Then, they edit the file and send it to <auto-dbm(a)ripe.net>. Thus, before the output of the whois server was modified, the update contained all the previous changed fields. Now, unless the user does "whois -c", the "changed" attributes are not shown. But when users want to update an object, they re-direct a whois look-up into a file, edit it and then send it to the database. However, this time, the "changed" lines are missing and the updated version of the object does not contain the previous "changed" lines. This behavior is what would have happened previously if you had sent an update to the db and had deliberately omitted the changed lines. (BTW, if you send an update to the db which only has a new "changed" attribute or has all the old "changed" attributes replaced with a new one, a NOOP is the result. The object in the db is not changed). If all the original "changed" information in an inetnum object is not retained, there may be a delay in getting reverse delegation for the associated address space. This is because <auto-inaddr(a)ripe.net> checks the date when the assignment was originally made and compares it to the assignment window which the local registry had on that date. Thus, the request for reverse delegation is processed manually. So, to keep all the "changed" attributes, do 'whois -c' when you are making a copy of the object before updating it. If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

2 1

Re: Cc: in <auto-dbm> replies
by kissg＠sztaki.hu 11 Sep '98

11 Sep '98

> > I think the database should send any outgoing mails > > with sender address <nobody(a)no.where.ripe.net> or similar Dear Carsten, > come on, you're kidding, aren't you? This would mean to expand > Usenet's bad habits to RIPE email answers. That doesn't seem to > be a really good idea... I just say that *automatic* aswers should be blocked. However I don't think to hide the real sender as spammers do. Any human intelligence can find out easily where the mail came from if the RFC822 header contains a Sender: or X-This-Mail-Really-Came-From: ;-) line. So this header looks absolute correct for me: To: <as required> Cc: <as proposed> From: bit-bucket(a)ripe.net (Do not reply this address) Sender: ripe-db(a)ripe.net (RIPE database engine) X-Comment: This is an acknowledgement, not intended to be replied. Regards Gabor

1 0

Re: Cc: in <auto-dbm> replies
by kissg＠sztaki.hu 11 Sep '98

11 Sep '98

> The suggestion and motivation is excellent, but there are nasty side > effects in practice: > > Including the Cc: field is a nice way to create mailloops. > When the 'Cc:' address would be used too, there is no way for the > database to break the loop since the 'Cc:' address is set by the user > and can possibly contain the automatic mail address of the db and/or > a (local) alias to the db. Hi, David! I think the database should send any outgoing mails with sender address <nobody(a)no.where.ripe.net> or similar nonexistent address. This would break any mailing loop. This is acceptable for humanoid recipients too because generally they don't want to reply the notifications and acknowledgements. Regards Gabor

3 2

Re: Cc: in <auto-dbm> replies
by Gunnar Lindberg 11 Sep '98

11 Sep '98

Actually, if you're already in the "parse 822 addresses" business (Reply-To: is one of them - possibly one of the more controversial) then one would assume you've been through most of the "who am i" problem already. Otherwise I'd be happy to share my copy of UCBMail, 1985, with you; many years later it has actually learned that I am <lindberg(a)cdg.chalmers.se>, not bad, right :-). Sorry, but I couldn't resist :-). Point taken, workaround noted, you <auto-dbm> folks probably have enough things to do anyway. Gunnar >From: johnpc(a)xs4all.net >Date: Thu, 10 Sep 1998 23:57:20 +0200 >To: David Kessens <davidk(a)ISI.EDU>, > Gunnar Lindberg <lindberg(a)cdg.chalmers.se> >Cc: db-wg(a)ripe.net >Message-ID: <19980910235720.D28191(a)xs3.xs4all.nl> >Subject: Re: Cc: in <auto-dbm> replies >On Thu, Sep 10, 1998 at 06:18:17PM +0000, David Kessens wrote: >> > Folks, I'm not on this list but <ripe-dbm(a)ripe.net> suggested I send >> > the idea to you. Right now I hope there is no spam-filter :-). >> > >> > My suggestion: >> > >> > Could you please make <auto-dbm(a)ripe.net> keep the Cc: list and >> > return responses to everybody on it (as well as everybody on To:). >> >> Currently, The 'From:' field (note: not the 'To:' field) is used which >> is a field that is set by the user upon arrival of the update message >> and set by the db after sending the message as the human mail box of >> the database. >I've just tested, and it seems the Reply-To: field is used if present. >So if you want to get the ripe-dbm to reply not only to you, but to >your coworkers as well, simply send the mails using: >Reply-To: you(a)w.ork.com, orkers(a)cow.ork.com > >> When the 'Cc:' address would be used too, there is no way for the >> database to break the loop since the 'Cc:' address is set by the user >> and can possibly contain the automatic mail address of the db and/or >> a (local) alias to the db. >You could break the loop by putting all the Cc: addresses in the To: >field, which isn't examined by the db. Well, unless seriously broken >mailers but the addresses back in the From: or the Cc: lines. But >then there's... > >> With the volume of mail that RIPE receives, broken mail systems and >> user errors like this do happen and would result in an unstable db >> system which is not very desirable. >You're RIPE, right? Just reclaim their IP space and add it to RFC1918/RFC1597 >:) (oh, wait, this ISN'T bofh.general? :) >-- >#! ##### Jan-Pieter Cornet ##### <johnpc(a)xs4all.net> ##### perl >++$_;$!=$_+++$_;($:,$,,$/,$*)=$!=~/.(.)...(.)(.).(.)/;$!=$_+$_; >($(a),$\,$~)=$!=~/(.)(.).(.)/; $_="$,$/$:"; $@++; $~="$~$_";($_)= >\$$=~/\((.)/;$|=++$_;$_++;$|++;$~="$~ $@$:";`$~$/$\$*$, $|>&$_`

1 0

Cc: in <auto-dbm> replies
by Gunnar Lindberg 10 Sep '98

10 Sep '98

Folks, I'm not on this list but <ripe-dbm(a)ripe.net> suggested I send the idea to you. Right now I hope there is no spam-filter :-). My suggestion: Could you please make <auto-dbm(a)ripe.net> keep the Cc: list and return responses to everybody on it (as well as everybody on To:). Motivation: Sending a request with a Cc: is usually because you want other people to be aware of what happens. Since <auto-dbm(a)ripe.net> doesn't keep Cc: that doesn't work and you have to forward the response manually. Now, of course *I* NEVER forget such a thing, but others do... :-). Gunnar Lindberg

3 2

1. draft, proposed agenda for DB-WG Mtg @ Edinburgh
by Wilfried Woeber, UniVie/ACOnet 28 Aug '98

28 Aug '98

Attached plese find the 1st draft of the proposed agenda for the DB-WG meeting during RIPE#31 in Edinburgh. As always, comments and suggestions more than welcome! In particular, please get in touch with me asap in case you want to get a slot for a presentation! Looking forward to see many of you in Edinburgh! Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB (&NIC) Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 -------------------------------------------------------------------------- Proposed Agenda for the Database Working Group Meeting RIPE-31, September 1998, Edinburgh 1. Draft, August 27, 1998 A. Administrative stuff (Wilfried Woeber, chair, 5min) - appointment of scribe - agenda bashing B. RIPE DB, operational update (RIPE NCC) - statitics, performance, changes - most recent mod.s: cross-notification handling of changed: referral - RPSL status, usage - mirror systems at other registries' sites C. RIPE DB, software development status (RIPE NCC) - done, being worked on, in the queue D. DB SW Re-implementation (RIPE NCC) - status, milestones/roadmap, resources required/available E. I-D draft-zsako-ripe-dbsec-pgp-authent-00 (Janos ? [Joao]) F. PGP deployment in the RIPE DB (RIPE NCC) - licenses, support G. ripe-157++ - who, how & when H. I-D draft-ietf-rps-auth-01, -rps-dist-?? (Cengiz ?) - RIPE region requirements/comments X. Chicago IETF report(s) ? Y. Input from other WGs - t.b.d. Z. AOB WW, 28-AUG-1998 00:19:01

1 0

New beta version of the RIPE DB
by Joao Luis Silva Damas 21 Aug '98

21 Aug '98

Dear all, we are happy to announce a new beta version of the RIPE DB. The major change in this release is the introduction of support for an additional authentication method, which in this case uses PGP. The previous authentication methods were NONE, MAIL-FROM and CRYPTPW. The new method is called PGPKEY and is described in draft-zsako-ripe-dbsec-pgp-authent-00.txt internet-draft (available at the usual places, eg. ftp.ripe.net). This draft reflects the work done by the RIPE Database Security Task Force up to this moment. The code is not available for download at this moment. There is a setup so users can experiment with it. * Queries can be done using a whois client pointed to the beta database at beta-whois.ripe.net port 43. * Updates can be sent to auto-beta(a)ripe.net The current setup contains only maintainer objects (a copy of the real ones as of yesterday) which are necessary to experiment. The draft is not yet fully implemented in this beta release (some checks are not done) but it allows operational experience. The code is beta quality and may have bugs. If you find any, please report them to ripe-dbm(a)ripe.net. The messages will however not be answered as fast as normal ripe-dbm. We will issue a new beta release soon and a final release is planned before RIPE31. Details about licensing PGP (free) for use with the RIPE Database will also be made public soon. If you have any questions, don't hesitate to ask. Happy testing, Joao Damas RIPE NCC

1 0

IRRd source code release
by Gerald Andrew Winters 18 Aug '98

18 Aug '98

For those who are interested we are announcing our first IRRd source code release which can be found at the following location: http://www.merit.edu/radb/irrd We will be updating the source code periodically with bug fixes, feature enhancements, etc... Each new IRRd release will be tagged with the version number to distinguish it from prior releases. The current code release is version 1.0. We wish to thank those people who have already begun to test IRRd and we continue to solicit users who feel they might be interested in the IRRd software package. -- IRRd Development Team <irrd-support(a)merit.edu>

1 0

"Changed:" field
by Andrey Petukhov 17 Aug '98

17 Aug '98

Dear Colleagues, I'd like to propose new behavior of the "Changed:" field of the database objects. It would be more convenient if database (or its front-end robot, processing requests from mail messages) sets value of the "changed:" field itself using "From:" field of the mail header/envelope. Database could contain "changed:" information in three modes depending of user needs: 1. Only one record, reflecting last change. 2. Two records, reflecting event of the creation of the object and "last changed" event. 3. Full history of the changes. The first record means "created", and next records reflect every change, sorted by date. The mode of the "Changed:" field can be described in the "mntner" object and is applied to all objects controlled by this mntner. The default behavior of this field applied to objects without mntner. In all cases the field(s) "changed:" have form "Changed: <e-address> <date>", as it is now, but <e-address> is retrieved from mail header/envelope with appropriate authorization checks (it is being done now), <date> is current date of the modification. There is no need to store changes itselves, that is subsequent versions of the object are not stored. Best Regards, -- Andrey Petukhov (AP9-RIPE) Phone: +7 095 705 9229 Systems Engineer Fax: +7 095 929 9363 Global One Russia (RoSprint) Mailto:pooh@ipnms.rosprint.net

1 0

Performance of the RIPE Database
by RIPE Database Administration 17 Aug '98

17 Aug '98

Dear Colleagues, There is normally a delay of 10 minutes between an update being processed and it being visible using the whois service. We are aware that this delay has increased and we are taking action now to maintain the delay at normal levels. If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

1 0

Performance of the RIPE Database.
by RIPE Database Administration 10 Aug '98

10 Aug '98

Dear Colleagues, There is a time-delay between when an object is processed by <auto-dbm(a)ripe.net> and when it is visible through the whois service. This delay is normally 10 minutes. This delay became very long recently, but no updates were lost. If you received an acknowledgement mail, which said that your update was successful, then your update was indeed successful. No updates were lost. The problem is fixed now. If you continue to have problems, please contact <ripe-dbm(a)ripe.net> with details of the problem. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

1 0

Announce: IRRd-1.0 Beta Release
by Gerald Winters 07 Aug '98

07 Aug '98

IRRd-1.0 Beta Release --------------------- Merit Network is pleased to announce the 1.0 Beta release of the Internet Routing Registry Daemon (IRRd): http://www.merit.edu/radb/ IRRd is designed as a stand-alone routing registry server. IRRd handles RIPE-181 and RPSL whois and RAToolSet queries, as well as database management tasks, including mirroring and object submission. Future versions will support object authentication and notification. The IRRd server features a Cisco Systems-like management and configuration interface. The IRRd architecture was designed to address performance problems with the original RAWhoisd and RADB databases. The current IRRd version supports router configurations up to 600% faster than previously. The IRRd server also supports indexing to disk and memory, handles both the RIPE-181 and RPSL databases, determines database syntax dynamically, and indexes the entire IRR in about a minute. Although this is a beta release, the software is currently in production use as the main RABD (whois.ra.net) server. The current beta release only includes binaries. A complete source code release is planned at the end of the beta trial (anticipated mid September 1998). IRRd is freely available and may be redistributed so long as the University of Michigan copyright is preserved. Development of the RPSL portions of IRRd were supported by the National Science Foundation (NCR-9321060). All other sections were supported by Merit Network, Inc. The ongoing IRRd efforts include significant efforts by a number of Beta testers, including Kevin Oberman (ESnet), Mark Prior (connect.com.au pty ltd), John Heasley (Verio), George Matey (Bay Networks), WeeSan Lee (USC/ISI), and Pierre Thibaudeau (Teleglobe). Many thanks for your suggestions and support! A mailing list, irrd-discuss(a)merit.edu, has been created for IRRd users to share experiences and advice. Subscribe by sending mail to irrd-discuss-request(a)merit.edu. -- IRRd Development Team <irrd-support(a)merit.edu> Gerald Winters Craig Labovitz Tom Spindler Jake Khuon Susan R. Harris

1 0

SUCCEEDED: Person: Wilfried Hauf (fwd)
by Hostmaster Schlund+Partner GmbH & Co. 07 Aug '98

07 Aug '98

Hello Hostmaster, as you can see, this Handle has been created at 8:32 today, which is 10:32 local time. Now, THREE hours after, ...: admin hostmast ~%date; wripe WH724-RIPE Fri Aug 7 13:23:43 CEST 1998 [sequoia.ripe.net] % Rights restricted by copyright. See http://www.ripe.net/db/dbcopyright.html % No entries found for the selected source(s). % % If you would like to search on arbitrary strings, % please see the Database page on the RIPE NCC % web-site at http://www.ripe.net/db/ % This will only work for RIPE data. This is not a single case, all our handles aren't available hours(!) after the succeeded mail has arrived. The 10 Minutes stated in the return messages would be okay, but we can't afford to have one day between handle registration and domain registration. I consider this a serious problem. Can you tell me if this is going to be fixed soon? Kind regards, Eric Schaetzlein Schlund + Partner GmbH & Co. Erbprinzenstr. 1 Tel. +49-721-91374-50 76133 Karlsruhe, Germany Fax +49-721-91374-20 http://www.schlund.de hostmaster(a)schlund.de ----- Forwarded message from RIPE Database Management <ripe-dbm(a)ripe.net> ----- Date: 7 Aug 1998 08:32:13 -0000 To: hostmaster(a)schlund.de From: RIPE Database Management <ripe-dbm(a)ripe.net> Subject: SUCCEEDED: Person: Wilfried Hauf Reply-To: ripe-dbm(a)ripe.net Your update was SUCCESSFUL, but it can take 10 minutes before your update is visible using a whois look-up. > From: hostmaster(a)schlund.de > Subject: Person: Wilfried Hauf > Date: Fri, 7 Aug 1998 10:19:22 +0200 > Msg-Id: <E0z4hkA-00040w-00(a)admin.schlund.de> The following objects were processed. New OK: [person] WH724-RIPE (Wilfried Hauf) ----- End forwarded message -----

1 0

Re: status attribute of the inetnum object.
by Paula Caslav 29 Jul '98

29 Jul '98

Dear Hank & colleagues, Hank Nussbacher <HANK(a)VM.TAU.AC.IL> writes: * On Thu, 09 Jul 1998 21:19:18 +0200 you said: * > * >Dear Colleagues, * > * >We intend to make the status attribute of the inetnum * >object mandatory on Monday, 13th July next. This has * >been discussed and agreed previously. However, if you * >have software that is _unavoidably_ dependent on this * >attribute being optional, please contact us. * > * >The new version of the inetnum object will be: * > * > * >inetnum: [mandatory] [single] [primary/look-up key] * >netname: [mandatory] [single] [look-up key] * >descr: [mandatory] [multiple] [ ] * >country: [mandatory] [multiple] [ ] * >admin-c: [mandatory] [multiple] [inverse key] * >tech-c: [mandatory] [multiple] [inverse key] * >rev-srv: [optional] [multiple] [ ] * >status: [mandatory] [single] [ ] # mandatory !!! * >remarks: [optional] [multiple] [ ] * >notify: [optional] [multiple] [inverse key] * >mnt-by: [optional] [multiple] [inverse key] * >mnt-lower: [optional] [multiple] [ ] * >changed: [mandatory] [multiple] [ ] * >source: [mandatory] [single] [ ] * > * >If you have anymore questions, please contact * ><ripe-dbm(a)ripe.net>. * > * >Regards, * > * >Ambrose Magee * >____________________________ * >RIPE Database Administration. * > * > * * I think the RIPE documentation needs some updating. * * ----------------------------------------------- * The status field can have one of these values: * * ALLOCATED PA (the most common allocation type for Local IR's) * * ALLOCATED PI (rare for Local IR's) * * ALLOCATED UNSPECIFIED * * ASSIGNED PA * * ASSIGNED PI * * These five values are explained in ripe-140. * ------------------------------------------------- * There is no ripe-140. Yes, you're right that needs to be updated. This quote comes from the database document ripe-157 and the document should actually point to ripe-159, we'll change that with the next version of ripe-157. We're also changing the output of "whois -t inetnum" right now to mention ripe-159. * Next. * * >From ripe-142: * ---------------------------------------------------- * status: Specifies whether the request is provider * aggregatable or provider independent. * Should be filled in with either "ASSIGNED * PA" or "ASSIGNED PI". * ---------------------------------------------------- * * No mention of "allocated PA" or "allocated PI" or * "allocated unspecified". The reason why we don't mention the various "allocated" attributes in ripe-142 is because only the RIPE NCC makes allocations, registries should only be entering "assignments" into the database, and therefore should always put "ASSIGNED" in the status attribute on the ripe-141 form which this document describes. In ripe-159, the general policy and procedures document, however, all types of allocation and assignment status types are described. (section 3.4.2 for assignments and section 4.4 for allocations) * I think the RIPE documents need to be updated. There should be * a pointer to ripe-127 instead. Good idea! It's added to the to-do list. :-) Kind regards, Paula Caslav Registration Services Manager RIPE NCC * -Hank * *

1 0

Re: status attribute of the inetnum object.
by Hank Nussbacher 28 Jul '98

28 Jul '98

On Thu, 09 Jul 1998 21:19:18 +0200 you said: > >Dear Colleagues, > >We intend to make the status attribute of the inetnum >object mandatory on Monday, 13th July next. This has >been discussed and agreed previously. However, if you >have software that is _unavoidably_ dependent on this >attribute being optional, please contact us. > >The new version of the inetnum object will be: > > >inetnum: [mandatory] [single] [primary/look-up key] >netname: [mandatory] [single] [look-up key] >descr: [mandatory] [multiple] [ ] >country: [mandatory] [multiple] [ ] >admin-c: [mandatory] [multiple] [inverse key] >tech-c: [mandatory] [multiple] [inverse key] >rev-srv: [optional] [multiple] [ ] >status: [mandatory] [single] [ ] # mandatory !!! >remarks: [optional] [multiple] [ ] >notify: [optional] [multiple] [inverse key] >mnt-by: [optional] [multiple] [inverse key] >mnt-lower: [optional] [multiple] [ ] >changed: [mandatory] [multiple] [ ] >source: [mandatory] [single] [ ] > >If you have anymore questions, please contact ><ripe-dbm(a)ripe.net>. > >Regards, > >Ambrose Magee >____________________________ >RIPE Database Administration. > > I think the RIPE documentation needs some updating. ----------------------------------------------- The status field can have one of these values: ALLOCATED PA (the most common allocation type for Local IR's) ALLOCATED PI (rare for Local IR's) ALLOCATED UNSPECIFIED ASSIGNED PA ASSIGNED PI These five values are explained in ripe-140. ------------------------------------------------- There is no ripe-140. Next. >From ripe-142: ---------------------------------------------------- status: Specifies whether the request is provider aggregatable or provider independent. Should be filled in with either "ASSIGNED PA" or "ASSIGNED PI". ---------------------------------------------------- No mention of "allocated PA" or "allocated PI" or "allocated unspecified". I think the RIPE documents need to be updated. There should be a pointer to ripe-127 instead. -Hank

1 0

What happened to RIPE Database full text search?
by ludger.bornhorst＠t-online.de 23 Jul '98

23 Jul '98

Dear all, since a short time I get the following answer on any query in http://www.ripe.net/cgi-bin/ripedbsearch: >The following problem occured during the search: > > No objects were found matching the search criteria > > Please try again! Maybe this error arose since the new RIPE-db version 2.1.3 has been implemented last Monday? -- Ludger Bornhorst, Deutsche Telekom AG, ZDK Zentrum fuer Datenkommunikation, Oldenburg, Germany Tel.: +49 441/234-5678 Fax : +49 441/27463

5 5

Re: What happened to RIPE Database full text search?
by Christian Panigl, ACOnet/UniVie 22 Jul '98

22 Jul '98

>Date: Wed, 22 Jul 1998 13:03:24 +0200 >From: Joao Luis Silva Damas <joao(a)ripe.net> > >Nothing happens to the RIPE DB itself. > >However, the full search text is not working at this moment. >We are investigating and working on fixing it. Hi Joao, not only full text search doesn't work but also ftp.ripe.net/ripe/dbase/split/* files are empty !!! Is this a related problem ? Are you already working on that ? Besides other things we are building our actual routing-filters based on those split-files ! Kind regards CP --- ---------------------------------------------------------------------- --- --- Christian Panigl : Vienna University Computer Center - ACOnet --- --- VUCC - ACOnet - VIX : -------------------------------------------- --- --- Universitaetsstrasse 7 : Mail: Panigl(a)CC.UniVie.ac.at (CP8-RIPE) --- --- A-1010 Vienna / Austria : Tel: +43 1 4277-14032 (Fax: -9140) --- --- ---------------------------------------------------------------------- ---

2 1

New release of the RIPE DB in production
by Joao Luis Silva Damas 21 Jul '98

21 Jul '98

Dear all, as announced last week, yesterday we installed version 2.1.3 of the RIPE DB software in our production systems. This version has been available for download from our ftp site since July 15th. The main changes in changes in version 2.1.3 are: - Changed attributes are no longer shown by default in any query. If you want to see them you will have to use the -c option. The database doesn't look at the changed attributes in updates so if you don't want to loose them when updating objects, make sure you first get the object using the -c option and update that. - Inclusion of cross notification in the Routing registry. For details see the RELEASE NOTES included below, Regards, Joao RELEASE NOTES for RIPE Database 2.1 SUPPORTED SYSTEMS This release has been tested with perl5.00401 on bsdi3.1 and GNU/linux systems. Please let us know if you have problems running it on other systems. FEATURES Changed attributes ------------------ This release modifies the default behaviour of the whois daemon by not displaying the "changed" attributes in any objects as result of a query unless specifically requested to do so, by using the new -c whois query option. Updates and deletes ignore the changed files so if an update differs from the previous object only in the changed fields a NOOP will be returned. Cross notification in the Routing Registry ------------------------------------------ A new major feature in this release is cross notification in the routing registry. Cross notification works according to: 1. Whenever a route object is added to the routing registry, a check is done to see if the address space overlaps with that in any other route object in the RR. If so, a notification will be sent to the submitter of the route object. This will always happen and is not dependent on any notification attributes described below. 2. Two new fields called "cross-nfy:" and "cross-mnt:" have been added to the route and aut-num objects. The "cross-nfy" field: a) contains a contact reference, specified as a NIC-handle pointing to a person or role object, the email address of which will get the notification; b) is optional; and c) is multiple (so that more than one contact can be notified). The "cross-mnt" field: a) contains a contact reference, specified as a mntner ID referencing the maintainer to be notified; b) is optional; and c) is multiple (so that more than one contact can be notified). This attribute is used to request notifications of the addition or removal of route objects which overlap the address space of the already registered route objects in which this attribute is specified. If the "cross-nfy:" or "cross-mnt:" attributes are used in: + a route object, then a notification will be sent for any overlaps with the address space specified in the route object; + an aut-num object, then a notification will be sent for overlaps with the address space specified in each route object in which the given AS number is specified in the "origin:" attribute. The contact/s in "cross-nfy:" or the mnt-nfy/s in the maintainers referenced by the "cross-mnt:" will receive an e-mail whenever: + a route is registered which overlaps this address space; or + a route is removed which overlapped this address space. If all is well, the former will indicate the introduction of multi-homing, and the latter will indicate the cancellation of the multi-homing. It is expected, however, that the former will often indicate an error, and the latter its removal. Either way, it will be useful to know about the registration and elimination of overlapping announcements. The set of sources searched for these conflicts is defined on a server wide basis (CROSSNOTIFYSOURCES in ripedb.conf). BUG FIXES Better check for disk full conditions when writing to the database Workaround for bug in perl handling integer numbers Performance improvements, better checks on forking and misc. additions contributed by users.

1 0