- db-wg - mailman.ripe.net

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 15 Mar '99

15 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

RIPE32 DB-WG Draft Agenda, version 3
by Wilfried Woeber, UniVie/ACOnet 28 Jan '99

28 Jan '99

Attached please find the 3rd draft of the Proposed Agenda for the DB-WG meeting during RIPE32 in Amsterdam, next week. As compared to version 2 there are some addition and some editorial improvements. Regards, Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Proposed Agenda for the Database Working Group Meeting RIPE-32, January 1999, Amsterdam 3. Draft A. Administrative stuff (Wilfried Woeber, chair) - appointment of scribe - agenda bashing | - deputy chair B. RIPE DB, operational update (RIPE NCC) - statistics, performance, changes, most recent mod.s - RPSL migration update, usage - documentation update C. PGP deployment in the RIPE DB (RIPE NCC: Roman) - current status of delpoyment, feedback D. DB SW Re-implementation (RIPE NCC: Joao) - status, milestones/roadmap, resources required/available E. Migration to the new SW - operational aspects - beta-test program and information exchange (ml ?) - proposal to *not* migrate obsoleted objects and attributes . dom-prefix . any others? F. I-D draft-ietf-rps-auth-01, -rps-dist-?? (??) - RIPE region requirements/comments - any progress G. Handling of person: & role: objects | - proposal to auto-generate handles for objects without a handle - proposal to *not* allow re-use of handles, pro.s and con.s - proposal to force-add maintainers for contact objects - operational issues, e.g. sharing maintenance of an object - impact on tools or scripts? | H. Timestamping & Serial #s - implementation proposal (RIPE NCC) | I. inet6num object - modification proposal (RIPE NCC) | J. Y2K cleanup - proposal to have the YYMMDDs changed to YYYYMMDD automatically | K. DB Consistency - status update (RIPE NCC) X. IETF report(s) (??) Y. Input from other WGs - Review of referral mechanism (might be promoted to be an agenda item in it's own right) - Tagging IP-Address ranges as Dial-In (proposal by Poul-Henning Kamp <phk(a)freebsd.org>) - t.b.d. Z. AOB ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WW, 26-JAN-1999 15:45 -------------------------------------------------------------------------- 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

DB-WG Minutes RIPE32 Edinburgh
by Wilfried Woeber, UniVie/ACOnet 26 Jan '99

26 Jan '99

