- db-wg - mailman.ripe.net

Update processing delayed
by RIPE Database Administration 22 Jun '99

22 Jun '99

Dear Colleagues, the database is very loaded now, due to some huge updates sent tonight. The queue of waiting updates is very long and you should be prepered for waiting times of several hours before your update gets processed. Please do not resend your updates. Thank you for your patience. If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, Roman Karpiuk ____________________________ The RIPE NCC Database Group.

1 0

Adding nic handles to objects without one
by Joao Luis Silva Damas 16 Jun '99

16 Jun '99

Dear all, as discussed and agreed to during discussions in the mailing lists and at the RIPE Meeting in Vienna, the RIPE NCC will be adding newly generated NIC handles to person objects that do not currently have one. Over the last days we have been testing the procedures to do this in a non-disruptive way. Unfortunately, due to the nature of the current database, the process needs about 5 hours to run. Due to this and to avoid interactions with nightly jobs that create several copies of the files, including the ftp site and the full text search indexes, we will stop updates tomorrow Tuesday at 19:00 (Amsterdam time). This will cause all updates to the DB sent after 19:00 to be queued for later processing that night. There is no need to send updates more than once. Queries will not be affected. That is, the whois server will keep answering queries normally. During the process, objects without nic handles will get unique new ones and also a "changed" attribute will be added with tomorrow's data and ripe-dbm(a)ripe.net as the author of the change. This is for future reference. If you have any questions, please do not hesitate to contact us. Best regards, Joao Damas DB Group RIPE NCC

2 1

RE: status on RIPE-DB rewrite
by Wilfried Woeber, UniVie/ACOnet 07 Jun '99

07 Jun '99

Rick, >can anyone give a status on the ripe-db rewrite in 'C' http://www.ripe.net/meetings/ripe/ripe-33/pres/db-reimpl/index.html might provide you with some answers. I'm sure RIPE NCC staff can give more details, if required. 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 --------------------------------------------------------------------------

2 1

Tagging of IP adresses / Application-Database
by Nacamar AS Guardian 07 Jun '99

07 Jun '99

Hi, at RIPE-Meeting 33, the issue on the agenda of the lir-wg of "Tagging of IP adresses and ANTI SPAM" was rejected. Partly, because this has been implemented by Paul Vixi, http://maps.vix.com/dul Further, it was felt that these tags should not be an addition to the IP-Objects, because it has a much broader range of possible applications. So, the issue was handed over to the db-wg to think about a new application-registry. Such an application-object could look like: >>> location: [mandatory] [single] [primary/look-up key] app-type: [mandatory] [single] [primary key] app-subtype: [mandatory] [single] [primary key] descr: [mandatory] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [optional] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] <<< Location would be a range of IP-Addresses or maybe a hostname, app-type a value/keyword like "nameserver", "dialin", "mail" etc., app-subtype a more detailed code for the application, like root-nameserver, tld-nameserver, cc-nameserver, etc. Details to be discussed... Then descr, contacts etc, just the usual stuff. Technically, this shouldn't be too hard, but the main questions remain on the administrative side: - who would use this database, and for what purpose (Anti-SPAM, better route-flap-dampening ...) - who should insert/maintain the contents - how to determine if the contents are 'legal', e.g. come from the 'owner' of the mentioned ip-ranges/hosts - what to do if someone protests against some contents, or claims damages because of some contents Just to spark a bit of discussion... Best Regards, HaJo Gurt ------------------------------------------------------------------- Nacamar Network Administration NACAMAR Data Communications guardian(a)nacamar.net Robert-Bosch-Str. 32 D-63303 Dreieich +49 6103 993 0 Voice Germany +49 6103 993 222 FAX gurt(a)nacamar.de ------------------------------------------------------------------- Titanic 12 - Hiroshima 45 - Tschernobyl 86 - Windows 95 - Silvester 99

3 4

Re: Tagging of IP adresses / Application-Database
by Wilfried Woeber, UniVie/ACOnet 04 Jun '99

04 Jun '99

