Transcript - APNIC Services

Sanjaya: Good afternoon, everyone. Welcome to the first APNIC Services Forum. We are going to have this forum in APNIC meetings starting this meeting, so this is going to be a regular forum.

As you know, the work of the APNIC Secretariat is to deliver services to both members and stakeholders, and this new forum will highlight some of the major projects of APNIC for 2012, and it will give you some information about the existing services, as well as upcoming services that we are going to have.

Hopefully, we could get some feedback from you, and for us to keep on improving our services.

Today's session, we will cover a range of topics, from our general public website, also to the technical services and upgrades and our investment in the Internet infrastructure.

We would like to focus this particular session on the South Asia region, because we are having this meeting in Delhi.

Let's start with the first presentation, by Louise Flynn. Louise will present our new project that APNIC has just started this year, called APNIC CONNECT.

Louise Flynn: Thanks, Sanjaya.

For those who do not know me, my name is Louise Flynn and I am the marketing and public relations consultant for APNIC. I work in the Members Services area, so most of my work is focused on bringing you, the members and stakeholders of the APNIC Community, more information about the APNIC services so you can get the best out of it.

You will see that reinforced with our new logo type, the focus on the APNIC Region, but specifically our mandate is not only to distribute address space, but to provide you all the information that you need.

My job is continuous improvement in that communications, and so I had a think and I thought about what most people would think about our community. There is certainly a level of diversity, but it's -- particularly with the old communication methods, there's a feeling that it's static, people are doing things slowly.

In reality, our community has different cultures, different languages and different levels of experience. We have so much collective intelligence and we as an Internet Community have a long history of being able to share this intelligence amongst ourselves, and that is the basis of why our Internet has grown the way it has.

I had another think about it, very late at night, and that was more like what I thought the APNIC Region looked like, with all the bouncing and moving and changing. So I thought, maybe our communications really needs to take into account that changing dynamic nature of our community.

What would it be like if we could get more members to talk to each other?

What is Project CONNECT? Well, we are looking to streamline the sharing of information at APNIC, between APNIC Secretariat, the Executive Council, our members and stakeholders -- more information on our services and how to use them, more information on APNIC research and statistics, more information about your fellow APNIC Community members and what they are doing in their local communities; more information on what's happening in global technical and governance forums and meetings; more information from other technical publications. Because we would like to share APNIC information but we also see some fantastic publications readily available that we want to be able to share with our members.

The point of APNIC CONNECT is to give you the opportunity to get the best from your APNIC membership. How do we do this? We are still working on this but what we think is we are going to bring you a single stream of information that members are going to be able to access and bring into a format that suits them. I will re-emphasise that. Rather than create another mailing list or another four, we want to take that information to where you read your information -- so bring it to you, so you can tailor it to the way you want.

We are looking to use familiar social media tools -- and I have just listed a few. In some other cultures there are certainly some other social media tools we are looking at as well, Facebook, Twitter and RSS.

You can start right now, if you'd like. We would like to build CONNECT from today. Please follow us on Twitter, we have a hashtag #APNIC33 that is running at the moment and I'll be tweeting during the session. You can "Like" our Facebook page, and if you "Like" it today or if you are new to our Facebook page, you will see some fantastic images from our sessions earlier today, and join our LinkedIn community.

How can you get involved? Project CONNECT will be only successful if we get the feedback from the community on how they want communications to come to them. We are looking at the feedback we have from you, because one of the biggest areas of comment on our member and stakeholder surveys is how people want to be communicated with.

We have website usability survey that we have the results of, that you will see next, and our upcoming members survey for 2012. But feel free to approach myself and the other Project CONNECT team, a few of which are here -- the Project CONNECT team is a diverse group of people across our business, from software to publications, to policy and community. We would love to hear your feedback, and thanks very much for listening.

Sanjaya: Any questions?

OK. Thanks very much, Louise.

APPLAUSE

Sanjaya: Next up would you Bhadrika Magan, our publications manager, and she will report the findings on our recent website usability test, that's our www.apnic.net website. We did some usability surveys last year, and this is her report. Thank you.