Dear DB-WG, attached is the draft minutes for the Edinburgh meeting. Thanks for the scribe, and apologies for not having been able to properly distribute them in time. I'm going to come back to this during the WG meeting on Thursday. Wilfried. ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10667.907769257.1(a)ripe.net> Hi, Wilfried ! I have revised the draft minutes. Here is the second draft. Regards, AMRM ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10667.907769257.2(a)ripe.net> Content-Description: Minutes Minutes of the DB-WG, RIPE-31, Edinburgh, Scotland. ================================================== The minutes at a glance: ----------------------- Introduction: ------------ Wilfried Woeber opened the session and welcomed the participants. The task of scribe was ascribed to AMRM. The attendance list was circulated to the participants. Agenda Bashing -------------- The agenda had already been sent to the mailing list. There were two additions: a proposal to redefine the IPv6 network object (inet6num) and site; and a proposal to hide the "notify" attribute in the output from a whois look-up. The running order or sequence of the agenda was modified to allowd David Kessens to chair the IPv6 WG. Minutes from RIPE-30: -------------------- WW said that the minutes from RIPE-30 had been misplaced, but that a search for them was in progress. Actions from RIPE-30: -------------------- Ronald van der Pol, SURFnet -To summarise the proposal to allow role objects in the admin-c attribute DONE ==> PROPOSAL RIPE NCC -To clearly document the use of contact information in the RIPE db. (This was an implicit action on the RIPE NCC). David Kessens - To circulate a proposal about DNS-style tagging of NIC-handles. DONE Ambrose Magee -To publish the URL for the inconsistency report on the DB-WG list DONE (but this project was suspended in July, 1998). [NCC -To implement pgp-authentication in the db software. DONE] Summary, with Action Points: --------------------------- Administration: Participants: 50 (or 110010, Base2). Notes by Ambrose Magee. Actions & Agenda Regular reports Internet Draft presentation: draft-zsako-ripe-dbsec-pgp-authent-00.txt draft-ietf-rps-auth-01 Recommendations & Decisions: * Stop special handling of "changed:" * allow role objects in "admin-c" lines * semantics of "refer:" alert, control flag * suppress notification-related attributes, similar to "changed:" ? No, see previous item. Discussion & Input received for semantices and handling of PGP functionality => further input welcome/required !!! Actions from RIPE #31 --------------------- *AP1* Referral Mechanism: _NCC_ To document the new mechanism; by default show authoritative data only and include a hint for the end-user; provide a flag to include the "local" object as well. Circulate to TLD, DNS, DB WG's; require input from TLD's. *AP2* _WW144_ To circulate the proposal to roll-back the whois -c change (the "changed:" attribute). *AP3* _WW144_ With input from _EJB3-RIPE_, to circulate the proposal to allow role objects to be referenced by the admin-c attribute. *AP4* _NCC Registration Services_ To review the impact of this change and, if required, to specify operational restrictions (e.g. not to be used in inetnum objects that describe allocations). *AP5* _Steve Byrne_ (Steven Burley ???) To circulate a write-up or description of the proposed nameserver object. *AP6* _Kevin Hayton_ To send to the DB-WG list his input on naming RIPE documents and on how to use the names. *AP7* _NCC_ To release the draft for ripe-157++ asap; target date: mid-November 1998. DB-Software-related activites: - document "changed:"/whois -c option interactions - develop a proposal on how to generate serial numbers (for updates) and to retire the "changed" line - input from the DB-WG to the re-implementation project is required asap. - new code to handle the "auth" issues raised in the Routing WG - release specification and design information for the re-implementation asap; DB-WG to provide input; the new code is to be made available as soon as it is written. Minutes of the DB WG, RIPE #31 ============================== [Note from the scribbler: *AP* == Action Point] RIPE Database Operations Update ------------------------------- - written by AMRM, but the presentation was given by JLSD1-RIPE (AMRM was on temporary loan to the Scottish National Opera :-) ) This presentation may be seen at: http://www.ripe.net/meetings/ripe/ripe-31/pres/r31upd/index.html RIPE Database Software Development ---------------------------------- Roman Karpiuk gave a presentation on the status of the development of the RIPE Database Software. (WW144 pointed out that this is the existing software, not the new implementation). This presentation may be seen at: http://www.ripe.net/meetings/ripe/ripe-31/pres/ripe-db-software/index.html There was some discussion during and after this presentation. -Duplicate Person Objects: Gert Doering, (SpaceNet), asked if fuzzy matching would be done on duplicate person objects. RK answered that currently, only simple string comparison would be done. Janos Zsako, JZ38, (BankNet), suggested that the proposal to disallow duplicate person objects should be discussed with the ccTLD's. He suggested that each ccTLD should allow other ccTLD's to add "notify" attributes to person objects that are referenced by domain objects from more than one country. WW144 felt that the ccTLD must be consulted. -Plans RK asked for input from the WG. -Questions && Discussion + Referral Mechanism for Domain objects WW144 thanked the NCC for implementing this referral mechanism. He suggested that an option be added to "whois" that forces a whois look-up to return the local object. He suggested that alternatively, both (or all objects, if they exist) should be returned - a sort of recursion. He asked for input. David Kessens suggested that "-R" be used as the option or flag to suppress referral or look-ups outside the RIPE database. Asger Kring (?), DK ccTLD Registry, said that these look-ups are often done by end-users and thus, it would be better to keep things simple. He suggested that the default behaviour be referral only and that a "flag" or option be required to get the local object. David Kessens agreed with this. WW144 suggested that we reverse the default behaviour of whois, for _new_ functionality. DK58 recommended that if a referral is done, then a notice should be prepended to indicate that recursion has occured - otherwise, the RIPE NCC may be open to complaints about the content of someone else's database. WW144 agreed with this recommendation and pointed out that the output of whois is already prepended with a copyright statement. MN131 suggested that comments on the use of national [TLD] registries be obtained, in particluar on the replication of data. *AP* WW144 asked the NCC to document this proposal and to circulate it to the mailing lists (DB, TLD, DNS). NO8 recommended an insistance on feedback from the TLD-WG. He went on to suggest that the default behaviour be to show only the authoritative data, but that a flag would show the local object. JZ38 again raised the issue of ccTLD's and their response to the issue of detecting duplicate person objects and how to handle them. "changed" attribute WW144 agreed with RK that the change in the output of whois was agree in the DB list, but that problems with updating objects, and the "knock-on" or consequent problems with the auto-inaddr robot were not seen. He further suggested that it would be required to document all these interactions and a proposal would then be made to the RIPE community. Eventually, we might use the "-c" flag again. David Kessens suggested that we roll back to the original situation and fix the problem. He did not like the idea of hacking the existing situation. Hans Petter Holen suggested that an internal history of the database objects be maintained. JLSD1-RIPE pointed out that such an internal history would require internally generated data and that first, the users must agree to this. PC111-RIPE explained the problems with the auto-inaddr robot. The robot checked the inetnum object in the db to see when a certain assignment was made and to see if this assignment was done within the range that the assignment window had at that time. DK13-RIPE suggested using serial numbers and timestamps as a method to keep an internal history of the objects. JLSD1-RIPE agreed in principle with this idea. JZ38 pointed out that it was not documented that the first "changed" line should be kept. WW144 supported this idea. *AP* WW144 promised to circulate this proposal to the DB mailing list (i.e. to roll-back the change to the output of whois and the "changed" line). He further suggested that the RIPE NCC and the DB WG devise a method of tracking updates of objects (using serial numbers ?) and then retire or redefine the function of the "changed" line. Role objects in admin-c lines ----------------------------- EJB3-RIPE, following up the proposal made by RVDP3-RIPE at RIPE #30, said that the current use of the role object is limited to non-admin-c attributes. He went on to say that address space is not assigned to an individual, but to an organisation. He then made a presentation about using role object in admin-c lines. This presentation is available at: http:// His presentation may be summarised by saying: the use of the role object in the admin-c line should be allowed. - Questions & Discussion AVA4-RIPE pointed out that NCC Registration Services need to see when someone leaves a local registry, especially when that person has experience of LIR procedures and policy. Currently, when a local registry changes its admin-c, the top level allocation object must be changed manually by NCC Registration Services. EJB3-RIPE replied that the information is still in the role object. WW144 recommended that the admin-c for a role object must reference a person object and not another role object. *AP* WW144 proposed that role objects should not be allowed for top level allocation objects. He went on to say that if there was consensus on this issue, then the boundary conditions should be defined. JZ38 agreed with this exception i.e. that role objects should not be permitted in top level allocation objects. DK58 agreed with the proposal and suggested that an "organisation" object be specified in the new implementation of the db. EJB3-RIPE recommended that this proposal be implemented asap. *AP* WW144 recommended that the DB WG should accept this proposal and thanked EJB3-RIPE for making it. At this point, the session adjourned for coffee. ----- Coffee ----- Suppression of the "notify" attribute in the output of whois ------------------------------------------------------------ WW144 said that there was a proposal from Australia (who ???) to suppress the "notify" attribute in the output from whois. The DB WG did not have a strong opinion on this and this proposal was not considered any more. IPv6, inet6num and site object ------------------------------ WW144 reminded the DB-WG that, following decisions made at IETF-42, formal requests for IPv6 address space were sent to the three regional registries. The regional registries will design the procedures and co-ordinate the activities. JLSD1-RIPE showed a template and an example of an inet6num object in the RIPE database. He requested comments on what functionality could be added to, or deleted from the object. He pointed out that there is no "route" object for IPv6, but said that the Routing WG will look at this. WW144 discussed the site object; he said that currently it is used to track tunnelling and IPv6/IPv4 address translation. He recommended that the DB WG look at the 6 Bone homepage on the web at http://www.6bone.net/ and he recommended that they read the RPSL specifications, the RIPE-181 document and review the inet-rtr object. Nameserver object ----------------- Steve Byrne (Steven Burley ??? ) suggested that a "nameserver" object be used in the RIPE database. *AP* WW144 asked him to write a proposal and to circulate it on the DB WG list. DB Software Re-implementation ----------------------------- JLSD1-RIPE gave a presentation on the re-implementation of the db software. This presentation is available at: http://www.ripe.net/meetings/ripe/ripe-31/pres/reimp/index.html - Questions && Answers Kevin Hayton (KH220-RIPE) asked if the new software would address the security issues as done in the IRR. He went on to ask if a web-interface [for updates] would be provided. JLSD1-RIPE said that the security issues would be handled in the new implementation and that if required, a web-interface would be developed. JLSD1-RIPE went on to say that the new implementation would have three separate modules: one each for Inetnum, Domain and Routing object, but that the underlying access would be the same. WW144 asked if the progress of the new code would be made public ? JLSD1-RIPE replied that there would be regular reports, which would be quickly followed up with the new code. He went on to say that the current aim was to support the current functionality. SB-RIPE asked if the new code would be written in PERL. JLSD1-RIPE replied: "No". WW144 said that he hoped that the package would be self-contained. JLSD1-RIPE said that the new implementation would not specify which SQL engine should be used. Thus, the new implementation would have a well-defined API and users could then obtain appropriate drivers. He added that, initially, MySQL would be used. AH102-RIPE asked what was the proposed implementation language. JLSD1-RIPE replied that it would be C - for reasons of maintainablility and resources. He went on to say that if the new code was to adequately support the RAToolSet, then it must be capable to respond _very_ quickly to look-ups. Thus, a faster response time was required (e.g. to support prefix authentication, as supported by the code of the Routing Registry). WW144 thanked JLSD1-RIPE for his presentation. Internet Draft on database security ----------------------------------- WW144 introduced the presentation by JZ38 by saying that he [JZ38] had written an internet draft and that this document would be adopted by the RPS WG of the IETF. JZ38 presentation may be found at http:// WW144 thanked JZ38 for his presentation and added that the code was now available on the RIPE NCC's Beta site. Deployment of PGP in the RIPE db -------------------------------- JLSD1-RIPE gave a presentation on the deployment of PGP in the RIPE db. This presentation is available at: http://www.ripe.net/meetings/ripe/ripe-31/pres/pgp-sup/index.html He said that licenses would only be be issued for users who already had a mntner object and that licences would issued within the next two to three weeks. JLSD1-RIPE said that details about support would be sent to the DB-WG mailing list. WW144 asked that that this mail be also sent to the LIR WG. HPH2/HPH14-RIPE agreed with this. WW144 emphasised that the licences were for PGP Version 5.0, although newer versions were available. Steven Byrne (Burley ???) asked if the licences were issued to a user. JLSD1-RIPE replied that the licences were issued on a per cpu basis; if a user requires more, s/he should ask for them. There were no questions about the cost of these licences. Upgrade of ripe-157 ------------------- JLSD1-RIPE gave a presentation on an upgrade of, and a replacement for, ripe-157. This presentation is available at: http://www.ripe.net/meetings/ripe/ripe-31/pres/ripe157plus/index.html - Questions && Answers; ripe-157++ Kevin Hayton (KH220-RIPE) said that although the content of RIPE documents was important, the presentation was also important. Furthermore, he suggested that the naming structure be reviewed and that the documents be redesigned to include hot links to other documents. WW144 agreed with this idea for html versions of RIPE documents. He suggested that key documents be given *AP* generic names. He also asked Kevin Hayton to send his ideas to the mailing list. - Questions && Answers; PGP and the RIPE db Kevin Hayton (KH220-RIPE) asked if the key certificate object would be listed in the general whois enquiries. JLSD1-RIPE replied that it would. KH220-RIPE suggested that this might be a security compromise. JZ38 said that a user must submit the public key to the db so that it is available for anyone to check the signature. Petra Zeidler, Xlink, felt that sending a key-certificate object to the RIPE db by e-mail, with no other checks was risky. JZ38 felt that the RIPE NCC should identify to whom a given certificate belongs and that is why they require that that anyone who requests a key certificate object must first have a mntner object in the RIPE db. He added that any problems with this approach would be detected by the notification mechanism and then the problem could be solved off-line afterwards. WW144 pointed out that this is the first attempt to upgrade security in the RIPE db, but that it is not the definitive one. The goal was to implement an useable system, sooner rather than later, although the shortcomings of the initial implementation were known. Petra Zeidler suggested that key certificate objects should only be visible to the maintainer her/himself. The meeting felt that there was a danger that some people will use the PGP key in the RIPE db for other purposes. JZ38 recommended that users should check other sources of public key rings. Petra Zeidler suggested that the type of key be mapped into the key certificate object itself. JZ38 recommended that users should always retrieve the local key. Petra Zeidler commented that a key-ring of 1200 keys would be slow. AH102-RIPE commented on how to check the authenticity of a key, instead of the NCC not taking responsibility for the authenticity of a key. JZ38 said that people who use PGP should be aware of this. RPS authorisation && authentication ----------------------------------- Cengiz Alaettinoglu gave a presentation on RPS authorisation and distributed RPS. This presentation may be found at: http://www.isi.edu/~cengiz/talks/ and it is based on these Internet-Drafts: draft-ietf-rps-dist-00 draft-ietf-rps-auth-01 - Questions && Answers Kevin Hayton questioned whether or not RPS authorisation and authentication could cope with multi-homing. *AP* WW144 and Cengiz Alaettinoglu promised to send the name of the appropriate draft to the mailing list. IETF-42 reports --------------- WW144 said that there were no important reports from IETF-42. Input from other WG's: --------------------- Routing WG: + An IPv6 Routing Registry is being planned. WW144 invited the DB-WG to give input. + IRR Acceptable Use Policy; WW144 asked if this would form a basis for a code of conduct for the RIPE db. WW144 invited the DB-WG to contact the appropriate individuals privately. AOB: --- NULL Close ----- WW144 thanked the members of the DB-WG for participating that morning and then formally closed the session. ------- =_aaaaaaaaaa0-- --------------------------------------------------------------------------------