=> >> back to basics: The only thing I wanted was an attribute => >> which said "SMTP connections from these IP numbers shouldn't happen" Yup, that was where it came from :-) And we are grateful to you for seeing this "spark" to get the whole discussion going! => > => >'overloading' of the current IP-Database with additional, => >basically unrelated informations was not wanted. => => Rather than bloat the idea to that size, I thing I'd rather drop => the proposal then. = =Ok, that would be the easiest way to get this issue done, sort of... Well, from the "users'" point of view, the innards of the implementation shouldn't be that important ?? >On the other hand, the administrative overhead >for the IP-Database with tags as extensions >is likely to be at least the same >as for a new, separate database. During the various discussions we hit a few interesting aspects (non-exhaustive list): - people do have a broad set of ideas what they woukd like to see documented. From dial-up use of IP addresses to "golden" networks for registry servers or root NS, to web-cache sites/peerings, to IPv6 tunnels... - the problem of over-loading existing objects, both schema-wise as well as maintainance-wise. E.g., for a larger ISP there's a good chance that the LIR staff wouldn't want to/be able to maintain application level entries... - the problem of authority for the data. We do have "over-loading" already, within the RIPE-DB. . I.e. the DB is (formally) authoritative for IP numbers, . it's a "reasonable" place to offer a routing registry service, but with much less (formal) authority attached by the NCC . it's offered/used as a repository for DNS data, discussion has started if "authority" for that subset should be moved to CENTR . an application type registry probably needs some sort of environment. Learning from DNS, I suppose the NCC is very reluctant to spend implementation effort unless we can come up with a model for use, authority and - eventually - funding. But, this list is emphasising the potential stumbling blocks... I'd be much more interested in proposals on the use and setup, how to maintain the data, how to derive and attach credibility, and the like. The floor is your's! Input, please! 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

status on RIPE-DB rewrite
by Rick H. Wesson 04 Jun '99

04 Jun '99

can anyone give a status on the ripe-db rewrite in 'C' thanks, -Rick

1 0

New RIPE DB sw version
by Joao Luis Silva Damas 04 Jun '99

04 Jun '99

Dear all, the RIPE NCC is happy to announce version 2.3 of the RIPE Database software. This new version introduces complete support for the IPv6 address objects. Only the RIPE NCC can introduce objects with value ALLOCATED in the status field of IPv4 address objects. This reflects the current registration policy. Some other minor features and a number of bug fixes have been introduced. For more details, please see the release notes included below and on the software package. This new version is available immediately from ftp.ripe.net and will be used on whois.ripe.net starting next Monday (7th June). Regards, Joao Damas DB Group RIPE NCC

1 0

Proposal to change default source search behavior in the whois server
by Jake Khuon 26 May '99

26 May '99

Currently, the RIPE whois server returns a result from a single-source (RIPE) search by default. One needs to pass a -a flag in order to obtain multiple-source returns. Because of this behaviour in conjunction with the necessity to allow a "defaulted" query to return inetnums, the architecture of the database is limited to a single source. For those organisations who may wish to run their own registry and participate in mirroring, this poses a considerable issue. I propose that the behaviour be modified so that the default would be to return a single-match first-hit from multiple-source search. That is, a query will return only one result but it will search through the source search order and return the first match it finds rather than simply stopping at the RIPEdb. -- /*====================[ Jake Khuon <khuon(a)GCtr.Net> ]======================+ | Network Statistics Engineer, NSM/Net-Eng /~ |2 () |\| ~|~ | @ |2 | | VOX: +1(408)328-4828 Fax: +1(408)328-4806 _/~ G L & B A L C E N T E R | +============[ 1154 East Arques Avenue, Sunnyvale, CA 94086 ]============*/

1 0

2. Draft, proposed agenda DB-WG meeting RIPE-33, Thu.,May 6
by Wilfried Woeber, UniVie/ACOnet 05 May '99

05 May '99