Bhadrika Magan: Thanks, Sanjaya.

My name is Bhadrika, and I think I have met a lot of you. I am the publications manager and one of the key roles the team does is to look after the APNIC website.

We conducted the website usability survey last year, and by way of background, we launched the new website a few years ago, so we thought it was a good time to survey members to see what they thought of the website.

There were 21 survey questions, and respondents rated the website according to a scale of "very dissatisfied" to "very satisfied", and there were a few questions which provided for comments.

We had 418 respondents, 223 were account holders, and 195 were not account holders. The respondents also generally reflected the membership composition. They were spread across Australia and New Zealand, South-East Asia and South Asia.

We also got some interesting data from Google Analytics, which indicates there is a strong Chinese-based community which accesses the website, but we will be doing some more research into that.

Overall, we had high satisfaction for the website. 71.5 per cent of respondents were somewhat satisfied to very satisfied, with 77 per cent -- if you include the neutral responses.

95.8 per cent found what they were looking for and 83.7 per cent of respondents were familiar with Internet concepts. Also, the majority of the users visited the website from an APNIC communication.

Here is a graphic to illustrate the satisfaction rates.

What did our members come to the website to look for? With the nature of the questions, we rounded out a top 15 and a bottom 15. The top 15 includes the top 8 of IP addressing, learning about IPv6, address trends, membership information, MyAPNIC, IPv4 exhaustion, resources and policies.

Here is a graphic to illustrate that.

The bottom 15, it was not surprising, except for maybe two or three, which included mailing lists and resource certification.

In terms of navigation, 94.8 per cent found the menu options on the home page clear and 90.9 per cent found the left-hand menu and other navigational tools clear.

80.3 per cent of respondents did not have any trouble navigating the website, but 19.7 per cent did, and 10 comments related to trouble accessing information and tools.

In terms of accessibility, again it was a good response, we had 95.8 per cent of respondents who found what they needed and 89.2 per cent did not have any problems accessing the website.

We grouped the users into three categories, which we found: frequent users, regular users and first-time users. We got those results from the majority of the users who visited the website several times a month, several times a week and once a month.

It was interesting to note that we had first-time visitors which measured at 13.56 per cent.

Here is a graph to illustrate that.

269 respondents preferred email updates, and this indicates that they desired getting information in a preferred format, rather than relying on visiting a web page.

In terms of functionality, we got some very good responses, in terms of "very satisfied" and "somewhat satisfied", for content that was informative, relevant and clear.

Similarly with quality and appearance, 71.5 per cent were "somewhat" and "very satisfied overall", in terms of speed of page load, navigation, easy to understand and visually pleasing, ranging from 3.58 to 3.65 out of 5.

Here is a graphic to illustrate that.

What we realised is that general information about IP addressing was the most popular with first-time users and with regular users, so it is very important that we keep that information up to date and clear.

With the bottom 15, it was surprising to see resource certification and use of mailing lists in that bottom 15, so we need to create awareness and improve the content. Also, we will be tweaking the navigation to address the 70 respondents who did make comments.

What we are proposing to do is something like this: where when you whoever over the top navigation tool bar, you will see information grouped underneath it, which will make it easier for users to find what they are looking for.

We hope to get that done in the next few months.

Further research -- we definitely want to be doing this regularly, so we will repeat the survey annually. By doing this, we can establish trends with satisfaction, geographic spread and usage, and we can also explore the secondary analytics that we got from Google and make some further adjustments after that.

That's all from me. Thank you very much.

Sanjaya: Thank you, Bhadrika. Are there any questions? No. Thank you.

APPLAUSE

Sanjaya: If the first two presentations are actually for addressing the needs of our general or public stakeholders, then the next presentation is focusing on the APNIC members and account holders. George Kuo, our member services manager, will present what's news on MyAPNIC, our primary members service portal.

George Kuo: Thank you, Sanjaya. My name is George Kuo. I look after the member services. One of my responsibilities is to be involved in the development of MyAPNIC.

Briefly, my presentation today is going to highlight on three features that we have built into MyAPNIC, for membership support.