1 0

RIPE32 DB-WG Draft Agenda, version 2
by Wilfried Woeber, UniVie/ACOnet 22 Jan '99

22 Jan '99

Attached please find the 2nd draft of the Proposed Agenda for the DB-WG meeting during RIPE32 in Amsterdam, next week. As compared to version 1 there is a small addition and some editorial improvements. Regards, Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Proposed Agenda for the Database Working Group Meeting RIPE-32, January 1999, Amsterdam 2. Draft A. Administrative stuff (Wilfried Woeber, chair) - appointment of scribe - agenda bashing B. RIPE DB, operational update (RIPE NCC) - statistics, performance, changes, most recent mod.s - RPSL migration update, usage - documentation update C. PGP deployment in the RIPE DB (RIPE NCC: Roman) - current status of delpoyment, feedback D. DB SW Re-implementation (RIPE NCC: Joao) - status, milestones/roadmap, resources required/available E. Migration to the new SW - operational aspects - proposal to *not* migrate obsoleted objects and attributes . dom-prefix . any others? F. I-D draft-ietf-rps-auth-01, -rps-dist-?? (??) - RIPE region requirements/comments - any progress G. Handling of person: & role: objects - proposal to auto-generate handles for objects without | - proposal to *not* allow re-use of handles, pro.s and con.s - proposal to force-add maintainers for contact objects - operational issues, e.g. sharing maintenance of an object - impact on tools or scripts? H. Review of referral mechanism (this might go to Input from other WGs) X. IETF report(s) (??) Y. Input from other WGs - Review of referral mechanism (might be promoted to be an agenda item in it's own right) - Tagging IP-Address ranges as Dial-In (proposal by Poul-Henning Kamp <phk(a)freebsd.org>) - t.b.d. Z. AOB ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WW, 22-JAN-1999 15:09:12 -------------------------------------------------------------------------- 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

RIPE32 DB-WG Draft Agenda, version 1
by Wilfried Woeber, UniVie/ACOnet 21 Jan '99

21 Jan '99

Attached please find the 1st draft of the Proposed Agenda for the DB-WG meeting during RIPE32 in Amsterdam, next week. As usual - comments, additions, proposals appreciated. I would also invite you to review the content hints for the individual topics, to maybe review the WG mailing list archive and - where appropriate - to submit comments and proposals to the list before the meeting; in particular if you do *not* intend to be there during the WG meeting itself. Due to considerable over-load on my end at the moment, there's a very good chance that some items are missing from the 1st draft, even if I had acknowledged them beforehand. There is no intention to drop these things! Please request them again and I'll amend the proposed agenda. I might still find them on my own, though :-) Thanks, regards, and see you in Amsterdam during next week! Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Proposed Agenda for the Database Working Group Meeting RIPE-32, January 1999, Amsterdam 1. Draft A. Administrative stuff (Wilfried Woeber, chair) - appointment of scribe - agenda bashing B. RIPE DB, operational update (RIPE NCC) - statistics, performance, changes, most recent mod.s - RPSL migration update, usage - documentation update C. PGP deployment in the RIPE DB (RIPE NCC: Roman) - current status of delpoyment, feedback D. DB SW Re-implementation (RIPE NCC: Joao) - status, milestones/roadmap, resources required/available E. Migration to the new SW - operational aspects - proposal to *not* migrate obsoleted objects and attributes . dom-prefix . any others? E. I-D draft-ietf-rps-auth-01, -rps-dist-?? (??) - RIPE region requirements/comments - any progress F. Handling of person: & role: objects - proposal to auto-generate handles for objects without - proposal to force-add maintainers for contact objects - operational issues, e.g. sharing maintenance of an object - impact on tools or scripts? G. Review of referral mechanism (this might go to Input from other WGs) X. IETF report(s) (??) Y. Input from other WGs - Review of referral mechanism (might be promoted to be an agenda item in it's own right) - Tagging IP-Address ranges as Dial-In (proposal by Poul-Henning Kamp <phk(a)freebsd.org>) - t.b.d. Z. AOB ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WW, 21-JAN-1999 17:03:42 -------------------------------------------------------------------------- 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

RIPE NCC PGP license distribution
by Joao Luis Silva Damas 20 Jan '99

20 Jan '99

Dear all, as you may be aware from past presentations at RIPE meetings and discussions in the lists, the RIPE Database now supports PGP authentication as a stronger way of protecting your database objects. This use of PGP with the RIPE Database is seen by PGP Inc as a commercial use of their software that therefore requires a commercial license. To enable users to take advantage of the new feature, the RIPE NCC will distribute PGP licenses to Database users according to the policy and procedures described in a new RIPE Document: RIPE 190, available now at the RIPE NCC's website. http://www.ripe.net/docs/ripe-190.html To obtain more information on how to use PGP with the RIPE Database, please refer to the recently release RIPE 189 document, also available at the RIPE NCC's website. http://www.ripe.net/docs/ripe-189.html Please direct any questions/comments to ripe-dbm(a)ripe.net Best regards, Joao Damas Database Group RIPE NCC

1 0

New RIPE doc + new RIPE Database release
by Joao Luis Silva Damas 14 Jan '99

14 Jan '99

Dear colleagues, we are happy to announce a new RIPE document together with a new maintenance release of the RIPE Database code. New RIPE Document RIPE 189 - RIPE NCC Database documentation update to support RIPE DB ver. 2.2.1 A new RIPE document to supplement RIPE 157 as reference material on the use of the RIPE Database. Describes new or modified functionality since RIPE 157 was issued. Covers DB releases up to the 2.2.1 release (see below). New RIPE Database release Version 2.2.1 is mostly a maintenance release. There are very little user visible changes from version 2.2. For more details please read the release notes available at ftp://ftp.ripe.net/ripe/dbase/software/RELEASE-NOTES-2.2.1 This version will go into production at whois.ripe.net next Monday. It is available for download now from ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-2.2.1.tar.gz Best regards, Joao Damas & all the Database Group RIPE NCC

1 0

FW: Database security
by Barak Engel 05 Jan '99

05 Jan '99

Hi all, Wilfried asked me to forward this to the list, so here goes :-) 10x, Sincerely, \'"'/ Barak Engel ( o o ) ---------------------ooOO-^-oOOo--------------------------- barak(a)netvision.net.il Network Expert BE-RIPE BE174 Phone/Fax: +972 48 560600/551132 Cellular: +972 50 469 341 ----------------------------------------------------------- -----Original Message----- From: Barak Engel [mailto:barak@netvision.net.il] Sent: Tuesday, January 05, 1999 6:10 PM To: Wilfried Woeber, UniVie/ACOnet Subject: RE: Database security Wilfried hi, Many 10x. As I didnt see that this went to the list, Im not mailing my answer to the list too. See my comments in the text body. Barak > -----Original Message----- > From: Wilfried Woeber, UniVie/ACOnet [mailto:woeber@cc.univie.ac.at] > Sent: Tuesday, January 05, 1999 5:12 PM > Subject: RE: Database security > > 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... Sorry :-) IL-NETVISION > => 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 :-( Alright, as I said, I wasnt here... sorry if its an old wound. > 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 :-) Agreed. > . 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... Hmm... well, this sort of functionality could be preserved by adding a new field, or doing the searches by netname instead of descr. I guess. > 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 ;-) True. But this may require more knowlegde and research, and therefore might be missed by some. In any case, it is possible to restrict each object by password (i.e. add password field or whatever), which will solve this problem. > 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... Yes, I guess thats true... Im just trying to point everyone's attention to this issue, TBH. I dont have any magical solutions short of descussing the whole DB structure. > => 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. Well, this is again true... but if we could find some ways to close the bigger loopholes, we may achieve most of what I feel we should be looking for. > 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 > -------------------------------------------------------------------------- >

