______________________________________________________________________ DRAFT TRANSCRIPT Database SIG Thursday 2 September 2004 11.00am ______________________________________________________________________ XING LI: Good morning. Welcome back. I am chairman of this session. This is today's topics. First I will summarise the open items left from the previous SIG. The database policy is relatively simple compared with other policies. There are several remaining things. The first, db-16-002, the secretariat to implement the proposal to prevent customer records in the APNIC Whois database being publicly available. The update is open to be implemented by the third quarter of this year. The second from the previous database SIG - db-17-001: Pending approval at each remaining stage of the policy proposal process, APNIC secretariat to implement the proposal to protect historical records with an APNIC maintainer. Then this update is open - to be implemented by the end of this year. Then db-17-002 - a proposal for IRR mirroring policy to be returned to the database mailing list for further discussion. db-17-002. The proposer has been contacted and has advised that they are going to conduct some experiments and will resubmit the proposal after they have evaluated the results. That's for the IPv4 Whois database. Any questions? So everything is on the web. So we can continue to the items today after the summary. We have actually one proposal and the other are information items. The first one is the proposal from NTT on IPv6 IRR service at APNIC. KATSUYASU TOYAMA: My name is Katsuyasu Toyama from NTT. I'm also involved the JPNIC IRR planning team. Today I will make a proposal for IPv6 IRR service at APNIC. As you know, IPv6 network is being deployed gradually, but it is not so widely used now, although it will be inevitably used in future. This graph shows the current situation, the recent trend of advertised IPv6 prefixes. There were 545 prefixes of IPv6 that could be seen in the last month. The number of the prefixes is increasing. But compared with IPv4, the number of prefixes is far lower than that of IPv4, which is approximately more than 140,000 prefixes. So the IPv6 network is based on almost the same routing architecture as IPv4. That means the package of IPv6 is based on the destination numbers and routing information is exchanged between the odd number systems by the BGP protocol. The current situation of the routing table is IPv6 routing table is just like this table. I do not deeply explain this, but currently on the global routing table there is a variety of prefixes with various prefix lengths. Approximately 84 per cent of the prefixes are correctly advertised - there is not a good definition of the correct but approximately these are the good prefixes. We couldn't see any bogus routes on the routing table. The providers may filter those bogus routes out, but we couldn't see that. It seems to me fewer punching holes comparing with IPv4. There are few /33 or /42, /44 or /48. There seem to be fewer punching holes. Currently the IPv6 network is said to be clean. But when it will be widely deployed it will have the same troubles or anomalies as the current IPv4 networks such as instability due to misconfigured routing or malicious attack such as route hijacking. To prevent misconfigured or malicious routing information a mechanism verifying routing information is required. I think IPv6 IRR will serve as the database for verifying advertised prefixes, for example by generating the filters, the prefix filters, from IRR databases or advertised prefixes. Or if IRR database can store some kind of a certificate about an AS number or the prefixes or the private keys - no, public keys - of the providers, they can be used to verify the advertise prefixes. At least IRR database for IPv6 we can use it as a list of the contact points. Of course, IPv6 IRR should be able to be trusted by everyone - it should be trusted if it is always correct and updated. Also it covers all the routing information. These points are not achieved by current IPv4 or IRR, so we have to consider these things to build IPv6 IRR. So our proposal is as follows: first, a framework of IPv6 IRR should be discussed and defined; after that IPv6 IRR service should be launched by APNIC; then it will be promoted to other IRRs - in other words, encourage other IRRs to provide a service of IPv6 IRR. If we have an IPv6 IRR, it can contribute to the stable routing of IPv6 network, so if IRRs start the service earlier, the more easily IPv6 IRR is deployed. Of course, if we cannot build an IRR database for IPv6, some operation costs will increase. So the framework - outstanding issues on the framework of IPv6 IRR is just like this. The first, who will administer the IRRs - RIR, NIR, LIR? What kind of architecture will the IRRs have - that is another issue, like the current IPv4 IRR or as an improvement, if necessary. And how to keep the objects in IRR up to date - that is also another important issue. Do we do it by making some rules or procedures to keep those objects updated or graphic technologies to be used to keep those objects up to date. Also a schedule to provide IPv6 IRR service is an important issue. These are very complicated issues and many people have many opinions, so effort is required to establish a working group to discuss those things. This is one candidate of the architecture. So RIR keeps the routing registry. And also at the local level, NIR or LIR has the routing registry. And at the global level, the routing information which can be on the global routing table should be stored at the global level. Such kinds of things should be discussed. So I do not touch on them in detail. From the point of the schedule, the framework discussion should be done on the database SIG and/or policy SIG and to make some draft framework for IPv6 IRR. This is because it is sometimes closely related with global routing policy. And in the framework discussion and how to encourage other RIRs to promote the IPv6 IRR service or to collaborate with them about these framework discussions. In parallel to the framework discussion, maybe we have to verify the implement of IRR server software. After that process, we can launch the service. In summary, we propose a framework of IPv6 IRR should be discussed and defined. After that IPv6 IRR service should be launched by APNIC and it should be promoted to other RIRs. To achieve them, it is required to establish a working group for this discussion. Thank you very much. Any comments or questions? XING LI: Any questions or comments? SANJAYA: In preparing this idea, have you looked into expanding the current IRR service that APNIC has been providing for IPv4 or are you thinking of a new system altogether? KATSUYASU TOYAMA: If it is necessary to build a new IRR database, but the first - for the contact point at least I think the current version of that database can be used co-existent with IPv4 and IPv6. But as I proposed here, if IRR itself can be trusted by everyone and to ensure such things, it may be necessary to do some kind of mechanism or procedure. Those things may be supported by special software. So at the time I think there should be another software. But I think basically they can co-exist, IPv4 and IPv6. SANJAYA: Thank you. XING LI: Any other comments or suggestions? KATSUYASU TOYAMA: May I ask some questions of the committee. XING LI: Yes. KATSUYASU TOYAMA: Do you think that a unique IPv6 IRRs you don't need? I think it is important for the operations of IPv6. XING LI: Any comments? Anyone want to answer his question? Do we need shorthand. All right, how about I try shorthand. Who wants APNIC in general IRR to provide IPv6 routing registry information database? Who is thinking this kind of service is not necessary? So nobody. So actually people like the idea. However, the details should be worked out. KATSUYASU TOYAMA: So maybe you think a mailing list - maybe you think a mailing list. I will send some kind of a proposal or a draft out, a draft of the framework, so please make any comments on that. XING LI: OK. Unfortunately, frankly speaking, the mailing list is very, very quiet. So maybe this one can make the mailing list a little bit hotter. GEORGE MICHAELSON: George Michaelson APNIC. As a piece of background information, we expect to have a version of RIPE Whois software which is able to do RPSLng, the extension of RPSL which provides IPv6 IRR functionality and multicast routing registry functionality. We expect to have this some time towards the end of this year. I think we have good reasons to want to look at this code for other reasons, so infrastructure support, the mechanisms that let us support this activity, I think the timing is good for your proposal for the part about trying to do testing in December. I think promotion in 2005 - that is maybe an aggressive schedule, but it's good to do that. It's good we see it, we can get some activity around this. Maybe you're thinking at the Kyoto meeting? KATSUYASU TOYAMA: Yes. GEORGE MICHAELSON: So I think things are coming together for this. I would like to encourage Larry Blunk from Merit to participate in discussions because the other major implementation of IRRD he is responsible for. It will be an important area of convergence for us that this is able to do authentication with our framework if we can be a high-trust point to let people know about allocation and assignment of resources in registry process, then maybe we can help improve trust in this framework. So I think it's good that we have a signal that people want routing work and I think your idea of more discussion is good. KATSUYASU TOYAMA: Thank you very much. So more discussion is necessary about these kinds of things. So I'm trying to encourage people to join this discussion about the framework for promoting IPv6 IRR. XING LI: Thank you very much. The next presentation will be by APNIC's Sanjaya - privacy of customer assignment records - project update. SANJAYA: Thank you. My name is Sanjaya from APNIC secretariat. I'm going to make a report on the proposal that was approved in APNIC 16, so two meetings before. But we have been having difficulties implementing this because of technical reasons. But I'm hoping that this update will bring good news about the implementation of that policy. I'm going to just remind everybody about why we are doing this and also what needs to be visible in our database, in the public database, and the solution that we have in mind, what's the system configuration, what are the migration steps. And I'm going to show you a demonstration of how to hide and make visible resources in our database using MyAPNIC and then we'll continue with the implementation schedule and some frequently asked questions. Just to remind everybody, behind this proposal are three major motivations. One is the privacy issues. As we heard from the presentation during the plenary, there is increasing government concern about privacy. That is something that we really need to consider - of exposing customer assignment. Also there's an APNIC legal risk. Fortunately we have not so far been sued, but we have a responsibility for accuracy and advice to the public and there might be damages caused by us not maintaining accurate personal data. The last one is some of the customer data is poorly maintained. So one or another reason, probably negligence about updating the latest data - we clearly don't have direct control over customer assignment data because it's protected by the APNIC member themselves. Also it's quite expensive for a member to maintain if they must report all their customer assignments in the public database. That's why we have this policy proposal. And that is why it got approved in APNIC 16. Now we'll continue with what is it we're going to make visible in APNIC database. We are going to show the whole block of IANA range. Also the APNIC range. We will still show that. Non-APNIC range are those ranges allocated to other IRRs, but we put that in our database for reference process. We are also going to have those that are delegated directly by APNIC to direct members as well as NIR and we will also show NIR allocations and assignments. Anything below that - everything that is assigned by LIR or ISP - that is including customer assignments, infrastructure and suballocations - will have an optional visibility. In fact, the default behaviour would be not visible. But it can be moved to visible space by the responsible custodian. In APNIC Whois database terminology, if you remember, there's a status attribute in all the inetnum and inetnum 6 object. Then everything above this line would usually have a status attribute of portable - so it's assigned portable or allocated portable. Those below this line are what we would usually see as the assigned non-portable or allocated non-portable address. This is the system that we are building right now. We have the public database - the APNIC Whois database - that keeps all those that must be visible. Then we are also going to maintain a separate private database that will be seeded with the customer assignments, infrastructure and suballocations. Basically when we implement this policy we'll move all of this to the private database. Then it's up to the member to move it back to the public space if they want to. As you can see, the application that will be able to see the private database are the allocation manager, which is in APNIC software, and also from the member point of view MyAPNIC is the only application that can see the private database. No other application - email updates, web updates - will be able to see the private database. This is a very secure area which only MyAPNIC, which has a very strong authentication, can see. Migration steps - firstly, we must develop a system and test it. This is what I'm doing now - I'm going to shortly show you a prototype at this meeting. At some time we will announce a cutover date. It is selected for 30 September - so this month. After it is successfully done we will announce project completion. I'm going to show you my demonstration now. I'm going to use our test machine. When we implement this system, what you will see in MyAPNIC is you will be able to - maybe I should go back - it's lost the way - it's not looking good. Yep - whew! This is your usual resources scheme in MyAPNIC where you can look at all the allocation that you have received, the date of allocation, the size of the allocation and then usually if you drill down to a range, for example - I'll select this one - then you usually see the list of objects - the list of records that you keep in your Whois database. When we implement this policy you will see that most or all of your customer assignment records would be in this table, which is the private records. If we go to a Whois query for that range then basically you won't be able to see anything. It's not there - it's no longer there. But you can then - if you choose that some of the customer assignment need to be visible, you just click them and say move these two records to public. You can see now that these two records which were below here have been moved up to the public records shown in whois.apnic.net. It should be there - I don't know what happened! We should be able to see that record. So it seems - it's in heavy development, so probably some of the programmers in APNIC have been changing the code. So that's a short snapshot of what you can do as a member to move things to the public space. It's quite simple really. Implementation schedule: we are building the system now. It is still in prototype stage at the moment. We expect to complete development some time in the third week of September and do a lot of interim testing before that. I'm demonstrating the prototype now. We announced the migration last week, just before we started this meeting. Another reminder will be sent in the middle of September and just before the cutover we will migrate the data at the end of September and then announce the completion and prepare the report for APNIC 19. Some frequently asked questions: what will happen after migration? After we migrate on 30 September, only portable allocations and assignments will be visible and non-portable objects will not be visible. What if a member wants to keep their Whois records as they are, so they don't like hiding the customer assignments? Then they can immediately contact the help desk at apnic.net to revert the data. We can recover it. Within 48 hours we will recover your objects into the public space. Can an email to auto-dbm update private records? The answer is not at the moment. You will have to use MyAPNIC to maintain that hidden data. As I showed you in the system, nothing else in MyAPNIC will be able to see that record. However, we are implementing a new registry systems that will allow you to do so in the future. But that will not be in 2004. It will be probably next year. Can the public web update see private records? No. It is very secure. How can a member move objects from Whois to private database and vice versa, from public to private and private to public? The answer is use MyAPNIC. What if a member doesn't want to use MyAPNIC? If they don't want to use MyAPNIC they should put all their objects in public space so they don't need MyAPNIC. They can update everything like it used to be. What about related objects? What we are moving to the hidden space are inetnums, i6netnums, IPv6 addresses. How about nic-handles, contact addresses - will it be moved as well. The answer is no. But if you have moved your inetnums into the private space and you see no reason why you should keep a person in the public database you can just delete them. APNIC also has the regular maintenance program. If we see contact persons or role objects or anything else that doesn't relate to any other object - so it stands there not being used by any other object - then we will clean it up. We will back it up, delete it. So APNIC will do that. Can an inetnum that is referenced by a route object be removed from the Whois database? This is related to the IRR. Once you have registered your route object - when you create a route object it will check for the inetnum making sure that you are authorised to create it. However, once the object has been created, you can move it to the private space if you wish. But then the question is can a route object be created - that is referring to a private inetnum? Unfortunately, no. You have to make it public first, refer it to create the route object then move it back to the private if you want. That concludes my presentation. XING LI: Are there any questions? IZUMI OKUTANI: I have a question about registering the person object or role object. When you initially want to register your inetnum and you also don't want to have personal role objects disclosed in the Whois database, can you just submit the information without registering the person or role object? SANJAYA: No, you have to register the person or object but then you can delete it afterwards, if you want. XING LI: Any other questions? OK, thank you very much. I believe the next presentation is also by you. The next topic is protecting historical records in the APNIC Whois database. SANJAYA: This proposal was approved in the last meeting in KL. Again I'm going to remind everybody about why we're doing this, what the purpose was. What the implementation issues are we're facing - some editorial or administrative changes we made to the proposal and the implementation schedule. This is the one, as Professor Xing Li mentioned, is targeted for December. The background - why we want to protect the historical ASN and IPv4 address range is because they have become a source of abusive activities in the Internet. You only need to look at the URL I've shown on the slide to see how they profiled during this. When we look at the database that we had as of February this year, there are 3,190 of these objects in our database that we will categorise as historical. We don't know who the author is. The delegation was before APNIC was established. The director is of a nature that we cannot reliably identify who the custodian is. The decision from APNIC 17 is we should protect all this historical inetnum and aut-num with APNIC-HM maintainer. When we delegate a range to an ISP, then we would protect that allocation record with APNIC-HM. We'll do the same with the historical record. At the moment they're maintained by whoever that may not exist. We will change it to APNIC-HM. Does this mean they can no longer use the resource? No. Existing custodians can still use the resource. It can still be routable. It's just that the record will be locked - they will not be able to change the record anymore. This is to avoid people handing down historical allocation to other people as well. We lose the accountability of that range. The existing custodian who wants to maintain their records should sign a formal agreement with APNIC. So we should have an account relationship with APNIC and the annual fee is $100 per maintainer. But then there is an administrative change here. Because our relationship with other organisations - APNIC relationship with other organisations is based on account, not really on maintainer, so one account can have several maintainers, we changed the wording to annual fee is $100 per account. Implementation issues: from the technical point we need to be able to find and lock the historical records automatically and notify the affected parties. This is being developed at the moment. We see no issue here. I think we can do this. In the administration side, APNIC accounting needs to set up a new account type and a new contract form - a simple form for this historical account holder to sign and establish an accounting relationship with us. in the host master department, we need to have a way of validating historical address holder. So when somebody comes and claims, "I am the custodian of that historical space", we need a way of processing and knowing and validating that they are indeed the correct party. Then how would the host master service the historical record update request. Schedule: systems is being developed. We expect completion by the end of October. We also need, based on the feedback during the last meeting, to come back to NIR if a historical record is found in their country, just to check who is going to handle this. Would the NIR take care of it or APNIC directly? We have done that. We have consulted all the NIRs when we found the historical records that belongs to their country. We are in the middle of modifying the administration process, establishing new account, drawing up a new contract. Also the host masters are reviewing and changing their process to handle this new type of account. We're going to make an announcement some time early in November and December after we have locked the record. In the process of locking the record we will also send an email to whoever can be found at that moment, the contact person above this. So it shouldn't be a surprise to them. They should know it and they can respond immediately if they want to. After the completion in December we'll prepare for the APNIC 19 report. Some frequently asked questions. What will happen after December 2004? All the historical records will have mnt-by APNIC-HM. A mnt-lower will allow them to subdivide the allocation to smaller objects. Can the resource still be used by the existing custodian? Yes. This policy has no impact on the historical address usage. Must the existing custodian open an account with APNIC? The answer is no. They don't have to. However, if they don't establish an account relationship with APNIC, because we don't know who they are, we don't have a relationship with them, the record, of course, cannot be changed. So what would be the benefits of paying the $100 annual fee? The custodian can request update to the record if they change address or contact person - they can contact APNIC to change it for them. They will have a mnt-lower field maintained by themselves. They can subdivide the resource. And they have access to MyAPNIC account - they can use MyAPNIC capabilities for their benefit. Would it be difficult to open an account? We don't think so, as long as we are sure that you are the original organisation that received the delegation, we'll just ask you to sign a 1-page document - some sort of service level document with the APNIC and service level holder that will allow them to have all the benefits we mentioned in the previous question. The last one is what if the custodian is already an APNIC member? Then the record will be unlocked for them for free because they are already a member, we know who they are. But still it will be flagged as historical, so it won't be counted towards their membership size. That's it. Any questions? RANDY BUSH: On the enterprise side I get address space from the IRR. I'm their customer. I'm a customer of Connect here in Fiji. I get two or three pieces of address that I scatter around in my two or three sites. I have border routers - because I'm multihomed they have their own AS number. They speak BGP. Because of BGP security issues, I will soon want to use sBGP, for which I have to register a certificate. I have no LIR, I do not want to join APNIC, but I need the certificate and I need to register with the database. You don't have to answer today but we have a little problem. SANJAYA: Your question is more related to the previous presentation about what should we show in our public database, isn't it? RANDY BUSH: No. SANJAYA: Is it about historical records? RANDY BUSH: No, it's about joining and paying $100. SANJAYA: This only applies to historical records, this $100. You happened to be the one who received that delegation? RANDY BUSH: I receive it now. I generate my certificate. How do I put it in? SANJAYA: It's already there. RANDY BUSH: Not the certificate for the address block, but the certificate for my routers? GEOFF HUSTON: I think you're asking for another piece of implementation to support an sBGP style approach which requires border routers to actually participate in the certificate process in order to do integrity of AS paths. As a suggestion into what kinds of things in the coming months or years about making BGP more secure you need to do that and can't tie it to the initial allocation of risk. RANDY BUSH: I'm assuming that will happen. My problem was merely the administrative one of assuming that happens. I'm given the address space by an IRR not APNIC - so I'm not an LIR, I'm not an APNIC member but my cert has to go in there and I need to control it. It's an administrative problem. SANJAYA: From my understanding of how SGBP works the certificate has to be signed in a hierarchical manner - RIR, NIR, LIR, end user. There's the new RFC - 3780 - issued by KPIX about how you delegate the certificate -- RANDY BUSH: Let's not get distracted with SBGP. All I'm saying is there is an end site that is not an LIR or an APNIC member which will be generating and needing to restore their certificate in the database. I'm just addressing the administrative issue. All I'm saying is note that this is an anomaly, that the administrative model you just proposed has a little problem. SANJAYA: What problem is that? Sorry, I don't get it. PAUL WILSON: A current APNIC member has a large quantity of registrations, customer registrations, registered in the database if they choose to. The service includes customer registrations - no charge. I expect the same thing would apply to the certificates needed by those customers and that there will be an administrative procedure for whatever level of administration is required - by the customer or by the member. SANJAYA: Who is servicing this company - this end user - the NIR, right? RANDY BUSH: Maybe. SANJAYA: Or do they get historical delegation from 1990 -- RANDY BUSH: 1980. SANJAYA: So they receive a direct allocation from whoever and they've been using it ... RANDY BUSH: It's the AS number that's the problem, not the address block, because the AS number represents the router. We are on a very small corner case and we're spending too much time. I just want to note we have a problem. SANJAYA: Thanks, Randy. XING LI: Thank you. The next presentation is also by APNIC, Elly Tawhai - modification of Whois domain object authorisation. ELLY TAWHAI: Good afternoon. My name is Elly. I'm here to present Whois domain object authorisation. So currently non-MyAPNIC users when they submit a domain object to the database, there's a procedural problem. Now that problem is that the Whois database authorisation is hierarchical. And that APNIC maintainer is contained within the lower attribute for all APNIC /8 domain objects. Therefore, non-MyAPNIC users, if they try to submit, say, for example, create a /24 or a /16 domain object to the database, then it will fail. So up on screen you can see an example of a /20 which has been allocated to member XYZ. They therefore try and create a /24 reverse delegation. When they submit the domain object, as I mentioned before, to auto-dbm, it will fail. So, as I mentioned before, because APNIC's reverse maintainer is contained within the lower attribute of the parent object - 202.in-addr.arpa in this example - so only new domain objects with munt-by and password within the maintainer will succeed. Problems due to this authorisation model is that all domain objects need to be manually created. This is very inconvenient due to the time delay caused by this manual creation. So in effect we're not providing the best possible service due to this. So a procedural solution that has been come up with - say, for example, for allocations - we will compare the mnt-by of the domain template with the mnt-lower of the related inetnum object. To make this a bit clearer, you can see an example - I've put up an example of an inetnum object and a domain object. In this algorithm that has been come up with we would compare the mnt-by in the domain template with the mnt-lower of the related inetnum object. So if the correct passwords were provided for this maintainer and all the conditions were met, then the domain template would be passed and it would be created automatically. Now the procedural solution for assignments will be slightly different because portable assignments contain no mnt-lower attribute in the related inetnum objects. So therefore we compared the mnt-by in the domain template with the mnt-routes instead. So I'll jump show you an example to make it a little clearer. So we would compare the mnt-by in this domain template with the mnt-routes of the related inetnum object. The problem with this is mnt-routes is not a mandatory object within inetnum objects for portable assignments. So we would encourage members to use the mnt-routes attribute. If the correct password was provided and all the conditions were met, the domain template would be passed and the domain object would be created. Exceptions to this would be there are old allocations contained within the database which have no mnt-lower attribute. There are also some assignments with no mnt-routes attribute. In these cases we would encourage people to forward their domain templates that don't meet the solution to the help desk at apnic.net for manual creation. To provide you some statistics, 622 new domain objected were submitted for manual creation between 1 January and 27 February this year. Out of this number, 558 - that's 89 per cent - would have succeeded through this new algorithm. This solution would be implemented at the end of 2004. Does anyone have any questions? OK, thank you for your time. XING LI: We have some questions from the network. SPEAKER: We have a question from JPNIC on Java charge. I'll read it out for you. SPEAKER: I can ask from here. For Sanjaya's question from the second preparation about historical records. In the presentation I've seen it says a $100 fee. I know it's a one-time fee. In the presentation it said annual fee. I'm a bit confused. Can you explain which is correct? SANJAYA: It's in the proposal actually. The wording 'annual' is in the original proposal that got passed. SPEAKER: I'm confused, that's all. XING LI: So the last presentation is on RIPE database software update. LAURA COBLEY: Good morning. My name is Laura Cobley. I'm from the RIPE NCC. I'm going to give you an update on the most recent changes to the RIPE Whois database software. I've been asked to make the presentation on behalf of the software engineering department. If you have any questions at the end I'll do my best to answer you but I may have to direct you to those guys to help you out. I've been supplied with a bunch of handouts that may assist with more technical information for you. They'll be handed around some time during the presentation. The most recent changes that we've made to the software are not yet available for download. We're using them for our own database. But they will be made available for our other users as well. Firstly we have introduced support for X.509 as part of the effort to improve security in the database. This means that X.509 can now be used as a method of authentication and the key-cert class can support X.509 as well as BGP. Our users can update objects in the database using X.509 - email and web update and sync updates too. We've introduced organisation objects into the database to make it easier to trace organisations responsible for a specific resource. Previously with only person and role objects, it could be quite difficult to keep track of people who are responsible for an organisation or who might have left the organisation or not kept their records up to date. The 'org' attribute can be added to any kind of object and can be queried by its handle or its name and those inverse queries are also possible. It will be returned by default along with the person and role objects. We created the very first organisation object on behalf of IANA, RIR and LIRs and then updated inetnum, inet6num and as-block. Non-LIRs can have objects created. We've also completely overhauled the reverse DNS procedure as we had quite a lot of inconsistent and obsolete information. Previously the domain objects and DNS records were kept separately, which meant that in order to update the domain object in the database, the user would have to send a separate email to auto-in-addr@ripe.net, instead of the usual way. It was still possible to send the object to the database directly. When this was done the information was not replicated in the DNS. You can imagine what that meant - quite a lot of inconsistent information in our opinion, which we decided to clear up. In the old way, there was also no support for X.509 or web updates and we had policy restrictions in place, which meant occasional manual intervention from us and delays and work for the LIRs. The new procedure means that the database is now the authoritative source for domain objects. The DNS is then periodically updated using that information. The users no longer have to send their updates to a separate interface. They can now send their requests directly to the database - auto-dbm@ripe.net and we have removed a few of the policy constraints, which has had the effect of less need for manual intervention and less preparatory work for the LIRs. Those changes that we made to the policy constraints means now all allocated space can be delegated as opposed to only assigned space and you no longer need to be an LIR to send in the request. Another step towards improving security in the database has been the modification of the NONE. This means there are no unprotected records in the database. We removed instances of auth:NONE. If necessary, we replaced it with an MD5-PW password. In all instances where RIPE-NCC-NONE-MNT had been used we replaced this to RIPE-NCC-locked-MNT. And a special URL was sent to contacts to create a new maintainer. A few of the other changes that we've made have been that inetnum objects can be created using CIDR notation instead of having to use the whole address range. That makes things a bit quicker. Users can also specify a separate maintainer that has the authority to create route objects for address ranges within a larger block using prefix range lists for mnt-routes. Overlapping inetnum objects have been prevented - mostly cleaned up. If you would like to discuss further developments or information in the RIPE region there are some URLs here with contact email addresses. Those are also on the meeting site in the presentation and I think also on the handouts. So you can double-check those later if you need to. If anyone has a question I'd be happy to try to answer. XING LI: Thank you very much. That is the end of the presentation. I have an announcement. Today the meeting has been hosted by Telecom Fiji and Connect. Today's meeting is sponsored by JPNIC, the fellowship program by Softbank BB and we also have in-kind sponsors for wireless connection, Internet bandwidth, PCs for terminal room, by Telecom Fiji, Connect, Fintel and Xceed Pasifika. Lunch is provided from 12:30 to 2pm. The onsite notice board is available for any meeting information. Opening plenary and IPv6 are available in video archive, APNIC 18 meeting website/programme. There is a MyAPNIC demo all day at the Helpdesk area. Helpdesk is available - come and have a chat with APNIC host masters when you are free. Thank you for participating in this database meeting. We'll see you next year.