For those of of you who are not quite familiar with MyAPNIC, it really is a secure members services website or tools, to support members who like to manage the Internet resources -- because we have built in Whois, update function and also other features that support policy implementation.

Of course, a lot of members who wish to manage their account details and contacts can also use the tools online that are available 24 hours, any time that it is needed.

Of course, to support the ongoing needs of the members, a lot of policy implementation also continues to be built into the tools.

The access is really easy, it is available to all members, and corporate contact will get instant sign-up, just using a user name and password, and other contacts, when it is approved by the corporate contact, would also get access straight away.

The first feature I would like to highlight is the support for IPv4 transfers. Many of you probably are already familiar with the proposal prop-50 and prop-96, the recent one implemented in November last year, and this is about the recipient account having to demonstrate their needs before receiving the address space, and the transfer can happen to all account holders of APNIC.

The feature that I would like to highlight for IPv4 transfers is the parties who are involved in the transfers will be able to use the forms that we built in, so the source account will first have to initiate the transfer, and the recipient account will be informed, so that they can go and take the next step, they can go and accept or reject the transfer, provided they take the action in the next 30 days, otherwise the transfer initiated by the source will be cancelled.

Throughout the process, all the corporate contacts of both accounts will be informed, kept updated with the status of the transfer. As a result, the successful transfer will be published in the transfer log.

Just to give you an idea of what has been happening since that feature has been introduced, these are the statistics of the transaction of the transfer using IPv4 transfer policy. The updated stats are available from the url here, as you can see.

The next thing I would like to also highlight, this is the screenshot you will see when you log into MyAPNIC, you will see the forms available, one for the source to initiate and one for the recipient to receive.

The next thing I would like to demonstrate to you is what we call transfer pre-approval. This is what I like to call the icing on the cake that we add on to support the IPv4 transfer. Because we know a lot of members out there may have the need for more IPv4 addresses now, but are not able to find a source and entity to transfer. So with this feature, it actually helps them to be able to submit their resource needs to APNIC and have it evaluated by the Hostmaster, so they are sure that by the time when they have identified or located the source to transfer, then they will be able to just do it without having to worry about whether the requirement is going to be rejected or not being able to meet the policy criteria.

The pre-approvals, once approved, will last for 12 months, so it allows them for the next 12 months to start looking for the source to transfer. If during this period the needs have changed again, they can resubmit and have it re-evaluated, and when the new site of approval is approved, then it will override the previous one.

Again, in the resources page, when the user logs in, they will see the transfer pre-approval, and you just click on it and follow the form. It is a very simple form, and eventually it will ask the user to demonstrate the need, but basically it is the same resource request form the user has been using in MyAPNIC.

The second thing I would like to talk about or share is the resource certification feature. This has actually been available since 2008, but basically it is to support members who like to use secure routing, and in plain English, it enables a third party to verify the authenticity of information about Internet resources when that is digitally signed by the resource holder.

What is really in the resource certification feature? I will show you the screenshot in a minute. It allows the user or APNIC member to create their route origin attestation. Because this is a secure feature, for the user who likes to access this particular feature, they will need to log in using APNIC digital certificate, and they will need to also activate the service before they start using it, so it is optional.

Again, in the services page, if you log in with APNIC digital certificate, you will see the "Resource certification" at the bottom of the page, where the user will be able to click. If it is the first time that you have accessed this, you will be asked to activate this service. Once you have activated it, you will be able to see this page where you can view the certificate information and also create the ROA.

The last things I would like to share about the DNSSEC feature, to support members who are ready for DNSSEC, the three stages for APNIC Secretariat to prepare for this and the last stage is for the MyAPNIC implementation, which was introduced in the middle of last year.

Basically, it is the improvement of the Whois template that we have added the ds-rdata attribute, so those who are Eadie will be able to update the existing domain object by introducing the ds-rdata value into the attribute. It also has a bulk update feature for managers who have a lot of resources to manage and who like to bulk update.

This is the screen where you go to the Whois update. If you bring up your domain object, you would see the ds-rdata attribute listed there and you could copy and paste the value into it and update this object.