Dear WG participants, dear WG-Chairs, here's the final draft agenda for the DB-WG meeting. 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-33, May 1999, Vienna, AT 2. Draft A. Administrative stuff (Wilfried Woeber, chair) - appointment of scribe - agenda bashing - review of action items B. RIPE DB, operational update (RIPE NCC) - statistics, performance, changes, most recent mod.s - RPSL migration update, usage - current status of PGP deployment C. DB SW Re-implementation (RIPE NCC) - progress, milestones/roadmap, deployment, documentation - operational aspects, mirrors, clients - proposal to *not* migrate obsoleted objects and attributes . dom-prefix . others? D. I-D draft-ietf-rps-auth-??, -rps-dist-?? (??) - RIPE region requirements/comments - any progress E. DB Consistency Project (RIPE NCC) - status update F. IPv6 issues - what are the loose ends? . Routing registry (RPSLng ?) . Objects . IP-registry X. IETF report(s) if any :-) Y. Input from other TFs/WGs - LIR-WG: application specific registries? DUL, Root-NS, TLD-NS,.... - DBsec TF mission accomplished? mandate for continuation? next activities, if any at all? Z. AOB ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WW, 5-MAY-1999 13:46:59

1 0

1. Draft, proposed agenda DB-WG meeting RIPE-33 @ Vienna
by Wilfried Woeber, UniVie/ACOnet 23 Apr '99

23 Apr '99

Dear WG participants, dear WG-Chairs, attached please find a very preliminary agenda draft for the DB-WG meeting in Vienna in May. Any comments and proposals for modification are very much appreciated. Looking forward to see you in Vienna, 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-33, May 1999, Vienna, AT 1. Draft A. Administrative stuff (Wilfried Woeber, chair) - appointment of scribe - agenda bashing - review of action items B. RIPE DB, operational update (RIPE NCC) - statistics, performance, changes, most recent mod.s - RPSL migration update, usage - current status of PGP deployment D. DB SW Re-implementation (RIPE NCC) - progress, milestones/roadmap, deployment, documentation - operational aspects, mirrors, clients - proposal to *not* migrate obsoleted objects and attributes . dom-prefix . others? E. I-D draft-ietf-rps-auth-??, -rps-dist-?? (??) - RIPE region requirements/comments - any progress X. IETF report(s) Y. Input from other WGs - t.b.d. Z. AOB ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WW, 23-APR-1999 15:03:27

1 0

Adding nic handles to contact objects without one (72 chars/line)
by Joao Luis Silva Damas 19 Apr '99

19 Apr '99

Thou shall not send vi docs directly on a mail! At people's request here goes the mail again with sorter lines. Regards, Joao ------- Include message ------ Dear all, During the month of February the RIPE NCC, at the RIPE Database working group's request after the RIPE 32 meeting in Amsterdam, put out a proposal to add automatically generated nic handles to existing person objects that do not currently have one. Some other unrelated issues have caused me to not follow this up appropriately. I am sorry for that. In order to resume (and hopefully swiftly conclude) this issue, I will use the rest of this message to summarize the state of discussions. I would like to ask for a 10 day discussion period after which I will summarize the conclusion to the list and have the Database group take whatever action is agreed to. Summary: The initial proposal called just for the addition of an automatically generated nic handle to person and role objects which currently do not have one. This would be done using the same automatic procedure used by the Database software when a user request an AUTO nic handle. That is, the database takes up to 4 initials from the name, looks for the highest exisiting number of a nic handle in the sequence of nic handles with the same initials, generates a new number and adds the suffix "-RIPE". Input received discussed if we should use the opportunity and try to modify some database objects that reference person and role objects by name instead of nic handle as is required now in the RIPE Database. These are two separate issues. The first one could be approved without the second one. The first one alone brings old objects up to date to current specifications, simplifies the prorammers life and enables further steps to increase the DB's consistency. In my personal opinion it is a Good Thing. The main advantage of the second part is that: - References by nic handle are less ambiguous than references by name since the DB ensures that there are no duplicate nic handles whereas there is no reason why two persons can't have the same name. (Note: currently there are around 30 duplicate nic handles in the RIPE DB due to legacy objects from the past and bugs in past releases of the software. This problem is being addressed in the context of the RIPE DB consistency project. There will be an extensive report on the progress of this project in the coming RIPE meeting in Vienna). Doing this doesn't solve all the problems, naturally, and may have some problems as itemized below: - If the reference by name is to a name for which more than one object exists then there is an ambiguity that can't be handled automatically. The solution to this requires intervention by the referencing object's owner. This will be handled by the DB consistency project. - If there is no object with the referenced name then the referencing object is at least partially orphaned. This issue will also be addressed by the DB consistency project and may eventually need further policy decisions in the future, to be discussed by the community. - There is a chance that a person/role object with a refenced name exists and is unique but is not the one that created the referencing object. Eg. if I created an inetnum object in 1991 but then deleted my person object and then my twin ghost registered in the DB and created some new objects: should the original inetnum object (still in the database) be linked to my twin ghost (who probably doesn't know anything about it)? If this issue is seen as a heavy one then no name references can be modified to references by NIC handle automatically, unless an exhaustive search of the DB update logs is performed (and even then, there is no guaranteed result). I think this summarizes the state of affairs. Please give your input as soon as possible so that a conclusion can be reached. If possible, address the original and the extension proposal separately. Thanks, Joao Damas RIPE DB Group Manager RIPE NCC

