September 1998 - db-wg - mailman.ripe.net

<auto-dbm@ripe.net> is slow this afternoon.
by RIPE Database Administration 17 May '18

17 May '18

Dear Colleagues, Because of a very high level of use this afternoon, the response time of <auto-dbm(a)ripe.net> is longer than normal. I have made contact with those who are responsible and I expect the situation to improve as the machine works through the queue. Please be patient. Obviously we at the RIPE NCC Database Group are continuously working to make the performance of the database as good as possible. However, we cannot make improvements in zero time. We thank you for your co-operation up to now and we ask for your continued co-operation so that everyone receives the best possible service. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

2 2

NIC handle writeup
by David Kessens 02 Dec '98

02 Dec '98

Hi, We discussed in depth the issue of NIC handles during the db-wg session of the Stockholm RIPE meeting. I promised to write a draft with a proposal. It's enclosed below for your review, David K. --- Internet Engineering Task Force David Kessens Draft ISI Expires March 1999 <draft-kessens-registryobject-identifiers.txt> Registry Object Identifiers Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract NIC handles have existed for a long time while they were never properly defined. At the same time, many registries started with their own interpretation of a definition that didn't exist. This document attempts to describe a definition that mostly backwards compatible with the definitions that most registries currently use. Introduction For a long time, a need existed for a unique identifier to identify personal data in the regional registries. The NIC handle has been invented to address this issue. However, the concept of NIC handles has never been documented in any place and as a result, several registries use different definitions. This draft is an attempt to write up a definition that is compatible with the current definitions that most registries use and that allows other, possibly new registries, to design their own identifiers that Kessens [Page 1] Draft RIDE References August 1997 are guaranteed to be unique. In addition, this document generalizes the concept to allow registries to use these unique identifiers for other classes (like host objects) then the personal data classes. Concepts The identifier consists of two parts: - internal registry identifier The identifier is unique within the registry, but doesn't need to be unique on a global scale. This gives the registry maximum freedom to design their own identifiers for local use. In the past, one of the most difficult problems was the entropy in the the NIC handle name space. - global registry identifier This identifier makes the internal registry identifier unique on a global scale. A registry can be queried using the internal identifier or with a combination of internal and global identifier. The registry will add it's own identifier when the internal identifier is omitted. Definition InternalIdentifier[@GlobalIdentifier] The global identifier is the same as a domain which is in use by the registry. The internal identifier is an RPSL word [1]. Identifiers are not case sensitive. Discussion No central authority was ever present to allocate global identifiers. This caused name collisions. However, it's undesirable to have such an authority. Therefore, it is needed to get an identifier from some other already defined namespace. The domain name system provides us such an identifier with minimal cost. A convention for internal identifiers for use in conjunction with Kessens [Page 2] Draft RIDE References August 1997 personal data exists: InitialsOfPerson# It is recommended but not required to follow this convention. The '@' sign is choosen since it cannot be part of the internal identifier. In the past '-' was used which is causing ambiguities. It is not required that every registry is actually using the convention. A registry can mirror another registries data that doesn't participate in the scheme and assign a global identifier using a domain that is used by the other registry. Example example: KH1(a)ARIN.NET KH1 is local identifier ARIN.NET is global registry identifier (last part of domain name can possibly be omitted) Security considerations The model describes a dataformat which doesn't have security problems in itself. It doesn't make the system more or less secure. Acknowledgments The ideas presented in this document are a composition of ideas and thoughts of the author and many other people that have developed over the years. In particular, the people that were present at the RIPE database working group, IETF ride BOFs and their respective mail lists have had quite some influence on the final outcome of this draft. References [1] Cengiz Alaettinoglu e.a., RPSL, rfc2280.txt Author's Address: David Kessens, ISI Kessens [Page 3] Draft RIDE References August 1997 4676 Admiralty Way, Suite 1001 Marina del Rey, CA 90292-6695 USA davidk(a)ISI.EDU Kessens [Page 4]

4 6

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 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