With that, I have finished my presentation. Feel free to ask questions, if you have any. Or if you would like to learn more detail about these features, we have the Members Services staff at the Services Lounge in the exhibition area, so feel free to come and have a chat with us, we are happy to show you step by step.

Thank you.

Sanjaya: Thank you, George.

APPLAUSE

Sanjaya: Next up is myself, to present IPv6 pool management. This is also still very relevant to our members and account holder.

IPv6 delegation requests are really picking up after APNIC hit its last / of IPv4. While APNIC has many small and medium members from the 56 economies we serve, we also have some very, very large members coming from the most populated economies on earth, such as China, India and Indonesia.

Our delegation size varies greatly, because of this, and we find that managing this various sizes of IPv6 delegations is quite tricky, so I am going to present how we are managing APNIC's IPv6 address pool.

I will start with some background, then what is the current practice we have, what issues have been discovered and what solutions we are cooking up, and how this would impact on the policy considerations. So it is good that we have this presentation before the policy discussion tomorrow, because this might be relevant in the discussion.

About the background, there are two IP address management principles which need to be balanced, on one side is the conservation -- I mean address spaces are limited -- and the other side is aggregation. So we do not want to fragmentize address space, we do not want to populate the routing table with too many fragments of IP address space.

In the IPv4's limited space, we actually put more emphasis on conservation over aggregation. In the end, we now have a very complex and large global routing table. The last count is in the range of 400,000 prefixes announced in the global routing table, because we prefer conservation over aggregation.

With IPv6, though, with this very big space, it is an opportunity for us to place more emphasis on aggregation over conservation. So the policies and practices that we have developed so far have been and should continue to maximise long term aggregation potential.

I would like to introduce two different ways of chopping up an address space. The first one is the sequential allocation, that we use mostly for our IPv4 address space, and the second one is sparse allocation, that I need to explain a little bit, which has been recommended since a few years back as the best algorithm to preserve aggregation.

The sequential allocation is simple. You start from the bottom of the address and move up bit by bit. When you make an allocation, when APNIC makes an allocation or delegation, we reserve some space at the back of it, based on what we predict the member will grow into. So it is a best effort basis, but I think we are probably mostly wrong than right in that, because it's really hard to predict how fast each individual member grows.

With IPv6, with the introduction of sparse allocation, we actually have the opportunity to do a binary chop algorithm, so we start with the first prefix coming from the bottom of the stack, and then the next allocation would be taken, number 2 is taken right on the middle, between the bottom and the highest address; and the third would be a quarter in; and the fourth would be in the other quarter; and so on. Just looking at the number there, you can see that we allocate in a binary chop manner.

The reason we do that is because it guarantees that the allocation or delegations are very sparsely allocated, giving a maximum growth potential for every allocation.

The problem with sparse allocation is it turns out that mixing a large or fast growing and small or slow growing blocks in the same sparse allocation is problematic.

If we start doing the binary chop algorithm before long, the largest available space may not fit what the large network needs. So we will have a collision, like what is shown on the diagram.

It turns out that the same size fits all, or put everyone in the same sparse allocation space, creates early fragmentation.

What we then do is we split our pool into multiple large allocation pools. For example, we split into two, one pool for the very large blocks and the other pool for the normal ones. Because the larger blocks allocation rate is much more slower, they have more room to grow. But it is still an informal or best efforts strategy, because we cannot predict the future.

What we have as the current practice is we currently, as you know, have been delegated a /12 from IANA, we split the /12 into two equal size pools of /13 each and one half is used for the large allocation and the other half is for small and medium allocations. The large one is now fragmented down to a /17, so if anyone is needing more than a /17, then it will have to be fragmentized.

The smaller pool is fragmented down to a /24. We make no reservations still. We just do a pure sparse allocation there.

So far so good, but we know that collision is coming and we know, based on this new strategy, we may need additional pools for better management.

What is our future practice? The plan is to have additional pools, so at the moment we have only two pools of /13 each and we would like to have some more separate pools, and we are thinking of introducing the idea of reservations. This may require an additional /12 from IANA, and we think we could qualify under the global policy and could submit a request to IANA shortly.

But this all depends on your comments in this meeting, as well as what is happening tomorrow at the policy discussion.