3 2

Re: Objects to deprecate (OSI dom-prefix)
by Wilfried Woeber, UniVie/ACOnet 16 Apr '99

16 Apr '99

Wearing my plain DB user hat, >the RIPE NCC hereby requests from the RIPE community to consider NOT >to support the Domain-prefix object in the new RIPE DB code currently >under development. >This would mean not writing the code to support the object and dump the data >in the transition to the new code (still a few months away). I fully support this proposal. 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

Objects to deprecate (OSI dom-prefix)
by Joao Luis Silva Damas 16 Apr '99

16 Apr '99

Dear all, the RIPE NCC hereby requests from the RIPE community to consider NOT to support the Domain-prefix object in the new RIPE DB code currently under development. This would mean not writing the code to support the object and dump the data in the transition to the new code (still a few months away). This object is intented to store OSI CLNS prefixes and has seen little use. Currently there are 6 objects of this type. The most current update took place in May 1994. The prefixes stored right now are: 39.528f.1100 39.756f.1111 39.756f 39.250f 39.250f.0000.02 39.276f.3100 in case the owners want to inspect them and check their use :-) Best regards, Joao Damas RIPE NCC

2 1

2 digit years in the RIPE DB (Y2K)
by Joao Luis Silva Damas 16 Apr '99

16 Apr '99

Dear all, at the last RIPE meeting the Database Working group asked the RIPE NCC to propose to the community a rewrite of all dates currently stored in the RIPE Database that are using two figures for the year as dates with four figures for the year. The RIPE DB software has already been modified to avoid problems with Y2K. Changing the date format would make things cleaner and not dependant on conventions for interpretation of dates. This simplifies software development both at the RIPE NCC and by users writing their own programs. This is a rather small change although it involves modification of user data and therefore we would like to open a comment period of 10 days to see if there any user concerns about the proposed change. Best regards, Joao Damas RIPE DB Group Manager RIPE NCC

1 0

Adding nic handles to contact objects without one
by Joao Luis Silva Damas 16 Apr '99

16 Apr '99

