Database SIG, Thursday February 26, 9:00am - 10:30 pm XING LI: Good morning. This is the Database SIG. This session's chair is Dr Xing Li from concern yet. This will be from 9:00 to 10:30. Before the session, I’d like to announce two things. One is, on the schedule book, actually, the policy meeting is not this afternoon but at 11:00, after this session. And the second - there is onsite notice board so you can check the website and find related notices. In today's session, we have quite a few presentations today. And first, let me review the action items left last time. So those are the open action items. Action database 16-001 - "Proposed policy for mirroring on IRR to be sent to database mailing list for further discussion." Actually, frankly speaking, the mailing list is quite quiet. However, JPNIC is going to represent this proposal in today's session. Action database 16-002 - "Secretariat to implement proposal 'privacy of customer assignment records' in three months". An APNIC staff is going to present the report today. Action database-16-003 - "Secretariat to implement proposal 'protecting resource records in APNIC Whois Database'. This will involve changing the maintainer of objects protected by MAINT-NULL to the maintainer of the parent object as well as deprecating NONE in the maintainer's auth attribute." And also, there will be a report on this one. So this is the remaining action items left from APNIC 16. As I mentioned earlier, most of it will be covered by today's presentations. So let's ask the first report. The first is "Protecting historical records in APNIC Whois database" by Sanjaya from APNIC. Please. SANJAYA: Good morning. My name is Sanjaya from APNIC Secretariat. I’m here to present a proposal by the APNIC Secretariat to protect historical records in APNIC Whois Database. First, I will start with the definition. When we say 'historical record', what we mean is a record in APNIC Whois Database referring to address space not covered by a current agreement with APNIC. So usually it's an old allocation or assignment established before APNIC membership structure has been established. Now, the problem that we have at hand is the historical ASN and IPv4 address space has increasingly become a source of abusive activities in the Internet. You probably want to visit this URL here that tells how the abuser uses the historical records to do the activities. I will also explain further in the next slide how to do that. I will give you that. Based on the last count, we have about 3,190, that's 1.5% of the records we have in our database, that we would categorise as historical objects. When you look at our Whois database, then the standard assignment or allocation record that APNIC gives to the member would look like this. The mnt-by - the object would be maintained by APNIC-HM and then the member would have the mnt-lower, control of the mnt-lower, so the member can then further delegate and assign this block. So the master record itself, the large block that APNIC delegates to the member is protected by APNIC-HM. In the historical record, you will notice that the mnt-by is not by APNIC-HM. It is mnt-by the custodian maintainers. So these are the key differences between the current record and the historical record. The idea is actually to change this record to look like this. Let me show you how the abuser can use the historical record to perform... that's the abuser, that's the APNIC Whois Database. First thing he does is find some historical or some old records in the whois database that looks like it's not being maintained and then they will try to update that data with bogus company. They can do this because the old record is maintained by somebody who probably no longer exists, the email address is no longer valid. So, when they try to update the database, no notification is being sent to the custodian. So they can keep on trying updating until they succeeded. So now the whois database has a record that contains the abuser's bogus company. Once he's successful in getting the record, then they will request a route to an ISP who doesn't know anything about it and the ISP, upon receiving the request route, would look up in the whois database, find that record which has been changed by this guy so, of course, then they will think that the data is matched. Because the data has matched, then the ISP will open the route for the abuser, who will then attack the targets. After receiving complaints from the targets, the unsuspecting ISP might then revoke the route and then perhaps put that block into a blacklist. There are many blacklists that we know of, there are more than 30 blacklists from the last time I counted. And once it goes into the blacklist, the abuser can no longer use that block, so they just repeat the process again and again and again. So there will be less and less routable space in the historical record that can be used. This is one example of finding out whether an address is already in the blacklist or not. Just type in the address here in openrbl.org and then, if you do some research on this, you will notice that some of the historical records are actually already in a few blacklists. So to address this issue, the APNIC Secretariat would like to propose that all historical inetnum and autnum will be protected by APNIC-HM, so just like a normal allocation. When we protect this with APNIC-HM, it doesn't mean that the existing custodian cannot use the resource. They can still use it, but they will not be able to change the record by themselves because they need APNIC-HM's approval to do the change. Existing custodians who wants to maintain their records should sign a formal agreement with APNIC. Hopefully, by signing a formal agreement, then we put into that how to take care of the address space, the usage policy of the address space and so on. And because this will require some administrative effort, then we think that, once the custodian goes into a formal agreement with APNIC, then we could charge an annual fee of US$100 per maintainer. We have also checked with the other RIR regions. ARIN, for example, because of their new move to the new database system, historical records that have invalid e-mail will automatically be locked because then - because the e-mail is no longer valid and people cannot update the record, so it's happening there. LACNIC and RIPE currently have no similar project. Impact to the NIRs - at the moment, none. This proposal will affect historical records in APNIC Whois Database only. But we encourage the NIRs to discuss with their community and see how they are going to address this issue. So it's - you know, giving an NIR flexibility on how to implement the solution of this problem. So this is only affecting - this proposal is only affecting APNIC Whois Database. We think we will need about seven months for implementation. If this proposal gets approved, the policy development process requires two months for comment on the mailing list followed by EC approval. After that proposal has been approved by EC, then we probably need about four months to actually implement this policy. If approved, we will of course report the implementation activities in the next DB-SIG and in the mailing list as well. Is there any questions? DAVID CHEN: My name is David Chen from TWNIC. Firstly, I agree with your proposal. Could you make a list regarding NIRs object to invoke NIR? Do you know what I mean? We didn't know which object has been changed to the APNIC maintainers. We want to deal with our members to hand out those kind of objects. Maybe those objects - NIR didn't know. So would you please make a list for NIR and to know how many objects has been changed? Thank you. SANJAYA: Right, so just let me see if I can understand your question. There are objects in the APNIC Whois Database that might belong to an NIR's member. Right? Is that your...? And you want to know the list before we change something so make sure that you see if it does belong to your member, then you can contact your member. DAVID CHEN: Yeah. IZUMI OKUTANI: I think I have a similar concern to David's. Another point about ours is that we have some objects that's registered in both APNIC and JPNIC database where JPNIC is not being the maintainer but we had some kind of involvement in the past and we'll be happy to provide you with the list of those inetnums. So could you please inform us before you change the maintainer to APNIC so that we can inform - well, they won't be members, but inform the members in our database that these changes will happen. SANJAYA: Right. Yeah, what we can do with NIRs is - before actually performing the change, we'll send the list to you guys, probably sorted by country so you can each look at your territory and see if you can do something before we actually change it. IZUMI OKUTANI: I have one more question. I think some of the organisations would want to change the maintainer to JPNIC rather than APNIC. In that case, could I assume that this US $100 won't be charged. SANJAYA: No. If it's maintained by JPNIC, then it would be up to your policy how you charge this. IZUMI OKUTANI: Just - we're not going to be charged by APNIC either? SANJAYA: Good point. I think we should charge you. IZUMI OKUTANI: Really? SANJAYA: I don't think so. Anne? Anne doesn't like it. She wants to charge! TOSHIYUKI HOSAKA: Do you expect... when you make a formal agreement with resource holder, do you expect some effort by NIR to help some contractual work, I mean translation or something like that? SANJAYA: If they deal with us directly, if they only deal with us directly, then we - I don't think we will need NIR's assistance in that. But, like I said before, we would send the list first to NIR so you might want to proactively approach them before we actually send them. TOSHIYUKI HOSAKA: OK. Thank you. XING LI: Because this is a proposal, we need to reach consensus. I’d like you to speak out if you have any comments and suggestions. TOSHIYUKI HOSAKA: I'm sorry. One more question from Toshi - is this formal agreement different from your membership agreement with APNIC? SANJAYA: It will be different because this is not a membership. They can become a member if they want to but if they just want to sign for the $100 maintenance. TOSHIYUKI HOSAKA: OK. So there would be no membership fee? SANJAYA: No. This is just a maintainer's fee. XING LI: Actually, I have a question. Is that part of the non-member fee structure, this fee? Because, for example, some organisations do not need to be the members of APNIC but, if they can pay your one-time fee they can get service. So is that fee into that non-member structure of APNIC? SANJAYA: Yes, it is. In a way, it's part of the non-member fee structure but it's slightly different for the historical records. Just slightly different. XING LI: Thank you. Is there any other questions or comments? OK, if not, then let's do show hands. Who supports this proposal, then please raise your hand. Could APNIC staff please count. 15. OK, who is against this proposal? 0. OK. So we reach the consensus and we will introduce this proposal to the APNIC Member Meeting tomorrow. Thank you very much. APPLAUSE So the second proposal will be by JPNIC, a proposal for mirroring on IRR. JUNICHI MATSUMOTO: I'm Junichi Matsumoto. I’m a member of the JPNIC IRR planning team. Today, I propose an IRR mirroring policy, which we proposed at last APNIC policy meeting and we posted this proposal to the mailing list, but there's no discussion on that mailing list and so we propose at this meeting. The proposal is based on the IRR hierarchical topology. We reached consensus at the 13th AP Open Policy Meeting. Let me explain the characteristics. There are two characteristics in this model. One of these two characteristics is RIR and NIR IRR maintain their own database as the picture shows. The three RIRs exchange their own database information and send and each RIR receives NIR database and sends to RIR's shared database. We call this the public database for the database of RIRs/NIRs. This public database is open to the world. The other one we call private database for the database of ISP company or ISP's use. The way these are used is different from the public database. So we just leave private database out of the scope of this presentation. Anyway, the second characteristics is LIRs receive the shared PUBLIC database. In this model, LIRs can receive shared database from NIRs and RIRs. To realise this model, there are two issues to solve. The first one is comes up with an IRR tries to collect. An IRR needs negotiations with several IRRs to receive database. I'll explain the reason why. This is an example - when JPNIC tried to receive the RIPE database under this topology, we will ask APNIC to receive RIPE database to appear in APNIC RIR but then APNIC can't transfer. APNIC cannot transfer the RIPE database. APNIC cannot transfer. JPNIC have to ask RIPE to use their database. If JPNIC want to receive 10 other databases, then JPNIC have to contact and negotiate 10 IRRs. It's too many bilateral agreements. So this is a problem to realise this hierarchy. Next issue comes up when IRR distributes the database. As an example: if APNIC distributes JPNIC distribute APNIC a database to JPNIC, JPNIC will transfer its database to LIRs under this hierarchical structure and then what the problem is - if JPNIC transfer the JPNIC's database without any transferring limitation, in this case, LIR A might transfer the APNIC database to LIR B and LIR B might transfer to LIR C, so the database goes spread to unintentional IRRs and these unintentional IRRs might abuse this. So APNIC cannot allow their database protecting from abuse. So that's the second problem. Therefore, we propose these items. Define and deploy IRR mirroring policy. This policy shall and will include - RIRs and NIRs exchange and share their PUBLIC database. This means just RIR and NIR exchange and show their PUBLIC database without any other. Of course, this policy shows the detail of how to exchange the database, so we can make our common policy to exchange and share the database. The second one is - "RIRs and NIRs transfer shared PUBLIC database to downstream IRR by their decision." This is to solve this collecting issue. As I explained, IRR needs to contact and negotiate too many bilateral agreements, so to avoid this many agreement, we have each IRR and each RIR and NIR can have to transfer their database by their decision. And third one - "LIR's IRR received PUBLIC database from an upstream IRR but cannot transfer the database." This is for the distributing issue. We propose this to agree with RIRs and NIRs so each RIR and NIR should have a memo to protect - to LIR about these items. When this proposal reach consensus, we think this is the implementation process - firstly, defining the process. We need defining the detail of this common policy. We suggest a brief idea of this policy. We have to define the detail. And second thing, after we define the detail, proposing the common policy at APOPM. If this proposal reaches consensus, third step - deploying this policy among RIRs and NIRs. Thanks for your listening and please give me comments if you have. Thank you. XING LI: Thank you. So any comments? GEORGE MICHAELSON: George Michaelson from APNIC. I don't think that you have given a bad model. I think that you have a well-formed proposal that is self-consistent and that proposes a structured mechanism, structured behaviours that would work. But I think the fundamental problem is that the wider community, the RIPE community, the ARIN community, have a different view of the nature of interactions between address-holders, between ISPs, between participants in the routine framework. And I think, philosophically, they do not wish to have this kind of structured organisation. I know this is silly, counter-intuitive, because what you propose would mean less work, and it would mean better convergence of routing feasibility, which I think are very good goals. But the experience I have of going to other policy meetings is that the ISP communities in Europe and America don't wish to adopt this kind of behaviour. Which is very difficult. I would like to see a change but I think you are facing the problem of reaching wider convergence. If we adopt this behaviour within the Asia Pacific region, I think that's a good thing. I don't have a problem with providing support to you to facilitate this, with providing tools in APNIC routing behaviours, routing registry behaviours, to help you with this. I have no problem with doing this and I think this would be good activity, but I think, for wider convergence, I think you probably have a problem, because this would be now the third or fourth presentation that is an extension of the ideas of the JPIRR working group and the consistent message that we are getting informally from NANOG meetings or from other regional registry meetings is, essentially, we just don't think we need to do this. I am sorry, because I do realise you have put a lot of work into this proposal but I feel it's appropriate to say you don't yet have convergence in a wider community of routing-active people to adopt this behaviour. JUNICHI MATSUMOTO: Yes. I talked with some people who are working in IRR and share the opinions. The reason to propose this policy to have the global database is to make a fairer routing system. BGP is one of the databases but it depends on something. It's not - there's an obligation with routing registry and some routing registry and BGP. So we want to have a global database to use routing - I mean, to avoid the abusing something. I was operator of ISP and I was sometimes... the routing registry. Some ISPs use a routing registry for making the... and some ISPs really care about the registry database. However, is if they can't commission, there's no global database, so someone asked us about "Where can I register? Can I register with APNIC or JPNIC?" We have to say that, if you are announce your own address, I mean, register, you have to register all of them. So this is based on LIR's requirement. We really want this hierarchical topology for Internet users. So it's OK to mail this proposal to RIR's mailing list or some area, but I think LIR s want the global database. Yes. Of course, all of them, but some of them will require a standard routing registry database. RANDY BUSH: Randy Bush. I’m a little confused. Why does someone need to put their stuff in more than one of the existing IRRs? My routes, my definitions, are not in APNIC, JPNIC, etc, etc. I run a routing registry and my stuff's in there and people who build their configurations automatically fetch it from there. It's a - George, I think, characterised the tension and I think it's centralisation which has features and has its good features and a distributed system and distributed systems are a little more chaotic but the Internet has shown them to be a little more resilient. JUNICHI MATSUMOTO: Yeah, of course, one good RIR the case and if there's any activity to unify the IRR, we just throw these proposal away and I just agree to make one IRR to manage - not manage, to collect the global data. However, I don't know that there's such kind of activity, so we try to make a global database under the current conditions. I mean, less change. Probably that's why we proposed this. GEOFF HUSTON: This is Geoff Huston. I must admit I am slightly puzzled as to why you want a single global database for this kind of work. And certainly the environment in which we currently live has a multitude of such routing registries set up as either public community services or via particular providers for their purposes. Normally, when you are trying to use these routing registries in terms of trying to automatically update your filters, the only bits of the registries that you're interested in are those of your neighbours, not a global - it's a computation around your neighbourhood rather than a global computation and, given that, it's not clearly the maintenance of a global system. It's certainly been tried at some point in the past and I can remember this going back at least 10 years. The maintenance of such a global system does not appear to have gained sort of buy-in from the industry and from the participants. You can't do this top down. Providers have got to do it because they see value and benefit in doing it and the way they're doing it at the moment is indeed in these decentralised community-based models, where individual providers actually register their routes in ways most convenient for the registry, if they choose to do so. And, while I see that your proposed structure that would allow such a thing to be built using mirroring, what's missing for me is the drive, the motivation, to actually have it. JUNICHI MATSUMOTO: Yes. I - we think IRR's routing registry and routing database but, you know, some communities in the IRR community and local use. That's different. But I think IRR is collecting the routing database. If we collect the IRR database and decentralise, then the information will be useful for the other case. We're, I mean we are working to improve the liability of the IRR registry, to try to change - we are checking the practice of the... anyway, the data is correct or not, we are checking if the data in correct or not. So we are trying to make global registry and I understand it's with the views of the local and community views, so I think the IRRs or going to separate or have a structure where it will be changed. I mean, restructure. IRR's proposal for restructuring will happen but we think this kind of global registry is here. I guess you don't think - IRR is not for global routing recommendation distribution, do you think the global routing registry's users are useful? GEOFF HUSTON: You asked me do I think a global routing registry is useful and, as I said before, the use that most people make of the routing registry is to configure, autoconfigure various forms or prefixes on the routers. In that case, the global routing registry is not relevant for them. What is relevant is that they can collect the route registry information that pertain to their adjacent neighbours because you can only filter your edge. The only sort of global thing that I can do is a theoretic exercise about trying to understand consistency of the routing registry entrants that we already know that the aggregate sum of what's in the routing registries is not consistent, that the information is incomplete, relatively inaccurate and only maintained sporadically. And that knowledge has been around for a very long time and I don't think it's going to change. Because some folk don't use routing registries and use other mechanisms to maintain filters on their routers then not everyone buys into the concept of having a routing registry. Therefore, the information there is not consistent. So then you say, "Why have a global one when you're spending a lot of effort creating an information system that is not an accurate mirror of the routing system." JUNICHI MATSUMOTO: I think we know we have to discuss this kind of view but... We are working to - I mean to - we are working through the database then as I spoke. We are making an IRR application for liability. We are trying. I understand the countries, the global database from the IRR registry - it's not liability but we can improve the liability so it - and we are trying to raise the liability higher. So I think it's - it will be - but, you know, I don't think we have to propose this kind of policy after the initialising liability. Most activity relies on the liability routing registry... Q. Our proposal is we want to get an IRR object from only one IRR server or IRR database. If you want to do that, then we collect the whole IRR database to the one IRR server. This is the idea needs, then if we get some collusion for this problem, we will use the new solution. But we discuss about this, such as an IRR BOF or Japan Operators Group or some other community. But we cannot - we couldn't find them as a solution. So then, if we find, as a solution not this proposal, then we can use new solution better so we use this idea, this proposal is good solution in currently, please give me a new idea to solve this problem. OK, so only one comment. Randy or Geoff, I want to say that IRRs don't have incomplete database. IRR's database is not a complete object. So we looked at the object and APNIC would have not whole object. We know. But if you want to get whole IRR object. RANDY BUSH: It's not going to register whether you centralise or decentralise. The data problem is - the data quality problem is part of the distribution question. But my question is, you say this is the approach you see that solves the problem. I’m not sure what the problem is. KUNIAKI KONDO: Currently, there are meant RIR servers. So we can get the whole object from the over 40 IRR servers. IZUMI OKUTANI: Sorry, can I interrupt. I think everyone wants to know why it is a problem that we don't have a globally unique IRR server. You probably have to answer that question for everyone to see it - "OK, we need this system." RANDY BUSH: Where are you having problems get it. The tools automatically map the list to the Whois servers and you automatically build this stuff. OK, it does work today. So I’m having trouble understanding the problem and, in my heart, I think the Internet has succeeded because it's a distributed system and Geoff and I were just trying to remember before there were SWIPs and before there was an RADB, there was a single centralised system and it was horrible to use, not because of the user interface, but because one problem centrally and everything fell apart, not just - you couldn't reach one server and some things fell apart. That server had a problem, everybody died in the whole world. OK? It's the centralisation problem. And now, obviously, I would say, "Is it a problem that we don't have one global SMTP server? IZUMI OKUTANI: I can understand that this proposal would be effective if everyone thinks, "OK, yes, we need a globally unique IRR server" but before we go into the details of how to realise, you know, this - how to implement it, we need to, you need to explain to the others why you think we need a globally unique server for IRR system. I’m sorry - not server - a globally unique IRR system. I think most people here think that the current system doesn't have any major problems. So - RANDY BUSH: The problems are orthodic. The quality of data is the problem. IZUMI OKUTANI: It's more like the accuracy of the data is more of a problem rather than having the IRR servers distributed. Like RADB, RIPE, that's not the problem. So you probably have to explain why you want to, you know, - right, exactly, why you want to pull it together. Can I just explain in Japanese? XING LI: Because of the time, is there any other comments or suggestions? We are probably - let's try to reach some consensus even though they are still discussing. Maybe we'll try to reach consensus at the end of this session. OK, so the rest of the presentation will be informative presentations about maybe - maybe the Japanese community can have more discussion and later we're back to this item. I really want to have some consensus on this one because this is the third time proposed in SIG Database meeting. We should make some action. Otherwise, after the session, it's very quiet in the mailing list and no discussion on this and it's not good to keep this kind of discussion forever. JUNICHI MATSUMOTO: Just one question I want to hear the opinion on these things. Do you think this kind of global routing registry is useful or being needed or not? If everyone thinks this kind of database is useless, we can't talk this kind of stuff any more. So please can you raise your hand - I'll ask them about it - about whether a global routing database is useful. Can you raise your hands. Do you think this kind of routing registry is useless? Do you think the global routing database is needed? Or not needed? XING LI: OK, let me repeat the question. Do you think the centralised - KUNIAKI KONDO: I'm sorry. We don't need to mention the global routing IRR's database. So our proposal included distributed IRR system, you know, not to centralise. OK, so, we discuss about and we mean to discuss about and collect the Japanese community's opinions and speak to Geoff, write down the answer and post it to the mailing list. I think this has just start today more discussion, OK? Then, we don't beneath need consensus in this place and OK? XING LI: OK, what you say is you'd rather like to leave this as the mailing list discussion items. Is that right? KUNIAKI KONDO: OK. XING LI: What does the audience think about we put this into the mail list for further discussion? That's OK? Any comments against this idea? OK, so we don't need to discuss - make consensus later. So this will be put back to the mailing list for further discussion. OK. Very much. XING LI: So the next presentation will be by RIPE, RIPE database working group update. That presentation has been cancelled, so the next one will be by Sanjaya again - privacy of customer assignments report. SANJAYA: This will be a progress report of two projects that is in the open action items. So 16-002 and 16-003. But not for 16-003 has been completed so my report for 16-003 is we have completed the implementation. Except the last one where all the maintainer. We have notification but we are waiting before we change it, 60 days. That will end first week of April. So by first week of April, this implementation will be 100% completed. On the action item db-16-002, I have a short presentation here. This is the project update. Just to remind all of us about the proposal itself. The approved proposal is we agree, the APNIC community agree, we remove the requirement for public registration of assignments by members ISPs. Customer assignment is no longer required to be public. Assignment registration is still mandatory but doesn't have to be public, it could be hidden. We will provide hidden attribute for whois objects. Whenever APNIC system see hidden, it will not show it in the whois screening. But APNIC allocations or assignment, that is being given directly by APNIC, will be publicly visible. The implementation status is when we think about it, in the development team, we realised this probably better to change the hidden attribute to public. So ‘public: yes’, if you see an object with ‘public: yes’, that object will be shown in whois. If it has public ‘no’ or a missing attribute, the object will be hidden. We need more time to modify the software. So it's easier to modify this. So we need more time. We are designing a master registry database. Once that master registry database has been created, then all assignments will go into this master registry database and only those that has public equal 'yes' will be extract into Whois. Hopefully this will be completed by the third quarter of this year. That's all the update I have. XING LI: Thank you. Any comments or questions? No. OK. Thank you very much. The next presentation will be by George from APNIC. GEORGE MICHAELSON: Morning everyone. OK. Sorry. Good morning everybody. I would like to give you a presentation on the status of the early registration transfer project that we've been doing for the whole of the last year. What we've been doing is looking at transferring management of resources that were deployed into the Internet before there was a regional registry system. So these are the resources that people applying directly to NSI and other historical needs like the Internet. And their data management function was successively carried on by different agencies as we moved through the process, ultimately, ending up with ARIN having responsibility for matching these resources. But with the subsequent development of the regional registry process, this means that people have been left with two or more mechanisms for managing their resource, so they have different data accuracy, different requirements of proof of identity and it has made life much more complicated for people. The data that has been maintained in the public view has been of a variable quality. In short, it was quite easy to be given resource with very low level of compliance against your use. There's been no obligation to update this information. Many of the records in the transition between different registries, parts of the information were not carried over, so information such as the original data assignment has been lost. We've recently been analysing the volume of changeover records in the global framework, if you consider all of the historical resources. A very large amount of resources had no real update since around 1998. I guess in Internet years, that's geriatric. OK. We did a review of the data and the ASN numbers were easy to do and these were transferred in one go in August of 2002. APNIC received 115 ASN record in one go. We then started analysing the IPv4 records via /8. One /8 consisted of resources that it made no sense. It went directly to JPNIC who took over responsibility for this resource. They actually retain a relationship with ARIN directly because if we introduce APNIC into the equation, they will be telling us that they wish to change DNS. So although it may seem a little odd that we still have an NIR relationship directly with ARIN, it makes a lot of sense. There were other networks that were only the concern of one regional registry. I’m not actually sure at the moment if LACNIC received direct control of /8s. I think you did, didn't you. I think you received two or three /8s as part of this proposal and I know RIPE NCC have received some entire /8s. Some networks were going to be very difficult to deal with. 1 floospp/8s. We decided to try and leave the more difficult networks till later and we were going to see what the workload would be to do the transfers. The best decision was based on the workload. RIPE NCC were the main issue in terms of the amount of work because they've existed longer and have a far higher volume of historical resources that have been used in Europe. We decided the amount of work that was done by hostmaster staff was probably much more important than technical work. The technical work was about running scripts but the hostmaster work was about communicating with entities with organisations so they had a much higher workload to deal with. What we did was we implemented a mechanism for sharing DNS reverses because most of the ongoing activity in connection with resource management is about updating management to DNS. We designed a system that was based on fragments of the entire zone that was being managed and used the rsync protocol as a way of transferring these. This was a very lightweight process. Very easy to design. We do believe in the longer term that we'll be looking at things that use DNS on our update but felt it was appropriate to use this in the first cut of the technology. We're also using this scheme to manage shared zones with the NIRs in the APNIC region. We've found this has been much more complex and been in discussion with the NIRs and expect to implement a more structured process within our region for management of this resource. So we did some special transfers. The whole networks, the single agencies. We had some test runs. Then we adopted a schedule of two /8 transfers every two weeks to all of the RIRs. During member meetings or during national public holiday period, we wouldn't do any transfer work and we decided we'd leave the nasty bit that's the /24s until the end. This slide should give you an idea of the amount of work we've been doing. The vertical axis is the number of transferred resources and the horizontal one is time. We had a bit of a test run early in January and had a very big test run where we had a transfer. The gap between was because we had the APNIC meeting and the gap after was because RIPE NCC had a member meeting and we had a very solid window where we did transfers. The blue column is the number of /16s and the red column is the number of organisations. We had a very large number of /16s but for a small number of communication event. And for the rest of the year, we've been going through a process of doing about 50, maybe 70 a month, communicating with people. So, this slide is a bit messy but it gives you an idea of why we have to decide this was determined by RIPE NCC. The pale column is the number of records, organisations, that had to be dealt with by each agency. Pale column is RIPE NCC. For every single /8, they consistently have the highest number of communications to do. There were some networks where APNIC had a similar number but we've been tracking a much lower level of activity, but the RIPE NCC have to work hard here and it was fair to let that rate that we conceded. The swamp is quite different. There are only three networks. In 196 there's going to be a low number. In 198 it might get up to 40. In 192, the RIPE NCC are going to have to deal with over 3,000 discreet objects. We're quite lucky. We've only got 750. We're going to have to think about a different way of dealing with this resource. We're in the middle of transfer of four /8s now. These two were completed in the beginning of the meeting and these two will be completed at the end of IETF. In March we have two more networks and in April we have three. At that point, the easy part will be over in the vast bulk of the /8s by a number of /8s that have already been transferred. For the swamp, what we've decided to do is adopt a different methodology. We've tried to decouple the process. When we might be dealing with net 170, LACNIC and RIPE were dealing with it. In this process within net 192, we were dealing with numbers of the lower region and RIPE NCC might be dealing with numbers of the higher region. We want a system that gives them records that suits them to deal with that at the time. We've been thinking - if you have a /16, you get an email from ARIN saying, "Your network is going to be transferred and after we've accepted it you get another email that says we've taken over management of your resource." We think for these swamp regions, it may be easier to simply say after we've transferred the data, your data has been moved. So this is an alteration. The reason we feel comfortable with this is because of the observation here that many records are unchanged since before 1998. In the swamp, we found this particularly to be true. 80% of the data is completely unchanged over a 5-year window. We feel quite comfortable that the volume of people who are going to need to change DNS and suddenly find they're subject to procedural change without notification is really very low and although it is a risk - there will be some people who have issues - we feel it is better in procedural terms that we deal with transition of the data. This is still under consideration, but this is currently what we are planning. So, thank you, are there any questions about the activity? XING LI: Any comments or suggestions? IZUMI OKUTANI: Just like the earlier proposal about changing the maintenance, is it possible for resources under NIR management to let us know in advance so that we can let the users know. It sometimes causes confusion for the organisations. They receive this from RIRs and don't know what to do. GEORGE MICHAELSON: It would be easy for me to arrange a pre-list of resources by country code and communicate with NIRs to let them know. I think that would be easy. For the swamp, we are planning maybe a 2-month hold where there will be no apparent activity and in that window it would be easy to share that data with you. If you would like to come to us and say, ‘here is what we can do in a good process’, there will be less work for us, so I would be delighted to share this activity with you. But the thing that is a little hard here is that most of the resources today have been DNS management issues for a single /8. A company like the Komatsu tractor factory gets two. And that in some ways is very good when you took the entire /8. If you take management of that 16, you have to tell us about NS records that we then have to tell ARIN and it may be simply to manage that. I would be reluctant to transfer all of the resources that attach as JP, but in terms of telling you they're in transition and have you interact, I think that's fine. IZUMI OKUTANI: I totally understand your point, that point you made. GEORGE MICHAELSON: When people have /24s I think that would be great. In any case, if you can help with communication with sorting of the resource, no problem. GEOFF HUSTON: One of the issues is trying to find very old address blocks that recently appear. In ERX, the issue goes is that transaction overwriting the original data allocations of the date of the transfer or have you taken measures to ensure the original allocation made remains in both the delegated files and the whois files as the original allocation point? GEORGE MICHAELSON: We had a problem in the early process where we didn't appreciate the validity of the data, the dates in the data. We haven't documented retention of the earliest recorded data against the resource so there was a window for about three to four months when a large number of historical networks suddenly bumped up as being. We've reviewed the import data and where we have a clear creation date, we promote that to registry. If we don't have a creation date, where we have an update date, if we have multiples, we pick the oldest. If we only have one, we pick the one they gave. If there is no date object, any kind associated with the record, we have a problem. We've discussed informally internally what to do. I like the idea of putting them down as April 1, 1969, but it's quite difficult to know what the right thing to do is when you have no date but we've tried really, really hard to preserve the earliest recorded creation flag in registry. The way we import the records in whois, we actually embed the whole of the original object into the remarks field. So until the point that the resource - that delegated body takes over active control where they can change that record, until they actively take it, the historical record is preserved as a comment against the current resource record. I know that's about data processing that would be difficult on whois, but in registry we do attempt to preserve it. If you've seen significances variances there, I would love to know. GEOFF HUSTON: 2003 was an active year for allocations. RIPE ERXs have rewritten originated date and RIPE has allocated some 4, 500 entries last year when is a false number. I was wondering what APNIC had done? GEORGE MICHAELSON: We have decided to push back on to the original historical date. If you see an issue with another registry I'll take it up with them. XING LI: Thank you, George. Is there any other presentation? OK. So, I believe this is the end of this session. Thank you very much for participating in Database SIG. The Policy SIG doesn't start at 2 o'clock, but at 11 o'clock this morning, the information in the document is incorrect. So please come back at 11 o'clock. Thank you very much.