This is an example of possible pool distribution that APNIC could have. We could say, if we get more address space from IANA and get another /12 or get a /11, we could fit it into four equal sizes of /13 each and put maximum reservation into each of those pools, based on, probably, a nibble boundary split like that.

This is the simplest form of deciding the pool, but I suspect that if we decided to go ahead, it may not be as simple as this one.

The point I want to make here is actually in the reservation, when we make a reservation, the reservation can expire. So if we make a reservation, after making an allocation, and then that member does not come back to us after, say, two years, within the planning window, then we expire the reservation.

Then we will select the APNIC and the NRO Hostmaster will have the ability to select the pool, which pool, out of these, say, four examples, would the will indication be made. They would look at additional considerations, such as the economy size, the population size, what is the ISP market share in the market and so on. It is still a best efforts process, but our aim is to be good and not really perfect, because still it is very hard to predict the future.

The reservation conditions, we would consider that as an internal or administrative practice, so the APNIC Hostmaster and the NIR Hostmaster have the ability to decide whether they want to make a reservation or not, and reservations are not registered or certified, they won't show on the Whois Database, it can't be signed by the RPKI, no authority to advise or route the reservation, and it is never guaranteed, the same as a reservation in IPv4. We could tell it to the holder and it will be allocated when necessary.

Policy considerations: the plan is for the address pool management, including sparse allocation and reservation -- not the plan, it is currently considered as administrative practice, chosen by APNIC staff or Secretariat or NIR Hostmaster, and it still must be consistent with all address policies.

The question then is: should any part of this be formalised in policy? Of course, it is the community decision, and proposals are welcome, as always. It so happens that there is one proposal that exactly touches on this, and it is by accident -- we didn't know when we prepared this presentation, we did not know that the proposal will come. But please come tomorrow and have a look at prop-102. It very much relates to this issue, so please discuss it then.

Thank you. Any questions?

Dean Pemberton:

The proposal boils down to the sparse allocation and having the proposal for people to see. You have put forward a great presentation here, that basically outlines what the current method of doing the sparse allocations are.

Do you have any intention to put the documentation on how it currently works, from the presentation here, up on the website, and then effectively I could pull the proposal and we could go home half an hour earlier.

Sanjaya: We have thought about publishing this practice on our public website. In fact, our discussion with IANA, Elise is on cue over here -- actually, they sort of nudged us to that direction, and we are still thinking about it. But now, since we have this policy, then I think it is timely. It is good that we probably discuss this in a policy discussion.

Dean Pemberton: Right, cool.

Elise Gerich (ICANN and IANA): My question is: you are not going to publish that you have reserved the other block, the other adjacent numbers or range?

Sanjaya: The reservation, yes.

Elise Gerich (ICANN and IANA): As IANA allocating and still supposedly following policy, how will we know that those things are reserved and therefore you have a depletion of your allocation and should get more numbers?

Sanjaya: The intention is to -- for those that we communicate to the member that they have that reservation, the intention is to publish it on our FTP stats file, so IANA could have a look at that stats file and know how much reservation has been made for different proposals in different pools.

Since the global policy says that we would qualify for additional space if the combined reserved and delegated space has reached 50 per cent, then it is our intention to show the reservation space for that proposal.

Elise Gerich (ICANN and IANA): So it will be publicly available on your website?

Sanjaya: It will be publicly available on the IPv6 FTP list, yes.

Elise Gerich (ICANN and IANA): OK. Thank you.

Sanjaya: Andy?

Andy Linton (Policy SIG Chair): Could we go back to your table, Sanjaya.

As Dean said, it is great to have this on the table before we have the discussions tomorrow, I think it would be really useful to our community.

The numbers here, you say this is indicative?

Sanjaya: This is an example, yes.

Andy Linton (Policy SIG Chair): I was seeking some extra clarification here. For example, something in pool A would be typically the first reservation you would get out of here -- the block you would get out of here would be a /32?

Sanjaya: Yes, and if we think they are small members, we will put it there.

Andy Linton (Policy SIG Chair): The next one would be a /28 and a /24 and a /20, as you come up here?