Dear all, During the month of February the RIPE NCC, at the RIPE Database working group's request after the RIPE 32 meeting in Amsterdam, put out a proposal to add automatically generated nic handles to existing person objects that do not currently have one. Some other unrelated issues have caused me to not follow this up appropriately. I am sorry for that. In order to resume (and hopefully swiftly conclude) this issue, I will use the rest of this message to summarize the state of discussions. I would like to ask for a 10 day discussion period after which I will summarize the conclusion to the list and have the Database group take whatever action is agreed to. Summary: The initial proposal called just for the addition of an automatically generated nic handle to person and role objects which currently do not have one. This would be done using the same automatic procedure used by the Database software when a user request an AUTO nic handle. That is, the database takes up to 4 initials from the name, looks for the highest exisiting number of a nic handle in the sequence of nic handles with the same initials, generates a new number and adds the suffix "-RIPE". Input received discussed if we should use the opportunity and try to modify some database objects that reference person and role objects by name instead of nic handle as is required now in the RIPE Database. These are two separate issues. The first one could be approved without the second one. The first one alone brings old objects up to date to current specifications, simplifies the prorammers life and enables further steps to increase the DB's consistency. In my personal opinion it is a Good Thing. The main advantage of the second part is that: - References by nic handle are less ambiguous than references by name since the DB ensures that there are no duplicate nic handles whereas there is no reason why two persons can't have the same name. (Note: currently there are around 30 duplicate nic handles in the RIPE DB due to legacy objects from the past and bugs in past releases of the software. This problem is being addressed in the context of the RIPE DB consistency project. There will be an extensive report on the progress of this project in the coming RIPE meeting in Vienna). Doing this doesn't solve all the problems, naturally, and may have some problems as itemized below: - If the reference by name is to a name for which more than one object exists then there is an ambiguity that can't be handled automatically. The solution to this requires intervention by the referencing object's owner. This will be handled by the DB consistency project. - If there is no object with the referenced name then the referencing object is at least partially orphaned. This issue will also be addressed by the DB consistency project and may eventually need further policy decisions in the future, to be discussed by the community. - There is a chance that a person/role object with a refenced name exists and is unique but is not the one that created the referencing object. Eg. if I created an inetnum object in 1991 but then deleted my person object and then my twin ghost registered in the DB and created some new objects: should the original inetnum object (still in the database) be linked to my twin ghost (who probably doesn't know anything about it)? If this issue is seen as a heavy one then no name references can be modified to references by NIC handle automatically, unless an exhaustive search of the DB update logs is performed (and even then, there is no guaranteed result). I think summarizes the state of affairs. Please give your input as soon as possible so that a conclusion can be reached. If possible, address the original and the extension proposal separately. Thanks, Joao Damas RIPE DB Group Manager RIPE NCC

1 0

ANNOUNCEMENT: RELEASE OF IRRd-1.3-Beta
by Gerald Andrew Winters 09 Apr '99

09 Apr '99

Merit Network, Inc. is pleased to announce the first production-quality release of the Internet Routing Registry Daemon (IRRd). Source code, manuals and binaries are now *freely* available from: http://www.irrd.net IRRd is an optimized, multi-threaded IRR database server with support for a complete set of RIPE-181 registry services, including: whois queries, an interactive Cisco-like configuration/management interface, remote registry mirroring, email/tool object submissions, and password/PGP. IRRd also includes private database support, security access lists, and an expanded query language. We encourage providers actively using the RADB (and other IRR registries) in production for the generation of router access lists/config files to run a local, mirroring copy of the IRRd server. IRRd has served as the production RADB routing registry daemon since early February. Note: Complete RPSL support will be available with IRRd-2.0 (beta release scheduled for late May). If you are interested in serving as an alpha tester for IRRd-2.0 please send email to irrd-support(a)irrd.net. -- The IRRd Development Team

1 0

Re: Modifications to the inet6num in the RIPE Database
by Wilfried Woeber, UniVie/ACOnet 17 Mar '99

17 Mar '99

Guy, Engin, thanks a lot for the explanation! Guy said: >Finally, you can only have one of these constructs per address. This is >common sense really since, if you have 3ffe::aaaa::bbbb, you cannot tell >how many zeroes are replaced with the first pair of colons and how many >by the second. There is no convention (AFAIK) for which block would be >written out in full. Personally, since I am lazy, I choose to write out >the fewer number of zeroes (remembering that I only need one zero per >block of 4 hex digits). > >So, some examples of IPv6 addresses are... > >3ffe:1100:0:c00::/52 >= Note the :0: because there is a :: later in the address Engin added: >The algorithm we use translates "5:0:0:78:0:0:0:0" >into "5:0:0:78::" but not "5::78:0:0:0:0". Of course, >both are legal, but we choose to double-colonize the >last group of zeros, and all prefixes are normalized >according to this and then put into the registry. which already gives us two compatible but different ways to deal with that, and >But I don't know what 6bone registry does. interesting, indeed. Taking this one step further, and looking back at what we did with IPv4, where it would be feasible to say 131.130/16, implying 131.130.0.0/16, I wonder if it wouldn't again be worthwhile to restrict the use of these shorthand notations in the Address Registry? Is there a danger for braking something by _not_ allowing the "::" construct in the registry at all, or - in particular - not _in the middle_ of a prefix? 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 --------------------------------------------------------------------------

6 6

Re: Modifications to the inet6num in the RIPE Database
by Wilfried Woeber, UniVie/ACOnet 16 Mar '99

16 Mar '99

Hi David, Joao, et.al. <disclaimer> My question is going to prove complete ignorance when it comes to IPv6 address formats. So please bear with me :-) </disclaimer> => The two suggested changes are: => => - - addition of a "status" attribute with the following possible values: => TLA, NLA and SLA. => Syntax checks will be done so that: => TLA is only allowed if the prefix length is 3<x<=16 => NLA is only allowed if the prefix length is 16<x<=48 => SLA is only allowed if the prefix length is 48<x<=64 = =This is fine although, I am not entirely convinced that we really need =it. It's a bit redundant information. By definition something is a =TLA/NLA/SLA so you can just look at the 'inet6num:' field and you =already know what it is. Can't you just generate this field =automatically ?!? For the IPv4 case we do have a well-established format for external representation of addresses and prefixes, i.e. full dotted quad with /prefix-length. In the 6bone registry there's IPv6 prefixes with a "structured" external representation, like "3FFE::/16" or "5FBC:1000::/32". So my questioon is: is there an agreed algorithm to insert punctuation at the "appropriate" positions, and does the proposal/criticism for the semantic checks do have an influence on this formatting? Thanks, 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 --------------------------------------------------------------------------

