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