1 0

Database security
by Barak Engel 04 Jan '99

04 Jan '99

Hello all, I am new to this mailing list, so please forgive me if I do not adhere to established processes. I promise to learn as we go on :-) The issue I would like to bring up is that of database security, namely, the fact that the database is completely accessible by anyone. Why do I propose that this is a problem? Let us, for the sake of this example, consider two fictive companies, NetISP and ISPNet. Both are ISP's, and they compete over market share in their country. As you are aware, a full customer list is considered very useful information in industrial espionage in this field, something that one company would most certainly not want to reveal to the other. Yet, with the RIPE DB open for prying eyes, both ISPs could easily gain this info. Alright, you say, so what? Both suffer from the same disadvantage, right? Well, not really. Following are just two scenarios I cooked up to explain why: 1) NetISP has been in the market for four years. ISPNet is new, and is interested primarily in market share. Since this is their focus, being new, they can allow themselves the luxury of selling at losing prices, in an effort to establish a market share. Looking at the RIPE DB, they can immediately find all the customers of NetISP, and try to "steal" them away. NetISP, however, has no such option. 2) NetISP got RIPE allocations, while ISPNet got other allocations. Why? It happens. In Israel, for example, the range 192.114.0.0-192.118.255.255 can be allocated without having to update the RIPE DB. Assume for a moment that NetISP have RIPE allocated IPs, while ISPNet have those "special" IPs. Only the latter will be able to check on the former. Again NetISP will lose. I suggest that some security feature be added to the database. Maybe hide some fields with a password, or make the retrieval utility more secure. There is a serious business problem here that I feel needs to be resolved. Many 10x, Sincerely, \'"'/ Barak Engel ( o o ) ---------------------ooOO-^-oOOo--------------------------- barak(a)netvision.net.il Network Expert BE-RIPE BE174 Phone/Fax: +972 48 560600/551132 Cellular: +972 50 469 341 -----------------------------------------------------------