4 3

Modifications to the inet6num in the RIPE Database
by Joao Luis Silva Damas 15 Mar '99

15 Mar '99

Dear all, A week has passed and no comments against the proposed modifications to the IPv6 object have been put forward. Therefore we take it that everyone is happy with it and will procede with the implementation. We expect this to be available in about two weeks. The original message is repeated below for your reference. Regards, Joao Damas DB Group RIPE NCC ------- Begin Original Message From: Joao Luis Silva Damas <joao(a)ripe.net> Date: Thu, 04 Mar 1999 10:20:17 +0100 To: lir-wg(a)ripe.net, db-wg(a)ripe.net Subject: Modifications to the inet6num in the RIPE Database Dear all, below are the proposed modifications to the inet6num object in the RIPE Database as discussed during the past RIPE Meeting. These are mainly to bring the IPv6 object up to the IPv4 object's functionality. The two suggested changes are: - - addition of a "status" attribute with the following possible values: TLA, NLA and SLA. Syntax checks will be done so that: TLA is only allowed if the prefix length is 3<x<=16 NLA is only allowed if the prefix length is 16<x<=48 SLA is only allowed if the prefix length is 48<x<=64 - - addition of "mnt-lower" capabilities, as in the IPv4 object. We would like to open a comment period of 1 week from today to gather input and proceed with implementation if there is consensus. Regards, Joao Damas DB Group RIPE NCC ------- End Original Message

2 1

