- db-wg - mailman.ripe.net

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 29 Dec '98

29 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

Problems with <auto-dbm@ripe.net>
by RIPE Database Administration 11 Dec '98

11 Dec '98

Dear Colleagues, Mail for <auto-dbm(a)ripe.net> was not delivered since last night untill this morning. We have fixed the problem, and updates are now being processed again. No updates were lost; they were stored and you do need to send them again. However, there is a big queue of updates yet to be processed. We anticipate that the update queue will be at normal levels within 60 to 90 minutes. If you have any questions, please contact <ripe-dbm>. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Pedro Figueiredo ____________________________ RIPE Database Administration.

1 0

maintainer
by Hostmaster INTERNETX 10 Dec '98

10 Dec '98

Hi there, how we could get a maintainer-handle for protecting the handles of our customers? We have a class-c and are a ISP? If this is not enough, why? Best regards ________________________________ InternetX, Domain Service Center Hr. Bems, hostmaster(a)internetx.de Tel. +49 941 5839458 Fax. 5839460

2 1

Maintainer creation policy
by Joao Luis Silva Damas 07 Dec '98

07 Dec '98

Dear all, 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". Some consequences of this would be: - The RIPE NCC would no longer do any identity checks on the requester (compliance with the policy will be, of course, checked). - Users may wish to protect objects that already have (soft) maitainers. A clear example would be a user protecting a domain object with a soft maintainer (eg: auth: NONE) with their own maintainer (which may have PGP on it). - Users with inetnum,route,etc objects are strongly encouraged to protect their objects with a strong maintainer to prevent accidental or malicious "protection" by other users. Note: Any object can have more than one maintainer. To modify/delete an object only one maintainer authentication needs to be matched. In order to add a maintainer to an object that already has one (or more) the user will need cooperation from one of the previous maintainers. Waiting for your comments, Joao Damas RIPE DB Group RIPE NCC

1 0

Re: Ripe change to whois
by Hank Nussbacher 03 Dec '98

03 Dec '98

At 04:00 PM 11/30/98 +0100, Joao Luis Silva Damas wrote: Just check http://www.checkdomain.com with some nonexistant domain housed at RIPE and tell me if something isn't wrong here. -Hank >Hello. > >I am including the tld-wg into this discussion so as to make sure all involved >parties are aware of the discussion. > > Alexander Koch <akoch(a)sgh-net.de> writes: > * Hello. > * > * > The design of this feature was specified some time ago by Carol Orange and > * > * > Wilfried Woeber (please see http://www.ripe.net/meetings/ripe/ripe-27/pres > * /rout > * > e/referral/) and discussed in the RIPE db-wg mailing list (please see > * > http://www.ripe.net/mail-archives/db-wg/19970501-19970601/threads.html) > * > * Oh. Fine. Do I get it right that this was discussed and agreed on > * more than a year ago? Argh. > * > >Yes, indeed. We had a period where we have been late with developments. That >period is now behind us. > > * This change breaks too many things, imnsho, and it seems again that if > * you are not able to make it to the RIPE meetings, you have lost. A > * special announce would have been most helpful (an explicit one, stating > * this). > * > >But, we did... or so I thought. We'll look into more ways of getting this >announcements across while trying to minimize the mails sent to people who >don't care about this. > >This particular feature has been actively asked for by the ccTLD >adninistrators and seen as a good thing by everyone I have had a chance to >speak with. These are actually the first complaints about it we have got so >far. > > * > As a side note I would like to stress that the RIPE Database is NOT the so > * urce > * > of authoritative data for domain objects (although we are happy to provide > * a > * > repository for TLD administrators). > * > This is UNLIKE the internic whose business is to sell names. > * > * Oh. Fine. whois.nic.de *cough* barely ever working... Weak argument. > * And If I wanted to know the data about the domain one level higher, > * I can do so myself, I don't need to get it told to me by whois, I > * want to know whether crab.de (bad example, it really exists) is in > * the DB already or not. > >I am sorry but I can't talk about the availability of services we don't >operate. > >I am sure you can look up domains yourself but this was actually seen as >providing the users (specially the ones less familiar with the RIPE DB) with >help on where to find the correct information. > >It seems to me that over time people have developed a sense that the RIPE DB >is the authoritative source of information regarding domain names in Europe. >May be this issue should be up for debate now. > >As a matter of fact the referral mechanism was seen as a way for ccTLD >administrators to include information in the Database pointing to their own >authoritative sources of information. > > * > * > The RIPE NCC is therefore acting according to users directives that were > * > discussed and agreed on an open way. > * > * Hitchhiker's Guide, anyone? *sigh* > >??? > > * > * This was a not-so-nice change, really. Consider this a statement of > * disagreement with the way the change took place. Ok, one more mailling > * list to follow... Time to sell. > >Will do so. As I said before, we will keep modifying and developing the RIPE >DB software and in particular this feature if users feel that is what they >want. We will also provide our point view. >I would like to have the input of the community. > >Regards, >Joao > > * > * Regards, > * Alexander Koch > * > * -- > * SGH Internet Division, Alexander Koch, Systems Administration > * Hannover, Germany, Phone +49 511 909198 0, Fax +49 511 391307 > * > > >