Sanjaya: Yes.

Andy Linton (Policy SIG Chair): You mentioned that you might or you were contemplating notifying the person --

Sanjaya: We can. It depends.

Andy Linton (Policy SIG Chair): That they were in pool A, B, C, D or whatever. It would be implied they were getting a /32, therefore their maximum reservation would be likely a /28. Is it the intention to do that sort of thing, just for clarification?

Sanjaya: Yes, the intention is -- well --

Andy Linton (Policy SIG Chair): I appreciate, I don't want to put you on the spot, but I wondered if that was in the thinking?

Sanjaya: Yes, the thinking is to inform them, but clearly tell them that they cannot route it or it is not ... it is there as a reserved status, and hopefully the filterers and everything would take that into consideration and definitely reject the space that is on reserve status.

Paul Wilson (APNIC): Just a clarification, following up from Andy there. Correct me if I'm wrong here, Sanjaya, but so far our reservations have been internal, they have never been published.

Sanjaya: Correct.

Paul Wilson (APNIC): For the sake of the IANA process, we have always declared to IANA how much we have reserved in accordance with the policy and have based "on that declared reservation, and IANA has trusted that, and that is all that the IPv6 policy requires. But we do recognise that, to start declaring large amounts of reserve space that may come as a surprise and there may be, naturally, an interest in some transparency. So the proposal now is to actually implement that higher level of transparency by putting the reserve blocks into the status files.

Sanjaya: Yes, correct.

Paul Wilson (APNIC): It means, whether or not someone is told that they have a reservation, they would see in the FTP stats file that an allocation that has been made to them has a neighbouring reservation, and they might draw the conclusion --

Sanjaya: It could be done like that, yes.

Paul Wilson (APNIC): Or we may decide to stop playing games and tell them, "Yes, you have a reservation."

The thing I hear when we talk about reservations, they sound like a promise and if you give someone a reservation and tell them about it, they will expect to have it available to them when they need it, which is not the case. We would be making it very clear that a reservation is not a promise forever and a reservation for a particular ISP may need to be broken some time in the future, if that address space is required for other allocations. Correct?

The other critical factor here is that there is no Whois record or digital certificate, RPKI certificate, for reservations, so someone who receives the allocation may well know, and we may choose to tell them that they have the reservation, but the Whois record and the RPKI certificate will absolutely reflect only the allocation that has been made to them.

Sanjaya: Correct. Thanks. Thanks for clarifying, Paul.

That's all from me.

We have two more presentations, and that is by Frank Salanitri, our projects and systems services manager. He will focus now more on a value that we provide to the operator community. There are two presentations, one is his recent work in looking at the abuse contact activities, since we introduced IR prop-79, we have compiled some interesting statistics and he will show some to you, with focus on the South Asia region. After that, he will follow up with a presentation about our root server deployment, also with focus on the South Asia region. Thank you.

Frank Salanitri: Good afternoon. My name is Frank Salanitri. I work for business, but I also looking after a lot of projects in services as well. Services is the area that I recently came from to join the business area.

As Sanjaya explained, my first presentation is about network abuse, an update.

A question I get asked quite often is: what is APNIC's role in preventing network abuse? Honestly, all I can say is, as a registry, APNIC adopts and applies the policies for its community which address network abuse. But we do not have the capacity to investigate complaints, nor do we have the powers to regulate Internet activity in our own country, let alone across borders in other countries.

We also do seek to raise awareness of the need for responsible network management in the Asia Pacific region and also raising awareness of the mechanisms in place for managing network abuse.

We do that through training and communication, communication like this forum here. I have spoken at other NOC forums as well. Actually, I have plenty of time to tell you a quick story, that I was presenting in Sydney at an AusNOC, I think Geoff was there, and at the time I said in the presentation that network operators were stupid for not updating their filters.

At the time, I thought, maybe it wasn't appropriate to say. Then later on, years later, I bumped into people and they say, "You know -- that conference, I don't remember what it was about, the food was -- but I remember being told I was stupid from someone at APNIC and every time I remember him, I look at my filters." So it did serve its purpose.