Annoing lists.:(
by Irmantas Gudelis 15 Mar '99

15 Mar '99

[ Moderator note: changed local-ir(a)ripe.net -> db-wg(a)ripe.net ] Is it good that everybody is using addreses from ripe database for sennding such a stuipid and annoing messages? The problem is that it is happening more frequently. Maybe anybody has solved the problem how to filter messages like that ..? ---------- Forwarded message ---------- Return-Path: <JCh7649460(a)aol.com> Delivered-To: irmis(a)isi.kvm.lt Received: (qmail 11358 invoked from network); 5 Mar 1999 15:09:08 -0000 Received: from lex.balt.net (root(a)195.14.162.1) by isi.kvm.lt with SMTP; 5 Mar 1999 15:09:08 -0000 Received: from imo13.mx.aol.com (imo13.mx.aol.com [198.81.17.3]) by lex.balt.net (8.9.1a/8.9.0) with ESMTP id QAA01908 for <registry(a)balt.net>; Fri, 5 Mar 1999 16:00:27 -0100 From: JCh7649460(a)aol.com Received: from JCh7649460(a)aol.com by imo13.mx.aol.com (IMOv19.3) id aTOYa22613; Fri, 5 Mar 1999 09:15:15 -0500 (EST) Message-ID: <3afff544.36dfe6f3(a)aol.com> Date: Fri, 5 Mar 1999 09:15:15 EST Mime-Version: 1.0 Subject: Profit From The Internet Growth-Explosion 800 607-6006 Ex 2492 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 3.0 for Windows 95 sub 76 This is a 1 time mailing Fire the Boss and break the Alarm Clock! I did! after eleven years, I left a $140,000 a year income for this opportunity I can truly say it was one of the best decisions of my life!!! Never commute again! make $2000-$5000 per week from home with a turn key marketing system! To find out how our system works call the 800#. You can start out in your spare time, work part time or work up to full time if you want to! It's your business! Call 1-800 607-6006 ex 2492# then press 1 no selling! stay home with the family! Proven track record of success! 1 800-607-6006 ex 2492# call now! Profit From The Internet Growth-Explosion 800 607-6006 Ex 2492 Thank You

2 2

Re: Modifications to the inet6num in the RIPE Database
by Simon Leinen 14 Mar '99

14 Mar '99

Joao, sorry for the late comment, but I have a small issue with the following: > Syntax checks will be done so that: > TLA is only allowed if the prefix length is 3<x<=16 > NLA is only allowed if the prefix length is 16<x<=48 I think the separation between TLA and NLA space is not that clear. There are eight reserved bits between the TLA field and the NLA field (see section 2.5.7 of RFC 2373 and section 3.1 of RFC 2374). By introducing the checks as you proposed, you seem to have decided that those should be part of the NLA field. I don't think this is warranted. Section 3.2 of RFC 2374 makes it clear that some of the reserved bits might also be used to extend the TLA field in the future. You should permit either both TLAs and NLAs, or neither of them for prefix lengths between 16 and 24. I suggest rejecting such prefixes for the moment, and keep in mind that the reserved bits may be added to the TLA and/or NLA over time. If I missed some change in the intended structure of IPv6 unicast addresses, please apologize. Regards, -- Simon Leinen simon(a)switch.ch SWITCH http://www.switch.ch/ Who is General Failure & why's he reading my disk?

2 1

Modifications to the inet6num in the RIPE Database
by Joao Luis Silva Damas 04 Mar '99

04 Mar '99

Dear all, below are the proposed modifications to the inet6num object in the RIPE Database as discussed during the past RIPE Meeting. These are mainly to bring the IPv6 object up to the IPv4 object's functionality. The two suggested changes are: - addition of a "status" attribute with the following possible values: TLA, NLA and SLA. Syntax checks will be done so that: TLA is only allowed if the prefix length is 3<x<=16 NLA is only allowed if the prefix length is 16<x<=48 SLA is only allowed if the prefix length is 48<x<=64 - addition of "mnt-lower" capabilities, as in the IPv4 object. We would like to open a comment period of 1 week from today to gather input and proceed with implementation if there is consensus. Regards, Joao Damas DB Group RIPE NCC

1 0

[Fwd: FAILED:]
by Nader S Kawar 03 Mar '99

03 Mar '99

Hello, I am trying to update our aut-num object in the database but it fails giving me the below error message. Can anyone pls tell me what needs to be done. thanks. Regards, Nader Kawar Global One Jordan ------------------------------ RIPE Database Management wrote: > > Part of your update FAILED > > > From: Nader S Kawar <nader(a)go.com.jo> > > Subject: > > Date: Thu, 25 Feb 1999 14:28:14 +0200 (GMT) > > Msg-Id: <199902251228.OAA05619(a)go.com.jo> > > For help see <http://www.ripe.net/db/> or > include 'help' in the subject line of your message > > Objects without errors have been processed. > > Update FAILED: [aut-num] AS8376 > > aut-num: AS8376 > descr: GO-JOR Autonomous System > descr: Global One Communications (Jordan) Ltd > descr: Amman > as-in: from AS4004 10 accept ANY > as-in: from AS4005 10 accept ANY > as-in: from AS6453 10 accept ANY > as-in: from AS8697 10 accept ANY > as-out: to AS4004 announce AS8376 > as-out: to AS4005 announce AS8376 > as-out: to AS6453 announce AS8376 > as-out: to AS8697 announce AS8376 > default: AS4004 10 > admin-c: SK161-RIPE > tech-c: NK68-RIPE > mnt-by: GO-JOR > changed: nader(a)go.com.jo 19990225 > source: RIPE > *ERROR*: authorisation failed, request forwarded to maintainer

2 1

Adding nic handles to contact objects without one
by Joao Luis Silva Damas 02 Mar '99

02 Mar '99

Dear all, during the last RIPE meeting, in Amsterdam, the database working group discussed a proposal to automatically add NIC Handles to all person and role objects in the RIPE Database that don't yet have one (new objects can't be created without nic handles anymore). This proposal was supported by the working group and it was agreed that it should be circulated to the mailing lists to give people not attending a chance to provide input. This does not affect how other objects reference these person or role objects. This is only intended to bring old objects into conformance with the current object definitions and does not mean that data provided by the user will be modified. Only the nic handle attribute will be given a value when the object lacks one. No other attributes will be touched. Objects which already have nic handles will not be touched. The nic handle is a tag conveying no information about the user or role described in the object. It is an identifier for the object. This addition would make data more uniform and could be a benefit for everyone. For more information on nic handles, please read RIPE 157 and RIPE 189 available at http://www.ripe.net/docs Best regards, Joao Damas Database Group RIPE NCC