3 2

Re: Ripe change to whois
by Hank Nussbacher 03 Dec '98

03 Dec '98

At 06:35 PM 12/1/98 +0000, Niall O'Reilly wrote: >On 30 Nov 98, at 17:14, Hank Nussbacher quoted someone >who had written: > >> > >> >As a matter of fact the referral mechanism was seen as a way for ccTLD >> >administrators to include information in the Database pointing to their own >> >authoritative sources of information. > >I can confirm that this was indeed the intention when this was first proposed in >the RIPE (25, I think) DNS-WG meeting. > >> > * > The RIPE NCC is therefore acting according to users directives that were >> > * > discussed and agreed on an open way. >> > * >> > >Yes and no, I have to say. > >At RIPE 31, the functionality proposed certainly appeared to me to be what had >been sought. I am no longer certain that this is indeed the case. In particular, >the following surprises have arisen. > >First, the key notion of making the referral function available per TLD at the >option of the TLD registry concerned seems to have been lost. This is a >fundamental element of the original concept of over two years ago. > >Second, the "feature" of returning the data relating to the parent domain in the >case that the specified domain cannot be found seems to me to have nothing >to do with referral. The referral concept has to do with re-directing the query to >an authoritative whois server, not with second-guessing the intent behind the >query and substituting other data which is available locally. I suggest that this >"feature" be declared a bug and removed. > >I am sure that these technical problems are based on misunderstandings which >can easily be resolved. > >A more significant surprise is that TLD registries, who have had no specific >prior notification, now find that data about their domains is being returned in >response to a class of query for which this was not formerly the case, and that >they have to deal with the unexpected fallout. Niall, Thank you for bringing sanity to this! I am sure now that this can all be cleared up and we can all go back to what we are all doing and let RIPE continue working the way it has always done - with no hiccups, technical excellence and 3 years ahead of the USA. -Hank > > >Niall O'Reilly > >IE Domain Registry at UCD >Chair, RIPE TLD-WG > >

2 1

Re: Ripe change to whois
by Frank Faubert 02 Dec '98

02 Dec '98