3 4

Re: updating a person object
by Joao Luis Silva Damas 30 Dec '98

30 Dec '98

Hi, Object reordering only takes place when the mail contains AUTO nic-handle creation. This is because references to the new object need to be resolved (by creating the nic handle) before the other objects can be processed. If you don't request AUTO nic handle creation, there is no reordering. Therefore, sending a mail containing a delete followed by a creation should be safe (the only possibility for it to go wrong would be if between the processing of the deletion and the creation an update taking place at the same time grabs the old nic handle. This is extremely unlikely and impossible to do on purpose since it depends on machine load, etc). Once again, if the object in the deletion is referred to by other DB objects the deletion will fail. But in this case, so would the creation immediately after it, since the nic handle would be in use. regards, Joao "Wilfried Woeber, UniVie/ACOnet" <woeber(a)cc.univie.ac.at> writes: * >you're right - it's possible this way if the person object isn't * >related to any other object in the database. FMPOV it should be * >strongly recommended that deletion and re-creation would be done * >by just _one_ email to 'auto-dbm@...' because of the sequential * >processing. This avoids the re-use of the NIC-handle by the * >'AUTO-1' mechanism in between two separate mails. * * This is also my "gut-feeling". * * However doing so in many cases generates "funny" error messages * due to object re-ordering within a single update message, and it * might interfere with what you had in mind. * * I think this is still not resolved completely. * Maybe the DB SW technicians could clarify this issue? * * Wilfried. *

