Database SIG, Thursday 21 Aug, 11:20-12:30 pm XING LI: Good morning. I believe this is the time to start. OK. Sorry for making your tea break shorter. I’m the chair. My name is Xing Li. I’ll give you a brief introduction of the draft charter. The open action items were left last time. But we tried to make the presentation short, so we will not miss lunch. OK, the database SIG is to examine developments in the operation of APNIC Whois Database and to discuss related issues affecting registration practices, database security, specification of objects and the database features. Any comments or items we should add into this charter? Any comments? Suggestions? So, is this consensus agreed? OK, good. Thank you. From the last Database SIG, there are several remaining action items. First action items, action, db-14-002, secretariat to create sample hierarchically inetnum objects with associated maintainer objects in the APNIC Whois Database. So what’s the progress? SANJAYA: This action item has been recorded in my later presentation. XING LI: Thank you. The second action item is db-15-001: further discussion on requirements to host a local Whois to be put to the SIG-db mailing list. To my observation, there is no discussion on this item. The database mailing list is very quiet. Any suggestions or whatever? If no comments, then that’s probably the end of this item. Action db-15-003. Secretariat to clean up the database, deleting unreferenced objects and modifying RPSL noncompliant objects. A. This action item has been repeated. XING LI: The next presentation of APNIC 16 database. The first presentation from JPNIC. JUNICHI MATSUMOTO: I’m Junichi Matsumoto from Japan Telecom. I’m a member of JPNIC IRR planning team. Today I propose a policy of mirroring on IRR, where every IRR will be brought through. JPNIC’s goal, one of our goals to improve IRR’s utility is to realise a hierarchically mirroring topology. NIRs receive all database from one RIR. IRR A receives APNIC. However, a problem of this topology is - an IRR’s database spreads unlimitedly under this topology. For example, IRR A’s database is transferred to each IRR when mirroring. So how does IRR A prevent LIRs propagating A’s database if A wants? There’s no way to prevent. Therefore, we make a new rule to limit spreading of IRR database. RIR/NIR’s IRR limit LIRs to transfer their databases. IRR A limits receivers of A’s database by LIRs of each region. RIRs have this new rule. An RIR make an LIR agree with this rule. IRRs are limited to receive A’s database. So IRR A is happy with this. It is not effective unless all RIRs-NIRs. Therefore we propose this policy to reach a consensus. The proposal is, a registry managing database should have distributing policy and the registry makes other IRRs obey the policy when mirroring. In the case of this picture, IRR A is JPNIC, B is APNIC and C is NIR. IRR a has... and also C must obey distributing policy when seen with B. I explain what this distributing policy is. The right of distributing IRR’s database is limited by RIR/NIR. RIR/NIR requires LIR to obey this policy when mirroring. This policy is applied if and only if the source of database’s IRR wishes. Some IRRs do not care the limitation of spreading database. I explain the process of mirroring. An example case. In this case, IRR A APNIC, BJP number and CIRR. When this process happens, IRR A applies distributing policy to A’s database and IRR B obeys A’s distributing policy. C asks IRR B to mirror and transfer A’s database. Then B informs C that IRR A applies distributing policy. So C to obey … distributing policy. And B might require C to submit the agreement. B allows C to get A’s database by the new mirror. This is a process we use in the distributing policy. JPNIC applies distributing policy. JPNIC requires JP region’s LIRs to submit a letter to obey this policy when mirroring with JPNIC. For details go to our website (shown on screen). This proposal will be implemented until second quarter 2004 if we reach a consensus. This proposal implemented by all RIRs/NIRs. This time I propose this. Do we need to travel to other regions’ policy meetings to recognise this? If you have any opinion or questions, please speak? GEORGE MICHAELSON: Thank you for a very clear description of what you are proposing. I think you’ve given a very easy to understand description of the kind of policy control that you wish to apply. My question is have you already built a database and an inquiry system that lets people find out what are the registered policy statements of IRR managers, because reading your proposal on the website, it looks to me like we need a facility for people to find out in advance what the policy constraints are? And we need a mechanism to coordinate. I think what you are proposing, for people who do not want wide distribution of their IRR, I think what you are proposing is a good mechanism. But I’m interested in what support technology you may already have to facilitate this? MATSUMOTO: The point is I by using the system of IRR server. We just have a route for this policy but we just pick a route by using this policy. In 2004, if we reach the consensus. Does that answer your question? GEORGE MICHAELSON: I think we will need more discussion to come to an understanding. If you were prepared to progress discussion of this idea at NANOG or at ARIN meetings, I think this would be good. It may be too aggressive to fast to suggest that this could be done in 2004. But the idea that you have talked about I think is worth exploring. I think most people will want very wide distribution of some level of routing policy. The preferred case I believe should be publicly available. But clearly for people who need some privacy of detailed routing, we need a limit for distribution. JUNICHI MATSUMOTO: Thank you for your understanding. Thank you. RANDY BUSH: If I have private routing policy, it will be my own database. If I am my - if my automated software is trying to look up routing policy of others, it has to go to a list of all known router registries. So, why would I want there to be any propagation of data between registries? The only reason I can see for any propagation is so an end user at a keyboard typing up a Whois query does not have to go through a long list of registries to find out who owns it. I think that is a mis-design of the query system. JUNICHI MATSUMOTO: You mention the private routing, private routing information. We are proposing just global routing information. So our proposal including the private routing information, how come some are separated to the private or global routing information in the one IRR system. For example, making a new appeal to an IRR routing, such as no propagation. These attributes in the routing equation never apply to the global registry system. That system is the next step we think. RANDY BUSH: What is private routing policy data? That to me is - I have a contract that says the fact that you do so is private. I’m not going to put that into the APNIC database, that is going to be a copy of the IRR data that I use internally only. It isn’t going to be copied in any way, OK? I currently cannot imagine that there is data that I would put in the APNIC database, which is published. It’s public. It might as well go everywhere. Why do I care? What data is private that I want to restrict to one RIR? Or that I’m going to propagate it all. If it’s private, it’s going to stay within my company? JUNICHI MATSUMOTO: So your question is correct. The system does not propagate private. We don’t have query answer, how to propagate public routing RIRs. We have to have more discussion or something like that about private routing information. XING LI: Any other questions or comments? Q. I’d like you to clarify what do you want, for APNIC to have consensus for some idea? It is not so clear for me. Please again make clear what do you want from this community for this? JUNICHI MATSUMOTO: OK. Our proposal is to have an open distributing policy. If any IRR has to obey. The consensus is - my idea is to spread the IRR database, especially for IRR data. If you ask to obey this policy when you receive the database from any other IRR, you obey this policy or not. If it’s OK to obey this policy, I hope you say that is consensus. Is this clear for you - my proposal and consensus. Q. I may need some time. XING LI: There are three choices. The first choice is make consensus on this proposal. The second choice is say something against that, as Randy Bush said. And the third is put this proposal into a mailing list and discuss in the next APNIC database SIG. Any further comments? If no further comments, I would like you to show hands for which one you prefer to see if the action item can make a consensus. Any comments? OK. First - who likes this proposal and want make consensus passed? Please show hands. Q. Before making consensus, I have one point - this proposal wants to reach a consensus about just a general - generic observation about mirroring policy. General mirroring policy means the NIR and RIR - just APNIC - these RIRs have to have a core mirroring policy to prevent an IRR database distributing IRR database outside to other IRRs and endusers. So we want to make consensus that this point - the common mirroring policy. We have to have a common mirroring policy. Is that right? XING LI: That’s OK. Actually, Randy Bush does not really like this. RANDY BUSH: I just think we’re attacking the wrong part of the problem. That it’s Whois that’s broken and you’re trying to solve Whois by moving the data all round and then, once you start moving the data all around, you want to set policy on where and how it’s moved. And things are getting more and more complex instead of just fixing Whois. XING LI: OK. So any comments or suggestions? Who agrees with Randy Bush’s comments? Please show hands. No? Oh, one. I think this should be put into a mailing list and agree further. One or two agree with the proposal and one agrees with Randy Bush’s suggestions. How about put into mailing list and discuss further as action item. Agree? OK, that’s the thing we can do. OK. Thank you. JUNICHI MATSUMOTO: Thank you very much and just one point - I know there’s no right in the IRR. I propose this policy which is why we hope every region’s NIC sets up IRR server. I hope you do that. Thank you for your attention. APPLAUSE XING LI: Next presentation will be by Paul Wilson from APNIC. PAUL WILSON: This is a proposal which is hopefully a proposal of simplifying things rather than complicating them, referring back to Randy’s previous comment. It’s also a proposal that’s in response to a lot of discussions over quite a few years about the APNIC registration policies and numerous concerns which have been raised over many years which appear to be still with us and are apparently more valid than ever. The background of the policy is that registration is a core goal of address space management. We must record the custodianship of a public resource. This is a fundamental principle. We use the registration practically to verify utilisation of address space. That is a verification by the registry of how much address space is being utilised by address space holders. Registration is also used around the world to address security of network diagnosis issues. So I’m not sure everyone here would have looked up a Whois database to try and find out the source of some network abuse-related incident. These are our principal goals and essential aspects of registration. So, in theory, all useage of address space is registered. The APNIC secretariat is supposed to and does register assignments that are made, not only to members, but to nonmembers as well. Those members, ISPs in particular, register sub- allocations which they make to their customers. So, in theory, all utilisation and all custodianship, whether it’s portable or non-portable is registered. Quite a few perception for this exist and some of us would recall discussions for registrations for cable and ADSL users. We’ve made exceptions in the cases of small assignments to customers that they don’t get registered. We already have a number of exceptions. We also have a number of problems which, as I say, have been mentioned over quite a few years. There are fundamentally at the core serious privacy issues. Long-term concerns have existed about the publication of customer information on the Whois database. In particular, from the ISP LIR members of APNIC, there’s an issue of issue of publishing lists. On the part of customers, there are also concerns about privacy of their own personal information and possible use of that information by others. There’s also, very importantly, increasing government concern for privacy all around the world and some quite strict legislation, that is law, for handling of information. This creates - in particular the latter point, legislation - creates some legal risks and concerns for APNIC and the registry. We are, in some cases, legally responsible for the accuracy of data, also for the advice to the subject of data records, which is required in certain privacy legislation. That is, if you are storing private information about individuals in particular, then there’s a responsibility to actually advise the individual of exactly what that information is being used for. Those responsibilities are shared by APNIC as the publisher of the information. We might also be at some risk of liability for damages caused by maintenance of inaccurate data. So, in the case of network hacking abuse and so on, that is happening from incorrectly registered data, then there may be a case of liability. These legal risks are more recent than the general privacy concerns and they have come about, as I say, from government legislation and so forth. The other problem that we is that customer data is often poorly maintained. APNIC, the registry, has not got direct control over the accuracy of that information. We rely entirely on the ISP, the member concerns, to identify and keep up-to-date records and we know that that happens, that that doesn’t happen to the exist that all customer records are regularly updated. It’s very expensive for them to maintain records in that fashion so that all records are up to date. In any case, deliberate offenders who might be using address space for illegal purposes don’t use accurately registered space anyway. The records most likely to be inaccurate are the ones which are most likely to be the source of problems and hence the problem is that those records serve no useful purpose whatsoever. Some people could pursue that and try to contact the subject of these inaccurate records and waste time do that. They inevitably come back either to the ISP or, very often, to APNIC with complaints about inaccurate registrations and about activities that have been carried out. So the proposal here is quite an important proposal and it’s, as I say, it’s one that has come out of many years of concern. It does really fundamentally alter one of the principles that we’ve discussed many times in this forum and the proposal is to remove the requirement for public registration of assignments by members of ISPs. Public registration of customer assignments would still be optional. So an ISP that is committed to maintaining up-to-date records of their customer assignments so that network diagnosis can be carried out, so that the Whois records can provide a useful record of customer assignations, ISPs should still be able to do that. ISPs might also have - ISPs will also be lodging Whois records for the sake of demonstrating utilisation but they may not want those records to be visible and, in that case, to provide that visibility, it’s proposed to add a new attribute called ‘hidden’ to Whois records that will prevent those records from being publicly accessible through a public Whois query. Registration of assignments is still mandatory in some way or other, because they are required for the registry to calculate the utilisation of address space. Now, that can be done quite easily these days through MyAPNIC. We’ll hear some more about that later on and tomorrow, where MyAPNIC is providing Whois record management and, of course, the important point is that allocations and assignments by APNIC and by NIRs must continue to be registered. We must register the party with primary responsibility for that portable allocation and that is - or portable allocation or assignment and that is, of course, the member or ISP concerned. And I think what we need to do here is to reaffirm the member’s responsibility for usage of the address space, for correct registration of the address space so that the Whois database and performance function of assisting and tracking and security, stability, hacking, spamming, etc problems. This would be available for inetnum and inet6num objects. It would have a value of yes or no. In the case of yes, the data would be considered private and not revealed through a public Whois Query. It would only be revealed through an interface such as APNIC which is secured and will restrict visibility of that data to the owner of that data or to the lodger of that data, in this case the member or ISP. The value of no, if the hidden attribute has value no, then the data is public and would be seen by a public Whois query. Now, the default value, if this attribute is not contained on the record at all would indicate private data. So that proposal would necessarily involve essentially hiding all data by default which was not explicitly revealed, deliberately revealed to the public. And, of course, as I have mentioned in this previous slide, the allocations made to NIRs would continue to be publicly registered, so we would be including the attribute of hidden value no on all of those appropriate records. So the impact of the registration goal, the essential registration goal to track those responsible for particular resources is not adversely affected. The customer of APNIC or the NIR, that is the member or non-member receiving the allocation or assignment directly from that registry would still be visible and, under this policy, we are reaffirming the responsibility for maintaining the accuracy of those records. The fact that LIR customer records may not be available does not arguably affect the registration goal and the ISP responsibility for the address space, for instance, for the responsibility for routing address space, in general, would be accessible. In the case of network problems, particularly in abuse cases, those records are not - almost always not correct anyway. And, of course, ISPs may choose to register customers if they wish to do that and if they commit to maintaining the accuracy of the records. In terms of resourcing administrations and convenience for LIRs and members, there is little or no impact as they have to be registered anyway. Some member with an automated system, there may be some changes required to their software systems to enter the hidden attribute. For people using MyAPNIC, that change would be implemented in MyAPNIC software. The implementation steps involved and modification of the database software is, as you may know, this is the database software and this change would be made by APNIC in this case. We would update APNIC database records for hidden data no. We would update records of NIRs held with us. We would regard some as local database policies for the NIR. There would be a local process implementation at that step. MyAPNIC is being modified to support this change to Whois and it would be changed to allow the data. The implementation timeline is probably - a minimum of three months. It may take a little longer to implement the changes, to do this. That is the proposal and so I’ll be very happy to hear any comments or questions. Thank you. RAY PLZAK: Two things - first of all, a similar discussion is occurring in the ARIN region, both from the stand point of privacy and also from the stand point of which records must necessarily be public records with the discussion saying that public records should probably be only those which reflect direct assignments or allocations by ARIN and anything subsequent. The other thing, in regards to your hidden attribute flag, we’ve already modified our database to have that capability. We did that, however, in regards to what we’re doing to deal with hijacking but it could be used for the same purpose. PAUL WILSON: That’s very interesting. Thank you. XING LI: Any other questions? Yes. IZUMI OKUTANI: I think the idea is very good and it would really help many customers who are concerned about privacy issues. We have a slightly different kind of implementation in JPNIC so it would be quite difficult for us to implement exactly the same policy immediately. But I support the idea in general. PAUL WILSON: Thank you. XING LI: Any other comments? Suggestions? Because this is a formal proposal, we need a consensus. Who supports this proposal? Please show hands. IZUMI OKUTANI: Sorry. I have one more question. I’m for the idea, but what would you do for portable assignments that you don’t have an upstream LIR registration? PAUL WILSON: Portable assignments are assignments by the registry, by APNIC or by the NIR and, in that case, they have to be registered. IZUMI OKUTANI: OK, so the customer assignments are the end user’s assignments? PAUL WILSON: The actual assignment or the assigned block has to be registered because it’s a direct assignment from the registry. XING LI: OK. Who is against this proposal? Please show hands. No? OK, we make consensus on this. Thank you. So three months from today? OK, thank you. APPLAUSE OK, the next presentation will be also by APNIC, Sanjaya. The title is protecting resource records in APNIC Whois database. SANJAYA: OK. Thank you. My name is Sanjaya from APNIC Secretariat. I’m in charge of the database clean-up project. So this is part of APNIC’s attempts to provide a better-quality data for our members and to the public in general. So my proposal will be about making protection to resource records in APNIC becomes mandatory. I’ll just go over these agendas. The motivation of this proposal actually is - we think the correctness of resource records in APNIC Whois database becomes critical in Internet operations. A lot of people are relying on the data to track problems. And, if we do have resource records in our database that are not protected, then they are subject to misuse. And, in fact, unmaintained resources have actually been used by parties other than the original custodians. So what you would probably better know as ‘the hijackers’. So a little bit of a background - why we have unprotected resources in our database. Previously, we allowed objects to be unprotected. That is before. With the Whois v3 migration, those which were not protected, we temporarily maintained with MAINT-NULL, which is a protector. MAINT-NULL itself has no pass word so it is not protected. We proposed in APNIC-14 to replace those with a parent object maintainer. But it did not receive consensus. So, in fact, but then we generate the next item so, early on, Professor Xing Li asked about the action item from APNIC-14 about this project. So we did the test project on the IPv4 202/8 range and everything is quite smooth. So we think we are ready to propose this again and hopefully get a consensus this time. This is an example of an unprotected object. So this is the source object, and it’s maintained by MAINT-NULL which is unprotected. Now, this object has a parent object, so it is a larger block encompassing the previous object and this one is protected by a maintainer. So our proposal is actually to replace this object, MAINT-NULL, by the parent object’s maintainer. So, if we find an object that is maintained by MAINT-NULL, then we will replace it with the parent object’s Mnt-by. And, at the same time, we want to propose, because this would be useless if we still have a maintainer with a ‘none’ authentication. So we feel that it’s about time for us to just deprecate the use of ‘NONE’ in the maintainers. This is an example of unprotected maintainer, a maintainer object with the NONE. We currently have 101 of these maintainers in our database. RIPE at the moment has put forward a proposal to also deprecate auth:NONE. Correct? A. That’s correct. SANJAYA: And ARIN currently does not allow unprotected records. That’s the same as LACNIC. So, this is the report on the test we did on the inetnum 202/8 range. We found 2,889 that is protected by MAINT-NULL and we replaced all of them with the parent object’s maintainer. Successfully converted is over 2,400. We failed to convert 470, partly because the parent object is also protected by MAINT-NULL. So we have to replace this parent object’s MAINTNULL with a grandparent’s object and also there are some other errors. For your interest, this shows there’s quite a lot of records spread all over the region. And, if you look at these objects, I found out that they are mainly old objects - 1996 or older. So, as of the time this report is writ10, we have had no complaints from those that we have replaced. So nobody actually complained to us, which is good. So we would like to propose that we continue with the whole IPv4 range. All IPv6 range, by the way, are protected, so we need not worry about that. So, if we get approval then, 30 days after approval, we would like to remove all MAINT-NULL and replace it with the parent objects on this range. Those that are delegated from IANA and ASN, we will also replace. Also from ERX project, we will also replace it. Also from AUNIC. on the deprecation of autnum, we would like to propose this schedule - one, we send e-mail notification to the contact persons of maintainer objects that is currently protected by auth:NONE and give them 60 days to comply to change from auth: NONE to something else. If not, then we will replace it with CRYPT-PW and then, basically, keep the pass word secure until somebody from that maintainer contact us and we will reveal the pass word to that person. If there is any complaint or any error that we have done a change on an object that is not supposed to be changed, then we can - we will make it within two APNIC secretariat business days to fix that error, as far as the supporting documents have been satisfied. We will report the project in sig-db APNIC mailing list as well as at the APNIC17 database SIG meeting. Any questions? XING LI: Any questions? Comments? Suggestions? If no comments, let’s show hands. Who agree with proposal to let APNIC go more forward? Please show your hands. Agree with this proposal? OK, thank you. Who against this proposal? No? OK. So we make the consensus. Thank you. APPLAUSE And the final presentation is informative, also by Sanjaya, so please continue. SANJAYA: This is a quick report on what we - I think it’s in APNIC-15 action item as well, where we are want to delete objects that is basically not used. So we got an approval in APNIC 15 so I’m here to report what we’ve done. We want to remove Whois records that are not related to actual resource information and also remove - we’ve found some inetnums that are not within our APNIC range. It’s strange but it happens so we also want to get rid of them. And also modify and correct records that are not RPSL-compliant. We say that we will make a notification before we do any deletion and 60 days notification and we will report this in APNIC 16. So, as of 31 January 20 03, we have 21 unused maintainer, 27,554 unused persons and roles. We have 116 inetnums outside of APNIC range. This was the proposal at that time on the timeline. It’s probably easier to read this one. So this is what we have done. We are here now. We have identified all the objects in April. We start to send e-mail notifications in May, because there are 27,000 over e-mail that we have to send, we have to do it over a month period of time. So we start to do probably about a 1000 a day. And we have given 60 days and we have also put the announcement in the public website. So, beginning August, we started deleting the objects. We are about 60% done. September/October, would be dealing with maintainer and the inetnum cleanup while the data correction of RPSL compliance is done immediately as soon as we found objects. So these are the completed tasks. We have announced the project. We have e-mailed all the contact. We have the web information set up. We have deleted about 16,000 person and role objects and no complaints received so far. We have ongoing data correction. And remaining tasks are - we need to continue deleting the person/role for another 40% of them and maintainer cleanup, inetnum cleanup and ongoing data correction. So, hopefully, by the end of this year, or by the next meeting, we could probably record the full completion of this project. That’s all. If you need more information, this is this website (indicated on screen). XING LI: Any questions, suggestions or any other? OK. Thank you. APPLAUSE So, it’s almost done. One thing - as I mentioned earlier, the action item for further discussion on requirements to host the local Whois to be put to the SIG in the mailing list. So, still, we are pending this and need further discussion, because it’s quite quiet. If someone proposes further, then we will initiate the discussion again. What do you think? Because it’s very quiet on the mailing list. How about we close this action item and wait for further proposal? How about this idea? Agree this idea? OK. So we close this action item and waiting for the further discussion. And I believe that’s all for today. And I have some housekeeping announcements. First - KT is the platinum sponsor and the second - MyAPNIC demo all day at APNIC help desk. And help is available at break times. And for others, please check the onsite notice board. And also - someone left this wireless card in the previous session. If that’s yours - it’s SDC wireless card so, if you lost your card, please come here and pick it up. and thank you very much for participating in database SIG and see you next time. Thank you very much. APPLAUSE