Hi All, Please forgive the intrusion, I am new to this discussion. Hank>Phone call #4 today. User goes to http://www.checkdomain.com to determine Hank>if ubuy.co.il is valid. www.checkdomain.com says the domain is owned by me Hank>(Internet Society of Israel). Now try it for xxxyyy.co.at or xxxxyyy.co.ie Hank>or any domain for that matter located at whois.ripe.net. This is just one Hank>Internet site that has based its site and code on how RIPE works. There Hank>very well may be others. I am the maintainer of checkdomain.com, and to be honest, I was completely ignorant of these changes to the RIPE DB until Mr. Nussbacher sent an e-mail to me. Hank>Just check http://www.checkdomain.com with some nonexistant domain housed at Hank>RIPE and tell me if something isn't wrong here. -Hank I have since updated checkdomain.com to check the "domain:" field returned from the DB and return the equivalent of a "no match" if it is not the same as the user specified. The new behavior is way too confusing to our users, who are checking to see if a domain name is still available. Joao>If people don't want to be subscribed to these lists but the work going on Joao>there is relevant to them may be it would be a good idea to, at least, make it Joao>a monthly task to overview the archives and look at the presentations given Joao>during RIPE meetings. Otherwise, how can we make sure that we reach all Joao>interested parties without spamming the rest? Have you considered an announcement list? I for one do not have time to constantly monitor the discussions on the DB list, as checkdomain.com is not a source of income for my company, but a completely free service we provide to the internet. However, I would very much like to receive announcements from RIPE to my direct e-mail address at frank(a)sane.com. If you choose to implement this, please add me to the announcement list. Joao>I would like to have the input of the community. While I am sure that the change was needed for some users, I'm sure that you can agree that it is also causing problems for other users. I think that it would be a very good thing if you could offer a method of getting the old behavior from whois queries, as well as a method of getting the new behavior. Now, I don't want to get involved in the debate over which way should be the default, but I think that both methods should be offered. Please let me know what I need to do in order to use the old behavior, so I can remove my quick hack from checkdomain.com and replace it with a supported method. BTW: I also want to thank RIPE for the DB service they provide! Sincerely, Frank Faubert checkdomain.com

1 0

NIC handle writeup
by David Kessens 01 Dec '98

01 Dec '98

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

4 6

Re: Ripe change to whois
by Hank Nussbacher 01 Dec '98

01 Dec '98