7 9

Re: Maintainer creation policy
by Havard.Eidnes＠runit.sintef.no 29 Dec '98

29 Dec '98

> the RIPE NCC is considering relaxing the requirements for obtaining a > maintainer. This has certain consequences that we would like people > to consider and then put forward comments either supporting or > rejecting this proposal. > > We propose the following new policy: > > - The RIPE NCC will create maintainers for all users whose person/role > object is mentioned in any object in the RIPE database except if it is > only mentioned in other person or role objects. > - If the person/role is not mentioned in any other object, the > maintainer will not be created. > > This should allow all users to protect their data but prevent the > database from becoming some sort of "phone book". Maybe I'm getting out of touch with things, but frankly, I do not see how this solves the "phone book" problem or any other problem for that matter. Instead I see it creating a few new problems... I also do not really understand from the description above what exactly is going to happen. Some interpretations: o All "person" objects referenced from other objects (except "role" objects) will result in the creation of a new maintainer object for that user, and the user's maintainer will be added as a mnt-by: attribute of the objects where the person was referenced earlier. If the total size of the database is a problem (and I think it is), this will not help one little bit, as this will add new objects corresponding to a *large* percentage of the person objects in the database. Furthermore, it is not necessarily true that users referenced as admin-c, tech-c or zone-c *own* the information registered, although there may be consensus that this is so for the Internet registry part of the RIPE database. For the other "subparts" of the database there may be policy implications of updating the information, a prime example could be information from the domain registry side. o The RIPE NCC will add mnt-by: attributes on all person objects referenced from other objects (except "role" objects). Which maintainer is to be used is not exactly stellar clear. I consider this to be an unlikely interpretation, although I must say that the statements above are sufficiently unclear that I do not clearly understand what is going to happen. I do not understand at all how this will reduce the "phone book" problem of the RIPE database, as this will not prevent the creation of "free- standing" objects in the RIPE database (?). I furthre presume that the "phone book" problem is exactly this -- free-standing, un-referenced person objects? Another alternative to the "phone book" problem could be that a large part of the RIPE database is indeed objects resulting from it making double duty as a domain registry information repository, although I still seem to remember statements by the RIPE NCC to the effect that this is not regarded as a problem. Why not just permit maintainer object creation by anyone satisfying the above requirements ("reference exists"), but not create the maintainer objects themselves or the mnt-by: attributes? I cannot see that there have been any comments to this proposal, so am I the only one who does not understand what is going to happen, and what the rationale for it is? I do however think that the effective time between announcement and implementation is way too short -- with IETF and Christmas and New Year holdays in-between it comes down to 1-2 weeks only. Regards, - Håvard