What are these mechanisms we have in place in our community? We have an IRT object, which is an Internet response team, or that's what it stands for. It's an object that we -- that are mandatory for iNet 6 nums and ... nums, it was a policy that APNIC implemented in the region in APNIC 29, 2010. In out saysa there are approximately 56,000 iNet num objects, of which there are about 35,000 that have a missing IRT object. They are obviously objects that were introduced prior to 2010 when the policy was introduced.

Looking there quickly, you can see, that is APNIC's IRT object. The email address associated with it is security@apnic.net. As you see, this one here applies to the top level parent block for one /8.

I am going to give you an idea of the volume and complaints we get to security@apnic.net.

This is data from March last year. For that month we got approximately 22,354 -- that is an exact number -- for that whole month. As you see, the majority, 18,917 complaints were all to do with spam-related complaints.

Looking at that whole month, we see again that 79 per cent or nearly 80 per cent is all to do with spam. The next one, 6.9 per cent, is to do with attacks. Mail server atax 4 per cent. All the rest are all to do with some form of attack. The smaller, the lesser amounts are trademark infringements and fraudulent sites.

Looking at the distribution of email type complaints by region, we see that the highest region in terms of spam complaints is East Asia with 39 per cent, then South Asia with 27 per cent and then South-East Asia with 27 per cent. South Asia and South-East Asia are the same. South Asia, the region we are in now, includes Pakistan, Bangladesh and Butan. South-East Asia is countries like the Philippines, Vietnam and Thailand.

Then the distribution of non-email type complaints by region, 50 per cent come from East Asia, being China, Korea, Thailand, Japan, that area there; and then South Asia is down here at 21 per cent.

For that month, overall, just for South Asia, we see 87 per cent were spam complaints, 9.7 per cent were mail server attacks, DDOS was 0.9 per cent and so forth.

In September, I presented those figures at a prior APRICOT meeting, and then a black lister in Europe thought that we weren't getting enough complaints, and he started for the month of September sent us all the complaints for our region to security@apnic.net, irrespective whether there was an IRT object. If it came from our region, he sent us the email complaint and we got 300,000 emails in that one month.

50 per cent or 165,000 were in the South-East Asia, and South Asia 37 per cent, which was 120,000-odd.

He proceeded to do that until we emailed him and told him to please stop, our mail server was starting to suffer slightly.

In conclusion of what I have been speaking about, IRT objects in South Asia spam is people's most frequent complaint at 87 per cent. IRT objects are registered on Whois to reach the appropriate people for abuse complaints.

We understand there are issues with points of contact and handling these complaints. Points of contact are not always up to date or reachable, and points of contact also receive large amounts of spam. We need to ensure the mechanisms in place are adequate to help resolve the complaints.

What can you do? Well, we need your cooperation to maintain your Whois contacts. Please review your contacts on Whois, your email address, your phone numbers. Of course, if you do not have an IRT object registered against the objects, please do. If you see incorrect contacts in Whois, not just your own objects but other people's objects, please send an email to helpdesk@apnic.net and please give us feedback about the effectiveness of IRT objects.

If there are any complaints or problems or solutions about abuse, we would love to hear about them, so email the Secretariat at helpdesk@apnic.net.

Of course, you can also make policy proposals to improve IRT objects or points of contacts in Whois, if you feel there is a need for change or improvement.

That is the end of my first presentation. Are there any questions?

My next presentation is on the root server deployments in our region. APNIC has been supporting root server deployments since 2002. The aim of the project has been to substantially improve the Internet reachability and response time in our region. Of course, this has directly benefited ISPs and end users. Because queries have been answered locally, instead of having to traverse into another country and then come back again, those response times have been dramatically shortened.

APNIC funds the equipment and the initial installation costs and also the ongoing maintenance at those sites.

The host, who is the organization that hosts the quilt and the site in their country, they provide the datacentre rack space and all the transit costs involved in maintaining that site there.

There are 25 root server instances funded partially or fully by APNIC, 14 Fs, 8 Is and 3 Ks.