At 01:01 PM 11/30/98 +0100, Joao Luis Silva Damas wrote: Yes, that may be all correct - from a techno standpoint. What I am stressing is the human engineering aspect. Up till now, thousands of hits are sent to the whois.ripe.net every month to determine whether a domain exists or not. Users have been doing this for years. Suddenly, the output is different and they do not realize it. I highly doubt that the human engineering aspect was discussed or analyzed to any extent in the DB WG. -Hank >Dear all, > >The implementation of the referral mechanism is a new feature of the latest >release of the RIPE DB software. > >The design of this feature was specified some time ago by Carol Orange and >Wilfried Woeber (please see http://www.ripe.net/meetings/ripe/ripe-27/pres/rout >e/referral/) and discussed in the RIPE db-wg mailing list (please see >http://www.ripe.net/mail-archives/db-wg/19970501-19970601/threads.html) > >According to this proposal the algorithm to be implemented is > >(extracted from the proposal): >*********** >Algorithm >--------- >If the following query is submitted to the RIPE database: > > whois [flags] xxx.yyy.zz > >the algorithm will work as follows: > >------- >NAME="xxx.yyy.zz" > >until (NAME = "") { > If object with domain = NAME found, > If object contains referral (see "Referral" below) > forward query (see "Forward" below) > Else > return object > Else > Strip(NAME) (xxx.yyy.zz -> yyy.zz, etc) >} > > >NOTES >----- >1. We move up the tree here, and return the next level answer >if present. If the query requests "tuintje.cwi.nl" (Piet, do you >mind?), they currently get "No entries found ...". In the new >mechanism, they would get: > >domain: cwi.nl >. >. >. >mnt-by: NL-DOMREG >changed: hostmaster(a)domain-registry.nl 19950227 >source: RIPE > >Moreover, if the object for cwi.nl contains a referral, the query >would be passed on to the specified server as explained below. > >2. The algorithm will be set off by any query which causes a search in >the domain object index. This means any query with "-T domain", or >any general query (no -T flag) with something that "looks like a >domain". >************* > >Currently and due to s small desynchronization within the RIPE NCC DB group >and the fact that the proposal was not clear about a particular point the >referred query is for the truncated object in the RIPE DB containing the refer >attribute. We want to modify this so that the query to the authoritative >server is for the user's initial query and not the result of the truncating >algorithm. This change will take place either today or tomorrow and a note >will be sent to the db-wg. > >As a side note I would like to stress that the RIPE Database is NOT the source >of authoritative data for domain objects (although we are happy to provide a >repository for TLD administrators). >This is UNLIKE the internic whose business is to sell names. > >The RIPE NCC is therefore acting according to users directives that were >discussed and agreed on an open way. > >We are happy to hear any comments about this or any other issues regarding the >DB software and will keep working to suggest and provide users with >functionality that will help them the most. > >Please send any comments to the RIPE mailing lists. > >Best regards, >Joao Damas >RIPE DB Group manager >RIPE NCC > > > NCC local-ir list Moderator <lir-mod(a)ripe.net> writes: > * > * I feel this is more appropriate to be discussed on the db-wg. > * > * Mirjam Kuehne > * RIPE NCC > * > * ------- Forwarded Message > * > * Date: Thu, 26 Nov 1998 19:21:13 +0200 > * To: <local-ir(a)ripe.net> > * From: Hank Nussbacher <hank(a)ibm.net.il> > * Subject: Ripe change to whois > * > * I may have missed it, but a serious *bad* change has occured to the whois > * interface. Previously, if I did a check on abcdef.co.il and abcdef did not > * exist, whois would return an error message. Now, whois returns the domain > * and role records for the next upper level domain - i.e. co.il or .il. Other > * examples: zzzz.ac.uk, zzzz.ac.at. > * > * How did I find out about this? I received 3 phone calls already in the past > * 24 hours from users in Israel stating that I personally am registered as > * owner of hundreds of domains. They state that being on the board of the > * ISOC-IL which oversees the registration, I have violated the rules (limit of > * 10 domains per person - other countries have similar restrictions). I have > * tried explaining to them that I am not the owner of these domains. If it > * was 1 user, I would assume they didn't read the entry correctly. But the > * fact that 3 totally different people have called me to ask whether I would > * sell certain domain names to them, I can only conclude that the RIPE change > * is not that successful. > * People have been used to getting an error message from RIPE, similar to the > * "No match" one gets from Internic. When they now get a valid response, they > * don't bother to check that the response is not for the domain they > * requested. There is no error message or error code. > * > * This needs to be rectified (and changes discussed in the future - ignore if > * it has been mentioned). > * > * - -Hank Nussbacher > * ISOC-IL board member > * > * > * > * > * ------- End of Forwarded Message > * > * > * > > >

4 7

Re: Ripe change to whois
by Hank Nussbacher 30 Nov '98

30 Nov '98

At 02:17 PM 11/30/98 +0100, Joao Luis Silva Damas wrote: Phone call #4 today. User goes to http://www.checkdomain.com to determine if ubuy.co.il is valid. www.checkdomain.com says the domain is owned by me (Internet Society of Israel). Now try it for xxxyyy.co.at or xxxxyyy.co.ie or any domain for that matter located at whois.ripe.net. This is just one Internet site that has based its site and code on how RIPE works. There very well may be others. -Hank >Dear Hank, > >May be (or may be not) the "human engineering aspects" were discussed enough >but, please, >if things like this affect your work so much, get into the db-wg mailing list >and give your input. > >The TLD wg was also involved in this and they were actually very much looking >forward to have this mechanism in place. > >If you still feel that "This needs to be rectified" you can discuss this with >the community, although it would have been better to discuss all this when the >design was proposed instead of going around the loop again (which, of course, >we'll do if users want to). > >I'll wait and listen. > >Regards, >Joao > > Hank Nussbacher <hank(a)ibm.net.il> writes: > * At 01:01 PM 11/30/98 +0100, Joao Luis Silva Damas wrote: > * > * Yes, that may be all correct - from a techno standpoint. What I am > * stressing is the human engineering aspect. Up till now, thousands of hits > * are sent to the whois.ripe.net every month to determine whether a domain > * exists or not. Users have been doing this for years. Suddenly, the output > * is different and they do not realize it. I highly doubt that the human > * engineering aspect was discussed or analyzed to any extent in the DB WG. -H > * ank > * > >

1 0

Ripe change to whois
by NCC local-ir list Moderator 30 Nov '98

30 Nov '98

I feel this is more appropriate to be discussed on the db-wg. Mirjam Kuehne RIPE NCC ------- Forwarded Message Date: 26 Nov 1998 17:21:38 -0000 Received: (qmail 23377 invoked by uid 0); 26 Nov 1998 17:21:35 -0000 Received: from ncc.ripe.net (193.0.1.99) by postman.ripe.net with SMTP; 26 Nov 1998 17:21:35 -0000 Received: from postman.ripe.net by ncc.ripe.net with SMTP id AA27381 (5.65a/RIPE-NCC); Thu, 26 Nov 1998 18:21:34 +0100 Received: (qmail 23374 invoked by uid 0); 26 Nov 1998 17:21:30 -0000 Received: from biff.ibm.net.il (192.115.72.164) by postman.ripe.net with SMTP; 26 Nov 1998 17:21:30 -0000 Received: from docking.interall.co.il (dial1.tlv.ibm.net.il [192.116.177.129]) by biff.ibm.net.il (8.8.8/8.8.2) with SMTP id TAA31544 for <local-ir(a)ripe.net>; Thu, 26 Nov 1998 19:21:26 +0200 Message-Id: <2.2.32.19981126172113.006820b4(a)max.ibm.net.il> X-Sender: hank(a)max.ibm.net.il X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 26 Nov 1998 19:21:13 +0200 To: <local-ir(a)ripe.net> From: Hank Nussbacher <hank(a)ibm.net.il> Subject: Ripe change to whois I may have missed it, but a serious *bad* change has occured to the whois interface. Previously, if I did a check on abcdef.co.il and abcdef did not exist, whois would return an error message. Now, whois returns the domain and role records for the next upper level domain - i.e. co.il or .il. Other examples: zzzz.ac.uk, zzzz.ac.at. How did I find out about this? I received 3 phone calls already in the past 24 hours from users in Israel stating that I personally am registered as owner of hundreds of domains. They state that being on the board of the ISOC-IL which oversees the registration, I have violated the rules (limit of 10 domains per person - other countries have similar restrictions). I have tried explaining to them that I am not the owner of these domains. If it was 1 user, I would assume they didn't read the entry correctly. But the fact that 3 totally different people have called me to ask whether I would sell certain domain names to them, I can only conclude that the RIPE change is not that successful. People have been used to getting an error message from RIPE, similar to the "No match" one gets from Internic. When they now get a valid response, they don't bother to check that the response is not for the domain they requested. There is no error message or error code. This needs to be rectified (and changes discussed in the future - ignore if it has been mentioned). - -Hank Nussbacher ISOC-IL board member ------- End of Forwarded Message

3 3

Re: Ripe change to whois
by Hank Nussbacher 30 Nov '98

30 Nov '98

At 02:17 PM 11/30/98 +0100, Joao Luis Silva Damas wrote: I admit that I have not taken part in the DB WG, since I trust the work done there, and all changes that have been done over the past years have been fine and in their place. This change too, from a technical aspect - is good. I would not have spotted the "human engineering" aspects either even if I was on the list and contributing. Sometimes, one can admit their mistakes and say we need to reevaluate the results. I have received another 3 calls today (we only register 500 domains per month on average in .il) from users wanting to buy .il domains from me. No one else is seeing this problem??? -Hank >Dear Hank, > >May be (or may be not) the "human engineering aspects" were discussed enough >but, please, >if things like this affect your work so much, get into the db-wg mailing list >and give your input. > >The TLD wg was also involved in this and they were actually very much looking >forward to have this mechanism in place. > >If you still feel that "This needs to be rectified" you can discuss this with >the community, although it would have been better to discuss all this when the >design was proposed instead of going around the loop again (which, of course, >we'll do if users want to). > >I'll wait and listen. > >Regards, >Joao > > Hank Nussbacher <hank(a)ibm.net.il> writes: > * At 01:01 PM 11/30/98 +0100, Joao Luis Silva Damas wrote: > * > * Yes, that may be all correct - from a techno standpoint. What I am > * stressing is the human engineering aspect. Up till now, thousands of hits > * are sent to the whois.ripe.net every month to determine whether a domain > * exists or not. Users have been doing this for years. Suddenly, the output > * is different and they do not realize it. I highly doubt that the human > * engineering aspect was discussed or analyzed to any extent in the DB WG. -H > * ank > * > >

1 0