2 1

Re: updating a person object
by Andreas Scher 28 Dec '98

28 Dec '98

Hi Joao, >If the old object is being referenced by other objects in the Database, the >deletion will not succeed because of integrity checks. In this situation you >may ask ripe-dbm(a)ripe.net to modify the object for you. You will need to >produce some sort of ID to make sure you are the person responsible for that >object. More info upon request. thanks for the answers (to all others too). There where references to two other objects in the database. So I will send my request to ripe-dbm(a)ripe.net. Kindly regards Andreas Scher ----------------------------------------------------------------- Andreas Scher scher(a)planet.de -----------------------------------------------------------------

1 0

updating a person object
by Andreas Scher 28 Dec '98

28 Dec '98

Hello, is it possible to change (correct) the name of a person object without changing the nic handle (delete and create new) ? Perhaps is it possible to delete the object and create a new one with the old nic handle (not AUTO-1). Is it possible and allowed ? Thanks in advance Andreas Scher PS: I hope my question points to the right group. Please let me know the right address if not. ----------------------------------------------------------------- Unternehmensgruppe PLANET - Hagenower Strasse 73 - 19061 Schwerin -----------------------------------------------------------------

1 0

Re: Subnetting legacy Class B networks
by Wilfried Woeber, UniVie/ACOnet 16 Dec '98