4 5

Fwd: RE: Database security
by Wilfried Woeber, UniVie/ACOnet 11 Feb '99

11 Feb '99

Dear all, due to finger trouble I failed to send my reply to the list(s) as well. My apologies - here you go... Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ First of all I'd like to start out by confirming, IMHO, the usefulness of this sort of on-line discussion. Next, in order to balance what I'm going to add as my comments further downstream, I'd like to assure you that I *do* understand your concerns. And on top of that, it might be useful to include the Local-IR WG... => Lets discuss, what measures should be taken to circumvent the situation you describe. => I can see the problem from two different point of views: => => 1) Yours. Then we have to close the database down, to a bare => documentation-tool for IP-Nets, accessible only by the registries. = = Thats not what I said. For example, the DB could only hide specific fields =behind a password. For example, the "descr" field which gives away the company =name. There's two basic problems with that: . I don't expect any agreement (soon) as to *which* fields should be hidden. We've been through that one recently - and painfully :-( All of the fields have been invented and defined because there was a community consensus about the usefulness of that sort of *public* information. If we can identify attributes which we do not need any longer, let's scrap them rather sooner than later :-) . The DB is not used by the operations folks exclusively, but also by the LIRs, I suppose, e.g. to cross-check the more complex IP-Address requests. Hiding descr: attributes would severly impede that possibility... On a more general level, restricting access to "registries" doesn't get you anywhere. Re-living the scenary you describe, the new "nasty" new-comer would simply arrange for a service contract with the NCC, and off we go. The cost: according to ripe-188, it's 2.650,- + 2.100,- ECU. That sounds like a bargain. And doing so gives them access to pre-paid education by the NCC staff about the use of the DB ;-) As long as I've been following the IANA/ICANN stuff recently, or have read some of the IETF drafts (rps-auth, rps-dist, amongst others), there's really no bottom to that pit we're supposed to dig... => 2) Mine. I need the database to track technical problems and people who are =able to solve them. (hopefully, this view is shared by most of the people here =;)) = = Including myself. But on the other hand, there is a problem here which, I feel, =needs to be addressed. The database structure was implemented in times when the =Internet was not so business oriented as it is today. I think that it may need =some rethinking to fit the times, so to speak :-) I fully agree with you that a fair amount of re-thinking is required during the immediate future. In particular about the usefulness of attempts to implement rules, BCPs, code of conduct and regulations by spending programming resources. It's not going to buy us anything. => The security mechanism, which is in place, is not technical, it is just =organisational. There is a copyright on the database. The uses, you describe, =are forbidden by this copyright. => => If someone violates this copyright, at least in Germany there are other =measures to forbid such a use of the database. = = Well, lucky for you in Germany :-) = Seriously, though, there is no way in which you could actually prove, in court, =the sort of thing I describe. I am talking from personal experience... *sigh* Well... I suppose in many, if not most regions, there is *quite a lot* of interesting data accessible to the "public", which does indeed have commercial value. For example in our old little country, it's access to - a comrehensive register of real estate ownership (and the debts secured by that!), - the official place of residence for an individual, - an official registry for companies (including management strucure and directors,...) and for assocations, - car ownership and license plates, - phone books (and eventually we've got PNO regulation going!) on and on... I could come up with zillions of good ideas to make use of that data. And indeed some people do. Some of these attempts are legal, some others are frowned upon, the rest is illegal and triggers prosecution. This is real life. I think we have to spend more effort in the future to work on the legal and social aspects, instead of on setting up technical "filters".... Any arguments to the contrary appreciated! Regards, Wilfried (DB-WG chair) PS: Still the best way for keeping customers is offering "the" better service, whatever that is :-) -------------------------------------------------------------------------- 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 --------------------------------------------------------------------------

2 1