1 DISCLAIMER: While every effort is made to capture a live speaker's words, it is possible at times that the transcript contains some errors or mistranslations. APNIC and Lloyd Michaux apologises for any inconvenience, but accepts no liability for any event or action resulting from the transcripts. ************ >>Sumon Ahmed Sabir (Fiber@Home): Welcome back to the second session of the SIG. You are kindly requested to take your seat. We will be starting your second session. Masato already mentioned that there is no more policy to discuss, but there is some proposal regarding the Whois database accuracy and all these thing, so actually APNIC Secretariat volunteered, with some presentation regarding the Whois database and the first speaker on this is Mr Adli from APNIC. He will be talking about Whois database accuracy. >>Adli Wahid (APNIC): Good morning, everyone, my name is Adli Wahid from APNIC, security specialist. I have been asked to do a short presentation on the importance of Whois database accuracy and I will be presenting from the perspective of security response community. We have managed to get some feedback through our security engagements with them, either at this conference or some 2 previous engagements, about how they go about using the Whois database and their expectation. Some of these items are probably straightforward, but I'll just mention them anyway. When it comes to using the Whois database, from the security response community, normally they start using the database when there is an incident, so when something happens, and we have all kinds of security incidents these days, from DDoS attack, people sending spam, some hosts doing brute force attack to gain log-in access to systems, aggressive scanning. Sometimes the security response team have to do with hosts that are DDoS agents or compromised or have been infected or they could be dealing with a botnet command and control, so a machine that is issuing commands to other machines to attack other systems. There will be times where they have to deal with phishing or fraudulent websites. These are sites that try to steal information from users, or there could be times where you have a zero day vulnerability, like Heartbleed or something like that. So lots of hosts are being vulnerable or exposed on systems. In that context, there is a need to be able to stop the ongoing badness, so you need to contact somebody to take care of that or stop that immediately. 3 Sometimes the cooperation or collaboration required are in the form of: please remove that system, or please remove that website, or please block access to it, so that other people will not be affected by it. Or it could be the request or the expectation could be: can you get somebody to fix this, so it's a vulnerable machine, maybe it's a critical system. If you don't fix it as soon as possible, there could be more problems. In certain situations the security response community would like to have more information about it, maybe some logs or how long has this been up and running and who could be responsible for it, or do you know who's ultimately responsible for removing things or fixing stuff, and so on and so forth. This is why the Whois accuracy is very important. So it helps to be able to look up the Whois database, whether it's name or numbers, and in this case I think we are talking about the numbers, to be able to basically get a point of contact and reach that person immediately, because if you don't do that, if you're not able to contact immediately or get an accurate information from the Whois database, there is delay and when you have delay, then you are not able to reduce the impact or exposure of incidents. From the security community, they are always thinking about "How do 4 I reduce the impact?" or "How do I mitigate this from causing more damage?" Accurate information is definitely very important. Without accurate information, what happens today is that they have to go through various loops, like asking people, "Do you know someone that I can trust in that organisation or contact a CERT or contact just anybody who could basically get me to reach somebody in that organisation who is the resource owner or holder of a particular IP address?" So time is very important, so that's responsiveness. Ideally, accurate information is always the first step, but ideally, that point of contact should be able to provide some form of assistance or do something about it. So if they're not responsible, ultimately responsible for it, maybe escalate it downstream or escalate it to somebody for coordination or relay the information to the ultimate resource owner to fix it. The security response community has also been helpful in providing information about invalid contacts. Maybe they have tried for a while and they are not getting the right response. So they really appreciate if there is a channel to tell the people who are running the registry, this particular information is not really responding to the request or the email bounced or nobody 5 picked up the phone when they tried to reach them, to call them, so that this could be probably changed or modified at a later stage. So in conclusion, what I want to highlight here is that definitely the accuracy is win-win for all, the security response community, but also people who are holding such resources because if you don't respond in a timely manner, then it could impact also the users or the customers, that particular block could be blacklisted somewhere and thus it impacts the whole organisation or the customers downstream. But other than accuracy, other qualities that are expected, but this is not the fault of the database itself. But also the person or the organisation behind that point of contact should also be responsive and this means a couple of things. There are certain rules by the resource holder to make sure that contact is always accurate and you have some form of security awareness in the organisation, so if somebody contact you about botnet command and control, you immediately can imagine what is the impact of this and how fast of an action is expected, more or less, and perhaps policies and procedures in place within the organisation or within the economy, or whatever, for providing incidence response escalation or 6 coordination. Policies tend to be very important especially in situations where you need to share some information with an external party, for instance. So having all that in place certainly helps for you to always make sure that eventually you have accurate information provided in the Whois database. I think for the second part, this is in a way an outreach opportunity for this community as well to always highlight this issue from time to time, so that we can always have accurate information in the Whois database that will help other communities who need to use such information. With that, that's all I have. Thank you very much for listening. >>Sumon Ahmed Sabir (Fiber@Home): Any comments or questions for this presentation? No comments, thank you, Adli. >>Adli Wahid (APNIC): Thank you. APPLAUSE >>Sumon Ahmed Sabir (Fiber@Home): Now I'll ask the next speaker, Vivek Nigam from APNIC, who'll be talking about the importance of APNIC Whois data quality. >>Vivek Nigam (APNIC): Good morning, everyone. My name is Vivek and I'll be talking about the invalid contact management, so how we process invalid contacts. 7 Adli just spoke about the importance of Whois data quality, so in this presentation, I would like to talk about what we are doing to improve some of this Whois data quality by processing invalid contacts that are reported to us. Some areas I'll cover include the actual steps we take to contact our members and get them to update invalid contacts, what are some limitations and frustrations that are experienced, as well as some trends and observations we have noticed in relation to invalid contacts. Firstly, I'd just like to show you how invalid contacts are reported. If you ever need to get in touch with a network for whatever the reason may be, you can search them in the Whois database and you'll find some contact details of the person responsible for those networks. In the event any of these contacts are invalid, you can simply click on "Report Invalid Contact" and submit that request to APNIC. There's a simple form you complete, you select what details are invalid, give us some more details of the bounce message and so on and then hit "Submit". When this happens, the help desk team at APNIC we get some tickets with the details of this invalid contact and 8 then we follow this up with the member and try and get them to update. In this graph here, you can see the total number of invalid contacts we process every year. There are two problems you can see here, the first one being the volume. We are getting over a thousand invalid contacts every year, which is quite high. The second one is the consistency. We seem to be receiving this large volume consistently. There's no signs of any improvements here. The typical types of invalid contacts that get reported include the emails are not working, so they are bouncing, phone number is disconnected, sometimes we even get reports that the address is incorrect. Someone has actually gone to the physical address listed in Whois and they find out there's no such organisation that exists there. Then we also get reports of non-responsive Whois contacts. So someone has sent multiple emails, but the Whois contact simply ignores them and does nothing about them. I'd like to talk about how we process these reports once they come through to the help desk team. At APNIC we have some internal contacts for all our members, like the technical contacts, corporate 9 contacts, and so on. So when we get these reports, we send a couple of emails to all these internal contacts and we ask them, "Hey, we have received reports that your Whois contact is invalid. The policy requires you to keep it updated, so can you fix it up and let us know." Generally some members respond to these emails, but there are some who don't. So after that, we try and make some phone calls to these members and then again ask them the same thing, "What's happening? Can you update these invalid contacts." And again some of them respond and do it, but then there are others who simply ignore that. When this does not work, we log those details of the pending invalid contacts and see what other ways we can get them to update this contact. At that stage, we try and find some additional contacts for these organisations to see if they can help us out, so we do web searches, we go to the company website, see if we can get hold of new contacts, we also get assistance from the other team members at APNIC. So we go to our liaison officers, see if they know someone in that organisation. Then even at times when possible, we try and meet these members in person. So when we go to events like 10 this one or NOGs, we see if some organisation is attending with whom we have invalid contacts and then use that opportunity to get them to fix it up. So as you can see, this process can be quite time consuming, sometimes it can take very long and it adds frustrations to the people who are reporting the invalid contact. How do we respond to non-responsive contacts? This one is slightly more tricky. Typical example here is someone has sent network abuse complaints to a Whois contact and after multiple tries, they have just ignored and not done anything about it. In these cases, we try and take a best effort approach. Again, we contact our internal contacts and tell them, "We are receiving reports that you are not responding to your emails. Can you check if you're receiving them and follow it up", and then leave it up to the member to do that. If they don't, we also suggest to the person that they can take legal action, like go to the police and report it and in the case there's a CERT available in that economy, we also suggest you can go try the CERT and see if they can help you. If none of these steps work, we let them voice their concerns through the APNIC PDP to let them know what the problem is. 11 Actually, these days we also receive a lot of these non-responsive contacts from the CERTs and LEAs themselves and then they complain why we can't do something about it. To that, we tell them that APNIC does not have legal authority to enforce standards of behaviour in relation to how those IP addresses are used, and the policy does not allow us to take any further actions here. If the actual contact is invalid, we can tell the member, "Fix it." But if the contact is simply not responding or they are not getting a good response, we cannot take arbitrary actions on a case-by-case basis. Lastly, I would like to share some trends we have noticed. Typically, a new member joins APNIC and they get the maximum /21 delegation, so at the time of the application, they provide all their company details, they meet the requirements to get IPs. After that, almost instantly, we start receiving network abuse complaints originating from those IPs. That is followed by invalid contacts for those IPs, so they are not responding. As of last year, we have had five such cases reported to us. When this happens, we follow our standard procedure, we get in touch with the member, ask them to update the 12 invalid contacts and at this stage, the member stops responding to us. We find out some of the details they have provided to us are invalid as well, like the phone stops working. In this case, we also try and contact the members upstream provider and see if they can help us get in touch with them and follow up this matter and in the event all the avenues we try fail, we issue a notice of breach of agreement to this member for providing us false information and then not updating that information. Then if they finally don't respond to that breach, we simply end up closing the account and reclaiming those resources. These are the different procedures we take. I'm happy to answer questions or get feedback, if we can do something different or if the members should be doing something different. >>Sumon Ahmed Sabir (Fiber@Home): Any questions from the back? >>Aftab Siddiqui (Eintellego Networks): Yesterday we saw the presentation from the services the APNIC Services put a lot of effort to make sure the billing contact is up to date, because that makes a lot of difference for the billing. But they don't make an effort to make sure the IRT object is up to date or not. I would like to know 13 why. >>Vivek Nigam (APNIC): The IRT object we treat as any other Whois object. So when people report invalid contacts, be it for or person, role or IRT, we follow the exact same procedure. So if you think the IRT is not getting updated, I think we should be looking at how all contact objects are not getting updated. We need suggestions on what else we can do to help improve these contacts. >>Aftab Siddiqui (Eintellego Networks): I just need to suggest one thing, I just need confirmation from the ARIN, they do have a system where they send an email to the contact who is responsible for the account, every year if I'm not mistaken, just to confirm that email is correct or not, and if the person doesn't respond, they do something about it. So I just need a clarification on that from ARIN, that that's how it works, and if that is working for them, then why not adopt the same thing here? >>Leslie Nobile (ARIN): We do have a policy for POC validation. We do send automated emails on an annual basis to every single registered point of contact in our database, including direct points of contact that we issue space to and their downstream reassignment contacts as well. We get a fairly low response rate, but after -- 14 I believe it's after 30 days or 60 days, I don't remember, but in any event, if we get no response from them at all, if they don't come in and update it automatically or even through sending us an email, they get marked as invalid in the database and that's where they stay, this is an invalid point of contact. The policy is good in theory, but it's not really working that well, particularly for the downstream customers that we have no relationship with. Upstream customers, the ones we have the direct relationship with, it works a little bit better, but our response rates are fairly low, definitely under 10 per cent. That's a project I'm working on now, we should see improvement next year in the fourth quarter, we have about 7 to 10 actions we are going to be taking and building into our system for improvement, so we hope to see a better response. But it is a policy, it's not driven by a business practice. >>Aftab Siddiqui (Eintellego Networks): In MyAPNIC if you don't create an IRT object, you cannot proceed and do anything without it. So if we take something out of ARIN and send an email to the contacts and if they don't confirm it, we can lock out their MyAPNIC, unless they confirm it. I'm not sure if it requires a policy or it's just an operational procedure, because there is no 15 policy which dictates that if you don't create an IRT object, your MyAPNIC will be locked out. If I'm wrong, so please, Adam, go ahead. >>Vivek Nigam (APNIC): I can give some input there. For the IRT objects, it doesn't lock out your MyAPNIC as such, it doesn't let you make Whois updates, and that is the policy aspect, because after IRT policy was implemented you need to reference IRTs when you update customer assignments or inetnum objects. >>Aftab Siddiqui (Eintellego Networks): Just in case, moving forward, as I said, if we want to take something out of ARIN's policy which is not working as we got to know now, any change is required by other policy or you are planning to make certain changes through your operational procedures? That's it. >>Vivek Nigam (APNIC): In terms of procedures like the idea you suggest we send an email, we can do that operationally, but the problem there is what if they don't respond like ARIN, and it's the same as the procedure we are currently doing, we send them emails manually, this is just automated and might really not make much difference. >>Adam Gosling (APNIC): I was just going to clarify the point for Aftab. The IRT object is mandatory and so that means we were able in Whois to say, "You must 16 absolutely do it" and to stop people doing anything else until they did. So if that makes it clear. It was really a very important part of the proposal, I guess. The other points of contact are kind of in there and they are kind of must have. You must have a point of contact. It's a little bit weaker, I guess, and I guess that doesn't go to the procedures that Vivek is talking about so much. >>Owen DeLong (Akamai): You mentioned five cases last year where people registered address space immediately you started getting complaints about abuse or something and the POCs were unreachable relatively soon after the registration. How many of those were accidental and how many of those were basically a new form of snow shoeing, for lack of a better term? >>Vivek Nigam (APNIC): How many of them were accidental in which -- >>Owen DeLong (Akamai): As in they didn't mean to have their contact stuff be invalid, they just let it lapse and they had a change shortly thereafter by coincidence and didn't update it or how many of them were intentional abuse? >>Vivek Nigam (APNIC): The way we evaluated it, all of them were intentional, which is why we took the extra steps and issued them the breach. 17 >>Aftab Siddiqui (Eintellego Networks): IRT object is mandatory, but if you don't access MyAPNIC, there is no way you can force me to make an IRT object. So that's the only operational procedure you are -- if I had a resource prior to the IRT object policy, unless you have applied the billing contact or the corporate contact as an IRT object, you can't force me to create an IRT object. If I'm wrong, please correct me. >>Leslie Nobile (ARIN): I really need to follow up with that, because I didn't tell you that what happens once a POC is marked invalid, which I think you were going toward this, they can no longer come into their ARIN online account and do anything. They cannot request resources. They can't update records. They can only update their POC handle, if they're carrying that invalid tag. So we essentially lock them out from doing any further transactions with ARIN through our automated system or even through a manual system. So they're done. >>Ernest Byaruhanga (AFRINIC): I was glancing through your membership agreement and one of the things I read was that members are obliged not to provide false information to APNIC. So if their contact information associated with their records in the Whois database is not correct, could that not be considered as false 18 information and therefore a breach of that agreement and perhaps grounds for APNIC to revoke that agreement? >>Vivek Nigam (APNIC): The way I look at it I think the membership agreement is referring to the organisation details for the Whois. We actually have policy documents to say how the Whois should be used and what they should update and know. >>Aftab Siddiqui (Eintellego Networks): Just a comment. Anyone listening to this conversation, we have confirmation from ARIN. They have done it through policy change, so we do have a policy proposal option available. Certainly I'm ready to help anyone, if somebody is interested. Thank you so much. >>Sumon Ahmed Sabir (Fiber@Home): Any more questions or comments? It's a very important issue actually. Adli told about the importance of the accuracy of the data and Vivek shows the operational challenges there. We must find a solution, how can we can make this data updated. Thank you, Vivek, for your presentation and now I'll request George Kuo to come up to discuss improving APNIC Whois data quality. APPLAUSE >>George Kuo (APNIC): Good morning. Thanks for the opportunity and given by the Policy SIG chair for me to 19 share and present improving APNIC Whois database quality information with you all. What am I going to talk about in my presentation for the Whois data quality improvement? Really I wanted to talk about what we have done to improve APNIC's data and why, and what would be the benefit, the outcome of good quality data. I will give you a brief overview of what we have done over the years and what we plan to move forward in the future and perhaps get your thoughts and comments on what we have been doing and whether there's anything more we need to do. The Whois database, as we know it today, contains lots of information, APNIC registry, if I can borrow Geoff's word, we faithfully record all the delegations in there. So registration records about IP address, IPv4, v6, AS number and so on, the resource that has been given. As it is today, that this database also contains a routing registry information, so there's information on routes, and so on, and all this information you can see from this graph here that contain some sort of contact information, email address, phone number, and so on. What I'm really talking about here -- I think 20 there's wrong slides that have been loaded. But anyway, if I could draw your attention to the box in the middle here, that's what I'm talk about, I'm referring to, as to what we have been working on to improve, because that's where APNIC's responsibility lies. So we want to make sure the registration records are accurate. We know that the information is consumed by various different people. That's used for different purpose, for policy, for troubleshooting, network operation support, reporting of network abuse activities and also used by research organisations. There's various different use of it and it's used by various different group of people. I actually have an updated slide and I want to draw your attention again here -- the arrow should be going the other way around. It has been consumed by all these people involved, but in particular, for the APNIC member and NIR members, it's actually two directions of activities, because of information contributed at the same time by the APNIC and NIR members. What really matters? What are really critical thing? We want to make sure the Whois data is always available with information that can be trusted and what I'm focusing on today is the quality of the data. The 21 contact should be up to date for use. On that, we actually have been doing various different things over the year to increase the data quality, to improve the data quality. We started way back in 2013 and that's just the discussion on the floor earlier about the IRT contact. When the policy was first introduced, so we have been working on implementation, because it was not retrospective, but we also did a lot of campaigning and awareness to encourage those objects that were created before the policy implementation to add that information and we have taken by stages to also work with the members to put as much information there as possible. Also recently, just end of last year, we also helped those members who don't have the IRT contact to populate it in Whois in particular for the direct delegations registration in Whois database. At the same time, we believe that to encourage people to update information, we must have good tools for them. We open up the update of what we call the parent registration. Previously, those registrations are protected by APNIC's maintainer, which means contact detail to be -- if there's change to those contact detail, they will have to email APNIC Secretariat, the hostmaster and get those changed. So we have opened it 22 up and made it easy so that they could update it using MyAPNIC portal. We thought it might both be useful to improve the registration guidelines to write it in a language that everyone can understand, the guideline would help to achieve the consistency, so that whoever the different group of people that use the Whois data, can expect a level of consistency. So we know exactly what is used to be registered. So that's what we would like to achieve with the guideline. Of course, it's not just about APNIC. We also need to work with the members of the community to improve that information and so I will show you some more information in the following slide. This is just to give you an example of what's been done. We did the IRT contact improvement, we improved the MyAPNIC portal to allow update to be much easier. We also improved the invalid contact reporting, so when you go and use a Whois search, previously you have to identify which one is invalid and copy and paste and then send an email. But now you can just tick "select", whether it's an incorrect phone number or address, and so on, and email that through directly right there when you are doing the search. We hope that it will encourage reporting and 23 clean-up of the inaccurate information. This is just a quick overview of what we have been doing to help improve the Whois data quality. What's the plan? From 2016 onwards, we believe, like I said, we can't do this alone. The Secretariat collects this information and makes a registration. We also rely on members to provide this information to us in time. As soon as it's changed, they can give it to us, we can change that information and make updates. This is what we like to move forward and also, wherever possible, we have the opportunity to meet with our members, such as the conference, at the NOG activity, at our outreach activities. Also, when we go out and provide hostmaster consultation, we like to have set aside some time to discuss about checking this contact information so we could make update. Again, that's another opportunity to keep the record up to date. Again, I think that's the bulk of my presentation and I would like to, again, seek comments from the membership and the community to see whether anything more can be done and I'm talking about in terms of APNIC's data, but if I can draw your attention back to this diagram here, there's another set of data that exist in the Whois database and that's the third box in 24 the diagram. The reason why is that information is contributed by the holder of these resources, for example, the operators, the ISPs, they register customer assignments, they register their routing information and over time, of course, that information can be out of date and if they are not corrected timely, that affects the whole set of Whois data. So I guess what I would like to seek your comments or for discussion is how can we work together to improve the whole Whois database? APNIC would do its best to achieve the accuracy or information of the delegation, but how can the customer assignment information be improved? Is what we do currently enough or should more be done to improve the Whois data quality? >>Mark Foster (NIWA): Mark Foster from NIWA again, speaking personally. I think one of the problems is going to be that in this you can compel people to update their information. They're going to, many people are going to do the bare minimum required to establish their delegation and thereafter, they are going to focus on things which actually have a direct operational context for them, provisioning customers and enabling services. The details of what appear in Whois are not going to be on their radar unless they are somehow coerced or 25 compelled to keep that information current. That also relates to the point around customer information appearing in Whois, aside from the privacy concern that Dean raised earlier today. If you are effectively requiring an APNIC member to keep their APNIC information, their Whois information current, even as they move assignments from customer to customer, you are introducing a lot of work for them, for probably marginal gain, and I think unless you can basically make it compulsory, you're not going to make a lot of headway. I suggest that the audience in this room are not the people we need to be talking to, because the people in this room are here because they care. I think at a business level, once people have got their operations in place, they're not going to care beyond that unless there's an operational reason to do so. >>George Kuo (APNIC): Thank you for your comments, Mark. I guess I believe it's very important for us to be able to engage widely with the members, because we also would like to understand the way they operate. It could be very different, so at the same time, if I can refer back to my slide earlier, that we also tried to improve tools that the members can use and we have -- >>Mark Foster (NIWA): Sorry, I don't mean to interrupt, but 26 a follow-up question might be: of APNIC members, are there any statistics captured around how many of them make use or make regular use of MyAPNIC? >>George Kuo (APNIC): I believe we can extract that data, yes, I believe so, but I don't have that with me now. >>Sanjaya (APNIC): What the APNIC Secretariat is contemplating and I would like to hear your thoughts about this idea, this is rather a radical idea, is -- can you show the hierarchy again, please? We were thinking or contemplating of just keeping the APNIC direct delegation in the Whois. The customer assignments should just be moved to a different database, probably together with the routing registry information, probably just two different database. One is the authoritative fully under APNIC control information about who they delegate resource directly to and then anything below that, and routing registry that is used by the operators' community, just lives in a completely different database. What are your thoughts on this? This is not the question to you, George, it's a question to the community, those who are in this room. What do you think if we split those two? >>George Kuo (APNIC): I understand, yes. >>Sanjaya (APNIC): Yes, right, please? 27 >>Rajesh Chharia (ISPAI): I second the views of Sanjaya, that whatsoever resources are being allocated from the APNIC directly to the ISP or to the member, it should be on a single database and that ISP in turn are doing the routing to the different different customer, the pool, not I'm talking about the individual IP what we were discussing in the earlier session, I'm talking of the pool, should be sent as an allocation to the customer like the customer assignment, what you are putting as a last block, that can be shifted to another database with a different name. So if anybody wants to have the view of that particularly IP which organisation or member is using this IP, it can be reflected and under that it can be reflected who has allocated this IP address to whom. >>George Kuo (APNIC): Perhaps I'd like to point out just one thing, just kind of triggered by Rajesh, your comment here. Customer assignments actually are compulsory by the policy that need to be registered, but however, within the current APNIC Whois database, LIR members have the option to move those registration to private database if they have privacy concerns. That's how it is done currently. I'm just stating what's happening now. >>Rajesh Chharia (ISPAI): We can remove the address and 28 contact detail as a privacy, but at least the name of the customer should be there, so that immediately we should be able to know who is using the particular IP. My suggestion, but I agree with the -- and I appreciate the privacy of the customer also. We should not reflect the name, address and whatsoever things are there, we can put that clause under the private and rest one name should be there, into the public domain. >>George Kuo (APNIC): Thank you. Any comments or further question? >>Mark Foster (NIWA): Just in addition from myself, I also support Sanjaya's thoughts. We would greatly improve the accuracy of Whois information if the vast majority of the information that's in there and inaccurate right now, because it's stale, were to be moved elsewhere. That seems like a simple answer to the problem. >>George Kuo (APNIC): Thank you, Mark. >>Aftab Siddiqui (Eintellego Networks): Just for the sake of clarification, you are saying that what Sanjaya was suggesting, that there will be one database which will carry all the information of the member details which APNIC assigned to them, right? >>George Kuo (APNIC): Sorry, I didn't quite hear you. >>Aftab Siddiqui (Eintellego Networks): One database which is -- who will manage the first database. APNIC will 29 manage it or the member will manage it themselves? If members are going to manage it themselves, then we'll end up with the same situation that we have today. So if APNIC is going to manage it for them and members can't change it, then are you going to take that responsibility for 5,000-plus customers? >>George Kuo (APNIC): Currently, now in Whois it's the member's or LIR's responsibility to make sure those customers are registered and updated. But it's just all in one, but I think the proposal that was or suggestion that Sanjaya mentioned is to move that information and put it in a separate database, but of course it will still have its quality issue, but at least the database or if you still call it APNIC's Whois database, would contain the upper level of registration, the direct delegation from APNIC and that would be a much better data set. >>Sanjaya (APNIC): The answer to your question, Aftab, about the first database, the authoritative database, is it will be a collaboration of course between APNIC and the NIR by the way and their direct members. >>George Kuo (APNIC): And the members, yes. >>Sanjaya (APNIC): It is still collaboration, but who's responsible, it's APNIC. It is APNIC. So APNIC is responsible and has to make sure that the members do 30 update them if they change their data. So it's okay, we can do it, because we have a relationship, direct relationship with this member, so just what Leslie said, they have a much better ability to speak with the POC of your direct, the one that you have a direct agreement. So that's what I suggested. I'm not saying that the member cannot change, I think through MyAPNIC, they should be able to still change contact person and then APNIC would probably do secondary check or something, just make it a bit more high quality. >>Aftab Siddiqui (Eintellego Networks): This is totally aligned with my previous comment and I support this suggestion. >>Ingrid Wijte (RIPE NCC): I would like to share a few of our efforts regarding the contact information from our members and some things that we do to improve those. Within RIPE region we have a procedural activity audit which is mandatory for all members and since about a year ago, we have revised that activity and it's now called Assisted Registry Check. We call every member, about 3,000 a year is what we currently aim for. We send them information beforehand regarding all sorts of information which we want to check with them and contact information is one of the main things, both in the RIPE database as in our 31 internal systems and it's actually quite successful with regards to the quality of the information that we have, because almost 50 per cent of cases, contact information was updated both in the RIPE database as in our internal files. So that's 50 per cent of the people that we contact had outdated information, which currently is improved. Additionally, we also discuss with them the registration data that they have for their customers in the database and encourage them to review those and help them out if they need our help to update things. >>Gaurab Upadhaya (Limelight Networks): I don't see this discussion going anywhere, frankly. I also think that maybe you can do a better job of separating the registry information from the supplementary information that goes into the Whois and making it clear what APNIC is authoritative about, which is the registry database. Your address allocation is what you are authoritative about. What goes into the IRR portion of the Whois is completely mistake, I mean, you know, RADb is crap and so is most of the IRR data. I think that distinction needs to be made very clear to everyone that, "Hey, we don't really have a way of validating what people put in IRR and how old it is and whether it is even correct", 32 still, and there might be other mechanisms to deal with that, like setting automated updates or whatever. What I would like to see is a complete separation of those two topics and a focus on getting our registry data correct and given that people don't pay they get kicked off, I think there is a valid way of validating the registry data itself and maybe you need to tag the data that comes out of Whois saying, "This is a registry data. This we are authoritative about." And that will be a way, that will only give you allocation information or assignment information. I mean, that will give you allocation information. It won't give you the assignment details. Maybe that will clean up, because I don't think APNIC has responsibility of the IRR portion of the data that members don't update. Make sense? >>George Kuo (APNIC): Yes. >>Gaurab Upadhaya (Limelight Networks): I think that needs to be communicated. If you say Whois, then the point of the discussion is moot. >>George Kuo (APNIC): Just to clarify, so you support the proposal that Sanjaya mentioned earlier to separate this data, that's what you -- >>Gaurab Upadhaya (Limelight Networks): Yes, and how we do that might be a separate topic of discussion. 33 >>George Kuo (APNIC): Yes, of course. >>Gaurab Upadhaya (Limelight Networks): I don't think we should be having two Whois or something like that, but the data can be tagged, saying that allocation or whatever, however we do it, or the Whois interface can refer to two different database, so that when we get the source -- I mean, I'm going into details now, but, yes. >>George Kuo (APNIC): Sure. To respond, my response to your part of comments is that we are actually working towards the direction to engage the member to update the registry data. Thank you. >>Elise Gerich (ICANN): I was just going to ask a clarification on the proposal itself. I think Gaurab might have just talked to that, but I want to see if I understand the proposal. For instance, in the IANA database for IPv4 unicast allocations, we never do anything except say APNIC, RIPE, ARIN, LACNIC, AFRINIC. Yet, then there's a pointer that then goes to the regional registry databases which then it's your responsibility to say that you have allocated to the LIRs or whichever organisation, so is that proposal to have a similar hierarchy such as we have today but taken down to LIR region? Is that what the proposal is that we expand the hierarchy to have lower levels? Sanjaya is just shaking 34 his heads. Okay, thanks, I just wanted a clarification, because I wasn't sure what the proposal was. Thank you, Sanjaya. >>Sumon Ahmed Sabir (Fiber@Home): Masato, you have a comment? >>Masato Yamanishi (Santen Pharmaceutical): I have a question for clarification also and it is related with Elise's point. Since we have NIR maintain their Whois database, does NIR have same issue, and whether this discussion should also need to consider NIR database or not? >>George Kuo (APNIC): Let me explain what has been done now. We also register the delegation -- there is also information of the NIR's delegation to their member. I believe that's also kind of authoritative, so they would maintain in among other APNIC direct allocation to its member. Currently, when the data sync between APNIC and NIRs' Whois, it also bringing customer information as well. So if we were to move towards the direction to separate those two, then obviously that part of the information will not be in the Whois. >>Sumon Ahmed Sabir (Fiber@Home): Does that answer your questions, Masato? >>Masato Yamanishi (Santen Pharmaceutical): Rather, I like 35 to hear NIR's comment. >>Sumon Ahmed Sabir (Fiber@Home): Izumi, can you please come forward? >>Izumi Okutani (JPNIC): We're an NIR in Japan, so I think we basically run our Whois in the way which George has explained, so we do run our own Whois. So in addition to English we have the Japanese information, we send all our Whois information to APNIC and we are pretty much responsible for the accuracy of allocation data or direct assignment data and then for the registration of the customer assignment within the LIRs actually take responsibility in ensuring its accuracy. So, I don't know, if the idea is to actually remove that part of responsibility of having the registration of assignment data and we will be removing those and we would be pointing out to, I don't know, LIRs' Whois, that might actually need some changes within our Whois, so that would be a big requirement. But then just thinking in terms of who's responsible for keeping accuracy for which data, I think I agree with this thinking that for allocation it's basically the registry, in this case APNIC, or NIRs who register data, would be responsible in maintaining its accuracy. Then for the customer assignment, under LIR's allocation, LIR should be responsible in ensuring its 36 accuracy. Does that clarify? >>George Kuo (APNIC): Thank you. >>Rajesh Chharia (ISPAI): I agree with Izumi, that the data which being allocated by the NIR, especially India, we should be responsible for the correctness of the data and we ensure why, because we are using the Whois data of APNIC right now and while we are allocating any resources to our members in turn, we are taking three step KYC documents, know your customer documents, which is the government documents. After that we do the allocation. What we seek, when we are allocating, when we are producing any data to the APNIC or to our member for the registry, we are responsible for that and I second the words of Izumi. >>Klee Aiken (APNIC): I'm watching the Adobe and Daryl referring back to the original idea, says, "Good idea". >>Sumon Ahmed Sabir (Fiber@Home): Thank you. >>Aaron Hughes (ARIN, 6Connect): Aaron Hughes, 6Connect, ARIN board and citizen of the internet. It seems to me that the approach that we're taking is a little off, in that we seem to be focusing on removal and effectively RIR NIR attestation and clean up and lockout and that a potentially better approach would be to look at this as a global issue and potentially get 37 a group together to have an outcome document of an RFC for marking things in a positive way. In other words, attestation that a given object is correct by an RIR or by an NIR or by operators and have some system to say every time this is attested to it is higher in value as more accurate, and a way to extract that data, so we can mark them that way. So that things that never get touched simply are unattested and we can choose whether to use those objects or not. I'm not exactly sure how to get a group together like this, but I think sort of a Knights of the Routing Table kind of group would be a great way to start talking about an outcome document that is actually changing the RFC and making a standard better to actually create attestation. That's my two cents. >>George Kuo (APNIC): Would there be any question for me or comment? >>Paul Rendek (RIPE NCC): I'm trying to get my head around this thing, because I'm looking at it maybe from different perspectives as well. I actually can see the point that ARIN has brought up. Because it looks to me, correct me if I'm wrong, because this isn't my forte here, but it looks to me like you're just kicking the bucket down the road a bit. What will then be the accountability chain? 38 All of a sudden, wow, the RIR databases look nice and clean we can say that the quality is good. Then this next set, what would be the whole mechanisms around making sure -- because this is why you're bringing this up, the data is not -- the quality is not there, we have privacy issues, I guess, from a sovereign perspective. People look at things differently on what you would put in databases. I understand all of that, but it almost seems like we are kicking the bucket down and I don't know, and I guess it would be smart, this is the part that I liked about what Aaron said, is that you probably need to get a group of people together to discuss, "What does this mean?" Because what would be the various accountability chains going down the round? I think potentially it could add complexity, but then again I can also see that if the accountability is right, it would be a little clearer. I'm not really sure. >>George Kuo (APNIC): Thank, Paul, and actually after Gaurab's comments I was going to add a bit more information. Actually, one of the objectives, I can say, for this presentation is to share activities the APNIC Secretariat has been doing to improve APNIC's data and so I mentioned that we are doing various improvement 39 in web information, tools, way how object can be updated and we try to form a set of guidelines and now we move on to engage widely with the membership, understanding how they work better, to understand how they create or provide information to us and just to get a better understanding, so we can work better with them. As I said, the Whois registry data, we can't do it alone. We also need members' help to provide the information timely to us and that's the engagement part that we are working towards. It will be quite similar to what Ingrid shared earlier that RIPE NCC has been doing. So that's one part of this presentation. Then there was the proposal from Sanjaya to perhaps we could also consider separate, different sets of data that contribute purely by the operators, by the APNIC members and by shifting that away which contains customers assignment, contains routing information, if you move that aside, it's like if we have a very messy room while we work very hard to tidy that up and we move some sort of stuff away, it will become a much tidier room, if I could use that analogy. >>Sanjaya (APNIC): Sorry, George, but the intention is not like what you implied, like kicking the bucket down, no, it's not. It actually becomes just yet another domain 40 of information that needs to be managed. >>Paul Rendek (RIPE NCC): You are making another dirty room. >>Sanjaya (APNIC): No. I think my idea is not exclusive to Aaron's idea. We can do both. So we could then apply attestation process on both of these realms. You see what I mean? It's just that we want to have control on our realm, the registry's realm. Yes, we can use the attestation and then the operator realm can have their own, and that's why discussing in the IETF is probably the right place, because it is particularly the operator realm. What will be the best practice here? >>Paul Rendek (RIPE NCC): That's great. That's the reason why I support -- >>Sanjaya (APNIC): We can have both. >>Paul Rendek (RIPE NCC): Yes, Gaurab's train of thought had me going, "Okay ..." and Aaron's train of thought had me going, "Okay, because ..." If I look at this even further down the road, we all have this issue. It's not a single RIR that has this issue. But we're not looking at this from a common perspective. We all probably have procedures or policies in place on what we see is acceptable data, and we have mechanisms for how we would say, "Hmm, the data is not good, so we are going to do this to you." Each registry does it in 41 a little bit of a different way. When you look at the world out there now and maybe how people are looking at this, they are probably saying, "Hmm, doesn't this need to be looked at a little bit from the perspective globally?" You know what I mean, maybe not just within each RIR, but it would be probably nice to have a lot of eyes on this, because sooner or later, that accountability from that other room that you have made dirty is not going away. We need to understand what that is from regional perspectives and I think that that's great and I think a place like the IETF or something in the collective there probably would work. I can see what you're doing here and it would probably make this a little bit cleaner or it would look a little bit cleaner, but I'm wondering whether we're adding complexity of moving something somewhere and then making, what, a whole another body? Who would make sure that this was in line with contracts and policies and procedures within each RIR? It starts to get a little bit more complex there. That's why I can kind of see what Gaurab was saying and what Aaron was saying there, but okay, that's just my thinking. >>Owen DeLong (Akamai): I think the point that the discussion has devolved to members of RIR staff debating 42 amongst themselves in front of the community the minutiae and details of how to go about this maybe should be taken off line. >>Izumi Okutani (JPNIC): A quick support for Aaron's comment, Paul's comment earlier and I think it's important that we have an integrated common picture with other parts of the region and of course we need to hear operators' input. Not everybody is here today at the session and it's them who actually use the data and they need to update the data. I do have mixed feelings about physically separating the data sets. But what I liked about Sanjaya's idea is how I understood it to have clear sense of responsibility. So I think realistically, RIRs can't chase or NIRs can't chase each of the LIR's customers. So if we want to maintain the data accurate, we really need to raise awareness that this area under LIR customers is the part that LIRs really need to focus and work on. So it doesn't mean that we don't care about the accuracy of data below, but then it's a way of ensuring, "Hey, it's your part of the responsibility, so can you make sure that you actually update the data", and I think if we can actually share this kind of message in an integrated way and then with other regions, I think that would be really nice. 43 >>Sumon Ahmed Sabir (Fiber@Home): Thank you, Izumi. Actually, we have another presentation, so thank you very much for the comments. I think we need to control this discussion. >>Masato Yamanishi (Santen Pharmaceutical): What I could capture from the discussion is many people think this topic is worth to continue discussion. Also, maybe we need to have more global discussion or discussion among different entities. Also, one of input came from security community, so I think we need to show what we think about this topic right now. So can I ask the APNIC Secretariat to summarise the discussion and possible next step and present it to the mailing list? Then we can continue the discussion on that level. How about this idea? >>Adam Gosling (APNIC): I'd be more than happy to summarise that. I'm not sure what the next step might be. We can maybe talk about it amongst the staff, but if anyone has any suggestions what the next step might be, other than post this on the mailing list. >>Masato Yamanishi (Santen Pharmaceutical): I think one possible next step which arise in the discussion is ask opinion to other RIRs or other community. >>Gaurab Upadhaya (Limelight Networks): I strongly suggest 44 we involve the NRO AC or ASO AC, whatever they are called, because this would be coordinating this within RIRs and I do think this probably likely has to go all the way to the IETF, you know, or put it in DNS. That always works. LAUGHTER >>Masato Yamanishi (Santen Pharmaceutical): We have two NRO AC in here. How do you think? >>Aftab Siddiqui (Eintellego Networks): Wearing the NRO AC chair hat, I guess, if you're not putting it in the DNS, that's cool and then we are happy to discuss with the community and within the ASO AC as well. So we'll take care of that. We'll discuss it and share it with the Secretariat, what our input is, and we'll update as soon as we can. Thank you. >>Sumon Ahmed Sabir (Fiber@Home): Thank you, George. >>George Kuo (APNIC): By the way, you will be able to download my current version of my presentation from the conference website. Thank you very much. APPLAUSE >>Sumon Ahmed Sabir (Fiber@Home): I'd like to now invite Elly Tawhai from APNIC to talk about the APNIC version upgrade. >>Elly Tawhai (APNIC): Hello, everyone. My name is Elly Tawhai and I'm here to talk about upgrading the APNIC 45 Whois current version that we have. What I'll be covering in today's presentation, I'll be covering the motivation behind upgrading the APNIC Whois database, along with objective and some challenges in doing this, along with a number of proposed changes if the community is interested and what are the next steps. Up on the screen you can see a number of motivations. The motivations behind upgrading the APNIC Whois database and getting the community's feedback from this is, well, one of the reasons is we want to take advantage of enhanced syntax, new flags and attributes. Basically the reasoning behind this is to help improve the user experience. The other advantage is to also provide a better operational testing platform, and I'll go into more details about this. This will help to improve database accuracy. Also to provide the APNIC community with richer APNIC database query options. Currently APNIC uses RIPE NCC's Whois database code, but the APNIC Whois database has not had an upgrade for a little while now, so we're a little behind. The objective behind this is to upgrade the APNIC Whois database to the latest version. Some of the challenges is user awareness, making the 46 community aware of the new objects, attributes, flags, features that will be available to them and getting their idea of what the community would like, along with data conversion and policy difference. Because there is currently a policy differential between RIPE NCC and APNIC and by this there will be data conversion and change from both of -- from APNIC's side in order to implement this code change. The first change, if the community is interested, is what we call an organisation object. The organisation object provides information about an organisation that is registered for an internet resource. Its purpose will be the means to link together all of the internet resources related to an organisation. This object will be the starting point for managing data within the APNIC Whois database. All of your other objects will be related to this one object. To help put this in perspective, on the screen you can see what an organisation looks like, an example of it. So you can see that the organisation object will only contain business organisations. It can be referenced within any object. The advantage of this object is that you will be able to have many ways to perform inverse queries on data relating to an organisation. 47 What I mean by this, one of the challenges I have talked to members about this week is, say for an example, the case scenario where a member has many objects registered for their organisation, for the internet resources within the APNIC Whois database. They have had a number of different contact changes, so these contacts have left the organisation, their person object is referenced within their resource objects, they're not sure what their previous contacts NIC handles were, so it's very hard for them to perform inverse queries, in order to update their objects relating to internet resources. The advantage of this is having an organisation object, it would not be difficult to find all of the resources or information about their customers for their organisation as their data would be set up in a more structured manner. The next change that we are going to cover is what we call an import-via and export-via attribute. What this means, these attributes use what we call routing policy specification language, which allows operators to specify routing policies regarding directly adjacent networks through various import and export statements. These attributes only apply directly to adjacent networks, so the addition of import-via and export-via 48 attributes within the aut-num object will especially help participants of multilateral peering services to inform the intermediate autonomous system what routing policy should be applied towards other participants. To give you an idea of what this will look like within these import-via and export-via, I have just given a brief example of what it would look like using routing policy specification language, in order to help put it in perspective. Moving right along, the next attribute we are proposing is created and last modified. The created attribute would contain the date of when an object was created. Last modified would actually contain when an object was last modified. By introducing "created" and "last modified" attributes will lead eventually to the depreciation of the change attribute, which we use currently. The issue with change attribute currently is that although there can be only at least one change attribute required, there is no guarantee that this change attribute will actually contain data of when the last change was actually made. The advantage of adding both "created" and "last modified" attribute, they will contain more accurate data of when an object was created and when an object 49 was last modified. What will happen is if the community is interested in these attributes, every object will contain a created attribute and a last modified attribute regardless if an object has not been updated since it was created. That's how we would go about implementing those attributes, if the community was interested. The next attribute change that we are looking at is referral by attribute to be changed as optional. For those of you who don't know, a referral by attribute is listed within a maintainer object. The purpose of the referral by attribute is to list the maintainer used during the maintainer object creation process. The problem is that it is contained in the maintainer object for historical reasons. A lot of people when you talk to them in the community, they don't know what a referral by attribute stands for. So by changing this attribute as optional, it will make it easier for people to be able to create their maintainer objects and know what to list within this attribute. We are also proposing to change the syntax for a role object, in order to be more like an organisation object rather than a person object. By changing the syntax, what we will do is basically it will become much more relaxed of what you can put in the role object 50 attribute itself. This attribute could contain anywhere between 1 to 30 words separated by white space. A word could have up to 64 characters. The role object attribute could not only contain letters, but it could also contain digits and characters. Characters such as square brackets, colon, exclamation mark, so if your organisation contains these types of characters within your organisation name, then you will be able to list these characters with the role object attribute itself. The next feature I'm going to talk about is dry-run updates. What dry-run updates will allow you to do is to test an update within APNIC Whois database without actually changing anything. You could test your updates within the production Whois database without any changes taking place. If you had any questions such as what would happen if an update was made, would the update work, what would the change look like, this is what you could do using this feature. We do have a test APNIC Whois database currently, but the problem with using the APNIC test Whois database is it has limited data. If you wanted to test a particular update, you would have to replicate this data by creating certain objects, in order to ensure that an update would work. 51 The advantage of creating or using this dry-run update future, you could test your updates within a production APNIC Whois database without any change being made. So it would be much less effort. The last change I wanted to speak to you about is new query flags, such as valid syntax and no valid syntax. Over the course of time, syntax of database objects have changed. However, existing data may not always have been updated when these changes occur. There may be objects within the database without invalid syntax, according to the current rules. These query flags, what they do is they allow to filter out the objects in a query response, so those objects with valid syntax or those without valid syntax. The advantage of these new query flags is there can be a comparison used from old version to new version for data checking. I've talked about all these different changes, so what's next? I'd like to encourage and we welcome feedback from the community, so what we will do in March is we will make a web page available which will cover and outline all of the changes that I have mentioned, so the new object, new attributes, new features. So this page will 52 contain information about this and it will allow the community to go through in much more detail at your own pace and have time to digest this. What we will do is encourage, once the community has had a look, is to provide feedback. We will gather this feedback and based on interest from the community, we will then upgrade the APNIC Whois database according to what features the community is interested in. We are looking to perform the APNIC Whois database upgrade some time before the end of the year and reporting on this feedback within the next APNIC standalone meeting in Bangladesh. Thank you. Are there any questions? >>Sumon Ahmed Sabir (Fiber@Home): Any questions for Elly regarding the Whois database upgrade? >>George Kuo (APNIC): I just want to quickly add one comment that Elly mentioned about the challenges in data conversion, that should not require any effort by APNIC members. Thanks. >>Sumon Ahmed Sabir (Fiber@Home): Actually, I just wondering that you mentioned that import-via and export-via object. What is the difference between the export and import? >>Elly Tawhai (APNIC): Basically, from my understanding, it will allow the attributes listed within the aut-num 53 object and it will help the participants basically with multilateral peering services to inform the intermediate autonomous system what the policy should be applied to other participants. For example, if there was one AS number that had root server participants, they could outline who their root server participants are and they could also outline who is actually functioning as providing the function of a root server. Is there anyone else in the room that would like to go into more detail about this? >>Sumon Ahmed Sabir (Fiber@Home): Any more questions? Thank you, Elly. APPLAUSE >>Sumon Ahmed Sabir (Fiber@Home): I think we are at the end of our session. We started with the importance of data, updated data, correct data in the Whois database. Then we saw how Vivek presented how APNIC is trying to correct, rectify the incorrect data and then we have some improvement plan and we have had a lot of comments and feedback. I think it's very difficult to come to conclusion and it came to that we need to talk with the other RIRs actually, how they are handling and it's a global issue altogether and LIR, NROs are involved and I hope they will give us some feedback on this and Sanjaya proposed to split the database into two parts, 54 and everything needs to be discussed further and I think we can see the database will be more accurate and give accurate information. It's very important for security reasons, important for routing and any other related information. Contact information is very important especially on this, so I think we have more further discussion. It's almost lunchtime, so thank you very much for being here. The next session will be at 2 o'clock. Just before finishing, I think Masato wants to make a comment, he has something to say. >>Masato Yamanishi (Santen Pharmaceutical): Before ending the SIG session and going to the lunch, let me mention two things. First one is although we are ending Policy SIG session, we will have another session about geolocation which is related with IP address policy. Originally, APNIC staff asked to cover that topic in Policy SIG session also, but I'm afraid that there are too many informational sessions compared to the fact that we don't have any official proposal. So we decided to have that topic as another independent session, not part of SIG session. But please attend that session also if you will be available in this afternoon. The second thing which I want to mention is about my 55 term. As you know, my term will end at next APRICOT meeting, not next APNIC meeting. So second next meeting. I would like to announce that I'm not interested in continuing this position further for two reasons. First one is I was elected co-chair in the second meeting of 2011. So indeed, this meeting is the 10th meeting for me as co-chair or chair and I think it is better to have a new person in this position for the community. That is the first reason. The second reason is I'm now working for a different industry, so it is not easy to catch up latest status in this industry. So for these two reasons, I decided I will not continue for next term. Currently, I'm thinking about two options. The first option is I will step down at the next meeting and have chair and maybe co-chair election in next meeting. The second option is I will serve chair until the end of term, then we will have chair election in second-next meeting, next APRICOT meeting. I'm still wondering between these two options, but anyway, if you are interested in Policy SIG chair, please contact me or Sumon or Adam or George, and we are really happy to explain what is the roles and responsibilities of Policy SIG chair and also since I'm still wondering among the two options, when I will step 56 down or end my term. So please share your thoughts to help my decision. Thank you very much. The meeting is over. APPLAUSE >>Aftab Siddiqui (Eintellego Networks): I just want to make a comment. Masato, you as a Policy SIG chair have done a great job so far in those many years. I would like to thank you for your efforts and I would like to request you to continue in your position until your term expires. Thank you very much. >>Masato Yamanishi (Santen Pharmaceutical): Thank you very much. I will work as chair in next meeting, at least, so you don't need to worry right now. Can I declare ending this session. So the meeting is over. Thank you very much. APPLAUSE