16 Dec '98

Hi Randy! >for the record, verio also filters B on /16. we do so because that is what >the registries told us were allocation boundaries. if registries intend to >change these policies, it would be kind to warn and discuss. I think we should try keeping separate things separate. From my point of view, the information about the allocation boundaries as provided by the registries is one thing. Users (ISP customers), announcing subsets of address-space they got assigned somehow, maybe from a legacy class B block, is another thing. If they do so without checking the constraints of the routing system, on the technical side, or the contracts with their ISP(s), on the administrative side, then this is outside the responsibility of any IP-allocation- or Routing-Registry, I think. But I'm sure *you* are perfectly aware of that :-) Cheers, 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

New RIPE database software release
by RIPE Database Administration 16 Dec '98

16 Dec '98

Dear Colleagues, we are happy to announce the new release of RIPE database software. It is running now on our production system and is available for download from: ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-2.2.tar.gz. Release notes are in: ftp://ftp.ripe.net/ripe/dbase/software/RELEASE-NOTES-2.2 Most important new features are: - PGP authentication support - referral mechanism for domains - referential integrity checks - new syntax checks - bug fixes For more details please read the release notes. If you have any problems, questions, remarks, bug reports - please send mail to ripe-dbm(a)ripe.net. User documentation describing new release is being worked on and we hope to make it available soon. We would also like to inform you that we have migrated our database server to new hardware and OS platform - it is now running on Sun Enterprise E450 machine under Solaris 2.6 operating system. We hope you will experience performance improvements. Best regards, Roman Karpiuk RIPE NCC Database Group

5 4