______________________________________________________________________ TRANSCRIPT Database SIG Thursday 24 February 2005 2.00pm ______________________________________________________________________ XING LI I am Professor Xing Li. I'm the current chair of the Database SIG. Today, we're going to have a one and a half hours of presentations and discussions. Actually, today we have only one policy presentation. Others are informative. First, let me give you a review of the open items we left from previous APNIC meeting. So those open action items. The first one is db-18-001 - "Proposal for establishment of an IPv6 IRR to be referred to the mailing list for detailed discussion of the framework and implementation" and the status is open. And the status update will be by Sanjaya later in today's session. The next one - OK, this is quite an old one - db-17-002 - "Proposal for Internet Regional Registry mirroring policy to be returned to the database mailing list for further discussion." And the status is open. However, there is no activities in the mailing list. By the way, I would really like to see activity in the mailing list. And because there is no corresponding proposal for this in this APNIC SIG meeting, so I don't know. SPEAKER FROM THE FLOOR On behalf of the presenter, currently we didn't have enough activity, as you know, there is no discussion on the mailing list. So but this year we are planning to change our service to the JP IR service in the JP region. So, in this changing, we may have some activity around this proposal so, anyway, so by the next APNIC meeting, we will decide whether to progress this proposal or not. So, yeah, this is the current status. XING LI OK, thank you. Any comments or suggestions? Because, I remember that we discussed in the previous meeting that, if there was no activities, probably we would close this action item in this meeting but, based on what you mentioned, probably we can see further updates in the next one. So any comments? Who are interested on this one? People prefer to make this - I mean, open and we will have presentations in the next APNIC meeting. Do you prefer this? Please show hands if you prefer to keep this action item open. I prefer. OK, thank you. And who is against? That means, who really wants close this action item in this SIG meeting. Please show hands. So nobody really against. So, OK, let's keep this open and we are waiting for the proposal in next APNIC Database SIG meeting. And I would like to suggest if, in the next one, no further whatever - new updates - then we will close that. Please keep notes. OK, thank you. And 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." And the status is done and implemented on 14 December last year. And, if you are in the mailing list, you can also see the announcement, the mailing list, you receive list already. So any comments or suggestions? OK. And next one - db-16-002 - "Secretariat to implement proposal 'privacy of customer assignment records' in three months" and the status is done and implemented on 5 October last year. So that's basically the remaining action item and from this presentation we will have one open and waiting for APNIC to have further presentation and make decisions. Thank you very much. And the next presentation will be a policy proposal by JPNIC. Toshiyuki Hosaka, thank you very much. TOSHIYUKI HOSAKA Good afternoon, everyone. I am Toshiyuki Hosaka from JPNIC. Today I will make a presentation about my proposal for APNIC to publish assignment statistics. Introduction Some of you may be aware that APNIC and all RIRs publish IP and AS numbers allocation report on each RIR's website. This gives statistics on the IPv4 and the IPv6 and AS number allocation from RIR to NIR or LIR or end user. And this statistics is updated daily. And on the common format - with a common format among RIRs. The format is shown at this URL (refers to slide). So this is the format for the IP and AS numbers allocation. You can see here as APNIC - this is the name of RIR - and the country code and the name of the resource and so on. This is the time when the resource was allocated or assigned. So current problem We have allocation data, as you saw, but we have no data published regarding assignments currently made by APNIC. This is very important study IP address consumption, for example, how much assignments are actually made out of those allocations. And we cannot use - actually, we can use APNIC Whois Database to collect those assignment information but we should not use, I think, APNIC Whois Database for this purpose because whois database - sorry, whois query shows unnecessary information for this purpose. I am not saying such as the name of the organisations, contact, telephone numbers or something like that - I'm not saying this information is not necessary, but those information are certainly necessary to find a contact of the network-holder or AS number holder but, for this purpose, we don't need such information to collect the assignment statistics. And one more point is that most of assignments are hidden from public database, from APNIC database because, privacy of customer assignment records policy had been implemented by APNIC last year. So what about other RIRs? The situation is exactly the same as APNIC. Each RIR publishes allocation data and is open to public. But no RIRs publishes assignment data. So the proposal is APNIC to collect and publish IP address assignment statistics, including at least the following information Country code. Type of IP address - that is IPv4 or IPv6. Prefix size of the assignment. And the number of assignments registered under the specified prefix. This will be shown, for example, in the next slide. And the data which should be collected is all assignment data registered as 'assigned non-portable' and 'assigned portable'. This means that we don't need sub-allocation data registered as 'allocated non-portable'. Because we should avoid double counts of assignments registered under such allocations as a sub-allocation. So this is the example of format (refers to slide). Example of data we need. This is country code, address type - IPv4 or IPv6 - this is the prefix, /24, /25, /26, and this is the number of assignment for each specified prefix. In this example, we can see in Japan there is over 2,678 assignments of /24. But this is just an example. So data format and the frequency of the report are left to the implementation to allow flexibility for APNIC. So what we can get from this proposal? Such information is very useful for future address policy discussion. This enables - this information enables speculation of the volumes of address stocks within LIR s and the scale of deployment among end users by comparing the volume of allocations and assignments. And especially in terms of IPv6, we need such information - how much assignments are made from - made out of, say, a /32 allocation, because IPv6 is still under diffusion period. And to implement this policy, we have no conflict with privacy of customer assignment records because we don't touch any information, the content information assigned to the organisation which is assigned IP address. We don't need any telephone number. We don't need any name of the organisation, something like that. We are aware that some assignments are stored in NIR database and some data are not visible from APNIC. So implementation, NIR implementation is at discretion of NIRs. But - this is just for your information - but JPNIC already publishes assignment statistics like this (refers to slide). The register is in Japanese but I assume you can understand out of this, like, this one, /24 - in the year of 2004 in February, JPNIC made - no, no, no, sorry - JPNIC had 24 /24 assignments registered in our database. So, to summarise my proposal - APNIC to publish assignment statistics, including country code, type of IP address, prefix size of the assignment and the number of assignments registered under the specified prefix. And this statistics, I think, is useful for the whole address community for future policy discussion, including both IPv4 and IPv6, I believe. Thank you, this is my presentation. XING LI OK, thank you. Any questions? RANDY BUSH Randy Bush, IIJ. Something on the side, which is from a research perspective, is it's often useful to be able to take an IP address and want to know what country it's in. And this has privacy issues and other issues but, for example, those people who heard my talk yesterday on DNS anycast, it would be nice to have known where all those addresses were geographically to understand biases in research. I don't know if this is the right place to think about that. As I said, I understand there are privacy issues. TOSHIYUKI HOSAKA Actually, I have not talked with APNIC about this visibility, so I would like to have APNIC comments for this. I assume he's going to (refers to Sanjaya, who is at microphone). SANJAYA Yes, thank you. Sanjaya from APNIC Secretariat. We have evaluated this proposal in APNIC to see whether we can deliver if it gets approved and we have come to the conclusion that we can make these statistics. But with some disclaimers in that we don't hold all the data in the Asia Pacific region, just like Toshi said. Some are stored in the NIRs, so we are going to say that this is not the complete list and, to have a complete list, please get it from the other resources as well. Basically, that's what we will do if this proposal gets approved. TOSHIYUKI HOSAKA Thanks for your comment. Yes, we are aware that APNIC does not have all the assignments in the region. So hopefully we can - in the NIR community, including APNIC, should keep a discussion about - to collect the data among the AP region. But, at this stage, APNIC data is inactive. TIM CHRISTENSEN Tim Christensen from ARIN. Is your intention to replace existing allocation information with this format? TOSHIYUKI HOSAKA No. TIM CHRISTENSEN Could I ask you to put the format back on the screen, please? I'd just like to see it. TOSHIYUKI HOSAKA This is the current format? TIM CHRISTENSEN No, your suggested format, I'm sorry. Thank you. I just wanted to be able to read that for a minute. Thank you very much. GEORGE MICHAELSON George Michaelson from APNIC. We believe that the current stats format has extension possibilities which would allow us to encompass this information perhaps in a different way but compatibly with that current format. The current format says that extra fields on the ends of lines are to be ignored, so existing applications understand to ignore and we are considering proposals for an extension of this format that is compatible but would include this kind of information. TOSHIYUKI HOSAKA Already, but at the moment it's up to you, I think. GEORGE MICHAELSON Yes, I think your principle of needing a tool to do this for research is sound. The format is under consideration. TOSHIYUKI HOSAKA Thank you. XING LI Is there any other comments? No comments? You don't care? OK. So let me ask you, could you please repeat what's exactly you propose - I mean, the time frame and the involved parties and those kinds of things. So we can make a decision in the consensus process. Otherwise, it's too much information here. TOSHIYUKI HOSAKA Alright. My proposal is APNIC is to public assignment statistics, including country code, the type of IP address, prefix size of the assignment and the number of the assignments registered under the specified prefix. In some format, whatever, decided by APNIC, with some flexibility. XING LI So you want APNIC to decide format. Otherwise, probably that will be like a whois database. ARIN, RIPE and APNIC and others have a different format. In the future, probably, the unified format will be a part of that. Also, if it's too flexible, if NIR and RIR will have a different format, that will create trouble. I don't know. As Sanjaya proposed, maybe, George, the current statistics format with some extended work would satisfy this proposal. I don't know. GEORGE MICHAELSON Yes, I think it would satisfy this proposal but it's subject to negotiations amongst the registries to converge on it exactly. XING LI And you want it proposed to publish these statistics every day, right? That's your proposal, right? TOSHIYUKI HOSAKA No, frequency is left to APNIC as well. But my original idea is at least once a month. XING LI So any trouble for APNIC? Once a week? SANJAYA We are already doing the allocation status daily so, in theory, we can do it daily as well. XING LI Are there potential privacy issues from the comments of the APNIC member? Is there any potential privacy issues? Please do think the proposal when a decision is made that's some of the realities we have to face. AHMED ALKAZIMY Ahmed Alkazimy from APJII. Just informational - we are doing the same as JPNIC. We're doing the statistic without pointing the IP address. We're just doing the statistics on our website every four months. OK, thank you. XING LI Thank you. So other comments? OK, that's to show hands. Who supports this proposal, please raise your hands. (Pause) OK, thank you. Now, who is against this proposal, please show your hands. (Pause) No-one? OK, I believe we reach a consensus and we will report this to the APNIC member meeting. Thank you very much. APPLAUSE XING LI OK, so, the next ones are the informative proposals. OK, three by Sanjaya and the other is by George. The first is "privacy of customer assignment records - project update". SANJAYA Thank you. This is a report on the completion of the project, so the privacy of customer assignments proposal has been - has received a consensus in APNIC 17 I think. And we have implemented it successfully last year. I'm going to go over this agenda so basically give a background to keep our mind fresh on why we are doing this, what solution we are implementing and what is the feedback of the implementation of this proposal. The motivation for this proposal is actually privacy issues. There's a long-term concern that customer information - publication of customer information can be abused and there's also increasing government concern for privacy. So APNIC is at a legal risk if we don't anticipate this, we might end up in an unproductive legal battle. So we want to avoid this early. And we also know that the customer data is poorly maintained anyway, the whois database. So, if a customer has cancelled with the ISP, it may not get updated and so on. We made an analysis of what is it that the public really needs to see. We believe that the general public must still be able to see all the records on this area. So the IANA range, the APNIC and non-APNIC range, allocations and assignments that is delegated directly from APNIC, the NIR range and also allocations and assignments that is delegated by the NIR. So these must be publicly visible. And we have made a conclusion that everything under this line - customer assignments, infrastructure, sub-allocations - may or may not be visible. It's really up to the parent holder of the assignment that they want to show the chart objects. So this is the design that we have come up with (refers to slide). We split the database into two database areas - public database, which is the whois database, and a private database that is not visible. And the public database lists all these records and the private database lists all these optionally visible records. From APNIC's point of view, the system to manage these two data is using our allocation manager application. This is internal to APNIC. And from the members' point of view, the way to manage these two database is through MyAPNIC. The other tools that we consider is not as highly secure as MyAPNIC can only just date the public database. This was our implementation schedule last year (refers to slide). I'm happy to report that we are very much on time on this. And we completed the data migration in the first week of October. To be exact, it's the 5th of October that we completed the whole migration. What we are doing in doing the migration is actually copy the data that is not to be visible into the private database and then remove them from the public Whois database. So this is the point where everything that needs to be deleted from the whois is already copied, everything has already been copied to the private database and nothing is left in the whois database. The - during this data migration, we implement all the tools that is needed to manage this database. The end result looks like this (refers to slide). It is clearly seen here that the private database is actually bigger than the publicly visible database. So now we are holding more data in the private database than the public. But you can see that there's a lot of the grey block here - actually, this is still the customer assignment. Some ISPs have chosen to keep their customer data public for one or other reasons, which is good. So, you know, it's really up to them. We are giving them flexibility for our members, whether they want to publish or not publish their customer database. This indicates that some members do want to keep it published. The new tools we are coming up with to manage this public and private data - we made new features in MyAPNIC to allow management of the private record. It's running now. It's being used by the members. If you have any feedback on that, I'd be happy to hear it. And we are under - we are developing a scripted interface. This is more of an automation that allows particular last members who doesn't want to go into the graphical user interface of MyAPNIC, just use their script to pump the data to the private database. It's being developed and should be made available to the members soon. The feedback we received During the first week after we migrate the data, we had not many queries and complaints. We received about 10 questions, mostly to request - we had moved their private objects and they didn't want to and so they requested we move it to the public database and then they will move it back to private whenever they feel comfortable with it. There are some issues with historical resource holders, mainly in the New Zealand area. I think it's mainly those who are not contactable. Sometimes with historical resource holders, sometimes we can't really send information to them because we don't really know who they are. It's not in our records whatsoever. We did have some problems with that but as soon as it's found, we fixed it and then everything is working fine. And this is the feedback from some parties, which has been addressed by JPNIC's presentation just now. And that is the loss of statistical information from the Whois database because most of the customers' assignment data is gone, then people can no longer track the usage rate of the information. So I'm glad that we have reached consensus on JPNIC's proposal because that addresses the concern that we received after migrating the data. That's all on the customer privacy presentation. RANDY BUSH Randy Bush, IIJ. In the other regions and in the DNS automatic provisioning protocols and so on and so forth, the granularity, which is more private or not, is the field, not the whole record - in other words, I don't mind when I'm a broadband customer or whatever, that my record for my address space is there and public. I just don't want my phone number and e-mail there, maybe. The whole provisioning systems for all these now - at least their architecture and specification allows control at the field level not of the whole record. And I Think we at APNIC need to put some thought in that direction in the long term. This is a pretty big chunk to move to private, the whole record. SANJAYA Thanks, Randy. We certainly will - we are certainly willing to think along that lines. Would you mind making a proposal maybe? If that is an effort that we should be doing in the APNIC Secretariat or do you think this is not something that we need to discuss with the members? RANDY BUSH Well protocols like CRISP and what is it, EPP or whatever - SANJAYA CRISP, yeah. RANDY BUSH I think you want those things to settle down. I'm trying not to make a mess, to make proposals that create a lot of work before things are settled. I'm just saying I think that's the direction things are actually going - not moving entire records to private. SANJAYA OK. So basically your message is we should keep that in mind and, you know, as the tools becomes available, we follow that. XING LI Other questions, suggestions, comments? OK, thank you. SANJAYA This next presentation is protecting historical records in the APNIC Whois database. This proposal was approved in the last APNIC meeting. I will go through the background, why we're doing this, how we implemented this and whatever feedback we received from the membership afterwards. The motivation is the historical ASN and IPv4 address range is becoming a source of abusive activities in the Internet. It's being tracked in this URL you can look at that. Based on our assessment on how it will impact our database we noticed that about 1.5% of our total IPv4 address records contains "falls" into the historical object category. So the decision was from APNIC 17 that we should not allow unidentified person updates with historical records so we have agreed to do - what was proposed is we will protect it with APNIC hostmaster maintainer. This doesn't mean that the existing customer cannot use the resource. They can use it as usual. Nothing impacts on their operation, it's just that they cannot change the record. They need to contact us and we will change the record. If they do want to maintain the record then there is some identification process they need to go through and have an agreement . The proposed annual fee is $100. When implementing the policy we noticed that $100 per maintainer doesn't make sense any more because APNIC's way of interacting with the customer is through the account relationship so we changed US$100 to $100 per account regardless of how many records that account had. This was the schedule. We wanted to implement this, to lock the record on the first week of December but due to some technical problem we had to move it back to middle of December. In the end we actually locked the IPv4 record date of the 14th December and the historical ASN records on the 21st of December, 2004. There are 5,633 locked records now and 243 locked autnum records. The reaction we got - we got complaints from some members saying that the notification period was too short. We sent the notification to people before we locked to give them time to identify themselves to APNIC and then start doing the process. They said, Some of us might have had vacation, so in the end we have to make some adjustment as long as that is within reason then we are willing to negotiate the time. Also, there's some feedback that for just $100 annual fee, our process is too cumbersome so we were thinking about streamlining the account opening process. There's also an impact of this to the lame delegation project. We check at our reverse delegation database and look, if some of them are found lame then we contact the responsible party, asking them to fix it. But historical protection protects it so they can't make a change so we had to make some adjustment there. Those who are contacted by the lame delegation project due to having a lame delegation will get a one-time allowance to change the data without opening an account so as long as they stick with it, change it once, that's fine. We are not going to charge them but if they keep on changing again in the future then they probably should consider opening a surplus account fee with us. That's my report. XING LI Any questions? OK. SANJAYA Thank you. Last one! This is an ongoing report. This project has not been completed. It's there on the table. This is a status report on the project. This project is implementation of the proposal for APNIC to provide IPv6 IRR registry service. Standard agenda. The proposal was delivered by Katsuyasu Toyama in APNIC 18 and the proposal is for APNIC to define a framework of IPv6 IRR and make consensus among all the RIRs, then launch IPv6 IRR service, then promote the IPv6 IRR. In APNIC 18 DB SIG a consensus was reached that this proposal is accepted and to be executed by the APNIC secretariat. The APNIC EC endorsement on 19 November, 2004. Our implementation strategy for this is APNIC already has an IRR, so we are not going to make a new service but we will extend our present IRR service to include IPv6. The specification that we are going to support is those proposed by the RPSLng Internet draft, proposed by these people (Indicates) The reason we're using this is to address the first item here, that says we need to make consensus among all the RIRs and we think, alright, the only standard that's out on the table at this moment for the IPv6 routing registry is as defined by the - and since APNIC is already using RIPE Whois database to deliver our IRR service and the RIPE Whois database now supports RPSLng we think, OK, let's just install the latest RIPE Whois database, we deliver our IRR service. The new database, the latest have these features to support the IPv6 IRR. There's a new class of routes6. They have attributes like this. I'm not going to go into detail on this one. There are some attributes classes as well, so autnum class, route-set has one, filter-set has one, peering-set has one attributes and so on. Most of them basically specify multiprotocol allowing both IPv6 and IPv6 to be specified - IPv4 and IPv6 to be specified in the value. Proposed schedule. We are here now. We have made project planning before coming to this meeting. Specification and business rules will be defined in the first two weeks of March, customisation and development is going on right now. Then we will migrate our master server around. So we're expecting that by end of April we should be able to deliver IRR for IPv6. If you want to know more about the RPSLng IETF Internet draft there is the URL. It is in rfc editor queue. I don't know if there's any update on this? Is Andre here? Andre, do you have any update on this? Has it gone forward from the RFC editor? ANDRE ROBACHEVSKY I think the authors just sent their final approval to RFC Editor so it should soon be published as an RFC. SANJAYA If you want to know more about the RIPE database support for the RPSLng, you can find it in that URL. Feel free, if you have any questions, but we can think of this one FAQ that we might get when we implement this system is - will the implementation this have new system affect existing IRR objects in this APNIC database? The answer is no. It will not break anything, especially those who are already using APNIC IRR for IPv4, it will not break the objects at all. It's just an extension. It allows you to put IPv6-related values into the registry. Don't worry about it! XING LI Any questions? comments? Suggestions? SPEAKER FROM THE FLOOR One comment, services for IPv6 IRR, so that I think the next stage we encourage the people to register the route to this registry and keep updating these databases, and at the time we can use the database as a reference for announcements. So the next stage we would like to encourage people to register, update their databases. Thank you. SANJAYA Thank you. Yeah, it is in one of your - the last one in your proposal to promote this one, yeah. Yes, I think we will help you, I hope you will help us with it as well. We all will promote people to use this new IPv6 IRR after April when we install the system. Thank you. XING LI Thank you very much. APPLAUSE The next presentation will be by George. GEORGE MICHAELSON Hello, everyone. This is a report on the current status of activities covering RPSLng and CRISP. I'm appearing partly in my normal role as the technical group manager at APNIC, also one of the co-chairs of the CRISP working group in IETF to talk a little bit about RPSLng, as Sanjaya's noticed, the draft is at version 8. It's very likely to go to submission and progress through. It is also good to see that we now have support for multicast and IPv6 registry framework. One of the authors of the draft had an implementation running in October of 2004 and the RIPE NCC support was really quite soon after that in December. We are going to be doing our deployment as Sanjaya has indicated as part of our activity in the - CRISP. So, CRISP is the cross registry information service protocol. It's about finding the authoritative information about what is called labels in its charter. Labels is more neutral term that covers things like names and addresses. It's been designed to be extensible, using XML as a mechanism that allows you to specify different versions of its schema and so add new information elements and new structures quite easily. It is important to note it's not backwards compatible with older systems who are - for finding these resources and it's not about provisioning. It's an information discovery service, not an information management service. The current working group status is that we have four official milestones listed on our charter. We had a January deliverable to issue a revised specification. We had another January deliverable. We had a March deliverable for the first draft IP address registry spec. The June deliverable has been held over, there's been more discussion so we're a little bit behind on that activity but we are expecting progress. May is the end point, the logical end point that means the submission dead line for the June, July window of IETF. However, we have RFCs. We've made some targets. We now have four RFCs, the requirements 3707, then the IRIS core protocol, that is the XML character that supports the query types on this and the authentication model. Work in progress, we have the a-reg activity a provision 9. We have in modification to this document there's a problem in the address space that you need to find where to go to get the right answer about addresses. In name space it's usually quite obvious from the name you're looking at when you should query to find information about that name. But in the number space because of things like the early registration project the responsibilities are highly distributed so we've separated out the determination of where to ask for further information as this document a-reg URI res which is in the 00 draft state. There was an observation that the protocol TCP protocol and B protocol was quite expensive. You have to authenticate, connect, maintain a network binding. So we've got a light weight protocol called D-check which is purely for the name space because the registrars there are - it's sort of like a denial of service attack. People who want to register names would send thousands of queries to them one after the other - is it there yet? Is it there yet? Can I have that name? They just hammer on and on waiting to see if name is free so they can be the first one to get the name then sell it to someone else. So there's a lightweight protocol that we give them back " No" answer quickly so they can avoid the overhead of connecting. There's also the lwz protocol, an attempt to say " We don't need this full beep layering, don't need full protocol layering". Let's just make direct. This might make it easier for people to implement faster service delivery. I think these might both be applicable to us. In number space management we often get queries about addresses that have been used for hacking. If people have a zone alarm gateway it might come to us repetitively with the same address asking us about information. It may be that the d-check protocol has good ideas that we should think about implementing too. The other thing that's quite exciting is this new body of work which I'm calling r-reg, this is a submission from Nagahashi-san, Yoshida-san and Kondo-san. They have been working a large number of years in the area of routing registries. It's complement area to the address and domain name registry function. It basically would implement the kinds of behaviour you get in RPSLng. There might be some issues about protocol and about the design that we still need to discuss, but this is the goal we're trying to achieve. If this became a formal work item in CRISP that means that CRISP would cover all the Internet registry functions. ICANN have had an interest for some time that there would be convergence of this activity, John Klenzin (?) has a consulting role in ICANN to see if we look at all registry functions and try to make them consistent. This would meet ICANN's concerns. They're quite interested that this work item will be adopted. It's going to be discussed in the IETF meeting in Paris. My hope as the co-chair is we will adopt this work item formally and progress it through. We have a BOF, a CRISP BOF at this APNIC meeting. It's an opportunity for people to talk about this activity as well. Future directions. Well, CRISP is query only but we currently use whois for data management as well. So if we look into the future when we're offering CRISP as an information service we have to think about whether we can do something to improve the data management function and one idea is that we could look at this protocol called EPP which is also XML encoded data objects and many LIRs currently have to use this protocol for their interactions in domain name registries. Some of the information types and operations in EPP are not appropriate for numbers, but it's also an extensible protocol. We might have the ability to do some work here, there are open implementations available, ISC have a facility called open reg, it might be a vehicle that could give a lot more memory access to do data management. We also have the activity that Sanjaya has been working on to do bulk management tools in MyAPNIC. These might well be complementary to a read only CRISP service. We don't think CRISP is going to be available stand alone in this year. We have to think about planning for a convergence activity of who is running - Whois and CRISP probably running through to 2006. This means we'll have a dual service for quite some time. Whois is part of a charter activity. One of the defined functions of the registries that they provide this information service to let people know who has the number of resources. CRISP is functionally similar to Whois is it's possible we might wish to make sure CRISP would meet our charter obligations in this area. We also have to think about clients. The information is inherently being presented in quite structured format. It won't be as simple as whois to just read the data that comes back from the server. On the other hand, the data will be totalised, it will be easier to manipulate this data and use it in different ways. So we're quite interested to see clients deployed to all platforms, libraries, access methodologies, it would be nice to make sure these are consistent across all registry types. We have to think about the convention of processes, that people do at the moment for access to whois, we're going to need to give them assistance to move these over to CRISP. My personal belief, I'm speaking in working group chair but also as a member of this SIG, I think the database SIG would be very important to discuss these activities and to get a sense of future direction. I suggest we should try to put a road map together to give everyone in our community a sense of direction and present this at the next APNIC meeting. That's it. XING LI Any comments, suggestions? TOMOYA YOSHIDA One of the authors of this draft of the registry for CRISP. We are thinking about the future of the IR function of CRISP. The IR system is based on the mirroring, so we have to set many mirror paths to many IR server. So this is very difficult to get the information because the database is spread all over the world. So now we are thinking this function of the r-reg, working registry for CRISP so it is very useful to get information and cross-registries just our idea to be implemented to the function of the CRISP and routing registry for CRISP. So if you know the detail, please see the draft and let's discuss this draft. XING LI Any other comments, suggestions? I have a question - how many people from Asia Pacific participate in an IETF working group? Some idea? GEORGE MICHAELSON Our normal attendance at the working group is around 50 people and I don't have a good sense of how many are from our region but I think we are represented. I couldn't be more specific, I'm sorry. I don't have the details for that. XING LI OK, thank you. So I believe this is all the items in the agenda. Any comments for this session? So we've finished about 17 minutes earlier. Thank you very much for participating in the APNIC SIG and welcome to be continued in the next SIG meeting. Thank you very much. APPLAUSE