Here is a map of the distribution of root servers in our region. The most recent ones, last year, were F in Ulaanbaatar in September last year, and Thampu in Butan, I think that was April last year, and this is our distribution of servers in the South Asia region.

I will be going into more detail about the servers in India, since obviously we are in India at the moment.

I am not sure if you can see that, but this is the actual I-Root server in Mumbai. It is three servers, a router and a switch. It is a very simple set-up. For what it does, the equipment does not seem very substantial for the work and the service that it provides to the community.

Now I am going to go through and look at the workload, what each of the I, F and K are doing in India, and compare them to appropriate sites in the Asia Pacific region, to give you an idea of the workload that the servers are doing here in India.

This one here is the last 12 months for Mumbai, the I-Root, and the graphs I have are different because they have come from the different root operators, so the formats of the graphs are slightly different, so bear with me that they are not all consistently the same.

This one here is queries per second. As you see, from the information, the summary at the bottom, the average queries per second is 893. You see a few dips here and there, and of course no one is perfect; obviously at some time the node has been down. Obviously it came back up quite quickly.

Here is a comparison to Hong Kong. Its average queries per second is 397, so you can see it's just over half of the workload of Mumbai. As you can see, the workload might be smaller or less, but it has been consistently up the whole time.

Now looking at K-Root in Delhi, queries per second. As you can see, there has been a substantial increase in the last 12 months from February, servicing about, say, 1,000 or 1,250 queries per second. There was a slight dip in October, then a gap where the equipment was down. Obviously the equipment was having problems in this period and finally crashed, then came up again. We see from October to December there has been a slow increase up to now, possibly servicing about 2,250 queries a second, on average.

With K, there is no comparable -- there is no K-Root in Hong Kong. The closest one might be Japan, but it's a super-node, so I compared it to Brisbane instead. Brisbane, on average, is servicing about 300 queries per second consistently.

I like this graph here, where it shows a little dip around Christmas time, so it is good to see people possibly closing their computers and spending time with their families.

F-Root in Chennai. This graph is packets per second. I have been told, at the moment, it is servicing about 966 queries per second. The graph here is for the last seven days, from last Sunday, going back. You see the troughs up and down, so that is daytime, nighttime, daytime, nighttime. Obviously at night the traffic goes down.

Compared to Hong Kong, which is 642 queries per second, but it is a bit more of a flatter structure -- not the large peaks and troughs.

Where are we going with root servers in 2012? We have a complete rebuild planned next week for F-Root in Chennai, which is a replacement of three serves and two routers. We are trying a small form factor F-Root installatin in Dakar, which is one server and one router. We will be trialling this as a great cost effective solution for small island countries, say in the Pacific region, where they experience only fairly low traffic.

There will also be more replacements and rebuilds in August for F-Root in Hong Kong, we have routers planned for Korea in August, and there is also minor service work for Is and Ks around the region as well. We also have two new sites in negotiation at the moment. I cannot really say which ones they are at the moment, but there will be more information about them at the next APNIC Meeting in Cambodia.

Thank you. That is the end of that presentation. Any questions?

Elise Gerich (ICANN and IANA): Are the 25 root servers accessible by both IPv4 and IPv6?

Frank Salanitri: Yes, not all of them. There are some. The map we have on our website has further information there as to the ones that do and don't. Obviously, India, I think they are all v4, but that is a future plan as well, to make sure we upgrade all the root servers around the region to service v6 as well.

Elise Gerich (ICANN and IANA): OK. Just wondered. Thank you.

Sanjaya: Any other questions? Thank you, Frank.

APPLAUSE

Sanjaya: That concludes all the presentations for this APNIC Services session.

As I said at the opening, this is our first APNIC Services Forum, we are going to have another one in the next meeting in Cambodia. So if anyone has any ideas or suggestions on the topics to cover for the next meeting, please say so now or email helpdesk@apnic.net.

Anyone? No. OK. That concludes our session for today.

Please don't forget that at 6.00 pm today in this same room we will have the AP IPv6 Task Force gathering. If you want to know what's happening with IPv6 deployment in this region, please make a time to attend the meeting. There is a lot of information sharing happening in that task force meeting.

Thank you.

APPLAUSE